「Kubernetes-native」へと舵を切るCloud Foundry、その理由と展望は？：草間一人氏が解説（2/2 ページ）
Cloud Foundryは、「Kubernetes-native」への移行という大きな変革の途上にある。具体的にはどのような取り組みが進行しているのか。背景と展望を含めて、PaaS研究会を主宰する草間一人氏が解説する。
CFARがKubernetesの上で動くことで、冒頭で示したような“cf push”の体験をそのまま享受できるようになる。複雑な概念の理解は不要になるのだ。
また、デプロイしたアプリケーションは内部的にはKubernetesで動いている。つまり、Kubernetes上の他アプリケーションと連携もそのまま行える。近年Kubernetesはデータベースのようなステートフルな仕組みも運用できるように進化しつつあるため、ステートレスなアプリはCFARで、ステートフルなアプリはKubernetesで動かし、それらを相互に連携させるという形になっていくかもしれない。
プラットフォームの観点から見ると、Kubernetesに載ることで、CFARをどこでも動かせるようになる点が大きい。これまでは、CFARの利点は認めつつも、動かせる環境が限られていることで導入を断念したという声が聞かれた。
現在では多くのベンダーがKubernetesのサービスを提供しており、パブリッククラウド、オンプレミス関わらず利用できるようになっている。つまり、これらどこの環境でもCFARを動かせるようになる。 既にKubernetesを導入している企業でも、加えてCFARを載せることでより優れた自動化機構の恩恵を受けることができるだろう。
Cloud Foundryプロジェクトにとっても、進化の著しいKubernetesの恩恵を受けられる点は大きい。コンテナオーケストレーターをKubernetesに任せてしまうことで、CFARとしての開発を利用者へのエクスペリエンスを向上させることに注力できる。
そしてKubernetes-nativeへ
2020年4月、CFFは「Cloud Foundry for Kubernetes（cf-for-k8s）」という新プロジェクトを発表した。紛らわしいのだが、前述したKubeCFとはまた別の方法で、CFARをKubernetes上に実現していくプロジェクトである。
KubeCFはQuarksで従来のCFARを変換してKubernetesに載せる。一方cf-for-k8sは、Kubernetesの標準にできる限り沿った形、すなわちKubernetes-nativeな形でCFARと同等の機能を実現していくことを目標としている。
まずは、cf-for-k8sと密接に関連するプロジェクトをいくつか紹介しよう。
Cloud Native Buildpacks
「Cloud Native Buildpacks（CNB）」は、CNCFのIncubationとしてホストされているプロジェクトで、HerokuとPivotal（現VMware）が中心となって開発が進められている。
元々Buildpackとはアプリケーションのソースコードをコンテナイメージに変換する仕組みであり、Herokuによって開発された。Cloud FoundryもBuildpackに対応しており、長らく両者の内部コンポーネントとして利用されてきた。
しかしDocker／Kubernetesによりコンテナへの人気が高まったことから、より汎用的なコンテナイメージ作成ツールとして独立する形で、CNBが誕生した。
Paketo Buildpacks
上記CNBの一実装として、CFFによりホストされているのが「Paketo Buildpacks」だ。Node.jsやJava、Goなど定番の言語に対応している。
kpack
「kpack」は、Pivotal（現VMware）によって開発されている、CNBをKubernetesのカスタムリソースとして動かせるプロジェクトだ。これにより、Kubernetes上でソースコードからコンテナイメージへの変換処理を行えるようになる。
Cloud Foundry for Kubernetes
そしてcf-for-k8sがある。これまでと同じCloud FoundryのAPIや認証・認可に加え、Eiriniを利用。これにPaketo Buildpacksとkpackによるコンテナイメージ作成機能を加え、Istioによるサービスメッシュ、Fluentdによるロギング機能も入ってくる。
KubeCFと違い、Quarksは利用しない。これまでのBOSHの仕組みは使わず、Kubernetesの標準に沿う形でのデプロイとなる。
IstioもFluentdもKubernetesでは広く使われているソフトウェアだ。これまでのCFARと違い、独自の仕組みに依存せず、Kubernetesのエコシステムに乗る形に変化していることがうかがえる。
VMwareが提供予定である、「VMware Tanzu Application Service for Kubernetes」は、このcf-for-k8sをベースとしている。
今後の展望
KubeCFとcf-for-k8sという、2つの異なるアプローチが今後どう交わっていくのかについて、CFFは方針を明らかにしていない。コミュニティーとしての最優先事項はKubernetesとの融合であり、アプローチを改良していくためフィードバックを待っているとのことだ。
だが、今後の展望について、明らかに言えることが1つある。それは、Cloud Foundryがこれまで提供してきた、アプリケーション開発者へのユーザーエクスペリエンスは変わらないということだ。
Cloud Foundryコミュニティーとしての焦点は、常に開発者の生活を楽にすることにある。冒頭にも紹介したチルダーズ氏は、コミュニティーへのメーリングリストにこう述べている。
「2011年にCloud Foundryが登場して以降、大きなアーキテクチャ変更は幾度もあった。しかし、簡易なコマンド一発でアプリケーションがデプロイできるという根本は一切変わらず、互換性についても極力維持する形で発展してきた。Kubernetesへの移行はこれまでの中で最も大きな変革だといえるが、今後もこの良さを維持しつつ、より良い方向に進化していくことを期待したい」
Copyright © ITmedia, Inc. All Rights Reserved.