@enisoc @ dchen1107 @fejta @thockin @ kow3ns @derekwaynecarrは、この追跡の問題を開いて、議論できるようにしました。

/割当

@derekwaynecarr来週のsig-node会議に必要なkubeletの変更をスコーピングしました。変更は、 kuberuntimeパッケージ、具体的にはkuberuntime_manager.go inとkuberuntime_container.goのみ必要であると_信じています_

kuberuntime_manager.go 、 computePodActionsを変更して、シャットダウントリガー（すべての非サイドカーが完全に終了したときにサイドカーを殺す）を実装し、最初にサイドカーを起動することができます。

kuberuntime_container.goでは、サイドカーを最後に終了してpreStopフックを送信するためにkillContainersWithSyncResultを変更できます（preStopフックビットは少し議論の余地があり、それを行うべきかどうかは決まっていませんでした。 @ thockinは、なぜその行動を奨励したくないのかについて良い点を持っていました。コメントを参照してください）。

さらに調査してほしい場合はお知らせください。

@ kow3nsポッド仕様（sig-app）でコンテナーシーケンスの完全な説明を定義でき、開始、再起動、カスケードの考慮事項（sig-node）のためにkubeletでシーケンスを処理する方法を定義できれば、この議論は私にとってより理にかなっています。 2月5日のsig-nodeミーティングをキャッチして、より多くの情報を提供しましょう。

cc @ Joseph-アービング

提案によると、サイドカーはinitコンテナが実行された後にのみ実行されます。 しかし、ユースケースで、initコンテナの実行中/実行前にサイドカーを実行する必要がある場合はどうなりますか。 たとえば、（Istioのように）サイドカーとして実行されているプロキシを介してポッドのトラフィックをルーティングする場合は、initコンテナ自体がネットワーク呼び出しを行う場合に備えて、initコンテナの実行中にそのプロキシを配置する必要があります。

@luksaある時点でサイドカーが初期化フェーズで実行される可能性があると思いますが、現在のところ、この提案ではそのユースケースをカバーしていません。 現在、初期化フェーズで同時コンテナーを実行する方法はありません。そのため、ここで提案されているものよりもはるかに大きく/厄介な変更になる可能性があります。

このKEPの更新：
私はこれについてsig-nodeから@derekwaynecarrと@ dchen1107の両方に話しましたが、彼らは提案について大きな懸念を表明しませんでした。 KEPにPRを提起し、実装の詳細に関する最初のメモを追加し、ディスカッション中に浮かび上がったいくつかのポイントを明確にします。

APIについてはまだ同意する必要があります。コンテナをサイドカーとしてマークする簡単な方法が、より詳細な順序付けフラグよりも優先されるというコンセンサスがあるようです。 ブール値を持つことはやや制限がありますが、おそらくcontainerLifecycle: Sidecar沿ったものが望ましいので、将来拡張するオプションがあります。

@ Joseph-Irving実際には、ブール値もcontainerLifecycle: Sidecarも、将来の適切な拡張性には適切ではありません。 代わりに、 containerLifecycleは、 deployment.spec.strategyに、 type: Sidecar持つオブジェクトである必要があります。 これにより、追加のフィールドを導入できるようになります。 「ポッドの全寿命にわたるサイドカー」ソリューションの場合、次のように表現されます。

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: CompletePodLifetime

とは対照的に

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: AfterInit

私の悪い名前を許してください-名前がアイデアを伝えてくれることを願っています。

しかし、 containerLifecycleをpod.spec.containersに導入するアプローチには1つの問題があります。 つまり、 pod.spec.containers指定されたinitコンテナと並行して実行されるサイドカーを使用するのは誤りです。 したがって、これを最終的に初期化コンテナに拡張できるようにしたい場合は、代替ソリューションを見つける必要があります。これにより、コンテナをより高いレベルでサイドカーとしてマークできるようになります。つまり、 pod.spec.containersまたはpod.spec.initContainers未満でpod.spec.containersません。 pod.spec.initContainersですが、 pod.spec.sidecarContainersようなものです。これについては、すでに説明したと思いますが、却下されました。 initコンテナの問題は、間違いなくこれらの方針に沿った解決策を必要とします。

@luksa initコンテナをサイドカーとしてマークし、それをinitコンテナと一緒に実行できるようにするだけで、initの問題を解決することもできます。 私が理解しているように、問題は、initコンテナーにサイドカーが必要な場合があることです。これは、ポッドの存続期間全体にわたって実行されるコンテナーが必要な場合とは異なります。

pod.spec.sidecarContainersの問題は、それがはるかに複雑な変更であり、ツールを更新する必要があり、kubeletが別のコンテナーのセットをサポートするために多くの変更を必要とすることです。 現在の提案ははるかに控えめであり、すでにそこにあるものに基づいているだけです。

@ Joseph-Irvingそうです。 initコンテナが実行された後にサイドカーをシャットダウンしてから、同じサイドカーを再起動することは理想的ではありませんが、そのオプションがないよりはましです。 より大きな問題は、古いKubeletsがinit-sidecarコンテナを適切に処理しないことです（メインサイドカーコンテナの場合のように）。

提案を完成させるときは、init-sidecarsを念頭に置いてください。 基本的に、k8sに「サイドカー」の概念を導入しています（以前は、基本的にすべてが等しいコンテナのセットしかありませんでした）。 今、あなたは実際のサイドカーを紹介しているので、私見、あなたは本当にこれを徹底的に考えるべきであり、非常に重要なサイドカーのユースケースを却下しないでください。

これの実装を喜んでお手伝いさせていただきます。 これがないと、Istioはinitコンテナーにその機能を提供できません（実際、Istioを実行している適切に保護されたKubernetesクラスターでは、initコンテナーは_any_サービスと通信する機能を完全に失います）。

https://github.com/kubernetes/enhancements/pull/841での実装の議論に関連して、この提案の基本的なPoCを含むWIPPRを開きましたhttps://github.com/kubernetes/kubernetes/pull / 75099。 これは最初のドラフトであり、明らかに完璧ではありませんが、基本的な機能が機能し、必要な変更の量を把握できます。

cc @enisoc

PoCが現在どのように動作するかを示す短いビデオをまとめましたhttps://youtu.be/4hC8t6_8bTs。 それが実際に動いているのを見るのは、それについて読むよりも良いかもしれません。
免責事項：私はプロのYouTuberではありません。

私は2つの新しいPRを開きました：

• https://github.com/kubernetes/enhancements/pull/918は、卒業基準、バージョンスキュー、アップグレード/ダウングレードに関するものです
• https://github.com/kubernetes/enhancements/pull/919は、APIの実装を決定することです

どんな考えや提案も大歓迎です。

@ Joseph-Irving設計プロセスの後半でコメントしている場合は申し訳ありませんが、現在の設計提案ではサポートされていない可能性のあるサイドカーコンテナの潜在的な使用例があります。 検討のために上げたかっただけです。 要点は、ポッドの終了時に、1つのサイドカーをメインコンテナの前に終了し、別のサイドカーをメインコンテナの後に終了するというシナリオがあるということです。

具体的な例としては、Djangoアプリコンテナーを備えたポッド、サービス登録用の領事サイドカー、データベースへの接続を管理するためのpgbouncerサイドカーなどがあります。 ポッドが終了したら、領事のサイドカーを最初に停止し（したがって、トラフィックがポッドにルーティングされないようにします）、次にアプリコンテナー（理想的には短い猶予期間後）、次にpgbouncerサイドカーを停止します。 現在の提案は、アプリの<-> pgbouncerコンテナーの依存関係を処理するのに最適に見えますが、プライマリコンテナーの_前_にサイドカーを分解したい場合をキャプチャするのに十分な表現力がないようです。

@currankaushik 、あなたが説明したシナリオでは、pre-stopフックを使用して、領事館のコンテナーにシャットダウンの準備をし、ルーティング要求を停止するように指示することができます（そのようなものをサポートできると仮定します）。 コンテナの終了が始まる前に、プレストップフックが最初にサイドカーに送られます。

これの動機は、istioのようなプロキシサイドカーがトラフィックをルーティングしていない状態に入ることができるようにすることでしたが、アプリケーションが終了してシャットダウンする間もトラフィックを許可しています。

@ Joseph-Irvingに感謝します。 したがって、私の理解を大まかに確認するために、最初にプレストップフックがサイドカーに送信され、次に非サイドカーにプレストップフックが送信され、次に非サイドカーにSIGTERMが送信され、次に（すべての非サイドカーが終了した後） ）サイドカーへのSIGTERM？ デザイン提案（https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/sidecarcontainers.md）はこれを暗示しているようですが、次のようにも述べています。

PreStopフックはサイドカーとコンテナに同時に送られます。

@currankaushikええ、あなたが説明したのは意図された振る舞いです。

あなたが引用したその行は言い換える必要があります。 私がそれを書いたとき、私はプレストップフックがどのようにコンテナに送られるかについていくつかの誤解を持っていました。 ご指摘いただきありがとうございます。

@ Joseph-Irvingは、1.15のアルファインクルージョンを対象としたこの機能ですか？

@ kacole2ええ、それは計画です。拡張フリーズ（4月30日）に間に合うようにKEPを実装可能にできると仮定しています。 APIが完成したらhttps://github.com/kubernetes/enhancements/pull/919 、テスト計画が合意されたらhttps://github.com/kubernetes/enhancements/pull/951すべての設定が必要だと思います。

/ milestone v1.15
/ステージアルファ

@ Joseph-Irving Kubernetes1.15拡張フリーズは2019年4月30日です。 Kubernetes 1.15マイルストーンに含まれるためには、KEPは、適切なテスト計画と卒業基準を備えた「実装可能」状態である必要があります。 このKEPを選択基準に準拠させるために必要なPRを提出してください。 これが1.15マイルストーンから外れる場合は、適切な追跡変更を行えるようにお知らせください。

@mrbobbytables残念ながら、これを実装可能な状態にするために開かれたPRはあまり動きがなかったので、1.16までこれを遅らせる必要があると思います。

心配ない。 迅速に対応し、お知らせいただきありがとうございます。
/マイルストーンクリア

このKEPはIstioにとって非常に重要であることに注意してください。

これは、istioサービスメッシュと一緒に調整されたブートストラップ/シャットダウン（akkaクラスター、lagomなど）を備えたサービスフレームワークを使用するすべてのプロジェクトのショーストッパーです。を参照してください。

cc @jroper

@ Joseph-Irvingはコメントの遅れについて心配していますが、デザインドキュメントに次のようなものは見当たりません。また、これらの意図された動作は何か疑問に思っていました。

サイドカーの障害が発生した場合、メインコンテナが終了していない場合は常にサイドカーを再起動しますか（ポッドのrestartPolicyは無視します）？ これは、サイドカーがプロキシ、負荷分散、ハウスキーピングの役割として機能するために使用されるので便利です。メインコンテナが機能し続ける限り、数回失敗しても問題ありません。

また、ポッドフェーズを計算するときに、すべてのメインコンテナが成功し、サイドカーが失敗した場合（サイドカーがSIGTERMをキャッチしない場合のように、リターンコードは143などになります）、ポッドフェーズはまだ「成功」していますか？

@ zhan849は現在、サイドカーコンテナがポッド再起動ポリシーに従い、 Succeededなどのポッドフェーズを計算するときにカウントされます。

これについてはプロセスのかなり早い段階で議論しましたが、一般的な感覚では、通常のコンテナーからの逸脱はできるだけ少なくし、説明されているユースケースが可能になる場合にのみそうする必要があります。

ポッドフェーズに関して：kubernetesで実行されているすべてのアプリケーションはSIGTERM（特にサイドカー）を処理する必要があると主張しますが、サイドカーが悪い方法で終了したかどうかを知りたい場合もあり、それをポッドフェーズに反映する必要があります。その情報を非表示にすると、混乱を招く可能性があります。

再起動ポリシーの場合、再起動ポリシーが適用されず、サイドカーがクラッシュしやすい場合にのみ問題になるようです。 ポッド再起動ポリシーからそれらを逸脱することの複雑さがそれだけの価値があるかどうかはわかりません。特に、サイドカーにポッド再起動ポリシーに従うことを望む人がいるかもしれません。

これらは両方とも、通常のコンテナが実行することと現在何が起こっているかと一致しています。
Kepに記載されている目標を達成するために、それらを変更する必要はないようです。

これらの目標を達成するために変更が必要な理由について、いくつかの広範なユースケースがある場合は、それが役立ちます。 コードベースへのより複雑な変更を正当化するのが簡単になるため。

@ Joseph-Irvingには、いくつかの差し迫ったニーズのために内部で実行されている、より単純なサイドカーimplがあります（これはコミュニティですでに進行中であるため、貢献しませんでした）。これが私たちが学んだことです。

ポッドフェーズについて：

1. コンテナの存在ステータスはすでにpod.status.containerStatuses反映されているため、情報が失われることはありません。 また、サイドカーの大きなユースケースはジョブ（またはKubeflowのポッドなどの実行から終了までのポッド）にあるため、意味のあるワークロードはメインコンテナーにのみ適用され、サイドカーの障害が原因でポッドフェーズが失敗としてマークされている場合、不必要な再試行が発生し、ジョブの失敗など、他の誤解を招く結果につながります。

2. サイドカーがSIGTERMを処理するのは理想的ですが、本番環境では、オープンソースソフトウェアに基づいて構築されたサイドカーがたくさんあり、 kube-proxy 、 postfix 、 rsyslogdなどのSIGTERMをうまく処理できません。

再起動ポリシーについて（議論の余地はありますが、サイドカーをrestartPolicyに厳密に従わせることは、本番環境では現実的ではありません）：

1. 「OnFailure」を設定してメインコンテナがまだ実行されているときにサイドカーを強制的に再起動することは、失敗したメインコンテナを再起動し、ジョブレベルの再試行制限とともに混乱するため、オプションではありません。

2. 通常、サイドカーを処理する場合、メインコンテナーには通常、サイドカーを使用できないための再試行ロジックが多数あります。これらは、コミュニティが明示的なコンテナー開始順序でサイドカーをサポートする前に実行されます。 このような履歴エラー処理は、その範囲を考えると変更するのは簡単ではありません。 サイドカーを再起動しないと、メインコンテナがハングして再試行します

3. 障害を上位レベルのコントローラーに伝播すると、調整のチェーンと多くのAPI呼び出しがトリガーされるため、エラーの不必要なエスカレーションにより、kubernetesのスケーラビリティが低下する可能性があります。
   より具体的な例：ジョブのメインコンテナがまだ実行中でサイドカーに障害が発生した場合、サイドカーを再起動すると、PATCHポッドステータス操作が1つだけになり、イベント関連のAPI呼び出しが最大で1つになります。 ただし、ポッドに完全に障害が発生すると、ジョブが調整され、CronJobやその他のCRDなどの採用レベルのコントローラーが増え、API呼び出しがさらに増える可能性があります。

他の人が同様の問題を見たかどうかも確認したい（/ cc

この変更には、 https：//github.com/kubernetes/community/pull/2342で必要な動作が組み込まれているので、ポッド全体（またはサイドカー以外のコンテナーのみ）を構成して、サイドカーが失敗しますか？

@JacobHenner現在、このKEPにそのようなメカニズムを実装する計画はありません。それを組み込むことについて説明しましたが、実際にはこのKEPにあまり依存せず、これとは独立して開発できます。 したがって、独自のKEPを持つ方が適しているようです。

@ Joseph-Irvingは、参考のために上記の落とし穴に対処したimplを共有するだけです（https://github.com/zhan849/kubernetes/commits/kubelet-sidecar）。私たちの目標は公式のサポートを待つことなので、試してみますこのコミットで変更を可能な限りローカルに保つため。

したがって、ジョブ再開ポリシーの場合==決して、メインコンテナが1つ、常にクラッシュする不良サイドカーが1つ、実行を継続する良好なサイドカーが1つある場合、メインコンテナが上記の実装で終了すると、ポッドのステータスは次のようになります。

containerStatuses:
  - containerID: xxxxx
    image: xxxxx
    imageID: xxxxx
    lastState: {}
    name: main
    ready: false
    restartCount: 0
    state:
      terminated:
        containerID: xxxxx
        exitCode: 0
        finishedAt: "2019-05-24T17:59:53Z"
        reason: Completed
        startedAt: "2019-05-24T17:59:43Z"
  - containerID: xxxxx
    image: xxxxxx
    imageID: xxxxx
    lastState: {}
    name: sidecar-bad
    ready: false
    restartCount: 1
    state:
      terminated:
        containerID: xxxxx
        exitCode: 1
        finishedAt: "2019-05-24T17:59:46Z"
        reason: Error
        startedAt: "2019-05-24T17:59:45Z"
  - containerID: xxxxx
    image: xxxxxxx
    imageID: xxxxx
    lastState: {}
    name: sidecar-healthy
    ready: false
    restartCount: 0
    state:
      terminated:
        containerID: xxxxx
        exitCode: 137
        finishedAt: "2019-05-24T18:00:24Z"
        reason: Error
        startedAt: "2019-05-24T17:59:44Z"
  hostIP: 10.3.23.230
  phase: Succeeded
  podIP: 192.168.1.85
  qosClass: BestEffort
  startTime: "2019-05-24T17:59:41Z"

私は一般的に、サイドカーKEPが実装可能な状態になる前に、ポッドフェーズと再起動ポリシーを考慮する必要があることに同意します。 このKEPであるかどうかは関係ありませんが、 @ zhan849の議論に概ね同意するので、ここで扱う必要があります。

ありがとう@smarterclayton ！
@ Joseph-Irvingは、実際にサイドカーと共有したいことが他にあるかどうかを知らせてくれます。

@smarterclayton @ zhan849 、私はあなたが作ったポイントに特に同意しません。ただいくつかのカウンターポイントを与えようとしているだけです。 ポッドフェーズ/再開ポリシーを変更しないことは、この提案の範囲をさらに拡大し、誰もそれについて非常に強く感じなかったため、意識的な選択でした。

このフィードバックをsig-apps / sig-nodeに戻し、彼らの考えを確認します。 @derekwaynecarrまたは@ dchen1107が認識されるであろうという点でチャイムする場合は特に、SIG-ノードは、できるだけ通常のコンテナに近くにサイドカーを維持するに熱心でした。

テストプランhttps://github.com/kubernetes/enhancements/pull/951とAPIデザインhttps://github.com/kubernetes/enhancements/pull/919PRが統合されました。

https://github.com/kubernetes/enhancements/pull/1109を開いて、KEPを実装可能としてマークしました。全員が満足したら、1.16でアルファ版として開発を開始できるはずです🤞

このKepは実装可能とマークされているので、来週からこれを1.16にするためにPRを上げます！

APIを実装するためにhttps://github.com/kubernetes/kubernetes/pull/79649を上げました。Kubeletの変更については別のPRを用意します。

こんにちは@ Joseph-Irving、私は1.16エンハンスメントリードです。 この機能は1.16でアルファ/ベータ/安定ステージを卒業する予定ですか？ 1.16トラッキングスプレッドシートに追加できるようにお知らせください。 卒業していない場合は、マイルストーンから削除し、追跡ラベルを変更します。

コーディングが開始されたら、またはすでにある場合は、適切に追跡できるように、この号に関連するすべてのk / kPRをリストしてください。

マイルストーンの日付は、Enhancement Freeze7 / 30およびCodeFreeze8 / 29です。

ありがとうございました。

@ Joseph-Irvingこれを実装するために追加の人が必要な場合は、この着陸に非常に興味があるので、喜んで手を貸します。

こんにちは@ kacole2これは1.16のAlphaをターゲットにしており、KEPは実装可能とマークされています。
現在、このための唯一のPRは、APIのkubernetes / kubernetes＃79649です。

@mhuxtableすぐに、kubeletの変更のPRを上げていきます。いくつかの作業を終えるだけです。それを見て、助けていただければ幸いです。 上げたらここにリンクします。

kubeletの変更を実装するhttps://github.com/kubernetes/kubernetes/pull/80744を開きました。

kubernetes / kubernetes＃79649（api）はまだ開いているため、このPRにはコミットが含まれているため、大きく見えることに注意してください。 私はそれをコミットに分割し、それぞれが異なる機能を実装しているので、そのようにレビューするのは簡単です。

このためのすべてのテストケースの実行はまだ完了していませんが、実装の最初のドラフトが完了しているので、皆さんに見てもらいたいと思います。

cc @ kacole2

@ Joseph-Irving

私はv1.16ドキュメントシャドウの1つです。
この拡張機能（またはv1.16で計画されている作業）には、新しいドキュメント（または既存のドキュメントへの変更）が必要ですか？ そうでない場合は、1.16エンハンスメントトラッカーシートを更新してください（またはお知らせください。更新します）

もしそうなら、8月23日金曜日までに予定されているk / website（ブランチdev-1.16）に対するPRを探しているのは、フレンドリーなリマインダーです。現時点では、プレースホルダーPRになる可能性があります。 ご不明な点がございましたらお知らせください。

こんにちは@daminisatya 、はい、これにはドキュメントの更新が必要です。プレースホルダーPRとしてhttps://github.com/kubernetes/website/pull/15693を上げました。
ドキュメントがどこに行くべきかについて誰かが意見を持っているかどうか知りたいのですが、今のところcontent/en/docs/concepts/workloads/pods/pod-lifecycle.mdに何かを入れています。

Code Freezeまであと1週間もかからないので、これで1.16になる可能性は非常に低いと思われます。
まだ2つの比較的大きなオープンPRkubernetes / kubernetes＃80744とkubernetes / kubernetes＃79649があり、レビューを得るのに苦労しています。
うまくいけば、これらを調べるために、次のリリースサイクルでより多くのレビューア帯域幅があるでしょう。

/割当

これにより、実際のサービスをオンデマンドで開始（および破棄）できるサイドカーを作成できますか？

ゼロへのスケールのようですが、アイドル中に実行されているのはサイドカーだけです。 リクエストが来ると、実際のサービスが起動し、最後の応答（30秒など）の後、サービスが終了します。 これにより、ほぼゼロにスケーリングする簡単な方法が可能になります（サイドカーのみが実行されたままになります）。

@Ciantic Operator Frameworkを使用すると、それだけでなく、さらに多くのことができます。 見てください

@janosroden私は見ましたが、実行中のサービスをゼロスケーラブルに上げる方法を理解するのはかなり難しいようです。

問題は、使用可能なオプションなどがないことではありませんオシリス、ケダまたはknative 。 私は最後のものを試しましたが、それは8Gbのメモリを占有し、その時点で「サーバーレス」であるとは言い難いです。

問題は、これらの実装のほとんどが新しいリソースなどを必要とすることです。これを考えると、ライフサイクル全体（オンデマンドでの起動と再起動を含む）を制御できるサイドカーを注入して、サービスを制御できるようにすることがはるかに簡単になります。そこに座っています。

なぜこれが有益なのでしょうか？ これは、使用率が低くメモリが少ない状況で非常に役立ちます。たとえば、Raspberry Piを使用したk3や、趣味のプロジェクト用のDigitalOceanドロップレットなどです。 私たちの多くは、常に実行している必要のないWebサービスをたくさん持っています。必要に応じてそれらをウェイクアップできるサイドカーがあれば、それで十分です。

これが実際にユースケースで機能するかどうかはわかりません。 私は、そのようなリソースに制約のあるシステムであなたがやりたいことをやりたいという願望を完全に理解しています。 ただし、実際に安定させるには、リソース要求を使用してワークロードのスケジュールを設定する必要があります。 これらは事前に指定する必要があるため、ワークロードが実行されているかどうかに関係なく、リソースを予約する必要があります。

これを回避するには、最初の接続の受信を行い、k8sに新しいポッドリクエストを作成し、スピンアップするのを待ってからトラフィックを送信するための独自のポッドが必要です。 この場合、サイドカーコンテナの機能強化は必要ないと思います。 k8s用のxinetdのようなものが必要だと思います。

こんにちは@ Joseph-Irving-1.17拡張機能がここにつながります。 チェックインして、この拡張機能が1.17でアルファ版に移行すると思われるかどうかを確認したいと思います。

現在のリリーススケジュールは次のとおりです。

• 9月23日月曜日-リリースサイクルが始まります
• 10月15日火曜日、EODPST-拡張機能のフリーズ
• 11月14日木曜日、EODPST-コードフリーズ
• 11月19日火曜日-ドキュメントを完成させて確認する必要があります
• 12月9日月曜日-Kubernetes1.17.0がリリースされました

その場合、コーディングが開始されたら、適切に追跡できるように、この号に関連するすべてのk / kPRをリストしてください。 👍

ありがとう！

こんにちは@mrbobbytables 、計画が1.17でアルファに卒業することである時間内にすべてをレビューすることができると仮定します。

現在開いているPRは次のとおりです。
https://github.com/kubernetes/kubernetes/pull/79649-APIの変更
https://github.com/kubernetes/kubernetes/pull/80744-Kubeletの変更

他に何か必要な場合はお知らせください。

素晴らしい！ ありがとう@ Joseph-Irving追跡シートに情報を追加します👍

@ Joseph-Irving

私はv1.17ドキュメントシャドウの1つです。
この拡張機能（またはv1.17で計画されている作業）には、新しいドキュメント（または既存のドキュメントへの変更）が必要ですか？ そうでない場合は、1.17エンハンスメントトラッカーシートを更新してください（またはお知らせください。更新します）

もしそうなら、11月8日金曜日までに予定されているk / website（ブランチdev-1.17）に対するPRを探しているのは、フレンドリーなリマインダーです。現時点では、プレースホルダーPRになる可能性があります。 ご不明な点がございましたらお知らせください。

ありがとう！

こんにちは@ VineethReddy02ええ、これにはドキュメントが必要です。プレースホルダーPRはこちらhttps://github.com/kubernetes/website/pull/17190

KEPを更新するためにPRを作成しましたhttps://github.com/kubernetes/enhancements/pull/1344これは実装PRhttps ます/ 80744。

コメントをいただければ幸いです

ねえ@ Joseph-Irving1.17エンハンスメントシャドウはこちら！ 👋この機能強化がどのように行われているかを確認するために、あなたと一緒にチェックインするために連絡を取ります。

拡張チームは現在、追跡シートでkubernetes / kubernetes＃79649とkubernetes / kubernetes＃80744を追跡しています。 同様に追跡する必要がある他のk / k PRはありますか？

また、コードのフリーズに近づいていることを示すもう1つのわかりやすいリマインダーです（11月14日）。

こんにちは@annajung 、

こんにちは@ Joseph-Irving、明日は1.17リリースサイクルのコードフリーズです。 k / kPRがマージされていないようです。 1.17トラッキングシートでは、この拡張機能にAt Riskフラグを付けています。

必要なPRはすべて14日（木）のEoDで統合されると思いますか？ その後、例外を除いて、リリースブロッキングの問題とPRのみがマイルストーンで許可されます。

こんにちは@annajung 、残念ながら、コードがフリーズする前にマージされる可能性は非常に低いようです。 私たちはこのリリースサイクルで多くの進歩を遂げたので、うまくいけば、それらを早期に1.18にマージすることができます。

ねえ@ Joseph-Irving更新していただきありがとうございます。 それに応じてマイルストーンを更新し、この拡張機能を1.18に延期されたものとしてマークします。 ありがとうございました！

/マイルストーンv1.18

ねえ@ Joseph-Irving。 1.18拡張機能はここをリードします👋。

1.18リリースは昨日開始されたので、1.18リリースでこれを上陸させる予定があるかどうかを確認するために連絡を取りますか？ コードがフリーズしたため、これは1.17を逃したと思います。 1.18をどのように探していますか？ PRはまだ開いているようです。

ありがとう！

こんにちは@jeremyrickard 、

ええ、計画は1.18リリースでこれを取得することです。

API PR（https://github.com/kubernetes/kubernetes/pull/79649）はthockinからレビューを受けました。先日、彼はいくつかのポイントを持っていましたが、それらが解決されたら、そのPRを閉じて、コミットをに組み込みます。 （https://github.com/kubernetes/kubernetes/pull/80744）これにより、APIと実装をマージできます。

Kubelet PR（https://github.com/kubernetes/kubernetes/pull/80744）については、レビューが必要です。このサイクルでレビューするために、sig-node帯域幅を取得できることを期待しています。

更新してくれてありがとう@ Joseph-Irving

トラッキングシートに追加しました！

パーティーに遅れてすみません。 これは、一般的なケースでは大幅な改善です。 しかし、より高度なケースをカバーしていないようです。

Istioサイドカーにも依存するログをエクスポートするサイドカーのケースを考えてみましょう。 Istioサイドカーが最初にシャットダウンした場合、一部の機密ログがエクスポートされない可能性があります。

より一般的なアプローチは、コンテナー間の明示的な依存関係を定義することです。 彼らがサイドカーであるかどうかに関係なく。

代わりに、そのようなAPI定義についてどう思いますか。

kind: Pod
spec:
  containers:
  - name: myapp
    dependsOn: ["exporter", "istio"]
  - name: exporter
    dependsOn: ["istio"]
  - name: istio

@rubenhakそれは本当にすぐに乱雑になります。 依存関係を明確に進めるには、何を満たす必要がありますか？ 開始と準備の間にギャップがあることがよくありますが、dependsOnはそのAPIが対応していないことを本当に気にかけていると思います。

@ kfox1111提案された設計は、メインコンテナを起動するためにサイドカーが始動し、準備ができていることをどのように判断しますか？ 私が提案する唯一の違いは、コンテナを「サイドカー」としてマークする代わりに、依存関係を定義するより一般的な方法を使用することです。

私はdependsOnが基準を指定するべきではないと思います。 依存コンテナで指定できます。 readinessProbeおよび/またはlivenessProbeで十分ではないでしょうか？ そうでない場合は、 startupProbeが存在する可能性があります。成功した場合は、依存コンテナーを開始できることを示します。

こんにちは@ Joseph-Irving私はv1.18ドキュメントの影の1つです。
この拡張機能（またはv1.18で計画されている作業）には、新しいドキュメント（または既存のドキュメントへの変更）が必要ですか？ そうでない場合は、1.18エンハンスメントトラッカーシートを更新してください（またはお知らせください。更新します）

もしそうなら、2月28日金曜日までに予定されているk / website（ブランチdev-1.18）に対するPRを探しているのは、フレンドリーなリマインダーです。現時点では、プレースホルダーPRになる可能性があります。 ご不明な点がございましたらお知らせください。

こんにちは@irvifaここでプレースホルダーPRを上げましたhttps://github.com/kubernetes/website/pull/19046

こんにちは@ Joseph-Irving迅速な対応ありがとうございます！

@rubenhak -私は、依存関係の完全なグラフを持つことはかなり迅速にかなり厄介を得ることができること@ kfox1111に同意します。 ポッド仕様の順序でコンテナーを開始してから、逆の順序（スタックのように）でコンテナーを破棄するのはどうですか？ これは実装がはるかに簡単で、私が考えることができる一般的な順序付けのユースケースのほとんどをカバーしています。

@rgulewich 、もう少し詳しく説明してもらえますか？正確に何が乱雑になる可能性がありますか？ グラフから順序を導き出すことは簡単な作業です。特に、正気のオペレーターが15台を超えるサイドカーを走らせることはないという事実を考えると（すでに一気に）。

注文のアイデアは大丈夫​​ですが、ほとんどのサイドカーはアドミッションコントローラーを使用して注入されるため、注文の正確さを保証することは非常に困難です。 間接化の必要があります。

@rubenhakコンテナの依存関係の順序にサイクルが存在する可能性がありますが、k8s / kubeletはどのようにしてサイクルを中断し、コンテナを開始/停止する順序を決定しますか？ 大声で考えると、これはAPI側の検証である可能性があります。

ねえ@ Joseph-Irving、

1.18のコードフリーズは2020年3月5日です。

コードのフリーズに向けて追跡しているので、この拡張機能の卒業に向けて取り組んでいるPRをリストアップ/リンクしてください。

ねえ@jeremyrickard 、

追跡するPRはhttps://github.com/kubernetes/kubernetes/pull/80744
このPRにはAPIの変更が含まれていますが、レビューが終了すると、コミットが上記のPRにマージされますhttps://github.com/kubernetes/kubernetes/pull/79649

@rubenhakコンテナの依存関係の順序にサイクルが存在する可能性がありますが、k8s / kubeletはどのようにしてサイクルを中断し、コンテナを開始/停止する順序を決定しますか？ 大声で考えると、これはAPI側の検証である可能性があります。

@ bjhaid 、API側が検証を行うことができます。 ループ検出は、（DFSトラバーサルのように）線形の時間計算量を持つ簡単なアルゴリズムです。

サイドカーの注入後にも検証を再実行する必要があるかもしれません。

私はこれについてしばらく考えていました...依存関係に関する問題のほとんどは、実際にはメッシュをサービスすることだと思います。 （多分誰かが別の例を考えることができます）

サービスメッシュプロキシは、何よりも先に開始して準備を整える必要があり、何よりも後に終了する必要があるサイドカーです。 それらは長時間実行されているので、初期化コンテナというよりはサイドカーのようなものです。

ただし、initContainersは、理想的にはすべてのサービスメッシュも使用できる必要があります。

ただし、initContainersは他のサイドカーコンテナを初期化する必要がある場合があります。

initコンテナー、サイドカーコンテナー、および通常のコンテナーを含む、ある種の複雑な依存関係システムを設計することはできますが、サイドカーの2つのクラスだけを用意する必要があるのではないでしょうか。 通常のサイドカー、そしてネットワークサイドカー？

ネットワークサイドカーは、最初からすべて準備ができている必要があります。 サービスメッシュプロキシはここにあります。
次に、initコンテナが順番に実行されます。
サイドカーはすべて始動して準備が整います。 これには、認証プロキシ、ロガーなどが含まれる場合があります。
通常のコンテナが起動し、準備が整います。

分解は逆です。

これにより、サービスメッシュがコンテナの順序付けで抱えていると思われるすべての問題を解決しながら、依存関係の問題を排除できますか？ 私はそう思っていますか？

@ kfox1111 、Vaultはサイドカーを使用してシークレットインジェクションを実行するようになりました。 どのクラスに収まる必要がありますか？ また、場合によっては、ボールトはサービスメッシュに依存するか、またはその逆になります。

私が言っているのは、そのようなデザインが最終的に10のサイドカークラスに爆発するということです。 そのようなアプローチは、物事がどのように実行されるべきかについてのさらに強い意見を意味します。 人々は、アプリケーションを起動するために必要な順序を達成するためだけに、クラスでハッキングを開始します。

これらのクラスの唯一の目的が順序を定義することである場合、それを明示的に行わないのはなぜですか？

あなたの質問に答えると、そのような設計はいくつかのユースケースをカバーしますが、ボールトサイドカー、ロギングサイドカーなどの他のケースには役立ちません。これはすでに元の機能の再設計の提案です。 これは2回目の試みなので、今回は正しく行う価値があります。

依存関係がどのように複雑であるかはわかりません。 これについて詳しく教えていただけますか？ 依存関係によりYAML定義がより明確になり、隠れたロジックはありません。 ハードコードされたクラスを使用したアプローチでは、ネットワークサイドカーが他のサイドカーの後に実行される理由を説明する隠しロジックとより多くのドキュメントが必要になります。

コンテナにフィールドを導入するとどうなりますか？

    // +optional
    Priority int

このフィールドは、同じタイプ（サイドカー、通常）のコンテナ間で有効です。
サイドカーコンテナの場合、優先度の高いサイドカーコンテナが最初にインスタンス化され、最後に破棄されます。

@tedyu 、依存関係には、「優先度」と比較してはるかに多くのメタデータと値があります。 依存関係https://www.geeksforgeeks.org/find-the-ordering-of-tasks-from-given-dependencies/を指定して優先順位を生成するには、30行のc ++コードが必要です。 逆はできません。

もう1つの利点は、依存関係グラフを指定すると、特定のコンテナーを同時に開始できることです。
次の例では、「A-> B、B-> C、D-> C」コンテナBとDは、Cが初期化されている場合、同時に開始できます。 実装がそれをサポートする必要があると言っているわけではありませんが、少なくともAPIでそのような定義が許可されていれば非常に価値があります。

整数の優先度はうまく機能しません。CSSのz-indexプロパティ（ -9999 ）の場合と同じように、標準化されていないさまざまな種類の数値を使用します。

@rubenhakこの時点で提案しているのは、基本的にこのKEPで説明されている機能とはまったく異なる機能であり、小さな調整ではなく、完全に書き直されたものです。 これを再評価するには、以前にこの機能に同意したすべての人（これがすべての関係者によって承認されるまでに1年かかりました）を取得する必要があります。
このような機能に情熱を注いでいる場合は、独自のKEPを作成し、それをさまざまなSIGに渡して、フィードバックをもらうことをお勧めします。

依存関係グラフのアイデアは、この提案が2018年に開始されたときに詳細に議論されました。結論は、いくつかのユースケースを可能にするものの、十分に強力なユースケースではなく、追加された複雑さは価値がないという点で一致していました。

あなたは、あなたが説明していることを実装するために必要な変更の程度をいくらか過小評価していると思います。 ただし、考えているほど単純な場合は、Kubernetesで機能する独自の概念実証を作成し、それをSIGに提示して、ケースを強化することができます。

このKEPはまだGA機能ではありません。KEPが承認されて実装された場合、このKEPを削除できます。 それらはまだ相互に排他的ではありません。

この変更は、すべてのユースケースに最適なソリューションではないかもしれませんが、ほとんどの場合、エクスペリエンスが劇的に向上します。これを統合して、実装についてもう1年間議論する方がはるかに良いと思います。

KEPが承認されて実装された場合、これを削除できます。 それらはまだ相互に排他的ではありません。

それらは相互に排他的でしょうか？

この機能に価値があるかどうかを自問しています。将来、別の拡張機能によって、より明示的なコンテナーの起動/シャットダウンの順序付け（これは素晴らしいと思います）が有効になっている場合でも...そして私はそう思っています。

コンテナをinit、sidecar、または「通常」に分類することによって暗示される起動/シャットダウンの順序は、これらの分類は、コンテナの望ましい動作の_その他_有用で、おそらく無関係な側面も表しますね。

たとえば、 restartPolicy != Alwaysのポッド（おそらくジョブを実装するポッド）では、サイドカーとして指定されたコンテナが、完了状態に入るポッドとは関係がない場合に便利です。

@ kfox1111 、Vaultはサイドカーを使用してシークレットインジェクションを実行するようになりました。 どのクラスに収まる必要がありますか？ また、場合によっては、ボールトはサービスメッシュに依存するか、またはその逆になります。

ボールトのようなものがサイドカー/ initコンテナーを必要としないように、csiエフェメラルドライバーを介して作業しました。 作品にはヴォールトドライバーがいると思います。

emptyDirを備えた通常のサイドカーは、ネットワークサイドカーを使用する必要があるサイドカーに適しているように見えますが？

@ Joseph-Irving、私は決してこのKEPの侵入を阻止しようとしていませんでした。あなたがほぼ2年前に開始し、これがリリースされるのを待っている人がかなりいることを理解しています。

依存関係グラフに関連する以前の議論へのリンクはありますか？

ねえ@ Joseph-Irving、

2020年3月5日のコードフリーズが間もなく終了することをお知らせします。 PRはまだマージされていないようですが、この拡張機能のコードフリーズに向けて順調に進んでいると感じていますか？

ねえ@ jeremyrickard 、APIレビュー（https://github.com/kubernetes/kubernetes/pull/79649）は基本的に行われます。 そのPRを閉じて、実装PRに完全に移行し、すべて（APIと実装）を1つのPRにマージできるようにします。

実装PR（https://github.com/kubernetes/kubernetes/pull/80744）は徹底的にレビューされているため、最終承認を探すためにsig-node承認者を取得しようとしています。

これがコードのフリーズに間に合うように発生するかどうかは、私が言うのはやや難しいです。それは、私が時間内に一部の承認者の注意を引くことができるかどうかに大きく依存します。

これがコードフリーズによって入るのを見たいです。 これにより、 https： //github.com/istio/istio/issues/7136に対するIstioのソリューションがよりシンプルで優れたものになります。

これに関する動きは1.18になりますか？ istioサイドカーが高速実行ジョブで期待どおりに機能するために必要なようです。

さまざまな方法でsig-node承認者に連絡しようとしましたが、応答がありませんでした。 ですから、これで1.18になるとはあまり楽観的ではありません。

@ Joseph-これらのケースのために＃pr-reviewsslackチャネルを作成しました。 あなたはそれを試しましたか？ これは、PRレビューのエスカレーションを取得する方法です。 （私はそこにそれを見ませんでした）

ねえ@ Joseph-Irving、

現在、コードのフリーズからわずか数日です。 レビューアの帯域幅に基づいて、これを1.19に延期しますか？ または、プッシュしてみてください。

ねえ@jeremyrickard 、

これらのPRを1.18に統合することについて、誰も私に返答していないので、それが実現するかどうかは非常に疑わしいです。

1.19まで延期することはできますが、そうすることに意味があるのではないかと思い始めています。
このKEPはほぼ2年間飛行しており（元のアルファターゲットは1.15でした）、問題のPRはほぼ1年間開いており、「レビューアー帯域幅」はありません。
私は丁寧にメールを送り、怠け者で、sig-meetingsに行き、レビューをもらうために直接会う人さえ見つけましたが、私たちはほとんど進歩していません。
私が何とか得たレビューは、マイナーな変更を提案しただけで、大規模な書き換えが要求されたわけではありません。PRはすべて、基本的に1年前と同じです。
毎日積極的に人々にpingを送信するつもりなのかどうかはわかりませんが、それは私が快適に行えることではありません。

問題は、この機能を実際に気にする人がいないことだと思います。この機能を推進しているのは私だけです。SIGの誰も、これを見抜くことに興味を持っていないようです。 アルファ版に移行するのに2年かかる場合、ベータ版/ GAに移行するのにどのくらい時間がかかりますか？ （ほとんどの人が実際にこれを使用できる場合のように）

苛立たしいことに、この機能を導入することに幅広いコミュニティやエンドユーザーから関心が寄せられているようです。そもそもこれを行った理由は、これが問題であると判断し、SIGに修正するかどうかを尋ねたためです。 「私たちには能力がありませんが、あなたがそれをしてくれることを嬉しく思います」と言いました。
それで、彼らが求めたすべてのことを行い、KEPを作成し、すべての関係者に承認され、すべてのコードとすべてのテストを作成し、リリースが通過するたびに常に最新の状態に保ちました。

これを遅らせるたびに、たくさんの人を失望させているような気がしますが、これはすべて私のせいですか？ コードはとてもひどいので、誰もコメントすることはありませんか？ 私は注意を引くのに十分積極的ではありませんか？
私は自分でこれを成し遂げることができないと感じています、そして私はこの死んだ馬を打ち負かすことに少しうんざりしています。

長い怒り（ジェレミーや個人的にはジェレミーに向けられていない）をお詫びしますが、これは長い間私の魂をゆっくりと食い尽くしてきました。

苛立たしいことに、この機能を導入することに幅広いコミュニティやエンドユーザーから関心が寄せられているようです。そもそもこれを行った理由は、これが問題であると判断し、SIGに修正するかどうかを尋ねたためです。 「私たちには能力がありませんが、あなたがそれをしてくれることを嬉しく思います」と言いました。

@ Joseph-Irvingこれについて。 アクティブユーザーとして、私が興味を持っているのでこのスレッドを見てください（そして私の同僚の2人もそうです）。 問題に関するアクティビティ、プルリクエスト、スラックチャネル、またはsigは、この機能に関心のある最良の指標ではない可能性があります。

@dimsたぶんあなたはいくつかの光を当てることができますか？

@ thockin〜1年前にKubernetesポッドキャストでインタビューを受けているのを聞きました。あなたはKubernetesへの貢献について話しました。 たぶん、このサイドカーKEPが1.16に到達しなかったことを本当に悪く感じたのは、あなたか別のポッドキャストエピソードの誰かでした。 さて、ここに再びいます。

この問題は、たとえばの従業員でない場合に貢献することがいかに難しいかを示す代表的な例のようです。 Google、RedHat、またはその他の大手プレーヤー。

Slackでもレビューを依頼しましたが、 @ thockinから明示的な保留があると言われたので、今後の方向性も

私は一時的なcsiドライバー機能に多くの時間を費やしました。 それをやり遂げるのも同様に苛立たしいことであり、多くの遅延と再設計の後でそれがうまくいくかどうか確信が持てなかったことがありました。 だから、私はあなたの痛みを感じます。 痛みを和らげる方法を見つけられたら素晴らしいと思います。 そうは言っても、いくつかのメジャーリリースを逃した後、最終的にはそれを取り入れました。 ですから、あきらめたり、希望を失ったりしないでください！ 船は曲がるのが難しいかもしれませんが、最終的には曲がります。

ネットワークサイドカーに依存するあらゆる種類のトポロジを実行している人は、このKEPが解決する可能性のあるコンテナの起動/シャットダウンの順序の問題に遭遇する可能性があります。 このチケットの「Istio」をCtrl-Fで押すと、コンテナの注文に関連する多くの煩わしさがわかります。

ここにIstioのメンテナはいますか？ 多くはGoogle社員であり、内部的にはK8sの人々にさらに影響を与える可能性があります。

Istio / K8sショップとして、私たちはあなたがこれを上陸させることを絶対に応援しています、@ Joseph-Irving！ ✊❤️

@Josephの称賛-これまでサイドカーを作ってくれたIrving。

サイドカーのライフサイクル管理の場合でも、バッチジョブでこの機能が必要になるか、Kubernetesが機能しないため、コードレビューの支援やフィードバックの提供にも多くの時間を費やしました。

このため、しばらくの間k8sをフォークしてきましたが、このような重要な機能が正式にサポートされるのを本当に楽しみにしています。

Istio + Kubernetesショップとして、この機能も待ち望んでいました。 そして、リリースからリリースへとスリップすることにますます不満を募らせています。 私たちは、仕事の仕事量でサイドカーを殺すためにハックに頼らなければならないことを嬉しく思いません。 私たちのニーズにとって、これは1年以上にわたって、Kubernetesで必要な唯一の最も重要な機能です。

@thockinこれを明示的に保留したことが上記で報告されています。 その理由を教えてください。

これも待ち望んでいるLinkerdユーザーがたくさんいます。 @ Joseph-Irving、私たちはあなたを応援しています。

ここにいる他のみんなが見たかどうかはわかりませんが、kubeconのビデオを掘り下げて見た後、Lyftがこれに似た何かをしたことがわかりました。 kubernetesのフォークからの言及されたコミットは次のとおりです： https ：

Istio + Kubernetesショップとして、この機能も待ち望んでいました。 そして、リリースからリリースへとスリップすることにますます不満を募らせています。

私は潜在的なistioユーザーですが、このような機能を待っているため、少し傍観していました。 しかし、上記の議論の間、私は、ここで議論されているサイドカー機能だけでは、istioサイドカーがワークフローで抱えているすべての問題を解決できないと私に思わせるものを見続けています。 しかし、それは役立つかもしれません。 これが行き詰まった理由の一部だと思います。

istio cniドライバーを使用する場合、サイドカーでistioを実行するとどのように機能しますか？ ネットワークに到達しようとするinitコンテナは、istioのドキュメントに記載されているように正しく機能しないと思います。

したがって、上記の私の質問は、ネットワークサイドカーがそれ自体のものであるかどうかです。

この問題は、たとえばの従業員でない場合に貢献することがいかに難しいかを示す代表的な例のようです。 Google、RedHat、またはその他の大手プレーヤー。

はぁ！ あなたが知らないのは、それらの人々も時々立ち往生しているということです！

真剣に、ごめんなさい。 言い訳はありますが、それはひどいので気にしないでください。

明確にするために：
アプローチに関するフィードバックを得るために、これをアルファとしてマージするべきではないという意味ではありません。 一般的には音だと思います。 サービスメッシュなどのユースケースには、カバーできない穴がいくつかあると思います。 しかし、それはこれをできるだけ早く取得することをブロックする理由ではないので、カバーされていない他のすべてのユースケースを見つけて、機能のベータ版をすべての人にうまく機能させることができます。 それがまさにIMOのアルファです。

私がしたこと、特にこれが既存のサービスメッシュの問題に対する特効薬になることを望んでいる人々に言及しているだけです。 提案されたアルファがその特定の問題を完全に修正するとは思わない。 ですから、まだ期待を高くしすぎないでください。 ただし、まだすべての人をサポートしていないという理由だけで、この機能をブロックしないでください。

例外をリクエストしました。これを取得できるかどうかを見てみましょう。
https://groups.google.com/d/msg/kubernetes-sig-release/RHbkIvAmIGM/nNUthrQsCQAJ

このサイドカーKEPが1.16に到達しなかったことを本当に悪く感じたのは、おそらくあなたか他の[KubernetesPodcast]エピソードの誰かでした。

Lachie EvensonのエピソードGuinevereSaengerのエピソードをご覧ください。 私は今週、この1つの問題を解決するためにPRレビューが必要であることを

ここにIstioのメンテナはいますか？ 多くはGoogle社員であり、内部的にはK8sの人々にさらに影響を与える可能性があります。

@duderinoと@howardjohnは両方ともこのスレッドにすでにコメントしています。

明確にするために、マージする必要があります。
kubernetes / kubernetes＃79649
kubernetes / kubernetes＃80744

追跡する必要のある他のPRはありますか？

ありがとう！

• 拡張チーム

（公的または私的に）サポートのメッセージを投稿してくれたすべての人に感謝します❤️

延長リクエストを受け入れたリリースチームを含め、コミュニティのメンバーがこれを1.18にしようと勇敢に努力しましたが、残念ながら、これを1.19に延期することが決定されました。 このコメントから始まる関連する会話を見ることができます： https ：//github.com/kubernetes/kubernetes/pull/80744#issuecomment-595292034。

1.18にはなっていませんが、ここ数日はかなりの注目を集めており、この勢いが1.19に引き継がれることを期待しています。

cc @ jeremyrickard 、 @ kikisdeliveryservice

素晴らしいもの@ Joseph-Irving、あなたの欲求不満のいくつかは価値があり、聞いていたようです。 頑張ってくれてありがとう。

/ milestone v1.19

こんにちは、みんな。 私たちのグループは先週このトピックについて話し合っています。

まず、ここで起こったことをお詫びします。 私たちはそれについて満足していません。

このPRと関連するKEPは、プロジェクトがより良くできる多くのことを明らかにしました。 私たちは、社会的、手続き的、および技術的な懸念を分離したいと思います。

社会的には、この機能はお互いを喜ばせたいという私たちの欲求の犠牲になりました。 デレクは、SIG内で留保が表明されたにもかかわらず、クレイトンとティムがKEPを推進していたため、KEPを承認しました。 私たちは皆、お互いを信頼していますが、「ノー」と言えるとは限らないようです。 私たちは皆、まったく同じことをしたので、これを知っています。 私たちの誰もが次の素晴らしいアイデアの妨げになりたくありません。

お互いを信頼することには、私たちが「いいえ」と言えることを信頼することと、誰かが「いいえ」と言うとき、彼らが正当な理由でそうしていることを信頼することが含まれなければなりません。 この技術分野はSIGにまたがっており、最終的に問題を解決するためのsig-nodeに、まだサポートしにくい新機能を受け入れるように圧力をかけるべきではありません。これは、特にTim、Derek、Claytonに関するものではありません。しかし、すべての高レベルの承認者とSIGのリードおよび「上級」の貢献者。

この機能は、KEPに関する手続き上の不確実性の犠牲にもなりました。 KEPレビュアーとして、私はコードレビュアーになる義務がありますか？ コードレビューアに委任するには？ または単にKEPを読むために？ KEPはリリースにまたがっていますが、リリースの特定のスパンで予算化された一連の変更にシェパードが使用可能であることをどのように確認しますか。 KEPがSIGにまたがる場合、SIG全体に時間をどのように割り当てて割り当てるのですか？ これを明確にする必要があります。 KEPプロセスでの役割の定義を強化するために、いくつかのKEP変更提案（KEP KEP）に取り組みます。

技術的には、この機能は時間と注意の両方の犠牲になりました。 レビューアはそれをレビューするのに十分な時間をとらなかったか、単に彼らにとって十分に高い優先度ではありませんでした。 前後の議論には時間がかかります。 状況と問題空間に対する私たちの理解は時間とともに変化します。

より多くのユーザーがKubernetesを採用するにつれて、sig-nodeに報告される奇妙なエッジケースやフレークの数が増えています。 ポッドのライフサイクルはKubernetesの中核であるため、そのサブシステムに加えられた変更は慎重に行う必要があります。 新しい機能をマージする能力は、信頼性を向上させたいという私たちの願望とバランスを取る必要があります。 今日のポッドのライフサイクルについての考え方は、この機能が開始されたときの考え方とは少し異なります。 これにより、これに至るまでのユースケースが減ることはありませんが、長期にわたるKEPを定期的に再検討する必要があることを示唆しています。

ポッドのライフサイクルについて考えて、少し第一原理を実行する必要があると思います。 本当に何が欲しいの？ あまり複雑にならないように努めましたが、その複雑さを複数のフェーズに分割しただけであり、最終的な結果は、正面から取り組むよりも複雑になる可能性があります。

これは、このPRおよび関連するKEPにとって何を意味しますか？ 100％確実ではありません。 しかし、それはおそらくこれをまだ押し通すべきではないことを意味します。

デレクは、シャットダウンシーケンスに関していくつかの懸念を提起しました。 KEPは今のところそれらを範囲外と呼んでいますが、多少の躊躇があります。 ノードのシャットダウン時の正常な終了はすでに尊重されておらず、多くのユーザーを驚かせています。 それはこのKEPのせいではありませんが、それを「酌量すべき状況」と呼びましょう。 誰かがサイドカーを使用してポッドを「クリーンアップ」する場合（たとえば、キャッシュされたログをログサービスに排出するため）、シャットダウンに関する明確で有用なセマンティクスを（合理的に）期待しますが、このKEPは保証しません。

ティムは、初期サイドカーが物になる必要があるのではないかと懸念していますが、それは正しくないと感じています。 彼は過去にその懸念を放棄しましたが、それでも彼を悩ませています。

ポッドライフサイクルの中期的な目標と、それを実行するための彼らの欲求を定義するのに役立つSIGノードが必要です。 これが目標に向けた段階的なステップは、ブロックを解除できますが、目標がわからない限り、ヘッドライトを過剰に運転している可能性があります。

これが悪臭を放つと私たち全員が最初に言いましょう。 私たちは本当の問題の声明、情熱的な貢献者、そして善意のあるメンテナのセットを持っています、そして私たちは結局...ここにいます。 ティムはブレインストーミングとデザインを手伝うために彼の時間をボランティアで提供します。 Derekは、現在のポッドライフサイクルのノードシャットダウン作業をプッシュして、ポッドをさらに成長させるための安定した基盤を確保します。 計画外のマシン障害が発生した場合に、何が保証され、何が保証されないかを慎重に指定する必要があります。

ありがとう、
クレイトン、デビッド、ドーン、デレク、ジョン、ティム

デレクまたはドーン-より全体的なポッドとコンテナのライフサイクルについてブレインストーミングを行う時間を作ることができるシグノードはありますか？

@thockinは、これをsig-nodeアジェンダに追加します。

@ thockin @ derekwaynecarrこれがうまくいかなかった理由についてのtl; drは何ですか？

1行の機能強化の説明：コンテナをサイドカーとしてマークできるようになり、通常のコンテナの前に起動し、他のすべてのコンテナが終了した後にシャットダウンできるようになりました。

サービスメッシュサイドカーのこの新しい時代の生活を楽にする何かのように聞こえます。

さらに、サイドカーをメインアプリコンテナーの前に開始し、メインアプリコンテナーの終了後にシャットダウンするための推奨事項はありますか？

...なぜこれが入らなかったのかについてのtl; drは何ですか？

@naseemkullahhttps ： //github.com/kubernetes/enhancements/issues/753#issuecomment-597372056から...👇

これは、このPRおよび関連するKEPにとって何を意味しますか？ 100％確実ではありません。 しかし、それはおそらくこれをまだ押し通すべきではないことを意味します。

デレクは、シャットダウンシーケンスに関していくつかの懸念を提起しました。 KEPは今のところそれらを範囲外と呼んでいますが、多少の躊躇があります。 ノードのシャットダウン時の正常な終了はすでに尊重されておらず、多くのユーザーを驚かせています。 それはこのKEPのせいではありませんが、それを「酌量すべき状況」と呼びましょう。 誰かがサイドカーを使用してポッドを「クリーンアップ」する場合（たとえば、キャッシュされたログをログサービスに排出するため）、シャットダウンに関する明確で有用なセマンティクスを（合理的に）期待しますが、このKEPは保証しません。

[...]

ポッドライフサイクルの中期的な目標と、それを実行するための彼らの欲求を定義するのに役立つSIGノードが必要です。 これが目標に向けた段階的なステップであることに同意できれば、ブロックを解除できますが、目標がわからない限り、ヘッドライトを過剰に運転している可能性があります。

敬意を表して、私はリードがこれを整理することを優先することを計画しているかどうかについて興味があります。 @ Joseph-Irvingはこれに膨大な量の作業を投入し、彼の解決策に満足していたであろう驚異的な数の人々が、これを否定した人々からいくつかの優れた解決策を聞くことを切望しています。

最低限、いくつかの側面がある問題がありますが、実際にどのような問題が発生するかを見つけるために、アルファとして参加することは依然として合理的だと思います。 これをマージできますか？ 問題がベータ版への移行を妨げる可能性があるため、最初のアルファ版が作成される前に完璧になることは重要ではないと思います。

これをsig-nodeアジェンダに追加します。

@thockin @derekwaynecarrこれの現在の状態に関する更新はありますか？ sig-nodeミーティングノートを調べましたが、これについては何もわかりません。

多くのユースケースにとって重要であるため、このスレッドには多くの開発者がいて、これを実装するために時間を割いて喜んで貢献します（KEP自体には他のKEPの2.5倍の：+1：があります）。 これを実現するために何ができるでしょうか。 この領域の安定性の前提条件のリストがあれば、達成するために多くのリリースにまたがる可能性がありますが、積極的に取り組み始めることができれば、現在の状況から大幅に改善されます。

こんにちは@ Joseph-Irving @ thockin @khenidak @ kow3ns -1.19拡張機能ここをリードします。この拡張機能が1.19で卒業すると思われる場合は、チェックインしたいと思いますか？

リリースのこの部分を使用するには、次のようにします。

1. KEP PRは、実装可能な状態でマージする必要があります
2. KEPにはテスト計画が必要です
3. KEPには卒業基準が必要です。

現在のリリーススケジュールは次のとおりです。

• 4月13日月曜日：第1週-リリースサイクルが始まります
• 5月19日火曜日：第6週-拡張機能のフリーズ
• 6月25日木曜日：第11週-コードフリーズ
• 7月9日木曜日：第14週-ドキュメントを完成させて確認する必要があります
• 8月4日火曜日：第17週-Kubernetesv1.19.0がリリースされました

@palnabarun 、このコメントhttps://github.com/kubernetes/enhancements/issues/753#issuecomment -597372056によると、このKEPは無期限に保留されているため、1.19で卒業することはありません。

状況を明らかにしてくれた@ Joseph-Irvingに感謝します。 ：+1：

あなたの努力に感謝します！

これを取り入れたいと思っているすべての人に、そして再び@ Joseph-Irvingに-私は個人的にこの状況を非常に残念に思っています。 私もこれ（またはそのようなもの）が欲しいのですが、実際のところ、sig-nodeは現在、人々よりもやるべきことが多く、彼らはこれを検討する準備ができていません。

最悪だ。 わかった。 私は本当にそうします。

人々が助けることができる最善の方法は、コードレビューを行い、トリアージを発行し、バグとテストを修正し、sig-nodeの専門家がより多くの容量を持ち、そのような変更を行うことへの自信。

sig-nodeには、今やるべき人よりもやるべきことがたくさんあります

了解した。 私たちは、sig-nodeの容量ニーズを社内で強調して推進してきました。 私たちは、sig-node OSSボランティアを招き、指導しています。一部のボランティアは、この分野で働きたいという願望を持って、新しい経験を積んでいます（これまでのところ4人）。 私はあなたのコメント@thockinに引用します、ありがとう！

/マイルストーンクリア

人々が助けることができる最善の方法は、コードレビューを行い、トリアージを発行し、バグとテストを修正し、sig-nodeの専門家がより多くの容量を持ち、そのような変更を行うことへの自信。

@thockinリポジトリ、メーリングリスト、ガイドなどのリンクを提供して

@ tariq1890このKEPを書いている人々は、すべてを正しく行っています。 彼らは石を回さずに残していません。 ここでの問題はまさに@thockinが言ったことです。最初に修正する必要のある技術的負債があり、これを検討する前にそのための手が必要です。 ですから、人々が何をする必要があるかを手伝ってくれるように頼むのです。

こちらの最新のアップデートをご覧ください： https ：

@dims私は誤解されてきたと思います。 私が言いたかったのは、実行可能な目標と目標のリストが必要だということです。 対処すべき技術的負債がある場合は、GitHubマイルストーンを維持するか、OPコメントで保留中のアクションアイテムの箇条書きリストを提供して、この問題にアクセスする人々が対処する必要があることをすぐに知ることができるようにすることができます。

私は間違いなくこのKEPを進めることでsig / nodeに私の助けを提供するつもりですが、方法がわかりません

@ tariq1890具体的な質問は次のとおりです：「（まだ送信されていないKEP）kubeletノードのグレースフルシャットダウンの前提条件」 https://github.com/kubernetes/enhancements/pull/1874/files#diff -c6212b56619f2b462935ad5f631d772fR94

それを始める必要があります。 誰かがポイントを取り、それを実行する必要があります。

-薄暗い

したがって、この問題の関係者のhttps://github.com/kubernetes/enhancements/pull/1874を要約し
そのため、ノード終了のソリューションが実装されるまで、この機能は進行しないことが決定されました。
現在ここにグーグルドキュメントがあります： https ：
これにはこの問題に関する多くの議論が含まれていますが、このためのKEPはまだ提出されていません。
まだ未解決の質問があるので、そこにコメントすることは役立つかもしれません。 @ bobbypageと@mrunalpがこの取り組みを主導していると

@ Joseph-Irvingは要約してくれてありがとう。 この拡張機能のすべての+ veエネルギーが、機能の1回限りではなく、定期的にsig-nodeのすべての人からの参加につながることを願っています。 やるべきことはたくさんあり、手はほとんどありません。

やあ！ ただし、このKEPに関するもう1つのコメント：過去のSIGノード会議（録音を視聴したい場合は6月23日）でこのKEPに関するいくつかのエッジケースを提起し、その議論を継続する適切な方法は、それらに関するPRを開くことであると判断しました。問題を解決して、どのように進めるのが最善かを判断できるようにします。

私は現在、これらの問題と私が考えることができるいくつかの代替案を述べるためにPRに取り組んでいます。

また、KEPの状態は（実装可能ではなく）暫定的なものになっているため、すべての人がKEPを快適に進めることができると同意した場合にのみ、レビューして再度実装可能に設定できます。

この号で欠けている情報はこれだけだったと思います。 ありがとう！

@rata問題を処理する適切な方法で問題/ PRを開きましたか？

@mattfarinaこれはPRですhttps://github.com/kubernetes/enhancements/pull/1913
これには、KEPの現在の問題/エッジケースに対する提案されたソリューションの数が含まれています
また、特定の決定が行われた理由のより良いログが得られるように、議論され、反対されたいくつかの代替案の詳細が含まれています。

サイドカーの機能がスケーリングもカバーすることを強く望んでいます。
現在、HPAスケーリングはメトリック（CPUなど）に基づいています。 ポッドに複数のコンテナーが含まれている場合は、すべてのコンテナーの平均が使用されます（私が知る限り）。 サイドカー（app + nginxなど）を備えたポッドの場合、これによりスケーリング機能を正しく作成することが非常に困難になります。 Kubernetesでのサイドカーの実装に、HPAスケーリングに使用されるメトリックの観点から、ポッド内の1つのコンテナーを「信頼できる」ものとしてマークすることが含まれることを期待していました。

サイドカーの機能がスケーリングもカバーすることを強く望んでいます。

これは便利ですが、必ずしも「サイドカー」固有ではないことに同意します。実装はこれから切り離されているため、別の問題にするのが理にかなっている場合があります。これはすでに非常に複雑です。 私はまた、あなたがサイドカーを無視したいと思っているとは確信していません。 たとえば、代わりにコンテナごとのHPAスケーリングが必要になる場合があります。 わからない-私が思うに、それ自体の問題として調査する必要があるだろう。

特にIstioEnvoyサイドカーの場合、この問題の現在の回避策について誰かが言及している、または共有するのがとても親切である可能性がありますか？

私は以下を含む可能な回避策を思い出します：

• SIGTERMを無視するカスタムEnvoyイメージ。
• シャットダウン時にアプリケーションコンテナ内からEnvoyで/ quitquitquitを呼び出す（ジョブ完了の回避策と同様）

特にIstioEnvoyサイドカーの場合、この問題の現在の回避策について誰かが言及している、または共有するのがとても親切である可能性がありますか？

supervisorようなカスタムデーモンイメージを使用して、ユーザーのプログラムをラップします。 デーモンはまた、特定のポートをリッスンして、ユーザーのプログラムの正常性ステータス（終了したかどうか）を伝えます。

回避策は次のとおりです。

• デーモンイメージをinitContainersとして使用して、バイナリを共有ボリュームにコピーします。
• CDはユーザーのコマンドを乗っ取り、デーモンを最初に起動させます。 次に、デーモンはEnvoyの準備ができるまでユーザーのプログラムを実行します。
• また、デーモンのヘルスステータスをチェックし続けるスクリプトであるpreStopをEnvoyに追加します。

その結果、Envoyの準備ができている場合はユーザーのプロセスが開始され、ユーザーのプロセスが終了するとEnvoyは停止します。

これは複雑な回避策ですが、本番環境では正常に機能します。

説明のリンクは404を与えます

https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0753-sidecarcontainers.md

私はそれがすべきだと思います：

https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0753-sidecarcontainers.md

ええ、それはhttps://github.com/kubernetes/enhancements/pull/1913で移動されました、私はリンクを更新しました

特にIstioEnvoyサイドカーの場合、この問題の現在の回避策について誰かが言及している、または共有するのがとても親切である可能性がありますか？

スタートアップの問題について@shaneqldは、istioコミュニティが非常に巧妙な回避策を考え出しました。これは、基本的に、コンテナリストの最初のコンテナとしてエンボイを挿入し、エンボイの準備ができるのをチェックして待機するpostStartフックを追加します。 これはブロックされており、他のコンテナーは開始されていません。アプリコンテナーを開始する前に、エンボイがそこにあり、準備ができていることを確認してください。

これを実行中のバージョンに移植する必要がありましたが、非常に簡単で、これまでの結果に満足しています。

シャットダウンについても、preStopフックで「解決」していますが、SIGTERMを続行する前に、アプリケーションが正常にシャットダウンすることを期待する任意のスリープを追加しています。

関連PR： https ：

こんにちは@ Joseph-Irving @ thockinと他のみんな：smile：

拡張機能はここをリードします。 まだたくさんの会話が続いているようですが、進捗状況を追跡できるように、1.20にこれを含める予定がある場合はお知らせください。

ありがとう！
キルステン

@kikisdeliveryserviceはあなたを投稿し続けます、ありがとう！

特にIstioEnvoyサイドカーの場合、この問題の現在の回避策について誰かが言及している、または共有するのがとても親切である可能性がありますか？

スタートアップの問題について@shaneqldは、istioコミュニティが非常に巧妙な回避策を考え出しました。これは、基本的に、コンテナリストの最初のコンテナとしてエンボイを挿入し、エンボイの準備ができるのをチェックして待機するpostStartフックを追加します。 これはブロックされており、他のコンテナーは開始されていません。アプリコンテナーを開始する前に、エンボイがそこにあり、準備ができていることを確認してください。

これを実行中のバージョンに移植する必要がありましたが、非常に簡単で、これまでの結果に満足しています。

シャットダウンについても、preStopフックで「解決」していますが、SIGTERMを続行する前に、アプリケーションが正常にシャットダウンすることを期待する任意のスリープを追加しています。

これらを行う方法について、いくつかの洞察を詳しく示していただけますか？ Istio-proxyサイドカーに「pre-stop」を追加するにはどうすればよいですか？ カスタム構成が必要か、カスタムサイドカーを使用しているようです。 ポッドが縮小すると、メインコンテナがジョブを終了しようとしますが、SIGTERMの直後にIstioサイドカーが閉じたためか、外部への接続が失われるという同じ問題に直面します。 今はデフォルトのサイドカーインジェクションを使用しています。 ありがとうございました！

このスレッドはハイジャックされています。 話題にとどまりましょう。

エンハンスメントフリーズは来週の10月6日火曜日です。 その時までに、KEPを更新して実装可能としてマークする必要があります。

また、KEPは古い形式を使用しているため、更新は素晴らしいでしょう（詳細を打ち出し終えたら）： https ：

@kikisdeliveryservice残りに感謝します。 1.20に含まれることが決定された場合に行います。 ありがとう！ :)

これは1.20の一部にはなりません。 pingしてくれてありがとう！ :)

私はこの問題に興味があり、@ Joseph-Irvingと@howardjohnの両方に、これに関する洞察を提供してくれたことに感謝したいと思います。これは、私の質問のいくつかを解決するのに役立ちました。

この提案をハイジャックしたくはありませんが、上記の会話に基づいて、これはこれまでに認識されていたよりも少し広い/大きな問題ではないかと思います。

私はこの問題に対する次の解決策を想像することができます-

1. initContainersの後、「メインコンテナ」の前に開始し、「メインコンテナ」が終了した後に終了する、新しいコンテナエンティティ「サイドカーコンテナ」を定義します（@ Joseph-Irvingの元の提案による）
2. @luksaの提案に従って、「サイドカーコンテナ」がinitContainerの前に開始するかどうかを設定する追加のフィールドを（1）に定義します。
3. 広く行きなさい。

個人的には、オプション（2）は私の当面の問題を解決します。

しかし、これらの質問が、スケジューリングとポッドの定義方法に関するK8sのより戦略的な問題を語っていないのではないかと思います。 私の特定の（Istio関連の）ケースでは、ポッド内のランレベルのようなものを提案しました。

オプション（2）も私の問題を解決しますが、ポッド/ステートフルセット/デーモンセット/その他にコンテナ依存関係のDAGを埋め込む必要がある、さらに複雑な依存関係構造を想像できます。これは、私が考えているオプション（3）です。

より一般的なものを作成するために、この問題をポッド定義自体に再び焦点を当てるべきかどうか疑問に思っていますか？ 私はもともとランレベルのアナロジーの観点から考えていましたが、おそらくAirflowのようなDAG構造が最も広い適用性を持っているでしょう。

エンボイをinitコンテナとして追加するのはどうですか？ このようにして、他のinitコンテナにネットワークを提供します。 initが終了すると、「exit 0」も終了し、通常の使節（initではない）が引き継ぎます。

@michalzxc私が間違っていなければ、initコンテナは1つずつ順番に実行されるため、現在、別のコンテナの隣にinit-containerとして使節を置くことはできません。

やあ！

サイドカーの議論はこの場所で続けられました（私はsig-node slack、これを開始したgithub PR、およびいくつかのメーリングリストを更新しました）：
https://groups.google.com/g/kubernetes-sig-node/c/w019G3R5VsQ/m/bbRDZTv5CAAJ
https://groups.google.com/g/kubernetes-sig-node/c/7kUaX-jBN3M/m/dhI3E8LOAAAJ

ご覧のとおり、現在、ユースケースを収集しています。さらにいくつかのユースケースを作成した後、さまざまな小グループがそれらに対処する事前提案を作成できます。 ユースケースを自由に追加するか（まだ存在しない場合）、後で事前提案の部分に参加してください:-)

どうか、このエンハンスメントの問題をトピックに留めておきましょう（そしておそらくクローズされます）。 あなたはそれらの場所での会話に参加することを歓迎します:)

このKEPは進行せず、Sig-nodeやその他の人々は、これは正しい方向への段階的なステップではないと感じているため、設計図に戻り、すべての使用法を解決できる新しいKEPをいくつか考案する予定です。このKEPおよび他のケースに記載されているケース。

@rataの以前のコメントをご覧くださいhttps://github.com/kubernetes/enhancements/issues/753#issuecomment-707014341
あなたが議論に貢献できる場所のために。

このKEPで行われたすべての作業が使用されないのは残念ですが、より多くの人々がこれらの問題について考えているので、彼らが思いついた解決策がすべての人にとって最善になることを願っています。
私はすでに2年以上これを乗り越えようとしてきたので、これは私が先に進むのに良い時期だと思います。

/選ぶ

@ Joseph-Irving：この問題を解決します。