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

by Yoshiken

Slide 1

Slide 1 text

転生したらEKSをTerraform管理することになった件 JAWS DAYS 2021前夜祭 - AWSのTechとJAWS-UGのトレンドキャッチアップ -

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Copyright © every, Inc. All rights reserved. いきなり AWS「あと数ヶ月で現行のEKSのサポート終了するよ。強制的にアップデートね。」ぼく「ぴえん🥺」先輩「サービス開始以降EKSのアップデート1回だけしかしたことない…(再現性無」ぼく「うーんこの」上長「まかせた」ぼく「たすけてー！！！！おかーさーーーーん！！！！おとーさーーーん！！！！」転生(転職)したら...

Slide 7

Slide 7 text

Copyright © every, Inc. All rights reserved. そしてイベントホライゾンへそもそもインフラ(AWS)を専属で見る人がいなかった。(故に僕が採用されたサーバーサイドエンジニアが片手間で面倒を見るので最新情報のキャッチアップやベストプラクティスができる体制ではない。かと言って正論を振り回すと信用や連携に亀裂が生じ、属人化が生まれるので、今までインフラを触ってたエンジニアと足並みを揃えてベストプラクティス等を教えつつ無理のない(知識のオーバーフローが起きない)範囲で改修。マウントダメ、絶対

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Copyright © every, Inc. All rights reserved. Terraform構成改善案 workspaceが歴史的経緯(真相は闇)で使われてたり使われなかったり。 →事故多発の要因 →知識レベルがバラバラなのでworkspaceを使用せずにフォルダ構成のみ各モジュールが完全に独立している状態。 →汎用性が低い(variable "region" をO(n)回分見る) →ルートを作成しその配下にツリー方式でmoduleを作成でDRYに

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Copyright © every, Inc. All rights reserved. 式年遷宮 ● Cluster Migrationという方式 ○ 新しいクラスターを立ち上げて、同一の podを作成 ■ podが稼働状態になったら古いクラスターの podは廃棄してOK ○ 後述するin-place upgradeに比べてダウンタイムも発生せず、 CoreDNSやKubeProxyなど色々なことを考えずに済む ■ しかも上げるバージョンの制約が無いので一気にアップデート (延命処置)ができる

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Copyright © every, Inc. All rights reserved. やったか…？ ● 運用コストがでかすぎる問題 ○ 新しいクラスターを作成するため、 SGやIAMなど追加で記述し確認する項目がサービス規模に比例して増えていく ○ バージョンが出るたびに行うにはあまりにも人の手が入りすぎる ■ アップデートする間隔を開けてしまい結局リリースノート数バージョン分見直して余計コストが掛かる運用が見えてしまった … ● やらかし ○ CronJobを移行の際に新クラスターで作成 →旧クラスターで停止の間に二重で実行されてしまった ■ push通知だっため、ユーザー様のアプリに同一内容の通知が二重で飛ぶ ● 👆先週やってしまった

Slide 23

Slide 23 text

Copyright © every, Inc. All rights reserved. In-place upgrade ● 既存クラスター自体をアップデート ○ ノードを順番にアップデートしていき乗り換える ○ AWS EKSの公式ドキュメントはこちらを推奨している ○ 基本的にはダウンタイムは発生しない。致命的なエラーによりアップデートができなくても自動でロールバックされる。 ○ Probeをきちんと定義しないとヘルスチェックできなくて爆死するよ！ ● 結論はこちらを先に試して、ダウンタイムが発生するようならCluster Migration

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

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?知らない子ですねぇ

Slide 31

Slide 31 text

Copyright © every, Inc. All rights reserved. EKS独特の注意事項 ● subnetに kubernetes.io/cluster/ というtagがつく ○ VPCにもtagがつく ■ ただしversionしだいで仕様が変わるので公式ドキュメントを check ○ 消すとEKS側が認識できなくなって死ぬので忘れずに ● alb-ingress-controllerで作成されたELBの名前がUUIDだけで何にもわからん ○ tagで名前付いてるのでがんばってください … ○ alb-ingress-controller自体はterraform上で管理ができるので、公式ドキュメントどおりにやるとつらみが発生するので気をつけてください ● kube2iamという概念 ○ 基本的にはnode(ec2)単位でのIAMと思われがちだが、不必要な権限まで podが所有する ○ それを防ぐためにpod単位でIAMを絞り込む機能 ○ これもTerraformで管理できるよ！

Slide 32

Slide 32 text