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

メトリックとダッシュボード

CoreDNS は、CoreDNS およびアップストリーム DNS サーバーの例外を検出するために、標準の Prometheus インターフェイスを通じてヘルスおよびパフォーマンスメトリックを公開します。

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

• セルフマネージド Prometheus：CoreDNS メトリックをスクレイピングし、重要な指標に対するアラートを設定します。「CoreDNS Prometheus 公式ドキュメント」をご参照ください。

ログ分析

DNS の例外が発生した場合、CoreDNS のログは根本原因の診断に不可欠です。DNS 名前解決のロギングと Simple Log Service (SLS) の収集を有効にすることを推奨します。詳細については、「CoreDNS ログの分析と監視」をご参照ください。

Kubernetes イベントの配信

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

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

1. CoreDNS の ConfigMap を編集します。

   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 の負荷評価

DNSPerf などのオープンソースツールを使用して、DNS パフォーマンスをベンチマークします。カスタマイズされた評価を実行できない場合は、以下のベースライン推奨事項に従ってください：

• 最小レプリカ数：冗長性のために、常に少なくとも 2 つの Pod を維持します。

• リソース制限：Pod ごとに少なくとも 1 CPU コアと 1 GiB メモリ のリソース制限を設定します。

• パフォーマンスのスケーリング：CoreDNS のパフォーマンスは CPU と線形にスケーリングします。NodeLocal DNSCache が有効な場合、1 つの CPU コアで通常 10,000 QPS 以上を処理できます。

• レプリカ比率：ピーク時の CPU 使用量を監視できない場合は、保守的な 1:8 の Pod 対ノード比率 を使用します (クラスターノード 8 つごとに CoreDNS Pod を 1 つ追加します)。

CoreDNS Pod のスケーリング

CoreDNS Pod の数は、利用可能なコンピューティングリソースを決定します。評価結果に基づいて Pod 数を調整します。

• 推奨ポリシーに基づく自動スケーリング

  dns-autoscaler をデプロイして、推奨ポリシー (クラスターノード 8 つごとに Pod 1 つ) に基づいて CoreDNS のレプリカを自動的に調整します。

  式：replicas = max(ceil(cores × 1/coresPerReplica), ceil(nodes × 1/nodesPerReplica))

  これにより、クラスターが成長しても 1:8 の比率が維持されます。

  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 数に置き換えます

• HPA または CronHPA を使用しない

  ワークロードの自動スケーリングメカニズム (HPA や CronHPA など) は Pod 数を自動的に調整できますが、頻繁なスケーリング操作を実行します。Pod のスケールインによって引き起こされる名前解決の例外 (前述の IPVS UDP の問題) のため、ワークロードの自動スケーリングを使用して CoreDNS の Pod 数を制御しないでください。

CoreDNS Pod 仕様の最適化

CoreDNS のリソースを調整するもう 1 つの方法は、Pod の仕様を変更することです。ACK マネージド Pro 版クラスターでは、CoreDNS Pod のデフォルトのメモリ制限は 2 GiB で、CPU 制限はありません。一貫したパフォーマンスを確保するために、CPU 制限を 4096m (最小 1024m) に設定します。これらのリソースリクエストと制限はコンソールで調整できます。

CoreDNS Pod のスケジューリング

kube-dns サービスのアフィニティ構成の無効化

autopath プラグインの無効化

一部の初期の CoreDNS バージョンでは autopath プラグインが有効になっており、特定のまれなケースで名前解決エラーを引き起こす可能性があります。有効になっているかどうかを確認し、構成ファイルを編集して無効にします。詳細については、「Autopath issue #3765」をご参照ください。

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

2. autopath @kubernetes の行を削除し、変更を保存します。

3. CoreDNS Pod の実行ステータスとログを確認します。ログに reload という単語が含まれていれば、変更は成功です。

グレースフルシャットダウンの構成

lameduck メカニズムは、CoreDNS プロセスが終了しようとするとき (更新または再起動中)、終了する前に既存のリクエストを処理することを保証します。

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

• lameduck モードでは、CoreDNS は指定された期間、すでに受信したリクエストの処理を続けながら、システムに新しいリクエストの送信を停止するよう信号を送ります。

アップストリームプロトコル (prefer_udp) の最適化

NodeLocal DNSCache を使用する場合、通信チェーンは アプリケーション -> NodeLocal DNSCache (TCP) -> CoreDNS (TCP) となります。デフォルトでは、CoreDNS はその後、TCP を介してアップストリームの VPC DNS (100.100.2.136/138) に到達しようとします。

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

readiness プローブ用の ready プラグインの構成

CoreDNS v1.5.0 以降では、readiness プローブが機能するために ready プラグインが必須です。

1. 次のコマンドを実行して、CoreDNS ConfigMap を開きます。

   kubectl -n kube-system edit configmap/coredns

2. ファイルに 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 ConfigMap で multisocket を有効にします：

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

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

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

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

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

最適な構成を決定するには、さまざまな設定で QPS と負荷をテストしてください。

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