EKS でクラスターを構築していると、kubernetes (以下 k8s) のバージョンアップなどを安全に行いたいといったニーズからクラスターごと新しく作って DNS の切り替えでクラスターを更新したいという事があると思います (事前に新しいバージョンでの動作確認などを行いたいといった理由から、DROBE ではそれが良さそうという結論になりました)

この記事では、クラスター切り替え時に考える事になる external-dns の挙動について解説します

external-dns とは k8s の ingress や service と外部の DNS と紐付けを行ってくれる k8s object です

Helm を使って cluster に install すると、external-dns の deployments に加えて service account なども一緒に作られます

external-dns の動作は非常にシンプルです

監視対象となる k8s resource を設定しておくと、その resource の生き死にを検知して DNS のレコードを調整してくれるといった挙動になります

AWS であれば対象となる Route53 の Zone やレコードに対して read / write が行えるような IAM を発行して Service アカウントに紐づけておく事で AWS リソースの編集を行ってくれます

DROBE では監視対象として Service:Loadbalancer に加えて istio の istio-gateway と istio-virtualservice も監視対象としています (istio が作る Loadbalancer に domain を向けたいため)

冒頭で説明したように EKS cluster を 2 つ作って Cluster1 から Cluster2 に切り替える事を想定してみます

まず Cluster1 が作業開始時点での primary (domain への traffic が向いている Cluster) だとすると、Cluster2 を作る際には external-dns だけは作らないでおいておく必要があります

この時点で Route53 の record の管理は Cluster1 の external-dns が行っています

次に、Cluster1 の external-dns を削除します

ここで external-dns の policy を upsert-only にしておく事で external-dns が削除されても Route53 にレコードは残ります (policy を sync にしてしまうと Route53 のレコードが消えてしまうので注意が必要です)

最後に Cluster2 の external-dns を作ります

この時点で Route53 のレコードの書き換えが発生し、domain にきた traffic は Cluster2 に向くようになります

あとは Cluster1 を削除してしまえば切り替えが完了になります

注意点として Cluster1 と Cluster2 の external-dns の txtOwnerId を同じにしておかないと DNS レコードの上書きが発生しません

txtOwnerId はもともと意図しない DNS レコードの上書きなどを防ぐものだと思いますが、この場合には同じにしておかないと意図した動作にならないので注意が必要です

external-dns を利用した EKS Cluster の切り替えについて記載しました

eks はバージョンの更新にしっかりついていく事が必要になる一方で、稼働中のクラスターのバージョンをあげるのがやっかいな部分もあると思います

この手法を使う事で、新しい Cluster に traffic を向ける事なく動作確認を行って、ある程度安全に切り替える事が出来ると思います