CoreDNSをクラスタに合わせてチューニングするための参考情報として、Kubernetes (1.12) 環境でCoreDNS (1.2.5) を使用して実行したテスト結果を共有します。デフォルト設定のCoreDNSに加えて、オプションの_autopath_プラグインを有効にしたCoreDNSもテストしました。 _autopath_プラグインは、Kubernetesの悪名高いndots:5問題が原因でPodが発生するDNSパフォーマンスの低下を透過的に軽減する最適化機能です。これらのテストでは、_autopath_を有効にした場合のメモリ/パフォーマンスのトレードオフを定量化しています。
この記事のガイドと公式は、GCEのクラスタに対する一連のテストに基づいており、環境によって異なる場合があります。このブログ記事は完全な結果からの抜粋です。詳細はこちらをご覧ください。
メモリとPod
大規模なKubernetesクラスタでは、CoreDNSのメモリ使用量は、主にクラスタ内のPodとサービスの数によって影響を受けます。
デフォルトのCoreDNS設定の場合
CoreDNSインスタンスに必要なメモリ量（デフォルト設定を使用）を推定するには、次の式を使用できます。
必要なメモリ量（MB）（デフォルト設定） = (Podの数 + サービスの数) / 1000 + 54
_autopath_プラグインを使用する場合
_autopath_プラグインは、クラスタ外部の名前（例：`infoblox.com`）のクエリのパフォーマンスを向上させるオプションの最適化機能です。 _autopath_プラグインを有効にすると、CoreDNSはPodに関する情報を格納するために、大幅に多くのメモリを使用する必要があります。
_autopath_プラグインを有効にすると、Podのすべての変更を監視する必要があるため、Kubernetes APIにも追加の負荷がかかります。
CoreDNSインスタンスに必要なメモリ量（_autopath_プラグインを使用）を推定するには、次の式を使用できます。
必要なメモリ量（MB）（_autopath_を使用） = (Podの数 + サービスの数) / 250 + 56
CPUとQPS
最大QPSは、CoreDNSを使用するクラスタで`kubernetes/perf-tests/dns`ツールを使用してテストされました。使用された2種類のクエリは、_内部クエリ_（例：`kubernetes`）と_外部クエリ_（例：`infoblox.com`）です。
デフォルトのCoreDNS設定の場合
GCE n1-standard-2ノード上のCoreDNSの単一インスタンス（デフォルト設定）
| クエリタイプ | QPS | 平均レイテンシ（ミリ秒） |
|---|---|---|
| 外部 | 67331 | 12.021 |
| 内部 | 33669 | 2.608 |
1サーバーの観点からは、2.404ミリ秒のレイテンシで33667 QPSを処理していますが、クライアントの観点からは、各名前ルックアップは実際には5つのシリアルルックアップで構成されています。
_autopath_プラグインを使用する場合
CoreDNSの_autopath_プラグインは、ClusterFirst検索リストのペナルティを軽減するオプションです。有効にすると、クライアントが外部名を検索するときのDNSクエリの数が削減されます。
GCE n1-standard-2ノード上のCoreDNSの単一インスタンス（_autopath_プラグインを有効にした場合）
| クエリタイプ | QPS | 平均レイテンシ（ミリ秒） |
|---|---|---|
| 外部 | 31428 | 2.605 |
| 内部 | 33918 | 2.62 |
ここでは、外部クエリの数値が大幅に改善されていることにご注意ください。これは、_autopath_プラグインの最適化によるものです。
_autopath_が有効になっていると、外部クエリのサーバー側のレイテンシがわずかに増加します（+ 8％）。
これは、サーバー側で各検索ドメインを個別にチェックするという追加の作業を行っているためです。
ただし、5回のラウンドトリップではなく1回のラウンドトリップで応答できるため、クライアント側の全体的なパフォーマンスは大幅に向上します。
詳細…
テスト環境とデータの収集方法の詳細については、こちらの完全な結果をご覧ください。