Azure Kubernetes Service (AKS) で LocalDNS を構成する

適用対象: ✔️ AKS 自動 ✔️ AKS Standard

ほとんどの運用ワークロードでは、AKS の推奨される運用環境対応の既定値は AKS Automatic です。 LocalDNS は、AKS 自動クラスターで事前構成されています。 AKS Standard では、LocalDNS の動作は、Kubernetes のバージョンとノード プールの既存の LocalDNS プロファイルによって異なります。

LocalDNS は、クラスターで実行されているワークロードの DNS 解決のパフォーマンスと回復性を向上させる AKS の機能です。 各ノードで DNS プロキシを実行することで、LocalDNS は DNS クエリの待機時間を短縮し、一時的なネットワーク中断時の信頼性を向上させ、カスタマイズが必要な場合に高度なキャッシュと転送の制御を提供します。

アーキテクチャの詳細や主要な機能など、LocalDNS とは何かについては、Azure Kubernetes Service (AKS)の DNS 解決に関するページを参照してください。

AKS Automatic と AKS Standard における LocalDNS の動作

Preferred モードの互換性チェック

Kubernetes 1.37 以降、AKS Standard では、これらのプールの作成時または更新時に、明示的な LocalDNS プロファイルなしで、 Preferred モードが対象ノード プールに割り当てられます。 AKS では、明示的に構成されたプロファイルが保持されます。

Preferred モードで LocalDNS を最初に有効にする前に、AKS は次の互換性要件を確認します。 要件が満たされていない場合、LocalDNS は無効のままです。

AKS が Preferred モードで LocalDNS を有効にすると、その後の関連のないノード プールの更新中も有効になります。 無効にするには、LocalDNS mode を明示的に Disabled に設定します。

LocalDNS 構成のベスト プラクティス

AKS クラスターに LocalDNS を実装する場合は、次のベスト プラクティスを検討してください。

• 最小限の構成から始める: Preferred モードに移行する前に、Required モードを使用して LocalDNS 構成構文を検証する単純な構成から始めます。 Preferred モードでは、LocalDNS を有効にせずに構成が検証されるため、クラスターに影響を与えずに構成エラーを早期にキャッチできます。
• 適切なキャッシュ戦略を実装する: ワークロードの特性に基づいてキャッシュ設定を構成します。
  • レコードを頻繁に変更する場合は、短い cacheDurationInSeconds 値を使用します。 これを行うときは、cacheDurationInSeconds が DNS レコード TTL の上限として機能しますが、増やさないことに注意してください。 結果として得られる TTL は、アップストリームから返されるもの、またはキャッシュ プラグインで設定されているものの小さい値です。
  • 安定したレコードの場合は、長いキャッシュ期間を使用して DNS クエリを減らします。
  • DNS の停止中にサービスを維持するために、適切な設定で serveStale を有効にします。
  • LocalDNS でのキャッシュ保存はベスト エフォートベースで動作し、ステール レスポンスを保証するものではありません。 キャッシュは 256 個のシャードに分割され、エントリの最大数は既定で 10,000 件であり、各シャードに約 39 件のエントリを保持できるようにしています。 シャードがいっぱいになり、新しいエントリを追加する必要がある場合は、既存のエントリの 1 つがランダムに選択されて削除されます。 古いエントリや有効期限が切れたエントリへの優先付けはありません。 結果的に、特にクエリ ボリュームが高い場合、古いレコードが常に使用可能であるとは限りません。
• DNS パフォーマンスの監視: LocalDNS を有効にした後、次を使用してアプリケーションの DNS パフォーマンスを監視します。
  • アプリケーションのパフォーマンス メトリック。
  • ネットワーク負荷の軽減を検出するためのノード メトリック。
  • queryLoggingがLogに設定されている場合にエントリをログに記録します。
• 最小特権原則に従う: DNS 転送規則を構成する場合は、必要な DNS サーバーとドメインへのアクセスのみを許可します。
• 運用環境のデプロイ前にテストする: 運用クラスターにロールアウトする前に、常に非運用環境で LocalDNS 構成をテストします。
• コードとしてのインフラストラクチャ (IaC) の使用: localdnsconfig.json ファイルをインフラストラクチャ リポジトリに格納し、AKS デプロイ テンプレートに含めます。
• TCP 転送のネットワーク構成: VnetDNS への DNS 転送に TCP を使用する場合は、ネットワーク セキュリティ グループ (NSG)、ファイアウォール、またはネットワーク仮想アプライアンス (NVA) が CoreDNS/LocalDNS サーバーと VnetDNS サーバー間の TCP トラフィックをブロックしないようにします。
• NodeLocal DNSCache と LocalDNS の両方を有効にしない: ノード プールにおいて、アップストリームの Kubernetes NodeLocal DNSCache と LocalDNS の両方を有効にすることはお勧めしません。 AKS ではこの構成はブロックされませんが、すべての DNS トラフィックは LocalDNS 経由でルーティングされるため、予期しない動作が発生したり、NodeLocal DNSCache の利点が減ったりする可能性があります。
• LocalDNS を有効にする前に、アップストリームのカスタム DNS サーバーに TCP 接続上限を設定しないでください。ノード プールで LocalDNS を有効にすると、各ノードは、前に使用した短い UDP 交換ではなく、ローカル DNS プロキシからアップストリーム リゾルバーへの有効期間の長い TCP 接続を開きます。 カスタム DNS サーバー (BIND、Unbound、Windows DNS、サード パーティ アプライアンスなど) が同時 TCP クライアント接続の固定制限で構成されている場合、または LocalDNS 前のトラフィックに基づいて制限を調整した場合、LocalDNS からの新しい TCP 接続を拒否して、クラスター全体の DNS 解決エラーが発生する可能性があります。 LocalDNS をオンにする前に、TCP 接続の制限を大きな既定値のままにし、有効化後に AKS ノードから安定状態の TCP 接続数を検証し、ノードのスケールアウト、アップグレード、および再イメージ化のヘッドルームを使用して、その後の制限のみを調整します。

[前提条件]

AKS 自動クラスターには、事前構成済みの LocalDNS が含まれます。 このセクションの前提条件は、主に、AKS Standard および高度なカスタマイズ シナリオで最も一般的な LocalDNS 動作を有効またはカスタマイズする場合に適用されます。

• LocalDNS を使用するには、Kubernetes バージョン 1.31 以降の既存の AKS クラスターが必要です。 AKS クラスターが必要な場合は、Azure CLI、Azure PowerShell、または Azure portal を使用して作成できます。
• この記事では、Azure CLI バージョン 2.80.0 以降が必要です。 Azure Cloud Shellを使用している場合は、最新バージョンが既にインストールされています。
• LocalDNS は、Linux または Ubuntu 22.04 以降Azure実行されているノード プールでのみサポートされます。
• ノード プールに使用される仮想マシン (VM) SKU は、LocalDNS をサポートするために少なくとも 4 つの vCPU (コア) を持つ必要があります。

AKS クラスターで LocalDNS を有効またはカスタマイズする

LocalDNS は AKS のノード プール レベルで構成し、ワークロードと環境によって動作を調整できるようにします。

AKS Automatic では、LocalDNS は既に事前構成されているため、このセクションは主にカスタマイズ用です。

AKS Standard では、このセクションを使用して LocalDNS を有効にして構成します。

LocalDNS を有効にする前にカスタム DNS を検証する

仮想ネットワークでカスタム DNS サーバーが使用されている場合は、LocalDNS を有効にする前に、AKS ノードからの両方の DNS トランスポートをテストします。

dig +udp @<custom-dns-ip> <fqdn>
dig +tcp @<custom-dns-ip> <fqdn>

どちらのコマンドも有効な応答を返す必要があります。 UDP が成功しても TCP がタイムアウトした場合は、TCP ポート 53 が完全なネットワーク パスを介して許可され、カスタム DNS サーバーが TCP クエリを受け入れるように構成されるまで LocalDNS を有効にしないでください。

ノード プールで LocalDNS を有効にする

通常、この手順は AKS Standard に適用されます。 AKS Automatic には、事前構成済みの LocalDNS が既に含まれています。

ノード プールの作成時に LocalDNS を有効にするには、カスタム構成ファイルで次のコマンドを使用します。

az aks nodepool add --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

既存のノード プールで LocalDNS を有効にするには、カスタム構成ファイルで次のコマンドを使用します。

az aks nodepool update --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

ノード プールで LocalDNS を無効にする

LocalDNS の無効化は高度な操作であり、通常、検証済みの例外がない限り、AKS 自動運用の既定値には推奨されません。

ノード プールの LocalDNS を無効にするには、 プロパティを mode に設定して、localdnsconfig.jsonファイルを更新する必要があります。 この変更により、指定したプール内のすべてのノードでローカル DNS プロキシをオフにし、DNS 解決を既定のクラスター動作に戻すように AKS に指示します。 構成ファイルを更新した後、Azure CLIを使用してノード プールに適用して、変更を確実に有効にします。

az aks nodepool update --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

LocalDNS 操作の確認

AKS 自動では、検証によって、構成済みの LocalDNS ベースラインがワークロードに対してアクティブであることが確認されます。 AKS Standard では、検証によって LocalDNS ロールアウトが確認されます。

LocalDNS が有効になったら、指定されたノード プール内のポッドから DNS クエリを実行し、応答の SERVER フィールドを調べて LocalDNS アドレスが返されたことを確認することで、その操作を確認できます (169.254.10.10 または 169.254.10.11)。

検証手順を実行する前に、次の条件が満たされていることを確認します。

1. AKS クラスターにアクセスするために kubectl をインストールして構成済みです。
2. ユーザー アカウントには、ポッドを作成して実行するための十分なアクセス許可があります。
3. LocalDNS を検証するノード プールが 準備完了 状態です。
4. BusyBox イメージ (busybox:1.28) は、クラスター ノードからアクセスできます。

検証の例:

1. LocalDNS が有効になっているノード プールにデバッグ ポッドを作成します。

   kubectl run dnstest --image=busybox:1.28 -- sleep 3600
   

2. ポッドが実行されたら、次のコマンドを実行して DNS 解決を確認します。

   kubectl exec -it dnstest -- nslookup kubernetes.default
   

   出力を確認します。 localDNS が正常に動作している場合は、サーバー アドレスが 169.254.10.10 または 169.254.10.11 の応答が表示されます。

   Server:    169.254.10.10
   Address 1: 169.254.10.10
   
   Name:      kubernetes.default
   Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local
   

LocalDNS の構成

LocalDNS では、JSON ベースの構成ファイル localdnsconfig.json を使用して、各ノード プールの DNS 解決動作を定義します。 このファイルを使用すると、操作モード、さまざまな DNS ドメインのサーバー ブロック、およびキャッシュ、転送、ログ記録などのプラグイン設定を指定できます。

既定の LocalDNS 構成

AKS Automatic では、LocalDNS が事前に構成されています。 カスタマイズは、特定の要件がある場合にのみ使用します。

AKS Standard では、この既定の構成が出発点として適しています。

LocalDNS をカスタマイズする場合は、テンプレートとして次の構成形式を使用します。 必要に応じて追加のサーバー ブロックを定義できますが、サポートされていないまたは非標準の最上位レベルのプロパティを構成に追加すると、検証エラーが発生します。

{
  "mode": "Required",
  "vnetDNSOverrides": {
    ".": {
      "queryLogging": "Error",
      "protocol": "PreferUDP",
      "forwardDestination": "VnetDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    },
    "cluster.local": {
      "queryLogging": "Error",
      "protocol": "ForceTCP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    }
  },
  "kubeDNSOverrides": {
    ".": {
      "queryLogging": "Error",
      "protocol": "PreferUDP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    },
    "cluster.local": {
      "queryLogging": "Error",
      "protocol": "ForceTCP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    }
  }
}

LocalDNS の mode を構成する

LocalDNS は、ワークロードに対する LocalDNS の適用範囲を定義する 3 つの可能なモードで有効にすることができます。

• Required: すべての前提条件が満たされている場合、ノード プールに LocalDNS が適用されます。 要件が満たされていない場合、デプロイは失敗します。
• Disabled: ローカル DNS 機能を無効にするため、DNS クエリはノード上でローカルに解決されません。
• Preferred: AKS は、LocalDNS 構成が構文的に正しいことを検証しますが、ノードで LocalDNS を有効にしません 。 ただし、このモードを適用してもノードの再イメージ化操作がトリガーされるため、クラスター内の DNS 解決に影響を与えることなく、構成でエラーをテストできます。

AKS Automatic の運用ワークロードの場合は、カスタマイズする必要が検証済みでない限り、事前構成済みの LocalDNS 動作を維持します。

次の表は、各モードと Kubernetes バージョンの LocalDNS 動作をまとめたものです。

LocalDNS のサーバーブロック

既定の構成は、 dnsPolicy:default ( vnetDNSOverrides の下) を使用するポッドと、 dnsPolicy:ClusterFirst ( kubeDNSOverrides の下) を使用するポッドからのクエリに適用されます。 それぞれには、 . と cluster.localの 2 つの既定のサーバー ブロックが定義されています。

• . は、パブリック ドメインまたは非クラスター ドメイン (たとえば、 microsoft.com) を解決しようとしているポッドからのすべての外部 DNS クエリを表します。
• cluster.local は、Kubernetes サービス名または内部クラスター リソースを解決しようとしているポッドからのすべての内部 Kubernetes サービス検出クエリを表します。 これらのクエリは、クラスター内で解決するために CoreDNS 経由でルーティングされます。

LocalDNS 構成でサポートされているプラグイン

構成の検証規則

LocalDNS 構成を作成するときは、デプロイエラーを回避するために、次の検証規則に注意してください。

• ルート ゾーン (.) の制限: vnetDNSOverrides においては、ルート ゾーンの forwardDestination を ClusterCoreDNSすることはできません。
• Cluster.local ゾーンの制限: vnetDNSOverrides と kubeDNSOverrides の両方に対し、forwardDestination の cluster.local を VnetDNS にすることはできません。
• プロトコルと serveStale の互換性: protocol が ForceTCP に設定されている場合、serveStale を Verify に設定することはできません。 Immediate を代わりに使用します。

LocalDNS でカスタム サーバー ブロックを作成する

CoreDNS は、部分的な一致ではなく、クエリ対象ドメインの完全一致に基づいて、特定のサーバー ブロックにクエリを照合します。 カスタム サーバー ブロックが必要な場合は、追加された構成で localdnsconfig.json という名前のファイルを作成することで、LocalDNS 構成に追加できます。

たとえば、microsoft.com にアクセスするときに特定の DNS ニーズがある場合は、次のサーバー ブロックを使用できます。

"microsoft.com": {
  "queryLogging": "Error",
  "protocol": "ForceTCP",
  "forwardDestination": "ClusterCoreDNS",
  "forwardPolicy": "Sequential",
  "maxConcurrent": 1000,
  "cacheDurationInSeconds": 3600,
  "serveStaleDurationInSeconds": 3600,
  "serveStale": "Immediate"
}

LocalDNS の監視

AKS Automatic では LocalDNS が事前構成されているため、カスタム チューニングを適用する前にベースライン検証と監視動作から開始します。

LocalDNS は、監視とアラートに使用できる Prometheus メトリックを公開します。 メトリックは、ノード IP のポート 9253 で公開されます。

DaemonSet としての Azure Managed Prometheus アドオンのスクレープ構成例：

kind: ConfigMap
apiVersion: v1
metadata:
  name: ama-metrics-prometheus-config-node
  namespace: kube-system
data:
  prometheus-config: |-
    global:
      scrape_interval: 1m
    scrape_configs:
    - job_name: localdns-metrics
      scrape_interval: 1m
      scheme: http
      metrics_path: /metrics
      relabel_configs:
      - source_labels: [__metrics_path__]
        regex: (.*)
        target_label: metrics_path
      - source_labels: [__address__]
        replacement: '$NODE_NAME'
        target_label: instance
      static_configs:
      - targets: ['$NODE_IP:9253']

LocalDNS のトラブルシューティング

特定のドメインに対する DNS クエリが失敗する

LocalDNS を有効にした後、特定のドメインに対する DNS クエリが失敗する場合:

1. 正しく構成されていない可能性があるドメイン固有のオーバーライドが localdnsconfig.json に存在するかどうかを確認します。

2. ドメイン固有のオーバーライドを一時的に削除し、既定の . 構成のみを使用してみてください。

3. protocol設定を調整して、ユーザー データグラム プロトコル (UDP) と伝送制御プロトコル (TCP) の両方で問題が発生しているかどうかを確認します。

4. CoreDNS ログで、 169.254.10.10:53 または 169.254.10.11:53 LocalDNS アドレスへのタイムアウトを確認します。 影響を受けるノードから、UDP と TCP 経由でアップストリームのカスタム DNS サーバーを個別にテストします。

   dig +udp @<custom-dns-ip> <fqdn>
   dig +tcp @<custom-dns-ip> <fqdn>
   

   UDP が成功しても TCP が失敗する場合は、次のことを確認します。

   • カスタム DNS サーバーは TCP ポート 53 でリッスンします。
   • NSG とファイアウォールでは、AKS ノード サブネットから TCP ポート 53 を使用できます。
   • NVA とルートは、TCP DNS トラフィックをドロップしたり、非対称的にルーティングしたりすることはありません。

   影響を受けるノード プールで LocalDNS を無効にするには、その LocalDNS モードを Disabledに更新します。 有効なプールを Disabled に変更すると、更新プログラムの一部としてノードの再イメージ化がトリガーされます。 永続的な修正を行う場合は、カスタム DNS サーバーとネットワーク パスが、ポート 53 の UDP と TCP の両方で DNS をサポートしていることを確認します。

LocalDNS の VNet DNS サーバーを更新する

(Azure ポータルまたは CLI を使用して) VNet 構成でカスタム DNS サーバーを直接更新する場合、AKS クラスター ノードはこれらの変更を自動的に適用しません。 VNet レベルで DNS 設定を更新すると、ネットワーク リソース プロバイダー (NRP) にのみ通知されますが、AKS リソース プロバイダーには通知されません。 その結果、AKS ノードは、さらにアクションを実行するまで、以前の DNS サーバー設定を引き続き使用します。

AKS ノードが新しい VNet DNS サーバー設定を確実に取得するには:

1. 必要に応じて、Azure portal または API を使用して VNet DNS 構成を更新します。

2. AKS リソース プロバイダーを使用してノード プールを再イメージ化し、更新された DNS 設定が適用され、保持されるようにします。

   az aks nodepool upgrade --resource-group myResourceGroup --cluster-name myAKSCluster --name mynodepool --node-image-only
   

このプロセスにより、AKS リソース プロバイダーは DNS の変更を認識し、ノード プール内のすべてのノードに適用されます。

LocalDNS で DNS 解決を許可するように Cilium ネットワーク ポリシーを更新する

クラスターに Cilium ネットワーク ポリシーをデプロイする場合は、LocalDNS IP アドレスへのポッドエグレスを明示的に許可する必要があります。

ネットワーク ポリシーでは、指定されていない宛先に対して既定の拒否モデルが適用されるため、明示的に許可されない限り、LocalDNS への DNS トラフィックはブロックされます。

• Azure CNI Powered by Cilium <=v1.16 with k8s <=1.31 では、これは CIDR ベースのポリシーによって実現できます。
• Azure CNI Powered by Cilium >=v1.17 with K8s >=1.32 では、エンティティをホストするエグレスを許可する Cilium ネットワーク ポリシーを使用できます。

すべてのバージョン間のトラフィックを許可する Cilium ネットワーク ポリシーについては、「AKS ローカル DNS は Azure CNI Powered by Cilium でサポートされていますか?」を参照してください。

関連するコンテンツ

• AKS Automatic とは
• AKS 自動クラスターを作成する
• Azure Kubernetes Service における LocalDNS (概念)
• AKS での LocalDNS に関する問題のトラブルシューティング
• CoreDNS カスタマイズ ガイド
• CoreDNS アップストリーム プロジェクト ページ
• AKS でのアプリケーションのネットワークの概念