複数のコンテナを持つジョブは成功しません

Question

私はGKEクラスタでKubernetesを実行しており、すべてのデプロイ時にDB移行スクリプトを実行する必要があります。ステージングは​​簡単です：私たちは独自のボリュームを持つ永続的な別個のMySQLサービスを持っています。しかし、プロダクションではGCE SQLを使用して、2つのコンテナを持つジョブを作成します.1つは移行用、もう1つはCloud Proxy用です。

この新しいコンテナのため、kubectl describe jobs/migrationを実行するとジョブは常に1アクティブとして表示され、完全に失われています。私はコンテナを再注文して、デフォルトでチェックするかどうかを確認しようとしましたが、違いはなく、a）コンテナを殺すか、b）ジョブ内のただ1つのコンテナのステータスをチェックする方法がありません。

アイデア？

Answer 1

各ポッドはinit containerで設定できます。これは問題に適しているようです。したがって、永続的に実行する必要のある2つのコンテナを持つPodを持つ代わりに、移行を先取りするためのinitコンテナを定義することができます。例えば。

apiVersion: v1 
kind: Pod 
metadata: 
    name: init-container 
    annotations: 
    pod.beta.kubernetes.io/init-containers: '[ 
     { 
      "name": "migrate", 
      "image": "application:version", 
      "command": ["migrate up"], 
     } 
    ]' 
spec: 
    containers: 
    - name: application 
    image: application:version 
    ports: 
    - containerPort: 80 

Answer 2

あなたの特定の問題について十分な詳細を掲載していません。しかし、私は経験に基づいて推測しています。

TL; DR：独立している場合は、コンテナを別々のジョブに移動します。

-

Kubernetesジョブは、ジョブが成功するまで、再起動しておきます。 kubernetesジョブは、成功したすべてのコンテナが成功した場合にのみ成功します。

これは、コンテナが再開証明の方法で返却されることを意味します。コンテナが正常に実行されると、コンテナが再び実行されても成功するはずです。それ以外の場合、container1は成功し、container2は失敗します。ジョブが再開されます。それから、container1は失敗します（すでに成功しているため）。したがって、ジョブは再開し続けます。

Answer 3

私はそれが1年遅れていることを知っていますが、すべてのアプリケーションのために単一のcloudsqlプロキシサービスを実行し、このサービスをDBホスト名として使用するためにアプリケーションのイメージにDBアクセスを設定することがベストプラクティスです。

この方法では、DBを使用するすべてのポッドにcloudsqlプロキシコンテナを置く必要はありません。