現代のKubernetesテストの5つの課題

コンテナ化からマイクロサービスまで、リモートワーク、アジャイルチーム、クラウドネイティブの採用により、より迅速な開発およびリリースサイクルを管理できるようになりました。

しかし、開発サイクルの重要な部分であるテストが欠けていました。結局のところ、毎日（または毎時間、毎分…）デプロイする場合、テストにどれだけの時間が残るでしょうか?また、テストは製品の提供に非常に重要であり、毎回正しく実行する必要があります。

Kubernetes の使用を開始したとき、特に GitOps アプローチに従って継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインでテストを構成する場合に、統合テストに大きな課題があることがすぐにわかりました。クラウド ネイティブでテスターが直面する上位 5 つの課題を詳しく見てみましょう。

1. 密結合

密結合アーキテクチャには、特に大量のデータや多数のソースを処理する場合に多くの利点があります。しかし、開発者とテスターのテストの自由が制限されます。

テストとテスト実行アクティビティは CI/CD およびビルド ワークフローと密接に結合されているため、ビルドと同時にテストを実行する必要が生じます。しかし、ビルドと同期していないテストを実行する必要がある場合はどうなるでしょうか?コンポーネントを更新し、テスト スイートの特定の部分のみを再実行したい場合はどうすればよいでしょうか。または、オーケストレーションが GitHub Actions や Jenkins などの CI/CD ツールに関連付けられている場合、特定のテストを実行する必要がありますか?

2. GitOps

GitOps を使用すると、クラスターのステータスを常に把握し、洗練されたワークフローを使用してクラスターを操作できます。成熟した DevOps アプローチと堅牢な GitOps フレームワークを組み合わせると、毎日膨大な量のコードを本番環境にデプロイできます。しかし、テストは具体的にどこで行われ、どのように実行されるのでしょうか?

すべてのクラスター状態を Git で管理するという考え方に、テストとテスト関連の成果物をどのように結び付ければよいでしょうか。テストも同じように管理していますか?すべてのクラスターに適用しますか? GitOps CI/CD パイプラインですでにコードが適切に記述されている場合、テストはどのようにパイプラインに適合するのでしょうか?

3. テストツールの多様化

今では、独自の言語とツールを選択でき、チーム内の個人でも異なる言語とツールを使用できます。これは素晴らしいことです。あらゆる仕事に適切なツールを選択できます。テストも例外ではありません。私たちは、API テスト (SoapUI、Postman)、エンドツーエンドの機能 UI テスト (Cypress、Selenium)、負荷テスト (JMeter、k6)、さらには自動化および統合テスト用の社内フレームワークなど、さまざまな目的でさまざまなテスト ツールを使用しているチームを見てきました。

欠点は、異なるテスト フレームワーク、ツール、ライブラリによって結果が異なる形式で生成されることです。組織によっては、特定の言語での特定のテストを可能にする特定のフレームワークを構築するところもあります。これは、その仕組みを知っているチーム内の 1 人が退職するまでは素晴らしいことです。

テスターとして、すべてにおいて優秀であることはできません。しかし、テストはスタックの非常に多くの部分に影響するため、言語やツールの好みに関係なく、簡単に実行および監視できる標準化されたアプローチが必要です。

4. 測定と監視

結果を見る前に、ビルドで何か問題が発生した理由について第六感を感じたことはありますか?テストが主な焦点である場合、これらのことに対する敏感さを養うことは簡単ですが、組織の非同期性の増大は、それぞれが独自のビルド パイプラインを持つ独立したチームによって管理されるマイクロサービスと同様に、ますます障害になります。この非同期性により、テスト結果のパターンを理解していない人々による問題も明らかになり、物事が間違った方向に進んでいることを検出することが難しくなります。

さまざまな種類のコンポーネントやサービスを多数使用している組織では、QA およびテストの合格/不合格率の指標を一貫して追跡することが重要です。結局のところ、ベンチマークがなければ、チームはどのように成功を測定できるのでしょうか?

5. アクセス制限

Kubernetes にデプロイすると、ロールベースのアクセス制御は言うまでもなく、厄介なネットワーク アクセスとセキュリティの制限によって、クラスター内でアクセスできる内容や実行できる内容が制限されることがあります。これは誰もが経験したことがあるでしょう。これらの制限を解決するのは簡単ではありません。もちろん、必要なときにアクセスを提供してくれる寛大な DevOps の同僚がいるほど幸運な人もいますが、必ずしもそうとは限りません。さらに、特定のテスト環境では、通常付与される権限をはるかに超える機能テストやパフォーマンス テストを実行するために、クラスター アクセスが必要になる場合があります。