EKSバージョンアップ工数削減大作戦！ ~Terraform化とE2Eテスト自動化~ 株式会社 kubell コミュニケーションプラットフォーム本部 SRE部 桝谷 花世 2024年11月28日

「Chatwork」とは ※※Nielsen NetView 及びNielsen Mobile NetView Customized Report 2024年4月度調べ月次利用者（MAU:Monthly Active User）調査。 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む41サービスを株式会社kubellにて選定。 効率的に情報共有できる グループチャット 仕事の見える化ができる タスク管理 見落としがなくなる ファイル管理 いつでも会議ができる ビデオ/音声通話

自己紹介 3 桝谷 花世 (Masutani Hanayo) 所属　株式会社 kubell 　　　コミュニケーションプラットフォーム本部 　　　SRE部 ~2023/09 SIerにて主にインフラ領域を担当 2023/10~ 株式会社kubell SRE部に入社 　　　　　　　 主にKubernetes周辺を担当 x: hnchn87 SRE部では 「Chatwork」のSREやPlatform Engineeringを担当

4 「Chatwork」はAWSを利用しています

AWSリソースは開発チームで構築 5 必要なAWSリソースはSREが関与することなく開発チームで構築 Terraform×Atlantisについて詳しくは古屋さんの登壇資料へ！ ( https://speakerdeck.com/saramune/gabanansuxiang-shang-wei-yuan-hui-with-opa) Terraform PR EKS 2.Pull 開発者 1.Comment 3.Check 4.Apply

ApplicationはEKS上で稼働 App Manifest EKS(app) EKS (manager) Manifest 1.Master merge 3.Push 2.Build 4.Update 5. Polling 7.Apply 開発者 6. Press the Sync button Helmfiles datadog- agent cert- manager 7.Apply リリースプロセスについて詳しく以下の資料へ！ ( https://speakerdeck.com/hanayo04/ekstoargo-rolloutdeshi-xian-suru-chatwork-noxin-ririsupurosesu)

7 みなさんEKSのバージョンアップどうしてますか？

8 「Chatwork」ではBlue-Green方式でバージョンアップを実施 EKS(ver1.29) datadog- agent cert- manager cluster- autoscaler fluent external- dns Chatwork EKS(ver1.30) datadog- agent cert- manager cluster- autoscaler fluent external- dns Chatwork

移行時の役割分担 9 新EKSの構築と各種ツールのインストールが SREの役割 EKS(ver1.29) datadog- agent cert- manager cluster- autoscaler fluent external- dns Chatwork EKS(ver1.30) datadog- agent cert- manager cluster- autoscaler fluent external- dns Chatwork SRE Dev SRE Dev

10 EKSの構築と各種ツールのインストールを なるべく楽にしたい！

achlis + Argo CD 11 achlisでEKSクラスタを構築 achlis(eksctlのwrapper)でeksctlで使用する設定ファイルを生成したりしつつ、 EKSクラスタを構築 詳しくはCreater’s Noteへ https://creators-note.chatwork.com/entry/2020/02/13/144318 各種ツールを Argo CD経由でデプロイ datadog-agentやfluentなどSRE管轄の各種ツールをArgo CDを使ってデプロイ

achlis + Argo CD の問題点 12 1. 手元のPCから実行する必要がある 2. SREでしか触れない

achlis + Argo CD の問題点① 13 手元のPCから実行する必要がある $ VAR_ENV=XXX ./achlis build --aws-profile=*** 設定ファイルを作成 vpcId: "vpc-xxxxx" publicSubnetNameFilter: "xxxxx-*" … buildしてファイル生成 $ VAR_ENV=XXX ./achlis apply --aws-profile=*** applyしてEKSクラスター作成 生成されたファイルを masterにマージ&Argo CDでSync $ git commit $ git push origin master CI上で動かすことも可能ではあるが、生成されたファイルを commit/pushしたり、AWSクレデン シャル等の関係で自動化の難易度が高い

achlis + Argo CD の問題点② 14 SREでしか触れない EKSクラスターの作成・削除を行える強い権限が必要なので限られた人しか触れないツールに なってしまっている SRE ほぼAdmin権限を所持 (機密情報等 一部は閲覧・操作不可 ) 担当領域の運用保守に 必要な権限のみを所持 開発 開発チームは担当領域のAWSリソースは自分たちで構築できるのに EKSのSAはachlisで管理されているためSREに依頼しないといけない

15 achlisからTerraform + helmfiles に移行しました！

なぜTerraform？ 16 EKS以外のAWSリソースは Terraformで管理されていた いろいろなタイミングが噛み合った

なぜTerraform？ 17 EKS以外のAWSリソースは Terraformで管理されていた atlantis apply とコメントすると atlantisさんが Terraformを実行してくれる atlantisを使って、既にPR上でTerraformを実行出来る環境が整っていた

なぜTerraform？ いろいろなタイミングが噛み合った Terraformの新機能への追従が遅い リソース作成順のコントロールが難しい k8sとTerraformの境界分離が難しい achlis開発時は公式が提供しているeksctl の方が新機能への追従が早かった aws-authの依存関係を考慮しないと Terraformでのクラスタ作成時にエラーにな り、移行が現実的ではなかった IRSAを使用すると、IAMロールの中にクラス タ情報を記載する必要があり、k8sと Terraformの境界分離が難しかった Terraformの新機能への追従が早くなった Access Entryがリリースされた Pod Identityがリリースされた Terraformが普及し、基本的には追従が遅く て困るようなことはなくなった 2023末にAccess Entryがリリースされ、 Terraformとk8sの依存関係が減った 2023末にPod Identityがリリースされ、 IAMロール内にクラスタ情報が不要になった https://creators-note.chatwork.com/entry/2024/02/07/162154

Terraform化した際の工夫点 19 terraform_dataを活用 パラメーターの変更はないがノードグループを入れ替えたい Terraform実行の途中でスクリプトを実行したい

Terraform化した際の工夫点 terraform_dataとは Terraformにおける管理リソースタイプの一つで、標準的なリソースライフサイクルを実装する が、他のアクションを直接実行することはない。 本リソースは、プロバイダーの設定を必要とせず、常に組み込みプロバイダーを通じて利用可 能。 主に、管理リソースライフサイクルに従う必要がある値を保存したり、他に適切な管理リソースが ない場合にプロビジョナーをトリガーするために使用される。 https://developer.hashicorp.com/terraform/language/resources/terraform-data

Terraform化した際の工夫点 パラメータの変更はないがノードグループを入れ替えたい resource "aws_eks_node_group" "managed_node_group" { for_each = local.eks_managed_node_groups ... lifecycle { replace_triggered_by = [ terraform_data.replace_nodegroup[each.key] ] } } resource "terraform_data" "replace_nodegroup" { for_each = local.eks_managed_node_groups input = 1 } inputを更新することで、 パラメータの変更なしでノードグループを 更新可能 lifecycleのreplace_triggered_byに terraform_dataを指定

Terraform化した際の工夫点 Terraform実行の途中でスクリプトを実行したい resource "terraform_data" "update_autoscaling" { for_each = local.eks_managed_node_groups triggers_replace = [ aws_eks_node_group.managed_node_group[each.key].resources[0].autoscaling_groups[0].name, filebase64sha256("scripts/update-asg.sh"), ] provisioner "local-exec" { command = <<-EOT scripts/update-asg.sh \ … EOT } } aws_eks_node_group.managed_node_group[each.key]...を指定することで ノードグループが作成されたタイミングでスクリプトの実行が可能 filebase64sha256("scripts/update-asg.sh")を指定することで スクリプトを更新した場合にもスクリプトの実行が可能

Terraform + hemfiles + Argo CD 23 PR・UI上でEKSの構築&各種ツールのインストールが完結 $ atlantis apply tfファイルを作成 module "eks130-test" { create = true cluster_name = "eks130-test" cluster_version = "1.30" … PRを作成し、PR上でatlantisを実行 helmfilesの設定ファイルを作成 masterにマージ&Argo CDでSync $ git commit $ git push origin master Terraform×Atlantisのフローに載せ、各種ツールの manifestをhelmfilesに移行したことでデプロ イがPRとArgo CDのUI上で完結出来るようになった datadog: enabled: true fluentd: replicas: 2 …

achlis -> Terraform + helmfilesにしたことで 24 1. 手元のPCから実行する必要がある 2. SREでしか触れない

achlis -> Terraform + helmfilesにしたことで 25 1. 手元のPCから実行する必要がある 2. SREでしか触れない PR & UI上で完結するようになった

achlis -> Terraform + helmfilesにしたことで 26 1. 手元のPCから実行する必要がある 2. SREでしか触れない PR & UI上で完結するようになった SRE以外も触れるようになった

しかし・・・ 27 EKSの構築と各種ツールのインストールが完了しても 動かないと意味がない！

28 Dev側の移行前に各種ツールの動作確認が必要 EKS(ver1.29) datadog- agent cert- manager cluster- autoscaler fluent external- dns Chatwork EKS(ver1.30) datadog- agent cert- manager cluster- autoscaler fluent external- dns Chatwork SRE Dev SRE Dev

さらに・・・ 29 EKSのバージョンアップ以上の頻度で 各種ツールの最新バージョンが出る

30 安全に楽に定期的に ツールのバージョンアップをしたい！

kibertasの作成 31 kibertas = KubernetesのE2Eテスト自動化ツール を作成 https://github.com/chatwork/kibertas

kibertas 32 2024/11末時点で、kibertasのテスト対象となっているものは以下の通り ingress cert-manager cluster-autoscaler datadog-agent fluent 「これがないとクラスタとして機能が停止するもの」を基準として選定。 必要があれば今後も追加していく予定。 気になること・追加したいことがあれば PRお待ちしております！

kibertas 33 ingress Ingressリソースを作成し、DNSレコードとHTTPエンドポイントを確認 1. Namespace、Service、Deploymentを作成 a. テスト用のNamespace、Service、Deploymentが正常に作成され、Podが正常に稼働 することを確認 2. Ingressの作成 a. Ingressリソースが正常に作成され、指定されたホスト名と Serviceが正しく関連づけられ ることを確認 3. DNSレコードの確認 a. 指定されたホスト名のDNSレコードが存在し、正しいIPアドレスを返すことを確認 4. HTTPエンドポイントの確認 a. Ingress経由でServiceにアクセスし、HTTPステータスコード200が返されることを確認 5. リソースの削除 $ kibertas test ingress

kibertas 34 cert-manager cert-managerを使用して証明書リソースを作成し、証明書が正しく発行されることを確認 1. Namespaceを作成 a. テスト用のNamespaceが正常に作成されることを確認 2. Root CAの作成 a. Certificateリソースを使用してRoot CA証明書が正常に作成され、その証明書と秘密鍵 がSecretに保存されることを確認 3. Issuerの作成 a. Root CAを使用して、証明書を発行するための Issuerリソースが正常に作成されることを 確認 4. 証明書の作成 a. Issuerを使用してテスト用の証明書が正常に作成され、その証明書と秘密鍵が Secretに 保存されることを確認 5. Secretの確認 a. 証明書と秘密鍵が保存されたシークレットが存在し、内容が正しいことを確認 6. リソースの削除 $ kibertas test cert-manager

kibertas 35 cluster-autoscaler Node数に応じてDeploymentのレプリカ数を調整し、Cluster Autoscaler or Karpernter が正しく動 作していることを確認 1. Namespaceを作成 a. テスト用のNamespaceが正常に作成されることを確認 2. Nodeリストの取得 a. 指定されたラベルを持つNodeのリストが正常に取得されることを確認 3. Deploymentの作成 a. ノード数+1のレプリカ数を持つDeploymentが正常に作成され、そのPodが正常にスケ ジュールされることを確認 4. リソースの削除 $ kibertas test cluster-autoscaler

kibertas 36 datadog-agent Datadog APIを使用してKubernetesクラスタのメトリクスをクエリし、Datadog Agentが正しく動作し ているかを確認 1. メトリクスクエリの実行 a. 指定されたメトリクスクエリがDatadog APIに対して正常に実行され、結果が返されること 2. メトリクスデータの確認 a. クエリ結果にメトリクスデータが含まれていることを確認 $ kibertas test datadog-agent

kibertas 37 fluent Fluentdを使用してKubernetesクラスタのログを収集し、Amazon S3バケットに保存する設定が正し く機能しているかを確認する 1. Namespace、Deploymentを作成 a. テスト用のNamespace、Deploymentが正常に作成され、Podが正常に稼働することを 確認 2. S3バケットの確認 a. Fluentdが収集したログが指定されたS3バケットに正しく保存されていることを確認 3. リソースの削除 $ kibertas test fluent

kibertasでのテスト 38 Applicationにkibertasを追加 apiVersion: batch/v1 kind: Job metadata: name: kibertas-test-datadog-agent annotations: argocd.argoproj.io/hook: PostSync argocd.argoproj.io/hook-delete-policy: HookSucceeded spec: template: spec: containers: - name: kibertas image: ghcr.io/chatwork/kibertas:v0.0.7 command: ["kibertas", "test", "datadog-agent"] (例) datadog-agentのapplicationにkibertasのdatadog-agentを実行するjobを追加 「Chatwork」ではPostSyncをトリガーに実行 kibertasのイメージを指定 テスト実行のコマンドは $kibertas test xxx

kibertasでのテスト 39 Argo CDでSyncして実行 PostSyncをトリガーにしているので Syncするとjobが起動する 正常に終了するとjobは削除される

kibertasでのテスト 40 テスト結果が「 Chatwork」に届く NG クラスター名 クラスター名 メトリクスの取得に失敗している OK クラスター名 クラスター名

41 kibertasを導入することで EKS構築時やツールのバージョンアップ時の 手動の動作確認が不要になり 気軽にバージョンアップが出来るようになった！

まとめ 42 EKS構築が安全に少ない工数で可能になった SREしか触れなかったServiceAccountを開発チームが安全に作成出来るようになり、 開発チームの生産性が上がった バージョンアップが気軽に実施出来るようになった EKSのE2Eテストを自動化することで、動作確認の工数が削減され、気軽にEKSや各種ツールの バージョンアップを実施出来るようになった 開発チームの操作可能範囲が広がった achlis -> Terraform + helmfilesに移行することで、手順がシンプルになり、 元々の他のリリース手順に沿うようになったので、 安全に少ない工数でEKSの構築が出来るようになった

今後 43 新しいバージョンの EKS構築用のPR作成の自動化 kibertasリポジトリの CI環境の整備 現状はCIではGithub Actions上で出来る範囲でしかテストを実施していない。 今後はAWS上に実際にリソースを作成して確認する必要のあるテストも実施出来るようにCIを整備して いく予定 現状は新しいEKSのバージョンが公開されたら、SREメンバーが手動でPRを作成している。 今後は新しいEKSのバージョンが公開されたら自動的にPRが作成されるような仕組みを作成したい

kubellではSREを探しています 皆様のご応募お待ちしています！ 働くをもっと楽しく、創造的に Join Our Team! ↑SREの求人情報はこちら↑

働くをもっと楽しく、創造的に 45