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 以上をサポートできます。ドメイン名リクエストの QPS 需要は、サービスの種類によって大きく異なります。各 CoreDNS Pod のピーク時の CPU 使用率を監視できます。ピーク時に Pod の CPU 使用量が 1 コアを超える場合、CoreDNS レプリカをスケールアウトすることを推奨します。ピーク時の CPU 使用率を判断できない場合は、控えめに Pod とクラスターノードの比率を 1:8 で使用できます。つまり、追加するクラスターノード 8 つごとに、CoreDNS Pod を 1 つ追加します。

CoreDNS Pod 数の調整

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

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

  次の 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 Pod の数を手動で調整できます。

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

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

  Horizontal Pod Autoscaler (HPA) や CronHPA などのワークロードの自動スケーリング機能も Pod 数を自動的に調整できますが、頻繁なスケーリング操作が発生します。Pod のスケールイン時に DNS 名前解決の例外が発生するため、ワークロードの自動スケーリング機能で 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 コンポーネントバージョンは保守されなくなったため、できるだけ早くアップグレードする必要があります。

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

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

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 のパフォーマンスが向上します。プラグインの詳細な説明については、「コミュニティドキュメント」をご参照ください。

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 コア数に等しいです。