Container Service for Kubernetes:DNSのベストプラクティス

メトリクス

CoreDNS は、標準の Prometheus インターフェイスを介して、解決結果を含むヘルス メトリクスを公開します。これにより、CoreDNS サーバー、さらにはアップストリーム DNS サーバーの異常を検出できます。

Managed Service for Prometheus は、CoreDNS 用の組み込みメトリクスモニタリングダッシュボードとアラートルールを提供します。ACK コンソールで Prometheus とそのダッシュボード機能を有効にできます。詳細については、「CoreDNS コンポーネントの監視」をご参照ください。

セルフマネージドの Prometheus インスタンスを使用して Kubernetes クラスターを監視する場合、Prometheus で関連するメトリクスを監視し、主要な指標に対するアラートを設定できます。詳細については、「Prometheus に関する CoreDNS 公式ドキュメント」をご参照ください。

ログ

DNS に異常が発生した場合、CoreDNS のログを使用すると根本原因を迅速に診断できます。CoreDNS のドメイン名解決ログを有効にし、Log Service でそのログを収集することを推奨します。詳細については、「CoreDNS ログの分析と監視」をご参照ください。

Kubernetes イベント配信

CoreDNS v1.9.3.6-32932850-aliyun 以降では、k8s_event プラグインを有効にして、重要な CoreDNS ログを Kubernetes イベントとしてイベントセンターに配信できます。k8s_event プラグインの詳細については、「k8s_event」をご参照ください。

この機能は、新しい CoreDNS デプロイメントではデフォルトで有効になっています。以前のバージョンから CoreDNS v1.9.3.6-32932850-aliyun 以降にアップグレードする場合、手動で設定ファイルを変更して有効にする必要があります。

1. 次のコマンドを実行して、CoreDNS 設定ファイルを開きます。

   kubectl -n kube-system edit configmap/coredns

2. kubeapi と k8s_event プラグインを追加します。

   apiVersion: v1
   data:
     Corefile: |
       .:53 {
           errors
           health {
               lameduck 15s
           }
           // 追加開始 (他の差分は無視してください)
           kubeapi
           k8s_event {
             level info error warning // info、error、warning ステータスの重要なログを配信します
           }
           // 追加終了
           kubernetes cluster.local in-addr.arpa ip6.arpa {
               pods verified
               fallthrough in-addr.arpa ip6.arpa
           }
           // ... (残りの内容は省略)
       }

3. CoreDNS Pod の動作状況とログを確認します。ログに reload という単語が含まれている場合、変更は成功です。

CoreDNS コンポーネントの負荷評価

クラスターで DNS ストレステストを実行して、コンポーネントの負荷を評価できます。この評価には、DNSPerf をはじめとする多くのオープンソースツールが役立ちます。クラスターの DNS 負荷を正確に評価できない場合は、以下の推奨事項に従ってください。

• CoreDNS Pod の数は常に少なくとも 2 に設定し、単一 Pod のリソース制限は少なくとも 1 コア、1 GiB とします。

• CoreDNS のドメイン名解決 QPS は、その CPU 消費量と正の相関があります。NodeLocal DNSCache が有効な場合、各 CPU コアは 10,000 QPS 以上をサポートできます。ドメイン名リクエストの QPS 需要は、サービスの種類によって大きく異なります。各 CoreDNS Pod のピーク時の CPU 使用率を監視できます。Pod がピーク時に 1 CPU コア以上を使用する場合、CoreDNS レプリカのスケールアウトを推奨します。ピーク時の CPU 使用率を判断できない場合は、保守的に Pod とクラスターノードの比率を 1:8 で使用できます。つまり、8 つのクラスターノードを追加するごとに、1 つの CoreDNS Pod を追加します。

CoreDNS Pod 数の調整

CoreDNS Pod の数は、CoreDNS が使用できるコンピューティングリソースを直接決定します。評価に基づいて CoreDNS Pod の数を調整できます。

• 推奨ポリシーに基づいた自動調整

  以下の dns-autoscaler をデプロイできます。これは、推奨ポリシー (Pod とクラスターノードの比率 1:8) に基づいて、CoreDNS Pod の数をリアルタイムで自動的に調整します。Pod の数は、次の式を使用して計算されます：replicas = max(ceil(cores × 1/coresPerReplica), ceil(nodes × 1/nodesPerReplica))、そして計算結果は max および min パラメーターによって制限されます。

  dns-autoscaler

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: dns-autoscaler
    namespace: kube-system
    labels:
      k8s-app: dns-autoscaler
  spec:
    selector:
      matchLabels:
        k8s-app: dns-autoscaler
    template:
      metadata:
        labels:
          k8s-app: dns-autoscaler
      spec:
        serviceAccountName: admin
        containers:
        - name: autoscaler
          image: registry.cn-hangzhou.aliyuncs.com/acs/cluster-proportional-autoscaler:1.8.4
          resources:
            requests:
              cpu: "200m"
              memory: "150Mi"
          command:
          - /cluster-proportional-autoscaler
          - --namespace=kube-system
          - --configmap=dns-autoscaler
          - --nodelabels=type!=virtual-kubelet
          - --target=Deployment/coredns
          - --default-params={"linear":{"coresPerReplica":64,"nodesPerReplica":8,"min":2,"max":100,"preventSinglePointFailure":true}}
          - --logtostderr=true
          - --v=9

• 手動調整

  次のコマンドを実行して、CoreDNS Pod の数を手動で調整できます。

  kubectl scale --replicas={target} deployment/coredns -n kube-system # {target} を目的の Pod 数に置き換えます。

• ワークロードの自動スケーリングを使用しない

  Horizontal Pod Autoscaler (HPA) や CronHPA のようなワークロードの自動スケーリング機能も Pod 数を自動調整できますが、頻繁にスケーリング操作を実行します。Pod のスケールイン時には解決例外が発生するため、ワークロードの自動スケーリングを使用して CoreDNS Pod の数を制御しないでください。

CoreDNS Pod 仕様の調整

CoreDNS リソースを調整するもう 1 つの方法は、Pod 仕様を変更することです。ACK managed Pro cluster では、CoreDNS Pod のデフォルトのメモリ制限は 2Gi で、CPU 制限はありません。CPU 制限は 4096m に設定することを推奨します。また、CPU 制限の最小値は 1024m とします。コンソールで CoreDNS Pod の設定を調整できます。

CoreDNS Pod のスケジューリング

単一ノードまたは単一アベイラビリティーゾーンの障害を避けるため、CoreDNS Pod を異なるアベイラビリティーゾーンおよびクラスターノードにまたがってデプロイすることを推奨します。v1.8.4.3 より前の CoreDNS コンポーネントバージョンには、ノードレベルでのデフォルトのソフトアンチアフィニティポリシーがあり、リソースが不足している場合に一部またはすべての Pod が同じノードにデプロイされる可能性があります。この場合、Pod を削除して再スケジューリングをトリガーするか、コンポーネントを最新バージョンにアップグレードしてください。v1.8 より前の CoreDNS コンポーネントバージョンは現在メンテナンス対象外のため、できるだけ早くアップグレードする必要があります。

CoreDNS が実行されるクラスターノードは、CPU またはメモリを完全に使い切るべきではありません。これは、ドメイン名解決の QPS とレスポンスレイテンシーに影響するためです。クラスターノードの状況が許す場合は、カスタムパラメーターを使用して CoreDNS を専用クラスターノードにスケジュールし、安定したドメイン名解決サービスを提供することを検討してください。

kube-dns のセッションアフィニティの無効化

autopath プラグインの無効化

古いバージョンの CoreDNS の一部では autopath プラグインが有効になっており、一部のエッジケースで名前解決エラーが発生する可能性があります。有効になっているかどうかを確認し、設定ファイルを編集して無効化してください。詳細については、「Autopath」をご参照ください。

1. kubectl -n kube-system edit configmap coredns コマンドを実行して、CoreDNS 設定ファイルを開きます。

2. autopath @kubernetes 行を削除して、ファイルを保存します。

3. CoreDNS Pod の動作状況とログを確認します。ログに reload という文字列が含まれている場合は、変更は成功です。

グレースフルシャットダウンの設定

lameduck は、グレースフルシャットダウンを実現する CoreDNS の仕組みです。CoreDNS を停止または再起動する必要がある場合に、処理中のリクエストが突然中断されることなく完了するようにします。lameduck は次のとおり動作します：

• CoreDNS プロセスが終了しようとすると、Lameduck モードに入ります。

• lameduck モードでは、CoreDNS は新しいリクエストの受付を停止し、既存のリクエストはすべて完了するか、lameduck のタイムアウト期間を超過するまで処理を継続します。

forward プラグインのデフォルトプロトコルの設定

NodeLocal DNSCache は TCP を使用して CoreDNS と通信します。CoreDNS は、その後、受信リクエストと同じプロトコルを使用してアップストリーム DNS サーバーと通信します。そのため、デフォルトでは、業務コンテナからクラスター外のドメイン名を解決するリクエストは、NodeLocal DNSCache と CoreDNS を経由し、最終的に TCP で VPC DNS サーバー (デフォルトでは ECS インスタンス上の 100.100.2.136 および 100.100.2.138) に到達します。

# 変更前
forward . /etc/resolv.conf
# 変更後
forward . /etc/resolv.conf {
  prefer_udp
}

ready プラグインの設定

CoreDNS 1.5.0 より後のバージョンでは、Readiness プローブを有効にするために ready プラグインを設定する必要があります。

1. 次のコマンドを実行して、CoreDNS 設定ファイルを開きます。

   kubectl -n kube-system edit configmap/coredns

2. ファイルに ready 行が含まれているかどうかを確認します。含まれていない場合は、ready 行を追加し、Esc キーを押して :wq! を入力してから Enter キーを押し、変更した設定ファイルを保存して編集モードを終了します。

   apiVersion: v1
   data:
    Corefile: |
     .:53 {
       errors
       health {
         lameduck 15s
       }
       ready # この行が存在しない場合は追加してください。インデントは Kubernetes と整合させてください。
       kubernetes cluster.local in-addr.arpa ip6.arpa {
         pods verified
         fallthrough in-addr.arpa ip6.arpa
       }
       prometheus :9153
       forward . /etc/resolv.conf {
         max_concurrent 1000
               prefer_udp
       }
       cache 30
       loop
       log
       reload
       loadbalance
     }

3. CoreDNS Pod の動作状況とログを確認します。ログに reload という文字列が含まれている場合は、変更は成功です。

multisocket プラグインによるパフォーマンスの向上

CoreDNS v1.12.1 では multisocket プラグインが導入されました。このプラグインを有効にすると、CoreDNS は同じポートで複数のソケットを使用してリッスンできるようになり、高 CPU のシナリオで CoreDNS のパフォーマンスが向上します。プラグインの詳細については、「community documentation」をご参照ください。

coredns ConfigMap を使用して multisocket を有効にする必要があります：

.:53 {
        ...
        prometheus :9153
        multisocket [NUM_SOCKETS]
        forward . /etc/resolv.conf
        ...
}

NUM_SOCKETS は、同じポートでリッスンするソケット数を指定します。

推奨設定：推定 CPU 使用率、CPU リソース制限、および利用可能なクラスターリソースに合わせて NUM_SOCKETS を設定します。たとえば、次のとおりです：

• ピーク時に CoreDNS が 4 コアを消費し、利用可能なコア数が 8 の場合は、NUM_SOCKETS を 2 に設定します。

• ピーク時に CoreDNS が 8 コアを消費し、利用可能なコア数が 64 の場合は、NUM_SOCKETS を 8 に設定します。

最適な設定を判断するために、異なる設定で QPS と負荷をテストすることを推奨します。

NUM_SOCKETS を指定しない場合、デフォルト値は GOMAXPROCS です。この値は CoreDNS Pod の CPU 制限と同じです。Pod の CPU 制限が設定されていない場合、この値は Pod が実行されているノード上の CPU コア数と同じです。