Integrating Cloud DNS with GKE | Google Cloud Blog
課題
GKEないしはk8sではDNSクエリがとんでもない数発生する。というのもPod間の通信はドメイン名で行われるので、その解決に都度クエリが発生するからだ。
その他にもServiceアクセス、ServiceMesh…など、スケーラブルで高可用なシステムを維持するにはFQDNは欠かせない。
k8sはcoreDNSをというPodがこれらを一手に引き受けているが、coreDNSが負荷上がりすぎてk8sクラスタが事故るケースもよく聞く。
コロプラなどの大規模クラスタを運用しているところはNode Local DNS Cacheを各Nodeに入れることでレイテンシ減少とBlastRadiusを小さくしている。
『ドラゴンクエストウォーク』で、Kubernetesのマルチクラスター構成を採用した経緯｜コロプラベアーズ
CloudDNSが解決すること
- Node(Pod)からリンクローカルアドレス経由でDNSが利用可能なため、Node Local DNS CacheやCoreDNSが不要 (管理Pod減らせる)
- DNSは複数クラスタで同時に使えるので異なるクラスタのFQDNを共有可能
- GKEサービスのためのマルチリージョンのクロスクラスターサービスディスカバリ
価格
- マネージド ゾーン 料金
- 25 ゾーンまで マネージド ゾーンあたり $0.20/月
- 26～1 万ゾーン マネージド ゾーンあたり $0.10/月
- 1 万ゾーン超 マネージド ゾーンあたり $0.03/月
- トラフィック 料金
- 10 億件まで 100 万件のクエリごとに $0.40/月
- 10 億件超 100 万件のクエリごとに $0.20/月
トラフィックがどれぐらいあるのか次第だけど10億でも月2万なので安い。Podのリソースをペイできそう。
個人的見解
DNSは複数クラスタで同時に使えるので異なるクラスタのFQDNを共有可能が非常に大きいと思っている。クラスタ間の名前解決はServiceMeshの仕組みを使うか、SubmarinerのLightHouse / skupperのようなクラスタ間接続のソフトウェアが必要だった。（もしくはLoadBalancer / Ingress利用)
クラスタ間通信をどう実現すべきか？は変わらず検討範囲だが、名前解決をクリアできたのは大きい。（使ってみないとわからないけど、流石にClusterIPしかないSeviceの名前解決ができてもクラスタ外からアクセスできないよね…？それともなんかGCPのスーパーネットワーク的な仕組みでうまいことNATとかすんのかな？ / ExternalIPとかうまく使えるなら）
公式サイトを見るとこれしかないのでうーん。NodePortなのかなあ。
- ClusterIP（デフォルト）
- NodePort
- LoadBalancer
- ExternalName
- Headless
クラスタごとに同じNamespace / Serviceを使うとレコードがかぶる恐れがあるのでうまく設計する必要がある。
->VPCスコープDNSを見るとクラスタごとに一意のドメイン発行するらしい。
あとはcoreDNSで見れるメトリクスやログに比べてCloudDNSがどの程度充実しているのか？とか、安定性はどんなもんじゃい？っていうところがクリアできれば積極的に使っていきたい。
EKSもコンセプト同じこと外から見るとすぐできる気がするので、是非取り込んでもらいたいです！！！
