Kubernetes: バッチジョブでのサイドカーコンテナのサポートの向上

/サブ

また、ここで提案されているように活気の問題を使用すると、ポッドが失敗したと見なされ、ジョブ全体が成功したと見なされないため、 http：//stackoverflow.com/questions/36208211/sidecar-containers-in-kubernetes-jobsは機能しません。

ポッドが0を返すのを待つのではなく、ジョブが成功を検出するためにプローブできるように、ジョブ成功プローブを宣言してはどうでしょうか。
プローブが成功を返すと、ポッドを終了できます。

すでに存在しているコンテナに対してプローブを実行できますか、または存在します
それが取り壊されているレースになりますか？

別のオプションは、特定の終了コードを特別な意味を持つものとして指定することです。

「ポッド全体の成功」または「ポッド全体の失敗」は両方とも
使える。

これはPodオブジェクト上にある必要があるため、APIの大きな変更になります。

13:41の木、2016年9月22日には、明牙[email protected]は書きました：

Jobがプローブできるように、ジョブ成功プローブを宣言してはどうでしょうか。
ポッドが0を返すのを待つのではなく、成功を検出します。

プローブが成功を返すと、ポッドを終了できます。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/25908#issuecomment -249021627、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AHuudjrpVtef6U35RWRlZr3mDKcCRo7oks5qsugRgaJpZM4IiqQH
。

@erictune良い点; 終了したコンテナをプローブすることはできません。

ポッド内の特定のコンテナーを「完了」コンテナーとして指定して、そのコンテナーが終了したときにジョブが完了したと言えるようにすることはできますか？

サイドカーコンテナは、丸太の輸送や監視などのために長持ちする傾向があります。
ジョブが完了したら、それらを強制的に終了できます。

ポッド内の特定のコンテナーを「完了」コンテナーとして指定して、そのコンテナーが終了したときにジョブが完了したと言えるようにすることはできますか？

このドキュメントポイント3を調べましたか？ここで詳細に説明され.spec.completionsを設定せず、最初のコンテナが0の終了コードで終了するとすぐにジョブが完了します。

サイドカーコンテナは、丸太の輸送や監視などのために長持ちする傾向があります。
ジョブが完了したら、それらを強制的に終了できます。

個人的には、これらは仕事というよりはRSのように見えますが、それは私の個人的な意見であり、最も重要なことに、私はあなたの設定の完全な詳細を知りません。

一般的に、このトピックにも触れている次のディスカッションhttps://github.com/kubernetes/kubernetes/issues/17244およびhttps://github.com/kubernetes/kubernetes/issues/30243があり

@soltysh上記で送信したリンク、ポイント3は、コンテナーの完了ではなく、ポッドの完了を参照しています。

2つのコンテナはemptyDirを共有でき、最初のコンテナは「I'm exiting now」メッセージをファイルに書き込み、もう1つのコンテナはそのメッセージを確認したときに終了できます。

@erictune私はこのバケツに該当すると思うユースケースを持っています。この問題を解決するための公式の推奨方法がないように思われるので、正しい方向に私を導いてくれることを願っています。

私はclient-goライブラリを使用して以下のすべてをコーディングしています：

つまり、基本的に1つのコンテナポッドでツールを実行する仕事があります。 ツールの実行が終了するとすぐに、結果ファイルが生成されることになっています。 ツールの実行が終了するとすぐにポッドが削除され、結果ファイルが失われるため、この結果ファイルをキャプチャできないようです。

HostPathをVolumeSourceとして使用した場合、この結果ファイルをキャプチャできました。minikubeをローカルで実行しているため、結果ファイルはワークステーションに保存されます。

しかし、それは推奨されておらず、本番コンテナには理想的ではないことを理解しています。 したがって、上記のようにEmptyDirを使用しました。 しかし、繰り返しになりますが、ポッド自体で削除されるため、実際にキャプチャすることはできません。

それで、サイドカーコンテナパターンも使用して問題を解決する必要がありますか？

基本的に、上記で提案したことを実行します。 ジョブが開始するたびに、ポッドで2つのコンテナーを開始します。 1つのコンテナがジョブを実行し、ジョブが完了するとすぐに、他のコンテナによって取得されるメッセージをドロップします。このメッセージは、結果ファイルを取得してどこかに保存しますか？

そもそもなぜ2つのコンテナが必要なのか理解できません。 なぜジョブコンテナはこれをすべて単独で実行できないのですか？ つまり、ジョブを終了し、結果ファイルをどこかに保存し、それにアクセス/読み取り、どこかに保存します。

@anshumanbh私はあなたに提案します：

1. 永続ストレージを使用して、結果ファイルを保存します
2. hostPathマウントを使用します。これは1とほぼ同じで、すでに試しています
3. 結果ファイルを既知のリモートロケーション（s3、googleドライブ、ドロップボックス）、通常はあらゆる種類の共有ドライブにアップロードします

@soltyshファイルを永続的に保存したくありません。 実行するたびに、その結​​果を最後の結果と比較したいだけです。 したがって、これを行うことを考えていた方法は、実行のたびにgithubリポジトリにコミットしてから、差分を実行して何が変更されたかを確認することでした。 そのためには、結果を一時的にどこかに保存して、Githubに送信できるようにする必要があります。 わかる？

@anshumanbhは完全に明確ですが、それでも

@soltyshですから、上記のリストからオプション3を選択したいのであれば、どのように実装すればよいでしょうか。

私が直面している問題は、ジョブが終了するとすぐにコンテナーが終了し、ファイルが失われることです。 ファイルがない場合、S3 / Googleドライブ/ドロップボックスなどの共有ドライブにファイルをアップロードするにはどうすればよいですか？ ジョブのコードを変更して、終了する前に自動的にどこかにアップロードすることはできないため、残念ながら、最初にジョブを実行してから、ファイルをどこかに保存する必要があります。

ジョブのコードを変更できない場合は、ファイルをアップロードできるようにコードをラップする必要があります。 作業しているのが画像である場合は、コピーコードで画像を拡張するだけです。

@soltyshはい、それは理にかなっています。 私はそれをすることができました。 ただし、次の質問は、複数のジョブを実行する必要があり（さまざまなツールを実行していると考えてください）、これらのツールのいずれにもアップロード部分が組み込まれていないとします。 それで、今、私はそのラッパーを構築し、アップロード部分でそれらのツールのそれぞれを拡張する必要があります。 ラッパー/拡張機能を一度作成して、すべてのツールで使用できる方法はありますか？

その場合、サイドカーのパターンは合いませんか？

ええ、できます。 同じポッド内に複数のコンテナを入れてみますが、パターン化してください。 わあ。 ポッドはジョブコンテナを実行しており、追加のコンテナと一緒に出力を待機してアップロードしています。 これがどれほど実行可能かはわかりませんが、すでに試してみることができます。

穏やかなping-サイドカーの認識により、Envoyなどのマイクロサービスプロキシの管理がはるかに快適になります。 共有する進歩はありますか？

現在の状況では、各コンテナにはライフタイムを調整するためのバンドルされたツールが必要です。つまり、アップストリームのコンテナイメージを直接使用することはできません。 また、追加のargvとマウントポイントを挿入する必要があるため、テンプレートが大幅に複雑になります。

以前の提案は、一部のコンテナーを「完了」コンテナーとして指定することでした。 反対のことを提案したいと思います-いくつかのコンテナを「サイドカー」として指定する機能。 ポッド内の最後の非サイドカーコンテナが終了すると、ポッドはサイドカーにTERMを送信する必要があります。 これは、PythonのThread.daemon 、多くのスレッドライブラリに見られる「バックグラウンドスレッド」の概念に類似しています。

設定例、コンテナmain終了すると、kubeletはenvoy強制終了します：

containers:
  - name: main
    image: gcr.io/some/image:latest
    command: ["/my-batch-job/bin/main", "--config=/config/my-job-config.yaml"]
  - name: envoy
    image: lyft/envoy:latest
    sidecar: true
    command: ["/usr/local/bin/envoy", "--config-path=/my-batch-job/etc/envoy.json"]

参考までに、これが私が望ましいサイドカーの振る舞いをシミュレートするために使用しているバッシュマッドネスです：

containers:
  - name: main
    image: gcr.io/some/image:latest
    command: ["/bin/bash", "-c"]
    args:
      - |
        trap "touch /tmp/pod/main-terminated" EXIT
        /my-batch-job/bin/main --config=/config/my-job-config.yaml
    volumeMounts:
      - mountPath: /tmp/pod
        name: tmp-pod
  - name: envoy
    image: gcr.io/our-envoy-plus-bash-image:latest
    command: ["/bin/bash", "-c"]
    args:
      - |
        /usr/local/bin/envoy --config-path=/my-batch-job/etc/envoy.json &
        CHILD_PID=$!
        (while true; do if [[ -f "/tmp/pod/main-terminated" ]]; then kill $CHILD_PID; fi; sleep 1; done) &
        wait $CHILD_PID
        if [[ -f "/tmp/pod/main-terminated" ]]; then exit 0; fi
    volumeMounts:
      - mountPath: /tmp/pod
        name: tmp-pod
        readOnly: true
volumes:
  - name: tmp-pod
    emptyDir: {}

反対のことを提案したいと思います-いくつかのコンテナを「サイドカー」として指定する機能。 ポッド内の最後の非サイドカーコンテナが終了すると、ポッドはTERMをサイドカーに送信する必要があります。

@ jmillikin-stripe私はこのアイデアが好きですが、これがポッド内でいくつかのコンテナーを異なる方法で処理するか、それらの間に依存関係を導入するという原則に従っているのかどうかはわかりません。 最後の呼び出しは@erictuneに任せます。

＃17244を確認しましたが、このタイプのソリューションはユースケースに適合しますか？ これは@erictuneが前にいくつかのコメントに言及したものです：

別のオプションは、特定の終了コードを特別な意味を持つものとして指定することです。

@ jmillikin-stripe私はこのアイデアが好きですが、これがポッド内でいくつかのコンテナーを異なる方法で処理するか、それらの間に依存関係を導入するという原則に従っているのかどうかはわかりません。 最後の呼び出しは@erictuneに任せます。

Kubernetesは、コンテナを異なる方法で処理しないという原則について柔軟である必要があると思います。 私たち（Stripe）は、Envoyなどのサードパーティコードを改造してLampreyスタイルのライフサイクルフックを持たせたくありません。Envelopeスタイルのexec反転を採用しようとすると、Kubeletに特定のサイドカーを終了させるよりもはるかに複雑になります。

＃17244を確認しましたが、このタイプのソリューションはユースケースに適合しますか？ これは@erictuneが前にいくつかのコメントに言及したもの

別のオプションは、特定の終了コードを特別な意味を持つものとして指定することです。

私は、KubernetesまたはKubeletが「ゼロまたは非ゼロ」よりも細かい粒度でエラーコードを解釈することに非常に強く反対しています。 Borgletによる終了コードのマジックナンバーの使用は不快な機能ミスであり、特定のコンテナイメージが異なるポッドの「メイン」または「サイドカー」である可能性があるKubernetesではさらに悪化します。

たぶん、これを解決するには追加のライフサイクルフックで十分でしょうか？

になり得る：

• PostStop：ポッド内の他のコンテナーでライフサイクルイベントをトリガーする手段を使用します（つまり、トリガー停止）
• PeerStopped：ポッド内の「ピア」コンテナが停止したことを通知します-おそらく引数として終了コードを使用します

これは、コンテナを再起動するカスタムポリシーを定義する手段を定義することもできます。または、デフォルトで起動されていないコンテナを起動して、コンテナのデイジーチェーン接続を可能にすることもできます（コンテナが終了したら、コンテナbを起動します）。

これもありません。 接続のためにVPNクライアントを必要とするジョブを30分ごとに実行しますが、これが非常に役立つ可能性のあるユースケースがたくさんあるようです（たとえば、kubectlプロキシが必要なもの）。 現在、回避策としてjobSpec.concurrencyPolicy: Replaceしていますが、もちろんこれは、a。）並列ジョブの実行なしで生きることができ、b。）ジョブの実行時間がスケジュール間隔よりも短い場合にのみ機能します。

編集：私のユースケースでは、コンテナを終了ステータスとしてマークし、そのコンテナの終了ステータスを監視して残りのコンテナを強制終了するために、ジョブ仕様にいくつかのプロパティを含めるだけで十分です。

私もこれが必要です。 私たちの場合、それはサイドカーサービスとしてcloudsql-proxyコンテナを利用する仕事です。

ポッド内の「プライマリ」コンテナの名前にマップするアノテーションを追加するのはどうでしょうか。 そうすれば、ポッドの仕様を変更する必要はありません。

ポッドの設計方法の性質上、これは非常に一般的なユースケースのようです。 @soltysh @erictuneこれにすぐに取り組む予定はありますか？ 可能な限り助けてくれてうれしい:)

この機能も必要です。 私たちのユースケースの場合：
ポッドAはコンテナにする必要があります

• コンテナーA1 ：ログをファイルに出力する実行から完了までのコンテナー
• コンテナA2 ：サイドカーコンテナ。ファイルからstdoutにログを追跡するだけです。

私が欲しいもの：コンテナA1が成功して完了すると、ポッドAは成功して完了します。 コンテナA1にメインコンテナのラベルを付けることはできますか？メインコンテナが終了すると、ポッドが終了しますか？ @erictune （このアイデアは@mingfangによっても説明されてい

やあみんな、この問題は1か月間開いているようです。 これに関する最新情報は何ですか？ ジョブを実行したいユースケースがあります。 このジョブは、いくつかのサイドカーcontainers含むmainコンテナーを実行します。 mainコンテナが終了したときにジョブを終了する必要があります。 コンテナ間でsignalを送信するためにfileを共有するのは最先端ですか？

私はこれについていくつかの作業を開始してもかまいません。私がそうする場合（おそらくkubeconの後で）誰かが今後のPRをレビューできるかどうか知りたいです。

cc @erictune @ a-robinson @soltysh

@andrewsykimどのようなアプローチを取りますか。 また、ここに追加していることはわかっています。依存関係のサポートを追加するには何が必要ですか。 mainコンテナのように、サイドカーが初期化されるまで開始しないでください

メインコンテナのように、サイドカーが初期化されるまで起動しないでください

mainはサイドカーが初期化されたときにチェックできるはずなので（またはレディネスプローブを使用して）、このケースは問題ではないと思います。 これはこの問題には当てはまりません。 mainが終了していたからです:)

結局、kubernetes APIを監視し、一致するアノテーションを使用してジョブを終了し、メインコンテナが終了した単純なスクリプトを作成しました。 完璧ではありませんが、コアのニーズに対応します。 興味のある方はシェアできます。

@ajbouhそれを要点として共有していただければ、個人的に感謝します。 私は似たようなものを書き込もうとしていました

@nrmitchiこれが私が書いたyamlの要点です。 これは非常にシェルスクリプトですが、使用するAPIと機能するものを取得する方法の点で、おそらくそれはあなたにとって良い出発点です。 ご不明な点がございましたら、何をしているかについての質問にお答えします。

https://gist.github.com/ajbouh/79b3eb4833aa7b068de640c19060d126

@mrbobbytablesと同じCloudSQLプロキシのユースケースがあります。 クラウドSQLに安全に接続するには、プロキシを使用することをお勧めしますが、そのプロキシはジョブの完了時に終了しないため、次のようなクレイジーなハッキングや監視が発生します。 これに進む道はありますか？

@ amaxwell01これへのクラウドSQLプロキシの関与に関して、私はあなたがスターを付けたり更新を監視したりできる問題をグーグルで開きました： https ：

ありがとう@abevoelker私はそこであなたの投稿をフォローしています。 さらに、あなたのコメントは私を笑わせました👍

この問題の影響も受けています。
マイクロサービスには、k8s cronjobで実行できるいくつかのdjango管理コマンドがありますが、ジョブの完了時に停止しないcloudsqlproxyサイドカーが原因で成功しません。
いつ解決策が得られるかについての最新情報はありますか？
サイドカーコンテナパターンはますます使用されており、これが解決されるまで、多くの人がk8scronジョブとジョブを使用できなくなります。

これのために私の+1を投入したかっただけです。 私は他のみんなと同じGCEクラウドSQLプロキシの問題を抱えています。 それは私を殺しています... helmのデプロイが失敗し、それが私のテラフォームの適用に失敗します。

これについて何らかの解決策を本当に見たいと思います... @ ajbouhのjistはうまくいくように見えます...しかし、うわあ、それはハッキーです。

cloudsql-proxy必要とする他の人にとって、 cloudsql-proxyをDaemonSetとして実行するのはあなたのユースケースに合うでしょうか？ 私の場合、永続的なデプロイメントとプロキシを必要とするCronJobの両方があったため、プロキシを個々のポッドから切り離し、代わりにノードごとに1つのインスタンスをアタッチするのが理にかなっています。

はい、

cloudsqlプロキシサイドカーを削除し、のプールを構築することにしました
中央の名前空間にあるcloudsqlプロキシは、完全に機能し、
スケーラビリティとより簡単な展開を移動します。
これで、問題なくジョブとcronジョブを実行できます。

9:37の水、2018年2月7日には、ロブ・ジャクソン[email protected]
書きました：

cloudsql-proxyを必要とする他の人にとって、それはあなたのユースケースに合うでしょうか？
cloudsql-proxyをDaemonSetとして実行しますか？ 私の場合、私は両方とも永続的でした
デプロイメントとプロキシを必要とするCronJobなので、デタッチするのは理にかなっています
個々のポッドから取得し、代わりにノードごとに1つのインスタンスをアタッチします。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/25908#issuecomment-363710890 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ACAWMwetx6gA_SrHL_RRbTMJVOhW1FKLks5tSW7JgaJpZM4IiqQH
。

興味深いことに、デーモンセットを使用することは良い選択肢のように思えます。 daemonsetsを使用した場合、クラウドSQLプロキシ仕事の発見をどうするか- RJacksonm1＆@devlounge @？

それがトリックをするように見えるこれを見つけました...
https://buoyant.io/2016/10/14/a-service-mesh-for-kubernetes-part-ii-pods-are-great-until-theyre-not/

基本的に、ホストIPを取得するために次のようなものを使用する必要があります。

env:
- name: NODE_NAME
  valueFrom:
    fieldRef:
      fieldPath: spec.nodeName

@ RJacksonm1- hostPort機能させるために何か特別なことをしましたか？ fieldPath: spec.nodeNameアプローチと組み合わせて使用​​すると、常にconnection refusedを取得します🤔

編集： spec.nodeNameが正しく通過し、GKE v1.9.2-gke.1

@cvallance DaemonSetを公​​開するようにサービスを設定しました。これにより、アプリケーションはDNS経由でアクセスできます。 これは、アプリケーションがそれ自体と同じホストで実行されているcloudsql-proxyインスタンスと通信することを保証するものではありませんが、 cloudsql-proxyがクラスター全体に合わせて拡張されることを保証します（元々はDeploymentおよびHorizo​​ntalPodAutoscalerとしてプロキシしますが、スケールアップ/スケールダウンが多すぎることがわかりました。アプリでMySQL has gone awayエラーが発生します）。 これはDaemonSetの真の精神ではないと思います...🤔

@ RJacksonm1 - hostPortとspec.nodeName動作するようになりました...これで、ノードのDaemonSetに直接接続します😄

CloudSqlプロキシコマンドが機能しない：
-instances={{ .Values.sqlConnectionName }}=tcp:{{ .Values.internalPort }}
働く：
-instances={{ .Values.sqlConnectionName }}=tcp:0.0.0.0:{{ .Values.internalPort }}

🤦‍♂️

この問題についての牽引力を得るために私たちにできることはありますか？
ほぼ2年間オープンしていますが、まだ回避策しかありません

自分でこれを実装しようとしても、実装するソリューションやAPIの変更などについては、社内の人からの承認が必要なため、実行できないのではないかと思います。

これを成し遂げるために私にできることはありますか？

参考までに、共有ボリューム内のファイルが状態をサイドカーに伝達する@ jmillikin-stripeの回避策のcloud-sql-proxyサイドカーバージョンを作成しました。

それは問題なく動作しますが、私のK8s構成で最も厄介なハックです:(

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  template:
    spec:
      containers:
      - name: example-job
        image: eu.gcr.io/example/example-job:latest
        command: ["/bin/sh", "-c"]
        args:
          - |
            trap "touch /tmp/pod/main-terminated" EXIT
            run-job.sh
        volumeMounts:
          - mountPath: /tmp/pod
            name: tmp-pod
      - name: cloudsql-proxy
        image: gcr.io/cloudsql-docker/gce-proxy:1.11
        command: ["/bin/sh", "-c"]
        args:
          - |
            /cloud_sql_proxy --dir=/cloudsql -instances=example:europe-west3:example=tcp:3306 -credential_file=/secrets/cloudsql/credentials.json &
            CHILD_PID=$!
            (while true; do if [[ -f "/tmp/pod/main-terminated" ]]; then kill $CHILD_PID; echo "Killed $CHILD_PID as the main container terminated."; fi; sleep 1; done) &
            wait $CHILD_PID
            if [[ -f "/tmp/pod/main-terminated" ]]; then exit 0; echo "Job completed. Exiting..."; fi
        volumeMounts:
          - name: cloudsql-instance-credentials
            mountPath: /secrets/cloudsql
            readOnly: true
          - name: cloudsql
            mountPath: /cloudsql
          - mountPath: /tmp/pod
            name: tmp-pod
            readOnly: true
      restartPolicy: Never
      volumes:
        - name: cloudsql-instance-credentials
          secret:
            secretName: cloudsql-instance-credentials
        - name: cloudsql
          emptyDir:
        - name: tmp-pod
          emptyDir: {}
  backoffLimit: 1

プロジェクトの内部の誰かがこの問題の進捗状況についてコメントできますか？

ここで同じ問題

cc @ kubernetes / sig-apps-feature-requests @ kubernetes / sig-node-feature-requests

次のように、ジョブポッドを完了（他のコンテナを停止した状態）としてマークするために、ユーザーがジョブ内のコンテナを（名前で）正常に完了したいと指定できるようにすることは理にかなっていますか？

apiVersion: batch/v2beta1
kind: Job
metadata:
  name: my-job
  namespace: app
spec:
  template:
    spec:
      containers:
        - name: my-container
          image: my-job-image
          ...
        - name: cloudsql-proxy
          image: gcr.io/cloudsql-docker/gce-proxy:1.11
          ...
  backoffLimit: 2
  jobCompletedWith:
    - my-container

すなわちポッドまで、待機を実行しますmy-container成功裏に終了し、その後、ちょうど終了cloudsql-proxy 。

編集：このスレッドを上にスクロールすると、これが以前に提案されていることがわかります。 @erictuneまたは他の誰かが、なぜこれが機能しないのかについて詳しく説明できますか？

はい、それは完璧だと思います。 ジョブのステータスを監視し、完了したらパイプラインを続行できるものです。

ええ、それは完璧でしょう。

私はこのアイデアが好きです@jpalomaki

純粋にジョブコントローラ内でこれを解決するアプローチに関して私が抱えている懸念の1つは、ジョブが終了した後もポッドが実行され続けることです。 現在、ポッドは終了フェーズに入り、ノードはそれらのリソースを解放できます。

コントローラーが完了したと判断したときにジョブコントローラーにポッドを削除させることもできますが、これは、終了したポッドレコードが（ノードリソースを使用せずに）APIサーバーにとどまる現在の動作とも異なります。

これらの理由から、ポッドAPIレベルでこれに対処する方が、仮にあったとしても、私にはわかりやすいようです。 気になる「完了」コンテナはすでに終了しているため、ノードは個々のコンテナに到達して強制終了する必要がある唯一のものです。 これは、待機するコンテナーの概念を指定できるポッドレベルのAPI、または外部エージェント（ジョブコントローラーなど）が実際に削除せずにポッドを強制的に終了できるようにするポッドレベルのAPIのいずれかの形式をとることができます。ポッド。

また、プロセッサコンテナが正常に終了した場合に、コンテナによって生成されたファイルをアップロードするためのソリューションも探しています。

サイドカーコンテナにk8sAPIを介してコンテナのステータスを監視させ、アップロードまたは終了を開始するかどうか、いつ開始するかを知ることに対して行われた@mingfangの主張を理解できません。 サイドカーコンテナがポッドを出ると、ジョブは正常に終了するはずです。

別の考えは、ハックのように見えますが、データ生成コンテナーをinitコンテナーにし、データアップロードコンテナー（サイドカーコンテナーである必要はなくなります）を作成することがどれほど悪いかを知りたいです。 ）プロセッサコンテナが正常に終了した後にのみ自動的に開始されます。 私の場合、処理コンテナにデータを提供するために、最初のinitコンテナとしてデータダウンローダーコンテナも必要になります。これが特に悪い考えである場合は、その理由を知りたいと思います。

サイドカーをファーストクラスのk8sコンセプトに昇格させれば、この問題は解決しませんか？ Kubeletは、ポッド内で実行中のすべてのコンテナーがサイドカーのコンテナーとしてマークされている場合、ポッドを終了できます。

FWIW、私はCloud SQLプロキシを通常のデプロイ（ replicas: 1 ）としてデプロイすることでこれを回避し、 JobとCronJob type: ClusterIP介して使用させました。サービス。 これでジョブは正常に完了します。

私はこれに関する公式の立場が欲しいです。

APIからのサポートがない場合は、少なくとも、この問題が発生したときに人々が何をすべきかを理解できるように、代替ソリューションを公式に文書化する必要があります。

誰にpingを送信するのか、これに注意を向ける方法がわかりません...

これに対処するのは本当に素晴らしいことです。 ジョブがなくなることはないことに加えて、全体的なポッドステータスは明らかに正しくありません。

Init Containers:
  initializer:
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Wed, 21 Mar 2018 17:52:57 -0500
      Finished:     Wed, 21 Mar 2018 17:52:57 -0500
    Ready:          True
Containers:
  sideCar:
    State:          Running
      Started:      Wed, 21 Mar 2018 17:53:40 -0500
    Ready:          True
  mainContainer:
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Wed, 21 Mar 2018 17:53:41 -0500
      Finished:     Wed, 21 Mar 2018 17:55:12 -0500
    Ready:          False
Conditions:
  Type           Status
  Initialized    True 
  Ready          False 
  PodScheduled   True 

興味深いのは、initContainer（Terminated、Completed、Ready = True）とメインアプリコンテナー（Terminated、Completed、Ready = False）の状態と準備完了です。 それがFalseのオーバーポッドレディ状態を引き起こしているようです-私の見解では、間違っています。 これにより、このポッドにダッシュボードに問題があるとしてフラグが立てられます。

特にCloudSQLプロキシでこの問題が発生している別のお客様がいます。 cronジョブがCloudSQLにアクセスできるようにするために、永続的なサービスとして実行する必要はありません。

@yuriatgoogle最も簡単な解決策はまだbashとemptyDirの「魔法」です： https ：

それはハックですが、やらなければなりません。 @phidahを意図した攻撃はありません。

さまざまな理由で、多くの人がこれを望んでいるようです。 公式のサポートがあればいいのにと思います。 私は自分のサイドカーと仕事で同じ問題を抱えていたので、サイドカーにkube apiを使用して、ポッド内の他のコンテナーのステータスを監視させました。 completedで終了した場合、サイドカーは0を終了します。サイドカーが1を終了するというエラーが発生しました。おそらく最も洗練されたソリューションではありませんが、開発者が大幅に変更することなくトリックを実行しました。 興味のある方はコードをご覧ください： //github.com/uswitch/vault-creds/blob/master/cmd/main.go#L132。

これは私にゴリラズの歌M1A1を思い出させます...

こんにちは？ Hellooooooo？ 誰かいませんか？

はい、トラクション+1を取得してください

したがって、アップストリームの変更を必要とする提案されたソリューションは次のとおりです。

1. sidecar: true by @ jmillikin-stripe
2. @msperlによる追加のライフサイクルフック
3. jobCompletedWith by @jpalomaki

サイドカーの一時的な解決策、ハッキーなもの（しかし機能します）：

1. @phidahによるcloudsql-proxyサイドカーの場合

提案されたソリューションに関するKubernetesのメンテナからの回答をお待ちしており、既存のkubernetesバージョンを使用してこのユースケースを解決する方法について推奨事項を教えてください。 ありがとう！

レンダリングタスクのstdout / stderrをデータベースにアップロードするログエージェントを作成しようとして1日を費やした後、このスレッドを発見しましたが、ポッド内にエージェントが存在するということは、ジョブが決して終了しないことを意味することを発見しただけです。

上記の提案の中で、私は「サイドカー：真」が一番好きです。それはシンプルで要点があり、私のような開発者には非常に理解しやすいからです。 「サイドカー」は実際には単なるジョブ以上のものに適用され、完了要件以外の他のものを暗示するポッドデザインパターンであるため、私はおそらくそれを少し異なるものと呼ぶでしょう。 私のバイクシェディングを許せば、おそらく「ambient：true」のようなものと呼んで、このタスクがまだ実行されている場合でもジョブが完了したと見なすことができることを示します。 他の単語は「補助」または「サポート」である可能性があります。

他の多くの人が説明しているのと同じワークフローで、この問題も発生しました（接続のプロキシまたはメトリックの収集に使用され、ポッド内の他のコンテナーが正常に終了した後は目的がないサイドカーコンテナー）。

以前の提案は、一部のコンテナーを「完了」コンテナーとして指定することでした。 反対のことを提案したいと思います-いくつかのコンテナを「サイドカー」として指定する機能。 ポッド内の最後の非サイドカーコンテナが終了すると、ポッドはTERMをサイドカーに送信する必要があります。

これも私の理想的な解決策です。 SIGTERMの代わりにSIGHUPを提案するかもしれません-これは、SIGHUPのセマンティクスが関連する正確なユースケースのようです！ -でもどちらでもいいと思います。

現状では、Kubernetesでジョブを実行するには、サイドカー以外のコンテナが終了したときにKubernetes固有のコンテナ間通信を処理するためにアップストリームコンテナイメージに手動でパッチを適用するか、ゾンビポッドが終了しないようにすべてのジョブのサイドカーを手動で終了する必要がありますぶらぶら。 どちらも特に楽しいものではありません。

このパッチを作成したいと思いますが、コードを掘り下げる前に、@ kubernetes / sig-apps-feature-requestsからのガイダンスをお願いします。 これを機能させるためにポッド仕様にsidecarフィールドを追加しても大丈夫ですか？ ポッドの仕様を変更することを躊躇しますが、それが必要かどうかはわかりません。 たぶん今のところ注釈を使用しますか？

@andrewsykim私はしばらくの間この問題を

私の推論はそれです：

• この問題は2年近く前から発生しており、kubernetesコアからはあまり注目されていません。 したがって、ポッドの仕様を変更するのを待つか、直接入力を待つと、おそらく長い間待つことになります。
• 実行可能なPRは、古い問題よりも注意を引くのがはるかに簡単です。
• 将来的にポッド属性を使用するようにアノテーションアプローチを切り替えるのは、それぞれかなり良いはずです

考え？

こんにちは、私はkubeconのsig-appsの人たちにこの問題について話しました。基本的に、それは彼らの当面のロードマップにあるものではありませんが、彼らが有効なユースケースであると考えるものです。 彼らはこれに取り組むコミュニティの誰かに非常にオープンです。

これを解決するための拡張提案のPRを作成したので、これによってディスカッションが生成されることを願っていますhttps://github.com/kubernetes/community/pull/2148。

@ Joseph-Irvingをまとめてくれてありがとう！ これについて対処する必要のある詳細があるように思われるので、それまでは作業を延期します:)

永続的な長期的な問題:(

cc @ kow3ns @janetkuo

問題をさらに複雑にすることを意味することなく、 initContainersと一緒に「サイドカー」スタイルのコンテナーを実行できることも役立ちます。

私のユースケースはここの人々に似ています。データベースの移行を実行するinitContainerと同時にクラウドSQLプロキシを実行する必要があります。 initContainersは一度に1つずつ実行されるため、プロキシをデプロイメント+サービスとして実行する以外は、これを行う方法がわかりませんが、他のユースケース（ログ管理など）では適切な作業ではないと思います。その周り。

@mcfedr initコンテナの動作に関する観察を評価する、かなりアクティブな拡張提案があります。 それがこの提案の範囲内なのか、それに関連する改善なのかは私にはわかりませんが、十分に関連しているので、検討のために提起するのは理にかなっていると思います。

潜在的な実装/互換性の問題にもかかわらず、理想的なモデルは、サイドカーのinitコンテナーが、現在のように順次実行され続ける非サイドカーのinitコンテナーと同時に実行され、メインシーケンスコンテナーが起動する前にサイドカーが終了することです。

その価値については、CloudSQL Proxyet.alのようにまだ実行されているサイドカーを無視する必要性も表明したいと思います。

スクリプトにそれほど時間がかからないことがわかっているので、30秒後にcloudsqlコンテナを強制終了できました。 これが私のアプローチです：

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: schedule
spec:
  concurrencyPolicy: Forbid
  schedule: "*/10 * * * *"
  startingDeadlineSeconds: 40
  jobTemplate:
    spec:
      completions: 1
      template:
        spec:
          containers:
          - image: someimage
            name: imagename
            args:
            - php
            - /var/www/html/artisan
            - schedule:run
          - command: ["sh", "-c"]
            args:
            - /cloud_sql_proxy -instances=cloudsql_instance=tcp:3306 -credential_file=some_secret_file.json & pid=$! && (sleep 30 && kill -9 $pid 2>/dev/null)
            image: gcr.io/cloudsql-docker/gce-proxy:1.11
            imagePullPolicy: IfNotPresent
            name: cloudsql
            resources: {}
            volumeMounts:
            - mountPath: /secrets/cloudsql
              name: secretname
              readOnly: true
          restartPolicy: OnFailure
          volumes:
          - name: secretname
            secret:
              defaultMode: 420
              secretName: secretname

そしてそれは私のために働いています。
このアプローチに何か欠点がありますか？

それらは関連していて、CronJobにも簡単に適応できると思うので、これが私のソリューションです： https ：

これは、ここに掲載されている回避策の1つに基づいていますが、展開用であるため、 preStop使用します。 サイドカーをトラップすることは素晴らしい働きをします。

この問題に続いて。 また、cronjobのサイドカーとしてcloud_sql_proxyコンテナを使用しています
@stikoによるタイムアウト実装を使用しました

会話に、Replaceの使用に関して@ oxygen0211によって提案された解決策を追加するだけで、今のところ適切な回避策です。私のようにこの問題が発生した場合は、必ず確認してください。

https://github.com/kubernetes/kubernetes/issues/25908#issuecomment -327396198

このKEPは暫定的に承認されていますhttps://github.com/kubernetes/community/pull/2148 、まだ合意する必要のあることがいくつかありますが、比較的早く作業を開始できる場所に到達することを願っています。 KEPは30日にhttps://github.com/kubernetes/enhancementsに移動するため、フォローしたい場合はそこにあります。

サイドカーサポートが到着するまで、後で簡単に削除できるDockerレベルのソリューションを使用できます： https ：

Dockerソケットと標準のkubernetesラベルがマウントされた特権コンテナーを使用して、ジョブ内のコンテナーを管理します。

Istioとそのサイドカーでも同じ問題が発生していましたが、このようにcurl + preStopフックを使用してポッドを削除することにしました。

このような最小限のRBACルールを仕事に与える

apiVersion: v1
kind: ServiceAccount
metadata:
  name: myservice-job
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: myservice-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["delete"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: myservice-job-rolebinding
subjects:
  - kind: ServiceAccount
    name: myservice-job
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: myservice-role

そしてPOD_NAMEとPOD_NAMESPACEをあなたのENVにそのように

   env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace

最後に、次のようなpreStopフックを追加します

 lifecycle:
      preStop:
        exec:
          command: 
            - "/bin/bash" 
            - "-c"
            - "curl -X DELETE -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt https://$KUBERNETES_SERVICE_HOST/api/v1/namespaces/$POD_NAMESPACE/pods/$POD_NAME?gracePeriodSeconds=1"

ちょっと面倒ですが、適切なDockerコンテナを殺そうとするよりも少し安全で気まぐれではありません。

これをここに投げるだけですが、実行中のポッドの変更を監視するためのコントローラーをしばらく前に一緒に投げ、SIGTERMをサイドカーコンテナーに適切に送信しました。 それは間違いなく最も堅牢ではありません、そして正直なところ私はそれをしばらく使用していませんが、助けになるかもしれません。

https://github.com/nrmitchi/k8s-controller-sidecars

ClusterIPサービスを使用したデプロイとしてcloud_sql_proxyを実行するよう提案してくれた、 https： //github.com/kubernetes/kubernetes/issues/25908#issuecomment-371469801の@jpalomakiと@でhttps://github.com/kubernetes/kubernetes/issues/25908#issuecomment設定のヒントについて-364255363 tcp:0.0.0.0でcloud_sql_proxy instancesパラメータを許可する非-プロセスへのローカル接続。 これらを組み合わせることで、cronジョブにプロキシを使用させるのは簡単になりました。

長期的な問題（自己メモ）

同じ問題。 Cloud SQL GKE cronジョブを使用する方法に関する方法または公式ドキュメントを探しています

サイドノート：
GoogleはクラウドSQLを更新- > GoogleのKubernetesエンジンからの接続、ドキュメント今に加えて、 Connecting using the Cloud SQL Proxy Docker imageすることができますConnecting using a private IP address
したがって、同じ理由でここにいる場合（cloud_sql_proxyのため）、プライベートIPの新機能を使用できるようになります

サイドノート：
GoogleはクラウドSQLを更新- > GoogleのKubernetesエンジンからの接続、ドキュメント今に加えて、 Connecting using the Cloud SQL Proxy Docker imageすることができますConnecting using a private IP address
したがって、同じ理由でここにいる場合（cloud_sql_proxyのため）、プライベートIPの新機能を使用できるようになります

プライベートIP機能は、クラスター全体を削除して再作成する必要があるようです........？

@cropseこれは、クラスターがVPCネイティブでない場合にのみ必要です。

私はこの問題の回避策を作成しましたが、優れた解決策ではありませんでしたが、機能が追加される前にこのヘルプが役立つことを願っています。VPCは人気のある方法の1つですが、クラスター全体を削除するのは依然として苦痛です。

私の2セントを追加するだけです。ポッドが完了しないため、istioサイドカーの注入が発生した場合、ヘルムテストも失敗します。

@dansiviterあなたは私の回避策をチェックすることができます、私はすでに私のプロジェクトで舵をとってテストしました。

これが実装されるのを楽しみにしています！ :)

Istioプロキシが注入された場合、通常のジョブでも同じ問題が発生します。それ以上に、ProwでCIジョブを実行するため、これも必要です。
例：テスト目的のRailsアプリコンテナー+サイドカーデータベースコンテナー。

@cropseありがとう。 すべてのテストでこれを構成する必要があるため、試していません。 ポッド（ヘルムテストでは残念ながらジョブは許可されません）が失敗することを許可し、この問題が長期的に修正されるまでログを手動で検査することに依存しています。 しかし、それは他のジョブにとっても問題になりつつあるので、私たちはその立場を再考する必要があるかもしれません。

参考までに、この機能の追跡の問題はここにありますhttps://github.com/kubernetes/enhancements/issues/753人々がフォローしたい場合は、KEPがあり、いくつかのプロトタイピングが行われます（POCブランチ/ビデオがあります） ）、実装可能な状態になる前に、実装の詳細の一部を修正する必要があります。

サイドノート：
GoogleはクラウドSQLを更新- > GoogleのKubernetesエンジンからの接続、ドキュメント今に加えて、 Connecting using the Cloud SQL Proxy Docker imageすることができますConnecting using a private IP address
したがって、同じ理由でここにいる場合（cloud_sql_proxyのため）、プライベートIPの新機能を使用できるようになります

同じ理由で私はここにいましたが、この機能の準備が整う前にCloudSQLがプロビジョニングされました。 以前の提案を組み合わせて、dbmate migrator helmチャートにこれを（おそらく理想的ではありませんが、機能します）出しました。

      containers:
      - name: migrator
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        command: ["/bin/bash", "-c"]
        args:
          - |
            /cloud_sql_proxy -instances={{ .Values.gcp.project }}:{{ .Values.gcp.region }}:{{ .Values.gcp.cloudsql_database }}=tcp:5432 -credential_file=/secrets/cloudsql/credentials.json &
            ensure_proxy_is_up.sh dbmate up
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: DATABASE_URL
        volumeMounts:
          - name: cloudsql-instance-credentials
            mountPath: /secrets/cloudsql
            readOnly: true
      volumes:
        - name: cloudsql-instance-credentials
          secret:
            secretName: cloudsql-instance-credentials

ensure_proxy_is_up.sh

#!/bin/bash

until pg_isready -d $(echo $DATABASE_URL); do
    sleep 1
done

# run the command that was passed in
exec "$@"

Kubernetesでサイドカーコンテナの概念を理解し、サイドカー以外のコンテナが終了したかどうかに基づいてポッドをクリーンアップできるようにするのは良い時期でしょうか？

@Willux私は電話の

@krancourアップデートしてくれてありがとう。 私はその詳細を見逃したに違いありません。 最近ここで起こっている活動はあまりなかったので、何かが進行中であることを確認したかっただけです:)

参考までに、共有ボリューム内のファイルが状態をサイドカーに伝達する@ jmillikin-stripeの回避策のcloud-sql-proxyサイドカーバージョンを作成しました。

それは問題なく動作しますが、私のK8s構成で最も厄介なハックです:(

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  template:
    spec:
      containers:
      - name: example-job
        image: eu.gcr.io/example/example-job:latest
        command: ["/bin/sh", "-c"]
        args:
          - |
            trap "touch /tmp/pod/main-terminated" EXIT
            run-job.sh
        volumeMounts:
          - mountPath: /tmp/pod
            name: tmp-pod
      - name: cloudsql-proxy
        image: gcr.io/cloudsql-docker/gce-proxy:1.11
        command: ["/bin/sh", "-c"]
        args:
          - |
            /cloud_sql_proxy --dir=/cloudsql -instances=example:europe-west3:example=tcp:3306 -credential_file=/secrets/cloudsql/credentials.json &
            CHILD_PID=$!
            (while true; do if [[ -f "/tmp/pod/main-terminated" ]]; then kill $CHILD_PID; echo "Killed $CHILD_PID as the main container terminated."; fi; sleep 1; done) &
            wait $CHILD_PID
            if [[ -f "/tmp/pod/main-terminated" ]]; then exit 0; echo "Job completed. Exiting..."; fi
        volumeMounts:
          - name: cloudsql-instance-credentials
            mountPath: /secrets/cloudsql
            readOnly: true
          - name: cloudsql
            mountPath: /cloudsql
          - mountPath: /tmp/pod
            name: tmp-pod
            readOnly: true
      restartPolicy: Never
      volumes:
        - name: cloudsql-instance-credentials
          secret:
            secretName: cloudsql-instance-credentials
        - name: cloudsql
          emptyDir:
        - name: tmp-pod
          emptyDir: {}
  backoffLimit: 1

プロジェクトの内部の誰かがこの問題の進捗状況についてコメントできますか？

これが、GKEの安定したリリースチャネルに取り組んでいる私たちにとって最良のオプションであると考えるのは公正ですか？少なくとも数か月はKubernetes 1.18に追いつかないでしょう。

@Datamanceこの時点で、この問題に対処するためのKEPは、無期限に保留されているように見えます。

私はしばらく前にこのコメントを投稿しました。これは私の古い解決策でした。 私はここに自分のものをプッシュしようとはしていません。githubの「100morecomments ...」でそのコメントが失われ、リサーフェシングが再び役立つかもしれないと考えました。

@nrmitchi再ございます。 私はコメントの海でそれを見落としていた人であり、これは素晴らしい短期的な解決策のように見えます。

ポッドコンテナに以下を追加すると、別のアプローチがわかります。

    securityContext:
            capabilities:
                   add:
                    - SYS_PTRACE

その後、他のコンテナでPidをgrepできるようになります。メインのコンテナの最後で、次のように実行します。
sql_proxy_pid=$(pgrep cloud_sql_proxy) && kill -INT $sql_proxy_pid

@krancourはそれが役に立ったことをうれしく思います。 そのリポジトリ内のネットワークを見ると、ほぼ間違いなく私の元の場所よりも良い場所にあるいくつかのフォークがあり、それを基に構築/使用する方が良いかもしれません。

IIRCのlemonade-hqフォークには、いくつかの便利な追加機能がありました。

@nrmitchi 、私はコードをちらっと見ていますが、ただあなたに尋ねる方が速いかもしれません...

READMEに記載されていない前提条件が存在する可能性がある場合は、簡単にコメントしていただけますか？

たとえば、サイドカーの基になっている画像には、この回避策について特別な認識が必要ですか？ たとえば、コントローラーからの信号を特定のポートでリッスンする必要がありますか？ または、特定のシェルを含める必要があります（bash？）

@krancourこのソリューションは数年前に作成されたものであり、私の記憶は少し錆びている可能性があるというメモで応答の置きます。

当時、問題のコンテナが回避策を意識する必要がないように設計されていました。 私たちは主にサイドカーでサードパーティのアプリケーションを使用しており（たとえば、ストライプ/ベニューは1つだったと思います）、フォーク/変更したくありませんでした。

サイドカーの唯一の要件は、SIGTERM信号を適切にリッスンしてから、シャットダウンすることです。 サイドカーで実行されているサードパーティのコードで、別の信号を予期して回避する必要があったという問題があったことを思い出しますが、実際には、コントローラーは送信された信号の指定を許可する必要がありました（つまり、SIGTERMではなくSIGINT）。

コントローラはexecを使用してサイドカーのメインプロセスに直接信号を送るため、信号をポートでリッスンする必要はありません。 クライアントに存在しなかったため、機能がkubernetesコードからコピーされたときのIIRC。 これは現在公式クライアントに存在し、おそらく更新する必要があると思います。

ポッドコンテナに以下を追加すると、別のアプローチがわかります。

    securityContext:
            capabilities:
                   add:
                    - SYS_PTRACE

その後、他のコンテナでPidをgrepできるようになります。メインのコンテナの最後で、次のように実行します。
sql_proxy_pid=$(pgrep cloud_sql_proxy) && kill -INT $sql_proxy_pid

@ ruiyang2015このハックをありがとう。
ただし、誰かがそれを実装している場合は、コンテナ間でプロセスnsを共有することの意味を必ず

@nrmitchi

execを使用してサイドカーのメインプロセスに直接信号を送ります

それが私が尋ねた理由の一部です...具体的には、 FROM scratch作成されたイメージに基づくコンテナではこれが機能しないのではないかと思います。

@krancourフェアポイント、私はscratchから外れたコンテナでテストしたことはありません。 コード（または私の元のバージョン。これはフォークで変更されている可能性があります）を見ると、 bashに依存しているように

bashに依存しますが、変更できるはずです

もちろんですが、実行している限り、コンテナに存在するバイナリに常に依存します。スクラッチコンテナの場合は、明示的に配置したものを除いて、そこには何もありません。 🤷‍♂

その制限があるため、実行中のコンテナが完全に任意であり、サードパーティによって指定されている可能性があるユースケースにはこれを使用できません。 ああ、それから私もWindowsコンテナを使用しています。

代わりに、私が何に落ち着くのかについて言及します。 ほとんどのユースケースには多分重すぎるでしょうが、他の誰かのユースケースがこれを回避するのに十分似ている場合に備えて言及しています...

最初に終了ステータスを記録する限り、「プライマリ」コンテナが終了したポッドを単に_削除_するという贅沢をする余裕があります。 したがって、指定された（アノテーションを介して）コンテナーの完了を監視し、その成功または失敗を既に「ジョブ」ステータスを追跡しているデータストアに記録してから、ポッドを完全に削除するコントローラーを作成することになります。

念のため、ポッドの削除を少し遅らせて、中央のログ集約が魚雷を発射する前にプライマリコンテナの出力の最後の数行を取得する可能性を最大化するでしょう。

ヘビーハンドですが、一部の人にとってはうまくいくかもしれません。

@krancour完全に真実。 現状では、コントローラーは任意の使用ベースでは機能しません。 正直なところ、私は戻って、他のケースをサポートするために実装の一部を抽象化しようとはしませんでした。前述のKEPがマージされ、この機能の必要性がなくなったと本当に思ったからです。

この問題は4年前のものであり、KEPはまだどこにも行きません。また、最先端の技術はすべてのエントリポイントを置き換えるハッキーなインラインシェルスクリプトであるため、「標準」ハック（共有ボリュームの墓石）を成文化することにしました。 ）多段階ビルドを使用してコンテナイメージに簡単にベイクできるGoバイナリに変換します。

https://github.com/karlkfi/kubexit

それを使用するいくつかの方法があります：

1. あなたの画像にそれを焼きます
2. initコンテナとエフェメラルボリュームを使用してサイドロードします。
3. 各ノードでプロビジョニングし、ホストバインドマウントを使用してコンテナにサイドロードします

編集： v0.2.0は、「誕生の依存関係」（開始の遅延）と「死の依存関係」（自己終了）をサポートするようになりました。

ドライブバイコメント：これはhttps://github.com/kubernetes/enhancements/issues/753とまったく同じように見え

@vanzinは前に

これの私の使用例は、VaultがCronJobを実行するための資格情報を提供することです。 タスクが完了すると、Vaultサイドカーはジョブが保留状態で実行されたままになり、監視システムが何かが間違っていると判断します。 KEPに何が起こったのかは残念です。