すべてのプロダクト
Search
ドキュメントセンター

Container Service for Kubernetes:DNS 解決ポリシーとキャッシュポリシー

最終更新日:Apr 24, 2025

このトピックでは、Container Service for Kubernetes (ACK) クラスタでサポートされている Domain Name System (DNS) 解決ポリシーとキャッシュポリシーについて説明します。

DNS 解決パイプライン

このセクションでは、以下のシナリオにおける DNS 解決パイプラインを示します。

説明

以下の図に示されているタイムアウトや試行回数などの用語については、このトピックの「解決ポリシー」セクションと「キャッシュポリシー」セクションをご参照ください。

  • 非コンテナ化アプリケーションが Elastic Compute Service (ECS) インスタンスで実行されています。

    たとえば、次の図に示すように、App という名前のアプリケーションが ECS インスタンスで実行されています。

    DNS resolution pipeline 1.png

  • コンテナ化アプリケーションが Kubernetes クラスタのポッドで実行されています。ポッドは ClusterFirst DNS ポリシーを使用します。

    たとえば、次の図に示すように、App という名前のアプリケーションが Kubernetes クラスタのポッドで実行されています。

    DNS resolution pipeline 2.png

  • コンテナ化アプリケーションが Kubernetes クラスタのポッドで実行されています。ポッドの DNS ポリシーでは、DNS 解決に NodeLocal DNSCache を使用することが指定されています。

    たとえば、次の図に示すように、App という名前のアプリケーションが NodeLocal DNSCache がインストールされている Kubernetes クラスタのポッドで実行されています。

    DNS resolution pipeline 3.png

解決ポリシー

クライアント側

ほとんどの場合、ポッドの DNS クエリは、glibc によって提供されるインターフェイスを使用して処理されます。次の表では、/etc/resolv.conf ファイルで構成できるパラメータと、さまざまな環境でのデフォルト値について説明します。これらのパラメータは、glibc が DNS 解決を実行する方法を指定します。

パラメータ

説明

glibc のデフォルト値

ECS

ClusterFirst DNS ポリシーを使用するポッドのデフォルト値

Default DNS ポリシーを使用するポッドのデフォルト値

DNS 解決に NodeLocal DNSCache を使用するポッドのデフォルト値

ホストネットワークと Default DNS ポリシーを使用するポッドのデフォルト値

nameserver

ドメイン名を解決する DNS サーバー。

なし

VPC (Virtual Private Cloud) にデプロイされた DNS サーバー

CoreDNS のクラスタ IP アドレス

VPC にデプロイされた DNS サーバー

  • NodeLocal DNSCache の IP アドレス

  • CoreDNS ClusterIP

VPC にデプロイされた DNS サーバー

search

完全修飾ドメイン名 (FQDN) 以外のドメイン名は、解決される前に search パラメータで指定されたサフィックスが付加されます。

なし

なし

<ns>.svc.cluster.localsvc.cluster.localcluster.local

なし

<ns>.svc.cluster.localsvc.cluster.localcluster.local

なし

ndots:n

ドメイン名文字列のドットの数が ndots パラメータの値よりも大きい場合、ドメイン名は FQDN であり、直接解決されます。ドメイン名文字列のドットの数が ndots パラメータの値よりも小さい場合、ドメイン名は解決される前に search パラメータで指定されたサフィックスが付加されます。

1

1

5

1

3

1

timeout:n

各 DNS 解決のタイムアウト期間。単位:秒。

5

2

5

5

1

2

attempts:n

DNS 解決が失敗した場合に実行できる最大再試行回数。

2

3

2

2

2

3

rotate

ラウンドロビン方式で DNS サーバーに DNS クエリを送信します。

無効

有効

無効

無効

無効

有効

single-request-reopen

このパラメータを指定すると、同じソケットを使用して 2 つの DNS リクエストが送信された場合、クライアントは最初の DNS リクエストを送信した後にソケットを閉じ、新しいソケットを開いて 2 番目の DNS リクエストを送信します。

無効

有効

無効

無効

無効

有効

attempts パラメータは、特定のシナリオ、たとえば、SERVFAIL、NOTIMP、または REFUSED が返された場合、または解決結果なしで NOERROR が返された場合にのみ有効になります。詳細については、「attempts パラメータの概要」をご参照ください。

VPC にデプロイされた DNS サーバーは、VPC 内の ECS インスタンスのデフォルトの DNS サーバーです。DNS サーバーの IP アドレスは 100.100.2.136 と 100.100.2.138 です。DNS サーバーは、権限のあるドメイン名と Alibaba Cloud DNS PrivateZone に追加されたドメイン名を解決します。

CoreDNS のクラスタ IP アドレスは、kube-system 名前空間の kube-dns サービスの IP アドレスです。kube-dns サービスは、内部ドメイン名、権限のあるドメイン名、および Alibaba Cloud DNS PrivateZone に追加されたドメイン名に対する DNS クエリを CoreDNS に転送します。

NodeLocal DNSCache の IP アドレスは 169.254.20.10 です。NodeLocal DNSCache をデプロイすると、NodeLocal DNSCache はノード上の IP アドレスに送信された DNS クエリをリッスンします。

説明

resolv.conf の構成方法の詳細については、「resolv.conf」をご参照ください。

特定の場合、クライアント側の DNS 解決構成は、上記の構成とは異なる場合があります。

  • Alpine Linux イメージを使用してコンテナをデプロイする場合、DNS 解決構成が大幅に異なる場合があります。これは、Alpine Linux が glibc を musl libc に置き換えているためです。以下に、いくつかの違いを示します。

    • Alpine Linux は、/etc/resolv.conf ファイルの single-request パラメータと single-request-reopen パラメータをサポートしていません。

    • Alpine 3.3 以前のバージョンは、検索ドメインを指定できる search パラメータをサポートしていません。その結果、サービスディスカバリの実装に失敗します。

    • musl libc は、/etc/resolv.conf ファイルで指定された DNS サーバーに送信されたクエリを並列処理します。その結果、NodeLocal DNSCache は DNS 解決を最適化できません。

    • musl libc は、同じソケットを使用する A クエリと AAAA クエリを並列処理します。これにより、以前のカーネルバージョンの conntrack ポートでパケット損失が発生します。

    説明

    詳細については、「musl libc」をご参照ください。

  • Golang または Node.js を使用してアプリケーションを開発する場合、アプリケーションは組み込みの DNS リゾルバを使用する場合があります。これにより、DNS 解決に大きな違いが生じる場合もあります。

クラスタ内の内部 DNS サーバー

デフォルトでは、CoreDNS の /etc/resolv.conf ファイルは、CoreDNS をホストする ECS インスタンスの /etc/resolv.conf ファイルから継承されます。ただし、CoreDNS は組み込みの forward プラグインを使用して DNS クエリを転送します。

CoreDNS は NodeLocal DNSCache に組み込まれています。CoreDNS を構成するのと同じ方法で NodeLocal DNSCache を構成できます。

次の表に、forward プラグインのパラメータを示します。詳細については、「forward」をご参照ください。

パラメータ

説明

CoreDNS のデフォルト値

NodeLocal DNSCache のデフォルト値

prefer_udp

アップストリームサーバーとの通信に UDP を優先的に使用します。

有効

無効

force_tcp

アップストリームサーバーとの通信に TCP を強制的に使用します。

無効

有効

max_fails

アップストリームサーバーが異常とみなされるまでに発生する必要がある連続したヘルスチェックの失敗回数。

2

2

expire

アップストリームサーバーへの接続が維持される期間。デフォルトの期間は 10 秒です。

10s

10s

policy

アップストリームサーバーを選択するために使用されるポリシー。

random

random

health_check

ヘルスチェックが実行される間隔。

0.5s

0.5s

max_concurrent

アップストリームサーバーに送信できる同時クエリの最大数。

なし

なし

dial timeout

アップストリームサーバーへの接続のタイムアウト期間。

30 秒。タイムアウト期間は、実際の接続時間に基づいて動的に短縮されます。

30 秒。タイムアウト期間は、実際の接続時間に基づいて動的に短縮されます。

read timeout

アップストリームサーバーに送信されたリクエストのタイムアウト期間。

2s

2s

キャッシュポリシー

クライアント側

クライアント側の DNS キャッシュポリシーは、コンテナとアプリケーションの構成によって異なります。要件に基づいて、クライアント側の DNS キャッシュポリシーを構成できます。

クラスタ内の内部 DNS サーバー

パラメータ

説明

CoreDNS のデフォルト値

ACK の NodeLocal DNSCache のデフォルト値

ACK の CoreDNS のデフォルト値

success Max TTL

成功した DNS 解決のキャッシュの最大生存時間 (TTL)。

3600s

30s

30s

success Min TTL

成功した DNS 解決のキャッシュの最小 TTL。

5s

5s

5s

success Capacity

キャッシュできる成功した DNS 解決結果の最大数。

9984

9984

9984

denial Max TTL

失敗した DNS 解決のキャッシュの最大 TTL。

1800s

5s

30s

denial Min TTL

失敗した DNS 解決のキャッシュの最小 TTL。

5s

5s

5s

denial Capacity

キャッシュできる失敗した DNS 解決結果の最大数。

9984

9984

9984

ServerError TTL

異常なアップストリーム DNS サーバーから返された DNS 解決結果の最大 TTL。

5s

0s。インストールされている NodeLocal DNSCache Helm chart のバージョンが 1.5.0 より前の場合、デフォルト値は 5s です。

0s。インストールされている CoreDNS のバージョンが 1.8.4.2 より前の場合、デフォルト値は 5s です。

serve_stale

クライアントがアップストリーム DNS サーバーに接続できない場合、古いローカル DNS キャッシュを使用します。

無効

有効。インストールされている NodeLocal DNSCache Helm chart のバージョンが 1.5.0 より前の場合、このパラメータは無効になっています。

無効

説明

DNS キャッシュの実際の TTL は、返された DNS レコードの TTL、最大 TTL、および最小 TTL によって決まります。

  • 返された DNS レコードの TTL が最大 TTL よりも大きい場合、最大 TTL が DNS キャッシュの実際の TTL として使用されます。

  • 返された DNS レコードの TTL が最小 TTL よりも小さい場合、最小 TTL が DNS キャッシュの実際の TTL として使用されます。

  • 返された DNS レコードの TTL が最小 TTL よりも大きく、最大 TTL よりも小さい場合、返された DNS レコードの TTL が DNS キャッシュの実際の TTL として使用されます。

DNS 解決の最適化

前のセクションでは、Kubernetes クラスタの DNS 解決パイプラインと関連パラメータについて説明しました。ポッド YAML テンプレート、CoreDNS ConfigMap、および NodeLocal DNSCache ConfigMap のパラメータ設定を変更できます。次の例は、ポッド YAML テンプレートを構成する方法を示しています。

クライアントポッド YAML テンプレートで dnsPolicy:Default を指定すると、ポッドはポッドをホストする ECS インスタンスの DNS 設定を継承します。したがって、VPC 内の DNS サーバーの IP アドレスは、ポッドの /etc/resolv.conf ファイルに自動的に指定されます。

apiVersion: v1
kind: Pod
metadata:
  name: example
  namespace: default
spec:
  containers:
  - image: registry.cn-hangzhou.aliyuncs.com/example-ns/example:v1
    name: example
  # dnsPolicy パラメータは Default に設定されています。
  dnsPolicy: Default

# ポッドの /etc/resolv.conf ファイル。
# cat /etc/resolv.conf
nameserver 100.100.2.136
nameserver 100.100.2.138

ECS インスタンスの /etc/resolv.conf ファイルと比較して、ポッドの /etc/resolv.conf ファイルには、rotate、single-request-reopen、timeout:2、attempts:3 のオプションが含まれていません。これにより、ネットワークジッターが発生した場合に解決エラーが発生する可能性があります。次の内容に基づいてポッド YAML テンプレートを変更します。

apiVersion: v1
kind: Pod
metadata:
  name: example
  namespace: default
spec:
  containers:
  - image: registry.cn-hangzhou.aliyuncs.com/example-ns/example:v1
    name: example
  # dnsPolicy パラメータを Default に設定します。
  dnsPolicy: Default
  # 次のオプションを追加します。
  dnsConfig:
    options:
    - name: timeout
      value: "2"
    - name: attempts
      value: "3"
    - name: rotate
    - name: single-request-reopen

# /etc/resolv.conf にオプションを追加した後、変更を適用するためにポッドを再デプロイします。
# cat /etc/resolv.conf
nameserver 100.100.2.136
nameserver 100.100.2.138
options rotate single-request-reopen timeout:2 attempts:3