質問編集履歴
2
test
CHANGED
File without changes
|
test
CHANGED
@@ -9,8 +9,6 @@
|
|
9
9
|
Deployment が 2 つ定義されており,`app-master` ではマスターアプリケーションを 1 Pod だけ,
|
10
10
|
|
11
11
|
`app-worker` ではマスターに依存しているワーカーアプリケションを複数 Pod 作成しています。
|
12
|
-
|
13
|
-
(以下では,ホストやポートの指定等の,実際の細かい設定は省いています。)
|
14
12
|
|
15
13
|
|
16
14
|
|
@@ -90,7 +88,23 @@
|
|
90
88
|
|
91
89
|
|
92
90
|
|
91
|
+
上記では省きましたが,実際には ClusterIP サービスを立てて app-master が app-worker から見えるようになっています。
|
92
|
+
|
93
|
+
|
94
|
+
|
95
|
+
app-worker はパラメータとして app-master のホストやポートを渡され,
|
96
|
+
|
97
|
+
app-worker は起動時に app-master との接続を確立するようになっています。
|
98
|
+
|
99
|
+
|
100
|
+
|
101
|
+
|
102
|
+
|
103
|
+
# 問題点
|
104
|
+
|
105
|
+
|
106
|
+
|
93
|
-
残念ながらアプリケーションの実装が
|
107
|
+
残念ながらアプリケーションの実装があまり良くなく,app-worker が app-master と接続を確立した後に app-master が落ちても,
|
94
108
|
|
95
109
|
app-worker はそれを検知できずにプロセスは残り続けます。
|
96
110
|
|
1
test
CHANGED
File without changes
|
test
CHANGED
@@ -9,6 +9,8 @@
|
|
9
9
|
Deployment が 2 つ定義されており,`app-master` ではマスターアプリケーションを 1 Pod だけ,
|
10
10
|
|
11
11
|
`app-worker` ではマスターに依存しているワーカーアプリケションを複数 Pod 作成しています。
|
12
|
+
|
13
|
+
(以下では,ホストやポートの指定等の,実際の細かい設定は省いています。)
|
12
14
|
|
13
15
|
|
14
16
|
|
@@ -96,7 +98,9 @@
|
|
96
98
|
|
97
99
|
結果,Kubernetes は app-master が落ちたことを検知して Pod を新しく作成してくれますが,
|
98
100
|
|
99
|
-
app-worker はプロセスが落ちないまま残り続け
|
101
|
+
app-worker はプロセスが落ちないまま残り続け,古い app-master を参照し続けます。
|
102
|
+
|
103
|
+
このため新しい app-master とのコネクションが貼られません。
|
100
104
|
|
101
105
|
|
102
106
|
|
@@ -110,7 +114,7 @@
|
|
110
114
|
|
111
115
|
|
112
116
|
|
113
|
-
app-master が落ちた場合の復帰も自動化させたいです。
|
117
|
+
app-master が落ちた場合の復帰も意図通りに自動化させたいです。
|
114
118
|
|
115
119
|
|
116
120
|
|