質問編集履歴

2

2019/01/30 12:29

投稿

h-matsuo
h-matsuo

スコア11

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
- 残念ながらアプリケーションの実装がく,app-worker が app-master と接続を確立した後に app-master が落ちても,
107
+ 残念ながらアプリケーションの実装があまり良なく,app-worker が app-master と接続を確立した後に app-master が落ちても,
94
108
 
95
109
  app-worker はそれを検知できずにプロセスは残り続けます。
96
110
 

1

2019/01/30 12:29

投稿

h-matsuo
h-matsuo

スコア11

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 はプロセスが落ちないまま残り続けるため新しい app-master とのコネクションが貼られせん
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