CoreDNS は、クラスター内のデフォルトの DNS サーバです。クラスター内サービスと外部ドメインの両方のすべての名前解決を処理します。CoreDNS が利用できない場合、クラスター内の他のサービスは深刻な影響を受けます。CoreDNS のパフォーマンスと可用性の要件はシナリオによって異なり、デフォルトの構成はすべてのシナリオに適しているわけではありません。このトピックでは、ビジネスシナリオに基づいて CoreDNS コンポーネントを構成する方法に関する推奨事項を説明します。
影響評価
非マネージドモードでは、CoreDNS はクラスター内の他のワークロードと同様に扱われます。その可用性とパフォーマンスは、Pod の数、リソース制限、スケジューリングポリシー、ノード分散などの要因に依存します。
高負荷または不適切な構成は、クラスター内の DNS サービスの品質に直接影響します。CoreDNS は、主に次の 2 種類の問題に直面する可能性があります。
可用性の問題:
構成が正しくないと、ノードレベルおよびゾーンレベルの高可用性が妨げられ、単一障害点のリスクが生じます。
リソースが不足すると Pod がエビクションされ、サービスが中断される可能性があります。
パフォーマンスの問題:
同じノード上の他のワークロードとのリソース競合により、応答レイテンシが増加します。
ノードの負荷が高いと、ネットワーク I/O のパケット損失が発生し、DNS リクエストが失敗します。
CoreDNS Pod の数を調整する
UDP パケットには再送メカニズムがないため、クラスターノードで IPVS の欠陥による UDP パケット損失が発生した場合、CoreDNS Pod をスケールインまたは再起動すると、最大 5 分間、クラスター全体で名前解決のタイムアウトまたは失敗が発生する可能性があります。詳細については、「DNS 解決の問題のトラブルシューティング」をご参照ください。
ワークロードの自動スケーリングを使用しない: 水平ポッド自動スケーリング (HPA) やコンテナ定時スケーリング (CronHPA) などのワークロードの自動スケーリング機能は、Pod の数を自動的に調整できます。ただし、スケールアウトおよびスケールイン操作が頻繁に実行されます。Pod のスケールインは解決の失敗を引き起こす可能性があるため、ワークロードの自動スケーリングを使用して CoreDNS Pod の数を制御しないでください。
コンポーネントの負荷を評価する
DNSPerf などの多くのオープンソースツールは、クラスター内の全体的な DNS 負荷を評価できます。負荷を正確に評価できない場合は、次のガイドラインを使用してください。
すべての場合において、CoreDNS Pod の数を少なくとも 2 に設定します。単一 Pod のリソース制限は、少なくとも 1 CPU コアと 1 GB のメモリである必要があります。
CoreDNS が提供できる名前解決のクエリ/秒 (QPS) の数は、その CPU 消費量に正比例します。NodeLocal DNSCache を使用する場合、各 CPU コアは名前解決リクエストに対して 10,000 QPS 以上をサポートできます。名前解決リクエストの QPS 要件は、ビジネスの種類によって大きく異なります。各 CoreDNS Pod のピーク時の CPU 使用率を監視します。ピークのビジネス時間中に Pod が複数の CPU コアを使用する場合は、CoreDNS レプリカをスケールアウトします。ピーク時の CPU 使用率を判断できない場合は、クラスターノード 8 つごとに 1 つの CoreDNS Pod を控えめにデプロイできます。
評価が完了したら、「自動調整を構成する (推奨)」または「手動で調整する」をご参照の上、調整を行ってください。
自動調整を構成する (推奨)
cluster-proportional-autoscaler コンポーネントは、クラスターノード 8 つごとに 1 つの Pod という推奨ポリシーに基づいて、CoreDNS Pod の数をリアルタイムで自動的に調整します。HPA と比較して、CoreDNS の CPU 負荷メトリックに依存しません。必要なレプリカ数がクラスターサイズに比例するサービスに適しています。
この例では、レプリカ数を計算する数式は `replicas = max(ceil(cores × 1/coresPerReplica), ceil(nodes × 1/nodesPerReplica))` です。`min` および `max` パラメーターは、Pod の数を最小 2、最大 100 に制限します。
手動で調整する
次のコマンドを使用して、CoreDNS Pod の数を手動で調整することもできます。
kubectl scale --replicas=<target> deployment/coredns -n kube-system # <target> をターゲット Pod 数に置き換えます。CoreDNS Pod の仕様を調整する
ACK Pro マネージドクラスターでは、CoreDNS Pod のデフォルトのメモリ制限は 2 GiB で、CPU 制限はありません。CPU 制限を 4096m に設定し、最小値を 1024m とします。コンソールで CoreDNS Pod の構成を調整できます。
CoreDNS Pod の仕様を調整すると、Pod が再起動する場合があります。これにより、クラスター内で DNS レイテンシのタイムアウトや解決の失敗が時折発生する可能性があります。この操作はオフピーク時間中に実行してください。
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
クラスター ページで、目的のクラスターを見つけてその名前をクリックします。左側のペインで、 を選択します。
[ネットワーキング] タブをクリックし、[CoreDNS] カードを見つけます。カード上で [設定] をクリックします。

CoreDNS の構成を変更し、[OK] をクリックします。

専用ノードプールにデプロイする
CoreDNS コンポーネントの Pod を専用ノードプールにデプロイします。これにより、CoreDNS ワークロードがクラスター内の他のアプリケーションから分離され、リソースのプリエンプションから保護されます。
CoreDNS Pod を専用ノードプールにスケジューリングすると、Pod が再起動する場合があります。これにより、クラスター内で DNS レイテンシのタイムアウトや解決の失敗が時折発生する可能性があります。この操作はオフピーク時間中に実行してください。
CoreDNS 用の専用ノードプールを作成する
CoreDNS Pod 用の専用ノードプールを作成します。次の点に注意してください。
CoreDNS は高い計算リソースを必要としませんが、高いネットワークパフォーマンスが必要です。ネットワーク拡張型インスタンスを選択してください。4 CPU コアと 8 GB のメモリの仕様が推奨されます。
デフォルトでは、CoreDNS は 2 つの Pod をデプロイします。ノードプールには少なくとも 2 つのノードが必要です。
ノードプールには、他の Pod がそこにスケジューリングされるのを防ぐために Taint とラベルが必要です。たとえば、
system-addon: system-addonというキーと値のペアを Taint とラベルの両方として追加できます。Taint のEffectをNoScheduleに設定します。次のステップで Taint とラベルを使用します。
詳細については、「ノードプールの作成と管理」をご参照ください。
Pod をスケジューリングするように CoreDNS コンポーネントを構成する
[アドオン] ページで、[CoreDNS] カードを見つけて [設定] をクリックします。
[NodeSelector] セクションで、専用ノードプールのラベルを追加します。
既存の NodeSelector ラベルは削除しないでください。

[Tolerations] セクションで、専用ノードプールの Taint に対応する Toleration を追加します。

[OK] をクリックしてコンポーネントの構成を保存します。次に、次のコマンドを実行して、CoreDNS Pod が専用ノードプールにスケジューリングされていることを確認します。
kubectl -n kube-system get pod -o wide --show-labels | grep coredns
スケジューリングポリシーを使用して CoreDNS の高可用性を実現する
CoreDNS のノードアフィニティ、ポッドアンチアフィニティ、およびトポロジー対応スケジューリングポリシーは、デプロイメント中にのみ有効になります。ノードまたはゾーンの構成が変更された場合は、ACK コンソールに移動し、coredns デプロイメントを見つけて [再デプロイ] をクリックして、CoreDNS Pod が高可用性のために分散されていることを確認します。
ポッドアンチアフィニティ
デフォルトでは、CoreDNS は 2 つの Pod をデプロイします。ポッドアンチアフィニティポリシーを使用して、Pod を異なるノードに分散させます。これにより、ノードレベルのディザスタリカバリが実現します。ポッドアンチアフィニティポリシーを有効にするには、Pod のリソース request に基づいて十分なリソースを持つノードがクラスター内に少なくとも 2 つ利用可能であることを確認してください。ノードには次のラベルがあってはなりません。
k8s.aliyun.com: true(ノードの自動スケーリング機能が有効になっているノード)type: virtual-kubelet(仮想ノード)alibabacloud.com/lingjun-worker: true(Lingjun ノード)
トポロジー対応スケジューリング
デフォルトでは、CoreDNS はトポロジー対応スケジューリングを使用して、Pod を異なるゾーンにできるだけ均等に分散します。バランス条件が満たされない場合、スケジューリングを拒否します (`DoNotSchedule`)。これにより、ゾーンレベルのディザスタリカバリが実現します。このメカニズムにはいくつかの制限があります。このメカニズムが効果的に機能するようにするには、次の要件を満たしてください。
クラスター内のノードが少なくとも 2 つの異なるゾーンにあることを確認してください。各ゾーンには、CoreDNS をスケジューリングできる十分なリソースを持つノードが少なくとも 1 つ必要です。
ノードに、デフォルトで設定されている正しく一貫性のある
topology.kubernetes.io/zoneラベルがあることを確認してください。そうでない場合、トポロジー認識が失敗したり、Pod が単一ゾーンに集中したりする可能性があります。クラスターを v1.27 以降に、CoreDNS を v1.12.1.3 以降にアップグレードしてください。クラスターのバージョンが v1.27 より前の場合、トポロジー対応スケジューリングは `matchLabelKeys` をサポートしません。CoreDNS がローリングアップデートを実行すると、最終的な Pod の分散が不均一になったり、すべてのゾーンをカバーしなかったりする可能性があります。