探索 Pod 及其端点的终止行为
连接您的应用程序与服务后,按照 连接应用程序与服务 中概述的步骤,您将拥有一个持续运行的复制应用程序,该应用程序在网络上公开。本教程将帮助您查看吊舱的终止流程,并探讨实现优雅连接耗尽的方法。
吊舱及其端点的终止过程
通常,您需要终止吊舱,无论是升级还是缩减规模。为了提高应用程序的可用性,实施适当的活动连接耗尽可能很重要。
本教程解释了吊舱终止与相应端点状态和删除之间的流程,并使用简单的 nginx web 服务器来演示此概念。
带端点终止的示例流程
以下是 吊舱终止 文档中描述的流程示例。
假设您有一个包含单个 nginx
副本(仅用于演示目的)和一个服务的部署
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
terminationGracePeriodSeconds: 120 # extra long grace period
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
lifecycle:
preStop:
exec:
# Real life termination may take any time up to terminationGracePeriodSeconds.
# In this example - just hang around for at least the duration of terminationGracePeriodSeconds,
# at 120 seconds container will be forcibly terminated.
# Note, all this time nginx will keep processing requests.
command: [
"/bin/sh", "-c", "sleep 180"
]
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
现在使用以上文件创建部署吊舱和服务
kubectl apply -f pod-with-graceful-termination.yaml
kubectl apply -f explore-graceful-termination-nginx.yaml
吊舱和服务运行后,您可以获取任何关联的 EndpointSlices 的名称
kubectl get endpointslice
输出类似于以下内容
NAME ADDRESSTYPE PORTS ENDPOINTS AGE
nginx-service-6tjbr IPv4 80 10.12.1.199,10.12.1.201 22m
您可以看到它的状态,并验证是否注册了一个端点
kubectl get endpointslices -o json -l kubernetes.io/service-name=nginx-service
输出类似于以下内容
{
"addressType": "IPv4",
"apiVersion": "discovery.k8s.io/v1",
"endpoints": [
{
"addresses": [
"10.12.1.201"
],
"conditions": {
"ready": true,
"serving": true,
"terminating": false
现在让我们终止吊舱并验证吊舱是否正在终止,并尊重优雅终止期间配置
kubectl delete pod nginx-deployment-7768647bf9-b4b9s
所有吊舱
kubectl get pods
输出类似于以下内容
NAME READY STATUS RESTARTS AGE
nginx-deployment-7768647bf9-b4b9s 1/1 Terminating 0 4m1s
nginx-deployment-7768647bf9-rkxlw 1/1 Running 0 8s
您可以看到新吊舱已调度。
虽然正在为新吊舱创建新的端点,但旧端点仍处于终止状态
kubectl get endpointslice -o json nginx-service-6tjbr
输出类似于以下内容
{
"addressType": "IPv4",
"apiVersion": "discovery.k8s.io/v1",
"endpoints": [
{
"addresses": [
"10.12.1.201"
],
"conditions": {
"ready": false,
"serving": true,
"terminating": true
},
"nodeName": "gke-main-default-pool-dca1511c-d17b",
"targetRef": {
"kind": "Pod",
"name": "nginx-deployment-7768647bf9-b4b9s",
"namespace": "default",
"uid": "66fa831c-7eb2-407f-bd2c-f96dfe841478"
},
"zone": "us-central1-c"
},
{
"addresses": [
"10.12.1.202"
],
"conditions": {
"ready": true,
"serving": true,
"terminating": false
},
"nodeName": "gke-main-default-pool-dca1511c-d17b",
"targetRef": {
"kind": "Pod",
"name": "nginx-deployment-7768647bf9-rkxlw",
"namespace": "default",
"uid": "722b1cbe-dcd7-4ed4-8928-4a4d0e2bbe35"
},
"zone": "us-central1-c"
这使应用程序能够在终止期间传达其状态,并且客户端(例如负载均衡器)能够实施连接耗尽功能。这些客户端可以检测终止端点,并为其实现特殊逻辑。
在 Kubernetes 中,终止的端点始终将其 ready
状态设置为 false
。这需要发生,以确保向后兼容性,因此现有负载均衡器不会将其用于常规流量。如果需要在终止吊舱上进行流量耗尽,则可以将实际就绪状态检查为条件 serving
。
删除吊舱后,旧端点也将被删除。
下一步
- 了解如何 连接应用程序与服务
- 了解有关 使用服务访问集群中的应用程序 的更多信息
- 了解有关 使用服务将前端连接到后端 的更多信息
- 了解有关 创建外部负载均衡器 的更多信息
最后修改时间:2023 年 8 月 24 日下午 6:38 PST:使用 code_sample 短代码代替 code 短代码 (e8b136c3b3)