ノート。 翻訳。: Kubernetes の DNS の問題、より正確にはパラメータ設定 ndots、驚くほど人気があり、すでに 。 このトピックに関する別のメモでは、インドの大手証券会社の DevOps エンジニアである著者が、Kubernetes を運用する同僚にとって知っておくと役立つことについて非常にシンプルかつ簡潔に語っています。
Kubernetes にアプリケーションをデプロイする主な利点の XNUMX つは、シームレスなアプリケーション検出です。 サービスコンセプト ()、これはポッド IP アドレスのセットをサポートする仮想 IP です。 たとえば、サービスの場合、 vanilla サービスに連絡したい chocolateの仮想 IP に直接アクセスできます。 chocolate。 この場合、誰が DNS リクエストを解決するのかという疑問が生じます。 chocolate どうやって？
DNS 名前解決は、次を使用して Kubernetes クラスター上で構成されます。 。 Kubelet はファイル内のネームサーバーとして CoreDNS にポッドを登録します /etc/resolv.conf すべてのポッド。 内容を見てみると /etc/resolv.conf どのポッドでも、次のようになります。
search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5
この構成は、DNS クライアントが要求を DNS サーバーに転送するために使用します。 ファイル内 resolv.conf には次の情報が含まれています。
- ネームサーバー: DNS リクエストの送信先サーバー。 この例では、これは CoreDNS サービスのアドレスです。
- サーチ: 特定のドメインの検索パスを定義します。 興味深いのは、
google.comまたはmrkaran.devFQDN ではありません (）。 ほとんどの DNS リゾルバーが従う標準規則によれば、ルート ゾーンを表すドット「.」で終わるものだけが完全修飾 (FDQN) ドメインとみなされます。 一部のリゾルバーは、自分でポイントを追加できます。 したがって、mrkaran.dev.は完全修飾ドメイン名 (FQDN) であり、mrkaran.dev- いいえ; - ドット: 最も興味深いパラメータ (この記事はそれについてです)。
ndotsリクエスト名が「完全修飾」ドメイン名とみなされるまでの、リクエスト名のドット数のしきい値を指定します。 これについては、後で DNS ルックアップ シーケンスを分析するときに詳しく説明します。
尋ねると何が起こるか見てみましょう mrkaran.dev ポッド内:
$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53
Non-authoritative answer:
Name: mrkaran.dev
Address: 157.230.35.153
Name: mrkaran.dev
Address: 2400:6180:0:d1::519:6001
この実験では、CoreDNS ログ レベルを次のように設定しました。 all (そのため非常に冗長になります)。 ポッドのログを見てみましょう coredns:
[INFO] 10.1.28.1:35998 - 11131 "A IN mrkaran.dev.hello.svc.cluster.local. udp 53 false 512" NXDOMAIN qr,aa,rd 146 0.000263728s
[INFO] 10.1.28.1:34040 - 36853 "A IN mrkaran.dev.svc.cluster.local. udp 47 false 512" NXDOMAIN qr,aa,rd 140 0.000214201s
[INFO] 10.1.28.1:33468 - 29482 "A IN mrkaran.dev.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000156107s
[INFO] 10.1.28.1:58471 - 45814 "A IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 56 0.110263459s
[INFO] 10.1.28.1:54800 - 2463 "AAAA IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 68 0.145091744sふー。 ここで XNUMX つのことに注目してください。
- リクエストは、応答にコードが含まれるまで、検索のすべての段階を通過します。
NOERROR(DNS クライアントはそれを理解し、結果として保存します)。NXDOMAINは、指定されたドメイン名のレコードが見つからなかったことを意味します。 なぜならmrkaran.devFQDN 名ではありません (ndots=5)、リゾルバは検索パスを調べてリクエストの順序を決定します。 - エントリ
АиАААА並行して到着します。 実際のところ、XNUMX 回限りのリクエストは/etc/resolv.confデフォルトでは、IPv4 および IPv6 プロトコルを使用して並列検索が実行されるように構成されています。 オプションを追加することでこの動作をキャンセルできますsingle-requestвresolv.conf.
注意： glibc これらのリクエストを順番に送信するように構成できます。 musl - いいえ、Alpine ユーザーは注意してください。
ndot を試してみる
もう少し実験してみましょう ndots このパラメータがどのように動作するかを見てみましょう。 アイデアはシンプルです。 ndots DNS クライアントがドメインを絶対として扱うか相対として扱うかを決定します。 たとえば、単純な Google DNS クライアントの場合、このドメインが絶対ドメインであるかどうかはどのようにしてわかるのでしょうか? 設定した場合 ndots 1 に等しい場合、クライアントはこう言います。 google 単一の点はありません。 検索リスト全体を調べてみようと思います。」 ただし、尋ねると、 google.com、要求された名前がしきい値を満たしているため、サフィックスのリストは完全に無視されます。 ndots (少なくとも XNUMX つのポイントがあります)。
これを確認しましょう:
$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10#53
** server can't find mrkaran: NXDOMAINCoreDNS ログ:
[INFO] 10.1.28.1:52495 - 2606 "A IN mrkaran.hello.svc.cluster.local. udp 49 false 512" NXDOMAIN qr,aa,rd 142 0.000524939s
[INFO] 10.1.28.1:59287 - 57522 "A IN mrkaran.svc.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000368277s
[INFO] 10.1.28.1:53086 - 4863 "A IN mrkaran.cluster.local. udp 39 false 512" NXDOMAIN qr,aa,rd 132 0.000355344s
[INFO] 10.1.28.1:56863 - 41678 "A IN mrkaran. udp 25 false 512" NXDOMAIN qr,rd,ra 100 0.034629206s
以来 mrkaran 単一のポイントは存在せず、検索はサフィックスのリスト全体にわたって実行されました。
注: 実際の最大値は ndots 15 個に制限されています。 Kubernetes のデフォルトでは 5 です。
本番環境でのアプリケーション
アプリケーションが大量の外部ネットワーク呼び出しを行う場合、アクティブなトラフィックの場合に DNS がボトルネックになる可能性があります。これは、名前解決によって (システムが適切なクエリを取得する前に) 多くの不要なクエリが作成されるためです。 通常、アプリケーションはドメイン名にルート ゾーンを追加しませんが、これはハッキングのように思えます。 つまり、尋ねるのではなく、 api.twitter.com、「ハードコード」することができます api.twitter.com. これにより、DNS クライアントは絶対ドメインで直接権限のある検索を実行するように求められます。
さらに、Kubernetes バージョン 1.14 以降、拡張機能 dnsConfig и dnsPolicy 安定したステータスを取得しました。 したがって、ポッドをデプロイするときに、値を減らすことができます。 ndots、たとえば、最大 3 つまでです (最大 1 つまでです!)。 このため、ノード内のすべてのメッセージには完全なドメインが含まれている必要があります。 これは、パフォーマンスと移植性のどちらかを選択する必要がある場合の典型的なトレードオフの XNUMX つです。 DNS の結果も内部にキャッシュされるため、アプリケーションにとって超低遅延が不可欠な場合にのみ、この点を考慮する必要があるように思えます。
リファレンス
私がこの機能を初めて知ったのは、 、25月XNUMX日に開催されました。 とりわけ、この問題について議論がありました。
さらに詳しく調べるためのリンクをいくつか示します。
- 、なぜ Kubernetes では ndots=5 なのか。
- ndot の変更がアプリケーションのパフォーマンスにどのような影響を与えるか。
- musl と glibc リゾルバーの間。
注：私は使用しないことにしました dig この記事で。 dig 自動的にドット (ルート ゾーン識別子) が追加され、ドメインが「完全修飾」 (FQDN) になります。 ノー まず検索リストを実行します。 これについては 。 ただし、一般に、標準の動作に対して別のフラグを指定する必要があることは非常に驚くべきことです。
DNS を楽しんでください。 また後で！
翻訳者からの追伸
私たちのブログもお読みください:
- «";
- «";
- 「Kubernetes でのネットワークの図解ガイド」: , .
出所： habr.com