Kubernetesリソースの安定稼働に向けた TerratestによるHelmチャートのテスト自動化/Automating Helm Chart Testing with Terratest for Stable Operation of Kubernetes Resources

@CICDConference 2023
https://event.cloudnativedays.jp/cicd2023/talks/1767

Transcript

1. Kubernetesリソースの安定稼働に向けた TerratestによるHelmチャートのテスト自動化 CI/CD Conference 2023 by CloudNative Days Track A 17:20~18:00 Nobuhiko Kokubo
2. 自己紹介 小久保 信彦 所属 略歴 ソフトバンク株式会社 法人事業統括 クラウドエンジニアリング本部 2018/4~ Webアプリケーションエンジニア 2022/7~ ソフトバンクに中途入社 @kkb_0318
3. ソフトバンクで作っているサービス GIP DNS node External DNS Kubernetes Prod/Staging LB Inter net node node Managed Services Cert Manager RDB Secret Manager Prometheus クラウドネイティブアプリケーションプラットフォーム(CNAP) 特徴 • アプリケーション開発基盤 をローコードで作成 • GCP, AWS, Azureに対応 アプリ開発者
4. Table of Contents Kubernetesリソースの開発課題 アプローチ 単体テスト 結合テスト ソフトバンクでの運用 Kubernetesリソースに対する 単体テストの実践方法 テストツールとテスト対象 についての整理 Kubernetesリソースに対する 結合テストの実践方法 リソースの増大による 品質・開発効率の問題 ソフトバンクで実践している テストフローの解説 １. ２. ３. ４. ５. まとめ 本発表のまとめと 今後にむけて ６.
5. Table of Contents Kubernetesリソースの開発課題 アプローチ 単体テスト 結合テスト ソフトバンクでの運用 Kubernetesリソースに対する 単体テストの実践方法 テストツールとテスト対象 についての整理 Kubernetesリソースに対する 結合テストの実践方法 リソースの増大による 品質・開発効率の問題 ソフトバンクで実践している テストフローの解説 １. ２. ３. ４. ５. まとめ 本発表のまとめと 今後にむけて ６.
6. テストは大事 Vladimir Khorikov. 単体テストの考え方・使い方. マイナビ出版(2022). D. S. Bernstein, レガシーコードからの脱却. オライリージャパン(2019). 田中 ひさてる. ちょうぜつソフトウェア設計入門. 技術評論社(2022). …
7. アプリケーション E2Eテスト システム全体を対象に ユーザー視点からの動作を検証する アプリケーションにおける各種テストの役割 機能 結合テスト システムがプロセス外依存と 統合した状態で正常に動作するかを検証する メソッド コンポーネント 役割の異なるテストをバランスよくつくり動作を保証する 単体テスト システム内の１単位のふるまいについて 正しく動作するかを検証する
8. アプリケーション開発においてテストを作ることのメリット Vladimir Khorikov. 単体テストの考え方・使い方. マイナビ出版(2022). 費やす時間 プロダクトの成長 テストあり テストなし 中長期的な開発効率の向上 テストの有無によるプロダクトの成長の違い テストはプロダクトの品質や開発効率に良い影響を与える • リファクタリングによるデグレード リスクの低下 • プロダクト品質の維持 • バグ早期検出による手戻りの減少 テストによるその他のメリット
9. Kubernetesのアーキテクチャ概要 Kubernetes 複数のリソースが複雑に依存しながら動作する 依存
10. Helmを用いたKubernetesのアーキテクチャ概要 Kubernetes 複数のKubernetesリソースをパッケージ管理 デプロイ・アップグレード・バージョン管理が容易になる Helm Chart • Helm Template Kubernetesマニフェスト 作成のための雛形 • スキーマ情報 マニフェスト作成に必要 な入力値の情報 deploy
11. 複雑度が上がることにより生じる問題 エラーの特定に時間がかかる 修正のたびにkuberenetesで動作検証が 必要で開発効率が下がる デグレードしやすくなる アプリケーションのような単体・結合テストによるアプローチが重要 Kubernetes 複雑度が上がることによる問題
12. Terratest Chart Tests kube-monkey Kubetest K6 Kubernetes テストツール カスタマイズ性高く単体テスト・結合テストができそうなのはTerratest ツール名 テストの種類 できること 備考 e2eテスト 非機能テスト 非機能テスト バリデーション 結合テスト 単体テスト 結合テスト e2eテスト など 機能テスト 負荷テスト 性能テスト カオスエンジニアリング Helm動作検証 スキーマチェック Goでの記述次第 テストのカスタマイズに必 要な設定が多い テストシナリオの設計やコ ード記述の知識が必要 テスト結果の予測が困難 カスタマイズ困難 全てGoで記述する 必要がある Helm cli 標準
13. 本セッションで伝えたいこと Helmを用いたKubernetesリソースに対する 単体テスト・結合テストの考え方、実践
14. Table of Contents Kubernetesリソースの開発課題 アプローチ 単体テスト 結合テスト ソフトバンクでの運用 Kubernetesリソースに対する 単体テストの実践方法 テストツールとテスト対象 についての整理 Kubernetesリソースに対する 結合テストの実践方法 リソースの増大による 品質・開発効率の問題 ソフトバンクで実践している テストフローの解説 １. ２. ３. ４. ５. まとめ 本発表のまとめと 今後にむけて ６.
15. 今回想定するテスト対象 Kubernetes Helmを用いたKubernetes環境
16. Helm Chartをデプロイするまでのプロセス values.yaml Helm Templateにvalues.yamlを入力して、Kubernetesマニフェストを出力する Helm Template パラメータの準備 マニフェスト生成 デプロイ YAML YAML YAML YAML YAML
17. アプローチの検討｜テストの種類と役割の整理 単体テスト 結合テスト E2Eテスト システム内の１単位の ふるまいについて 正しく動作するかを検証する システムがプロセス外依存と 統合した状態で 正常に動作するかを検証する システム全体を対象に ユーザー視点からの動作 を検証する 複数のHelm Chartを 含めたKubernetes全体 の構築テスト 単一のHelm Chart をデプロイして 動作テスト Kubernetesマニフェスト の生成テスト YAML YAML 本発表の対象外
18. 単体テスト・結合テストに使用するツール go言語用のテストライブラリ Terraform, Kubernetes, Docker などに対応 あくまでライブラリであるため、テストコードやテストケースなどは 自分で実装しなければならない
19. Table of Contents Kubernetesリソースの開発課題 アプローチ 単体テスト 結合テスト ソフトバンクでの運用 Kubernetesリソースに対する 単体テストの実践方法 テストツールとテスト対象 についての整理 Kubernetesリソースに対する 結合テストの実践方法 リソースの増大による 品質・開発効率の問題 ソフトバンクで実践している テストフローの解説 １. ２. ３. ４. ５. まとめ 本発表のまとめと 今後にむけて ６.
20. 単体テストのテスト対象の整理 単体テスト システム内の１単位の ふるまいについて 正しく動作するかを検証する Kubernetesマニフェスト の生成テスト YAML YAML values.yaml Helm Template Kubernetes Manifest 様々なパターンの入力に対しマニフェストを想定通りに生成できるかを検証 条件分岐 繰り返し処理
21. 単体テストのテスト対象の整理 values.yaml Helm Template Kubernetes Manifest 副作用のない純粋関数のようにテスト可能 Prameters Functions Output
22. Terratestの導入 https://pkg.go.dev/github.com/gruntwork-io/terratest/modules/helm#RenderTemplateE valuesやtemplateFileを入力してKubernetes Manifestを取得できる
23. 失敗談｜確認したい観点のみテストを記述 各テストケースの目的に沿ったAssertionを実施 １つのテストに対するコード量が増大 共通化できないためマニフェスト毎にテストを書かなければならない 保守性低下・テストの記述や修正への心理的抵抗大
24. Assertionの修正 yaml同士を比較するという単純なテストに変更 YAML expect.yaml YAML actual • テストコードの保守性向上 • 再利用性向上 • 漏れのない仕様変更検知 よかったこと 今のところ問題なし。 マニフェストは設定ファイルなので一行の変更でも 大きな設定変更になりうる。 そのため少しの変更でも検知したい場合が多い。 Q. 偽陽性のテストが増えてメンテが大変にならないか
25. Terratestによる単体テストの実装例 Terratestを用いることでアプリケーションの単体テストのように Helm のテストを記述できる 準備フェーズ 実行フェーズ 確認フェーズ
26. テストコードの共通化 test modules 各パッケージから簡単にテストできるようにすることで テストコードの作成・保守コストを下げる 任意のマニフェストに対する共通テスト 複数のHelm Chartからの呼び出し 各リポジトリで記述しているテストコード Repository1 Repository2 Repository3 指定するのは 主に以下の３つだけ valuesファイル template ファイル expectファイル
27. 単体テストによる効果 Helmはテンプレート関数なため、設計 の自由度が低く依存関係が複雑になり 変更による影響を追うのが大変 少しリファクタリングするだけでも 他に影響がないことを確認するために 動作検証をする必要があり安易に改善 できない 単体テスト作成前 予期しない変更やデグレードを検出 できるようになった リファクタリングに対する 心理的障壁が下がり、改善サイクル を回しやすくなった 単体テスト作成後
28. Table of Contents Kubernetesリソースの開発課題 アプローチ 単体テスト 結合テスト ソフトバンクでの運用 Kubernetesリソースに対する 単体テストの実践方法 テストツールとテスト対象 についての整理 Kubernetesリソースに対する 結合テストの実践方法 リソースの増大による 品質・開発効率の問題 ソフトバンクで実践している テストフローの解説 １. ２. ３. ４. ５. まとめ 本発表のまとめと 今後にむけて ６.
29. 結合テストの実施 結合テスト システムがプロセス外依存と 統合した状態で正常に動作するか を検証する 単一のHelm Chart をデプロイして 動作テスト Helmにより生成されたkubernetesマニフェストをデプロイし 正しく動作していることを検証 パラメータの準備 マニフェスト生成 デプロイ YAML YAML 単体テスト 結合テスト
30. 結合テストの実施環境 Kubernetsクラスターが立ち上がって いること 前提条件 Helmのテストに必要なリソースが 存在していること Kubernetes Manifest YAML test deploy
31. テスト用のリソースのデプロイ方法 • 開発中のリソース(開発ブランチ)を使ってテストしたい • テスト用に必要なリソースも作りたい • 環境毎に分けたい FluxのCustom Resource FluxによるGitOpsの場合 GitOps テスト実施時に追加でやりたいこと
32. Kustomizeの概要 Kustomize: Kubernetes マニフェストのテンプレートツール Kustomize 構成
33. Kustomizeの概要 Kustomize: Kubernetes マニフェストのテンプレートツール kustomizeを利用することで 環境に応じてマニフェストファイルを作成することができる Kustomize 構成 出力されたマニフェスト overlay base
34. Kustomizeを用いたテストフォルダ構成(例) テストケースに応じた任意のリソースを管理できるようになる フォルダ構成 kustomization.yaml デプロイコマンド > kubectl apply -k path/to/directory
35. Assertion｜テスト対象となるリソースの整理 1. Helmを管理するCustom Resource 2. その他のリソース HelmReleaseが正常にインストール されていることの検証 Jobで生成されたリソース等、 追加で確認が必要なリソースの検証 HelmRelease Controller k8s API tf-controller Custom Resources ARM FluxのCustom Resource HelmChart
36. Custom Resourceの取得 Terratestのk8s パッケージを使用 yamlをHelmRelease structに変換 HelmReleaseをyaml形 式で取得 Terratestのk8sパッケージを用いてCustom Resource(HelmRelease)を取得する 1. Helmを管理するCustom Resource 2. その他のリソース
37. 非同期処理による問題 CustomResourceのデプロイは非同期処理になるため リソースが正しく作成されるまで待つ処理が必要 1. Helmを管理するCustom Resource 2. その他のリソース • HelmRelease CRの作成 • GitRepositoryからソース取得 • HelmChart CRの追加 • リソースのデプロイ HelmRelease Helm Controller k8s API HelmChart Source Controller Fluxの処理フロー概要 CustomResourceデプロイ時の処理 https://fluxcd.io/flux/components/helm/
38. 非同期処理に対応したテストの作成 Terratestのretry パッケージを使用 CustomResourceのStatusが Trueになるかを確認 callback関数で CustomResourceの 取得、 Statusチェック 特定の関数を繰り返し実行し、期待される結果が得られるまでリトライする 1. Helmを管理するCustom Resource 2. その他のリソース
39. Custom Resourceのテストコード 準備フェーズ 実行フェーズ 確認フェーズ 単体テストと同様に、準備・実行・確認フェーズに分けて シンプルにテストコードを記述できる 1. Helmを管理するCustom Resource 2. その他のリソース
40. Assertion｜Helm Release以外のリソースのテスト 1. Helmを管理するCustom Resource 2. その他のリソース HelmReleaseが正常にインストール されていることの検証 Jobで生成されたリソース等、 追加で確認が必要なリソースの検証 HelmRelease Controller k8s API tf-controller Custom Resources ARM FluxのCustom Resource HelmChart
41. Helm Release以外のリソースのテスト基準 リソースの種類によって成功基準を設定 1. Helmを管理するCustom Resource 2. その他のリソース ・・・
42. 任意のテスト関数 テストコード 準備フェーズ 実行フェーズ 確認フェーズ Custom Resourceのテストに加えて、任意のテスト関数を入力できる ようにすることで、各Helm Chartのテストコードを共通化できる 1. Helmを管理するCustom Resource 2. その他のリソース
43. Table of Contents Kubernetesリソースの開発課題 アプローチ 単体テスト 結合テスト ソフトバンクでの運用 Kubernetesリソースに対する 単体テストの実践方法 テストツールとテスト対象 についての整理 Kubernetesリソースに対する 結合テストの実践方法 リソースの増大による 品質・開発効率の問題 ソフトバンクで実践している テストフローの解説 １. ２. ３. ４. ５. まとめ 本発表のまとめと 今後にむけて ６.
44. ソフトバンクで作っているサービス GIP DNS node External DNS Kubernetes Prod/Staging LB Inte rnet node node Cert Manager RDB Secret Manager Prometheus クラウドネイティブアプリケーションプラットフォーム(CNAP) 特徴 • アプリケーション開発基盤 をローコードで作成 • GCP, AWS, Azureに対応 アプリ開発者 3つのクラウドベンダーに対応するためのテストが必要
45. ３ベンダーへのテスト 単体テスト values-aws.yaml values-az.yaml values-gcp.yaml YAML YAML YAML YAML YAML 結合テスト Apply テストコードを共通化し、異なるベンダーに対しても 同様のテストパターンの一つとして管理 Kubernetes Manifest
46. テスト戦略 リモートブランチ ローカル main stage feature 単体テスト 単体テスト 結合テスト 結合テスト e2eテスト 一般的なアプリケーション開発のようなテスト戦略を採用 featureブランチでの開発
47. 開発プロセス 実装・動作検証 テスト作成 コード修正 想定外の変更や マニフェストの破損を 検知しつつ安全に コードを修正する 動作検証しながらマニ フェストを作成する 検証済みのマニフェスト を正としてテストケース をつくる
48. テスト適用による効果 結合テスト 作成 e2eテスト 作成 単体テスト 作成 バグをテスト段階で検出できるようになった →バグ対応にかかる時間が減り、システム全体が安定稼働するようになった 50% • 全体のバグの割合が下がったとはいえない • テスト導入後に多くのバグを検出し、その後バグ割合が下がっている 0% ある期間でのスプリント毎のバグの割合 スプリント タスクに対する バグの割合 【考察】
49. Table of Contents Kubernetesリソースの開発課題 アプローチ 単体テスト 結合テスト ソフトバンクでの運用 Kubernetesリソースに対する 単体テストの実践方法 テストツールとテスト対象 についての整理 Kubernetesリソースに対する 結合テストの実践方法 リソースの増大による 品質・開発効率の問題 ソフトバンクで実践している テストフローの解説 １. ２. ３. ４. ５. まとめ 本発表のまとめと 今後にむけて ６.
50. まとめ • Kubernetesインフラもリソースが肥大化すればテストが必要になる • Terratestを用いることでアプリケーション開発のような 単体テスト・結合テストを実装できる • 適切なテストを作ることで 品質・生産性どちらも向上することが期待できる • 保守しやすいテストコードを記述することでより効果が発揮される
51. 今後に向けて 機能拡張＋テストによる堅実な成長 アプリケーション開発者が各クラウドのサービスを最大限活用するために CNAPへ追加すべき機能がまだまだたくさんある 現在提供中のパッケージ