Skip to content

Commit e53f424

Browse files
k8s-ci-robotk8s-ci-robot
authored
Merge pull request #40311 from windsonsea/endter
[zh] sync pods-and-endpoint-termination-flow.md
2 parents 4a589f6 + 30d839f commit e53f424

File tree

2 files changed

+334
-0
lines changed

2 files changed

+334
-0
lines changed

‎content/zh-cn/docs/tutorials/services/pods-and-endpoint-termination-flow.md

Lines changed: 302 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,302 @@
1+
---
2+
title: 探索 Pod 及其端点的终止行为
3+
content_type: tutorial
4+
weight: 60
5+
---
6+
<!--
7+
title: Explore Termination Behavior for Pods And Their Endpoints
8+
content_type: tutorial
9+
weight: 60
10+
-->
11+
12+
<!-- overview -->
13+
14+
<!--
15+
Once you connected your Application with Service following steps
16+
like those outlined in [Connecting Applications with Services](/docs/tutorials/services/connect-applications-service/),
17+
you have a continuously running, replicated application, that is exposed on a network.
18+
This tutorial helps you look at the termination flow for Pods and to explore ways to implement
19+
graceful connection draining.
20+
-->
21+
一旦你参照[使用 Service 连接到应用](/zh-cn/docs/tutorials/services/connect-applications-service/)中概述的那些步骤使用
22+
Service 连接到了你的应用，你就有了一个持续运行的多副本应用暴露在了网络上。
23+
本教程帮助你了解 Pod 的终止流程，探索实现连接排空的几种方式。
24+
25+
<!-- body -->
26+
27+
<!--
28+
## Termination process for Pods and their endpoints
29+
30+
There are often cases when you need to terminate a Pod - be it for upgrade or scale down.
31+
In order to improve application availability, it may be important to implement
32+
a proper active connections draining.
33+
34+
This tutorial explains the flow of Pod termination in connection with the
35+
corresponding endpoint state and removal by using
36+
a simple nginx web server to demonstrate the concept.
37+
-->
38+
## Pod 及其端点的终止过程 {#termination-process-for-pods-and-endpoints}
39+
40+
你经常会遇到需要终止 Pod 的场景，例如为了升级或缩容。
41+
为了改良应用的可用性，实现一种合适的活跃连接排空机制变得重要。
42+
43+
本教程将通过使用一个简单的 nginx Web 服务器演示此概念，
44+
解释 Pod 终止的流程及其与相应端点状态和移除的联系。
45+
46+
<!-- body -->
47+
48+
<!--
49+
## Example flow with endpoint termination
50+
51+
The following is the example of the flow described in the
52+
[Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
53+
document.
54+
55+
Let's say you have a Deployment containing of a single `nginx` replica
56+
(just for demonstration purposes) and a Service:
57+
-->
58+
## 端点终止的示例流程 {#example-flow-with-endpoint-termination}
59+
60+
以下是 [Pod 终止](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)文档中所述的流程示例。
61+
62+
假设你有包含单个 nginx 副本（仅用于演示目的）的一个 Deployment 和一个 Service：
63+
64+
{{< codenew file="service/pod-with-graceful-termination.yaml" >}}
65+
66+
<!--
67+
# extra long grace period
68+
# Real life termination may take any time up to terminationGracePeriodSeconds.
69+
# In this example - just hang around for at least the duration of terminationGracePeriodSeconds,
70+
# at 120 seconds container will be forcibly terminated.
71+
# Note, all this time nginx will keep processing requests.
72+
-->
73+
```yaml
74+
apiVersion: apps/v1
75+
kind: Deployment
76+
metadata:
77+
name: nginx-deployment
78+
labels:
79+
app: nginx
80+
spec:
81+
replicas: 1
82+
selector:
83+
matchLabels:
84+
app: nginx
85+
template:
86+
metadata:
87+
labels:
88+
app: nginx
89+
spec:
90+
terminationGracePeriodSeconds: 120 # 超长优雅期
91+
containers:
92+
- name: nginx
93+
image: nginx:latest
94+
ports:
95+
- containerPort: 80
96+
lifecycle:
97+
preStop:
98+
exec:
99+
# 实际生产环境中的 Pod 终止可能需要执行任何时长，但不会超过 terminationGracePeriodSeconds。
100+
# 在本例中，只需挂起至少 terminationGracePeriodSeconds 所指定的持续时间，
101+
# 在 120 秒时容器将被强制终止。
102+
# 请注意，在所有这些时间点 nginx 都将继续处理请求。
103+
command: [
104+
"/bin/sh", "-c", "sleep 180"
105+
]
106+
107+
---
108+
109+
apiVersion: v1
110+
kind: Service
111+
metadata:
112+
name: nginx-service
113+
spec:
114+
selector:
115+
app: nginx
116+
ports:
117+
- protocol: TCP
118+
port: 80
119+
targetPort: 80
120+
```
121+
122+
<!--
123+
Once the Pod and Service are running, you can get the name of any associated EndpointSlices:
124+
-->
125+
一旦 Pod 和 Service 开始运行，你就可以获取对应的所有 EndpointSlices 的名称：
126+
127+
```shell
128+
kubectl get endpointslice
129+
```
130+
131+
<!--
132+
The output is similar to this:
133+
-->
134+
输出类似于：
135+
136+
```none
137+
NAME ADDRESSTYPE PORTS ENDPOINTS AGE
138+
nginx-service-6tjbr IPv4 80 10.12.1.199,10.12.1.201 22m
139+
```
140+
141+
<!--
142+
You can see its status, and validate that there is one endpoint registered:
143+
-->
144+
你可以查看其 status 并验证已经有一个端点被注册：
145+
146+
```shell
147+
kubectl get endpointslices -o json -l kubernetes.io/service-name=nginx-service
148+
```
149+
150+
<!--
151+
The output is similar to this:
152+
-->
153+
输出类似于：
154+
155+
```none
156+
{
157+
"addressType": "IPv4",
158+
"apiVersion": "discovery.k8s.io/v1",
159+
"endpoints": [
160+
{
161+
"addresses": [
162+
"10.12.1.201"
163+
],
164+
"conditions": {
165+
"ready": true,
166+
"serving": true,
167+
"terminating": false
168+
}
169+
}
170+
]
171+
}
172+
```
173+
174+
<!--
175+
Now let's terminate the Pod and validate that the Pod is being terminated
176+
respecting the graceful termination period configuration:
177+
-->
178+
现在让我们终止这个 Pod 并验证该 Pod 正在遵从体面终止期限的配置进行终止：
179+
180+
```shell
181+
kubectl delete pod nginx-deployment-7768647bf9-b4b9s
182+
```
183+
184+
<!--
185+
All pods:
186+
-->
187+
查看所有 Pod：
188+
189+
```shell
190+
kubectl get pods
191+
```
192+
193+
<!--
194+
The output is similar to this:
195+
-->
196+
输出类似于：
197+
198+
```none
199+
NAME READY STATUS RESTARTS AGE
200+
nginx-deployment-7768647bf9-b4b9s 1/1 Terminating 0 4m1s
201+
nginx-deployment-7768647bf9-rkxlw 1/1 Running 0 8s
202+
```
203+
204+
<!--
205+
You can see that the new pod got scheduled.
206+
207+
While the new endpoint is being created for the new Pod, the old endpoint is
208+
still around in the terminating state:
209+
-->
210+
你可以看到新的 Pod 已被调度。
211+
212+
当系统在为新的 Pod 创建新的端点时，旧的端点仍处于 Terminating 状态：
213+
214+
```shell
215+
kubectl get endpointslice -o json nginx-service-6tjbr
216+
```
217+
218+
<!--
219+
The output is similar to this:
220+
-->
221+
输出类似于：
222+
223+
```none
224+
{
225+
"addressType": "IPv4",
226+
"apiVersion": "discovery.k8s.io/v1",
227+
"endpoints": [
228+
{
229+
"addresses": [
230+
"10.12.1.201"
231+
],
232+
"conditions": {
233+
"ready": false,
234+
"serving": true,
235+
"terminating": true
236+
},
237+
"nodeName": "gke-main-default-pool-dca1511c-d17b",
238+
"targetRef": {
239+
"kind": "Pod",
240+
"name": "nginx-deployment-7768647bf9-b4b9s",
241+
"namespace": "default",
242+
"uid": "66fa831c-7eb2-407f-bd2c-f96dfe841478"
243+
},
244+
"zone": "us-central1-c"
245+
},
246+
]
247+
{
248+
"addresses": [
249+
"10.12.1.202"
250+
],
251+
"conditions": {
252+
"ready": true,
253+
"serving": true,
254+
"terminating": false
255+
},
256+
"nodeName": "gke-main-default-pool-dca1511c-d17b",
257+
"targetRef": {
258+
"kind": "Pod",
259+
"name": "nginx-deployment-7768647bf9-rkxlw",
260+
"namespace": "default",
261+
"uid": "722b1cbe-dcd7-4ed4-8928-4a4d0e2bbe35"
262+
},
263+
"zone": "us-central1-c"
264+
}
265+
}
266+
```
267+
268+
<!--
269+
This allows applications to communicate their state during termination
270+
and clients (such as load balancers) to implement a connections draining functionality.
271+
These clients may detect terminating endpoints and implement a special logic for them.
272+
-->
273+
这种设计使得应用可以在终止期间公布自己的状态，而客户端（如负载均衡器）则可以实现连接排空功能。
274+
这些客户端可以检测到正在终止的端点，并为这些端点实现特殊的逻辑。
275+
276+
<!--
277+
In Kubernetes, endpoints that are terminating always have their `ready` status set as as `false`.
278+
This needs to happen for backward
279+
compatibility, so existing load balancers will not use it for regular traffic.
280+
If traffic draining on terminating pod is needed, the actual readiness can be
281+
checked as a condition `serving`.
282+
283+
When Pod is deleted, the old endpoint will also be deleted.
284+
-->
285+
在 Kubernetes 中，正在终止的端点始终将其 `ready` 状态设置为 `false`。
286+
这是为了满足向后兼容的需求，确保现有的负载均衡器不会将 Pod 用于常规流量。
287+
如果需要排空正被终止的 Pod 上的流量，可以将 `serving` 状况作为实际的就绪状态。
288+
289+
当 Pod 被删除时，旧的端点也会被删除。
290+
291+
## {{% heading "whatsnext" %}}
292+
293+
<!--
294+
* Learn how to [Connect Applications with Services](/docs/tutorials/services/connect-applications-service/)
295+
* Learn more about [Using a Service to Access an Application in a Cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/)
296+
* Learn more about [Connecting a Front End to a Back End Using a Service](/docs/tasks/access-application-cluster/connecting-frontend-backend/)
297+
* Learn more about [Creating an External Load Balancer](/docs/tasks/access-application-cluster/create-external-load-balancer/)
298+
-->
299+
* 了解如何[使用 Service 连接到应用](/zh-cn/docs/tutorials/services/connect-applications-service/)
300+
* 进一步了解[使用 Service 访问集群中的应用](/zh-cn/docs/tasks/access-application-cluster/service-access-application-cluster/)
301+
* 进一步了解[使用 Service 把前端连接到后端](/zh-cn/docs/tasks/access-application-cluster/connecting-frontend-backend/)
302+
* 进一步了解[创建外部负载均衡器](/zh-cn/docs/tasks/access-application-cluster/create-external-load-balancer/)

‎content/zh-cn/examples/service/pod-with-graceful-termination.yaml

Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
1+
apiVersion: apps/v1
2+
kind: Deployment
3+
metadata:
4+
name: nginx-deployment
5+
labels:
6+
app: nginx
7+
spec:
8+
replicas: 1
9+
selector:
10+
matchLabels:
11+
app: nginx
12+
template:
13+
metadata:
14+
labels:
15+
app: nginx
16+
spec:
17+
terminationGracePeriodSeconds: 120 # 超长优雅期
18+
containers:
19+
- name: nginx
20+
image: nginx:latest
21+
ports:
22+
- containerPort: 80
23+
lifecycle:
24+
preStop:
25+
exec:
26+
# 实际生产环境中的 Pod 终止可能需要执行任何时长，但不会超过 terminationGracePeriodSeconds。
27+
# 在本例中，只需挂起至少 terminationGracePeriodSeconds 所指定的持续时间，
28+
# 在 120 秒时容器将被强制终止。
29+
# 请注意，在所有这些时间点 nginx 都将继续处理请求。
30+
command: [
31+
"/bin/sh", "-c", "sleep 180"
32+
]

0 commit comments

Comments
 (0)