質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.48%

Q&A

解決済

2回答

4108閲覧

Kubernetes である Pod が再起動した際,依存する他の Pod も再起動させたい

h-matsuo

総合スコア11

0グッド

0クリップ

投稿2019/01/30 09:34

編集2019/01/30 12:29

現状

以下のマニフェストで表されるようなシステムの構築を考えます。

Deployment が 2 つ定義されており,app-master ではマスターアプリケーションを 1 Pod だけ,
app-worker ではマスターに依存しているワーカーアプリケションを複数 Pod 作成しています。

lang

1apiVersion: apps/v1 2kind: Deployment 3metadata: 4 name: app-master 5spec: 6 replicas: 1 7 selector: 8 matchLabels: 9 app: app-master 10 template: 11 metadata: 12 labels: 13 app: app-master 14 spec: 15 containers: 16 - name: app-master-container 17 image: (略) 18--- 19apiVersion: apps/v1 20kind: Deployment 21metadata: 22 name: app-worker 23spec: 24 replicas: 5 25 selector: 26 matchLabels: 27 app: app-worker 28 template: 29 metadata: 30 labels: 31 app: app-worker 32 spec: 33 containers: 34 - name: app-worker-container 35 image: (略)

上記では省きましたが,実際には ClusterIP サービスを立てて app-master が app-worker から見えるようになっています。

app-worker はパラメータとして app-master のホストやポートを渡され,
app-worker は起動時に app-master との接続を確立するようになっています。

問題点

残念ながらアプリケーションの実装があまり良くなく,app-worker が app-master と接続を確立した後に app-master が落ちても,
app-worker はそれを検知できずにプロセスは残り続けます。

結果,Kubernetes は app-master が落ちたことを検知して Pod を新しく作成してくれますが,
app-worker はプロセスが落ちないまま残り続け,古い app-master を参照し続けます。
このため新しい app-master とのコネクションが貼られません。

従って,現状 app-master が落ちた場合は,マニフェスト全体を手動で kubectl delete & kubectl apply する必要がある状態となっています。

やりたいこと

app-master が落ちた場合の復帰も意図通りに自動化させたいです。

アプリケーションの実装を見直すのも手ですが,時間もないためアプリケーション側の変更はしたくありません。

従って,Kubernetes が app-master のクラッシュを検知して再起動させるときは,
一緒に app-worker の全 Pod も再起動させて欲しいのです。

マニフェストに Pod の依存関係のようなものが書ければ良いのですが……
何か方法はありますでしょうか。

宜しくお願いします。

バージョン

lang

1$ kubectl version 2Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.2", GitCommit:"cff46ab41ff0bb44d8584413b598ad8360ec1def", GitTreeState:"clean", BuildDate:"2019-01-10T23:35:51Z", GoVersion:"go1.11.4", Compiler:"gc", Platform:"linux/amd64"} 3Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.2", GitCommit:"cff46ab41ff0bb44d8584413b598ad8360ec1def", GitTreeState:"clean", BuildDate:"2019-01-10T23:28:14Z", GoVersion:"go1.11.4", Compiler:"gc", Platform:"linux/amd64"}

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答2

0

ベストアンサー

Kubernetesを結構触ってるのですが、その構成だとKubernetesを使うのはおすすめしません。
マイクロサービス化も出来ていなさそうなので。。。
またインフラ屋としてはアプリケーションの実装を変更しろ!と言いたくなります。。。笑

解決策としては、app-masterが復帰した際に、app-masterPodがKubernetesAPIを叩いて、app-workerを再起動する。

参考サイトとしていくつか上げておきます。
APIDocument
UseCase

投稿2019/02/03 16:12

編集2019/02/03 16:13
DaichiYasuda

総合スコア173

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

h-matsuo

2019/02/04 03:28

なるほど Pod 内から API を叩けるのですね。 いただいたリンク先を参考に色々試してみます,ご回答ありがとうございました。
guest

0

応急処置として以下のようなスクリプトを作成して運用しています:

  1. kubectl get pods で app-master の RESTARTS 回数を監視
  2. RESTARTS が 1 以上になっていれば app-master がクラッシュ・再起動したと判断
  3. kubectl delete および kubectl delete を実行,1 に戻る

投稿2019/02/04 03:31

h-matsuo

総合スコア11

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.48%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問