CloudFoundry / Diegoの次のバージョンは、複数のホスト間でオーケストレーションされるDockerコンテナーのネイティブサポートを提供します[ リンク ]。これは、Kubernetesとよく似ています。
もちろん、Kubernetesが解決しようとしている問題はより一般的なものであり、CloudFoundryはアプリ開発に重点を置いています。しかし、私にとっては、どちらも同じ方向に向かっているように思えます。CloudFoundryは、単純なオーケストレーションに加えて、さらに多くの機能を追加しています。
それで、KubernetesがCloudFoundryよりも価値を追加するユースケースについて疑問に思っていますか？
回答:
CloudFoundry（過去）とKubernetes（現在）の両方のコミッターとして、私はおそらくこれに答える資格があります。
CloudFoundryを「アプリケーションPaaS」、Kubernetesを「コンテナPaaS」と呼びたいのですが、両方のプロジェクトが時間とともに変化して同じ市場で競争することを考えると、区別はかなり微妙で流動的です。
2つの違いは、CFには（12要素）ユーザーアプリ（jarまたはgemなど）とHerokuスタイルのビルドパック（Java + TomcatまたはRubyなど）を取り、ドロップレット（ Dockerイメージ）。CFはコンテナー化インターフェースをユーザーに公開しませんが、Kubernetesは公開します。
CloudFoundryの主な対象者は、Herokuスタイルのビルドパックを使用して12要素のステートレスアプリを展開したいエンタープライズアプリケーション開発者です。
Kubernetesのオーディエンスは、ステートレスアプリケーションと独自のコンテナーを提供するステートフルサービス開発者の両方を含む、少し広い範囲です。
この区別は将来変更される可能性があります。
両方のプロジェクトが成熟して競争するにつれて、それらの類似点と相違点は変化します。したがって、次の機能比較を1粒の塩と比較してください。
CFとK8はどちらも、コンテナー化、名前空間、認証、
Kubernetesの競争上の利点：
CloudFoundryの競争上の利点：
[x]これらの機能はDiegoの一部ではなく、ラティスにも含まれていません。
CloudFoundryの競争上の利点の1つは、コアCFコンポーネントのスケーリング、復活、監視などの機能を可能にする成熟したデプロイメントエンジンBOSHを備えていることです。BOSHは、プラグイン可能なクラウドプロバイダーの抽象化により多くのIaaSレイヤーもサポートします。残念ながら、BOSHの学習曲線と展開構成管理は悪夢です。（ボッシュコミッターとして、私はこれを正確に言えると思います。）
Kubernetesのデプロイの抽象化はまだ始まったばかりです。コアリポジトリでは複数のターゲット環境を利用できますが、すべてが正常に機能しているわけではなく、十分にテストされているわけでも、主要な開発者によってサポートされているわけでもありません。これは主に成熟度のことです。これは、時間の経過とともに改善され、抽象化が進むと期待できます。たとえば、DCOS上のKubernetesでは、1つのコマンドで既存のDCOSクラスターにKubernetesをデプロイできます。
DiegoはCFのDroplet Execution Agentを書き直したものです。もともとはKubernetesが発表される前に開発され、競争の状況が進化するにつれて、より多くの機能範囲を採用しています。その当初の目標は、液滴（ユーザーアプリケーション+ CFビルドパック）を生成し、Warden（Goで書き換えると名前がGardenに変更）コンテナーで実行することでした。当初から、それはLatticeとして再パッケージ化されています。これは、CloudFoundry-liteのようなものです（ただし、この名前は既存のプロジェクトで使用されています））。そのため、Latticeはユーザーの対象範囲と範囲を意図的に減らし、「エンタープライズ対応」にする機能が明示的に欠落しているという点で、ややおもちゃのようなものです。CFがすでに提供している機能。これは、一部のLatticeがコアコンポーネントのテストに使用されており、より複雑なCFからのオーバーヘッドの一部がないためですが、セキュリティとマルチテナントがそれほど懸念されていない内部の高信頼環境でもLatticeを使用できます。
CloudFoundryとWarden（そのコンテナーエンジン）もDockerよりも数年前に登場したことにも言及する価値があります。
一方、Kubernetesは、BORGおよびOmegaでの長年のコンテナ使用に基づいてGoogleが開発した比較的新しいプロジェクトです。Kubernetesは、DiegoがPivotal / VMwareでの第3世代コンテナーオーケストレーションと同じように、Googleでの第3世代コンテナーオーケストレーションと考えることができます（VMwareで作成されたv1、Pivotal Labsの協力を得てVMwareでv2、プロジェクトを引き継いだ後、Pivotalでv3）。 。
Cloud Foundryは、非常に独断的で処方されているため、常に製品の制約内で作業することを想定している優れたツールです。Web UIは最初の日を見るのはかっこいいですが、クライアントでの作業を開始してCI / CDパイプラインを構成した後はめったに使用されません。Cloud Foundry内で完全にサポートされないユースケースがポップアップするまでは、Cloud Foundryが優れていることを発見しました。これらのユースケースを提供すると、それらの問題を解決しようとするときにプロジェクトが遅れる可能性があります。その結果、インフラストラクチャの可視性が失われ、Cloud Foundryの外部で実行されるコンポーネントのメリットがサポートされます（複数のデータベース、kafka、hadoop、cassandraを考えてください）など）、時間の経過とともに、Dockerを取り巻く勢いとCloud Foundryの柔軟性の低さがユーザーをKubernetesに駆り立てるのではないかと思います。MesosまたはDocker Swarm / Datacenter。Cloud Foundryがこれらの3つに追いつく可能性はありますが、これらのオープンソースプロジェクトの人気により、そうなる可能性は低いと思われます。
企業が他の製品と実質的に類似した製品を作る理由に答えるのは難しいです。理由はたくさんあります。多分彼らはすでにそれを使い始めて、それに投資しています。たぶん彼ら（CF）は、Kubernetesが正しく行われていないか、API /モデル/詳細が間違っていると考えています。多分彼らは彼らが貢献するよりも製品全体を制御するならもっと速く動くことができると思っています。
確かに、私はこれをKubernetes開発者として言います-Kubernetes対Mesos、Amazon ECS対Kubernetes、またはDocker Swarm対Kubernetesの同じ質問をするかもしれません。
時間がたつにつれ、私たちはすべて同じ方向に向かっていて、より多くのコラボレーションを行い、お互いの作業の再発明に費やす時間が減ることを願っています。
Kubernetesについては、アプリ開発者に焦点を当てています。シンプルで強力なプリミティブにより、アプリを非常に迅速に構築してデプロイできます。私たちは、同様のテクノロジーを使った経験（まあ、Googleの経験）に基づいてコースを図表化しています。他の人は異なる経験や意見を持っています。
私の意見では、大きな違いは彼らが取っているアプローチです：
CFは、3つのコンポーネントからランタイムを自動的に構築します。ユーザー提供のアプリケーションバイナリ、アプリの実行に必要なミドルウェアとOSイメージ（幹細胞）を含むビルドパックです。CFユーザー（開発者）は、アプリケーションバイナリのみ（たとえば、実行可能なjarファイル）を提供する必要があります。残りの部分はCFが処理します。つまり、アプリをパッケージ化して実行します。
Kubernetesは、ミドルウェアとOSがすでに組み込まれており、実行の準備ができている開発者Dockerイメージを期待しています。そのために、Kubernetesの「デプロイメントマニフェスト」（Helmチャートなど）は、単一のアプリまたはサービスだけでなく、実行時にソリューションを構成するすべての[マイクロ]サービスを記述します。ランタイムの単一の宣言的な説明を送信すると、Kubernetesは、実際のランタイム状態が提供された説明と一致するように処理します。
したがって、CFアプローチを使用すると、「サービスのダウンタイムを発生させることなく、クラウド全体でパッチを適用したセキュリティの欠陥でOSを置き換える」などのユースケースに対処できます。ただし、システムのターゲットの「理想的な」ランタイムの宣言的な説明ではなく、サービスごとのサービスの配置にも焦点を当てています。
Cloud Foundryは、オープンソースのサービスとしてのクラウドコンピューティングシステムです。Cloud Foundryを使用すると、プロジェクトをさまざまなスペースにデプロイでき、クラウドサービスをアプリケーションにバインドすることもできます。
Kuberneteは、コンテナー化されたアプリケーションのデプロイ、スケーリング、管理を自動化するコンテナー（ポッド）の装飾ツールに似ています。ポッドという用語を使用して、コンテナーまたはコンテナーのグループを定義します。
Kubernetesのデプロイには、少なくとも次の2つのリソースが必要です。
1）deployment.yaml：このリソースは、コンテナーレジスター、レプリカセット（ポッドレプリカ）、ロールアウト戦略、スケーリング、プローブなどから取得する必要があるイメージのバージョンを定義します。
2）service.yaml：内部ポッドと外部の世界との間のインターフェースです。すべての外部トラフィックは、このリソースで定義されたポートをリッスンし、そこから内部ポッドに負荷を分散します。
さらに多くのリソースは、クラスター内のサービス（通常はhttp）への外部アクセスを管理するkubernetesが提供するイングレスです。Ingressを使用すると、負荷分散、SSL終了、名前ベースの仮想ホスティングを提供できます。
[pcfとkubernetes] [1] pcfとkubernetesの違い
PCF
（アプリケーションレベルでのプラットフォームの抽象化）•Pivotal Cloud Foundryは、クラウドネイティブアプリケーション開発の高レベルの抽象化です。
•アプリケーションレベルでプラットフォームを抽象化し、完全に構成されたアプリケーションを構築および展開します。
•PCFは、「アプリケーション」PaaS（Cloud Foundryアプリケーションランタイムとも呼ばれる）の一例です。
•開発者がアプリケーションを保守する
•新しいアプリケーション、クラウドネイティブアプリに最適です。短いライフサイクルと頻繁なリリースで作業するチームに、PCFは優れた製品を提供します。
Kubernetes
（コンテナレベルでのプラットフォームの抽象化）•Kubernetesは、コンテナスケジューラまたはオーケストレータです。
•コンテナレベルでプラットフォームを抽象化し、完全なアプリケーションの一部としてコンテナを構築および展開します。
•Kubernetesは「コンテナー」PaaS（CaaSとも呼ばれる）です。
•コンテナーオーケストレーションツールを使用すると、開発者は将来コンテナーを作成して保守します。
•新しいアプリケーションの場合、エンジニアリングチームの作業が増え、生産性が低下する
4年後の傾向は次のようになります。
Kubernetesクラスターは最近非常に安価になり、kubernetesのツール環境が改善されています。
また、他のポスターに記載されている競合機能のほとんどは、最近、kubernetes内で複製するのが非常に簡単です。