Kubernetes対CloudFoundry
CloudFoundry/Diegoの次のバージョンでは、Dockerコンテナーのネイティブサポートを提供します。Dockerコンテナーは、マルチホスト[ link ]で調整されます。これはKubernetesと非常によく似ています。
もちろん、Kubernetesが解決しようとしている問題はより一般的であり、CloudFoundryはアプリ開発により重点を置いています。しかし、私にとっては、どちらも同様の方向に向かっているように聞こえ、CloudFoundryは単純なオーケストレーションの上にさらに多くの機能を追加しています。
だから、KubernetesがCloudFoundryよりも価値を高めるユースケースについて疑問に思っていますか？
CloudFoundry（過去）とKubernetes（現在）の両方のコミッターとして、私はおそらくこれに答える唯一の資格を持っています。
PaaSのような
CloudFoundryを「アプリケーションPaaS」、Kubernetesを「コンテナPaaS」と呼びたいのですが、両方のプロジェクトが同じ市場で競争するために時間とともに変化することを考えると、区別はかなり微妙で流動的です。
2つの違いは、CFには（12要素の）ユーザーアプリ（jarやgemなど）とHerokuスタイルのビルドパック（Java + TomcatやRubyなど）を受け取り、ドロップレット（aに類似）を生成するステージングレイヤーがあることです。 Dockerイメージ）。 CFはコンテナ化インターフェースをユーザーに公開しませんが、Kubernetesは公開します。
聴衆
CloudFoundryの主な対象者は、Herokuスタイルのビルドパックを使用して12要素のステートレスアプリをデプロイするエンタープライズアプリケーション開発者です。
Kubernetesの対象者は、ステートレスアプリケーション開発者と独自のコンテナを提供するステートフルサービス開発者の両方を含めて、少し広くなっています。
この区別は将来変更される可能性があります。
- CloudFoundryは、Dockerイメージの受け入れを開始できます（ Lattice accepts Docker images ）。
- Kubernetesは画像生成レイヤーを追加できます（ OpenShiftはこのようなことをします ）。
機能比較
両方のプロジェクトが成熟し、競争するにつれて、それらの類似点と相違点は変わります。したがって、次の機能比較を一粒の塩と比較してください。
CFとK8はどちらも、コンテナ化、ネームスペース、認証、
Kubernetesの競争上の優位性：
- 個別にスケーリングするのではなく、ネットワークスタックを共有するコンテナのポッドをグループ化およびスケーリングします
- 独自のコンテナを持参
- ステートフル永続化レイヤー
- より大きく、より活発なOSSコミュニティ
- 交換可能なコンポーネントとサードパーティのプラグインを備えたより拡張性の高いアーキテクチャ
- 無料のWeb GUI
CloudFoundryの競争上の優位性：
- 成熟した認証、ユーザーのグループ化、マルチテナンシーのサポート[x]
- 独自のアプリをお持ちください
- ロードバランサーが含まれています
- BOSH [x]による展開、スケーリング、および維持
- 堅牢なロギングおよびメトリック集約[x]
- エンタープライズWeb GUI [x]
[x]これらの機能は、ディエゴの一部ではなく、ラティスに含まれていません。
展開
CloudFoundryの競争上の利点の1つは、コアCFコンポーネントのスケーリング、復活、監視などの機能を有効にする成熟した展開エンジンBOSHを備えていることです。 BOSHは、プラグ可能なクラウドプロバイダーの抽象化により、多くのIaaSレイヤーもサポートします。残念ながら、BOSHの学習曲線と展開構成管理は悪夢のようなものです。 （BOSHコミッターとして、私はこれを正確に言うことができると思います。）
Kubernetesの展開の抽象化はまだ始まったばかりです。コアリポジトリでは複数のターゲット環境を使用できますが、それらはすべて主要な開発者によって機能、テスト、サポートされているわけではありません。これはほとんどが成熟したものです。これは時間の経過とともに改善され、抽象度が増加すると予想されるかもしれません。たとえば、 DCOS上のKubernetes は、1つのコマンドで既存の DCOS クラスターにKubernetesをデプロイできます。
歴史的背景
DiegoはCFのDroplet Execution Agentを書き直したものです。もともとはKubernetesが発表される前に開発されたものであり、競争環境が進化するにつれてより多くの機能範囲を取り込んでいます。元々の目標は、ドロップレット（ユーザーアプリケーション+ CFビルドパック）を生成し、それらをワーデン（Goで書き換えるとガーデンに改名）コンテナーで実行することでした。当初から Lattice として再パッケージ化されていますが、これはCloudFoundry-liteのようなものです（ただし、その名前は 既存のプロジェクト によって取得されました）。そのため、ラティスはややおもちゃのようなものであり、意図的にユーザーの視聴者と範囲を縮小し、「エンタープライズ対応」にする機能を明確に欠いています。 CFが既に提供している機能。これは、ラティスを使用してコアコンポーネントをテストするためです。より複雑なCFからのオーバーヘッドはありませんが、セキュリティとマルチテナンシーがそれほど重要ではない内部の高信頼環境でもラティスを使用できます。 。
また、CloudFoundryとWarden（そのコンテナーエンジン）がDockerよりも数年前に先行していることにも言及する価値があります。
一方、Kubernetesは、BORGとOmegaでの長年のコンテナ使用に基づいてGoogleが開発した比較的新しいプロジェクトです。 Kubernetesは、Googleでの第3世代のコンテナオーケストレーションと考えることができます。DiegoがPivotal/VMwareでの第3世代のコンテナオーケストレーションと同じです（v1はVMwareで記述されています。 。
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の「展開マニフェスト」（ヘルムチャートなど）は、単一のアプリまたはサービスだけでなく、実行時にソリューションを構成するすべての[マイクロ]サービスを記述します。ランタイムの宣言的な説明を1つ送信すると、Kubernetesは提供された説明と一致する実際のランタイム状態を処理します。
そのため、CFアプローチは、「サービス全体のダウンタイムを発生させることなく、クラウド全体でOSをパッチされたセキュリティ欠陥に置き換える」などのユースケースに対処することを可能にします。ただし、システムのターゲット「理想的な」ランタイムの宣言的な記述ではなく、サービス展開ごとのサービスにも焦点を当てています。
Cloud Foundryは、オープンソースのPlatform-as-a-Serviceクラウドコンピューティングシステムです。 Cloud Foundryを使用すると、プロジェクトをさまざまなスペースにデプロイでき、クラウドサービスをアプリケーションにバインドできます。
Kuberneteは、コンテナ化されたアプリケーションの展開、スケーリング、管理を自動化するコンテナ（ポッド）の装飾ツールに似ています。そのポッドという用語を使用して、コンテナまたはコンテナのグループを定義します。
Kubernetesの展開には、少なくとも2つのリソースが必要です。
1）deployment.yaml：このリソースは、コンテナレジスタ、レプリカセット（ポッドレプリカ）、ロールアウト戦略、スケーリング、プローブなどから取得する必要があるイメージのバージョンを定義します。
2）service.yaml：内部ポッドと外部の世界との間のインターフェースです。すべての外部トラフィックは、このリソースで定義されたポートをリッスンし、そこから内部ポッドに負荷を分散します。
より多くのリソースは、クラスター内のサービス（通常はhttp）への外部アクセスを管理するkubernetesが提供するイングレスです。 Ingressを使用すると、負荷分散、SSL終了、名前ベースの仮想ホスティングを提供できます。
以下で見つけることができるkubernetesの詳細： https://kubernetes.io/docs/
[pcf vs kubernetes] [1] pcfとkubernetesの違い
PCF
（アプリケーションレベルでのプラットフォームの抽象化）•Pivotal Cloud Foundryは、クラウドネイティブアプリケーション開発の高レベルの抽象化です。
•アプリケーションレベルでプラットフォームを抽象化し、完全に構成されたアプリケーションを構築および展開します。
•PCFは、「アプリケーション」PaaS（Cloud Foundry Application Runtimeとも呼ばれます）の一例です
•開発者がアプリケーションを将来維持する
•新しいアプリケーション、クラウドネイティブアプリに最適。短いライフサイクルと頻繁なリリースを扱うチームにとって、PCFは優れた製品を提供します。
Kubernetes
（コンテナレベルでのプラットフォームの抽象化）•Kubernetesは、コンテナスケジューラまたはオーケストレータです。
•コンテナレベルでプラットフォームを抽象化し、完全なアプリケーションの一部としてコンテナを構築および展開します。
•Kubernetesは「コンテナー」PaaS（CaaSと呼ばれることもあります）です。
•コンテナオーケストレーションツールを使用して、開発者は将来コンテナを作成し、保守します。
•新しいアプリケーションの場合、エンジニアリングチームの作業量が増え、生産性が低下する
クベルネテスエンジン
Kubernetes Engineは、コンテナ化されたアプリケーションを展開するための管理された本番環境です。開発者の生産性、リソース効率、自動化された操作、オープンソースの柔軟性に関する最新の革新をもたらし、市場投入までの時間を短縮します。
2015年に開始されたKubernetes Engineは、12年以上にわたってコンテナでGmailやYouTubeなどのサービスを実行してきたGoogleの経験に基づいています。 Kubernetes Engineを使用すると、独自のKubernetesクラスターをインストール、管理、および運用する必要性が完全になくなるため、Kubernetesをすぐに起動して実行できます。
Kubernetes Engineは、アプリケーションとサービスの展開、更新、管理を簡単にすることにより、迅速なアプリケーション開発と反復を可能にします。 Kubernetes Engineは、ステートレスアプリケーションだけではありません。永続ストレージを接続し、クラスターでデータベースを実行することもできます。アプリケーションコンテナに必要なコンピューティング、メモリ、およびストレージリソースを記述するだけで、Kubernetes Engineは基盤となるクラウドリソースを自動的にプロビジョニングおよび管理します。ハードウェアアクセラレータのサポートにより、機械学習、汎用GPU、高性能コンピューティング、および特殊なハードウェアアクセラレータの恩恵を受けるその他のワークロードを簡単に実行できます。
Google Cloudコンソールの組み込みKubernetes Engineダッシュボードから環境を制御します。定期的なヘルスチェックを使用して、展開内のハングまたはクラッシュしたアプリケーションを検出および置換します。コンテナレプリケーション戦略、監視、および自動修復は、サービスの可用性を高め、ユーザーにシームレスなエクスペリエンスを提供します。 Googleサイト信頼性エンジニア（SRE）は、クラスターとそのコンピューティング、ネットワーク、およびストレージリソースを常に監視しているため、必要がないため、アプリケーションに集中する時間ができます。
1台のマシンから数千台に移行：Kubernetes Engineの自動スケーリングにより、サービスに対するユーザーの需要の増加に対応し、最も重要なときにサービスを利用可能に保つことができます。次に、静かな時間帯に縮小してお金を節約するか、優先度の低いバッチジョブをスケジュールして予備サイクルを使い果たします。 Kubernetes Engineは、リソースプールを最大限に活用するのに役立ちます。
Google Cloudのグローバル仮想プライベートクラウド（VPC）を使用して、きめ細かなネットワークポリシーを使用して、どこにいてもクラスターに接続して分離します。シームレスな負荷分散のために、単一のグローバルエニーキャストIPアドレスの背後にあるパブリックサービスを使用します。コンテナに対するDOSおよびその他の種類のエッジ攻撃から保護します。
Kubernetes Engineは、認定Kubernetesを実行して、クラウドおよびオンプレミス全体の移植性を保証します。ベンダーのロックインはありません。KubernetesEngineからアプリケーションを取り出して、Kubernetesがサポートされている任意の場所（自社運用サーバーなど）で実行できます。 Google Cloud Platform（GCP）およびエコシステム内のサードパーティソリューションを使用して、監視、ロギング、CI/CDなどの統合を調整できます。
クラウドファウンドリー
Cloud Foundryには、あらゆるプログラミング言語でアプリを実行するコンテナーベースのアーキテクチャがあります。既存のツールを使用して、コードを変更することなく、アプリをCFにデプロイします。任意のクラウドでCF BOSHを使用して、高可用性Kubernetesクラスターをインスタンス化、デプロイ、および管理します。
Cloud Foundryにデプロイされたアプリケーションは、Open Service Broker APIを介して外部リソースにアクセスします。 The Foundryで利用可能なサービスと統合をご覧ください。
Cloud Foundryは適応性が高く、テクノロジーの変化に耐えることができるため、将来的に新しいツール、言語、プラットフォームを採用できます。
アプリケーションをインフラストラクチャから分離することで、オンプレミス、パブリッククラウド、または管理インフラストラクチャでワークロードをホストする場所を個別に決定し、必要に応じてそれらのワークロードをアプリに変更を加えることなく数分で移動できます。
Cloud Foundryは現在のワークフローを中断しません。 AWSやDocker、Kubernetes、Java 、. NETなど、現在使用している技術やツールと互換性があり、現在の環境のあらゆるものと互換性があります。
Cloud Foundryは、ベンダーのロックインを回避するための最大限の柔軟性をユーザーに提供するオープンな貢献とオープンなガバナンスモデルを備えたオープンソースプロジェクトです。私たちは、あらゆる種類の課題に取り組むために集まった多様な心の信頼できるコミュニティを監督するのを助けます。より多くの視点と多様な思考は、より強力なコードを意味します。
4年後のトレンドは次のようになります。
Kubernetesクラスターは最近非常に安くなっており、kubernetesのツール環境は優れています。
また、最近、他のポスターにリストされている競合機能のほとんどは、kubernetes内で簡単に複製できます。