このトピックでは、Kubernetes クラスター内のコンテナー Pod のドメイン名解決およびキャッシュポリシーについて説明します。
DNS 解決パイプライン
次の図は、3 種類のアプリケーションデプロイメントにおけるドメイン名解決パイプラインを示しています。
図中の timeout や attempts などの用語の詳細については、「名前解決ポリシー」および「キャッシュポリシー」のセクションをご参照ください。
コンテナー化されていないアプリケーションは ECS インスタンス上で直接実行されます。
例: アプリケーションは ECS インスタンス上で実行されます。

コンテナー化されたアプリケーションは Kubernetes で実行されます。Pod は ClusterFirst DNS ポリシーを使用します。
例: アプリケーションは Kubernetes コンテナー Pod 内で実行されます。

コンテナー化されたアプリケーションは Kubernetes で実行されます。Pod は NodeLocal DNSCache を使用します。
例: アプリケーションは Kubernetes コンテナー Pod 内で実行され、NodeLocal DNSCache がデプロイされます。

解決ポリシー
クライアント側
ほとんどの場合、アプリケーションは Glibc が提供するインターフェイスを使用してドメイン名を解決します。次の表は、Glibc が使用する /etc/resolv.conf ファイルで設定可能なドメイン名解決パラメーターについて説明しています。
パラメーター | 説明 | Glibc のデフォルト値 | ECS | DNSPolicy が ClusterFirst に設定された Pod | DNSPolicy が Default に設定された Pod | NodeLocal DNSCache を使用する Pod | DNSPolicy が Default に設定され、ホストネットワークを使用する Pod |
| ドメイン名を解決するために使用される DNS サーバー。 | 空 | VPC DNS サーバー② | CoreDNS ClusterIP③ | VPC DNS サーバー |
| VPC DNS サーバー |
| 完全修飾ドメイン名 (FQDN) ではないドメイン名を含むリクエストの場合、リクエストが送信される前にドメイン名に | 空 | 空 | <ns>.svc.cluster.local svc.cluster.local cluster.local | 空 | <ns>.svc.cluster.local svc.cluster.local cluster.local | 空 |
| ドメイン名文字列のドットの数が ndots の値より大きい場合、そのドメイン名は FQDN と見なされ、直接解決されます。ドットの数が ndots の値より小さい場合、クエリの前にドメイン名に search サフィックスが追加されます。 | 1 | 1 | 5 | 1 | 3 | 1 |
| 単一のドメイン名解決リクエストのタイムアウト期間 (秒単位)。 | 5 | 2 | 5 | 5 | 1 | 2 |
| ドメイン名の解決に失敗した場合の再試行回数。 | 2 | 3 | 2 | 2 | 2 | 3 |
| DNS サーバーにラウンドロビン方式でクエリを実行します。 | シャットダウン | 有効 | 無効 | 無効 | 無効 | 有効 |
| このオプションが有効で、同じソケットを使用して 2 つのリクエストが送信される場合、リゾルバーは最初のリクエストを送信した後にソケットを閉じ、2 番目のリクエストを送信する前に新しいソケットを開きます。 | シャットダウン | 有効 | 無効 | 無効 | シャットダウン | 有効 |
①attempts パラメーターは、サーバーが SERVFAIL、NOTIMP、または REFUSED を返す場合や、サーバーが NOERROR を返しても解決結果がない場合など、特定のシナリオでのみ有効です。詳細については、「attempts パラメーターリクエストの詳細」をご参照ください。
②VPC DNS サーバーは、ECS インスタンスに設定されているデフォルトの DNS サーバーです。IP アドレスは 100.100.2.136 と 100.100.2.138 です。これらは、PrivateZone のドメイン名と権限のあるドメイン名の解決を担当します。
③CoreDNS ClusterIP は、Kubernetes クラスターの kube-system 名前空間にあるデフォルトの CoreDNS デプロイメントによって提供される kube-dns サービスの IP アドレスです。内部サービスドメイン名の解決と、PrivateZone および権限のあるドメイン名の解決リクエストの転送を担当します。
④NodeLocal DNSCache IP は 169.254.20.10 です。NodeLocal DNSCache コンポーネントがデプロイされると、各ノードでこの IP アドレスをリッスンします。
resolv.conf の構成の詳細については、「resolv.conf」をご参照ください。
場合によっては、クライアント側のドメイン名解決ポリシーが上記の設定と異なることがあります。
コンテナイメージとして Alpine を使用する場合、その組み込みの Musl ライブラリが Glibc を置き換えるため、解決動作に大きな違いが生じます。例:
Alpine は /etc/resolv.conf の single-request および single-request-reopen オプションに従いません。
Alpine 3.3 以前のバージョンは `search` パラメーターまたは検索ドメインをサポートしていないため、サービスディスカバリーが機能しません。
/etc/resolv.conf で設定された複数の DNS サーバーへの同時リクエストにより、NodeLocal DNSCache の最適化が効果を失います。
同じソケットを使用して A レコードと AAAA レコードを同時にリクエストすると、古いカーネルバージョンで Conntrack のソースポートの競合がトリガーされ、パケット損失につながります。
説明解決動作の詳細については、「musl libc」をご参照ください。
Golang や NodeJS などのプログラミング言語を使用する場合、アプリケーションは言語の組み込みドメイン名リゾルバーを使用することがあり、これも動作が大きく異なります。
クラスター内 DNS サーバー
デフォルトでは、CoreDNS の /etc/resolv.conf ファイルは ECS の構成を使用します。ただし、CoreDNS は組み込みの Forward プラグインを使用して DNS リクエストを転送します。
NodeLocal DNSCache は、DNS サービスの転送に組み込みの CoreDNS を使用します。構成方法は CoreDNS と同じです。
次の表は、Forward プラグインの名前解決ポリシーを制御するパラメーターについて説明しています。CoreDNS Forward プラグインの詳細については、「Forward」をご参照ください。
パラメーター | 説明 | CoreDNS のデフォルト値 | NodeLocal DNSCache のデフォルト値 |
| アップストリームサーバーとの通信に UDP を優先的に使用します。 | 有効 | 無効 |
| アップストリームサーバーとの通信に TCP を強制的に使用します。 | 無効 | 有効 |
| アップストリームサーバーが異常と見なされるまでの連続したヘルスチェックの失敗回数。 | 2 | 2 |
| アップストリームサーバーへの接続を 10 秒間維持します。 | 10s | 10s |
| アップストリームサーバーを選択するためのポリシー。 | random | random |
| ヘルスチェックの間隔。 | 0.5s | 0.5s |
| アップストリームサーバーへの同時接続の最大数。 | なし | なし |
| アップストリームサーバーへの接続タイムアウト。 | 30 秒。実際の消費時間に基づいて値は動的に減少します。 | 30 秒。実際の消費時間に基づいて値は動的に減少します。 |
| アップストリームサーバーからのデータ待機タイムアウト。 | 2s | 2s |
キャッシュポリシー
クライアント側
クライアント側のキャッシュポリシーは、コンテナーとアプリケーションによって異なります。実際のキャッシュポリシーは、特定の設定によって決まります。
クラスター内 DNS サーバー
パラメーター | 説明 | CoreDNS コミュニティのデフォルト構成 | NodeLocal DNSCache ACK のデフォルト構成 | CoreDNS ACK のデフォルト構成 |
success Max TTL | 成功したドメイン名解決結果のキャッシュの最大生存時間 (TTL)。 | 3600s | 30s | 30s |
success Min TTL | 成功したドメイン名解決結果のキャッシュの最小 TTL。 | 5s | 5s | 5s |
success Capacity | キャッシュする成功したドメイン名解決結果の数。 | 9984 | 9984 | 9984 |
denial Max TTL | 失敗したドメイン名解決結果のキャッシュの最大 TTL。 | 1800s | 5s | 30s |
denial Min TTL | 失敗したドメイン名解決結果のキャッシュの最小 TTL。 | 5s | 5s | 5s |
denial Capacity | キャッシュする失敗したドメイン名解決結果の数。 | 9984 | 9984 | 9984 |
ServerError TTL | アップストリーム DNS サーバーが異常な場合の解決結果の TTL。 | 5s | 0s (NodeLocal DNSCache Helm Chart バージョン 1.5.0 より前ではデフォルトは 5s) | 0s (CoreDNS バージョン 1.8.4.2 より前ではデフォルトは 5s) |
serve_stale | アップストリーム DNS サーバーに接続できない場合に、期限切れのローカルキャッシュの使用を許可します。 | シャットダウン | 有効 (NodeLocal DNSCache Helm Chart バージョン 1.5.0 より前ではデフォルトで無効) | CoreDNS バージョン 1.12.1 より前ではデフォルトで無効。CoreDNS 1.12.1 以降ではデフォルトで有効。 |
キャッシュの実際の TTL は、ドメイン名解決結果の TTL、最大 TTL、および最小 TTL によって決まります。ルールは次のとおりです。
結果の TTL が最大 TTL より大きい場合、実際の TTL は最大 TTL になります。
結果の TTL が最小 TTL より小さい場合、実際の TTL は最小 TTL になります。
結果の TTL が最小 TTL と最大 TTL の間にある場合、実際の TTL は結果の TTL になります。
最適化の提案
このセクションでは、Kubernetes クラスターでの解決パスとパラメーター構成について説明します。Pod YAML、CoreDNS ConfigMap、または NodeLocal DNSCache ConfigMap を編集することで、パラメーターを変更できます。以下に例を示します。
クライアント Pod に dnsPolicy:Default を設定すると、ECS インスタンス上の VPC DNS サーバー設定がコンテナー内の /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
# Pod YAML の dnsPolicy の値は Default です。
dnsPolicy: Default
# この時点でのコンテナー内の /etc/resolv.conf ファイル。
# cat /etc/resolv.conf
nameserver 100.100.2.136
nameserver 100.100.2.138ECS インスタンスと比較して、コンテナーの構成には rotate single-request-reopen timeout:2 attempts:3 オプションがありません。時折発生するネットワークジッターにより、サービスのドメイン名解決が失敗する可能性があります。これらのパラメーターを追加して、フォールトトレランスを向上させることができます。Pod YAML を次のように調整します。
apiVersion: v1
kind: Pod
metadata:
name: example
namespace: default
spec:
containers:
- image: registry.cn-hangzhou.aliyuncs.com/example-ns/example:v1
name: example
# Pod YAML の dnsPolicy の値は Default です。
dnsPolicy: Default
# 次のフォールトトレランス構成を追加します。
dnsConfig:
options:
- name: timeout
value: "2"
- name: attempts
value: "3"
- name: rotate
- name: single-request-reopen
# 変更後、Pod を再デプロイします。options パラメーターがコンテナー内の /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:3serve_stale を使用して DNS の安定性を確保する
serve_stale オプションは、CoreDNS cache プラグインの stale serving 機能の特定の実装です。serve_stale が有効になっている場合、アップストリーム DNS サーバーにアクセスできない場合でも、CoreDNS はキャッシュから期限切れのエントリを提供し続けます。この機能により、DNS 解決の信頼性が向上し、アップストリーム DNS サービスのジッターや時折発生する例外による解決の失敗を防ぐことができます。
この構成は、アンマネージド CoreDNS 1.12.1 以降ではデフォルトで有効になっています。この機能の詳細については、「RFC-8767」をご参照ください。
構成フォーマット
serve_stale [DURATION] [REFRESH_MODE]
DURATION: 期限切れエントリの有効期間。デフォルト値は1 hです。キャッシュされたエントリが期限切れになり、有効期間に達しても更新されない場合、CoreDNS はそのエントリの提供を停止します。REFRESH_MODE: 期限切れエントリを提供するためのポリシー:verify: 期限切れのエントリをクライアントに送信する前に、アップストリーム DNS サービスがアクティブであるかどうかを確認します。このメソッドはクライアントの解決レイテンシを増加させる可能性がありますが、更新が検出された場合はすぐに新しいエントリを提供できます。immediate: 期限切れのエントリをすぐにクライアントに送信し、その後アップストリーム DNS サービスがアクティブであるかどうかを確認します。これにより即時の応答が得られますが、更新時間はアップストリーム DNS サービスの更新に遅れる可能性があります。
構成例
次の構成は、アンマネージド CoreDNS v1.12.1.2 以降でデフォルトで使用されます。
cache 30 {
...
serve_stale 30s verify
}アンマネージド CoreDNS v1.12.1.1-4035d7a99-aliyun のデフォルト構成:
cache 30 {
...
serve_stale 1h immediate
}上記デフォルト構成を使用する場合、一部の極端なシナリオ (たとえば、ヘッドレスサービスの反復更新中にクライアントが DNS 解決を実行する場合など) では、DNS が期限切れのエントリを返すことがあります。この状況が頻繁に発生する場合は、「構成例」に示すように、ポリシーを verify に変更できます。