転生したらEKSをTerraform管理することになった件

Transcript

1. 転生したらEKSをTerraform管理 することになった件 JAWS DAYS 2021前夜祭 - AWSのTechとJAWS-UGのトレンドキャッチアップ -
2. Copyright © every, Inc. All rights reserved. お前誰よ 名前 : 吉田 健太 HN : よしけん 所属 : エブリー株式会社MAMADAYS開発部 SRE 趣味 : steamでゲームを買う・植田ひかるさん TW : @yoshiken_tut
3. Copyright © every, Inc. All rights reserved. 株式会社エブリーとは
4. Copyright © every, Inc. All rights reserved. 植田ひかるさん 誕生日 : 1996年11月14日 (ちなみに僕は11月13日) 出身地 : 茨城県 血液型 : O型 所属 : オフィスアネモネジュニア 代表作 : クロムクロ（劉神美） 文豪ストレイドッグス(ルイーザ・A) Tokyo 7th シスターズ（西園ホノカ） ©オフィスアネモネ
5. Copyright © every, Inc. All rights reserved. 本題
6. Copyright © every, Inc. All rights reserved. いきなり AWS「あと数ヶ月で現行のEKSのサポート終了するよ。強制的にアップデートね。」 ぼく 「ぴえん🥺」 先輩「サービス開始以降EKSのアップデート1回だけしかしたことない…(再現性無」 ぼく「うーんこの」 上長「まかせた」 ぼく「たすけてー！！！！おかーさーーーーん！！！！おとーさーーーん！！！！」 転生(転職)したら...
7. Copyright © every, Inc. All rights reserved. そしてイベントホライゾンへ そもそもインフラ(AWS)を専属で見る人がいなかった。(故に僕が採用された サーバーサイドエンジニアが片手間で面倒を見るので最新情報のキャッチアップやベス トプラクティスができる体制ではない。 かと言って正論を振り回すと信用や連携に亀裂が生じ、属人化が生まれるので、今まで インフラを触ってたエンジニアと足並みを揃えてベストプラクティス等を教えつつ無理の ない(知識のオーバーフローが起きない)範囲で改修。 マウントダメ、絶対
8. Copyright © every, Inc. All rights reserved. 直近の課題 課題1 terraformの構成がめちゃくちゃ →健全な心でリソース変更ができない 課題2 再現性が低いアップデート →なんにもわからん 課題3 迫るEKSアップデート →迅速かつリスクが低いアップデートの確立
9. Copyright © every, Inc. All rights reserved. 直近の課題 課題1 terraformの構成がめちゃくちゃ →健全な心でリソース変更ができない 課題2 再現性が低いアップデート →なんにもわからん 課題3 迫るEKSアップデート →迅速かつリスクが低いアップデートの確立
10. Copyright © every, Inc. All rights reserved. Terraform構成改善案 workspaceが歴史的経緯(真相は闇)で使われてたり使われなかったり。 →事故多発の要因 →知識レベルがバラバラなのでworkspaceを使用せずにフォルダ構成のみ
11. Copyright © every, Inc. All rights reserved. Terraform構成改善案 workspaceが歴史的経緯(真相は闇)で使われてたり使われなかったり。 →事故多発の要因 →知識レベルがバラバラなのでworkspaceを使用せずにフォルダ構成のみ 各モジュールが完全に独立している状態。 →汎用性が低い(variable "region" をO(n)回分見る) →ルートを作成しその配下にツリー方式でmoduleを作成でDRYに
12. Copyright © every, Inc. All rights reserved.
13. Copyright © every, Inc. All rights reserved.
14. Copyright © every, Inc. All rights reserved. Terraform構成改善案 workspaceが歴史的経緯(真相は闇)で使われてたり使われなかったり。 →事故多発の要因 →知識レベルがバラバラなのでworkspaceを使用せずにフォルダ構成のみ 各モジュールが完全に独立している状態。 →汎用性が低い(variable "region" をO(n)回分見る) →ルートを作成しその配下にツリー方式でmoduleを作成でDRYに 依存関係はtfstateでの解消のみ。 →依存関係の可視化が全くないのでわかりづらい →moduleを呼び出す際に変数として与えることで可視化
15. Copyright © every, Inc. All rights reserved. 直近の課題 課題1 terraformの構成がめちゃくちゃ →健全な心でリソース変更ができない 課題2 再現性が低いアップデート →なんにもわからん 課題3 迫るEKSアップデート →迅速かつリスクが低いアップデートの確立
16. Copyright © every, Inc. All rights reserved. 過去の事例 • そもそもTerraform化されていないものをTerraform化するためのもの ◦ コードからコードへのアップデートは前例無し
17. Copyright © every, Inc. All rights reserved. 式年遷宮 • Cluster Migrationという方式 ◦ 新しいクラスターを立ち上げて、同一の podを作成 ▪ podが稼働状態になったら古いクラスターの podは廃棄してOK ◦ 後述するin-place upgradeに比べてダウンタイムも発生せず、 CoreDNSやKubeProxyなど色々な ことを考えずに済む ▪ しかも上げるバージョンの制約が無いので一気にアップデート (延命処置)ができる
18. Copyright © every, Inc. All rights reserved. Cluster Migration
19. Copyright © every, Inc. All rights reserved. Cluster Migration
20. Copyright © every, Inc. All rights reserved. Cluster Migration
21. Copyright © every, Inc. All rights reserved. 直近の課題 課題1 terraformの構成がめちゃくちゃ →健全な心でリソース変更ができない 課題2 再現性が低いアップデート →なんにもわからん 課題3 迫るEKSアップデート →迅速かつリスクが低いアップデートの確立
22. Copyright © every, Inc. All rights reserved. やったか…？ • 運用コストがでかすぎる問題 ◦ 新しいクラスターを作成するため、 SGやIAMなど追加で記述し確認する項目がサービス規模に比 例して増えていく ◦ バージョンが出るたびに行うにはあまりにも人の手が入りすぎる ▪ アップデートする間隔を開けてしまい結局リリースノート数バージョン分見直して余計コストが 掛かる運用が見えてしまった … • やらかし ◦ CronJobを移行の際に新クラスターで作成 →旧クラスターで停止の間に二重で実行されてしまった ▪ push通知だっため、ユーザー様のアプリに同一内容の通知が二重で飛ぶ • 👆先週やってしまった
23. Copyright © every, Inc. All rights reserved. In-place upgrade • 既存クラスター自体をアップデート ◦ ノードを順番にアップデートしていき乗り換える ◦ AWS EKSの公式ドキュメントはこちらを推奨している ◦ 基本的にはダウンタイムは発生しない。致命的なエラーによりアップデートができなくても自動で ロールバックされる。 ◦ Probeをきちんと定義しないとヘルスチェックできなくて爆死するよ！ • 結論はこちらを先に試して、ダウンタイムが発生するようならCluster Migration
24. Copyright © every, Inc. All rights reserved. In-place upgrade
25. Copyright © every, Inc. All rights reserved. In-place upgrade
26. Copyright © every, Inc. All rights reserved. In-place upgrade
27. Copyright © every, Inc. All rights reserved.
28. Copyright © every, Inc. All rights reserved.
29. Copyright © every, Inc. All rights reserved. アップデートに関してはAtsushi Tanaka さんの スライドがめちゃくちゃわかりやすいので読んでください https://speakerdeck.com/bgpat/kubernetes-cluster-migration
30. Copyright © every, Inc. All rights reserved. 実際にTerraformに書くときに気をつけることは？ • 公式が提供してる"terraform-aws-modules/eks/aws"を使いましょう。 ◦ https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest ◦ 以下のものを自動でよしなに生成 ▪ cloudwatch_log・ami.eks_worker・iam_policy・iam・security_group・local_file.kubeconfig・ kubernetes_config_map・node_groups・cluster • 基本的にEKSに関することなら全て(configmapとかも)Terraform上で管理ができる ので集約しましょう ◦ eksctl?知らない子ですねぇ
31. Copyright © every, Inc. All rights reserved. EKS独特の注意事項 • subnetに kubernetes.io/cluster/<cluster-name> というtagがつく ◦ VPCにもtagがつく ▪ ただしversionしだいで仕様が変わるので公式ドキュメントを check ◦ 消すとEKS側が認識できなくなって死ぬので忘れずに • alb-ingress-controllerで作成されたELBの名前がUUIDだけで何にもわからん ◦ tagで名前付いてるのでがんばってください … ◦ alb-ingress-controller自体はterraform上で管理ができるので、公式ドキュメントどおりにやるとつら みが発生するので気をつけてください • kube2iamという概念 ◦ 基本的にはnode(ec2)単位でのIAMと思われがちだが、不必要な権限まで podが所有する ◦ それを防ぐためにpod単位でIAMを絞り込む機能 ◦ これもTerraformで管理できるよ！
32. Copyright © every, Inc. All rights reserved. 終劇