Kubernetes ベースのマルチクラウドとハイブリッドクラウド

マルチクラウドとハイブリッドクラウドとは

Kubernetes とクラウド ネイティブの普及により、高可用性、高同時実行性、弾力的なバーストも多くのアプリケーションに必要な要件になりました。これらの機能を実現するには、アプリケーションをアベイラビリティゾーンやリージョンにまたがって展開するだけでなく、クラウド サービス プロバイダーの容量が不足したり障害が発生したりした場合に、他のクラウド サービス プロバイダーやハイブリッド クラウド環境に自動的に切り替える必要があります。さらに、多くの人は、すべてのサービスを単一のクラウド サービス プロバイダーに結び付けることを望んでいません。

マルチクラウドとハイブリッド クラウドとは、アプリケーションをローカル データ センターと複数のクラウド サービス プロバイダーに展開し、必要に応じてそれらの間で動的にスケジュールできることを意味します。マルチクラウドとハイブリッドクラウドの利点は次のとおりです。

• クラウド サービス プロバイダーのロックインを排除: 特定の地域の単一のクラウド サービス プロバイダーまたはデータ センターだけに依存する必要がなくなります。
• 可用性の保証: 地域間や地理的範囲をまたぐだけでなく、クラウド サービス プロバイダーに障害が発生した場合でも、アプリケーションは他のクラウド サービス プロバイダーで引き続き実行できます。
• コストの最適化: クラウド サービス プロバイダーの価格に基づいて低コストのソリューションを選択したり、競合他社のコストに基づいて交渉したりすることもできます。
• 弾性バースト保護: ローカルデータセンターまたはクラウドサービスプロバイダーの容量が不足している場合は、他のクラウドサービスプロバイダーに拡張できます。

しかし、マルチクラウドやハイブリッドクラウドの難しさも明らかです。最も顕著な結果は次のとおりです。

• クラウド間ネットワーク接続
• クラウド間のデータ一貫性
• 大量データへのアクセス遅延
• 一貫性のないマルチクラウドインターフェースによる管理の複雑さ

これらの問題を解決するために、Kubernetes が誕生する以前から、異種クラウド プラットフォーム リソースの問題に特に対処するクラウド管理プラットフォームが実際に数多く存在していました。これらのクラウド管理プラットフォームは、クラウド リソース管理、コスト最適化、さらにはアプリケーション DevOps などのさまざまな問題を解決しますが、一般的にアプリケーション オーケストレーションの実際の管理を担当しないため、多くの場所でマルチクラウド 1.0 とも呼ばれています。

Kubernetes がマルチクラウド 2.0 を生み出す

Kubernetes やコンテナ技術が登場する前は、マルチクラウドやハイブリッドクラウドを実現するのは非常に難しく、クラウドサービスプロバイダーごとにカスタマイズされた開発が必要でした。アプリケーションはクラウド サービス プロバイダーのインターフェイスにバインドされているため、クラウド サービス プロバイダーを移行するときには、インフラストラクチャからアプリケーションへの対応する適応も行う必要があります。これは、クラウドに移行するときに多くの人が遭遇する問題点ですが、クラウド管理プラットフォームを通じて解決できます。

ただし、現在のクラウド管理プラットフォームは、クラウド リソースの管理に重点を置いています。多くのクラウド管理プラットフォームもアプリケーション DevOps を提供していますが、実際にはアプリケーションをさまざまなクラウド プラットフォームに配布するだけで、アプリケーションのオーケストレーションは担当していません。たとえば、クラウド全体で高可用性と弾力的なバーストを実現するには、アプリケーションがさまざまなクラウド サービス プロバイダーのインターフェイスを呼び出す必要があります。

Kubernetes とコンテナを使用すると、ローカル データ センターとクラウド サービス プロバイダーの Kubernetes クラスターは一貫したインターフェイスを提供できるため、ほとんどの場合、アプリケーションを特定のクラウド サービス プロバイダーに直接バインドする必要がなくなります。 Kubernetes クラスターのみを考慮すると、クラウド管理プラットフォームは、マルチクラウド Kubernetes クラスター管理にさらに簡素化できます。 Kubernetes Operator モードを利用すると、多くの Kubernetes アプリケーションが依存するクラウド リソースを同じ CRD に抽象化できます。これにより、アプリケーションとクラウド サービス プロバイダーがさらに分離され、多くの人からマルチクラウド 2.0 と呼ばれています。

マルチクラウド Kubernetes の場合、理想的なシナリオは、同じ Kubernetes クラスターが複数のクラウド プラットフォームにまたがり、すべてのアプリケーションを同じ Kubernetes API を通じて管理することです。もちろん、この理想的な状況は、クラウド サービス プロバイダーの違い、ネットワーク遅延、データ ストレージ、Kubernetes 自体のスケール制限により現実的ではありません。

そのため、現在主流となっているアプローチは、異なるリージョンや異なるクラウド サービス プロバイダーで複数のクラスターを実行し、それらのクラスター上で複数のクラスターのアプリケーションを接続することです。たとえば、最も簡単な方法は、サービスのレプリカを複数のクラスターにデプロイし、Consul、Linkerd、またはグローバル DNS を使用して負荷分散することです。

次の図は、Google Cloud が推奨する最もシンプルなマルチクラスタ サービス検出ソリューションです。

マルチクラウドとハイブリッドクラウドのソリューションは何ですか?

クラウド管理プラットフォームはマルチクラウド インフラストラクチャの展開の問題を解決し、Kubernetes は実際にクラウド サービス プロバイダー全体の新しい標準になりました。当然のことながら、マルチクラウドの次のステップは、複数の異なる Kubernetes クラスターでアプリケーションを管理する方法であり、それぞれ独自の焦点を持つ多くのオープンソースまたは商用ソリューションが登場しました。

最初のソリューションは、エラスティックバーストの問題の解決に重点を置いており、その代表的な例が Virtual Kubelet です。ローカル クラスターの容量が不十分な場合は、他のクラウド サービス プロバイダーのコンテナー製品を仮想ノードとしてクラスターに接続し、アプリケーションを実行するための容量を増やすことができます。

2 番目のソリューションは、サービス ガバナンスとトラフィック スケジューリングの問題の解決に重点を置いており、その代表的な例がサービス メッシュです。異なるクラスターのネットワークは、サービス メッシュ (またはメッシュ フェデレーション) を介して接続することができ、これにより、ネットワーク トラフィックの柔軟なスケジュール設定とフェイルオーバーを実現できます。実際、複数のクラスターをトンネルや専用回線で接続し、複数のクラスター間のネットワーク通信の信頼性をさらに確保するアプリケーションも数多くあります。

3 番目のソリューションは、クラスター間リソースのサービス検出とオーケストレーションの問題の解決に重点を置いており、その代表的な例が Kubernetes Cluster Federation V2 です。 KubeFed は、Kubernetes の元のリソース オブジェクトの上にクラスター間 CRD を再パッケージ化します。コントローラーは、それらを異なるクラスターに配布し、ExternalDNS などのサービス検出メカニズムを通じて異なるクラスター内のアプリケーションを接続する役割を担います。

最初の 2 つのソリューションにはすでに多くの実践例があり、これらの実践により効果的なソリューションであることが証明されています。 3 番目の解決策はまだ初期の調査段階にあります。個人的には、あまり実用的ではなく、実際の適用シナリオからはまだ遠いと思います。複数のクラウド間のサービス ガバナンスを KubeFed やその他の CRD のみに依存するのでは十分ではありません。

現在、すべての主要なクラウド プラットフォームは、マネージド Kubernetes サービスを提供しています。クラスター作成プロセスを除けば、アプリケーションの観点からは、ほとんどの場合違いはありません。ユーザーはすべてのサービスを同じクラウド プロバイダーに固定したくないため、クラウド間の移行は多くのユーザーにとって悩みの種となっています。さらに、大企業では既存のアプリケーションとの接続に問題が発生するため、主流のクラウドサービスプロバイダーは、次のようなクロスクラウドおよびハイブリッドクラウドソリューションも提供しています。

• Microsoft Azure: アーク
• Google クラウド: Anthos
• AWS: アウトポスト
• VMware: Tanzu ミッション コントロール
• バンザイクラウドPKE
• アリババクラウドACK

不透明な未来

マルチクラウドはクラウド サービス プロバイダーのロックインの問題を解決できますが、これまでのソリューションからわかるように、これらのソリューションは実際には特定の問題のみを解決するものであり、マルチクラウドのすべての問題を解決する完璧なソリューションは存在しません。

さらに、マルチクラウドは、次のような多くの新たな問題ももたらします。

• マルチクラウドの管理とオーケストレーションは、単一クラウドの管理よりもはるかに複雑です。データの同期、ネットワークの遅延、セキュリティなどには大きな課題があります。
• リソースが増えるとインフラコストが上昇する
• クラウドインフラストラクチャの保守担当者には高い要件があり、複数のクラウドプラットフォームのインフラストラクチャ、特に避けるべき落とし穴に精通している必要があります。

まだ多くの問題が残っていますが、オープンソース コミュニティと主要なクラウド サービス プロバイダーは、すでにマルチクラウドとハイブリッド クラウドのさまざまな問題の解決に取り組んでいます。例えば

• Cilium Cluster Mesh や Istio Service Mesh などのネットワーク ソリューションは、すでに複数のクラスターをサポートしています。
• Linkerd コミュニティは、Kubernetes マルチクラスター シナリオをサポートする方法と、サービス ミラーリングを通じて Kubernetes マルチクラスターをサポートする方法を設計しています。
• Kubernetes コミュニティでは、マルチクラスター サービス API のサポートについても議論されています。

マルチクラウドとハイブリッドクラウドの将来は期待に値します。