Cloud FoundryとKubernetesの組み合わせの過去と未来：統合は市場開発のトレンド

過去数年間、クラウド コンピューティング分野のオープン ソース コミュニティで最も議論を呼んだトピックは、Cloud Foundry と Kubernetes の関係でした。誰もが抱く疑問は、「それらは互いに置き換わるものか？」「それらは相互に排他的なものか？」「あるいは統合できるか？」という 3 つの問題に集中しています。現在の商用製品を見ると、両者の接続や統合はほとんどなく、どちらもさまざまな IaaS 上で実行できます。

当社は長年にわたり、従来のBOSH CPIから現在のコンテナ化されたCloud Foundryに至るまで、Cloud Foundryのデプロイメント関連の作業に携わってきました。この期間中、私たちは、両方の利点を最大限に引き出し、開発者のエクスペリエンスを向上させることを目指して、実現可能性分析、ベストプラクティス、エクスペリエンスの概要、価値の重要性など、両者を組み合わせたさまざまな技術的オプションを検討しました。

この記事では、Cloud Foundry の導入の観点から、業界と私たちが 2 つのシステムをどのように統合するかを紹介します。もちろん、どのような統合計画にも長所と短所があり、すべての統合はまだ急速な開発段階にあるため、ここでは将来の仕事や勉強に役立つアイデアをいくつか紹介したいと思います。

Cloud Foundry と Kubernetes の紹介

クラウドファウンドリ

Cloud Foundry は、クラウドに依存しない Platform as a Service ソリューションであり、業界で最も成功している PaaS プラットフォームです。 Cloud Foundry は、アプリケーションの実行、拡張、保守を容易にし、高速で便利な開発者エクスペリエンスを実現する環境を提供します。 Cloud Foundry は、Java、NodeJS、Ruby、Python など、ほとんどの言語と環境をサポートしています。

オープンソースの Cloud Foundry は、Pivo​​tal、IBM、VMware などを含む Cloud Foundry Foundation によって開発およびサポートされています。 IBM Bluemix や Pivotal Cloud Foundry などの Cloud Foundry の商用バージョンは、オープンソースの Cloud Foundry プロジェクトに基づいており、その上にエンタープライズ グレードのサポートを提供します。

クベネフィット

Kubernetes は、Google の Borg プロジェクトから派生したオープンソースのクラウド プラットフォームです。これは、AWS、Azure、Intel、IBM、RedHat、Pivo​​tal などの多くの業界大手やその他多くの企業を含むメンバーである Cloud Native Computing Foundation によって開始されました。

Kubernetes の主な機能は、コンテナ オーケストレーションとコンテナ ライフサイクル管理です。これに限定されるわけではありませんが、Docker コンテナを実行するために使用されることが多く、コンテナ サービス上に構築したいアプリケーション開発者やサービス開発者など、対象範囲は広くなります。 IBM の Container Service や RedHat の OpenShift など、Kubernetes をベースにした PaaS エクスペリエンスを提供するソリューションがいくつかあります。

2つのプラットフォームの比較

どちらのプラットフォームも成熟しており、完成しており、継続的な開発と改善により、2 つのプラットフォーム間の類似点と相違点もそれに応じて変化します。もちろん、コンテナ化、名前空間、認証メカニズムなど、2 つのプロジェクトには多くの類似点があります。どちらにもそれぞれ利点があります:

Cloud Foundry の利点は次のとおりです。

• 成熟した認証システムUAA、ユーザーグループ、マルチテナントのサポート
• 便利で高速なCFプッシュ
• 内蔵負荷分散ルーター
• 強力なログとメトリックの統合
• 成熟したデプロイメントツールBOSH

Kubernetes の利点は次のとおりです。

• 多数のコミュニティとサードパーティのサポートにより、強力なスケーラビリティを実現
• 完全なコンテナライフサイクルと自動スケーリング管理
• 便利で高速なコンテナ化アプリケーションの展開
• 優れた多様な永続層のサポート
• 複数のオープンソースUIのサポート

両者の現在の関係と統合

上記の比較から、2 つのプラットフォームにはそれぞれ独自の利点と強みがあることがわかります。そのため、業界の多くのメーカーは、両者を統合してメリットを最大化したいと考えています。今後、これら 2 つを統合するには、主に次の 3 つの方法があります。

Kubernetes の CPI

BOSH が Cloud Foundry の公式デプロイメント ツールであることはわかっています。これは、大規模な分散システムの展開とライフサイクル管理のためのオープンソース ツールです。ただし、BOSH は Cloud Foundry のデプロイに限定されず、要件を満たすリリースを提供している限り、他の分散システムにも適用できます。 CPI は Cloud Provider Interface の略です。これは、BOSH が IaaS と通信して仮想マシン インスタンスとテンプレートを作成および管理するために使用する API インターフェイスです。 CPI は現在、Amazon の AWS、Microsoft の Azure、IBM の SoftLayer などの IaaS プラットフォームをサポートしています。中国の Alibaba Cloud も CPI サポートを提供しています。 BOSH のメイン コントローラー Director は、CPI を介して基盤となる IaaS レイヤーと対話し、次の図に示すように、BOSH manifest.yaml ファイルで定義されたタスクとコンポーネントを IaaS レイヤーの VM にデプロイします。

したがって、最初の統合は、Kubernetes CPI のセットを開発し、BOSH と manifest.yaml 構成を通じて Cloud Foundry を Kubernetes にデプロイすることです。現在、IBM や SAP などの大手メーカーが対応する Kubernetes CPI を開発しており、GitHub で検索できます。個人的には、この方法は使いやすいものの、Kubernetes を IaaS の観点から見ており、下層は依然として BOSH を通じて管理されているため、Kubernetes プラットフォームの利点を十分に発揮できていないと思います。

Cloud Foundry コンテナ ランタイム (CFCR)

2017 年末、Cloud Foundry Foundation は、Pivo​​tal と Google が寄贈した Kubo プロジェクトの名前を CFCR (Cloud Foundry Container Runtime) に変更すると発表しました。一般的に、BOSH は Cloud Foundry と Kubernetes をデプロイするために使用され、Application Runtime は Cloud Foundry のアプリケーション サービスを管理するために使用されます。 Container Runtime は、データベースや監視など、Cloud Foundry にデプロイできない一部のサービスなど、Kubernetes の Container Service を管理するために使用されます。次に、以下に示すように、Open Service Broker を介して 2 つを接続します。

Cloud Foundry のコンテナ化

すべての Cloud Foundry コンポーネントをコンテナ化し、Kubernetes にデプロイすることは、比較的新しい統合方法です。現在、SUSE、IBM、SAP などの大手メーカーがこの作業を行っています。核となるのは、Cloud Foundry の BOSH Release を Docker イメージに変換し、Kubernetes デプロイメント ツール Helm を使用して、より自然に Cloud Foundry を Kubernetes 上にデプロイすることです。 BOSH Cli は、Cloud Foundry コンポーネントの Docker イメージを生成するときに BOSH リリースを変換するためにのみ必要です。 BOSH は、デプロイメントおよびデプロイメント後の管理には必要ありません。代わりに、Kubernetes は、すべての Cloud Foundry コンポーネントの Pod、サービス、および対応する構成リソースのライフサイクルを管理するために使用されます。これにより、開発者は Kubernetes の強力な管理機能と拡張機能を活用しながら、Cloud Foundry がもたらす優れた開発エクスペリエンスを享受できます。

IBMの取り組みと、その2つを組み合わせた成果

IBM は主に SUSE と協力して、上記の 3 番目のソリューションに基づいて IBM Cloud に迅速に導入できるエンタープライズ レベルの Cloud Foundry を作成しています。新しいサービスは IBM Cloud Foundry Enterprise Environment (CFEE) と呼ばれ、その主なコンポーネントは次のとおりです。

• まず、SUSE の変換ツール Fissile を使用して BOSH リリースをコンパイルし、CF コンポーネントの対応する Docker イメージにする必要があります。
• その後、Fissile を使用して、プリセット パラメーターを Helm または Kubernetes 構成リソース ファイルに変換する必要があります。
• IBM Cloud の強力なサービス リソースを活用して、データベース サービス、セキュリティー サービス、負荷分散サービスなどのエンタープライズ レベルのサービスに対するサポートを追加します。
• ***IBM CF の新バージョンのリリースにより、ユーザーは IBM Cloud Catalog で CFEE 環境を直接検索し、自動的にデプロイできるようになります。

従来の BOSH CPI デプロイメント方法と比較すると、新しい Cloud Foundry バージョンがリリースされた後、管理者はビルド タスクを 1 回実行するだけで、新しいバージョンの Docker イメージと Helm 構成が作成され、再利用できるようになります。この Cloud Foundry のデプロイ方法は 15 ～ 20 分程度かかりますが、これは 4 ～ 6 時間かかっていた以前の BOSH デプロイよりもはるかに高速です。

IBM は、2018 年前半の Cloud Foundry Summit で実験バージョンをリリースしました。

2018 年 10 月初旬、IBM は主にエンタープライズ顧客に優れたサービスとより大きな価値を提供することを目的として、CFEE の GA バージョンをリリースしました。デプロイされた CFEE 環境は他の環境から分離されているだけでなく、CFEE 環境にデプロイされた Cloud Foundry アプリケーションは、AI、ビッグデータ、IoT、ブロックチェーンなど、IBM Cloud 上の豊富なサービス リソースを簡単に使用できます。

関心のあるユーザーは、IBM Cloud Catalog を通じて CFEE の紹介を見つけることができます。

https://console.bluemix.net/do... しています。

展開ページでは、ユーザーは CFEE ドメイン名、Diego セルの数、CF バージョンなどの情報を設定できます。その後、CFEE は完全に自動化されたワンクリック展開を実装できます。約 1 時間で、エンタープライズ レベルの CF 環境が正常に展開されます。

もちろん、展開が完了した後も、CFEE は強力な管理、監視、およびコマンド ライン機能を提供します。図に示すように、ユーザーはページ上で Cloud Foundry とアプリケーションの使用状況を簡単に確認したり、対応するリソースを作成したり、IBM の外部サービスをバインドしたりすることができます。

両者の融合による今後の発展方向

もちろん、この 2 つの組み合わせの探求はここで終わるわけではありません。現在、ますます多くのメーカーや開発者が、この 2 つの統合に関する研究に参加しています。その中でも、IBM が主導する Cloud Foundry インキュベーション プロジェクトである Eirini は人気があります。そのアイデアは、Cloud Foundry の Diego セル コンテナ Garden を Kubernetes コンテナに置き換えて、2 つをより密接に接続することです。

SUSE が主導する Fissile プロジェクトもあります。将来的には、BOSH コマンドを通じて CF の Docker イメージと Helm 構成を直接生成し、コミュニティとの統合を強化する予定です。

要約する

要約すると、Kubernetes は Cloud Foundry にとって挑戦でも競争でもありません。 Cloud Foundry は、これとより適切に統合されることを望んでいます。 Cloud Foundry Foundation のエグゼクティブ ディレクターである Abby Kearns 氏は、次のように述べています。「Cloud Foundry は構造化された PaaS プラットフォームですが、他のプラットフォームは構造化されていません。ユーザーのニーズは多様です。それらをコンテナ化する必要はありませんが、プラットフォームがよりオープンになり、より多くのタイプをサポートできるようになることを期待しています。」

今後両者がどのように発展していくにせよ、その組み合わせは間違いなく市場のトレンドに適応し、ユーザーに多面的な価値向上をもたらすでしょう。二人は今後どんな火花を散らすのでしょうか？待って見てみましょう！