KubernetesベンダーとしてのVMwareは、少なくとも2つの顔を持っている：複数クラウドをどう統合するか（2/2 ページ）
VMwareはKubernetes関連市場で、少なくとも「Kubernetesディストリビューションベンダー」「Kubernetesの統合運用管理サービスベンダー」の2つの顔を持つベンダーとしての活動を本格的に開始した。VMwareのサーバ仮想化基盤を使わないユーザー組織にとっての、KubernetesベンダーとしてのVMwareを探る。
Cluster APIは、宣言的なAPIを通じた、Kubernetesクラスタのライフサイクル管理を実現する仕組みを整備する、KubernetesのCluster Lifecycle SIGにおけるプロジェクト。あるべき状態のKubernetesクラスタ構成をYAMLで記述し、これを指定してCluster APIを適用するだけで、望みの構成のクラスタが作成される。Kubernetesクラスタの作成に加え、アップデートやノードの追加・削除など、作成以降のライフサイクル全体をカバーできることが大きな特徴という。
Kubernetesプロジェクトを始めた後にHeptioを設立、買収に伴ってVMwareに移籍し、現在コンテナ関連の技術戦略に関わっているジョー・ベダ（Joe Beda）氏とクレイグ・マクラッキー（Craig McLuckie）氏は、同社のブログポストでCluster APIが大組織におけるKubernetes運用ニーズに応えると共に、マルチクラウドでの運用を容易にすると説明している。
ベダ氏は、セキュリティや運用安定性の観点から、小規模なKubernetesクラスタを多数立ち上げる傾向が強まっている。クラスタを容易に作成するやり方はあるが、可用性維持やアップグレードなどの後の運用が煩雑。現在のツールでは、こうした運用を大規模にやりにくいと説明。
Kubernetesクラスタのライフサイクル管理からユーザーを解放するため、パブリッククラウドでは、マネージドKubernetesサービスを提供している。だが、コントロールプレーンがオープンではないため、大組織にとっては使いにくい側面もあるという。
「システムはKubernetesに深く結びついており、コントロールプレーンにアクセスできないと、大組織として取り込みにくい。アドミッションコントローラーやAPIサーバのフラグを追加できず、重要なログイベントを取得できない。Kubernetesの利用者は、これを好ましいと思っていない」（マクラッキー氏）
マクラッキー氏は、VMware Tanzu Mission Controlを紹介した2019年8月のブログポストでも、次のように述べている。
「VMware Tanzuは複数のクラウドを駆使して（アプリケーションを）構築する開発者の世界に、APIドリブンなモデルを持ち込もうとしている。全てはKubernetesクラスタのプロビジョニングから始まる。私たちは、Kubernetesクラスタの作成と管理のための『簡単なボタン』を実現する、シンプルでクラウドフレンドリーなクラスタライフサイクル管理モデルを構築してきた」
マクラッキー氏は続けて、AWSの「Amazon Elastic Kubernetes Service（Amazon EKS）」、Microsoft Azureの「Azure Kubernetes Service（AKS）」 、Google Cloud Platformの「Google Kubernetes Engine（GKE）」といったパブリッククラウドのマネージドKubernetesサービスと、Cluster APIを通じた管理を対比させ、次のように説明した。
「クラウド事業者が提供するマネージドKubernetesサービス（AKS、EKS、GKE）に多少似ているように感じるだろうが、Kubernetesクラスタが開発者環境へ完全にプロビジョニングされており、開発者はこれに対して完全にアクセスできるという利点がある。このことで、クラウド事業者では実現が困難なレベルのカスタマイズ性と制御性を提供できるようになる」
ただし、Cluster API自体、本記事執筆時点では実験段階であり、Tanzu Kubernetes Grid Plusでも、これについて通常のサポートを提供していない。個々のインフラをCluster APIに連動させるための「Cluster API Provider」が、インフラ基盤ごとに開発されているが、まずはVMwareの顧客における主な利用シナリオに基づいて検証を進め、Cluster APIの機能改善および成熟を推進しようとしているようだ。
Cluster APIはKubernetesプロジェクトの一部であり、VMwareが独占できるものではない。同社は、オープンソースプロジェクトに貢献し、同時にこれを実装した自社製品に対する顧客のフィードバックを受け、コミュニティとして強化するサイクルを回しながら、自社商用製品の改善を続けるという、オープンソース製品ベンダーの“王道”をなぞろうとしている。
そして、KubernetesでCluster APIが当たり前の機能になれば、複数クラウドにまたがり、ベンダー非依存で多様なディストリビューションを統合管理することを目指すTanzu Mission Controlの価値が増してくるという考え方だ。
開発チームをスローダウンさせない統合管理を指向
Tanzu Mission Controlでは、Cluster APIを通じた容易なクラスタライフサイクル管理に加え、マネージドKubernetesサービスや、エンタープライズ向けKubernetesとして競合する存在の「RedHat OpenShift Container Platform」を含むあらゆるKubernetesクラスタをアタッチして、複数クラウドにまたがった統合管理ができることを特色としている。
「これは、クラウドサービス事業者からは得られないレベルの中立性で、VMwareならではのオープン性だ」と、マクラッキー氏は同ブログポストで述べている。
Tanzu Mission Control自体、マルチクラウド、ベンダー非依存のKubernetes統合管理をオープンソースツールで実現することをテーマとしている。今後は、同様な管理基盤を開発する、SAPのコントリビューションに基づいたオープンソースプロジェクト、Gardnerとの連携がクローズアップされてくる。
VMwareは、VMware Tanzu Mission Controlで実現している統合管理の具体的機能として、次を示している。
- 各クラスタの健康状態管理と障害の診断
- 統合的なユーザーアクセス管理
- セキュリティポリシーの構築と適用
- クラスタの構成管理
- 構成管理を目的としたクラスタの定期的スキャン
- Kubernetesおよび永続ボリュームを対象としたバックアップの統合管理
- リソース利用上限の適用とユーザー利用の可視化
ベダ氏とマクラッキー氏は、複数の拠点／プラットフォームに分散するKubernetesクラスタをまとめ上げ、これにAPI中心の運用管理フレームワークを適用することで、開発者のスピードを殺すことなく、開発者とプラットフォーム運用管理者の「いい関係」を作り上げていきたいとしている。
Copyright © ITmedia, Inc. All Rights Reserved.