以下の記事にあるように、"1.22 クラスターは 2023 年 6 月 4 日にサポートが終了"する。
https://aws.amazon.com/jp/blogs/news/amazon-eks-now-supports-kubernetes-version-1-26/
そして仕事で1.22をまさに使っているので、6/4までにアップグレードを終える必要がある。
これまでは自分が1人でアップグレード作業をしていたのだが、自分がやり続けることで他のメンバーの成長機会を奪うことにつながると考え、アップグレード作業を手放し他のメンバーにやってもらうことにした。
タイミングがいいのか悪いのか、これまでスムーズにいっていたアップグレード作業でいくつもどハマりしたので、未来の自分を助けるためにもメモを残しておく。
ハマったところたち
eksctlでnodegroupを使っていて、アップグレード作業の際にはnodegroupをもう一つ作り、古いnodeをdrainして、drainが完了したら古いnodegroupを削除するというのがアップグレード作業のおおまかな流れだ。
まず、eksctlで新しいバージョンのnodegroupを作ろうとしたが失敗した。
amiFamilyの指定が必要になってたことと、Amazon VPC CNI plugin for Kubernetes Amazon EKS アドオン(以下、CNIと表記)が古く新しく作ったnodeがhealthyにならなかったことが原因だった。
CNIのバージョンアップして、新しいバージョンのnodegroupを作れるようになり、古いnodeをdrainしようとしたときに、Throttlingが起きてdrainできない事象が発生した。詳細としてはkubectl get podしたときに、cronjobが作成するpodが大量に残っていたことでdrain起因の新たなpod作成に失敗していたことが原因のようだった。この時にすでにkube-proxyがうまく動いてなかったのだろう。
これは作業前の検証環境の状態確認が甘かったというか適当だったところなので反省しかない。
pod全て消してもdrainに失敗するので調べたところ、kube-systemのpodたちもうまく動いてなかった。aws-nodeはReadinessやLivenessのprobeでエラーがでていた。よく見ると、probeでgRPC通信が失敗していた
Readiness probe failed: {"level":"info","ts":"2020-06-16T15:34:23.817Z","caller":"/usr/local/go/src/runtime/proc.go:203","msg":"timeout: failed to connect service \":50051\" within 1s"}
aws-node Readiness probe errored: rpc error: code = Unknown desc = failed to exec in container: container is in CONTAINER_EXITED state
ここまでやって、kube-proxyが落ちていることに問題があるのでは？と気がついた。
kube-proxyは、ImagePullbackoffで落ちていた
ECRからImage取ってくるときに、no such hostと出ていたので通信がおかしいことがわかった
AWS公式のトラブルシューティングガイドを見ても全部正常だった
https://repost.aws/ja/knowledge-center/eks-ecr-troubleshooting
eksctl utils update-kube-proxy -c <cluster-name> --approve
をしたら、container imageのURLに、 region-code って入ってたせいでDNS名前解決に失敗していて、ImagePullできていないことがわかった。こんな感じのimageになっていた。ap-northeast-1が入るべきところにregion-codeという文字列が入ってしまったら名前解決できないのは、それはそうだねという感じ。
--region を渡さなかったからこうなった？まだよくわかっていないところ。
image: xxxxxxxxx.dkr.ecr.region-code.amazonaws.com/eks/kube-proxy:v1.23.17-eksbuild.1
daemonsetをyamlに吐き出して、region-codeをap-northeast-1に書き換えたらkube-proxyがうまく動いた。
kube-proxyがうまく動いたら、aws-nodeやcodednsもうまく動くようになった。
最後に
一度のアップグレード作業でいくつバージョンをあげるのがいいのだろう。
ECSでつくらないの？というのはもっともな質問であると思う。しかし、このサービスのインフラを作る時にパッと手が動くのがEKSであった。このような苦労があるならECS化したい気持ちが芽生えつつあるが、そこまでの工数割けるのか？というところはまだ具体的に考えられていない。
他の人に運用を渡そうとした途端にこのようなことになった。たくさんの失敗を経験できたので、まあよかったのではないだろうか。検証環境があって本当に良かった。
出張帰りの電車の中で、スマホで一気に書いた記事なので、前提条件などいろいろ雑になっているかもしれない。間違った認識により適当なことを書いているところがあるかもしれない。そのようなところを見つけたらご指摘ください。
