2018年4月の「Cloud Foundry Summit 2018 in Boston」では、Kubernetes上でコンテナとしてCloud Foundryを動かすCloud Foundry on Kubernetesについて、2つの大きな動きがあった。
IBMはCloud Foundry on Kubernetesのマネージドサービス、「IBM Cloud Foundry Enterprise Environment 」を発表。SUSEは同社のソフトウェア「SUSE Cloud Application Platform」が、Cloud Foundry FoundationからCloud Foundry Application Runtimeディストリビューションとしての認定を受けたと発表した。
ただし、いずれもまだ、本格提供には至っていない。
一方、SUSE Cloud Application Platformは2018年1月に限定顧客を対象としてリリース。2018年4月にはバージョン1.1を提供開始した。少数顧客との協業を通じ、良好な利用体験が得られるよう、取り組みを続けるという。今後数カ月にわたって、対象を拡大していくとする。
「Cloud FoundryはPaaS、KubernetesはIaaS+」
では、この2社はなぜCloud Foundry on Kubernetesを推進するのか。
IBMのリードIBM Cloud Foundryアーキテクトであるサイモン・モーザー（Simon Moser）氏は、ブログポストで次のように述べている。
「（Cloud FoundryとKubernetesは、）コンテナランタイムを動かすという点で非常に大きなオーバーラップがある。そして、この2つのコンテナランタイムの実装方法は異なっている（最終的にはrunc/containerdをベースとすることにはなるが）。（中略）だが一方で、k8s（訳注：Kubernetesのこと）の開発者にとっての使い勝手はとても貧弱だ。一般的にk8sは、『PaaS』というより『IaaS+』と考えられている」
KubernetesとCloud Foundryは抽象度の違いにより、管理者にとっての使い勝手が異なる（出典：モーザー氏のTHINK 2018における講演資料）
「では、k8sがPaaSというよりも『IaaS+』に近いのなら、CF（訳注：Cloud Foundryのこと）をk8s上で動かせるのではないか？ CFの特徴の1つは特定の『IaaS』に縛られないことだ。だからできるはずではないか？ そこでわれわれは試してみた」
モーザー氏たちは、まずCloud Foundryでプロビジョニング／ライフサイクル管理ツールとして使われているBOSHを用い、KubernetesをIaaSに見立ててKubernetesプロバイダーインタフェースを書いたという。だが、Kubernetesはサーバ仮想化などのIaaSに比べて「インテリジェント」であるため、うまくいかなかったという。
そこでSUSEが開発したfissileおよびSUSE Cloud Foundryに目を付け、これらを使ってCloud Foundry on Kubernetesを構築したという。
一方、SUSEのプロダクト＆テクノロジープログラム担当バイスプレジデント、ジェラルド・ファイファー（Gerald Pfeifer）氏は、筆者のメールによる質問に、次のように返答している。
「コンテナを動かし、管理するオペレーションタスクに関しては、Kubernetesがリーダーであり、市場に選ばれた存在だといえる。しかし、アプリケーション構築のための開発者にとってのワークフロー機能だ。（一方、）Cloud Foundryはコンテナベースのアプリケーションをパッケージングしてデプロイするための開発者のためのワークフローという点でリーダーであり、数々の企業においてもこれは実証されている。しかし、（Cloud Foundryは）これまで、今日広く普及しているKukbernetesプラットフォームを、オペレーションで活用してこなかった。SUSEがCloud Application Platformを開発したのはそのためだ」
「アプリケーションのパッケージングおよびデプロイメントについては、Cloud Foundryの非常に効率的なワークフローを手に入れられ、実際には今日のITプロフェッショナルの多くが動かすことを前提としているKubernetesプラットフォーム上に、デプロイできることになる」
ファイファー氏は、このアーキテクチャが、Cloud Foundryユーザーにとって、2つのメリットをもたらすと答えた。
第1に、Cloud Foundryをコンテナ化するため、物理マシンや仮想マシン上にCloud Foundryを直接導入するのに比べ、フットプリントを小さく抑えられる。
「従って、他のディストリビューションではコストがかかり過ぎて導入に至らなかったような、新しい層のユーザーにとって、手が届くようになる」
関連して指摘できるのは、SUSEがCloud Application Platformで、パブリッククラウドの多様なKubernetesマネージドサービスへの対応を進めていることだ。バージョン1.1ではMicrosoft Azureの「Azure Container Service」をサポートした。こうして多くのパブリッククラウドが提供している各種のKubernetesマネージドサービス上で、Cloud Foundryを「気軽に」使える環境が整ってくると考えられる。
第2にファイファー氏が指摘するのは、BOSHを使わなくて済むということだ。
「BOSHはパワフルだが複雑な技術」だとファイファー氏は述べている。KubernetesにCloud Foundryの管理を任せれば、Kubernetesに慣れた運用担当者が、これに加えてCloud Foundryを動かすだけのために、BOSHを設定し、管理する必要がなくなる。
「既存のKubernetes環境上で、Cloud Foundryのもたらす開発体験を、かなり容易に追加できることになる」（ファイファー氏）
つまり、開発者にとっては、「cf push」に象徴されるアプリケーション投入の容易さを提供するためにCloud Foundryを利用することが望ましい。そこで、Cloud Foundry on Kubernetesにより、Kubernetesユーザーである運用担当者にとってのCloud Foundryの導入、運用作業を簡単にすることで、この開発者にとって望ましい環境を、従来よりも提供しやすくできるのだという。
なぜ、Cloud FoundryとKubernetesを横に並べて使うよりもいいのか
Cloud FoundryプロジェクトおよびPivotalは、BOSHによる管理を通じ、Cloud FoundryとKuberenetesを横に並べて運用する環境を整備する取り組みを進めてきた。
では、Cloud Foundry on Kubernetesは、なぜCloud FoundryとKubernetesを横に並べて使うよりも優れているのか。ファイファー氏にあらためて聞いてみた。答えは次の通りだ。
「横に並べることで、顧客はCloud FoundryとKubernetesのどちらも利用できる。これは良いニュースだ。しかし、このアプローチには不要なオーバーヘッドがある。横に並べて動かすと、2つの独立した環境を管理しなければならないことになる。結局のところ、Cloud Foundryが得意なのは、開発体験の部分だ。一方運用面に関しては、アプリケーションを稼働するという点で、KuberenetesがCloud Foundryのインフラと完璧に競合し得る状況になっている」
「Cloud Foundryの運用基盤としてKubernetesを利用することで、双方の『いいところ取り』ができる。Kuberentesは既に多くの企業で採用されている運用基盤だ。Cloud Foundryは、その本来の目的であるユーザーエクスペリエンスの提供のために使われるべきだ。2つを横に並べて動かすのでは、これらの利点を得るために、2つの別個のインフラを稼働し、管理しなければならなくなる。最終的には、Kubernetes上にCloud Foundryを稼働させる実装により、2つを並列で動かす必要がなくなる。2つの同様な（、そして技術的に競合する）運用インフラを持つ必要はない」
0 件のコメント:
コメントを投稿