Tweet
Tweet

Slide 1

Slide 1 text

Kubernetesリソースの安定稼働に向けた TerratestによるHelmチャートのテスト自動化 CI/CD Conference 2023 by CloudNative Days Track A 17:20~18:00 Nobuhiko Kokubo

Slide 2

Slide 2 text

自己紹介 小久保 信彦 所属 略歴 ソフトバンク株式会社 法人事業統括 クラウドエンジニアリング本部 2018/4~ Webアプリケーションエンジニア 2022/7~ ソフトバンクに中途入社 @kkb_0318

Slide 3

Slide 3 text

ソフトバンクで作っているサービス 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に対応 アプリ開発者

Slide 4

Slide 4 text

Table of Contents Kubernetesリソースの開発課題 アプローチ 単体テスト 結合テスト ソフトバンクでの運用 Kubernetesリソースに対する 単体テストの実践方法 テストツールとテスト対象 についての整理 Kubernetesリソースに対する 結合テストの実践方法 リソースの増大による 品質・開発効率の問題 ソフトバンクで実践している テストフローの解説 １. ２. ３. ４. ５. まとめ 本発表のまとめと 今後にむけて ６.

Slide 5

Slide 5 text

Table of Contents Kubernetesリソースの開発課題 アプローチ 単体テスト 結合テスト ソフトバンクでの運用 Kubernetesリソースに対する 単体テストの実践方法 テストツールとテスト対象 についての整理 Kubernetesリソースに対する 結合テストの実践方法 リソースの増大による 品質・開発効率の問題 ソフトバンクで実践している テストフローの解説 １. ２. ３. ４. ５. まとめ 本発表のまとめと 今後にむけて ６.

Slide 6

Slide 6 text

テストは大事 Vladimir Khorikov. 単体テストの考え方・使い方. マイナビ出版(2022). D. S. Bernstein, レガシーコードからの脱却. オライリージャパン(2019). 田中 ひさてる. ちょうぜつソフトウェア設計入門. 技術評論社(2022). …

Slide 7

Slide 7 text

アプリケーション E2Eテスト システム全体を対象に ユーザー視点からの動作を検証する アプリケーションにおける各種テストの役割 機能 結合テスト システムがプロセス外依存と 統合した状態で正常に動作するかを検証する メソッド コンポーネント 役割の異なるテストをバランスよくつくり動作を保証する 単体テスト システム内の１単位のふるまいについて 正しく動作するかを検証する

Slide 8

Slide 8 text

アプリケーション開発においてテストを作ることのメリット Vladimir Khorikov. 単体テストの考え方・使い方. マイナビ出版(2022). 費やす時間 プロダクトの成長 テストあり テストなし 中長期的な開発効率の向上 テストの有無によるプロダクトの成長の違い テストはプロダクトの品質や開発効率に良い影響を与える ● リファクタリングによるデグレード リスクの低下 ● プロダクト品質の維持 ● バグ早期検出による手戻りの減少 テストによるその他のメリット

Slide 9

Slide 9 text

Kubernetesのアーキテクチャ概要 Kubernetes 複数のリソースが複雑に依存しながら動作する 依存

Slide 10

Slide 10 text

Helmを用いたKubernetesのアーキテクチャ概要 Kubernetes 複数のKubernetesリソースをパッケージ管理 デプロイ・アップグレード・バージョン管理が容易になる Helm Chart ● Helm Template Kubernetesマニフェスト 作成のための雛形 ● スキーマ情報 マニフェスト作成に必要 な入力値の情報 deploy

Slide 11

Slide 11 text

複雑度が上がることにより生じる問題 エラーの特定に時間がかかる 修正のたびにkuberenetesで動作検証が 必要で開発効率が下がる デグレードしやすくなる アプリケーションのような単体・結合テストによるアプローチが重要 Kubernetes 複雑度が上がることによる問題

Slide 12

Slide 12 text

Terratest Chart Tests kube-monkey Kubetest K6 Kubernetes テストツール カスタマイズ性高く単体テスト・結合テストができそうなのはTerratest ツール名 テストの種類 できること 備考 e2eテスト 非機能テスト 非機能テスト バリデーション 結合テスト 単体テスト 結合テスト e2eテスト など 機能テスト 負荷テスト 性能テスト カオスエンジニアリング Helm動作検証 スキーマチェック Goでの記述次第 テストのカスタマイズに必 要な設定が多い テストシナリオの設計やコ ード記述の知識が必要 テスト結果の予測が困難 カスタマイズ困難 全てGoで記述する 必要がある Helm cli 標準

Slide 13

Slide 13 text

本セッションで伝えたいこと Helmを用いたKubernetesリソースに対する 単体テスト・結合テストの考え方、実践

Slide 14

Slide 14 text

Table of Contents Kubernetesリソースの開発課題 アプローチ 単体テスト 結合テスト ソフトバンクでの運用 Kubernetesリソースに対する 単体テストの実践方法 テストツールとテスト対象 についての整理 Kubernetesリソースに対する 結合テストの実践方法 リソースの増大による 品質・開発効率の問題 ソフトバンクで実践している テストフローの解説 １. ２. ３. ４. ５. まとめ 本発表のまとめと 今後にむけて ６.

Slide 15

Slide 15 text

今回想定するテスト対象 Kubernetes Helmを用いたKubernetes環境

Slide 16

Slide 16 text

Helm Chartをデプロイするまでのプロセス values.yaml Helm Templateにvalues.yamlを入力して、Kubernetesマニフェストを出力する Helm Template パラメータの準備 マニフェスト生成 デプロイ YAML YAML YAML YAML YAML

Slide 17

Slide 17 text

アプローチの検討｜テストの種類と役割の整理 単体テスト 結合テスト E2Eテスト システム内の１単位の ふるまいについて 正しく動作するかを検証する システムがプロセス外依存と 統合した状態で 正常に動作するかを検証する システム全体を対象に ユーザー視点からの動作 を検証する 複数のHelm Chartを 含めたKubernetes全体 の構築テスト 単一のHelm Chart をデプロイして 動作テスト Kubernetesマニフェスト の生成テスト YAML YAML 本発表の対象外

Slide 18

Slide 18 text

単体テスト・結合テストに使用するツール go言語用のテストライブラリ Terraform, Kubernetes, Docker などに対応 あくまでライブラリであるため、テストコードやテストケースなどは 自分で実装しなければならない

Slide 19

Slide 19 text

Table of Contents Kubernetesリソースの開発課題 アプローチ 単体テスト 結合テスト ソフトバンクでの運用 Kubernetesリソースに対する 単体テストの実践方法 テストツールとテスト対象 についての整理 Kubernetesリソースに対する 結合テストの実践方法 リソースの増大による 品質・開発効率の問題 ソフトバンクで実践している テストフローの解説 １. ２. ３. ４. ５. まとめ 本発表のまとめと 今後にむけて ６.

Slide 20

Slide 20 text

単体テストのテスト対象の整理 単体テスト システム内の１単位の ふるまいについて 正しく動作するかを検証する Kubernetesマニフェスト の生成テスト YAML YAML values.yaml Helm Template Kubernetes Manifest 様々なパターンの入力に対しマニフェストを想定通りに生成できるかを検証 条件分岐 繰り返し処理

Slide 21

Slide 21 text

単体テストのテスト対象の整理 values.yaml Helm Template Kubernetes Manifest 副作用のない純粋関数のようにテスト可能 Prameters Functions Output

Slide 22

Slide 22 text

Terratestの導入 https://pkg.go.dev/github.com/gruntwork-io/terratest/modules/helm#RenderTemplateE valuesやtemplateFileを入力してKubernetes Manifestを取得できる

Slide 23

Slide 23 text

失敗談｜確認したい観点のみテストを記述 各テストケースの目的に沿ったAssertionを実施 １つのテストに対するコード量が増大 共通化できないためマニフェスト毎にテストを書かなければならない 保守性低下・テストの記述や修正への心理的抵抗大

Slide 24

Slide 24 text

Assertionの修正 yaml同士を比較するという単純なテストに変更 YAML expect.yaml YAML actual ● テストコードの保守性向上 ● 再利用性向上 ● 漏れのない仕様変更検知 よかったこと 今のところ問題なし。 マニフェストは設定ファイルなので一行の変更でも 大きな設定変更になりうる。 そのため少しの変更でも検知したい場合が多い。 Q. 偽陽性のテストが増えてメンテが大変にならないか

Slide 25

Slide 25 text

Terratestによる単体テストの実装例 Terratestを用いることでアプリケーションの単体テストのように Helm のテストを記述できる 準備フェーズ 実行フェーズ 確認フェーズ

Slide 26

Slide 26 text

テストコードの共通化 test modules 各パッケージから簡単にテストできるようにすることで テストコードの作成・保守コストを下げる 任意のマニフェストに対する共通テスト 複数のHelm Chartからの呼び出し 各リポジトリで記述しているテストコード Repository1 Repository2 Repository3 指定するのは 主に以下の３つだけ valuesファイル template ファイル expectファイル

Slide 27

Slide 27 text

単体テストによる効果 Helmはテンプレート関数なため、設計 の自由度が低く依存関係が複雑になり 変更による影響を追うのが大変 少しリファクタリングするだけでも 他に影響がないことを確認するために 動作検証をする必要があり安易に改善 できない 単体テスト作成前 予期しない変更やデグレードを検出 できるようになった リファクタリングに対する 心理的障壁が下がり、改善サイクル を回しやすくなった 単体テスト作成後

Slide 28

Slide 28 text

Table of Contents Kubernetesリソースの開発課題 アプローチ 単体テスト 結合テスト ソフトバンクでの運用 Kubernetesリソースに対する 単体テストの実践方法 テストツールとテスト対象 についての整理 Kubernetesリソースに対する 結合テストの実践方法 リソースの増大による 品質・開発効率の問題 ソフトバンクで実践している テストフローの解説 １. ２. ３. ４. ５. まとめ 本発表のまとめと 今後にむけて ６.

Slide 29

Slide 29 text

結合テストの実施 結合テスト システムがプロセス外依存と 統合した状態で正常に動作するか を検証する 単一のHelm Chart をデプロイして 動作テスト Helmにより生成されたkubernetesマニフェストをデプロイし 正しく動作していることを検証 パラメータの準備 マニフェスト生成 デプロイ YAML YAML 単体テスト 結合テスト

Slide 30

Slide 30 text

結合テストの実施環境 Kubernetsクラスターが立ち上がって いること 前提条件 Helmのテストに必要なリソースが 存在していること Kubernetes Manifest YAML test deploy

Slide 31

Slide 31 text

テスト用のリソースのデプロイ方法 ● 開発中のリソース(開発ブランチ)を使ってテストしたい ● テスト用に必要なリソースも作りたい ● 環境毎に分けたい FluxのCustom Resource FluxによるGitOpsの場合 GitOps テスト実施時に追加でやりたいこと

Slide 32

Slide 32 text

Kustomizeの概要 Kustomize: Kubernetes マニフェストのテンプレートツール Kustomize 構成

Slide 33

Slide 33 text

Kustomizeの概要 Kustomize: Kubernetes マニフェストのテンプレートツール kustomizeを利用することで 環境に応じてマニフェストファイルを作成することができる Kustomize 構成 出力されたマニフェスト overlay base

Slide 34

Slide 34 text

Kustomizeを用いたテストフォルダ構成(例) テストケースに応じた任意のリソースを管理できるようになる フォルダ構成 kustomization.yaml デプロイコマンド > kubectl apply -k path/to/directory

Slide 35

Slide 35 text

Assertion｜テスト対象となるリソースの整理 1. Helmを管理するCustom Resource 2. その他のリソース HelmReleaseが正常にインストール されていることの検証 Jobで生成されたリソース等、 追加で確認が必要なリソースの検証 HelmRelease Controller k8s API tf-controller Custom Resources ARM FluxのCustom Resource HelmChart

Slide 36

Slide 36 text

Custom Resourceの取得 Terratestのk8s パッケージを使用 yamlをHelmRelease structに変換 HelmReleaseをyaml形 式で取得 Terratestのk8sパッケージを用いてCustom Resource(HelmRelease)を取得する 1. Helmを管理するCustom Resource 2. その他のリソース

Slide 37

Slide 37 text

非同期処理による問題 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/

Slide 38

Slide 38 text

非同期処理に対応したテストの作成 Terratestのretry パッケージを使用 CustomResourceのStatusが Trueになるかを確認 callback関数で CustomResourceの 取得、 Statusチェック 特定の関数を繰り返し実行し、期待される結果が得られるまでリトライする 1. Helmを管理するCustom Resource 2. その他のリソース

Slide 39

Slide 39 text

Custom Resourceのテストコード 準備フェーズ 実行フェーズ 確認フェーズ 単体テストと同様に、準備・実行・確認フェーズに分けて シンプルにテストコードを記述できる 1. Helmを管理するCustom Resource 2. その他のリソース

Slide 40

Slide 40 text

Assertion｜Helm Release以外のリソースのテスト 1. Helmを管理するCustom Resource 2. その他のリソース HelmReleaseが正常にインストール されていることの検証 Jobで生成されたリソース等、 追加で確認が必要なリソースの検証 HelmRelease Controller k8s API tf-controller Custom Resources ARM FluxのCustom Resource HelmChart

Slide 41

Slide 41 text

Helm Release以外のリソースのテスト基準 リソースの種類によって成功基準を設定 1. Helmを管理するCustom Resource 2. その他のリソース ・・・

Slide 42

Slide 42 text

任意のテスト関数 テストコード 準備フェーズ 実行フェーズ 確認フェーズ Custom Resourceのテストに加えて、任意のテスト関数を入力できる ようにすることで、各Helm Chartのテストコードを共通化できる 1. Helmを管理するCustom Resource 2. その他のリソース

Slide 43

Slide 43 text

Table of Contents Kubernetesリソースの開発課題 アプローチ 単体テスト 結合テスト ソフトバンクでの運用 Kubernetesリソースに対する 単体テストの実践方法 テストツールとテスト対象 についての整理 Kubernetesリソースに対する 結合テストの実践方法 リソースの増大による 品質・開発効率の問題 ソフトバンクで実践している テストフローの解説 １. ２. ３. ４. ５. まとめ 本発表のまとめと 今後にむけて ６.

Slide 44

Slide 44 text

ソフトバンクで作っているサービス GIP DNS node External DNS Kubernetes Prod/Staging LB Inte rnet node node Cert Manager RDB Secret Manager Prometheus クラウドネイティブアプリケーションプラットフォーム(CNAP) 特徴 ● アプリケーション開発基盤 をローコードで作成 ● GCP, AWS, Azureに対応 アプリ開発者 3つのクラウドベンダーに対応するためのテストが必要

Slide 45

Slide 45 text

３ベンダーへのテスト 単体テスト values-aws.yaml values-az.yaml values-gcp.yaml YAML YAML YAML YAML YAML 結合テスト Apply テストコードを共通化し、異なるベンダーに対しても 同様のテストパターンの一つとして管理 Kubernetes Manifest

Slide 46

Slide 46 text

テスト戦略 リモートブランチ ローカル main stage feature 単体テスト 単体テスト 結合テスト 結合テスト e2eテスト 一般的なアプリケーション開発のようなテスト戦略を採用 featureブランチでの開発

Slide 47

Slide 47 text

開発プロセス 実装・動作検証 テスト作成 コード修正 想定外の変更や マニフェストの破損を 検知しつつ安全に コードを修正する 動作検証しながらマニ フェストを作成する 検証済みのマニフェスト を正としてテストケース をつくる

Slide 48

Slide 48 text

テスト適用による効果 結合テスト 作成 e2eテスト 作成 単体テスト 作成 バグをテスト段階で検出できるようになった →バグ対応にかかる時間が減り、システム全体が安定稼働するようになった 50% ● 全体のバグの割合が下がったとはいえない ● テスト導入後に多くのバグを検出し、その後バグ割合が下がっている 0% ある期間でのスプリント毎のバグの割合 スプリント タスクに対する バグの割合 【考察】

Slide 49

Slide 49 text

Table of Contents Kubernetesリソースの開発課題 アプローチ 単体テスト 結合テスト ソフトバンクでの運用 Kubernetesリソースに対する 単体テストの実践方法 テストツールとテスト対象 についての整理 Kubernetesリソースに対する 結合テストの実践方法 リソースの増大による 品質・開発効率の問題 ソフトバンクで実践している テストフローの解説 １. ２. ３. ４. ５. まとめ 本発表のまとめと 今後にむけて ６.

Slide 50

Slide 50 text

まとめ ● Kubernetesインフラもリソースが肥大化すればテストが必要になる ● Terratestを用いることでアプリケーション開発のような 単体テスト・結合テストを実装できる ● 適切なテストを作ることで 品質・生産性どちらも向上することが期待できる ● 保守しやすいテストコードを記述することでより効果が発揮される

Slide 51

Slide 51 text

今後に向けて 機能拡張＋テストによる堅実な成長 アプリケーション開発者が各クラウドのサービスを最大限活用するために CNAPへ追加すべき機能がまだまだたくさんある 現在提供中のパッケージ