多数のKubernetesクラスターを運用するための優れたコントロールプレーンとは？

F5エコシステム | 2020年1月24日

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

ここまでお読みになって、マルチクラスタ管理を「フリート運用」と呼び換えて、マーケティング的に見せているだけではないかと思われたかもしれません。しかし、マルチクラスタ管理とフリート運用では、対象とするユースケースが異なり、アーキテクチャも根本的に異なります。マルチクラスタ方式は、クラスタ数が比較的少なく、一貫した運用モデルでインフラクラスタを管理したい場合を想定しています。一方、フリート方式は、ロボット、自動車、産業用ゲートウェイに搭載されたK8sクラスタや、数十のパブリッククラウドリージョンなど、大規模なクラスタ群に同一のアプリケーションとネットワーク／セキュリティを展開したい場合を想定しています。次の2つのセクションでは、マルチクラスタ方式とフリート運用方式について、さらに詳しく説明し、比較します。

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

マルチクラスタ管理アプローチは、単一のチームが比較的少数のクラスタを運用するユースケースに対応するよう設計されています。たとえば、障害の影響範囲を抑えるために、複数のアベイラビリティゾーンに数十のクラスタを配置するケースが挙げられます。同様に、規制要件に対応するため、複数のリージョンに複数のクラスタを配置することもできます。

以下の2つの例では、マルチクラスターソリューションの仕組みを概要レベルで説明します。

構成

図1に示すように、Rancherのマルチクラスター方式を使用したアプリケーションデプロイを例に説明します。マルチクラスター方式では、アプリケーションのデプロイ先となるサイトを1つずつ選択します。クラスターが少数であれば、この方法で対応できます。しかし、たとえば1,000ものクラスターを扱うことは想定されていません。

図1

オブザーバビリティ

図2は、Rancherを例に、マルチクラスター方式におけるオブザーバビリティの仕組みを示しています。この方式では、デプロイされたPodの状態やCPUおよびメモリのリソース使用率を確認するために、各クラスターを1つずつダブルクリックする必要があります。対象サイトを個別に監視するこの方法は、クラスター数が少ない場合には適していますが、多数のクラスターの管理には適していません。

クラスター1：

クラスター2：

図2

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

export KUBECONFIG=~/Documents/kubeconfig/ce01-ashburn-aws-staging

kubectl apply -f checkoutservice.yaml

しかし、デプロイ、アップグレード、ポリシー、リソース予約など、操作ごとに自動化を構築する必要があります。この自動化では、多数のクラスターにわたって個々の操作を実行するだけでなく、障害発生時の処理にも対応しなければなりません。また、一部のクラスターでのベータテストや、全クラスターにわたるローリングアップグレードなど、複雑なシナリオでは、自動化がますます複雑になります。F5はプロセスの早い段階でこの点を認識し、次に説明するフリート運用アプローチを採用して、これらすべての機能を提供する分散コントロールプレーンを構築しました。

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

Fleet Operationsとは、お客さまがフリート全体に対する意図を宣言的に一度定義すると、影響を受けるサイトがその意図に沿うように維持する責任をシステムが担う仕組みです。意図の例としては、アプリケーションソフトウェアのバージョン、インフラストラクチャソフトウェアのバージョン（オペレーティングシステムのバージョンなど）、ネットワークポリシー、セキュリティポリシー、リソース予約などがあります。

インテントが適用されると、ユーザーはフリートのステータスと健全性を確認できるようになります。つまり、フリート内の全サイトにわたるインフラストラクチャとアプリケーションの健全性を単一の画面で集約して確認できるため、お客さまの運用チームの運用上の複雑さが軽減されます。健全性を確認するために各サイトやクラスターを1つずつ開いたり、情報を集約する自動化ツールを作成したりする必要はありません。

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

フリートのセグメンテーション

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

Label-Key=region。Label-value = US-West, JP-North, JP-south
model-year=(2015, 2016, 2017, 2018)
function=(spray, weld)

サイトにタグを付けると、ユーザーはラベルのキーと値の条件を使用して「仮想サイト」を定義できます。たとえば、マルチクラウド環境では、サイトにdev、pre-prod、prodなどのタグを付けることができます。次の図3は、前述のラベルのキーと値を使用したロボティクスのユースケース例を示しています。

図3

以下は、blend/go-sdk構文を使用してVolterra上に仮想サイトを作成するための設定スニペットです。この例では、各サイトにラベルキーves.io/countryとラベル値ves-io-jpnが付与されています。

図4

ユーザーは、あらかじめフリートのセグメントを定義し、プロビジョニング時にサイトへタグを付けてフリートに含める運用モデルに慣れています。仮想サイトは、この既存の運用モデルに自然に適合します。新しいサイトを適切なタグでプロビジョニングすると、追加の手動操作を行わなくても、事前に定義した仮想サイトに自動的に追加されます。さらに、Volterraは、ハードウェアメーカーやパブリッククラウドの種類など、プロビジョニング前の情報を検出し、システムタグを事前設定します。ユーザーは必要に応じて、自動検出されたこれらのタグを使用して仮想サイトを定義できます。

フリート構成

フリート構成機能について、以下の3つの例を用いて説明します。

ネットワーク／セキュリティポリシーの設定 -- 例として、各クラスターが特定のURL（例：github.com）と通信できることを要件とする新しいサービスを導入するケースを考えます。通常、ユーザーはホワイトリスト方式を採用し、クラスターからのアクセス先を特定の宛先のみに制限します。そのため、この新しいサービスを導入するには、各クラスターでネットワークポリシーを変更し、github.com をホワイトリストに追加する必要があります。さらに、すべてのサイトに導入する前に、いくつかのテストサイトで検証したいと考えています。Volterraでこれを実現するには、まずVolterra SaaSコンソールで、フリートの一部を選択する「test」仮想サイトを定義します。次に、ホワイトリストに登録するURLのリスト（この例ではgithub.com）などのネットワークポリシーを定義し、「test」仮想サイトに適用します。Volterraの分散コントロールプレーンは、上記で定義した仮想サイトによって選択された各サイトのローカルコントロールプレーンに、ネットワークポリシーを送信します。各サイトのローカルコントロールプレーンはネットワークポリシーを適用し、サイトごとに各ルールが適用された回数の統計情報を収集します。サービスが想定どおりに動作していることを確認したら、フリート内の残りのサイトを選択する「prod」仮想サイトにネットワークポリシーを適用できます。以下に、JSONを使用した設定スニペットと、VolterraシステムのUIを使用した設定例を示します。

図5

図6

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

図7

フリート全体へのアプリケーションのデプロイ — Volterraは、Virtual Kubernetes（vK8s）というオブジェクトを提供しています。これにより、ユーザーはKubernetes APIを使用して、フリート全体のアプリケーションを管理できます。ユーザーは、デプロイメントマニフェストファイルを用いて、標準的なKubernetesの方法（KubeconfigファイルおよびKubernetes API）でアプリケーションをデプロイし、デプロイ先となるサイトのセグメント（またはフリート全体）を指定します。その後、VolterraのVirtual Kubernetes（vK8s）が、フリート内または指定したセグメント内の各サイトへのアプリケーションのデプロイを担います。接続障害やインフラストラクチャ障害など、アプリケーションのデプロイ中に障害が発生した場合、Volterra Virtual Kubernetesは、結果整合性モデルというKubernetesのパラダイムに従ってデプロイを再試行し続けます。次のスクリーンショットは、ユーザーが「kuard」というアプリケーション（Kubernetes-up-and-running-demo-appを参照）を、フリート内の140サイトを選択する「jpn-all-sites」という仮想サイトにデプロイする例を示しています。新しいデプロイメントを追加するには、［Add Deployment］をクリックし、仮想サイトとしてデプロイ先を指定するだけです。

図8

適切なラベルを付けて新しいサイトをフリートに追加すると、そのサイトは仮想サイト（この例ではjpn-all-sites）に自動的に追加され、フリート構成（この例ではKuardデプロイメント）が新しく追加されたサイトに自動的に適用されます。これにより、運用チームの負担が軽減され、人為的ミスを排除できます。

フリートの可観測性

Virtual sitesとVirtual Kubernetes（vK8s）は、構成だけでなく、フリート内の分散サイト全体の健全性を集約するためにも使用されます。他のソリューションでは、各サイトから個別にステータスを取得して情報を集約するツールをユーザー自身が作成する必要がありますが、本機能はそれに比べて非常に強力です。システムは、すべてのサイトの健全性ステータスを単一画面に自動的に集約し、運用チームの運用上の複雑さを軽減します。収集される健全性ステータスには、アプリケーションのデプロイ状況、サイトの健全性、アプリケーションの健全性など、さまざまな項目が含まれます。

次のスクリーンショットに示すように、ユーザーはすべてのサイトの健全性を地図上ですばやく確認できます。色は健全性スコアを示し、75を超える場合は緑、40～75の場合はオレンジ、40未満の場合は赤で表示されます。健全性スコアは、接続性、信頼性、セキュリティ、パフォーマンス（リソース消費量）を集約したスコアです。

図9

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

図10

図11

次に、サイト間のCPUおよびメモリ負荷の分布から、すべてのサイトを横断した集約情報を確認できます。この情報は、IT管理者やサイト管理者が、使用率が高く、リソースが枯渇するおそれのあるサイトを特定する際に役立ちます。サイト管理者は、リソース消費量がしきい値を超えた場合に通知を受け取るよう、アラートを設定できます。このスクリーンショットでは、半数のサイトが使用可能なメモリの75%を超えて消費していることがわかります。この情報を得るために、個々のサイトをクリックしたり、追加のツールを作成したりする必要はありません。