多数の Kubernetes クラスターを運用するのに適したコントロール プレーンとは?

このブログでは、Volterra がどのようにしてユーザーがapplicationsとインフラストラクチャを艦隊のように運用できるように支援するかについて説明します。 当社のコントロール プレーンベースのアプローチが大規模なアプリ クラスター群の運用をどのように容易にするかを説明し、Google Anthos、Azure Arc、Rancher などの他のマルチ クラスター管理プレーン アプローチと比較します。

ここまで読んで、私たちが単にマーケティングの宣伝をしていて、マルチクラスター管理をフリート運用と呼んでいるのではないかと疑問に思われるかもしれません。 マルチクラスター管理とフリート運用のアプローチは、異なるユースケースに対応しており、アーキテクチャが根本的に異なります。 マルチクラスター アプローチは、クラスターの数が比較的少なく、ユーザーが一貫した運用モデルを使用してこれらのインフラストラクチャ クラスターを管理したいというシナリオに対応するように設計されています。 一方、フリート アプローチは、大規模なクラスター (ロボット、自動車、産業用ゲートウェイ、数十のパブリック クラウド リージョンなどの K8s クラスターなど) があり、ユーザーがこれらの大規模なクラスターに同じapplicationとネットワーク/セキュリティを展開したい場合のシナリオに対応するように設計されています。 次の 2 つのセクションでは、マルチクラスターとフリート運用アプローチについてさらに詳しく説明し、比較します。

マルチクラスターアプローチ

マルチクラスター管理アプローチは、単一チームの運用下にあるクラスターの数が比較的少ない場合のユースケースに対応するように設計されています。 このようなシナリオの例としては、爆発半径を縮小するために、いくつかのアベイラビリティーゾーンにまたがる数十のクラスターが挙げられます。 同様に、ユーザーは規制上のニーズに対応するために、いくつかのリージョンにまたがる複数のクラスターを選択する場合があります。

次の 2 つの例は、マルチクラスター ソリューションがどのように機能するかを (高レベルで) 示しています。

構成

図 1 に示すように、Rancher のマルチクラスター アプローチを使用したapplication展開の例を見てみましょう。 マルチクラスター アプローチでは、顧客はapplication展開のターゲット サイトを 1 つずつ選択します。 ターゲット サイトを 1 つずつ選択するこのアプローチは、クラスターがいくつかある場合に有効です。 ただし、このアプローチは、たとえば 1,000 個のクラスター向けには設計されていません。

可観測性

図 2 は、Rancher を例に、マルチクラスター アプローチで可観測性がどのように機能するかを示しています。 マルチクラスター アプローチでは、展開されたポッドのステータス、CPU およびメモリ リソースの使用率を確認するには、顧客は各クラスターを 1 つずつダブルクリックする必要があります。 ターゲット サイトを 1 つずつ監視するこのアプローチは、少数のクラスターには適していますが、多数のクラスターを管理するには適していません。

クラスター 1:

クラスター 2:

最初の例で説明した問題を解決するための明らかなアプローチは、各クラスターに対してタスクを繰り返す何らかの形式の自動化を作成することです。 たとえば、新しいクラスターが追加されるたびに、スクリプトは次の操作を実行して新しいapplication(たとえば checkoutservice) をデプロイできます。

KUBECONFIG=~/Documents/kubeconfig/ce01-ashburn-aws-staging をエクスポートします。

kubectl を適用 -f checkoutservice.yaml

ただし、展開、アップグレード、ポリシー、リソース予約などの各操作ごとに自動化を構築する必要があります。 この自動化では、多数のクラスターにわたって個々の操作を実行するだけでなく、障害状態の処理も考慮する必要があります。 また、クラスターのサブセットでのベータ テストや、すべてのクラスターにわたるローリング アップグレードなどの複雑なシナリオがある場合、自動化はますます複雑になります。 私たちはプロセスの早い段階でこれを認識し、次に説明するフリート運用アプローチを使用して、これらすべての機能を提供する分散型コントロール プレーンを構築しました。

Volterraのフリート運用アプローチ

フリート運用とは、顧客がフリートに対して意図を一度宣言的に定義し、システムが影響を受けるサイトが定義された意図に沿っていることを確認する責任を引き継ぐことを意味します。 意図の例には、applicationソフトウェアのバージョン、インフラストラクチャ ソフトウェアのバージョン (オペレーティング システムのバージョンなど)、ネットワーク ポリシー、セキュリティ ポリシー、リソースの予約などがあります。

意図が有効になると、システムはユーザーが艦隊の状態と健全性を確認できるようにします。 つまり、ユーザーは、フリート内のすべてのサイトのインフラストラクチャとapplicationsの健全性を 1 つの画面で集約的に把握できるため、顧客の運用チームの運用の複雑さが軽減されます。 ユーザーは、健全性を判断するために各サイトまたはクラスターを 1 つずつクリックしたり、情報を集約するための自動化ツールを作成したりする必要がありません。

Volterra のフリート運用アプローチは、セグメンテーション、構成、および可観測性の 3 つの主要コンポーネントで構成されており、これらについては次のセクションで説明します。

艦隊のセグメンテーション

多くの場合、ユーザーは開発、テスト、本番コンピューティング サイトなど、複数のサイトを混在させています。 開発ワークロードは開発サイトにのみ配置されるなどの組織ポリシーにより、さまざまなワークロードを特定のサイト セグメントに展開する必要があります。 ユーザーは、キーと値の 2 つの部分で構成されるラベルを使用して、サイトに柔軟にタグを付けることができます。 例: 

• ラベルキー=地域。 ラベル値 = US-West、JP-North、JP-south
   
• モデル年=(2015、2016、2017、2018)
   
• 機能=(スプレー、溶接)

サイトにタグが付けられると、ユーザーはラベルのキーと値の条件を使用して「仮想サイト」を定義できます。 マルチクラウドのシナリオでは、ユーザーは自分のサイトに dev、pre-prod、prod などのタグを付けることができます。 次の図 3 は、前述のラベル キー値を使用したロボットの使用例を示しています。

以下は、ユーザーが blend/go-sdk 構文を使用して仮想サイトを作成できる Volterra の構成スニペットです。 この例では、個々のサイトはラベルキー=ves.io/countryとラベル値ves-io-jpnでタグ付けされています。

ユーザーは、事前に艦隊のセグメントを定義し、プロビジョニング時に艦隊に含めるサイトにタグを付けるという運用モデルに慣れています。仮想サイトは、ユーザーの既存の運用モデルと完全に連携します。 新しいサイトが適切なタグを使用してプロビジョニングされると、追加の手動手順を必要とせずに、以前に定義された仮想サイトに自動的に含められます。 さらに、Volterra は、ハードウェアの製造元やパブリック クラウドの種類などの事前にプロビジョニングされた情報を検出し、システム タグを事前に入力します。 ユーザーはオプションで、これらの自動検出されたタグを使用して仮想サイトを定義することを選択できます。

艦隊構成

フリート構成機能は、次の 3 つの例で最もよく説明できます。 

• ネットワーク/セキュリティ ポリシーの構成- 各クラスターが特定の URL (例: github.com ) と通信する必要がある新しいサービスを展開する顧客の例を見てみましょう。 通常、ユーザーはホワイトリストを使用します。つまり、クラスターは特定の宛先にのみ到達できます。 したがって、この新しいサービスを展開するには、ユーザーが各クラスターにアクセスし、ネットワーク ポリシーを変更してgithub.com をホワイトリストに追加する必要があります。 さらに、顧客はこれをすべてのサイトに展開する前に、いくつかのテスト サイトでテストしたいと考えています。 Volterra でこの目的を達成するには、顧客はまず、Volterra SaaS コンソールでフリートのセグメントを選択する「テスト」仮想サイトを定義します。 次に、ユーザーは、URL のホワイトリスト (この例ではgithub.com ) などのネットワーク ポリシーを定義し、それを「テスト」仮想サイトに適用します。 Volterra の分散制御プレーンは、仮想サイト (上記で定義) によって選択された各サイトのローカル制御プレーンにネットワーク ポリシーを送信します。 各サイトのローカル コントロール プレーンは、ネットワーク ポリシーを適用し、サイトごとにヒットしたルールの統計を収集します。 顧客は、サービスが期待どおりに動作していることに満足したら、ネットワーク ポリシーを「prod」仮想サイトに適用して、フリート内の残りのサイトを選択できます。 以下は、Json を使用し、Volterra のシステム上の UI を使用する構成スニペットです。

• インフラストラクチャ ソフトウェアのアップグレード- フリート構成機能により、ユーザーはフリート全体 (またはフリートのセグメント) のインフラストラクチャ ソフトウェア (オペレーティング システムのバージョンなど) をアップグレードできます。 まず、ユーザーはオペレーティング システムをバージョン 1 からバージョン 2 にアップグレードする意図を定義します。 次に、ユーザーは、ローリング アップデート、ブルー/グリーンなど、フリート全体にわたる展開戦略を定義します。 ローリング アップデートとは、フリート (またはフリートのセグメント) 内のすべてのサイトのオペレーティング システムが順番にアップグレードされることを意味します。 ブルー/グリーン デプロイメント戦略とは、ユーザーが一連の「ブルー」サイト (開発サイトなど) でアップグレードをテストし、アップグレードされていない「グリーン」サイト (本番サイトなど) と健全性を比較することを意味します。 いずれの場合も、Volterra の分散コントロール プレーンは、仮想サイトによって選択され、展開戦略で定義されている各サイトのローカル コントロール プレーンにバージョン 2 ソフトウェアを送信します。各サイトのローカル コントロール プレーンは、A/B 方式でオペレーティング システムをアップグレードします。つまり、新しいパーティションを作成し、新しいパーティションにバージョン 2 を展開して、顧客が健全性を測定できるようにします。 バージョン 2 のインストールが成功しなかった場合、システムは自動的に元のパーティションのバージョン 1 にロールバックします。 以下は、ユーザーが Volterra SaaS ポータルを使用してインフラストラクチャ ソフトウェアのアップグレードを実行する方法を示したスクリーンショットです。 次の図に示すように、ユーザーは現在のインフラストラクチャ ソフトウェア バージョンと、すべてのサイトで使用可能な最新のソフトウェア バージョンを確認できます。 ユーザーは、運用モデルの指示に従って、特定のサイトまたはすべてのサイトを簡単にアップグレードできます。

• applicationsのフリート全体への展開 - Volterra は、ユーザーが Kubernetes API を使用してフリート全体のapplicationsを管理できるようにする Virtual Kubernetes (vK8s) と呼ばれるオブジェクトを提供します。 ユーザーは、デプロイメント マニフェスト ファイルを使用して標準の Kubernetes メソッド (Kubeconfig ファイルと Kubernetes API) を使用してapplicationsをデプロイし、applicationをデプロイする必要があるサイトのセグメント (またはフリート全体) を指定します。 その後、Volterra の Virtual Kubernetes (vK8s) が、フリート内のすべてのサイト (またはセグメント) にapplicationを展開する責任を引き継ぎます。 applicationのデプロイメント中に接続障害やインフラストラクチャ障害などの障害が発生した場合、Volterra Virtual Kubernetes は、最終的に一貫性のあるモデルの Kubernetes パラダイムに従って、デプロイメントを再試行し続けます。 次のスクリーンショットは、ユーザーが「jpn-all-sites」という仮想サイトに「kuard」というapplication( Kubernetes-up-and-running-demo-appを参照) をデプロイし、フリートの 140 サイトを選択している例を示しています。 新しいデプロイメントを追加するには、ユーザーは「デプロイメントの追加」をクリックし、仮想サイトの観点からデプロイメントの場所を指定して、新しいデプロイメントを追加するだけです。

適切なラベルが付いた新しいサイトがフリートに追加されると、新しいサイトは仮想サイト (この例では jpn-all-sites) に自動的に追加され、フリート構成 (この例では Kuard デプロイメント) が新しく追加されたサイトに自動的に適用されるため、運用チームの負担が軽減され、人的エラーが排除されます。

艦隊の観測可能性

仮想サイトと仮想 Kubernetes (vK8s) は、構成に使用されるだけでなく、フリート内の分散サイト全体の健全性を集約するためにも使用されます。 これは、ユーザーが各サイトからステータスを 1 つずつ取得して情報を集約するためのツールを作成する必要がある他のソリューションと比較して、非常に強力なツールです。 このシステムは、すべてのサイトのヘルス ステータスを 1 つの画面に自動的に集約し、顧客の運用チームの運用の複雑さを軽減します。 収集されるヘルス ステータスには、applicationの展開ステータス、サイトのヘルス、applicationのヘルスなど、さまざまな側面が含まれます。

次のスクリーンショットに示すように、ユーザーは地図上ですべてのサイトの健全性の概要を簡単に把握できます。 色は、健康スコアが 75 より大きい場合は緑、40 ～ 75 の場合はオレンジ、40 未満の場合は赤で示されます。 ヘルススコアは、接続性、信頼性、セキュリティ、パフォーマンス (つまり、リソース消費) で構成される集計スコアです。

ユーザーは、サイトの健全性とともに、すべてのサイトにわたる接続性の集約ビューも表示できます。 図 10 に視覚化されているように、サイトを Volterra バックボーンに接続する各リンクの接続状態も表示されます。 ユーザーは、ヘルス ステータスに基づいてパフォーマンスが低いリンクをクリックして、リクエストとエラーに関する詳細な統計情報を表示し、図 11 に示すように接続の問題をトラブルシューティングできます。

次に、ユーザーは、サイト全体の CPU およびメモリ負荷分散を介して、すべてのサイトにわたる集計情報を表示できます。 この情報は、どのサイトが過度に使用されており、リソース不足の危険があるかを IT 管理者またはサイト管理者が特定するのに役立ちます。 サイト管理者は、リソース消費量がしきい値を超えたときに通知されるアラートを設定できます。 このスクリーンショットでは、サイトの半数が使用可能なメモリの 75% 以上を消費していることが分かります。 この情報を取得するために、個々のサイトをクリックしたり、追加のツールを作成したりする必要はありません。

フリート オブジェクトの継続的な検証機能により、POD 展開のステータス (展開された POD の数、進行中の POD の数、失敗した POD の数) が提供されます。 デプロイされると、ユーザーはポッドのヘルスステータス（実行中か、イメージを待機中か、メモリ不足かなど）も確認できるようになります。

さらに、ユーザーは、次のスクリーンショットに示すように、セキュリティ ポリシーの有効性の集計ビューを確認し、すべてのサイトにわたるヒットを取得できます。

まとめ

Volterra のフリート運用アプローチが 3000 クラスターのフリートの管理にどのように使用されたかについて詳しくは、Kubernetes カンファレンスでのVolterra のプレゼンテーションをご覧になり、 Jakub Pavlik のブログをお読みください。

次のブログ「効果が出るまでの時間」では、Volterra の分散型コントロール プレーンとバックボーンが、非常に短い時間でグローバルに分散されたサイト間で構成の一貫性を伝播し、確保するのにどのように役立つかについて説明します。 乞うご期待！