cc @luxas @jbeda @mattmoyer @miekg

@ kubernetes / sig-network-feature-requests

このスイッチの背後にある議論は何ですか？

こんにちはクリスチャン、

ここに少し背景があります。 CoreDNSは別のCNCFプロジェクトであり、kube-dnsが基づいているSkyDNSの後継です。 これは柔軟で拡張可能な信頼できるDNSサーバーであり、KubernetesAPIへの直接統合を構築しました。 これは、 dns仕様に準拠して、クラスターDNSとして機能できます。 我々は@thockin、@matchstickとKubeCon周り@bowei昨年との協議を開始し、彼らは原則的にそれに開いているが、もちろんそれは正しい選択であることが証明される必要があります。

切り替える理由としては、CoreDNSは単一の実行可能ファイルと単一のプロセスであるため、kube-dnsよりも可動部分が少なくなっています。 Goで記述されているため、メモリセーフです（kube-dnsにはそうでないdnsmasqが含まれています）。 kube-dnsではサポートされていない多くのユースケースをサポートしています。 汎用の権威DNSサーバーとして、kube-dnsが合理的に追加することを期待できなかった多くの機能を備えています。

introまたはcoredns.ioも確認することをおウェビナーもあります。

これについての提案を期待します。

わかりました。 https://github.com/kubernetes/community/blob/master/contributors/design-proposals/Design_Proposal_TEMPLATE.mdに基づいていると思い

わかりました、これが提案です。 これを参照しているすべてのコミットについて申し訳ありません。

https://github.com/kubernetes/community/pull/1100

これが閉じることを意図していたかどうかわからない

/ reopen

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

@spxtrフォークのクロスリンクのためにこれを閉じるのをやめる方法はありますか？

これはGitHubのバグ機能です。 フォークを更新したときに閉じる動作を停止するように動作を変更するように依頼しましたが、「それを望まない場合は、コミットメッセージで「fixes＃soandso」と言うのをやめてください」という応答がありました。

コミットメッセージを検証するツールはどうですか？

test-infraで議論を動かしてみましょう。 話し合う問題を開きます。

それが可能だ。 「fixes＃number」ではなく「fixessomeorg / repo＃number」と言った場合にのみ問題が発生します。後者の場合、問題が存在しないフォークで問題をクローズしようとするためです。

@johnbelamaric ：wave：ドキュメントPRを

Doc PR： https ：

@luxas ：昨日SIG Networkで、CoreDNSがk8s1.10でベータ版になることが検証されました。

ここでステージ/ベータにフラグを立てる必要がありますか？

ベータ1.10のマーク

@johnbelamaricは、1.10のドキュメントを更新する必要があるように見えますか？ 役立つ場合： https ：
よろしければお手伝いできます。 機能状態フラグを更新する必要があるように見えますが、1.10リリースとベータ版への移行をどのように参照するかがわかりません。

["Re：[kubernetes / features] Switch de ..."で[email protected]を引用]

@johnbelamaricは、1.10のドキュメントを更新する必要があるように見えますか？ 役立つ場合： https ：
よろしければお手伝いできます。 機能状態フラグを更新する必要があるように見えますが、1.10リリースとベータ版への移行をどのように参照するかがわかりません。

ここで正確に何が必要ですか。 リンクしたドキュメントはベータ版とだけ言う必要がありますか？
CoreDNSバージョンを使用するには？ それは1.0.6以上である必要があります。

@miekgドキュメントを更新できるようです。 ラングリングマージ競合atm、ここにPRを投稿し、修正が完了したらレビュー担当者として追加します。

@ Bradamant3申し出に感謝します、しかしあなたが本当にそれをしたいのでなければ、私は今日これの世話をすることができますか？

https://github.com/kubernetes/website/pull/7638

頑張れ！ ありがとう！

@johnbelamaric
1.11でこれについて何か計画はありますか？

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

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

cc @idvoretskyi

この機能は

• k8sv1.9のALPHA
• k8sv1.10のベータ版
• GAの進行中のKEPがあります： //github.com/kubernetes/community/pull/1956

@justaugustusありがとう-私はメンバーではないので、ラベルを変更するなどのアクセス権がありません。しかし、 @ fturibが言うように、1.11のGAを対象としています。 @rajansandeepラベルを変更できますか？

ラベルを変更する権限がないようです。
@cmluciano @idvoretskyiは、ここでラベルを更新できます。

更新しました

@cmlucianoありがとうございます！

完全。 みんなアップデートしてくれてありがとう！

これは現在変更されており、オプションとして利用可能なCoreDNSとデフォルトとして利用可能なCoreDNSの2つの機能に分割する必要があります。 問題の名前を変更して、デフォルトにするために新しい問題を作成できますか（1.12をターゲット）？

@johnbelamaric / @ cmluciano-この機能の説明の名前を変更し、デフォルトのDNSプラグインとしてCoreDNSを有効にすることを中心に新しい機能（＃566）を作成しました。 PTALで、その機能の問題について更新する必要がある詳細があるかどうかをお知らせください。

@justaugustusありがとう！

@justaugustus現在のものと＃566の違いは何ですか？

@idvoretskyi現在のものはデフォルトでそれを有効にしません。 有効にできるGA機能を宣言するだけです。 デフォルトで（新規インストールおよびアップグレード時に）有効にするのは後で行われます。

@johnbelamaricそれは明らかです、ありがとう。

ただし、そのために2つの機能の問題が必要かどうかはわかりません。 CoreDNSがv1.11のGAである場合、デフォルトで独自のペースで有効にするのは、すべての展開ツール（kubeadm、kops、GKE、AKS、EKSなど）次第です。 一部のインストーラーオプションはOSSの世界に到達できないため、すべてのインストーラーオプションのオプションのデフォルトを指定することはできません。 これだけで行きます。 GKEのような_特定の展開_の機能としてCoreDNSの有効化を追跡したい場合は、オプションで別の問題でそれを行うことができます。

それはあなたにとって意味がありますか？

@luxas私はあなたの理解しています。 ただし、どのオプションを使用するかについて、ある時点で推奨事項を提供する必要はありませんか？ ある時点でkube-dnsを廃止したい場合はどうなりますか？

この「コンポーネントの交換」は新しい領域であるため、最善のプロセスを見つけようとしています。

CoreDNSがGAの場合、新しいものであるため、新しいクラスターのデフォルトになると思います。
これは、少なくとも私にとっては機能ステータスからの暗黙の推奨事項です。
CoreDNSがv1.11のすべての新しいクラスターで技術的にデフォルトになる準備ができている場合は、今すぐGAに移行し、kube-dnsを廃止します。 kube-dnsは、 https： //kubernetes.io/docs/reference/のGA: 1 year or 2 releases (whichever is longer)時点で、1年間（約4リリース、v1.15まで）の下位互換性のオプションとしてサポートされます。非推奨-ポリシー/

@luxas同様の機能を提供するいくつかのGAオプションから選択する追加機能（まだない場合）があると思います。 たとえば、kube-proxyにiptablesとipvsのどちらを使用するか。 そのような状況を管理するためのモデルが必要だと思います。

@johnbelamaric私は1.11の
また、この機能についていくつかのe2eテストの変更があるようです。 私は、これらのテストのどれを1.11の適合スイートに昇格させるべきかを確認するためにフォローアップしています。
Conformance WGとSig-Archによって概説されている、適合範囲を拡大するプロセスの一環として、stable / GAに移行する機能がConformanceスイートで表現されることを期待してい

私は、既存のDNS適合性テストがこれをカバーすることを期待します。 私
corednsの使用が準拠している必要があるとは思わないでしょう。

とはいえ、DNS適合性テストの範囲は十分です。
DNSの最小要件をカバーしますか？

@AishSundar ：CoreDNSがkube-dnsに取って代わります。 そのため、CoreDNSが既存のDNS適合性テストに準拠していることをすでに確認しました。
ここで実行されているCoreDNSのスイートテストがあります： http： //k8s-testgrid.appspot.com/sig-network-gce#gci -gce-coredns（これは適合性よりも大きい）

そのため、CoreDNSはすでにConformanceスイートに表現されています（kube-dnsと同じ、それが置き換える機能）。

また、CoreDNSがe2eで実行されているすべてのDNSテストに準拠していることを確認しました。 そのため、e2eテストにいくつかの変更があります。 しかし、それらは適合スイートの一部ではありません。

既存のテストをCoreDNSに適合させ、Configmapの変更によって構成を確認します： https ：

スケーラビリティに関する特定のDNS関連のテストを追加して、DNSの新しいテストを作成します（sig-networkingからの質問）： https ：

IPv6ユースケースのすべてのDNSテストを拡張します： https ：

@smarterclayton CoreDNSは、デフォルト構成に準拠しています。

ありがとう

2018年5月24日木曜日午前9:04、ジョンベラマリック[email protected]
書きました：

@smarterclayton https://github.com/smarterclaytonCoreDNSは準拠しています
デフォルト構成で。

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

ここで説明とPRポインタを提供してくれた

@ johnbelamaric-
1.11機能追跡スプレッドシートをもう1回スイープしてい
この機能の広告申込情報の不完全な/空白のフィールドに入力していただけませんか。

@justaugustus 「ドラフト」に更新しました。 さまざまな状態でいくつかのPRがマージされ、ドキュメントのレビューが行われています。 追跡の問題へのリンクはすでにそこにあります。

@johnbelamaricアップデートしてくれてありがとう！
その追跡の問題についてはすべて問題ないようです。 私の唯一の注意点は、追跡の問題は、Kubeadmプロジェクトではなく、 k/kまたはk/website問題として適しているということです。

機能が1.11のGAであるため、これを閉じます。 それでも追跡する必要がある場合は、お気軽に再開してください。
/選ぶ