このトピックでは、Container Service for Kubernetes (ACK) クラスターでサポートされているドメインネームシステム (DNS) 解決ポリシーとキャッシュポリシーについて説明します。
DNS解決パイプライン
このセクションでは、以下のシナリオにおけるDNS解決パイプラインを示します。
タイムアウトや試行など、次の図の用語の詳細については、このトピックの「解決ポリシー」および「キャッシュポリシー」のセクションを参照してください。
非コンテナ化アプリケーションは、Elastic Compute Service (ECS) インスタンスで実行されます。
たとえば、次の図に示すように、Appという名前のアプリケーションがECSインスタンスで実行されます。
コンテナー化されたアプリケーションは、Kubernetesクラスターのポッドで実行されます。 ポッドはClusterFirst DNSポリシーを使用します。
たとえば、次の図に示すように、Appという名前のアプリケーションはKubernetesクラスターのポッドで実行されます。
コンテナー化されたアプリケーションは、Kubernetesクラスターのポッドで実行されます。 ポッドのDNSポリシーでは、NodeLocal DNSCacheをDNS解決に使用することを指定します。
たとえば、次の図に示すように、Appという名前のアプリケーションは、NodeLocal DNSCacheがインストールされているKubernetesクラスターのポッドで実行されます。
解決ポリシー
クライアント側
ほとんどの場合、ポッドのDNSクエリは、glibcが提供するインターフェイスを使用して処理されます。 次の表に、/etc/resolv.confファイルで設定できるパラメーターと、さまざまな環境でのデフォルト値を示します。 これらのパラメーターは、glibcがDNS解決を実行する方法を指定します。
パラメーター | 説明 | glibcのデフォルト値 | ECS | ClusterFirst DNSポリシーを使用するポッドのデフォルト値 | デフォルトDNSポリシーを使用するポッドのデフォルト値 | DNS解決にNodeLocal DNSCacheを使用するポッドのデフォルト値 | ホストネットワークとデフォルトDNSポリシーを使用するポッドのデフォルト値 |
| ドメイン名を解決するDNSサーバー。 | なし | 仮想プライベートクラウド (VPC) にデプロイされたDNSサーバー ② | CoreDNS ③ のクラスターIPアドレス | VPCにデプロイされたDNSサーバー |
| VPCにデプロイされたDNSサーバー |
| 完全修飾ドメイン名 (FQDN) 以外のドメイン名には、ドメイン名が解決される前に、 | なし | なし | <ns>.svc.cluster.cloal svc.cluster.local | なし | <ns>.svc.cluster.cloal svc.cluster.local | なし |
| ドメイン名文字列のドット数がndotsパラメーターの値より大きい場合、ドメイン名はFQDNであり、直接解決されます。 ドメイン名文字列のドット数がndotsパラメーターの値よりも小さい場合、ドメイン名が解決される前に、検索パラメーターで指定されたサフィックスがドメイン名に追加されます。 | 1 | 1 | 5 | 1 | 3 | 1 |
| 各DNS解決のタイムアウト期間。 単位は秒です。 | 5 | 2 | 5 | 5 | 1 | 2 |
| DNS解決に失敗した場合に実行できる再試行の最大数。 | 2 | 3 | 2 | 2 | 2 | 3 |
| DNSクエリをDNSサーバーにラウンドロビン方式で送信します。 | 無効 | Enabled | 無効 | 無効 | 無効 | Enabled |
| このパラメーターを指定した後、同じソケットを使用して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を使用する。 | Enabled | 無効 |
| TCPを強制的に使用して上流サーバーと通信します。 | 無効 | Enabled |
| 上流サーバーが異常と見なされる前に発生する必要がある、連続して失敗したヘルスチェックの数。 | 2 | 2 |
| アップストリームサーバーへの接続が存続している期間。 デフォルトの期間は10秒です。 | 10s | 10s |
| 上流サーバーの選択に使用されるポリシー。 | random | random |
| ヘルスチェックが実行される間隔。 | 0.5s | 0.5s |
| 上流サーバーに送信できる同時クエリの最大数。 | なし | なし |
| 上流サーバーへの接続のタイムアウト期間。 | 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