背景

EKSの1.24が2024/01末日でEOLを迎えます。
それに伴って、最新のバージョンに上げました。（サービス無停止）
そこで得た知見をシェアします。

前提として
AWS上でクラスタを構築していて、terraformで管理されています。

全般

kubernetes上にOSSで他のアプリケーション(Argo etc)を使っていたら
upgrade guide みたいなものがあるので一通りを通すと、問題に直面した時に感が利く。
release noteとか、見てたら、日が暮れてしまうので、そこまでしなくてよかったと反省。

https://aws.github.io/aws-eks-best-practices/
が更新されていそうなので、適宜眺めておくとよかった。

in-placeであげるよりも、同じ構成のクラスタをもう一つ用意して、lbで切り替えた方が良さそう。

IaC必須

https://aws.amazon.com/about-aws/whats-new/2023/12/amazon-eks-upgrade-insights/
こういう機能が出たけど、あまり役に立たなそうだった。（Custom resource使っていると、影響あるリソースが網羅できていないので注意）

あまりk8s 依存がないので、単体であげる方が良さそう。
最新のバージョンは権限まわりが厳しくなっているので、ちゃんと設計した方が良さそう
雑に最低権限だけ与えていても動くっちゃ動く

あまりk8s 依存がないので、単体であげる方が良さそう。
アップグレードによる影響がほぼない。
webhookAPI使えるので、うまく利用して、CronWorkflowとかcliで管理すると楽

canary releaseができるみたいなので、利用して、単体でupgradeすると良さそう。
1.21はExternalName周りの挙動に気になる変更があるので、1.20にアップグレードしてから、当該の機能を有効化する動作検証やっといた方が良さそう。

動作確認になかなか骨が折れた。
動作確認のためにcli commandをたくさん書いて、テスト項目書を作ったので、cli周りはそこそこ慣れた。

やったことのボリュームが大きすぎて、何か書き残そうと思ったけど、まとめるのがしんどくなるので、内容が薄くなってしまう。

SREチームのメンバー数人に合意を得ながら一人で進めたので、
このプロジェクトに従事した３ヶ月で書いたドキュメントの量はそこそこあるが、
X(twitter)の採用ページにドキュメント書く人材よりコード各人材のが価値がある。
みたいな記載があって悲しくなった。