@derekwaynecarr @sttts @erictuneはこの問題を

@stttsドキュメントとPRへの適切なリンクを提供できますか？ 私はあなたがこのコードに最も近いと思います。

@ pweil- @sttts -我々の議論ごとに、これは我々が@ kubernetes / SIG-ノードの下Kubernetes 1.6にスポンサーしたい機能です

@ pweil- @derekwaynecarr 、この機能を1.6マイルストーンに設定する必要があることを確認してください。

@ idvoretskyi1.6のベータ版に移行することを目標としています。

@stttsありがとう。

これはまだアルファのようです：

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/seccomp.md
https://github.com/kubernetes/kubernetes/blob/master/pkg/api/annotation_key_constants.go#L35

また、kubernetes.io / docsにドキュメントが見つかりませんでした。

@ pweil- 1.8のアップデートはありますか？ この機能はまだリリースに向けて順調に進んでいますか？

@idvoretskyiこれは1.8の優先事項ではありませんでした。 @ php-coder PM計画のために、これにカードを追加できますか？ これをクラックに陥らせるのをやめ、ベータ版とGAに移行する必要があります。

@ pweil-この機能が1.8で計画されていない場合は、マイルストーンを「次のマイルストーン」または「1.9」で更新してください

これがベータ版になるのを見たいです。 そのための優先順位（または要件）には、次のものが含まれます。

1. アノテーション（Pod＆PodSecurityPolicy）は、コンテナーSecurityContextフィールドに移動する必要があります（https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md#alpha-field-を参照）既存のAPIバージョン）
2. OCI仕様のseccomp形式を決定し、Kubernetesのデフォルトプロファイルを定義します（Dockerを再利用できますか？） https://github.com/kubernetes/kubernetes/issues/39128
   NS。 KubernetesプロファイルがCRIを介してコンテナランタイムにどのように配信されるかを理解します（/ cc @yujuhong @ Random-Liu）
   NS。 ランタイムがdockerの場合、 docker/defaultは引き続き許可されます（下位互換性のため）
3. Kubernetesのデフォルトプロファイルを新しいデフォルトにする必要があります。 下位互換性のために、これはオプションの動作である必要があります（つまり、フラグ制御）。 https://github.com/kubernetes/kubernetes/issues/39845

1.9（または1.10）マイルストーンでこの作業を推進することに興味がある人はいますか？ @jessfraz @ kubernetes / sig-auth-feature-requestsおよび@kubernetes / sig-node-feature-requests私はあなたを見ています：wink：

関連項目： https ：

/ cc @destijl

誰かが時間があり、それをやりたいと思っているなら、彼らは大歓迎です、そして私は
どんな質問にも答えるのに役立ちます

2017年9月22日20:54、「Tim Allclair（St.Clair）」 [email protected]
書きました：

/ cc @destijl https://github.com/destijl

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

わかりました。他に誰もいない場合は、提案を更新して明日から開始します;）

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間非アクティブになると腐敗し、最終的には閉じます。

/lifecycle frozenコメントを使用して、問題が自動終了しないようにします。

この問題を今すぐ解決できる場合は、 /close 。

sig-testing、kubernetes / test-infra、および/または@fejtaフィードバックを送信します。
/ lifecycle stale

ねえ@jessfrazあなたがこれについてどこかに行ったかどうかわからない-私はそれをコーディングするための帯域幅を持っていませんが、テストを手伝って幸せです...

古くなった問題は、30日間操作がないと腐敗します。
/remove-lifecycle rottenして、問題を新規としてマークします。
腐った問題は、さらに30日間操作がないと終了します。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ライフサイクル腐敗
/ remove-lifecyclestale

腐った問題は、30日間操作がないと終了します。
/reopen問題を再開します。
/remove-lifecycle rottenして、問題を新規としてマークします。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/選ぶ

/ reopen
/ライフサイクル凍結
/ remove-lifecycle rotten

@ php-coder：作成したか、割り当てられていない限り、課題/ PRを再度開くことはできません。

/ reopen
/ライフサイクル凍結

7:07で月、2018年3月26日には、K8S-CI-ロボット[email protected]
書きました：

@ php-coder https://github.com/php-coder ：問題/ PRを再度開くことはできません
あなたがそれを作成したか、あなたがそれに割り当てられていない限り。

これに応えて
https://github.com/kubernetes/features/issues/135#issuecomment-376129291
：

/ reopen
/ライフサイクル凍結
/ remove-lifecycle rotten

PRコメントを使用して私とやり取りするための手順はこちらから入手できます
https://git.k8s.io/community/contributors/devel/pull-requests.md 。 もしも
私の行動に関連する質問や提案がありましたら、
kubernetes / test-infraに対する問題
https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue：
リポジトリ。

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

@smarterclayton ：作成したか、割り当てられていない限り、課題/ PRを再度開くことはできません。

/ reopen

@idvoretskyi ：作成したか、割り当てられていない限り、課題/ PRを再度開くことはできません。

Ihor 1、ボット0

@ pweil- @ php-coder @jessfraz
1.11でこれについて何か計画はありますか？

もしそうなら、あなたはその機能が適切なもので最新であることを確認してください：

• 説明
• マイルストーン
• 譲受人
• ラベル：
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

@ wangzhen127は現在取り組んでいますが、まだメンバーではないため、割り当てることができません。

https://github.com/kubernetes/kubernetes/pull/62662
https://github.com/kubernetes/kubernetes/pull/62671

更新してくれてありがとう、ティム！
/ remove-ライフサイクルが凍結されました

@ pweil- @tallclair -私たちは、の1回の以上の掃引やっているスプレッドシートを追跡1.11特長。
この機能の広告申込情報の不完全な/空白のフィールドに入力していただけませんか。

@ pweil- @tallclair -何の更新が進行しないか、ドキュメントWRTがあったとして、この機能は、1.11マイルストーンから削除されました。

cc： @jberkus

@ pweil- @tallclair @ kubernetes / sig-auth-feature-requests @ kubernetes / sig-node-feature-requests-

この機能は以前のマイルストーンから削除されたため、チェックインして、Kubernetes1.12でこの機能の計画があるかどうかを確認したいと思います。

その場合は、次のすべての情報を使用して、この問題が最新であることを確認してください。

• 1行の機能の説明（リリースノートとして使用できます）：
• 主な連絡先（譲受人）：
• 責任あるSIG：
• デザイン提案リンク（コミュニティリポジトリ）：
• e2eおよび/またはユニットテストへのリンク：
• レビュー担当者-（LGTMの場合）2人以上のレビュー担当者（コード領域のOWNERSファイルから少なくとも1人）にレビューに同意してもらうことをお勧めします。 複数の企業のレビュー担当者が優先：
• 承認者（機能が属するSIG /エリアからの可能性が高い）：
• 機能ターゲット（どのターゲットがどのマイルストーンに等しいか）：
  
  
  
  • アルファリリースターゲット（xy）
  
  
  • ベータリリースターゲット（xy）
  
  
  • 安定したリリースターゲット（xy）
  
  

機能のフリーズは7月31日であり、それ以降、機能の問題が不完全な場合は、マイルストーンに例外リクエストを受け入れる必要があり

さらに、次の関連する期限に注意してください。

• ドキュメントの締め切り（オープンプレースホルダーPR）：8/21
• テストケースのフリーズ：8/28

機能のすべてのPRに、関連するリリースノートも含まれていることを確認してください。

ハッピーシッピング！

/ cc @justaugustus @ kacole2 @robertsandoval @ rajendar38

1.12の変更は予定されていません

更新してくれてありがとう、@ tallclair！

1.9（または1.10）マイルストーンでこの作業を推進することに興味がある人はいますか？ @jessfraz @ kubernetes / sig-auth-feature-requestsおよび@kubernetes / sig-node-feature-requests私はあなたを見ていますウィンク

@tallclairそれでも望ましい場合は、今すぐこれを拾うことができます

@stlaz ：通知をトリガーするために言及を繰り返します：
@ kubernetes / sig-auth-feature-requests、@ kubernetes / sig-node-feature-requests

@stlaz 、この機能はまだ必要です。 ＃39845の最初のステップとして、アドオンにseccompプロファイルを追加することに時間を費やしました。 しかし、この機能をプッシュするのに十分な時間がありません。 あなたがこれに取り組むのが好きならそれは素晴らしいでしょう。 どんな助けでも大歓迎です！ :)

@ wangzhen127ありがとう、私はこの機能に関連して行われたことと開かれた問題をhttps://github.com/kubernetes/features/issues/135#issuecomment-331592961はまだ保持されており、今実行する必要のある作業を正確に要約しているようです。

また、これにFeatureGateを追加しようとしていることに気づきましたが、PRを閉じました。それはなぜですか？

PS：応答が遅れて申し訳ありませんが、私は少し不在でした。

コメント＃135（コメント）はまだ保持されており、今実行する必要のある作業を正確に要約しているように思われます。

そうです。 私が追加したいもう一つのことは、「苦情」モードを持つことです。 そのため、ユーザーは、強制終了するのではなく、禁止されているシステムコールを使用するという警告を（ログで）取得することを選択できます。 ロギングseccompアクションは、Linuxカーネル4.14以降（ seccomp doc ）で使用できます。 古いカーネルバージョンがまだ使用されている可能性があります。 したがって、それを処理する必要があります。 これもOCI仕様に追加する必要があります。

また、これにFeatureGateを追加しようとしていることに気づきましたが、PRを閉じました。それはなぜですか？

この機能ゲートの目的は、seccompのデフォルトプロファイルを非制限から「ランタイム/デフォルト」に変更することでした。 下位互換性について多くの懸念があったので、そうなる可能性は低いようでした。 現在、セキュリティのデフォルトが壊れているため、一般的にセキュリティのデフォルトを変更する計画はありません。 私が現在考えている最善のアプローチは、seccompを安定させることですが、それでもオプトアウトではなくオプトイン機能である必要があります。

ロギングseccompアクションは、Linuxカーネル4.14以降（ seccomp doc ）で使用できます。

2番目のステップの一部としてKubernetes固有のデフォルトのseccomp形式を定義するので、代わりにログを記録する形式を使用することもできます。 それには十分な価値がありますか？ 後者が失敗しすぎたときに、人々が「制限なし」から「kube / default」に移行するために使用できますか？ 彼らはそれがスイッチからスイッチバックに切り替わるのを気にかけますか？
4.13- Linuxカーネル（Debian-8,9; RHEL-6,7; Ubuntu LTS-14.04,16.04）を使用するLTSディストリビューションがあるので、カーネルの互換性は間違いなく覚えておくべきものです。

下位互換性について多くの懸念があったので、そうなる可能性は低いようでした。

コンテナランタイムは、seccompを初めて有効にするときに、過去にもこの変更を行う必要がありました。 現在、少なくともdockerは、誰かを壊した可能性のある「制限なし」よりも許可されていないデフォルトの動作で出荷されます。 基盤となるコンポーネントの動作（この動作をオフにする選択肢も提供します）に従うだけで、何も悪いことをしているとは思いません。

それには十分な価値がありますか？

これは議論することができます。 私の当初の考えは、デフォルトを制限なしからロギングに変更することでした。 したがって、下位互換性の問題はありません。 そして、なんらかの方法でデータを収集し、X％のケースで何もログに記録されていないことを示すことができれば、デフォルトのプロファイルで問題が発生することはありません。 次に、ログをkillに変更することを提案できます。 データ部分の収集はトリッキーで、多くの作業になる可能性があります。 私たちが実際にそのルートに行かなくても、ロギングプロファイルを持つことは、seccompを試してみたいが、まだ自信がない場合に役立つと思います。

コンテナランタイムは、seccompを初めて有効にするときに、過去にもこの変更を行う必要がありました。 現在、少なくともdockerは、誰かを壊した可能性のある「制限なし」よりも許可されていないデフォルトの動作で出荷されます。 基盤となるコンポーネントの動作（この動作をオフにする選択肢も提供します）に従うだけで、何も悪いことをしているとは思いません。

dockerがデフォルト値を変更すると、kubernetesはそのような値を明示的にunconfinedにリセットします。 私は以前にオフラインでsig-architectureの人々に連絡を取りましたが、彼らは下位互換性の問題について非常に心配しています。

そして、なんらかの方法でデータを収集し、X％のケースで何もログに記録されていないことを示すことができれば、デフォルトのプロファイルで問題が発生することはありません。

私はこの考えが好きです。 難しいのはもちろんデータを取得することです。どうやってデータを取得するのかわかりません。 また、最初にこの変更をOCI仕様に提案してから、少なくとも1つのコンテナーランタイムに実装する必要がありますね。 ライフサイクルのベータ部分でそれが発生しても問題ありませんか？

dockerがデフォルト値を変更すると、kubernetesはそのような値を明示的にunconfinedにリセットします。 私は以前にオフラインでsig-architectureの人々に連絡を取りましたが、彼らは下位互換性の問題について非常に心配しています。

分かりました。 おそらく、デフォルトのプロファイルとして「制限されていない」プロファイルを使用することもできます（後でkube/loggingようなものに置き換える可能性があります）。 その場合、これは拒否ルールの方法でPSPによって制御される可能性があるようです。ここでは、すべてがデフォルトで許可されているという前提から始めて、特権をさらに削減するだけです。 これをフラグで制御することは、PSPがオフになっている場合に役立つ可能性があります。そのため、PSPも使用する必要がありますが、これら2つのメカニズムを同時に使用するのは少し面倒です。

当初考えていた方向とは少し違うと思います。https：//github.com/kubernetes/kubernetes/issues/39845で行われた作業に反しruntime/default 、 kube/default 、 kube/loggingと、プロファイルをunconfinedに設定するオプションが表示されています。 残りはもちろん、現在の実装によってすでに提供されているlocalhost/.*プロファイルを持つ機能です。

ライフサイクルのベータ部分でそれが発生しても問題ありませんか？

私にはいいですね。 OCI仕様の提案を早期に開始することは役立つと思いますが。

今のところデフォルトは私には良いと思うので、「制限なし」で行ってください。 kubernetes / kubernetes＃39845の場合、アドオンにアノテーションを追加しました。 そして、私たちはこれ以上進むことができないと思います。

これまでのところ、runtime / default、kube / default、kube / loggingと、プロファイルをunconfinedに設定するオプションが表示されています。 残りはもちろん、現在の実装によってすでに提供されているlocalhost /.*プロファイルを持つ機能です。

私のために働きます。 kube/default場合、 docker/defaultから始めることができます。

ロギングseccompアクションは、Linuxカーネル4.14以降（seccomp doc）で使用できます。

私の理解では、これはPIDを使用してアクションをログに記録しますが、必ずしもコンテナー関連の情報である必要はありません。 したがって、auditdまたはホスト上の他のデーモンのいずれかが、ログが本当に役立つようにルックアップ/マッピングを実行する必要があります...

そして、なんらかの方法でデータを収集し、X％のケースで何もログに記録されていないことを示すことができれば、デフォルトのプロファイルで問題が発生することはありません。 次に、ログをkillに変更することを提案できます。 データ部分の収集はトリッキーで、多くの作業になる可能性があります。

Dockerのdockerデフォルトプロファイルを起動するときに、

@tallclairあなたが正しいです、私はすべての問題のコメントでちょっと迷子になりました。 参考までに、Dockerfilesがチェックされたことを示すコメントは次のとおりです： https ：//github.com/kubernetes/community/pull/660#issuecomment-303860107。 結局のところ、「殺害」のデフォルトを設定しても安全だと思います。

やあ
この拡張機能は以前に追跡されているため、チェックインして、Kubernetes1.13のステージを卒業する計画があるかどうかを確認したいと思います。 このリリースは、より「安定」することを目的としており、積極的なタイムラインがあります。 次の期限に間に合うと確信できる場合にのみ、この拡張機能を含めてください。

• ドキュメント（オープンプレースホルダーPR）：11/8
• コードスラッシュ：11/9
• コードフリーズの開始：11/15
• ドキュメントの完成とレビュー：11/27

1.13拡張トラッキングシートに含める必要がある場合は、今後の追跡とping @ kacole2のために、元の投稿のマイルストーンを更新してください。

ありがとう！

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間非アクティブになると腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

kubernetes/enhancements開かれた拡張機能の問題は、フリーズとしてマークされるべきではありません。
拡張機能の所有者は、リリースサイクル全体で状態を一貫して更新することにより、拡張機能を最新の状態に保つことができます。

/ remove-ライフサイクルが凍結されました

古くなった問題は、30日間操作がないと腐敗します。
/remove-lifecycle rottenして、問題を新規としてマークします。
腐った問題は、さらに30日間操作がないと終了します。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ライフサイクル腐敗

/ remove-lifecycle rotten

こんにちは@ stlaz @ pweil-、私は1.15のエンハンスメントリードです。 この機能は1.15でアルファ/ベータ/安定ステージを卒業する予定ですか？ 適切に追跡してスプレッドシートに追加できるように、お知らせください。 これには、KEPを1.15に含める必要もあります。

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

1.15の変更は予定されていません

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

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

注意として、すべての拡張には、各アルファ/ベータ/安定ステージの要件を説明する卒業基準を備えた実装可能な状態のKEPが必要です。

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

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

私はそれをGAに持ち込む計画の始まりを持っていますが、1.16でそれを実現するのは難しいかもしれません。 ただし、拡張機能のフリーズによって提案を出すようにします。

こんにちは@ tallclair @ pweil-、1.17エンハンスメントシャドウはこちら！ 🙂

*この拡張機能が1.17でアルファ/ベータ/安定に段階的に移行するですか？
この拡張機能を1.17トラッキングシートに追加できるように、お知らせください。

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

🔔フレンドリーなリマインダー

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

• Kubernetes拡張プロポーザル（KEP）は、拡張フリーズがリリースに受け入れられる

  • PRはに統合されます
  • implementable状態の場合
  • テスト計画と卒業基準を含める

• 関連するすべてのk / kPRをこの号に記載する必要があります

はい、これをv1.17で安定するように卒業する予定です-KEPはこちら： https ：

ねえ@tallclair 、追跡する追跡シートにこの拡張機能を追加します👍

わかりやすいリマインダーについては上記のメッセージを参照してください。KEPは暫定的な状態であることに注意してください。 KEPは、1.17リリースに追加するために実装可能な状態である必要があります。

/マイルストーンv1.17
/ステージ安定

ねえ@tallclairtestgridのテストへのリンクを投稿して、この拡張機能のために追加されたテストを追跡していただけませんか？

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

しましょう。 すでにたくさんのseccompテストがありますが、ダッシュボードのタブで見つけることができません（特定のテストについてすべてのテストグリッドを検索する方法はありますか？）
https://github.com/kubernetes/kubernetes/blob/0956acbed17fb71e76e3fbde89f2da9f8ec8b603/test/e2e/node/security_context.go#L147 -L177

@tallclairすべてのtestgridを検索する良い方法はありません= /

私の最善の推測（少なくともあなたが参照した4つについて）は、それらが実際には含まれていないということです。 😬

それらはnode-kubelet-featuresダッシュボードの一部である必要があるように見えますが、 ci-kubernetes-node-kubelet-featuresのジョブ構成にはtest_argsのためにこれがあります：

--test_args=--nodes=8 --focus="\[NodeFeature:.+\]" --skip="\[Flaky\]|\[Serial\]"

イチョウのテスト自体は[Feature:Seccomp]タグ付けされており、フォーカスフラグは一致しません。

GAに移行したら、機能タグを削除する必要があると思います。 Linuxではseccompが標準だと思うので、 [LinuxOnly]タグで十分です。

テストが実行されないという一般的な問題については、 https：//github.com/kubernetes/test-infra/issues/14647を提出しました

@tallclairさん、Enhancements Freeze （10月15日火曜日、EOD PST）からわずか5日です。 1.17リリースでこれを卒業できるようにするには、KEPをマージして、実装可能な状態にする必要があることを思い出してください。 KEPはまだ開いており、暫定的な状態にあるようです。

@tallclairさん、残念ながら1.17拡張フリーズの期限が過ぎており、KEPはまだ開いているようです。 この拡張機能を1.17マイルストーンから削除します。

1.17でこれを取得する必要がある場合は、拡張例外を提出できることに注意してください。

/マイルストーンクリア

ええ、カットしませんでした。 それを取り入れることを望んでいる
/マイルストーンv1.18

いいですね！ 拡張追跡シートで、これをv1.18に延期されたものとしてマークします。

ねえ👋、これを前進させるために私たちにできることはありますか？ こことAppArmorの問題に貢献できれば幸いです。

ねえ@tallclair

1.18機能強化チームのチェックイン！ 1.18で安定に卒業する予定ですか？ KEPはまだ開いているようです。

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

フリーズの強化： 1月28日
コードフリーズ： 3月5日
ドキュメント対応： 3月16日
v1.18リリース： 3月24日

念のため、KEPをマージして、ステータスをimplementable設定する必要があります。

ありがとう！

@saschagrunertオファーをありがとう！ @liggittで行ったAPIレビューをフォローアップするには、KEPで別のパスを取得する必要があります。 KEPが承認されたら、実装にご協力いただければ幸いです。

現在、KEPで最大の未解決の質問は、ローカルホストプロファイルタイプを処理する方法だと思います。 この機能を廃止したいので（理想的にはhttps://github.com/kubernetes/enhancements/pull/1269、/ cc @pjbgfのようなものを

ねえ@tallclair 、これが1.18になるかどうかについての更新はありますか？ 現在、マイルストーンでマークされていますが、これを追跡する必要があるかどうかは確認されていません。

ありがとう！

v1.18はこれについてはありそうもないようです。 私たちはぶつかることができると思います
/マイルストーンv1.19

素晴らしい、更新@tallclairをありがとう:)

こんにちは@ tallclair -1.19拡張機能ここをリードします。この拡張機能をこのリリースでstableに卒業する予定はありますか？

v1.19で卒業する予定はありません。 私はオープンKEPを持っていますが、今四半期はそれに取り組んでいません。 @pjbgfは

@ tallclair-更新していただきありがとうございます。 ：slightly_smiling_face：

/マイルストーンv1.20

昨日のsig-node会議で合意されたように、これについては計画にわずかな変更がありました。 これは現在、次の目的で計画されています。

/マイルストーンv1.19

@pjbgf ：マイルストーンを設定するには、

@palnabarunこの問題をマイルストーンv1.19に設定してもよろしいですか？

/ assign pjbgf

/マイルストーンv1.19

更新してくれてありがとう@ pjbgf @ tallclair 。 あなたの計画に従って追跡シートを更新しました。

どの卒業ステージを目指しているのか、KEPへのリンクを教えてください。

ありがとうございました！ すべての努力に感謝します。 ：slightly_smiling_face：

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

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

GAをターゲットにする

KEP： https ：
KEPにはまだ未解決のセクションがあり、フォローアップPRがあります： https ：

こんにちは@tallclair 、更新していただきありがとうございます。 ：+1：

それに応じてトラッキングシートを更新しました。

PS：KEPと最新のKEPアップデートPRへのリンクを使用して問題の説明を更新しました。

更新してくれてありがとう@palnabarun 。 ：+1：

こんにちは@ tallclair👋1.19ドキュメントシャドウはこちら！ 1.19で計画されているこの拡張作業には、ドキュメントの新規または変更が必要ですか？

ドキュメントの新規/変更が必要な場合は、6月12日金曜日までにk / website（ブランチdev-1.19 ）に対するプレースホルダーPRが必要になることを覚えておいてください。

@annajungそれは頭を上げるためです。 はい、seccompドキュメントにいくつかの変更があります。

これをピックアップしている@hasheddanを追加します（https://github.com/kubernetes/kubernetes/issues/58211）。

素晴らしい、アップデートしてくれてありがとう！ それに応じてトラッキングシートを変更します。
k / websiteに対するプレースホルダーPRが行われたら、お知らせください。 ありがとうございました！

@ pjbgf-ここにあるすべての実装PRにリンクしていただけますか-k / kまたはそれ以外ですか？ ：slightly_smiling_face：

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

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

@palnabarunこれが現在のものです：
https://github.com/kubernetes/kubernetes/pull/91381
https://github.com/kubernetes/kubernetes/pull/91408
https://github.com/kubernetes/kubernetes/pull/91182
https://github.com/kubernetes/kubernetes/pull/91442

また、それらすべてを含む包括的な問題を作成しました。

こんにちは@ pjbgf @ hasheddan k / websiteに対するプレースホルダーPRの期限は、6月12日金曜日です。PRが完了したらお知らせください。ありがとうございます。

@annajungリマインダーをありがとう！ まもなくオープンします：+1：

こんにちは@ pjbgf-アンブレラの問題を作成していただきありがとうございます。 ：+1：

私たちは同じことを追跡しています。 ：slightly_smiling_face：

こんにちは@ pjbgf-拡張の進行状況についてチェックインしたかっただけです。

リリースタイムラインは最近改訂されました。詳細については、こちらをご覧ください。

ご不明な点がございましたらお知らせください。 ：slightly_smiling_face：

改訂されたリリーススケジュールは次のとおりです。

• 7月9日木曜日：第13週-コードフリーズ
• 7月16日木曜日：第14週-ドキュメントを完成させて確認する必要があります
• 8月25日火曜日：第20週-Kubernetesv1.19.0がリリースされました

@palnabarunを更新していただきありがとうございます。 コードはほぼすべて完了していますが、現在、フォローアップレビューを待っています。 全体的に、私たちはまだ見栄えが良いです。 ：+1：

こんにちは@ pjbgf @ hasheddan 、次の締め切りが迫っていることを友好的に思い出させてくれます。
プレースホルダードキュメントPRにデータを入力し、7月6日月曜日までに確認できるようにしてください。

こんにちは@ pjbgf @ hasheddan ：wave：、実装関連の変更についてはhttps://github.com/kubernetes/kubernetes/issues/91286にまだ3つの保留中のアクションアイテムがあり、ドキュメント用に1つの保留中のアクションアイテムがあることがわかります。 彼らは7月9日木曜日のコードフリーズを過ぎてしまうと思いますか？

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

コードフリーズは7月9日木曜日にEODPSTで始まります

@palnabarun docs PRはほとんど準備ができており、seccompの特定のガイドを追加するだけです。 すでに現在の変更に関する@saschagrunertからLGTMを持っています。 ここで私たちを軌道に乗せてくれてありがとう:)

こんにちは@hasheddan 、上記の更新に感謝します。 EODによるレビュー（WIPの削除/リベース/すべての準備ができている）の準備をするための簡単なリマインダーです。 ありがとうございました！

@annajungがやる！ ありがとう！

@ hasheddan-更新していただきありがとうございます。 ：笑顔：

@ pjbgf - https：//github.com/kubernetes/kubernetes/issues/91286で、 2つのコアアクションアイテムがまだマージされておらず、マージプールにも含まれていないことがわかりました。 彼らはコードフリーズの前に入ると思いますか？

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

@palnabarunコードがフリーズする前に、すべてがすでにlgtmになっているので、それを実行しようとしています。 いくつかの不安定なテストatmでいくつかの問題が発生しています。 😅

頭を上げてくれてありがとう。

明確にするために、私たちがマージするのを待っている2つのprは次のとおりです。
https://github.com/kubernetes/kubernetes/pull/91408およびhttps://github.com/kubernetes/kubernetes/pull/92856

後者（https://github.com/kubernetes/kubernetes/pull/92856）は検証チェックに失敗しているようです。 https://github.com/kubernetes/kubernetes/pull/92856#issuecomment -655950700によると、マージする前にrebase / repush / rereviewが必要になります。

@kikisdeliveryserviceご説明ありがとうございます。 https://github.com/kubernetes/kubernetes/pull/91408での不安定なテストが失敗しなくなるのを待ってい

こんにちは@pjbgf ：wave：、私たちは今コードフリーズに入っています。

以来、 https：//github.com/kubernetes/kubernetes/pull/91408はマージプールにあり、 https：//github.com/kubernetes/kubernetes/pull/92856ではhttps://github.com/を介してリベースする必要がありhttps://github.com/kubernetes/kubernetes/pull/92856#issuecomment -655950700によると、ここでの最善のアクションは、2番目の完了に追加の時間を取得するための例外リクエストを提出することです。マージプールがクリアされた後のPR。

当面、マイルストーンから拡張機能を削除します。

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

一番、
Kubernetesv1.19リリース拡張チーム

/マイルストーンクリア

kubernetes / kubernetes＃91408はマージプールにあり、kubernetes / kubernetes＃92856はkubernetes / kubernetes＃92856（コメント）に従ってkubernetes / kubernetes＃91408をリベースする必要があるため、ここでの最善のアクションは例外を提出することだと考えていますマージプールがクリアされた後、2番目のPRを完了するために追加の時間を取得するように要求します。

マージキューで承認されたPRに基づいてリベースする場合、例外要求は必要ありません。 PRはコードが完了し、締め切りの1日前に承認されました。

こんにちは@liggitt ：wave ：、ご入力ありがとうございます。 ：+1：

拡張機能をサイクルに戻します。 私たちのすべての懸念はリベースに関するものでした。 それはソートされているので、これは良いことです。 ：slightly_smiling_face：

/マイルストーンv1.19

@pjbgf @ saschagrunert @ hasheddan-すべての貢献に感謝します。 ：100：

拡張機能の詳細な追跡をしてくれた@palnabarunに感謝します。 感謝します！ 🙏

@saschagrunert最終的なPRkubernetes / kubernetes＃92856がついにマージされます。 おめでとうございます！ これを反映するようにトラッキングシートを更新します。

@tallclair @pjbgf seccompはGAなので、この問題を今すぐ解決できると思いますか？

@saschagrunert通常、リリースが行われるのを待ってから、対応するKEPをimplementedとしてマークしてから、拡張機能の問題を閉じます。

https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.mdをimplementedとしてマークするために、自由に変更を加えてください。 ：slightly_smiling_face：

@saschagrunert通常、リリースが行われるのを待ってから、対応するKEPをimplementedとしてマークしてから、拡張機能の問題を閉じます。

https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.mdをimplementedとしてマークするために、自由に変更を加えてください。

説明をありがとう、 https：//github.com/kubernetes/enhancements/pull/1932でPRを開きました

KEPが更新されて実装されました（PRがついに統合されました！）

この問題を@saschagrunertでお気軽に閉じてください

みなさん、ありがとうございました!!

/マイルストーンクリア

/選ぶ
これで完了です。

@saschagrunert以前にこれについて話し合ったかどうかは思い出せませんが、最終的にアノテーションをクリーンアップする（つまり、サポートを削除する）計画はありますか？ そうする主な動機は、サードパーティのツール（ゲートキーパー、krailなど）が注釈とフィールドの両方をチェックすることを知る必要がないようにすることです。

@saschagrunert以前にこれについて話し合ったかどうかは思い出せませんが、最終的にアノテーションをクリーンアップする（つまり、サポートを削除する）計画はありますか？ そうする主な動機は、サードパーティのツール（ゲートキーパー、krailなど）が注釈とフィールドの両方をチェックすることを知る必要がないようにすることです。

はい、これはv1.23で計画されています。 これには、必要なユーティリティ機能が存在した後に実行できる警告メカニズム（まだ実行されていません）が組み込まれています（https://github.com/kubernetes/kubernetes/issues/94626を参照）。

KEPから：

注釈の使用法の認識を高めるために（古い自動化の場合）、警告メカニズムを使用して、v1.23でサポートが廃止されることを強調します。 検討されているメカニズムは、KEP＃1693で説明されているように、監査アノテーション、オブジェクトのアノテーション、イベント、または警告です。

…

マスターとノード間のバージョンスキューの最大2つのマイナーリリースをサポートしているため、最初の実装に合格した少なくとも2つのバージョンについて、アノテーションを引き続きサポートし、埋め戻す必要があります。 ただし、破損を減らすために、サポートをさらに拡張することを決定できます。 この機能がv1.19で実装されている場合、古い動作を削除するためのターゲットとしてv1.23を提案します。

これらのビットも実装されるまで、この問題を再開しますか？

ええ、機能が完全に終了するまでこれを開いたままにしておきましょう。 あなたが説明した仕事に対して提出されたak / kの問題はありますか？

ええ、機能が完全に終了するまでこれを開いたままにしておきましょう。 あなたが説明した仕事に対して提出されたak / kの問題はありますか？

これで1つになりました：https：//github.com/kubernetes/kubernetes/issues/95171 :)