Kubernetes クラスターでは、Pod はドメイン名を使用してサービスや外部サービスにアクセスします。これらのドメイン名は、アクセスを許可するために IP アドレスに名前解決される必要があります。DNS は、ドメイン名と IP アドレス間のマッピングを維持することでこれを処理します。このトピックでは、DNS の基本、Container Service for Kubernetes (ACK) の DNS コンポーネント、および DNS 設定について説明します。
ドメイン名の名前解決の仕組み
インターネット上のデバイスは IP アドレスを使用して通信しますが、ドメイン名の方が意味的で覚えやすいため、クライアントはほとんどの場合、ドメイン名を使用してリクエストを開始します。次の図は、クライアントが example.com にリクエストを送信する際のプロセスを示しています。
サーバーは自身の IP アドレスとドメイン名を DNS サーバーに登録し、DNS サーバーは対応するレコードを保存します。
クライアントは DNS サーバーに example.com に対応する IP アドレスを問い合わせます。
DNS サーバーはレコードを検索し、IP アドレスをクライアントに返します。
クライアントはその IP アドレスを使用してターゲットサーバーにアクセスします。
クラスター内のドメイン名の種類
内部ドメイン名:サービスのドメイン名で、クラスター内でのみ有効です。サービスにアクセスするには、完全修飾ドメイン名 (FQDN) 形式である
<service-name>.<namespace>.svc.<cluster-domain>を使用することを推奨します。短いドメイン名 (<service-name>) を使用すると、過剰な無効な DNS クエリが発生し、名前解決時間が長くなります。クラスタードメインは、クラスター作成時に設定されるカスタム設定で、デフォルトは
cluster.localです。外部ドメイン名:VPC 内部ドメイン名とパブリックドメイン名が含まれます。これらのドメイン名を名前解決するには、CoreDNS がアップストリーム DNS サーバーから結果を取得する必要があります。デフォルトでは、アップストリーム DNS サーバーは PrivateZone サービスで、IP アドレスは 100.100.2.136 と 100.100.2.138 です。
重要PrivateZone は、パブリックドメイン名の再帰解決に対してサービスレベルアグリーメント (SLA) を提供していません。再帰解決の制限については、「再帰的クエリの管理」をご参照ください。
クラスター内の DNS コンポーネント
ACK マネージドクラスターでは、CoreDNS と NodeLocal DNSCache の 2 つのコンポーネントが DNS を処理します。
CoreDNS
CoreDNS には、マネージドと非マネージドの 2 つのモードがあります。
比較項目 | ||
適用クラスター |
|
|
デプロイモード | コントロールプレーンにデプロイされ、ACK によってフルマネージドされます。 コンソールの [コンポーネント管理] ページでは、ホスト型コンポーネントのカードに [ホスト型] と表示されます。 | クラスター内でワークロード (Deployment) としてデプロイされます。デフォルトでは、kube-system 名前空間にインストールされ、ワーカーノードのリソースを消費します。 |
運用保守責任 | Alibaba Cloud がコンポーネントの運用保守を担当します。 | 責任共有モデルに従います:
|
特徴 |
|
|
ログ | ログはデフォルトで有効になっています。 | サポートされていますが、手動で CoreDNS のログを有効にする必要があります。 |
モニタリングとアラート | Prometheus モニタリングをサポートします。クラスターのモニタリングを設定する必要があります。 | |
パフォーマンス | 詳細については、「マネージド CoreDNS のパフォーマンス」をご参照ください。 | コンポーネントの設定に依存します。 |
非マネージド CoreDNS
CoreDNS は、Kubernetes クラスター内で DNS 名前解決を処理するコンポーネントです。内部サービスのドメイン名と外部ドメイン名の両方を名前解決できます。CoreDNS プロジェクトは、Cloud Native Computing Foundation (CNCF) によってホストされています。詳細については、「CoreDNS: DNS and Service Discovery」をご参照ください。
オープンソースの Kubernetes 標準に従い、ACK クラスターは CoreDNS をデフォルトの DNS サーバーとしてインストールします。CoreDNS は、kube-system 名前空間に Deployment としてデプロイされます。kube-dns は、CoreDNS の ClusterIP タイプのサービスです。CoreDNS の設定方法については、「非マネージド CoreDNS の設定」をご参照ください。
次の例では、default 名前空間の Pod が database-svc にアクセスしようとし、次のプロセスを経ます:
Pod は
/etc/resolv.conf設定ファイルを確認し、DNS サーバーの IP アドレスが172.0.XX.XXであると判断します。これは kube-dns の ClusterIP です。設定ファイルの例は次のとおりです。nameserver 172.0.XX.XX # DNS サーバーの IP アドレスを定義します。 search default.svc.cluster.local svc.cluster.local cluster.local # ドメイン名の検索サフィックスルールを設定します。設定されている検索パスが多いほど、ルックアップ試行回数が増加します。 options ndots:5 # ドメイン名解決設定ファイルのオプションを定義します。複数のキーと値のペアがサポートされています。Pod は、
searchフィールドの値をサフィックスとして使用して、kube-dns に DNS クエリを送信し、次の名前を順次名前解決します:database-svc.default.svc.cluster.local(Pod と同じ名前空間内のサービス)database-svc.svc.cluster.local(別の名前空間内のサービス)database-svc.cluster.local(クラスター スコープのドメイン名)database-svc(外部ドメイン名)
CoreDNS Pod は結果を返し、それは IP アドレス 172.4.XX.XX です。
Pod はこの IP を使用してターゲットサービス
database-svcにアクセスします。リクエストが VPC 内部ドメイン名やパブリックドメイン名などの外部ドメイン名に対するものである場合、CoreDNS Pod はクエリをアップストリーム DNS サーバーに転送します。
重要CoreDNS は実行されているノードからアップストリーム DNS サーバーのアドレスを継承するため、ノードの DNS サーバー設定を変更しないでください。
CoreDNS の設定は、kube-system 名前空間の
corednsConfigMap に保存されています。デフォルト設定では、forwardプラグインは/etc/resolv.confを指しています。これは、アップストリーム DNS クエリに対して、CoreDNS が自身のコンテナの/etc/resolv.confファイルから DNS サーバーのアドレスを使用することを意味します。CoreDNS コンテナ内の/etc/resolv.confファイルは、デフォルトでホストノードの/etc/resolv.confファイルと同じであり、デフォルトの DNS サーバーアドレス 100.100.2.136 と 100.100.2.138 を使用します。ノードの DNS サーバー設定を変更すると、CoreDNS は誤ったアップストリーム DNS アドレスを使用し、名前解決の失敗や予期しない結果につながります。.:53 { ... forward . /etc/resolv.conf { prefer_udp } ... }
マネージド CoreDNS
マネージド CoreDNS は、非マネージド CoreDNS と同じ原則で動作しますが、ACK によって完全に管理されます。クラスターリソースを消費せず、お客様による運用保守は不要です。また、負荷に応じて自動的にスケーリングします。詳細については、「マネージド CoreDNS のパフォーマンス」をご参照ください。
マネージド CoreDNS は、自動モードが有効な ACK マネージドクラスターでサポートされています。自動モードが有効な ACK マネージドクラスターを使用するには、「自動モードが有効な ACK マネージドクラスターの作成」をご参照ください。
NodeLocal DNSCache
NodeLocal DNSCache は、各ワーカーノードに DNS キャッシュを設定して CoreDNS の負荷を軽減し、クラスターの DNS の安定性と可用性を向上させます。DNS 負荷が高い、または DNS 応答速度と安定性に対する要件が厳しいシナリオでこのコンポーネントをインストールすることを推奨します。コンポーネントのインストールと使用については、「NodeLocal DNSCache コンポーネントの使用」をご参照ください。
次の例では、NodeLocal DNSCache をインストールし、node-local-dns-injection: "enabled" ラベルを default 名前空間に追加した後、default 名前空間の Pod が database-svc にアクセスしようとし、次のプロセスを経ます:
Pod はまず、自身のノードの DNS キャッシュを確認します。
プロセスは、キャッシュヒットが発生したかどうかに応じて、2 つの方法のいずれかで進行します:
ノードの DNS キャッシュに
database-svcのレコードが含まれている場合、キャッシュヒットが発生します。キャッシュは結果を返し、Pod はこの結果を使用してサービスにアクセスします。キャッシュミスが発生した場合、つまりノードの DNS キャッシュに
database-svcのレコードがない場合、結果は CoreDNS から取得されます。CoreDNS からの結果は、将来の使用のためにノードの DNS キャッシュにキャッシュされます。
クラスターの DNS 設定
クラスター内の DNS は、それぞれ異なるスコープを持つ 3 つの異なるレベルで設定できます。
クラスター設定
ClusterDomain は、各ノードの kubelet 設定です。この設定は、クラスター内のすべての kubelet で一貫している必要があります。そうでない場合、ネットワークエラーが発生します。
ClusterDomainClusterDomain は、クラスターのローカルトップレベルドメインであり、クラスター内のすべてのサービスの完全なドメイン名のデフォルトのサフィックスです。デフォルト値は
cluster.localです。ClusterDomain 設定は、通常、クラスター内ネットワークとクラスター外ネットワークを区別するために使用されます。クラスターを作成する際に、ClusterDomain をカスタマイズできます。カスタムドメイン名が一般的に使用される外部ドメイン名と競合しないようにしてください。
ノード設定
resolveConfresolveConfは、ノード上の DNS 設定ファイルへのパスを指定します。Pod のdnsPolicyがDefaultの場合、kubelet はresolveConfで指定されたファイル (デフォルトは/etc/resolv.conf) を Pod の/etc/resolv.confにコピーします。
Pod 設定
各 Pod には、DNS ポリシーをカスタマイズするための 2 つの設定があります:
dnsPolicyは DNS 名前解決ポリシーを定義し、dnsConfigはカスタム DNS サーバーと検索ドメインを指定するために使用されます。dnsPolicyとdnsConfigをさまざまなシナリオで一緒に使用する方法の詳細については、「DNS ポリシーの設定とドメイン名の名前解決」をご参照ください。