Kubernetes（以下K8s）上で分散システムやマイクロサービスを構築する際、アプリケーションコンポーネントはPodとしてデプロイされ、相互に通信を行います。この際、Pod同士の通信先を特定するために使われる仕組みの一つがDNSによる名前解決です。「Podはスケールやアップデートによって入れ替わるが、その度にIPアドレスって変わるよね？DNSキャッシュが残ってたら古いIPを参照してしまうんじゃ？」って思ったので調べてみました。

今回は、この調査結果、この問題がどのように解決されているのか、K8s固有の仕組みを踏まえて解説します。

なぜPod間通信でDNSが必要なのか

K8sでは、アプリケーションは一般的にPod単位でデプロイされます。しかし、Podは流動的な存在です。Rolling UpdateやAuto ScalingによりPodは頻繁に消えたり生まれたりします。そのため、特定の機能を担うPodに直接IPアドレスで接続するのは理にかなっていません。IPアドレスが変わるたびにクライアント側の設定を書き換えるわけにはいかないからです。

そこで、DNS名による抽象化が導入されます。K8sでは「Service」というリソースを用いて、同一の機能を提供する複数のPodに対して1つの安定した名前と仮想的なIPアドレスを割り当てます。クライアントは<serviceName>.<namespace>.svc.cluster.localのような一定のホスト名を使うことで、Podの入れ替わりを意識せずに接続先を指定できます。

ServiceとEndpointsで抽象化

ServiceがどのようにPodへのトラフィックを振り分けているのか、その裏側には「Endpoints」という仕組みがあります。EndpointsはServiceが参照するPodのIPアドレス群を保持するK8sリソースです。

• 新たなPodが立ち上がれば、そのPodのIPはEndpointsに自動的に追加されます。
• Podが削除されたり、ReadyでなくなればEndpointsから消えます。

このように、Service → Endpoints → Podという関係で、Podリストは随時最新化されます。

CoreDNSによる高速なDNS更新と短いTTL

K8sクラスタ内のDNSは、標準でCoreDNSが担当します。CoreDNSはKubernetes APIをウォッチし、ServiceやEndpointsに変更があれば、それに応じてDNSレコードを動的に更新します。

このDNSレコード更新頻度が高いことを前提に、CoreDNSは非常に**短いTTL(Time To Live)**をDNSエントリに付与します。TTLが数秒程度の場合、DNSキャッシュはすぐに無効化され、クライアントは短い間隔で再びDNS問い合わせを行うため、Pod入れ替えに伴うIP変化にすばやく追従可能です。

つまり、IP変更が発生しても、古いDNS情報はすぐに更新され、次の接続試行時には最新のIPを取得できるようになります。

kube-proxyによる動的なトラフィック制御

DNSが最新のPodリストを返したとしても、実際にトラフィックを振り分けるのはNode上で稼働するkube-proxyです。kube-proxyはEndpointsに基づいてiptablesやipvsルールを動的に更新し、Service宛てのリクエストを適切なPodに振り分けます。これにより、DNS解決後の実際のパケットルーティングもシームレスに切り替わります。

まとめ

Kubernetesでは、以下の要素が組み合わさることで、Pod入れ替え時のDNSキャッシュ問題を緩和・解決しています。

• Serviceによる抽象化：Service名でPod集合を指し示し、Pod IPの変動を意識させない
• Endpointsによる動的更新：Podリストを常に最新状態へアップデート
• CoreDNSの短いTTL設定：DNSキャッシュを短期間で更新し、古いIPを参照し続けることを防ぐ
• kube-proxyによるロードバランシング：Podへのトラフィックを即座に最新のEndpointsへ振り向け

この統合的な仕組みにより、Podが頻繁に入れ替わるクラウドネイティブな環境でも、名前解決が常に最新の状態を反映でき、DNSキャッシュ期間による問題が最小化されているのです。

---

これらを理解すると、K8sが大規模な分散システムをスケーラブルかつ可用性の高い形で支えるために、徹底した抽象化と動的更新の仕組みを用いていることがわかります。
これらが巧妙に組み合わされていることで、開発者はPodのIP変化を気にせず、アプリケーション開発に集中できるようになってるんですねえ〜