カスタム Kubernetes コントローラーを使用してトラフィックをテストする方法: ステップバイステップ ガイド

K8s コントローラーとオペレーター

k8s ワールドでは、すべてのリソースがコントローラー経由で作成されます。ポッド、デプロイメント、レプリカ セットなどの組み込みコントローラーがあるのと同様に、コントローラーは基本的に、クラスターの状態を継続的に監視し、クラスターを望ましい状態にするためのアクションを実行する制御ループに他なりません。リソースには、望ましい状態を提供する仕様があります。コントローラーは現在の状態をチェックします。望ましい状態と一致しない場合は、適切な変更や修正を加えて望ましい状態に近づけます。

さまざまなタイプの Kube-Controller-Manager

• ReplicaSet コントローラー: このコントローラーは、常に実行中のレプリカ Pod の安定したセットを維持する責任があります。これは、ノード障害やポッドの終了が発生した場合でも、指定された数のポッド レプリカが常に実行されるようにするために、デプロイメントと組み合わせて使用​​されることがよくあります。

• デプロイメント コントローラー: このコントローラーは、Pod と ReplicaSet の宣言的な更新を提供します。これにより、アプリケーションのスケーリング、ローリング アップデート、ロールバックが容易になります。デプロイメント コントローラーは、必要な数のポッドが常に実行されるように、ReplicaSet の作成と削除を管理します。

• StatefulSet コントローラー: このコントローラーは、データベースなどのステートフル アプリケーションの管理に使用されます。これは、セット内の各ポッドに一意の ID (安定したホスト名) を提供し、これらのポッドの順序と一意性を維持します。これは、安定したネットワーク識別子、安定した永続ストレージ、順序付けられた適切なデプロイメントとスケーリングが必要な場合に特に役立ちます。

• サービス コントローラー: このコントローラーは、一連のポッドの安定した IP アドレスと DNS 名を維持する責任があります。これはロード バランサーとして機能し、サービスのセレクターに基づいてトラフィックを適切なポッドにルーティングします。これにより、クラスター内でポッドが作成、破棄、または移動される場合でも、サービスは実行中のポッドにアクセスするための安定したエンドポイントを確保できます。

動作とアーキテクチャ

テストに入る前に、標準コントローラーの基本アーキテクチャを理解する必要があります。 Kubernetes のクライアント/サーバー アーキテクチャでは、コントローラーは、Kubernetes API サーバーに対して API 呼び出し (主に HTTP) を行うクライアントとして重要な役割を果たします。その主な目的は、Kubernetes API オブジェクトと実際のシステム リソースを調整することです。このアーキテクチャの重要なコンポーネントは、Informers の使用です。インフォーマーはクラスター内の変更を監視する責任があります。リソースに関する情報を取得するための継続的なポーリングは API サーバーのパフォーマンスを大幅に低下させる可能性があるため、これは非常に重要です。

インフォーマーは、リソース データをクエリし、それをローカル キャッシュに保存することによって機能します。データが保存されると、オブジェクト (またはリソース) の状態に変化があった場合にのみイベントが生成されます。このアプローチにより、システムが不必要なイベントによって圧倒されず、関連する変更が発生した場合にのみコントローラーに通知されることが保証されます。

このアーキテクチャにおけるもう 1 つの重要な概念は、リソースのバージョンです。このバージョンは書き込み操作ごとに変更され、オプティミスティック同時実行制御に使用されます。これにより、競合を回避し、システム全体の一貫性を維持する方法でリソースの更新が管理されるようになります。これらのメカニズムを理解して活用することで、Kubernetes コントローラーはクラスター内のリソースの状態を効率的に管理し、調整できるようになります。

Kubernetes のカスタム CRD とコントローラー

Kubernetes では、ユーザーがカスタム リソースを定義できるようにする Kubernetes API の拡張機能であるカスタム リソース定義 (CRD) の作成が可能です。これらのカスタム リソースは、デフォルトの Kubernetes インストールでは使用できず、ドメイン固有のユースケースや複雑なアプリケーション要件に対応するために使用されます。

これらのカスタム リソースを管理するには、カスタム コントローラーが必要です。カスタム コントローラー、CRD、および Kubernetes API サーバーは、次のような緊密な関係を形成します。

• CRD はカスタム リソースを定義します。

• API サーバーは、これらのリソースのライフサイクルを管理します。

• カスタム コントローラーは、これらのリソースの状態が目的の構成に従って確実に維持されるようにします。

このアーキテクチャにより Kubernetes の拡張性が可能になり、ユーザーはプラットフォームを特定のニーズに合わせて調整できるようになります。

コントローラーのテスト -

Kubernetes コントローラーを運用環境にデプロイする前に、Kubernetes API サーバーへのリクエストを処理できる状態にあることを確認することが重要です。 Kubernetes コントローラーをテストするには、いくつかのアプローチがあります。私が言及したものの一部は記事からのものです:

1. client-go のフェイクまたは高レベルの抽象化を使用する: このアプローチでは、バッキング API の実行が回避され、個別のコンポーネントを個別に単体テストするのに適しています。

2. コントローラー ランタイムの envtest パッケージの使用: このパッケージは、他のコントローラーからの干渉なしに、簡素化された API サーバーと連携して、タイミングやキャッシュ同期などの API との実際の対話を検証します。 。簡素化されたインスタンスに対するローカル テストと、完全に機能するクラスターに対するテストの両方をサポートします。

3. 実際の API サーバーの実行: このアプローチは、実際の結果をテストするための一時的な種類や microk8s などのステージング環境またはインスタンスに適しています。これにより、実際の API サーバーに対する対話をテストできます。

envtest や実際の API サーバーなどの外部プロセスを使用する利点は、分散システムに固有の遅延を考慮できることです。 Gomega などのライブラリは、アクションの発生後に特定の条件を待機するために使用できます。上記のアプローチは、多くの場合、特定のコンポーネントを分離してテストする単体テストや統合レベルのテストに最適と思われます。テストを書いてデータを偽装する

上記の手法は単体テストや統合テストには効果的ですが、コントローラーの全体的な機能を保証するために重要なエンドツーエンド (e2e) テストには対応していない可能性があります。 e2e テストの 1 つのアプローチは、リソースの更新やその他の操作を実行して、制御された環境でコントローラーのフロー全体をテストし、必要に応じてプロセスを複製することです。これは、実際のシナリオでコントローラーの動作を検証し、運用環境への展開の準備が整っていることを確認するのに役立ちます。

要約すると、Kubernetes コントローラーを本番環境に導入する前に、その信頼性と有効性を確保するには、単体テスト、統合テスト、エンドツーエンド テストの組み合わせが不可欠です。

Keploy を使用して Kubernetes コントローラーをテストする理由は何ですか?

Kubernetes コントローラーをローカルで構築してテストすることは、特に発信 API 呼び出しを処理する場合に困難になることがあります。しかし、Keploy は、API 呼び出しや DB クエリなどからテスト ケースやデータ モックを作成するツールとして、ソリューションを提供します。 Keploy を使用すると、Kubernetes コントローラーによって行われた発信呼び出しを記録および再生できます。これは、コントローラーが期待どおりに動作することをテストおよび確認する場合に非常に役立ちます。

コードを変更せずにどのようにしてこれが可能になるのか疑問に思われるかもしれません。 Keploy は eBPF を使用してカーネル空間にプローブを追加し、ネットワーク バッファ データを収集します。このデータはその後、Keploy のプロキシに送信されます。プロキシは、バッファのすべての処理がさまざまなプロトコル パーサーによって行われるユーザースペースとして機能します。 Keploy は、コントローラーの出力トラフィックをキャプチャし、その特定のイベントのリクエストと応答を YAML ファイルに保存できます。再生モード中、Keploy は実際の API サーバーに API 呼び出しを行う代わりに、その特定のリクエストに対して保存されている YAML ファイルからのレスポンスを返します。これにより、プロセスがクラスターや環境から独立し、Kubernetes コントローラーをローカルでテストする便利で効率的な方法が提供されます。

発信通話を録音する

そのため、コントローラーのテストをローカルまたはライブ環境からキャプチャするには、まず kubernetes クラスターを起動し、サーバーと何らかの対話を行うカスタム コントローラーを作成する必要があります。

Keploy でコントローラーを記録するには、次の手順に従います:

1. Kubernetes *rest.Config オブジェクトを安全でなく、CA ファイルなしで設定します。
   

   cfg.Insecure = true
   cfg.CAFile = ""
   

2. カスタム RoundTripper を作成して、リソースのバージョンを含むヘッダー フィールドを追加します。このヘッダーは、記録されたモックと同じ状態でリクエストを照合するためのトレース ID として機能します。実装例は次のとおりです:
   

   type customRoundTripper struct {
       rt http.RoundTripper
   }
   
   func (crt *customRoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {
       ctx := req.Context()
       rsv := ctx.Value("ResourceVersion")
   
       if rsv != nil {
           req.Header.Add("keploy-header", rsv.(string))
       }
       return crt.rt.RoundTrip(req)
   }
   
   cfg.WrapTransport = func(rt http.RoundTripper) http.RoundTripper {
       return &customRoundTripper{rt: rt}
   }
   

3. 同期プロセス中に必ず context.Context にリソースのバージョン値を設定してください。これは、変更されたコンテキストをコントローラーの更新メソッドと作成メソッドに渡すために重要です。例:
   

   func (c *Controller) syncHandler(ctx context.Context, key string) error {
       // set ResourceVersion in ctx
       rv := foo.GetResourceVersion()
       if rv != "" {
           ctx = context.WithValue(ctx, "ResourceVersion", rv)
       }
   }
   

4. Kubernetes コントローラーの Go バイナリをビルドします:
   

   go build -o sample-controller .
   

5. Keploy 経由で発信通話を録音するには、コントローラー コマンドを Keploy の Record コマンドでラップします。注 - keploy のこの機能はベータ版であり、まだメインではリリースされていません。これは、Kubernetes 愛好家がレビューを試みるための実験として特別に作成されました。したがって、この特定のブランチでチェックアウトし、 go build コマンドを使用して keploy バイナリをビルドする必要があります。 https://github.com/keploy/keploy/pull/1342.

   1. 指定されたブランチでチェックアウトします。

      1.
      

            git checkout kube-controller
          ```
      {% endraw %}
      

   1. そのブランチの keploy バイナリをビルドします。
      {% 生 %}

      go build -o keploy && sudo mv keploy  /usr/local/bin
      

1. kube 構成に従って必要なフラグを追加します。
   

   sudo -E env PATH=$PATH keploy record -c "./sample-controller -kubeconfig=$HOME/.kube/config"  --mtls-cert-path "$HOME/.minikube/profiles/minikube/client.crt" --mtls-key-path "$HOME/.minikube/profiles/minikube/client.key"  --mtls-host-name 192.168.49.2:8443
   

2. Keploy が発信呼び出しのインターセプトを開始するとすぐに、keploy/test-set-0/mocks.yaml が作成されることがわかります。各リソース バージョンには、mocks_ "" で示される個別のモック ファイルがあります。

注 - 明確にしておきたいのは、上記の機能は TDD (テスト駆動開発) には役に立たないということです。ただし、keploy のスタブ生成機能を利用することで、単体テストの作成中に keploy を実行できます。そのため、模擬 API サーバーを作成したり、特定の単体テストのスタブを作成したりする代わりに、そのテストを実際の環境で一度実行することができます。 Keploy はすべてのインタラクションをモック ファイルに保存し、次回テストを実行するときにそのデータを使用します。

記録されたモックを使用したテスト

記録されたモックを使用してコントローラーをテストするには:

1. mockAssert フラグを true に設定してテスト モードで Keploy を実行し、コントローラー バイナリを提供します。 Keploy は自動的に偽の kube 構成を作成します:
   

   cfg.Insecure = true
   cfg.CAFile = ""
   

2. オプションで、独自の再生時間を設定できます。これにより、指定された時間内に記録されたセッションの再生が試行されます。keploy と統合された完全なサンプル アプリがここにあります。
   

   type customRoundTripper struct {
       rt http.RoundTripper
   }
   
   func (crt *customRoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {
       ctx := req.Context()
       rsv := ctx.Value("ResourceVersion")
   
       if rsv != nil {
           req.Header.Add("keploy-header", rsv.(string))
       }
       return crt.rt.RoundTrip(req)
   }
   
   cfg.WrapTransport = func(rt http.RoundTripper) http.RoundTripper {
       return &customRoundTripper{rt: rt}
   }
   

3. 再生プロセスでは、通知者の 2 つのイベント間の正確な平均継続時間まで、十分に大きなイベント時間のギャップがトリミングされることに注意してください。これにより、イベントがレコード内で発生するよりも早く送信され、より高速な再生が容易になります。

4. これは、コントローラーによって生成された API 呼び出しのセッション全体を再生するのに役立ちますが、今回は応答を取得するために実際の k8s サーバーや外部ソースは必要ありません。すべての応答は、模擬サーバーまたは仲介者のように機能するケプロイ自体によって返されます。これにより、自信を持って CI-CD パイプラインで実行できるようになります。

5. たとえば - あなたは大規模なクラウド コンピューティング組織で働いており、すべてのものをデプロイするには大量の仮想化が必要であり、リソースを大量に消費する操作です。したがって、実際の環境でテストすることはほぼ不可能です。ここでは、Keploy のようなツールが、そのリソースのロールアウトが成功した場合に取得したい応答がすでに含まれているため、非常に役立ちます。そのため、コントローラー サービスの適切なフローを 1 回だけキャプチャするだけで済むため、高速で信頼性が高く、コストを節約できる操作が可能になります。また、後続のリリースで keploy リプレイを再利用できます。

結論

Keploy などのツールを使用すると、Kubernetes コントローラーをローカルでテストすることがより効率的かつ信頼性の高いものになります。発信呼び出しを記録して再生することで、さまざまなシナリオでコントローラーが正しく動作することを確認し、Kubernetes アプリケーションの全体的な品質を向上させることができます。 keploy は getest のようなテスト フレームワークをネイティブ サポートしているため、kube コントローラーを含むあらゆるアプリケーションのライン カバレッジを取得することも可能です。 Keploy を探索して、Kubernetes コントローラーのテスト ワークフローを強化してください!

よくある質問

Kubernetes コントローラーのテストに Keploy を使用する利点は何ですか?

Keploy は、次の方法で Kubernetes コントローラーのテストを簡素化します。

• 発信 API 呼び出しの記録と再生: これにより、テスト中にライブ環境が必要なくなります。

• 効率の向上: 保存されたモックを使用することで、テストが高速になり、実際の Kubernetes クラスターから独立します。

• コストとリソースの節約: 検証のためのリソース集約型環境への依存を軽減し、大規模な運用における CI/CD パイプラインに最適です。

Keploy は、Kubernetes コントローラーの送信 API 呼び出しをどのように処理しますか?

Keploy は

eBPF プローブ を使用して発信呼び出しを傍受し、要求と応答のペアをモック ファイルに保存します。リプレイモード中:

• 呼び出しはインターセプトされ、以前に記録されたモックと照合されます。

• 実際の API サーバーにアクセスする代わりに、これらのモックから応答が返されます。

  
  このメカニズムにより、ライブ Kubernetes クラスターを必要とせずにテストを実行できるようになります。
  

Keploy は Kubernetes コントローラーを使用したテスト駆動開発 (TDD) に使用できますか?

Keploy の記録および再生機能は TDD 専用に設計されていませんが、効果的に使用できます。

• スタブ生成: 実際の環境でコントローラーを 1 回実行して、インタラクションをキャプチャします。 Keploy は、後で使用するためにモックを作成します。

• 単体テストのサポート: これらのモックを活用することで、スタブを手動で作成することを回避し、テストの実行に集中できます。
  Keploy は、モック作成を合理化し、開発オーバーヘッドを削減することで、既存の TDD ワークフローを補完します。
  

以上がカスタム Kubernetes コントローラーを使用してトラフィックをテストする方法: ステップバイステップ ガイドの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。