kubernetes / kubernetesとの相互参照： Issue＃62822

更新していただきありがとうございます！

/ assign @leblancd
/種類の機能
/ sig network
/マイルストーン1.11

@leblancd利用可能な設計ドキュメントはありますか？

/ cc @thockin @dcbw @luxas @ kubernetes / sig-network-feature-requests

@ idvoretskyi-デザインドキュメントはまだありませんが、まもなくコラボレーションを開始します。

これは、Kubernetes Ingressがデュアルスタックをサポートすることを意味しますか？
これは、CNI（Calico）がデュアルスタック（たとえば、BIRDデーモンとBIRD6デーモンの両方）を実行する必要があることを意味しますか？

@ sb1975-デュアルスタック入力サポートに関しては、ハッシュ化する必要がありますが、これが私の予備的な考えです。

• デュアルスタック入力サポートは、主に、使用する入力コントローラー（サポートされているかどうか、および実装方法）によって異なります。 既存の入力コントローラーは、デュアルスタックをサポートするためにおそらくいくつかの変更が必要になります。
• 一般的な入力コントローラーの入力構成は変更されないことを期待しています（
• サービスにデュアルスタックのエンドポイントポッドがある場合、入力コントローラーは、パケットのファミリーに基づいて入力パケットをマップするために変更が必要になる場合があります。つまり、IPv4入力パケットをIPv4エンドポイントにマップし、IPv6入力パケットをマップします。 IPv6エンドポイントに。 負荷分散の重み付けを行うために、デュアルスタックエンドポイントは単一のエンドポイントターゲットとしてカウントする必要があります。

-V4 / V6ファミリ間で入力コントローラをマップする（入力IPv4パケットをIPv6バックエンドにマップする、またはその逆）ための将来のサポートを検討することもできますが、最初の開発は厳密なデュアルスタック（つまり、個別の独立したもの）です。スタック）。

Calicoおよびその他のCNIプラグインについて：

• CNIプラグインは、クラスタのシナリオは、デュアルスタックを必要としない場合、彼らはまだ（プラグインのサポート、それならば）のIPv4のみ、またはIPv6のみを実行することができますデュアルスタックモードで実行する必要は
• デュアルスタックのサポートには、おそらくさまざまなCNIプラグインの変更が必要になりますが、その作業はこのKubernetesの問題の範囲外と見なされます（Kubernetesを任意のデュアルスタックプラグインで機能させることに重点を置いており、おそらくブリッジプラグインを次のように使用します参照）、CNIの作業はケースバイケースで個別に行われます。
• 特にCalicoの場合、私は専門家ではありませんが、IPv4ルートとIPv6ルートの両方を処理するように単一のBIRDデーモンを構成できると思います（ここで「templatebgp」を検索してください：http：//bird.network.cz/？get_doc＆v = 20＆f = bird-3.html＃ss3.1）。 とはいえ、Calicoはすでにポッドでデュアルスタックアドレスをサポートしていますが、両方のファミリでBGPルーティングを機能させるために変更が必要になる場合があります。

@leblancd ：シナリオは次のとおりです：

1. NGINX入力コントローラーを使用するとしましょう
2. Ingressを介してサービスを公開しています。
3. デュアルスタックで構成されたポッドを実行しています
4. AおよびAAAAdns-recordsを使用してリモートでサービスにアクセスしようとしています。
   これらすべてを願っています
5. 要約：ポッドサービス名のAおよび/またはAAAAレコードに対する独自のクエリによって解決されるように、IPv4またはIPv6アドレスのいずれかを使用してポッドインターフェイスに接続したいと思います。
   テスト、文書化、アーキテクチャのこのイニシアチブに参加できますか？ただし、いくつかのガイダンスが必要です。
   この進捗状況を知るにはどうすればよいですか。

@ sb1975-良い質問です。 デュアルスタックを備えたNGINX入力コントローラー。 私はNGINX入力コントローラーの専門家ではありませんが（おそらくもっと慣れている人が飛び込むことができます）、ワークフローをどのように見るかを次に示します。

• 外部からKubeサービスにアクセスしようとすると、DNSコントローラーは入力コントローラーのAおよびAAAADNSレコードを使用してサービスを解決する必要があります。 入力コントローラーに到達するためにAレコードとAAAAレコードを使用するのは、クライアント/アプリの選択です。 したがって、入力コントローラーへの外部アクセスはデュアルスタックになります。
• 次に、NGINX入力コントローラーで、NGINXはL7 URLを調べ（要求がIPv4またはIPv6パケットにあるかどうかに関係なく）、それをアップストリームエンドポイントに負荷分散します。 入力コントローラーのロードバランサーがipv6 = onで構成されている場合（これはデフォルトです。https：//docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/#configuring-http-loadを参照してください） -balancing-using-dns）、およびサービスエンドポイントがデュアルスタックである場合、アップストリーム構成には、デュアルスタックエンドポイントごとにIPv4エントリとIPv6エントリの両方が必要です。 設計どおり、NGINXロードバランサーはエンドポイントのIPv4エントリとIPv6エントリを別々のサーバーとして扱いがIPv6（または、そのための構成ノブがある場合はIPv4）への負荷分散を無効にして、負荷分散がIPv4のみのエンドポイントになるようにすることができます。 または、NGINXロードバランサーを変更して、IPv4アドレスへの接続と対応するIPv6アドレスへの接続を同じエンドポイントへの2つのロードとして扱うことができます。

助けて参加することに関しては、これは大いにありがたいです！ デュアルスタックで本格的に作業を開始しようとしています（IPv6のみでCIを機能させる作業により、少し遅れています）。 仕様の概要（GoogleDocまたはKEPsWIP doc）をすぐに発表したいと思っており、レビューやセクションの作成に役立つ情報を探しています。 また、（設計仕様を超えた）公式ドキュメント、およびデュアルスタックE2Eテストの定義と実装についても確実に支援が必要です。 私がまだデザインについて少し大ざっぱな領域のいくつかは次のとおりです。

• ヘルス/活性/準備プローブは、デュアルスタックでどのように影響または処理されますか
• ネットワークポリシーに影響はありますか？
• ロードバランサーの懸念？
• クラウドプロバイダープラグインの懸念？
• L3 / L4入力の懸念？
  これらのいずれかについて考えたことがあれば、多分あなたはそれらのセクションを手伝うことができますか？

また、中間の「エッジでのデュアルスタック」（IPv6のみを使用）アプローチも検討しています。このアプローチでは、クラスターの外部からK8sサービスへのアクセスはデュアルスタックになりますが、これはマッピングされます（たとえば、NGINXを介して）。イングレスコントローラー）をクラスター内のIPv6のみのエンドポイントに接続します（またはステートレスNAT46を使用します）。 クラスター内のポッドとサービスはすべてIPv6である必要がありますが、大きな利点は、市場投入までの時間の観点から、デュアルスタック外部アクセスがはるかに迅速に利用できることです。

/マイルストーン1.12

@leblancd / @ caseydavenport-ここで多くの議論とマイルストーンの変更に気づいています。
これは1.11マイルストーンから引き出されるべきですか？

@ justaugustus-はい、これは1.12に移動する必要があります。 リリーススプレッドシートの行を削除する必要がありますか、それともこれを変更するために必要なことはありますか？

@leblancd私はそれをカバーしています。 フォローアップしてくれてありがとう！ :)

@leblancd @ kubernetes / sig-network-feature-requests-

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

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

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

以下を設定します。

• 説明
• 譲受人
• ラベル：
  
  
  
  • ステージ/ {アルファ、ベータ、安定}
  
  
  • sig / *
  
  
  • 種類/機能
  
  

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

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

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

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

ハッピーシッピング！

/ cc @justaugustus @ kacole2 @robertsandoval @ rajendar38

@ leblancd-
機能フリーズは今日です。 これをKubernetes1.12のベータ版に卒業する予定ですか？
もしそうなら、すべてが最新であることを確認して、1.12機能追跡スプレッドシートに含めることができますか？

こんにちは@ justaugustus-ベータステータスはKubernetes1.13に移行する必要があります。 設計KEP（https://github.com/kubernetes/community/pull/2254）で（遅いとはいえ）進歩を遂げており、CIテストPRとの再エンゲージメントに近づいていますが、Kubernetes 1.12ターゲットは少し楽観的すぎました。

上記の説明/概要を、以前にリクエストした情報で更新します。 お待ちいただいてありがとうございます。

/ remove-stage alpha
/ステージベータ

心配ありません、@ leblancd。 更新していただきありがとうございます！

こんにちは、 @ justaugustus @leblancd

ベータ版がデュアルスタック用に1.13に移行したというアップデートを読んだところです。 1.13のリリース予定日はいつですか？ 私たちは実際にデュアルスタックのサポートを探しています。 私たちの製品をコンテナに移行することは、決定的な決断です。

@ navjotsingh83 -Kubernetes1.13のリリース日が確定していないと思います。 Kubernetesリリースのドキュメントに1.13がリストされていません。

@ navjotsingh83 @leblancd 1.13リリーススケジュールが公開されています。 11月15日にコードがフリーズする短いリリースサイクル。 この機能をベータ版に移行するのに十分な時間だと思いますか。 自信を持ってこの問題を更新できますか？コード、テスト、ドキュメントの完成に関して何が保留中ですか？

SIGネットワ​​ーク会議での議論によると、1.13でこの機能についてかなりの作業が行われる予定ですが、1.13でベータ版に移行する予定はありません。 それに応じてマイルストーンを削除します。

/マイルストーンクリア

@ kacole2は、1.13拡張スプレッドシートからこれを削除します

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

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

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

/ remove-lifecyclestale

@leblancdこんにちは-私は1.14の拡張機能のリーダーであり、この問題をチェックして、1.14リリースで計画されている作業（ある場合）を確認しています。 拡張機能のフリーズは1月29日であり、すべての拡張機能にはKEPが必要であることを思い出してください。

@leblancd IPv4 / IPv6のクラスターのエッジでの描写の作成に関連して、以前のコメントをフォローアップしたいと

「また、中間の「エッジでのデュアルスタック」（クラスター内でのみIPv6を使用）アプローチを検討しています。このアプローチでは、クラスターの外部からK8sサービスへのアクセスはデュアルスタックになりますが、これはマッピングされます（たとえば、 NGINX入力コントローラー）をクラスター内のIPv6のみのエンドポイントに（またはステートレスNAT46を使用して）。 クラスター内のポッドとサービスはすべてIPv6である必要がありますが、大きな利点は、市場投入までの時間の観点から、デュアルスタック外部アクセスがはるかに迅速に利用できることです。」

このユースケースは現在のプロジェクトに適しているので、時間枠の周りのあなたの考えを見て、私自身または私たちのグループの誰かがこの市場投入までの時間の短縮に貢献できるものがあるかどうかを確認したいと思いました。

@KevinAtDesignworxエッジデュアルスタックであるが内部のipv6のみのアプローチが、コンテナーの内部から外部のipv4要求に到達できる場合（つまり、 curl -v 93.184.216.34 -H "Host: example.com" ）、私はそれが最善のアプローチだと心から思います。 インフラストラクチャでipv6を使用できる場合は、互換性の理由から、エッジ以外でわざわざipv4を使用する必要があります。 ただし、このアプローチが、クラスター内からipv4だけを使用してレガシーWebサイトにアクセスできないことを意味する場合は、もうよくわかりません。

464XLATがあるので、コンテナ内でのみipv6を実行できます。

@ KevinAtDesignworx-シナリオで入力コントローラーの使用が機能する場合は、外部からのデュアルスタック操作（クラスター内の単一ファミリへのプロキシ）用にNGINX入力コントローラーを構成できます： https ：

入力コントローラーは、各ノードのホストネットワークで実行する必要があるため、コントローラーはデーモンセット（各ノードに1つの入力コントローラー）として設定する必要があります。 これは、次のことを前提としています。

• ノードはデュアルスタックです（ポッドとサービスがシングルファミリーであるのとは対照的です）
• 各ノードの/ etc / hostsにはIPv6エントリがあり、そのノードのホスト名にはIPv6エントリのみ（IPv4アドレスなし）があります。

これは、クラスター内のV6クライアントから外部IPv4のみのサーバーへの接続用のNAT64 / DNS64に追加されます。

ステートレスNAT46もオプションですが、試したことがないので、そのための構成ガイドはありません。

@leblancd 1.15でここで計画されている作業はありますか？ この時点でも、KEPはまだ受け入れられていないようです。 ありがとう！

@leblancd IPv4 / IPv6のクラスターのエッジでの描写の作成に関連して、以前のコメントをフォローアップしたいと

「また、中間の「エッジでのデュアルスタック」（クラスター内でのみIPv6を使用）アプローチを検討しています。このアプローチでは、クラスターの外部からK8sサービスへのアクセスはデュアルスタックになりますが、これはマッピングされます（たとえば、 NGINX入力コントローラー）をクラスター内のIPv6のみのエンドポイントに（またはステートレスNAT46を使用して）。 クラスター内のポッドとサービスはすべてIPv6である必要がありますが、大きな利点は、市場投入までの時間の観点から、デュアルスタック外部アクセスがはるかに迅速に利用できることです。」

このユースケースは現在のプロジェクトに適しているので、時間枠の周りのあなたの考えを見て、私自身または私たちのグループの誰かがこの市場投入までの時間の短縮に貢献できるものがあるかどうかを確認したいと思いました。

コンテナ（ipv6のみ）の内部から、curlリクエスト（つまり、curl -v 93.184.216.34 -H "Host：example.com"）をクラスターの外部に送信します。 コンテナが存在するホストにipv4ルートが存在しない限り、宛先が不明または宛先に到達できないというエラーが発生すると思います。

@ GeorgeGuo2018k8sがDNS64 / NAT64を実装する場合、それは機能します。 これは、k8sが464xlat / platソリューションにどの程度入るか、エッジルーターなどで何を処理する必要があるかに大きく依存します。

実際には、kube-system名前空間内でホストネットワークとTaygaを使用するDaemonSet / Deploymentを使用して、内部DNS64がtaygaを使用してネットワークの外部に移動することで可能になると思います。

私には解決策のように聞こえます。

内部でIPv6のみのネットワークを実行しており、NAT64 / DNS64は非常にうまく機能します。 IPv6がまったくサポートされていない一部のレガシー製品では、必要な場所で直接clatdを使用することになりました。 （この場合、VM上で直接。）

@ kacole2-これを1.15で追跡したいと思います。 次のPRをマージするように取り組んでいます-https：//github.com/kubernetes/enhancements/pull/808

特に1.15の場合、以下のサポートを追加します。

• APIタイプの変更
  
  
  
  • Kubernetesタイプ
  
  
  • CRIタイプ
  
  
• デュアルスタックポッドネットワーク（マルチIPポッド）
• kubenetマルチファミリーサポート

マイルストーン追跡のためのcc @ caseydavenport ^

@ kacole2KEPがマージされました。 1.15でこれを追跡するために必要なものが他にあるかどうか教えてください

ちょっと@ leblancd @lachie835月30日木曜日までに予定されているk / website（ブランチdev-1.15）に対するPRを探しているだけのフレンドリーなリマインダーです。完全なドキュメントの始まりであるなら素晴らしいでしょうが、プレースホルダーですらPRは許容されます。 ご不明な点がございましたらお知らせください。

@ kacole2KEPがマージされました。 1.15でこれを追跡するために必要なものが他にあるかどうか教えてください

@ lachie83こんにちは、

@ kacole2KEPがマージされました。 1.15でこれを追跡するために必要なものが他にあるかどうか教えてください

実際、k8s1.15でデュアルスタックのサポートが確実に追加されるかどうかを知りたいと思います。

@leblancd k8s.iodev -1.15に対するプレースホルダーPRの期限は5月30日木曜日です。

@leblancd k8s.iodev -1.15に対するプレースホルダーPRの期限は5月30日木曜日です。

リリース1.15でデュアルスタックサポートが利用可能になると考えられますか？

@ GeorgeGuo2018 1.15の拡張シートにはまだありますが、拡張リード@ kacole2のみが詳細を提供できます。

こんにちは@ lachie83 @ leblancd 。 コードフリーズは2019年5月30日木曜日@EODPSTです。 リリースに含まれるすべての拡張機能は、テストを含めてコードが完全であり、ドキュメントPRが開いている必要があります。

凍結状態になるのを追跡できるように、現在のすべてのk / kPRをリストしてください。 PRがフリーズによってマージされない場合、この機能は1.15リリースサイクルでスリップします。 マイルストーンでは、リリースブロックの問題とPRのみが許可されます。

元の投稿のkubernetes / kubernetes＃62822はまだ開いています。 統合される予定の他のPRもありますか？

これがスリップすることがわかっている場合は、返信してお知らせください。 ありがとう！

@ simplytunde-頭を上げて感謝します。 今週はドキュメントPRをまとめる作業をしています。

@ GeorgeGuo2018-これはマルチリリースのKEPになります。 1.15でフェーズ1の着陸を計画しています。 詳細については、KEPの実装計画をご覧ください-https

@ simplytunde - 。 完了して、数日以内にレビューできるようにする予定です。

@ kacole2pingをありがとう。 1.15拡張機能のspeadsheetを、追跡しているk / k PR（https://github.com/kubernetes/kubernetes/pull/73977）とドラフトドキュメントPR（https://github.com/）で更新しました。 kubernetes / website / pull / 14600）。 現在、コードがフリーズする前にこのPRをマージする予定です。 他に何か足りない場合はLMK

@ kacole2 @claurenceとリリースチームとの話し合いの

/マイルストーンクリア

@simplytundeドキュメントPRにもコメントしました。 それが1.15マイルストーンからも削除されていることを確認してください。

こんにちは@ lachie83 @leblancd 、私は1.16エンハンスメントシャドウです。 この機能は1.16でアルファ/ベータ/安定段階を卒業する予定ですか？ 1.16トラッキングスプレッドシートに追加できるようにお知らせください。

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

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

https://github.com/kubernetes/dns/issues/315では、 DNSサービス検出仕様へのIPv6 / AAAAの追加について

@ lachie83 @leblancdこれを追跡するために1.16で卒業するかどうか、何か考えはありますか？

@ evillgenius75 @ kacole2これは1.16で追跡する必要があります。 この機能はアルファ状態になります。 KEPで定義されているフェーズ1とフェーズ2は1.16です。

KEPの追跡

• https://github.com/kubernetes/enhancements/pull/808

マージされたk / k PR（現在マスターにあるのは1.16になります）

• [マージ済み]フェーズ1- https：//github.com/kubernetes/kubernetes/pull/73977
• [マージ済み]フェーズ1e2eテスト-https ：//github.com/kubernetes/kubernetes/pull/78801
• [マージ済み]フェーズ1e2eテストのクリーンアップ-https ：//github.com/kubernetes/kubernetes/pull/80001
• フェーズ2サービス/エンドポイント-https ：//github.com/kubernetes/kubernetes/pull/79386
• フェーズ2kube-proxy- https：//github.com/kubernetes/kubernetes/pull/79576

関連するPR

• IPv6のサポートhttps://github.com/kubernetes-incubator/ip-masq-agent/pull/45
• フェーズ1ドキュメント–ツールの例が完成したら再開されます-https：//github.com/kubernetes/website/pull/14600
• [マージ済み]クリーンアップ-ノードdropDisabledFields- https：//github.com/kubernetes/kubernetes/pull/79741
• クラスターcidrの複数のマスクサイズをサポート-https ：//github.com/kubernetes/kubernetes/pull/79993
• デュアルスタックのE2eProwジョブhttps://github.com/kubernetes/test-infra/pull/12966

ねえ、 @ leblancd私はv1.16ドキュメントのリリースリーダーです。

この拡張機能（またはv1.16で計画されている作業）には、新しいドキュメント（または変更）が必要ですか？

8月23日金曜日までに予定されているk / website（ブランチdev-1.16）に対するPRを探しています。 それが完全なドキュメントの始まりであるならばそれは素晴らしいでしょう、しかしプレースホルダーPRでさえ受け入れられます。 ご不明な点がございましたらお知らせください。

@simplytundeはドキュメントPRです：//github.com/kubernetes/website/pull/16010

@ lachie83フレンドリーなリマインダーコードの1.16のフリーズは、
フェーズ2サービス/エンドポイント-kubernetes / kubernetes＃79386
フェーズ2kube-proxy-kubernetes / kubernetes＃79576

関連する：
クラスターcidrの複数のマスクサイズをサポート-kubernetes / kubernetes＃79993
デュアルスタックkubernetes / test-infra＃12966のE2eProwジョブ

こんにちは@ lachie83 @leblancd https://github.com/kubernetes/kubernetes/pull/79576とhttps://github.com/kubernetes/kubernetes/pull/79993は、コードがフリーズする前にマージされなかったようです。 Tide MergePool内。 この機能はv1.16から追加される予定です。 それでもこれを1.16リリースの一部にしたい場合は、例外を

@ kacole2応答の遅延についてお詫びします。 主なPRは、 https：//github.com/kubernetes/kubernetes/pull/79386でした。 kubernetes / kubernetes＃79576については、1.17に延期し、代わりにhttps://github.com/kubernetes/kubernetes/pull/82091（sig-networkとの合意）に焦点を当てることを決定しましたhttps://github.com/kubernetes/kubernetes/pull/80485で、これもマージされています。 kubernetes / kubernetes＃79993も1.17に延期されました

ちょっとそこ@ lachie83 @leblancd - 1.17拡張機能はここにつながります。 チェックインして、この拡張機能が1.17でアルファ/ベータ/安定版に移行すると思われるかどうかを確認したかったのですか？

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

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

その場合は、適切に追跡できるように、この号に関連するすべてのk / kPRをリストしてください。 👍

ありがとう！

/マイルストーンクリア

ハイボブ。 お問い合わせいただきありがとうございます。 私はまだこの拡張機能のフェーズ3を計画しており、拡張機能を完成させる予定です。 この拡張機能は、このリリースの終了時にまだアルファ版ですが、1.17の一部としてk / kに到達するフェーズ3関連の作業があります。

これは、デュアルスタックの1.17の高レベルの成果物のリストです。 このリストはリリース全体で更新します。

• IPtablesデュアルスタックプロキシー-https ：//github.com/kubernetes/kubernetes/pull/79576
• Pod.Status.PodIPsの下方APIサポート-https ：//github.com/kubernetes/kubernetes/pull/83123
• e2eは1つのCNIプラグインをテストします
• ホストファイルの変更（ホスト名のIPv6アドレスを追加する必要があります/ etc / hosts）-https ：//github.com/kubernetes/kubernetes/pull/83123
• 種類のデュアルスタック-https：//github.com/kubernetes-sigs/kind/pull/692
• e2eスイートを更新します-https ：//github.com/kubernetes/kubernetes/pull/80725
• エンドポイントスライスのサポート
• Kubeadmのデュアルスタックサポート-https ：//github.com/kubernetes/kubeadm/issues/1612

どうもありがとうございました@lachie83❤️先に進んで追跡シートに追加します。

/マイルストーンv1.17

@mrbobbytables sig-networkを介して計画を伝達した後、KEPのフェーズ3の一部として、上記の作業を詳細に説明するPRも追加しました。 KEP自体はまだimplementable状態にあり、これらの変更は、1.17の一部として計画された作業を具体的に文書化するだけです。

ある時点で、 https：//kubernetes.io/docs/concepts/services-networking/dns-pod-service/がhttps://github.com/kubernetes/website/issues/15434変更されたトラック。 相互参照に注意するために、ここで言及します。

フェーズ2e2eテストを追加するためにKEPを更新しました-https ：//github.com/kubernetes/enhancements/pull/1311

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

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

@ lachie83

11月8日のドキュメントプレースホルダーPRの締め切りが近づいています。 k / websitedev-1.17ブランチに対して1つを取得してみてください。

ねえ@ lachie83 、私はあなたがタブを維持していることを知っています、しかし私は立ち寄ってそれをとにかく言及する必要があります🙈
コードのフリーズが間近に迫っています（11月14日）。 物事はどうですか？ それまでにすべてがマージされる予定ですか？

ありがとう！

ねえ@mrbobbytables！ pingをありがとう。 1.17に着陸するために以下のPRを追跡しています。 この変更に関連するPRがさらに1つまたは2つある可能性があります。 これらの変更にはドキュメントが必要です。 プレースホルダードキュメントPRを上げます

• kube-proxyiptablesモードのデュアルスタックサポートpr / 82462
• デュアルスタック下向きAPIPR / 82462
• ipvsmetaproxierエンドポイントスライスサポートpr / 84089を追加します
• kube-controller-manager pr / 79993で複数ノードのCIDRマスクを許可する

@ irvifa-これがプレースホルダードキュメントPRです。 https://github.com/kubernetes/website/pull/17457

かっこいいありがとう🎉 @ lachie83

@ lachie83明日は、1.17リリースサイクルのコードフリーズです。 k / kPRはまだマージされていないようです。 😬1.17拡張追跡シートでこれをリスクありとしてフラグを立てています。
14日（木）のEoDで統合されると思いますか？ それ以降は、例外を除いて、リリースブロッキングの問題とPRのみがマイルストーンで許可されます。

ありがとうボブ-私は今日sig-networkとこれについて話し合い、アップデートを提供します。

ねえ@mrbobbytables。 これは、今日EoDによってマージされ、sig-networkによって承認されたPRのリストです。

• https://github.com/kubernetes/kubernetes/pull/85246
• https://github.com/kubernetes/kubernetes/pull/83123
• https://github.com/kubernetes/kubernetes/pull/79993

残りのPRは1.18にパントされる可能性が最も高いです-https ：//github.com/kubernetes/kubernetes/pull/82462

@mrbobbytablesは、上記のすべてのPRがマージされ、実際にkubernetes / kubernetes＃82462を1.18にパントすることを確認しています。 これらのPRは、1.17のデュアルスタックの動作に意味のある変更を追加するため、この機能強化は引き続き追跡できます。 今、私はドキュメントPRを準備する必要があります！ 1.18でkubernetes / kubernetes＃82462をリリースし、この作業をベータ版に進めることを望んでいます。

よろしくお願いします@ lachie83！

そして、それはライブです！ https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-release-announcement/

この拡張機能を1.18でベータ版に移行する予定です。 拡張卒業基準とテストプランは、このPRと一緒にKEPにあります：//github.com/kubernetes/enhancements/pull/1429

/マイルストーン1.18

@ lachie83 ：提供されたマイルストーンはこのリポジトリでは無効です。 このリポジトリのマイルストーン：[ keps-beta 、 keps-ga 、 v1.17 、 v1.18 、 v1.19 、 v1.20 、 v1.21 ]

/milestone clearを使用して、マイルストーンをクリアします。

/マイルストーンv1.18

この拡張機能を1.18でベータ版に移行する予定です。 強化卒業基準とテスト計画は、このPRと一緒にKEPで見つけることができます-＃1429

@ lachie83の更新に感謝します。これを、1.18スプレッドシートで追跡対象としてマークしました。

1.18に着陸する作業の一環として、次のPRを追跡してください。 https://github.com/kubernetes/kubernetes/pull/82462

追跡のための他の関連PRの追加：
https://github.com/kubernetes/test-infra/pull/15893
https://github.com/kubernetes-sigs/kind/pull/692

ありがとう@ lachie83！

こんにちは@ lachie83 、上記以外に追跡する必要のあるPRはありますか？

こんにちは、@ lachie83 @leblancd -私は1.18リリースチームのDocs影です。

1.18で計画されているこの拡張作業には、新しいドキュメントや既存のドキュメントへの変更が必要ですか？

そうでない場合は、1.18エンハンスメントトラッカーシートを更新してください（またはお知らせください。更新します）

ドキュメントの更新が必要な場合は、k / website（ブランチdev-1.18）に対するプレースホルダーPRの期限が2月28日金曜日であることを思い出してください。

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

誰かがv1.18のIPV6またはデュアルスタックのものを文書化するのを手伝いたいなら、私に少しだけ教えてください。 私は助けることができるかもしれません。

ねえ@ lachie83 、

kubernetes-sigs / kind＃692はまだマージされていないようです。 それはあなたのベータ卒業にとって重要ですか？

ねえ@ jeremyrickard @ sethmccombsこのPRhttps： //github.com/kubernetes/kubernetes/pull/86895をます。 合理的な前進ができるまで、これを1.18のベータ版に移行するのは賢明ではないと思います。

/マイルストーンクリア

@ lachie83アップデートありがとうございます。 この拡張機能をマイルストーンから削除しました。 1.19にこれを楽しみにしています。 :)

デュアルスタック拡張の状態が1.18のalphaままであることを確認したいと思います。 私は現在、コミュニティと協力して、1.19に完了する予定の作業を評価しています。 この拡張機能は1.19でもアルファ状態のままである可​​能性がありますが、確認したいと思います。 また、1.18ドキュメントの拡張状態を反映するようにドキュメントを更新するためのアクションを実行します。

デュアルスタックKubernetesをベータ版として表示しているページがウェブサイトにある場合は、優先/重要なバグとしてk / websiteに対してファイルしてください。

こんにちは@ lachie83-1.19拡張機能ここをリードします。この拡張機能が1.19で卒業すると思われるかどうかを確認したいと思いますか？

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

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

デュアルスタックKubernetesをベータ版として表示しているページがウェブサイトにある場合は、優先/重要なバグとしてk / websiteに対してファイルしてください。

@ sftim1.17と1.18のリリースラベリングに対処するために2つのPRを作成しました

@palnabarun 1.19リリースのタイムフレームでデュアルスタックKEPを更新するよう取り組んでいますが、現在、1.19リリースでコードの変更が行われるとは考えていません。 すでに行われた作業に1つのブロッキングの問題があります（ alpha状態になっているおかげで）。 ブロッキングの問題はhttps://github.com/kubernetes/kubernetes/pull/86895です。 次のKEPアップデートhttps://github.com/kubernetes/enhancements/pull/1679を介してこれに対処する予定ですが、提案された変更についてコンセンサスを得るには時間がかかります。 この段階では、現在の実装でこのブロッキングの問題に対処するまで、デュアルスタック拡張はalpha状態のままになります。 進捗状況に応じて最新情報を提供します。

更新してくれてありがとう、Lachie。 私はすべての努力に感謝します！ ：slightly_smiling_face：

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

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

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

/ remove-lifecyclestale

この拡張機能は1.20で追跡されるようにしたいと思います。 更新されたkep（ https://github.com/kubernetes/enhancements/pull/1679）に従って、アルファ状態で再実装されhttps：//github.com/kubernetes/kubernetes/pull/91824のPRを追跡して

9月17日のSIGネットワ​​ーク会議で議論された、自宅で一緒に遊んでいる人のための、ベータステータスへの最新のデュアルスタック卒業：

• kubeletデュアルスタックヘルスチェックのあいまいさを解決する必要があります。 https://github.com/kubernetes/enhancements/pull/1975経由
• 既存のデュアルスタックサービスPRを終了してマージする必要があります（アクティブなレビュー中）。 https://github.com/kubernetes/kubernetes/pull/91824経由
• デュアルスタックノードIPの動作を確定する必要があります。 https://github.com/kubernetes/enhancements/pull/1665経由
• サービスのSpec.LoadBalancerIPsフィールドに必要な変更（ある場合）を決定する必要があります

これらの項目はすべて積極的に取り組んでおり、1.20は依然としてデュアルスタックAPIベータ卒業のターゲットです。 ただし、最善の努力にもかかわらず、問題が時間内に解決されない可能性は常にあります。その場合、SIG Networkは、公開会議でベータ版への卒業を継続するかどうかを決定します。 どなたでもご参加いただけます。

@dcbw更新してますhttps://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md＃graduation -criteria

@dcbw更新してますhttps://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md＃graduation -criteria

ただし、実際には再実装ではありません。 以前の作業はすべて引き続き有効であり、1.20の作業はその上に構築されており、特定された必要な最後の変更を確定します。 sig-networkディスカッションの私の解釈は、 @ dcbwが投稿したリストは、卒業のために解決する必要のある残りの既知の問題のセットであるというものです。

こんにちは、みんな、

1.20拡張機能ここでリードします。これを追跡対象として設定します。何か変更があった場合は更新してください:)

念のため、EnhancementsFreezeは10月6日です。

注意として、KEPは更新した古い形式を使用しています： https ：

一番、
キルステン

/マイルストーンv1.20

こんにちは、 @ russellb-

ただし、実際には再実装ではありません。 以前の作業はすべて引き続き有効であり、1.20の作業はその上に構築されており、特定された必要な最後の変更を確定します。

https://github.com/kubernetes/kubernetes/pull/91824でのAPIの変更を考えると、デュアルスタックを1.20のアルファとしてマークすると、必要であることが判明した追加の再実装の余地ができるほど十分に異なります。 私たちは皆ベータに熱心であることを知っていますが、最初に+9,319 −3,261 PRを上陸させ、ほこりを落ち着かせましょう。 :)

kubernetes / kubernetes＃91824でのAPIの変更を考えると、デュアルスタックを1.20のアルファとしてマークすると、必要であることが判明した追加の再実装の余地ができるほど十分に異なります。 私たちは皆ベータに熱心であることを知っていますが、最初に+9,319 −3,261 PRを上陸させ、ほこりを落ち着かせましょう。 :)

@bridgetkromhoutええ、APIの準備状況を判断する前に、 https：//github.com/kubernetes/kubernetes/pull/91824にます。 できるだけ早くそれができることを本当に望んでいます。

こんにちは、みんな、

1.20エンハンスメントシャドウはこちら👋

この拡張機能は1.20に予定されているため、次の重要な今後の日付に注意してください。
11月6日金曜日：第8週-ドキュメントプレースホルダーのPR期限
11月12日木曜日：第9週-コードフリーズ

念のため、すべてのk / k PRとドキュメントPRをこの問題にリンクして、追跡できるようにしてください。

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

こんにちは@ kinarashah @ kikisdeliveryservice -sig-network呼び出しで、1.20のアルファに再分類する必要があることを確認しました。 これは完全な再実装であり、アルファ段階で浸してテストするのに時間がかかります。

こんにちは@ lachie83、1.20ドキュメントシャドウはこちら。

1.20で計画されているこの拡張作業には、新しいドキュメントや既存のドキュメントへの変更が必要ですか？

その場合は、ここの手順に従って、 k/websiteリポジトリのdev-1.20ブランチに対してPRを開いてください。 このPRは現時点では単なるプレースホルダーであり、 11月6日までに作成する必要があります。

また、リリースのドキュメント要件を確認して、リリースのドキュメント要件を理解してください。

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

ありがとう@ reylejano-rxm-kubernetes / website＃24725を開きました

こんにちは@ lachie83

ドキュメントPRを作成していただきありがとうございます。

今後の重要な日付を覚えておいてください。

• 11月6日金曜日：第8週-ドキュメントプレースホルダーPRの締め切りが完了しました！
• 11月12日木曜日：第9週-コードフリーズ
• 11月23日月曜日：第11週-ドキュメントPRのレビュー準備完了

リリースチームが追跡できるように、すべてのk / kPRとドキュメントPRをこの問題にリンクしてください。

こんにちは@ kinarashah @ kikisdeliveryservice -sig-network呼び出しで、1.20のアルファに再分類する必要があることを確認しました。 これは完全な再実装であり、アルファ段階で浸してテストするのに時間がかかります。

ねえ@ lachie83

上記を考えると、これはまだアルファそのままを対象としていると思いますか？ マージする必要のある未処理のPRは表示されません/作業はすでにマージされています。

_コードフリーズが11月12日木曜日の2日後に登場することを思い出してください。 すべてのPRはその日付までにマージする必要があります。そうしないと、例外が必要になります。_

ありがとう！
キルステン

こんにちは、 @ kikisdeliveryservice-はい、IPv4 / IPv6デュアルスタックサポート（再実装）は1.20のアルファ版になります。

この機能強化の進捗状況は次のとおりです。

1）コードはhttps://github.com/kubernetes/kubernetes/pull/91824からマージされます-1.20のアルファ版になります
2）そのコード変更をカバーするドキュメントの更新はhttps://github.com/kubernetes/website/pull/24725/にあります-レビューされ、dev-1.20ブランチにマージされました

この拡張機能で完了していない1.20に必要なものは他にありますか？

@bridgetkromhout明確な更新をありがとう、あなたはすべて元気です！

ServiceSpec LoadBalancerIPは、まだデュアルスタック実装の一部ではないようです。 それをサポートする計画はありますか、それとも私はそれを逃しましたか？

こんにちは@ chenwng-ロードバランサーのクラウドプロバイダーコードへの変更は、現在KEPで定義されている範囲外です：//github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md＃load -balancer-operation。

KEPに変更を加える必要があるかどうかを理解して決定するために、ユースケースと提案された変更を提供することで支援できます。

@chenwngデュアルスタッククラスターでLoadBalancerIPsで作業中のKEPがあります-https ：//github.com/kubernetes/enhancements/pull/1992

情報をありがとう、 @ aramase 、