CI/CD Conference 2023から、Kubernetesの構成をテストする事例を解説したセッションを紹介

CI/CD Conference 2023から、パブリッククラウド上に展開するKubernetesの構成をテストする事例を解説したセッションを紹介する。担当したのはソフトバンク株式会社のエンジニアである小久保信彦氏で、AWS、GCP、Azureのパブリッククラウド上にアプリケーションをホストするプラットフォームのCloud Native Application Platform（CNAP）を開発するチームに所属しているエンジニアだ。

●動画：Kubernetesリソースの安定稼働に向けた　TerratestによるHelmチャートのテスト自動化

小久保氏はCNAPの紹介に次いで、アプリケーションにおけるテストの概要を説明。ここでは単体テスト、結合テスト、E2E（End-to-End）テストを解説した。

自身が関わっているKubernetesをベースにしたプラットフォームの説明

テストについてはアプリケーション単体の動作を確認する単体テスト、外部と接続した状態で行う結合テスト、システム全体をエンドユーザー視点で検証するE2Eテストを、プラットフォームであるKubernetesに適応することが必要と解説した。

アプリケーションテストの3つの種類を解説

ここでKubernetesの概要を簡単に紹介し、構成を管理するためのツールであるHelmについて説明を行った。HelmではミドルウェアやデータベースなどをKubernetes上で実行するためのノウハウがChartという形で提供されており、テンプレートに必要なデータを与えて最終的なKubernetesのためのマニフェストを作るのがHelmの役割であると説明している。

Kubernetesの構成が複雑になれば問題解決にも時間がかかる

ここでは3つのパブリッククラウド上にCNAPが実装されていることから、それぞれの動作検証やエラー修正などについて時間がかかることを防ぐために、Kubernetesの構成に対してテストを行うことが必要となったと背景を説明した。

複雑なKubernetes構成をテストする必要性を解説

Kubernetesのテストツールについてもリサーチを行っており、KubetestやK6、kube-monkeyなどが対象として挙げられている。ソフトバンクとしてはカスタマイズが可能で単体テスト、結合テストが行えるTerratestを採用したと説明した。ちなみにTerratestはGoのライブラリであり、Goによるプログラミングが必須ではあるものの、カスタマイズ性の高さが評価されて採用に至ったという。

テストツールを比較した結果、Terratestを選定

ここでHelmがChartを使ってKubernetesがデプロイされる流れを解説。テンプレートとパラメータを使ってHelmがそのデータを合成し、出力としてYAMLファイルを生成するというのはアプリケーションにおけるパラメータと関数、出力という関係に近く、アプリケーションと同様のテストが可能になると考えたことを解説した。

テンプレートとパラメータからマニフェストを作り出すのがHelmの仕事

そしてKubernetesにおける単体テストとはHelmが生成するマニフェストの正しさの検証であり、結合テストとはHelm Chartを実際にデプロイして動作テストを行うことに相当すると説明。E2Eテストは今回のセッションの範疇ではないことから、外されている。

Kubernetesにおける単体テスト、結合テストとは何か

実際にこの発想でテストをKubernetesに適用したところ、1つのテストに対する大量のコードが必要となり、共通化もできないためマニフェストごとにテストを書かなければいけないという問題が発生したという。

テスト作成の失敗談を紹介

そのため生成されたYAMLファイルを実際に利用されているYAMLファイルと比較するという単純な手法に変更したことで、テストの再利用性が上がり保守の工数も削減されたことを紹介した。またテストコードの共通化も進み、それぞれのクラウドプラットフォームに適用されているという。

単体テストを導入した効果を説明

効果としてリファクタリングの心理的障壁が下がり、改善のサイクルが回るようになったとまとめた。

次に結合テストについても解説を行った。ここで言う「Kubernetesの結合テスト」とはHelmによって生成されたマニフェストが実際に想定した構成を実現できているのか？ について検証することだ。

Kubernetes実装の結合テストを実施

小久保氏のチームではFluxを用いた環境構築をGitOpsとして行っており、Kubernetesの環境がマニフェスト通りにデプロイできているのかを確認するためには、環境ごとにテストを分離すること、開発中のGitブランチからテストを実行するなどの要件があったという。そのため、KubernetesマニフェストのテンプレートをオーバーレイでパッチするツールのKustomizeを使っていることを紹介した。

Kustomizeの紹介

その上でKubernetesのカスタムリソースがデプロイされるかをテストするためには起動時間が必要な場合には、その待ち時間を考慮してテストコードを記述する必要があることを説明。ここではアプリケーションのテストとは違う特性があることを説明した。

カスタムリソースを確認するためには待ち時間を作る必要があることを説明

このためTerratestのretryというパッケージを使って特定のファンクションを繰り返し実行するテストコードを実装したことを説明した。

Terratestのretryを使って繰り返しを行うテストを実装

またその他のリソースについては、例を挙げながらテストの基準を説明。ジョブのステータスの確認や、HTTPのリクエストに反応することなどが挙げられており、インフラストラクチャーのテストならではの苦労が滲みだしていることがわかる。

Helm以外のリソースに対するテストの概要。さまざまなパターンがあることがわかる

またAWS、GCP、Azureのそれぞれに対するテストも、テストコードを共通化して実行していることを説明。アプリケーションテストのようなテスト戦略を採用し、実行していると語った。

テストの効果を説明

システム開発全体に渡ってバグが減ったということではないと説明したが、バグをテストの段階で検出できるようになったことが対応時間の削減につながり、システム全体が安定稼働するようになったという。

最後にまとめとして、インフラストラクチャーが複雑化することでテストの必要性が高まったこと、Terratestを使って単体テスト、結合テストを実装したこと、品質、生産性ともに向上したことなどを述べてセッションを終えた。Kubernetesを使ってアプリケーションを稼働している運用担当者にとって構成のテストにTerratestを検討するきっかけになるようなセッションとなったことは評価できる。

また今回のセッションでは言及されていないが、複数のクラウドサービスを抽象化してマルチクラウドを運用する際に問題になりがちなクレデンシャルの管理についても、ぜひ聞いてみたいと思わせる内容だった。