kube-proxy の更新タイミングについては Kubernetes: 詳解 Pods の終了 などの文献があるが、kube-dns の更新タイミングについては文献がなかったので自分で調査したメモ。
調べ方ポイント
kube-dns は通常２台に冗長化されている。
$ dig <service_name>.default.svc.cluster.local
のように調べると、どちらかの kube-dns に query が飛び、それぞれが保持しているTTLの値が異なるため、digを打つたびにTTLの値が変わったように錯覚を受ける。
$ dig <service_name>.default.svc.cluster.local
...
;; ANSWER SECTION:
<service_name>.default.svc.cluster.local. 28 IN A 10.4.9.10
[すぐ打つ]
$ dig <service_name>.default.svc.cluster.local
...
;; ANSWER SECTION:
<service_name>.default.svc.cluster.local. 2 IN A 10.4.9.10
[すぐ打ったのに TTL が 28 から急激に 2 に減ったように見える]
片方の kube-dns pod のIPアドレスを調べて
$ dig <service_name>.default.svc.cluster.local @<one_kubedns_ip>
のように調べると紛れがなくて良い（これに気づかず惑わされた。
Headless Service における kube-dns の更新タイミング
Headless Service はサービス名で名前解決したときに、サービスのVIPではなく、PodのIPアドレスを直接返してくるタイプのサービス。kube-proxy を通さずにクライアントからDNSラウンドロビンしたい場合に使う。
gRPCを使っていて仕方なく Client-Side LBしたい場合などに使う[1]。基本的にはkube-proxyを通さないDNSラウンドロビンは推奨されていない[2]
kube-dns への追加タイミング
pod が READY (readinessProbe で success)になると kube-dns に追加される。
その後 kube-dns の TTL (30 sec) が過ぎると、クライアント側から見れるようになる。
kube-dns からの削除タイミング
pod が TERMINATED status になる (完全に終了していなくても良い)と kube-dns から削除される。
その後 kube-dns の TTL (30 sec) が過ぎると、クライアント側から見れなくなる。
PS. つまり、(graceful) shutdown 中の pod に誤ってリクエストを飛ばしてしまうことがあるので gRPC で Client-Side LB している場合などはクライアント側でケアが必要だということ。
おまけ: Headless でない ClusterIP Service における kube-dns の更新タイミング
Headless でない ClusterIP Service の場合は Service の VIP が kube-dns に登録される。
Podのように運用中にがんがん動的に作成したり削除したりするものではないため、あまり更新タイミングが気になることはないが、一応書いておく。
kube-dns への追加タイミング
Service 作成のタイミングですぐに kube-dns に登録される。
その後 kube-dns の TTL (30 sec) が過ぎると、クライアント側から見れるようになる。
kube-dns からの削除タイミング
Service 削除のタイミングですぐに kube-dns から削除される。
その後 kube-dns の TTL (30 sec) が過ぎると、クライアント側から見れなくなる。