KubernetesDNSサービスの概要
序章
ドメインネームシステム(DNS)は、IPアドレスなどのさまざまな種類の情報を覚えやすい名前に関連付けるためのシステムです。 デフォルトでは、ほとんどのKubernetesクラスタは、サービス検出のための軽量メカニズムを提供するように内部DNSサービスを自動的に構成します。 組み込みのサービス検出により、ポッドやサービスが作成、削除、ノード間で移動されている場合でも、アプリケーションがKubernetesクラスター上で相互に簡単に検索して通信できるようになります。
Kubernetes DNSサービスの実装の詳細は、最近のバージョンのKubernetesで変更されています。 この記事では、KubernetesDNSサービスのkube-dnsバージョンとCoreDNSバージョンの両方を見ていきます。 それらがどのように動作し、Kubernetesが生成するDNSレコードを確認します。
始める前にDNSをより完全に理解するには、 DNSの用語、コンポーネント、および概念の概要をお読みください。 なじみのないKubernetesトピックについては、Kubernetesの概要をお読みください。
Kubernetes DNSサービスは何を提供しますか?
Kubernetesバージョン1.11より前は、KubernetesDNSサービスはkube-dnsに基づいていました。 バージョン1.11では、kube-dnsのセキュリティと安定性に関する懸念に対処するためにCoreDNSが導入されました。
実際のDNSレコードを処理するソフトウェアに関係なく、両方の実装は同じように機能します。
-
名前の付いたサービス
kube-dns
1つ以上のポッドが作成されます。 -
The
kube-dns
サービスは、KubernetesAPIからのserviceおよびendpoint イベントをリッスンし、必要に応じてDNSレコードを更新します。 これらのイベントは、Kubernetesサービスとそれに関連するポッドを作成、更新、または削除したときにトリガーされます。 -
kubeletはそれぞれの新しいポッドを設定します
/etc/resolv.conf
nameserver
のクラスタIPへのオプションkube-dns
適切なサービスsearch
より短いホスト名を使用できるようにするオプション:resolv.confnameserver 10.32.0.10 search namespace.svc.cluster.local svc.cluster.local cluster.local options ndots:5
-
コンテナで実行されているアプリケーションは、次のようなホスト名を解決できます。
example-service.namespace
正しいクラスターIPアドレスに。
KubernetesDNSレコードの例
完全なDNS A
Kubernetesサービスのレコードは次の例のようになります。
service.namespace.svc.cluster.local
ポッドには、ポッドの実際のIPアドレスを反映した、この形式のレコードがあります。
10.32.0.125.namespace.pod.cluster.local
さらに、 SRV
Kubernetesサービスの名前付きポートのレコードが作成されます。
_port-name._protocol.service.namespace.svc.cluster.local
これらすべての結果として、組み込みのDNSベースのサービス検出メカニズムが実現します。このメカニズムでは、アプリケーションまたはマイクロサービスがシンプルで一貫性のあるホスト名をターゲットにして、クラスター上の他のサービスやポッドにアクセスできます。
ドメインの検索と短いホスト名の解決
にリストされている検索ドメインのサフィックスのため resolv.conf
ファイルの場合、別のサービスに接続するために完全なホスト名を使用する必要がないことがよくあります。 同じ名前空間でサービスをアドレス指定している場合は、サービス名だけを使用してサービスに接続できます。
other-service
サービスが別の名前空間にある場合は、それをクエリに追加します。
other-service.other-namespace
ポッドをターゲットにしている場合は、少なくとも次のものを使用する必要があります。
pod-ip.other-namespace.pod
デフォルトで見たように resolv.conf
ファイルのみ .svc
接尾辞は自動的に入力されるため、最大ですべてを指定するようにしてください .pod
.
Kubernetes DNSサービスの実際の使用法がわかったので、2つの異なる実装の詳細をいくつか見ていきましょう。
KubernetesDNS実装の詳細
前のセクションで説明したように、Kubernetesバージョン1.11では、 kube-dns
サービス。 変更の動機は、サービスのパフォーマンスとセキュリティを向上させることでした。 オリジナルを見てみましょう kube-dns
最初に実装します。
kube-dns
The kube-dns
Kubernetes 1.11より前のサービスは、 kube-dns
ポッド kube-system
名前空間。 3つのコンテナは次のとおりです。
- kube-dns:DNSクエリ解決を実行するSkyDNSを実行するコンテナー
- dnsmasq:SkyDNSからの応答をキャッシュする人気のある軽量DNSリゾルバーとキャッシュ
- サイドカー:メトリクスレポートを処理し、サービスのヘルスチェックに応答するサイドカーコンテナ
Dnsmasqのセキュリティの脆弱性、およびSkyDNSのスケーリングパフォーマンスの問題により、代替システムであるCoreDNSが作成されました。
CoreDNS
Kubernetes 1.11以降、新しいKubernetesDNSサービスであるCoreDNSが一般提供に昇格しました。 これは、本番環境で使用する準備ができており、多くのインストールツールとマネージドKubernetesプロバイダーのデフォルトのクラスターDNSサービスになることを意味します。
CoreDNSは、Goで記述された単一のプロセスであり、以前のシステムのすべての機能をカバーしています。 単一のコンテナがDNSクエリを解決してキャッシュし、ヘルスチェックに応答し、メトリックを提供します。
CoreDNSは、パフォーマンスおよびセキュリティ関連の問題に対処することに加えて、その他のマイナーなバグを修正し、いくつかの新機能を追加します。
- stebDomainsと外部サービスの使用間の非互換性に関するいくつかの問題が修正されました
- CoreDNSは、特定のレコードを返す順序をランダム化することにより、DNSベースのラウンドロビン負荷分散を強化できます。
- と呼ばれる機能
autopath
にリストされている各検索ドメインサフィックスをより賢く反復することにより、外部ホスト名を解決する際のDNS応答時間を改善できます。resolv.conf
- kube-dnsを使用
10.32.0.125.namespace.pod.cluster.local
常に解決します10.32.0.125
、ポッドが実際に存在しない場合でも。 CoreDNSには、ポッドが適切なIPと適切な名前空間に存在する場合にのみ正常に解決される「ポッド検証済み」モードがあります。
CoreDNSの詳細と、kube-dnsとの違いについては、 KubernetesCoreDNSGAの発表をご覧ください。
追加の構成オプション
Kubernetesオペレーターは、ポッドとコンテナーが特定のカスタムドメインを解決する方法をカスタマイズしたい場合や、で構成されたアップストリームネームサーバーまたは検索ドメインサフィックスを調整する必要がある場合がよくあります。 resolv.conf
. あなたはこれを行うことができます dnsConfig
ポッドの仕様のオプション:
apiVersion: v1
kind: Pod
metadata:
namespace: example
name: custom-dns
spec:
containers:
- name: example
image: nginx
dnsPolicy: "None"
dnsConfig:
nameservers:
- 203.0.113.44
searches:
- custom.dns.local
この構成を更新すると、ポッドが書き換えられます resolv.conf
変更を有効にします。 構成は標準に直接マップされます resolv.conf
オプションなので、上記の設定でファイルが作成されます nameserver 203.0.113.44
と search custom.dns.local
行。
結論
この記事では、Kubernetes DNSサービスが開発者に提供するものの基本について説明し、サービスとポッドのDNSレコードの例をいくつか示し、システムがさまざまなKubernetesバージョンでどのように実装されるかについて説明し、ポッドをカスタマイズするために利用できるいくつかの追加の構成オプションを強調しました。 DNSクエリを解決します。
Kubernetes DNSサービスの詳細については、サービスとポッドの公式KubernetesDNSドキュメントを参照してください。