質問編集履歴
2
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -4,7 +4,6 @@
|
|
|
4
4
|
|
|
5
5
|
Deployment が 2 つ定義されており，`app-master` ではマスターアプリケーションを 1 Pod だけ，
|
|
6
6
|
`app-worker` ではマスターに依存しているワーカーアプリケションを複数 Pod 作成しています。
|
|
7
|
-
（以下では，ホストやポートの指定等の，実際の細かい設定は省いています。）
|
|
8
7
|
|
|
9
8
|
```lang-yaml
|
|
10
9
|
apiVersion: apps/v1
|
|
@@ -44,7 +43,15 @@
|
|
|
44
43
|
image: (略)
|
|
45
44
|
```
|
|
46
45
|
|
|
46
|
+
上記では省きましたが，実際には ClusterIP サービスを立てて app-master が app-worker から見えるようになっています。
|
|
47
|
+
|
|
48
|
+
app-worker はパラメータとして app-master のホストやポートを渡され，
|
|
49
|
+
app-worker は起動時に app-master との接続を確立するようになっています。
|
|
50
|
+
|
|
51
|
+
|
|
52
|
+
# 問題点
|
|
53
|
+
|
|
47
|
-
残念ながらアプリケーションの実装が
|
|
54
|
+
残念ながらアプリケーションの実装があまり良くなく，app-worker が app-master と接続を確立した後に app-master が落ちても，
|
|
48
55
|
app-worker はそれを検知できずにプロセスは残り続けます。
|
|
49
56
|
|
|
50
57
|
結果，Kubernetes は app-master が落ちたことを検知して Pod を新しく作成してくれますが，
|
1
title
CHANGED
|
File without changes
|
body
CHANGED
|
@@ -4,6 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
Deployment が 2 つ定義されており，`app-master` ではマスターアプリケーションを 1 Pod だけ，
|
|
6
6
|
`app-worker` ではマスターに依存しているワーカーアプリケションを複数 Pod 作成しています。
|
|
7
|
+
（以下では，ホストやポートの指定等の，実際の細かい設定は省いています。）
|
|
7
8
|
|
|
8
9
|
```lang-yaml
|
|
9
10
|
apiVersion: apps/v1
|
|
@@ -47,14 +48,15 @@
|
|
|
47
48
|
app-worker はそれを検知できずにプロセスは残り続けます。
|
|
48
49
|
|
|
49
50
|
結果，Kubernetes は app-master が落ちたことを検知して Pod を新しく作成してくれますが，
|
|
50
|
-
app-worker はプロセスが落ちないまま残り続け
|
|
51
|
+
app-worker はプロセスが落ちないまま残り続け，古い app-master を参照し続けます。
|
|
52
|
+
このため新しい app-master とのコネクションが貼られません。
|
|
51
53
|
|
|
52
54
|
従って，現状 app-master が落ちた場合は，マニフェスト全体を手動で `kubectl delete` & `kubectl apply` する必要がある状態となっています。
|
|
53
55
|
|
|
54
56
|
|
|
55
57
|
# やりたいこと
|
|
56
58
|
|
|
57
|
-
app-master が落ちた場合の復帰も自動化させたいです。
|
|
59
|
+
app-master が落ちた場合の復帰も意図通りに自動化させたいです。
|
|
58
60
|
|
|
59
61
|
アプリケーションの実装を見直すのも手ですが，時間もないためアプリケーション側の変更はしたくありません。
|
|
60
62
|
|