Skip to content

Commit cdd66be

Browse files
k8s-ci-robotk8s-ci-robot
authored
Merge pull request #40199 from kmuto/tutorials/services/pods-and-endpoint-termination-flow
[ja] add Japanese translation for tutorials/services/pods-and-endpoint-termination-flow
2 parents 9b21522 + 40d4a10 commit cdd66be

File tree

2 files changed

+237
-0
lines changed

2 files changed

+237
-0
lines changed

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

Lines changed: 205 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,205 @@
1+
---
2+
title: Podとそのエンドポイントの終了動作を探る
3+
content_type: tutorial
4+
weight: 60
5+
---
6+
7+
8+
<!-- overview -->
9+
10+
[アプリケーションをServiceに接続する](/docs/tutorials/services/connect-applications-service/)で概略を示したステップに従ってアプリケーションをServiceに接続すると、ネットワーク上で公開され、継続的に実行されて、複製されたアプリケーションが得られます。
11+
このチュートリアルでは、Podを終了する流れを見て、gracefulな(猶予のある)接続ドレインを実装する手法を模索するための手助けをします。
12+
13+
<!-- body -->
14+
15+
## Podの終了手続きとそのエンドポイント
16+
17+
アップグレードやスケールダウンのために、Podを終了しなければならない場面はままあります。
18+
アプリケーションの可用性を高めるために、適切なアクティブ接続ドレインを実装することは重要でしょう。
19+
20+
このチュートリアルでは概念のデモンストレーションのために、シンプルなnginx Webサーバーを例として、対応するエンドポイントの状態に関連したPodの終了および削除の流れを説明します。
21+
22+
<!-- body -->
23+
24+
## エンドポイント終了の流れの例
25+
26+
以下は、[Podの終了](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)ドキュメントに記載されている流れの例です。
27+
28+
1つの`nginx`レプリカを含むDeployment(純粋にデモンストレーション目的です)とServiceがあるとします:
29+
30+
{{< codenew file="service/pod-with-graceful-termination.yaml" >}}
31+
32+
```yaml
33+
apiVersion: apps/v1
34+
kind: Deployment
35+
metadata:
36+
name: nginx-deployment
37+
labels:
38+
app: nginx
39+
spec:
40+
replicas: 1
41+
selector:
42+
matchLabels:
43+
app: nginx
44+
template:
45+
metadata:
46+
labels:
47+
app: nginx
48+
spec:
49+
terminationGracePeriodSeconds: 120 # 非常に長い猶予期間
50+
containers:
51+
- name: nginx
52+
image: nginx:latest
53+
ports:
54+
- containerPort: 80
55+
lifecycle:
56+
preStop:
57+
exec:
58+
# 実際の活動終了はterminationGracePeriodSecondsまでかかる可能性がある。
59+
# この例においては、少なくともterminationGracePeriodSecondsの間は待機し、
60+
# 120秒経過すると、コンテナは強制終了される。
61+
# この間ずっとnginxはリクエストを処理し続けていることに注意。
62+
command: [
63+
"/bin/sh", "-c", "sleep 180"
64+
]
65+
66+
---
67+
68+
apiVersion: v1
69+
kind: Service
70+
metadata:
71+
name: nginx-service
72+
spec:
73+
selector:
74+
app: nginx
75+
ports:
76+
- protocol: TCP
77+
port: 80
78+
targetPort: 80
79+
```
80+
81+
PodとServiceが実行中になったら、関連付けられたEndpointSliceの名前を得られます:
82+
83+
```shell
84+
kubectl get endpointslice
85+
```
86+
87+
この出力は以下のようなものになります:
88+
89+
```none
90+
NAME ADDRESSTYPE PORTS ENDPOINTS AGE
91+
nginx-service-6tjbr IPv4 80 10.12.1.199,10.12.1.201 22m
92+
```
93+
94+
状態からわかるように、1つのエンドポイントが登録されていることが確認できます:
95+
96+
```shell
97+
kubectl get endpointslices -o json -l kubernetes.io/service-name=nginx-service
98+
```
99+
100+
この出力は以下のようなものになります:
101+
102+
```none
103+
{
104+
"addressType": "IPv4",
105+
"apiVersion": "discovery.k8s.io/v1",
106+
"endpoints": [
107+
{
108+
"addresses": [
109+
"10.12.1.201"
110+
],
111+
"conditions": {
112+
"ready": true,
113+
"serving": true,
114+
"terminating": false
115+
```
116+
117+
では、Podを終了し、そのPodがgracefulな終了期間設定を守って終了されていることを確認してみましょう:
118+
119+
```shell
120+
kubectl delete pod nginx-deployment-7768647bf9-b4b9s
121+
```
122+
123+
全Podについて調べます:
124+
125+
```shell
126+
kubectl get pods
127+
```
128+
129+
この出力は以下のようなものになります:
130+
131+
```none
132+
NAME READY STATUS RESTARTS AGE
133+
nginx-deployment-7768647bf9-b4b9s 1/1 Terminating 0 4m1s
134+
nginx-deployment-7768647bf9-rkxlw 1/1 Running 0 8s
135+
```
136+
137+
新しいPodがスケジュールされたことを見てとれます。
138+
139+
新しいPodのために新しいエンドポイントが作成される間、古いエンドポイントは終了中の状態のまま残っています:
140+
141+
```shell
142+
kubectl get endpointslice -o json nginx-service-6tjbr
143+
```
144+
145+
この出力は以下のようなものになります:
146+
147+
```none
148+
{
149+
"addressType": "IPv4",
150+
"apiVersion": "discovery.k8s.io/v1",
151+
"endpoints": [
152+
{
153+
"addresses": [
154+
"10.12.1.201"
155+
],
156+
"conditions": {
157+
"ready": false,
158+
"serving": true,
159+
"terminating": true
160+
},
161+
"nodeName": "gke-main-default-pool-dca1511c-d17b",
162+
"targetRef": {
163+
"kind": "Pod",
164+
"name": "nginx-deployment-7768647bf9-b4b9s",
165+
"namespace": "default",
166+
"uid": "66fa831c-7eb2-407f-bd2c-f96dfe841478"
167+
},
168+
"zone": "us-central1-c"
169+
},
170+
{
171+
"addresses": [
172+
"10.12.1.202"
173+
],
174+
"conditions": {
175+
"ready": true,
176+
"serving": true,
177+
"terminating": false
178+
},
179+
"nodeName": "gke-main-default-pool-dca1511c-d17b",
180+
"targetRef": {
181+
"kind": "Pod",
182+
"name": "nginx-deployment-7768647bf9-rkxlw",
183+
"namespace": "default",
184+
"uid": "722b1cbe-dcd7-4ed4-8928-4a4d0e2bbe35"
185+
},
186+
"zone": "us-central1-c"
187+
```
188+
189+
190+
これを使うと、終了中のアプリケーションがその状態について、接続ドレイン機能の実装目的でクライアント(ロードバランサーなど)と通信する、ということが可能です。
191+
これらのクライアントではエンドポイントの終了を検出し、そのための特別なロジックを実装できます。
192+
193+
Kubernetesでは、終了中のエンドポイントの`ready`状態は全て`false`にセットされます。
194+
これは後方互換性のために必要な措置で、既存のロードバランサーは通常のトラフィックにはそれを使用しません。
195+
Podの終了時にトラフィックのドレインが必要な場合、実際に準備できているかは`serving`状態として調べられます。
196+
197+
Podが削除される時には、古いエンドポイントも削除されます。
198+
199+
## {{% heading "whatsnext" %}}
200+
201+
202+
* [アプリケーションをServiceに接続する](/docs/tutorials/services/connect-applications-service/)方法を学びます。
203+
* [Serviceを利用したクラスター内のアプリケーションへのアクセス](/ja/docs/tasks/access-application-cluster/service-access-application-cluster/)を学びます。
204+
* [Serviceを使用してフロントエンドをバックエンドに接続する](/ja/docs/tasks/access-application-cluster/connecting-frontend-backend/)を学びます。
205+
* [外部ロードバランサーの作成](/docs/tasks/access-application-cluster/create-external-load-balancer/)を学びます。

‎content/ja/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+
# 実際の活動終了はterminationGracePeriodSecondsまでかかる可能性がある。
27+
# この例においては、少なくともterminationGracePeriodSecondsの間は待機し、
28+
# 120秒経過すると、コンテナは強制的に終了される。
29+
# この間ずっとnginxはリクエストを処理し続けていることに注意。
30+
command: [
31+
"/bin/sh", "-c", "sleep 180"
32+
]

0 commit comments

Comments
 (0)