Cloud FoundryとKubernetes、クラウドネイティブに向けた2つのアプローチ：吉瀬淳一氏が解説（1/2 ページ）

Cloud Foundry（Cloud Foundry Application Runtime）とKubernetesをどう考え、それぞれをクラウドネイティブなアプリケーション開発でどう生かすべきなのか。双方に精通するHewlett Packard Enterpriseの吉瀬淳一氏が、中立的な立場から解説する。

[吉瀬淳一，Hewlett Packard Enterprise]

　開発効率を高めるクラウドネイティブアプリケーションプラットフォームとしては、Cloud Foundryが知られてきた。一方、最近では複数のコンテナプラットフォーム、特にKubernetesが存在感を高めており、これにアプリケーションプラットフォームとしての期待をかける人が増えてきている。Cloud Foundry（Cloud Foundry Application Runtime）とKubernetesをどう考え、クラウドネイティブなアプリケーション開発でどう生かすべきなのか。双方に精通するHewlett Packard Enterpriseの吉瀬淳一氏が、中立的な立場から解説する。（編集部）

”Kubernetes, just run my code”が目標、ということは……

　2018年5月にコペンハーゲンで開催された「KubeCon + CloudNativeCon 2018 Europe」の参加者は4300人を超え、Cloud Native Computing Foundation（CNCF）が提唱する、Kubernetesを中心としたクラウドネイティブエコシステムへの関心の高さを改めて印象付けた。Google、Amazon Web Services（AWS）、Microsoftといった大手クラウドサービスプロバイダーをはじめ、いまやOSS（オープンソースソフトウェア）テクノロジーを活用している企業の大半が、何らかの形でKubernetesに関わっていると言っても過言ではない。

　今回のKubeCon + CloudNativeConでは、コンテナオーケストレーションそのものよりも、セキュリティ、マイクロサービスを前提としたアプリケーションルーティング、CRD（Custom Resource Definition）による機能拡張といった、実際に運用する上で必要となる機能について、Kubernetesをいかに補完していくかというトピックが多かったように思う。

　また、CNCFのExecutive Directorであるダン・コーン（Dan Kohn）氏は、カンファレンス冒頭のキーノートで、KubernetesのようなOSSプラットフォーム上でアプリケーションを運用していくためには、アプリケーションのみならずプラットフォームも含めて継続的なデプロイとテストが必要であり、そのためにはCI/CDが重要であると述べた。CNCFのメンバー企業であるWeaveworksの創業者兼CEOであるアレクシス・リチャードソン（Alexis Richardson）氏は、CI/CDの統合やバックエンドサービスのマーケットプレイス化を経て、2020年には”Kubernetes, just run my code”が実現できるようになる、というビジョンを示した。

　ここで、Cloud Foundryをご存じの方はこう感じるのではないだろうか。「Kubernetesの『これから』として語られている機能は、Cloud Foundryがコンセプトとして提唱し実装してきたことではないか？」と。

　Cloud Foundry Foundation（CFF）はCNCFのメンバーでもあり、今回のKubeCon + CloudNativeConのキーノートにも、Exective Directorのアビー・カーンズ（Abby Kearns）氏が登壇している。彼女が強調していたのは”Interoperability”（相互運用性）である。しばしばKubernetesのライバルとして見られるCloud Foundryではあるが、CFFとしては共存と共生による発展を目指す、というメッセージと取れる。

　実際に、現在CFFがホストしているのは、かつてCloud Foundryという名が示していたアプリケーションPaaSだけではない。以下の3つが主要プロジェクトとなっている。

• Cloud Foundry Application Runtime（CFAR）：従来のCloud Foundry（PaaS）プロジェクト
• Cloud Foundry Container Runtime（CFCR）：後述のBOSHでKubernetesをデプロイ・管理するプロジェクト
• Cloud Foundry BOSH：プラットフォームレイヤーのライフサイクル管理と維持を行うプロジェクト

　CFARとKubernetesはいずれもクラウドネイティブアプリケーションの実行基盤であり、コンテナ化されたマイクロサービスを柔軟にスケールさせるという点も共通している。機能のカバー範囲が異なるため、1対1で比較するべきものではないが、それぞれの特徴と違いについて簡単にまとめてみたい。

Cloud Foundry（CFAR）とKubernetes、それぞれの特徴と相互の違い

CFARは開発効率を向上するが、開発者の自由度は制限される

　CFARの機能を一言で表現するなら、「プラットフォームにソースコードを渡すだけでアプリケーションがアクセス可能になる」ということになる。それを実現するための構成要素は決して単純なものではない。主な機能としてはアプリケーションのビルドとランタイムの管理（buildpack）、ビルドされたアプリケーションコンテナの実行と管理（Diego）、DBなどの外部サービスとの接続（Service Broker）、ログの管理、サービスディスカバリとルーティング、などが含まれる。

　CFARにおけるアプリケーション開発者とプラットフォーム管理者の役割分担は明確で、アプリケーション開発者の行うことは前述の通り、基本的には「ソースコードを渡すだけ」である。とはいえCIやテストなど、アプリケーションのライフサイクル上開発側で考慮しなければならないことは残るが、それでも大幅な開発効率の改善が望める。

　これは逆に言うと、開発側の自由度が制限されるということでもある。アプリケーションランタイムは基本的にはプラットフォーム側で管理され、DBなどのバックエンドサービスもプラットフォームから提供されるものを利用する形になる。

　高いレイヤーでのサービスをユーザー（＝アプリケーション開発者）に提供する上で互換性を保つために、プラットフォーム側のアーキテクチャも、後述するKubernetesエコシステムの自由度と比べると、コントロールされたものとなっている。CFAR自体はインフラ（ベアメタル／仮想マシン／IaaS）に依存するものではないが、そのライフサイクルはBOSH Releaseとして管理されている。

　また、CFARはWebアプリケーションあるいはRESTベースのマイクロサービスに特化していて、データの永続性を要求するステートフルなサービスや、NICやGPUといった物理リソースに依存するようなサービスには向いていない。

Kubernetesは、スケールするコンテナオーケストレーション基盤

　Kubernetesは、Googleのサービス基盤であるBorgから派生したオープンソースプロジェクトである。あらゆるワークロードを大規模な分散環境で実行するための標準基盤として開発されたBorgのコンセプトを受け継ぎ、ワークロードに対してデータセンターリソースを柔軟に割り当てることによるスケーラビリティーと自律性が当初から重視されている。

　Kubernetesがオープンソース化された2015年当時、既にDockerがコンテナイメージのフォーマットとして定着しており、Dockerの利用による「ポータブルなアプリケーションイメージのビルドと管理」については認識が広まりつつあった。Kubernetesはコンテナイメージをデプロイし、実行・管理するための環境として注目を集め、急速に発展を遂げてきた。

　Kubernetesの機能範囲は、「コンテナオーケストレーションおよびそのためのクラスタ管理のみ」と言ってよく、CFARに含まれるようなアプリケーションのビルドは含まれていない。コンテナランタイムやストレージ、コンテナネットワークといった構成要素も「プラガブル」なものとして選択／組み合わせできるようになっている。

　Kubernetesの大きな特徴の1つは、宣言的な設定による自律的な状態の維持である。Kubernetesでは、マニフェストと呼ばれる構造的なパラメータ（通常YAMLで記述される）でシステムの「あるべき姿」を定義し、Kubernetesはそこに定義された状態を常に維持するように動く。これはイミュータブルなワークロードを迅速に展開しスケールさせる上での強力なコンセプトであるが、アプリケーションコンテナのデプロイだけはなく、ネットワークやパーシステントボリューム（永続ボリューム）といったインフラ要素の構成も、全てこのマニフェストで定義される。

　このため、管理すべきYAMLファイルは大量となり、それはしばしば「YAMLの壁」と呼ばれる。また、このマニフェストはアプリケーションのデプロイとインフラ要素を共にコードで定義するものであるため、それを誰がどのように管理するか、という課題がある。

Kubernetes環境の構築・運用が難しいと言われる理由

　ここで、「Kubernetesは構築と運用が難しい」と言われている理由について触れておきたい。

　Kubernetesを構成するコンポーネントは、以下の2種類に大別される。

Master Components

クラスタ全体のコントロールプレーンを担う。中枢神経とも言えるAPI Server、クラスタ内の状態情報を保持するするetcd、Podの配置と実行を制御するkube-scheduler、ノードやレプリカの状態を管理するkube-controller-managerなどが含まれる。

Node Components

ワークロードとなるPod（コンテナ）の実行ノードで動作する。Podの実行を管理するkubelet、Podとネットワークを接続するkube-proxyなどが含まれる。

　これらのコンポーネントを配備し、クラスタを維持するためには考慮すべき点は多い。例えばMaster Componentsはそれぞれがクラスタ全体の運用に必須となる重要なコンポーネントであるため、適切な手段で冗長化される必要がある。ノードの追加時にはNode Componentsが適切に配置されてクラスタに参加するような仕組みも必要だ。

　初期構築時にこれらのコンポーネントを配備する仕組みとしては、各ディストリビューションがそれぞれデプロイツール（インストーラー）を提供しているが、ネットワークやストレージ接続といったデータセンター要件に合わせて構成をカスタマイズすることは容易ではない。また初期構築時だけではなく、運用に入った後も障害時のリカバリー、Kubernetesやコンテナランタイムのアップグレードといったライフサイクルを考慮する必要がある。Google Kubernetes Engine（GKE）やAmazon Elastic Container Service for Kubernetes（EKS）といったマネージドKubernetes環境を利用することにより、Masterの管理からは解放されるが、オンプレではそうはいかない。

　また、アプリケーション開発とインフラ運用の役割分担という点でも難しさがある。Kubernetesでは、ネットワークやストレージに対する要求やレプリカなどのデプロイ形態といった、いわゆる”Infrastructure as Code”の部分も個々のアプリケーションの定義に含める必要がある。コンテナイメージのビルドに加えて、そういったコード化されたデプロイメント定義をCI/CDのパイプラインに含めることにより、柔軟性や敏捷性といったメリットを享受できるわけだが、これは従来型のいわゆる「アプリ担当／インフラ担当」の役割分担には当てはまらないため、いかに管理し自動化するかについては、先進的なKubernetesユーザー企業においても試行錯誤が続いている。