分散型Kubernetes PaaS向けコントロールプレーン

F5エコシステム | 2019年11月15日

本ブログは、F5がSaaSサービスを構築・運用するまでのさまざまな取り組みを紹介するブログシリーズの第1回です。

分散型Kubernetes PaaSのコントロールプレーン
分散アプリケーション向けグローバルサービスメッシュ
分散インフラ、アプリ、データのためのプラットフォームセキュリティ
分散クラスターのアプリケーションおよびネットワークセキュリティ
グローバルに分散したプラットフォーム全体のオブザーバビリティ
グローバルに分散したプラットフォームの運用とSRE
分散マイクロサービス向けGolangサービスフレームワーク

F5の以前のブログでご紹介したように、お客さまは、スマートマニュファクチャリング、公共安全のための映像フォレンジック、アルゴリズム取引、通信事業者向け5Gネットワークなど、複雑かつ多様なビジネスソリューションを構築しています。そのためF5は、これらのアプリケーションとそのエンドユーザーに、常時稼働し、接続性と信頼性に優れたエクスペリエンスを提供する必要があります。

これらのアプリケーションは、複数のクラウドプロバイダーやお客さまのエッジロケーションにまたがる複数のクラスターで稼働する可能性があるため、F5のプラットフォームチームは、複数のマルチテナントKubernetesクラスターをデプロイし、セキュリティを確保して運用するための分散コントロールプレーンとPaaSサービスを構築する必要がありました。この分散コントロールプレーンは、運用、スケーリング、パフォーマンスの面で多くのメリットをもたらしています。これらについては、プレゼンテーション（動画リンク）で取り上げます。たとえば、GitOpsを使用して数千のエッジK8sクラスターを管理する方法などです。また、今後数週間以内に別のブログ記事でもご紹介します。

要約

クラウドプロバイダー、プライベートクラウド、または複数のエッジロケーションに分散する複数のアプリケーションクラスターについて、導入、セキュリティ確保、運用の課題を解決でき、かつ使いやすいソリューションは市場に見当たりませんでした。
分散クラスターに必要なセキュリティおよび運用サービスを包括的に提供する、堅牢なKubernetesディストリビューションやPaaS（OpenShift、Cloud Foundryなど）は見つかりませんでした。必要なサービスには、PKIベースのアイデンティティ、RBACとユーザーアクセス管理、クラウドプロバイダー間のシークレットおよび鍵の管理、マルチクラスターサービスメッシュ、オブザーバビリティと監査ログ、アプリケーションおよびネットワークのセキュリティなどがあります。
Anthos（Google）、Azure Arc（Microsoft）、Rancherは、複数の異なるサービスをパッケージ化したマルチクラスター管理基盤です。分析の結果、これらでは、複数のクラスターにまたがるアプリケーションおよびインフラストラクチャサービスに求められる運用、スケーリング、セキュリティ、マルチテナンシーの要件を満たせなかったと判断しました。
Kubernetes上に構築したマネージドPaaS向けに、独自の分散コントロールプレーンを構築する必要がありました。標準のKubernetesから着手し、DevOpsチームとSREチームが必要とするプラットフォームサービスを提供するために、大幅な変更を加えました。さらに、多数の分散クラスターを管理し、異種インフラストラクチャ（エッジ、自社ネットワーク、複数のクラウドプロバイダー）全体でマルチテナンシーを実現するためのコントロールプレーンも構築する必要がありました。

アプリ管理にKubernetesを活用する理由と方法

分散アプリケーションを管理するプラットフォームの中核として、Kubernetes（K8s）を採用しました。Kubernetesは、特定の方法を過度に強制することなく豊富な機能を提供するため、お客さまにとって重要だと考える領域で柔軟にイノベーションを進められます。これを基盤としてサービスの構築を開始しました。また、K8sの普及に伴い、K8sに精通した開発者や運用担当者も見つけやすくなっています。

とはいえ、ハイブリッド環境（複数のクラウド、ネットワークPOP、エッジロケーション）全体にわたって多数の本番環境向けKubernetesクラスターをデプロイし、管理するのは容易ではありません。Kubernetesには、以下を実現できる標準搭載のソリューションがないためです。

クラスタリング、スケーリング、ゼロタッチプロビジョニングを自動化し、異種インフラストラクチャリソースを統合すること。これは特に、エッジや当社のネットワークPoPで大きな課題でした
分散した拠点間で高性能かつ信頼性の高い接続を実現する。特に、クラウドプロバイダーをまたぐ場合や、エッジ拠点から接続する場合に重要です
転送中および保存中のデータ、シークレット、鍵、ネットワークに関するセキュリティ課題を解決します。これらはすべて、エッジ、ネットワーク、クラウド全体で機能する統一されたPKIアイデンティティによって支えられます
真のマルチテナンシー（テナントの分離とセキュリティ保証）を実現し、社内および顧客向けの本番ワークロードと開発ワークロードを同じクラスター上で実行できるようにします
複雑なログおよびメトリクス収集の仕組みを構築することなく、一元管理されたポリシーと意図に連携する、分散クラスター全体の可観測性と運用機能を提供する

複数のクラウドプロバイダーに加え、GKE、AKS、EKS、RKE、OpenShift、Cloud Foundryなどのオープンソースプラットフォームを使用して概念実証を重ねた結果、上記5つの要件をすべて満たせるものはないことが分かりました。そこで、「バニラ」Kubernetesをベースに、アイデンティティ、ネットワーキング、セキュリティ、マルチテナンシー、ロギング、メトリクスなどの機能を追加し、独自のPaaSを構築することにしました。Kubernetesは社内のニーズを満たすために使用していますが、社内ユーザーやお客さまがワークロードを実行できるよう、これらのKubernetesクラスターを直接公開しないなど、難しい決断も必要でした（マルチテナンシーは重要な目標の1つであったため、この点については後ほど詳しく説明します）。

追加が必要だった複数の新機能に加え、エッジ、F5のネットワーク、パブリック／プライベートクラウドにまたがる多数の拠点で、F5のワークロード／サービスをお客さまのワークロードと並行して実行する必要もありました。そのため、複数の環境にある複数のクラスターを管理するための機能を追加で構築する必要がありました。これらのクラスターはすべて、F5のグローバルネットワークと分散アプリケーションゲートウェイを使用して接続され、クラスター間でゼロトラスト接続とアプリケーションレベルの接続を提供します。

難所：Kubernetesのマルチテナンシーとマルチクラスター

単一のKubernetesクラスターで稼働するアプリケーションの構築と運用は、クラウドプロバイダーが管理するクラスターを利用する場合でも、決して容易ではありません。そのため、DevOpsチームやSREチームは、運用負荷を最小限に抑え、多数のクラスターに伴う複雑さを避ける傾向があります。1つの大規模なKubernetesクラスターを構築し、あらゆる種類のリソースを同じクラスターに配置するケースも珍しくありません。運用を簡素化し、コンピューティング効率を最大限に高めながらコストを抑えてクラスターを運用できるため、一見すると優れた方法に思えます。しかし、いくつかの理由から、これは最善の方法ではありません。まず、本番環境のワークロードに求められる要件は、開発・テスト環境やステージング環境とは大きく異なります。不安定な開発ワークロードが、より安定した本番ワークロードに問題を引き起こす可能性があります。

多様なワークロードの要件に加え、K8sのセキュリティと分離に関する制約も、マルチクラスター化を促す要因の1つです。K8sのセキュリティとリソース分離の課題に対処する一般的な方法は、マルチテナントモデルを採用し、テナントごとに独立したクラスターを立ち上げることです。クラウドでは実現可能な場合もありますが、エッジで複数のクラスターを運用することはできません。エッジサイトではコンピューティングリソースとストレージリソースに制約があるほか、クラスターを追加するたびにログやメトリクスを中央のクラウドへ送信するためのネットワーク帯域幅も限られています。

複数のKubernetesクラスターに関する課題に対処するため、Kubernetesクラスターを一元管理するRancher（検討開始時点ではAnthosとAzure Arcはまだ存在していませんでした）とKubeFedを評価しました。当時利用できたアプローチは次の2つで、現在も状況は変わっていません。

中央コンソールからマルチクラスタ管理（Rancherなど）を行うことで、任意の場所に複数のクラスタをデプロイし、アップグレードやロールバックなどのライフサイクル管理操作を実行できるようになります。また、一部のシステムでは、構成やアプリケーションのデプロイを自動化し、個々のクラスタを操作することも可能でした。
もう1つのアプローチは、Kubernetesクラスターフェデレーション（KubeFed）のコントロールプレーンをデプロイすることです。これにより、複数の物理クラスターを1つのクラスターのように扱えます。検討当時、このプロジェクトは始まったばかりで、現在でもアルファ段階にとどまっています。

GCP AnthosとAzure Arcが最近発表されたことを受け、分散コントロールプレーンを構築するという当初の決定を再評価しました。その結果、これら2つの新しいサービスでも、分散クラスターに関する2つの重大な問題は解決できなかったと判断しました。私たちのプラットフォームに必要だった2つの主要な機能は、次のとおりです。

複数のクラスターを1つのフリートとして管理し、すべてのクラスターまたは論理的にグループ化されたクラスターを対象に、構成、デプロイ、メトリクスなどの運用を行う際の課題を解決すること。これは、SREチームの運用負荷を軽減し、DevOpsにおけるデバッグのしやすさとシステムのスケーラビリティを向上させるうえで不可欠です。
物理クラスターを新たに立ち上げることなく、単一の物理Kubernetesクラスターを分割してマルチテナンシーに対応できる機能。これは、マルチテナンシーのためだけに物理クラスターを追加したくない、リソースに制約のある環境では特に重要です

この2つの問題を解決するには、「複数」クラスターの運用オーバーヘッドを軽減し、リソースに制約のある環境でもマルチテナンシー向けに「複数クラスター」に相当する機能を提供できる、新たな手法である分散コントロールプレーンを考案する必要がありました。

分散コントロールプレーン：マルチクラスターKubernetesを実現した方法

プラットフォームチームは、チームが利用するKubernetes APIを公開する、Kubernetes向けの分散コントロールプレーンを構築することにしました。ただし、これらのAPIは、コントロールプレーン内にのみ存在する「仮想」クラスター、つまり仮想K8sクラスター用の仮想K8s（vK8s）APIサーバーから提供されます（図1を参照）。このコントロールプレーンは、ユーザーの意図を、エッジ、ネットワークPOP、パブリッククラウド環境で稼働する複数の物理Kubernetesクラスターに反映します。これらの物理クラスターにアクセスできるのは分散コントロールプレーンのみで、個々のテナントやユーザーはアクセスできません。

図1：分散コントロールプレーン

このコントロールプレーンは、各テナントに1つ以上の「仮想」アプリケーションクラスターを提供します。テナントはそこにアプリケーションをデプロイでき、コントロールプレーンは構成に基づいて、複数の物理Kubernetesクラスターにわたってアプリケーションを複製、管理します。構成やデプロイだけでなく、監視もこの「仮想」クラスターに追従するため、複数の物理クラスターからデータを収集して分析するツールを構築する必要はありません。

productpageというサンプルUIアプリケーションを例に説明します。このアプリケーションをpa2-par、ny8-nyc、ams9-amsの3拠点に分散し、各拠点で2つのレプリカを実行することを想定します。ユーザーがvK8sオブジェクトを作成して仮想クラスターにアタッチすると、標準のkubectlで使用できるvK8s APIサーバーが直ちにプロビジョニングされます。

次に、この仮想クラスターのkubeconfigをダウンロードし、productpageのK8sデプロイメントを記述する標準的なYAMLを作成します。

デプロイ仕様を作成したら、この仮想クラスター上にデプロイを作成できます。

ここでユーザーがデプロイメントを確認すると、6つのレプリカが起動しており、各ロケーション（pa2-par、ny8-nyc、ams9-ams）に2つずつ配置されていることがわかります。

次の出力は、各ロケーションで2つのPodが実行され、それぞれ特定の物理ノードにマッピングされていることを示しています

このシンプルな例は、インストールや管理の負担なく、わずか数分であらゆるアプリを複数のクラスターにレプリケートできることを示しています。分散コントロールプレーンは、意図をマッピングするだけでなく、個々のクラスター単位ではなく、仮想クラスター単位のオブザーバビリティも提供します。

マルチテナンシーに対応する分散制御と一元管理

As you can see in 図2に示すように、集中管理プレーンは2つのパブリッククラウドプロバイダー（各1リージョン）にまたがって稼働しています。1つはAWS、もう1つはAzureで、冗長性を確保しています。この管理プレーンにより、SREは厳格なマルチテナンシーを適用したテナントを作成できます。たとえば、VoltMeshサービスを担当する開発チームを1つのテナントとし、顧客向けPOCを担当するカスタマーソリューションチームを、独自のユーザーセットを持つ別のテナントとすることができます。

図2：マルチテナンシーとマルチクラスター

各テナントは複数の名前空間を作成し、それらの名前空間で共同作業を行うユーザーグループを割り当てることができます。これらはKubernetesの名前空間ではなく、ユーザー向けのRBACルールとIAMポリシーを備えた、F5のプラットフォーム内の分離境界です。

名前空間内のユーザーがアプリケーションクラスターを作成する場合、vK8sオブジェクトを作成します。これにより、管理プレーンにvK8s APIサーバーが作成されます。ユーザーはこのvK8sオブジェクトを使用して、Deployment、StatefulSet、PVCなどを作成できます。コントロールプレーンは、vK8sオブジェクトに関連付けられたサイトに基づき、これらの操作が1つまたは複数の物理クラスターで実行されるようにします。

各テナントとユーザーは標準のK8s操作を変更せずに使用するため、システムはSpinnaker、Helm、Jenkinsなど、運用担当者に広く利用されているさまざまなツールと互換性を確保できます。

分散コントロールプレーンによって得られるメリット

分散型コントロールプレーンの大きな利点は、SREチームとDevOpsチームの運用負荷を解消したことです。両チームは仮想クラスター全体で構成、デプロイ、監視、ポリシーなどの操作を実行でき、コントロールプレーンが複数の物理クラスターに自動的にマッピングします。複数クラスターの運用を簡素化するだけでなく、マルチテナンシーにおけるセキュリティと分離の問題も解決しました。

この分散コントロールプレーンにより、プラットフォームに新機能を追加する開発者の生産性も向上しました。複数のクラスターにまたがる構成や運用に影響する新機能を追加するたびに、新たな自動化を構築する必要はありません。開発者がインテントベースの構成モデルを使用すると、コントロールプレーンが必要な処理を判断します。さらに、この分散型マルチクラスターオブジェクトであるvirtual kubernetesを、別のCLIを新たに使うことなく、引き続きkubectlで操作できます。

これを開発・テスト環境、ステージング環境、本番環境で1年以上運用した結果、グローバルに分散されたこのコントロールプレーン（当社のネットワークPOPで稼働）には、スケーラビリティ、パフォーマンス、信頼性の面でも大きな利点があることが分かりました。これは、初期段階では十分に想定できていなかったことです。この知見については、近日開催予定のKubeConでのプレゼンテーションと、今後数週間以内に公開する別のブログ記事でご紹介します。