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

監視メトリクス

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

Prometheus for ACK には、組み込みの CoreDNS 監視メトリクスとアラートルールが含まれています。Container Service for Kubernetes コンソールで Prometheus とダッシュボード機能を有効にできます。詳細については、「CoreDNS コンポーネントの監視」をご参照ください。

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

オペレーションログ

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

Kubernetes イベント配信

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

新しくデプロイされた CoreDNS インスタンスでは、この機能はデフォルトで有効になっています。古いバージョンの CoreDNS からアップグレードする場合は、設定ファイルを手動で変更してこの機能を有効にする必要があります。

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 の負荷を正確に評価できない場合は、以下の推奨事項に従ってください：

• 常に少なくとも 2 つの CoreDNS Pod をデプロイし、各 Pod のリソース制限を少なくとも 1 CPU コア、1 GB メモリとします。

• CoreDNS の QPS 容量は CPU 使用率と直接相関しています。NodeLocal DNSCache を使用すると、各 CPU コアは 10,000 QPS 以上をサポートできます。ビジネスワークロードの DNS QPS 要件は大きく異なります。各 CoreDNS Pod のピーク時の CPU 使用率を監視する必要があります。ビジネスのピーク時に CPU 使用率が 1 コアを超える場合は、CoreDNS のレプリカをスケールアウトしてください。ピーク時の CPU 使用率が不明な場合は、保守的な対策として、クラスターの 8 ノードごとに 1 つの CoreDNS Pod をデプロイします。

CoreDNS Pod 数の調整

CoreDNS Pod の数は、利用可能な計算リソースを直接決定します。評価に基づいてこの数を調整できます。

• 推奨ポリシーに基づいて Pod 数を自動的に調整する

  以下の dns-autoscaler をデプロイできます。これは、クラスターの 8 ノードごとに 1 Pod という推奨比率に基づいて、CoreDNS 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 数に置き換えてください

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

  水平 Pod 自動スケーリング (HPA) や CronHPA などのワークロード自動スケーリングメカニズムは、Pod の数を自動的に調整できますが、頻繁なスケーリング操作をトリガーします。前述のように、Pod のスケールイン中に発生する可能性のある解決の異常のため、CoreDNS Pod の数を制御するためにワークロード自動スケーリングを使用しないでください。

CoreDNS Pod 仕様の調整

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

CoreDNS Pod のスケジューリング

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

CPU またはメモリ使用率がフルのクラスターノードに CoreDNS をデプロイすることは避けてください。これは DNS の 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 のグレースフルシャットダウンの設定

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

• CoreDNS が終了すると、Lameduck モードに入ります。

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

Forward プラグインがアップストリーム VPC DNS サーバーと通信するためのデフォルトプロトコルの設定

NodeLocal DNSCache は TCP を使用して CoreDNS と通信します。CoreDNS は、アップストリーム DNS サーバーと通信する際に、受信リクエストと同じプロトコルを使用します。デフォルトでは、アプリケーションコンテナからの外部ドメイン解決リクエストは、NodeLocal DNSCache と CoreDNS を経由し、TCP を使用して VPC DNS サーバー (100.100.2.136 および 100.100.2.138) に到達します。

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

Ready readiness プローブプラグインの設定

1.5.0 より後の CoreDNS バージョンでは、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 の解決パフォーマンスを向上させる

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 リソース制限、およびクラスターで利用可能なリソースに合わせることを推奨します。例：

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

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

最適な設定を決定するには、さまざまな設定をテストし、QPS と負荷を測定します。

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