みているプロダクトがEKSv1.19→v1.21にアップデートをした。事業部専属というわけではなくてSREとして別プロダクトばっかりみてたらサポート残り1ヶ月の状態で「あ、やべ。残り一ヶ月でEKS強制アプデ入るわ」となり、やらなくては~となったがプロダクトのフロントエンドの子が「やってみたいです!」というので他のレイヤーに対する熱意◎でまかせたら、会社都合でその子が部署異動で「開発環境はアプデ終わりましたが本番はできませんでした...後はよろしくお願いいたします...」とバトンを渡され虚構に陥りながら開発のリハ無しに本番のアップデートをした。ある話っすね基本的には弊社のSREの方針としては運用は各事業部に任せることが前提とはいいつつほぼほぼノールックだったのは反省点。昔に1.19に上げた時に各APIリソースのアップデートもそこまでしておらず、残り時間と加味してリソースのアップデートの検証もできなかったので最新の1.22ではなく現行のリソースで最大ギリアップデート可能な1.21にした。Controllerというものに変わるらしく、今まで地味に不便だった1service⇔1ELBをNservice⇔1ELBにできるのでついでにやってしまおう。いう前提の元、話を進めていきます。Controllerが使えない。すべてのリクエストを受け入れる設定になる。ないとすべてのリクエストを受け入れてくれないわけですよ。受け付けないELBが爆誕します。ControllerでELBまとめるときに必要なので今のうちに書いておくと忘れなくて良いです。インストール基本的に公式ドキュメント通りにやれば問題ないです。Controllerをインストール(fargate化を少しでも考えてるなら大人しくhelmにしましょうこんな感じ。Controllerで作成されたリソースを書き換えようとするんですが、今回は既存リソースをそのままにしたかったのでちょこっとPolicyをいじります。matometa-elb正直開発環境のELBが無駄に立ち上がってるのは地味に費用面でイラッとしてたので助かる。一応デメリットがあって、今のところlogのs3のprefixがserviceで分けられないので面倒ではある。弊社だとelbのlogはs3に置いて、athenaで分析してるんですがscan量増えて料金増えるな~と思いつつ減らしたELB分考えれば+かなと判断してやってます。Controllerで作成されたまとめられたELBが立っているのでroute53の加重ルーティングあたりで切り替えていきましょう。kustomizeで管理してるからmanifestで管理したいんだけど。見て「管理できる!」って自信持ったらやってください。あとfargate対応考えるとねぇ。Controllerで作成されたingressが消せないんだけど。消せないっていうかレスポンス帰ってこないんだけど。emptyにするとOK簡単にいうと旧ingressが無のfinalizersを掴んでて、旧ingressを消そうとすると、旧ingressが「無を消してからワイ消えますわ!」って状態になり無は無なので無を消せずにレスポンス帰ってこないってわけです。おりゃ!ってすればemptyで上書きします。つければレスポンス待たずに消えるらしいのでお好みで。