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

メトリックのモニタリング

CoreDNS は、名前解決の結果などのヘルス メトリックを標準の Prometheus インターフェイスを通じて公開し、CoreDNS サーバーや上流の DNS サーバーのエラー検出を支援します。

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

自己管理の Prometheus インスタンスを使用して Kubernetes クラスターをモニタリングしている場合、Prometheus で関連メトリックを監視し、主要なメトリックにアラートを設定できます。詳細については、「CoreDNS Prometheus 公式ドキュメント」をご参照ください。

ログ

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 以上をサポートできます。DNS リクエストの QPS 要件は、サービスの種類によって大きく異なります。各 CoreDNS Pod のピーク時の CPU 使用率を監視できます。ピーク時に CPU 消費量が 1 コアを超える場合は、CoreDNS レプリカをスケールアウトします。ピーク時の CPU 使用率を判断できない場合は、保守的に 1:8 のレプリカ対ノード比を使用します。

CoreDNS レプリカ数の調整

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

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

  以下の dns-autoscaler をデプロイできます。これは、推奨される 1:8 のレプリカ対ノード比に基づいて、CoreDNS レプリカ数をリアルタイムで自動的に調整します。レプリカ数は、次の数式を使用して計算されます：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 レプリカ数を手動で調整できます。

  kubectl scale --replicas={target} deployment/coredns -n kube-system # {target} を目的のレプリカ数に置き換えてください。

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

  Horizontal Pod Autoscaler (HPA) や CronHPA などのワークロード自動スケーリングメカニズムもレプリカ数を調整できますが、頻繁なスケーリングを実行します。スケールインは解決エラーを引き起こす可能性があるため、CoreDNS にはワークロードの自動スケーリングを使用しないでください。

CoreDNS Pod 仕様の調整

Pod 仕様を変更することで、CoreDNS のリソースを調整することもできます。ACK マネージド Pro クラスターでは、CoreDNS Pod のデフォルトのメモリ制限は 2 GiB で、CPU 制限はありません。一貫したパフォーマンスのためには、CPU 制限を少なくとも 1024m にすることを推奨します。これらのリソースリクエストと制限は、コンソールで調整できます。

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 という単語が含まれている場合、変更は成功です。

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

lameduck は、CoreDNS のグレースフルシャットダウンメカニズムです。CoreDNS が停止または再起動されるときに、進行中のリクエストが適切に完了し、突然中断されないようにします。lameduck メカニズムは次のように機能します。

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

• lameduck モードでは、CoreDNS は新しいリクエストの受け入れを停止しますが、すでに受信したリクエストの処理を、すべてのリクエストが完了するか、lameduck タイムアウト期間が経過するまで続行します。

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

NodeLocal DNSCache を使用する場合、通信チェーンは「アプリケーション → NodeLocal DNSCache (TCP) → CoreDNS (TCP)」となります。デフォルトでは、CoreDNS はソースリクエストと同じプロトコルを使用して上流 DNS サーバーと通信します。これは、ワークロードからの外部ドメイン名解決リクエストが NodeLocal DNSCache と CoreDNS を通過し、TCP を介して VPC DNS サーバー (ECS インスタンスにデフォルトで設定されている 2 つの IP アドレス 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 パフォーマンスが向上します。プラグインの詳細については、「コミュニティドキュメント」をご参照ください。

coredns ConfigMap で multisocket を有効にする必要があります。

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

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

設定の推奨事項：NUM_SOCKETS を、推定 CPU 使用率、CPU リソース制限、および利用可能なクラスターリソースに合わせて調整します。例：

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

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

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

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