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

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

最終更新日:Nov 12, 2024

このトピックでは、Container Service for Kubernetes (ACK) クラスターでサポートされているドメインネームシステム (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ポリシーでは、NodeLocal DNSCacheをDNS解決に使用することを指定します。

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

    DNS resolution pipeline 3.png

解決ポリシー

クライアント側

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

パラメーター

説明

glibcのデフォルト値

ECS

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

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

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

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

ネームサーバー

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

なし

仮想プライベートクラウド (VPC) にデプロイされたDNSサーバー

CoreDNS のクラスターIPアドレス

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

  • NodeLocal DNSCache のIPアドレス

  • CoreDNS ClusterIP

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

検索

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

なし

なし

<ns>.svc.cluster.cloal svc.cluster.local

なし

<ns>.svc.cluster.cloal svc.cluster.local

なし

ndots:n

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

1

1

5

1

3

1

timeout:n

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

5

2

5

5

1

2

試行: n

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

2

3

2

2

2

3

回転させる

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

無効

Enabled

無効

無効

無効

Enabled

single-request-reopen

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

無効

Enabled

無効

無効

無効

Enabled

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

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 ServiceのIPアドレスです。 kube-dns Serviceは、内部ドメイン名、権限ドメイン名、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をmusllibcに置き換えるためです。 次のリストにいくつかの違いを示します。

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

    • Alpine 3.3以前のバージョンでは、検索ドメインを指定できる検索パラメーターはサポートされていません。 その結果、サービス発見が実施されない。

    • 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は組み込みの転送プラグインを使用してDNSクエリを転送します。

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

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

パラメーター

説明

CoreDNSのデフォルト値

NodeLocal DNSCacheのデフォルト値

_udpを好む

好ましくは、上流サーバと通信するためにUDPを使用する。

Enabled

無効

force_tcp

TCPを強制的に使用して上流サーバーと通信します。

無効

Enabled

max_fails

上流サーバーが異常と見なされる前に発生する必要がある、連続して失敗したヘルスチェックの数。

2

2

期限切れ

アップストリームサーバーへの接続が存続している期間。 デフォルトの期間は10秒です。

10s

10s

ポリシー

上流サーバーの選択に使用されるポリシー。

random

random

health_check

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

0.5s

0.5s

max_concurrent

上流サーバーに送信できる同時クエリの最大数。

なし

なし

dial timeout

上流サーバーへの接続のタイムアウト期間。

30秒 タイムアウト期間は、実際の接続期間に基づいて動的に減少します。

30秒 タイムアウト期間は、実際の接続期間に基づいて動的に減少します。

読み取りタイムアウト

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

2s

2s

キャッシュポリシー

クライアント側

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

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

パラメーター

説明

CoreDNSのデフォルト値

ACKのNodeLocal DNSCacheのデフォルト値

ACKのCoreDNSのデフォルト値

マックスTTL成功

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

3600s

30 秒

30 秒

最小TTL成功

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

5s

5s

5s

容量成功

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

9984

9984

9984

拒否マックスTTL

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

1800s

5s

30 秒

拒否最小TTL

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

5s

5s

5s

拒否容量

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

9984

9984

9984

ServerError TTL

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

5s

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

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

serve_stale

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

無効

Enabled. インストールされているNodeLocal DNSCache Helmチャートのバージョンが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
  # The dnsPolicy parameter is set to Default. 
  dnsPolicy: Default

# The /etc/resolv.conf file in the pod. 
# 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
  # Set the dnsPolicy parameter to Default. 
  dnsPolicy: Default
  # Add the following options. 
  dnsConfig:
    options:
    - name: timeout
      value: "2"
    - name: attempts
      value: "3"
    - name: rotate
    - name: single-request-reopen

# After you add the options to the /etc/resolv.conf, redeploy the pod to apply the modification. 
# cat /etc/resolv.conf
nameserver 100.100.2.136
nameserver 100.100.2.138
options rotate single-request-reopen timeout:2 attempts:3