copied!

Testkubeとは？KubernetesクラスタにおけるE2Eテストの統合

Sreake事業部

2025.4.25

copied!

Sreake事業部インターン生の荒木です。長期インターン生としてKubernetesやSRE、LLM領域の関連技術など幅広い領域にわたって調査・検証を行っています。

今回、kubernetesクラスタのE2Eテストを統合、管理することができるTestkubeというツールを紹介します。

概要

testkubeはクラウドネイティブアプリケーション向けのテスト統合、実行プラットフォームです。

testkubeを用いることで、複数のコンテナ、Podに用意されたテストを一元管理し、コントロールプレーン上で実行、結果を参照することができます。また、CI/CDパイプラインからトリガーすることができます。

下記画像の通り、広く知られているテストフレームワークに対応しているため、既存テストの集約可能性が高いです。

提供形態と価格に関して

Testkubeを自分の開発環境で利用するには以下の手段があります。

オンプレミス
コントロールプレーンとエージェントを自分の環境下にデプロイして使用する。
クラウドコントロールプレーン
コントロールプレーンはTestkubeがホストし、エージェントのみをユーザー環境にデプロイするSaaS形式。
エージェントのみ利用する(スタンドアロンモード)
kubernetesクラスタにエージェントのみインストールして、testkubeCLIでエージェントを操作することでテストを実行する。

インストール実行に関して、testkubeが用意したCLIアプリケーション経由、もしくはHelmChartからのインストールが可能です。

CLIアプリケーション経由でインストールを行うと、ローカルのKubernetesクラスタに、Helm Chartとデモ環境用の設定ファイル (values.yaml) を用いてTestkubeがインストールされます。

まず、1. オンプレミスインストールに関して、これを行うにはライセンスキーを取得する必要があります。テストの実行回数などに制限がある無料ライセンスと、商用ライセンス($700/月)があり、これをインストールの過程で入力する必要があります。

そして、3. エージェントのみ利用する場合は構成要素がすべてオープンソースとして公開されています。そのため、testkubeCLI経由でエージェントを操作してテストを管理することもできます。

オンプレミスインストールではひとつのDashboardで複数のエージェントを操作することも可能です。つまり、複数クラスタにまたがるテスト管理、UI操作でのテスト実行、ユーザー管理等のテスト管理ソリューションの提供が有償ということです。

https://docs.testkube.io/articles/install/feature-comparison

オンプレミスインストール

TLSが無効で、かつローカルホストでのインストールであれば、testkube CLIを用いて容易にインストールできます。

# testkube CLIのインストール
wget -qO - https://repo.testkube.io/key.pub | sudo apt-key add - ; \
echo "deb https://repo.testkube.io/linux linux main" | sudo tee -a /etc/apt/sources.list; \
sudo apt-get update; \
sudo apt-get install -y testkube

$ testkube init --help
Init installs the Testkube in your cluster as follows:
        standalone-agent -> Testkube OSS
        demo -> Testkube On-Prem demo
        agent -> Testkube Agent
Usage:
  testkube init <profile> [flags]
  testkube init [command]
...
$ testkube init demo

testkube init demo を実行することにより、Helm ChartにDemo用のパラメータが渡されインストールが完了します。デフォルトでtestkubeはtestkube namespaceにインストールされます。

以下はオンプレミスインストールをDemoの構成でインストールした際のアーキテクチャです。

https://docs.testkube.io/articles/install/overview

$ kubectl get pod
NAME                                                    READY   STATUS      RESTARTS      AGE
testkube-api-server-58bd8fc9b9-4jk9b                    1/1     Running     2 (23h ago)   23h
testkube-enterprise-api-67bdf4bfcc-nnnvz                1/1     Running     0             23h
testkube-enterprise-api-migration-1-58psx               0/1     Completed   0             23h
testkube-enterprise-dex-59f76cf9fb-d7hs9                1/1     Running     0             23h
testkube-enterprise-minio-67b88745f6-zpmm7              1/1     Running     0             23h
testkube-enterprise-mongodb-6f675fb5df-92z5k            1/1     Running     0             23h
testkube-enterprise-nats-0                              2/2     Running     0             23h
testkube-enterprise-ui-5f88b6675-5bd8t                  1/1     Running     0             23h
testkube-enterprise-worker-service-54647588f9-tqpf8     1/1     Running     0             23h
testkube-minio-testkube-556b4d7899-9x2mc                1/1     Running     0             23h
testkube-nats-0                                         2/2     Running     0             23h
testkube-operator-controller-manager-7dd86484b9-8bnqj   1/1     Running     2 (18h ago)   23h

テスト実行の結果データや実行中のテストの情報はMongoDBに保存され、テスト実行時に生成される動画やスクリーンショットなどのメディアファイルはMinIOに保存されます。

NatsはTestkubeのAPIとエージェント間の通信で用いられます。worker-serviceは各テスト実行結果をNats経由でエージェントから収集し、MinioへのアップロードやMongoDBの操作を担当しています。

そして、AgentAPIはテストの実行インスタンスであり、各テストフローはKubernetesネイティブのJobとして実行されます。次の項で述べる、スタンドアロンモードではこれがテストを管理する役割を果たします。

スタンドアロンモードでのインストール

スタンドアロンモードはエージェントのみをクラスタにインストールする方法です。

https://docs.testkube.io/articles/install/standalone-agent#deployment-architecture

以下のコマンドでインストールできます。

testkube init

このエージェントはtestkube CLI を用いることでのみ操作することができます。このモードに関しては完全OSSなのでライセンスキーは必要ありません。マルチクラスタのテストの統合管理機能、RBACはこのモードでは行うことができません。

その他機能の差分は以下の通りです。

https://docs.testkube.io/articles/install/feature-comparison

その他高度なインストールに関して

コントロールプレーンを外部からアクセスするためにはNginx controllerとCert Managerを用いてIngressを構成することをtetstkubeは推奨しています。

TestkubeのHelm Chartは、ローカル環境以外へのデプロイを行う場合、主要なサービスへのルーティングにNginx Ingress Controllerのホストベースルーティングを用いることを前提としているようです。そのため、どのサービスがどのポートで接続するかといった情報を、values.yamlに詳細に記述する必要があると考えられます。

テスト管理の操作に関して

demoインストールを行った後、

testkube dashboard

を行うことで、必要なポートがホストマシンにPort-fowardされ、localhost:8080でアクセスできるようになります。

ログイン画面ではデフォルトのクレデンシャル、admin@example.com / password でログインできます。

ログインが完了するとダッシュボードが表示されます。

testkubeにおける実際のテストの管理方法について説明します。以下の内容は全てtestkubeCLIで実行することができるのですが、testkubeCTLには現在のtestkubeで非推奨になった機能を使用するサブコマンドが複数あります。公式ドキュメントにおいて、例えば「テストを作る」という目的において、一見該当しそうなコマンドがこれだけあります。

testkube create executor – Create new Executor
testkube create template – Create a new Template.
testkube create test – Create new Test
testkube create testsource – Create new TestSource
testkube create testsuite – Create new TestSuite
testkube create testworkflow – Create test workflow
testkube create testworkflowtemplate – Create test workflow template

しかし、実際に使うことが想定されるのは以下の2つだけであり、それ以外は全て現在非推奨の機能です。

testkube create testworkflow – Create test workflow
testkube create testworkflowtemplate – Create test workflow template

testworkflow
- 複数のステップから成る一連のテストの定義。
- GithubActions の .github/workflows/*.ymlに似た役割を持つカスタムリソース(CRD)。
testworkflowtemplate
- testkubeにより事前定義済みの各種テストフレームワークに対応したテストワークフローのテンプレート。
- これにパラメータを渡すことで、テストフローを効率的に作成することができる。
- このテンプレート自体を作成することもできる。

テストワークフロー

テストワークフローは、コントロールプレーンからUI操作を通じて追加できます。

UI上での手続きを経ることで、例として以下の様な定義を持つCRDが作成されます。

kind: TestWorkflow
apiVersion: testworkflows.testkube.io/v1
metadata:
  name: example_pytest
spec:
  container:
    image: python:3.8.17-alpine3.18
    workingDir: /data/repo/Pytest-Test-Workflow
  content:
    git:
      paths:
      - Pytest-Test-Workflow
      revision: main
      # usernameFrom:
      #   secretKeyRef:
      #     name: git-credentials # 例
      #     key: username
      # tokenFrom:
      #   secretKeyRef:
      #     name: git-credentials # 例
      #     key: token

  steps:
  - name: Run test
    shell: pip install pipenv requests pytest && pytest test-api-endpoint.py

これはgithubリポジトリに作成したpytestを実行するものです。プライベートリポジトリから取得する場合は、usernameFromおよびtokenプロパティを用いて事前に作成しておいたKubernetes Secretを指定することで認証を行います。

ZAP、Postman、k6、Pytestなど、多様なテストツールに対応したテンプレートが事前に用意されています。JavaScript系のフロントエンドのテストツールである、Cypressのテンプレートを使用した例です。

kind: TestWorkflow
apiVersion: testworkflows.testkube.io/v1
metadata:
  name: sample
spec:
  content:
    git:
      uri: https://github.com/kubeshop/testkube
      paths:
        - /data/repo/test/cypress/executor-tests/cypress-13
  use:
    - name: official/cypress/v1
      config:
        dependencies_command: "npm install"
  container:
    workingDir: /data/repo/data/repo/test/cypress/executor-tests/cypress-13

テンプレートとして、当該のofficial/cypress/v1を指定して、パラメータとして、config.dependencies_commandを与えています。

テンプレートの中身は

kind: TestWorkflowTemplate
apiVersion: testworkflows.testkube.io/v1
metadata:
  name: official--cypress--v1
  namespace: testkube
  labels:
    testkube.io/name: Cypress
    testkube.io/wizard: enabled
  annotations:
    helm.sh/hook: post-install,post-upgrade
    helm.sh/hook-delete-policy: hook-failed,before-hook-creation
    helm.sh/hook-weight: "19"
    testkube.io/categories: E2E
    testkube.io/description: Run Cypress tests
    testkube.io/icon: cypress
    testkube.io/image: cypress/included
spec:
  config:
    dependencies_command:
      description: Command to install dependencies
      type: string
      default: npm install
    run:
      description: Run command
      type: string
      default: npx cypress run
    version:
      description: Cypress version to use
      type: string
      default: 13.6.4
  container:
    image: cypress/included:{{ config.version }}
  steps:
  - name: Install dependencies
    shell: '{{ config.dependencies_command }}'
  - name: Run Cypress tests
    shell: '{{ config.run }}'

となっており、典型的な実行パターンが既に記述済みです。そのため、既存のテストコードがあれば、比較的容易にテストワークフローに組み込むことが可能だと考えられます。

testkubeにはcron形式で定期実行させる機能が備わっており、これを利用するには

spec:
  events:
  - cronjob:
      cron: 0 3 * * * # m h dom mon dow

として設定します。

テスト実行のトリガーと結果

実行結果のログは以下の様に確認できます。

負荷ツールであるk6のテンプレートでは実行結果をhtml形式でArtifactとして出力する設定が行われています。コントロールプレーンのUI上から参照、ダウンロードすることが可能です。

次の操作で同様のことはCLIで行えます。twはtestworkflowのエイリアスになっています。

作成

テストワークフローを記述した.yamlを用意して

testkube create tw -f [FILE_PATH]

リスト(テストワークフローの名前の確認)

testkube get tw

実行

testkube run tw [NAME]

削除

testkube delete tw [NAME]

テスト実行を既存のCI/CDと統合する

既存のCI/CDと統合して、テストワークフローの実行をトリガーする機能があります。

例えば、GithubActionでは、kubeshop/setup-testkube@v1というアクションが用意されており、testkube CLIと同様の機能をCICDの実行環境で使用することができます。

steps:
  - uses: kubeshop/setup-testkube@v1
    with:
      organization: ${{ secrets.TkOrganization }}
      environment: ${{ secrets.TkEnvironment }}
      token: ${{ secrets.TkToken }}

  - run: |
      testkube run testworkflow TEST_WORKFLOW_NAME -f

TkTokenはtestkubeのコントロールプレーンから発行することができるシークレットです。

今回の検証ではパブリックにtestkubeのコントロールプレーンをデプロイせず、完全にローカルのクラスタで試したため動作について詳細に検証できていません。

上記yamlには記述していないのですが、urlパラメータを用いてTestkube をデプロイした際のドメイン(URL)を記述する必要があるようです。プライベートアクセスのみ許可したネットワークのtestkubeをトリガーするには一工夫必要そうです。

まとめ

メリット

アプリケーションの外部テストに焦点を当て、これらテストの統括機能を提供できる。
多くのテストフレームワークに対応したテンプレートがあるため、既存のテストが存在する場合の導入が容易
管理用のクラスタと、サービスデプロイ用のクラスタに分かれていてもテストの統合が行える

デメリット

商業利用ライセンスが高額: $700/month
- https://testkube.io/pricing
- Freeトライアルではテストの総実行回数に上限がある。
インストールの難易度が高い
- 日本語ドキュメントが少なく、インストールのための情報が少ない
- 外部公開する構成でインストールするにはNginx controllerとCert Manageerを使用して、サブドメインルーティングを行う必要があり、設定が複雑。
Helm ChartにおけるAPIサーバーとして、testkube-enterprise-apiが使用される記述がある。
- このコンテナのソースコードがプライベートになっており、デバッグや、エラーが発生した際の原因特定が困難

確かにコントロールプレーン経由でのテスト管理は非常に直感的ですが、実運用する場合必要になるライセンス料が高額となっています。しかしながら、マルチクラスタ環境でのテスト管理や、複数のPodに依存するテストを一元管理する際に、大きなメリットがあると考えられます。

もし、testkubeを用いずにテストを管理する場合のことを考えてみましょう。先ほど使用したOpentelemetry Demoにおいては、テスト用のコンテナとdocker composeを作成し、それを本番構成のyamlをラップすることでテストを行っていました。

# Copyright The OpenTelemetry Authors
# SPDX-License-Identifier: Apache-2.0

include:
  - path:
      - docker-compose.yml     # depend on the main docker-compose file
      - docker-compose-tests_include-override.yml  # include override for tests

services:
  # *****
  # Tests
  # *****
  # Frontend Tests
  frontendTests:
    image: ${IMAGE_NAME}:${DEMO_VERSION}-frontend-tests
    container_name: frontend-tests
    build:
# 中略

  # Tracebased Tests
  traceBasedTests:
    image: ${IMAGE_NAME}:${DEMO_VERSION}-traceBasedTests
    container_name: traceBasedTests
    build:
# 中略
  tracetest-server:
    image: ${TRACETEST_IMAGE}
    platform: linux/amd64
    container_name: tracetest-server
# 中略

https://github.com/open-telemetry/opentelemetry-demo/blob/main/docker-compose-tests.yml より一部引用

冒頭のincludeパラメータで本番構成のdocker-composeファイルを読み込んでいます。このdocker-compose-tests.ymlをCI/CDパイプラインから実行することでテストが実行されます。この方法では大規模なサービス構成において非常に大きなdocker-composeファイルが必要となるうえ、各CIの実行時間も長くなってしまうことが想像できます。

その点、testkubeではテストワークフローを一度作ってしまえば、それをコントロールプレーン上で一元管理することができ、各テストもコンテナとして独立しているため、テストの実行時間も短縮されることが期待されます。

シングルクラスタの環境下であればスタンドアロンモードをヘッドレスで使用するユースケースが考えられます。工夫は必要ですが完全に無償でtestkubeを利用することができます。しかし、操作感や具体的な可能性を知るためにフリーのライセンスを取得してオンプレミスインストールを試すことをお勧めします。

おわりに

今回はクラウドネイティブアプリケーション向けのE2Eテスト管理ツールである、testkubeに関してまとめました。

小規模なクラスタやリポジトリ単位のテストCIで十分な場合に有効活用するためには工夫が必要かもしれませんが、多くのPodに依存するテストを実行、一元管理する際にライセンス料に見合った恩恵を享受できると考えます。

今回の検証ではtestkubeのコントロールパネルをパブリックでデプロイしたり、実際にコードリポジトリのCI/CDでテストワークフローを実行するなどは行えませんでした。今後の課題として、この機能に焦点を当てた検証を行っていく予定です。

SRE向けイベント【3-shake SRE Tech Talk #12】〜o11y Special〜を開催します