Sebagai komiter CloudFoundry (dulu) dan Kubernetes (sekarang), saya mungkin secara unik memenuhi syarat untuk menjawab pertanyaan ini.
Seperti PaaS
Saya suka menyebut CloudFoundry sebagai "Application PaaS" dan Kubernetes sebagai "Container PaaS", tetapi perbedaannya cukup halus dan tidak berubah, mengingat kedua project berubah seiring waktu untuk bersaing di pasar yang sama.
Perbedaan antara keduanya adalah bahwa CF memiliki lapisan pementasan yang mengambil aplikasi pengguna (12 faktor) (mis. Jar atau permata) dan buildpack gaya Heroku (mis. Java + Tomcat atau Ruby) dan menghasilkan tetesan (analog dengan Gambar Docker). CF tidak mengekspos antarmuka containerization kepada pengguna, tetapi Kubernetes melakukannya.
Hadirin
Audiens utama CloudFoundry adalah developer aplikasi perusahaan yang ingin menerapkan aplikasi stateless 12 faktor menggunakan buildpack gaya Heroku.
Audiens Kubernetes sedikit lebih luas, termasuk aplikasi stateless dan developer layanan stateful yang menyediakan container mereka sendiri.
Perbedaan ini bisa berubah di masa depan:
Perbandingan Fitur
Saat kedua proyek matang dan bersaing, persamaan dan perbedaan mereka akan berubah. Jadi ambil perbandingan fitur berikut dengan sebutir garam.
Baik CF dan K8 berbagi banyak fitur serupa, seperti containerization, namespacing, otentikasi,
Keunggulan kompetitif Kubernetes:
- Mengelompokkan dan menskalakan pod container yang berbagi tumpukan jaringan, bukan hanya menskalakan secara mandiri
- Bawalah wadah Anda sendiri
- Lapisan persistensi stateful
- Komunitas OSS yang lebih besar dan lebih aktif
- Arsitektur yang lebih dapat diperluas dengan komponen yang dapat diganti dan plugin pihak ketiga
- GUI web gratis
Keunggulan kompetitif CloudFoundry:
- Autentikasi yang matang, pengelompokan pengguna, dan dukungan multi-tenancy [x]
- Bawa aplikasi Anda sendiri
- Termasuk load balancer
- Diterapkan, diskalakan, dan dipertahankan hidup oleh BOSH [x]
- Logging yang kuat dan agregasi metrik [x]
- GUI web perusahaan [x]
[x] Fitur ini bukan bagian dari Diego atau termasuk dalam Lattice.
Penyebaran
Salah satu keunggulan kompetitif CloudFoundry adalah memiliki mesin penerapan yang matang, BOSH, yang memungkinkan fitur seperti penskalaan, kebangkitan, dan pemantauan komponen CF inti. BOSH juga mendukung banyak lapisan IaaS dengan abstraksi penyedia cloud yang dapat dicolokkan. Sayangnya, kurva pembelajaran BOSH dan manajemen konfigurasi penerapan adalah mimpi buruk. (Sebagai pelaku BOSH, saya rasa saya bisa mengatakan ini dengan akurat.)
Abstraksi penerapan Kubernetes masih dalam tahap awal. Beberapa lingkungan target tersedia di repo inti, tetapi tidak semuanya berfungsi, diuji dengan baik, atau didukung oleh pengembang utama. Ini sebagian besar adalah kedewasaan. Orang mungkin berharap ini meningkat dari waktu ke waktu dan meningkatkan abstraksi. Misalnya, Kubernetes di DCOS memungkinkan penerapan Kubernetes ke cluster DCOS yang ada dengan satu perintah.
Konteks Sejarah
Diego adalah penulis ulang Agen Eksekusi Tetesan CF. Awalnya dikembangkan sebelum Kubernetes diumumkan dan telah mengambil lebih banyak cakupan fitur seiring dengan berkembangnya lanskap kompetitif. Tujuan aslinya adalah untuk menghasilkan droplet (aplikasi pengguna + CF buildpack) dan menjalankannya di Warden (berganti nama menjadi Garden saat ditulis ulang di Go). Sejak awal, ini juga telah dikemas ulang sebagai Lattice , yang merupakan CloudFoundry-lite (meskipun nama itu diambil oleh proyek yang ada). Oleh karena itu, Lattice agak seperti mainan, karena sengaja mengurangi audiens dan cakupan pengguna, secara eksplisit kehilangan fitur yang akan membuatnya "siap untuk perusahaan". Fitur yang CF sudah sediakan. Ini sebagian karena Lattice digunakan untuk menguji komponen inti, tanpa beberapa overhead dari CF yang lebih kompleks, tetapi Anda juga dapat menggunakan Lattice di lingkungan kepercayaan tinggi internal di mana keamanan dan multi-tenancy tidak terlalu menjadi perhatian .
Perlu juga disebutkan bahwa CloudFoundry dan Warden (mesin kontainernya) juga sudah ada sebelum Docker, beberapa tahun.
Kubernetes di sisi lain, adalah proyek yang relatif baru yang dikembangkan oleh Google berdasarkan penggunaan kontainer selama bertahun-tahun dengan BORG dan Omega. Kubernetes dapat dianggap sebagai orkestrasi container generasi ke-3 di Google, sama seperti Diego adalah orkestrasi container generasi ke-3 di Pivotal / VMware (v1 ditulis di VMware; v2 di VMware dengan bantuan Pivotal Labs; v3 di Pivotal setelah mengambil alih proyek) .
Cloud Foundry adalah alat yang hebat dengan asumsi Anda bersedia untuk selalu bekerja dalam batasan penawaran karena sangat beropini / ditentukan. UI web keren untuk dilihat pada hari pertama tetapi jarang digunakan setelah Anda mulai bekerja dengan klien dan telah mengkonfigurasi pipeline CI / CD Anda. Saya telah menemukan bahwa Cloud Foundry sangat bagus sampai kasus penggunaan muncul yang tidak dengan mudah didukung sepenuhnya dalam Cloud Foundry. Mengirimkan kasus penggunaan ini dapat menunda project saat Anda mencoba menyelesaikan masalah tersebut, akibatnya Anda kehilangan visibilitas infrastruktur dan manfaat dukungan dari komponen tersebut yang kemudian sebagian besar berjalan di luar Cloud Foundry (pikirkan beberapa database, kafka, hadoop, cassandra , dll) Saya curiga seiring waktu, momentum seputar Docker dan ketidakfleksibelan Cloud Foundry akan mendorong pengguna ke Kubernetes, Mesos atau Docker Swarm / Datacenter. Ada kemungkinan Cloud Foundry dapat mengejar ketiganya, tetapi tampaknya tidak mungkin karena popularitas proyek open source ini.
sumber
Sulit untuk menjawab mengapa sebuah perusahaan membangun produk yang secara substansial mirip dengan produk lain. Ada banyak alasannya. Mungkin mereka sudah mulai menggunakannya dan berinvestasi di dalamnya. Mungkin mereka (CF) berpikir Kubernetes dilakukan dengan buruk atau mendapatkan API / model / detail yang salah. Mungkin mereka mengira dapat bergerak lebih cepat jika mereka mengontrol keseluruhan produk daripada berkontribusi.
Memang, saya mengatakan ini sebagai pengembang Kubernetes - orang mungkin menanyakan pertanyaan yang sama tentang Kubernetes vs Mesos, Amazon ECS vs Kubernetes, atau Docker Swarm vs Kubernetes.
Saya berharap seiring waktu, kita semua menjadi tren ke arah yang sama dan dapat lebih banyak berkolaborasi dan menghabiskan lebih sedikit waktu untuk menemukan kembali pekerjaan satu sama lain.
Adapun Kubernetes - fokusnya adalah pada pengembang aplikasi: primitif sederhana dan kuat yang memungkinkan Anda membangun dan menerapkan aplikasi dalam skala besar dengan sangat cepat. Kami bersandar pada pengalaman kami (yah, Google) dengan teknologi serupa untuk memetakan kursus kami. Orang lain akan memiliki pengalaman atau pendapat yang berbeda.
sumber
Perbedaan yang signifikan, menurut saya, adalah pendekatan yang mereka ambil:
CF membangun runtime dari 3 komponen secara otomatis: biner aplikasi yang disediakan pengguna, buildpack yang berisi middleware yang diperlukan untuk menjalankan aplikasi, dan image OS (stemcell). Pengguna CF (pengembang) harus menyediakan aplikasi biner saja (misalnya file jar yang dapat dieksekusi). CF menangani sisanya, yaitu mengemas dan menjalankan aplikasi.
Kubernetes mengharapkan image dari developer Docker yang berisi middleware dan OS yang sudah terpasang dan siap untuk dijalankan. Untuk itu, "manifes penerapan" Kubernetes (misalnya bagan Helm) menjelaskan tidak hanya satu aplikasi atau layanan tetapi semua layanan [mikro] yang menyusun solusi Anda pada waktu proses. Anda mengirimkan satu deskripsi deklaratif runtime Anda dan Kubernetes akan berhati-hati tentang status waktu proses yang sebenarnya sesuai dengan deskripsi yang Anda berikan.
Jadi pendekatan CF memungkinkannya untuk mengatasi kasus penggunaan seperti "mengganti OS dengan cacat keamanan yang ditambal di seluruh cloud Anda tanpa downtime untuk layanan Anda". Tapi itu juga berfokus pada layanan per penerapan layanan, bukan deskripsi deklaratif dari waktu proses "ideal" target sistem Anda.
sumber
Cloud Foundry adalah sistem komputasi cloud platform-as-a-service open-source. Cloud Foundry memungkinkan proyek untuk diterapkan di ruang yang berbeda dan juga mengikat layanan cloud apa pun ke aplikasi Anda.
Kubernete lebih seperti alat ornamen untuk kontainer (pod) yang melakukan penerapan otomatis, penskalaan, dan pengelolaan aplikasi dalam kontainer. Ini menggunakan istilah pod untuk menentukan wadah atau kelompok wadah.
Setiap penerapan kubernetes membutuhkan setidaknya dua sumber daya:
1) deployment.yaml: Sumber daya ini menentukan versi gambar mana yang perlu diambil dari register penampung, replika (replika pod), strategi peluncuran, penskalaan, dan probe, dll.
2) service.yaml: Ini adalah antarmuka antara pod internal Anda dan dunia luar, semua lalu lintas luar akan mendengarkan port yang ditentukan dalam sumber daya ini dari mana ia mendistribusikan beban ke pod internal.
Sumber daya lainnya adalah ingress yang disediakan kubernetes yang mengelola akses eksternal ke layanan dalam sebuah cluster, biasanya http. Melalui Ingress Anda dapat menyediakan load balancing, penghentian SSL, dan hosting virtual berbasis nama.
Lebih lanjut tentang kubernetes dapat Anda temukan di bawah: https://kubernetes.io/docs/
sumber
[pcf vs kubernetes] [1] Perbedaan antara pcf dan kubernetes
(abstraksi platform di tingkat aplikasi) • Pivotal Cloud Foundry adalah abstraksi tingkat tinggi dari pengembangan aplikasi cloud-native.
• Kami memiliki abstraksi platform di tingkat aplikasi, membangun dan menerapkan aplikasi yang dikonfigurasi sepenuhnya
• PCF adalah salah satu contoh PaaS "aplikasi" (juga disebut Cloud Foundry Application Runtime)
• Pengembang mengelola aplikasi di masa mendatang
• Ideal untuk aplikasi baru, aplikasi cloud-native. Untuk tim yang bekerja dengan siklus hidup yang pendek dan rilis yang sering, PCF menawarkan produk yang sangat baik.
(abstraksi platform di tingkat kontainer) • Kubernetes adalah penjadwal atau orkestrator kontainer.
• Kami memiliki abstraksi platform di tingkat kontainer, membangun dan menerapkan kontainer sebagai bagian dari aplikasi yang lengkap.
• Kubernetes adalah PaaS “container” (terkadang disebut CaaS).
• Dengan alat orkestrasi kontainer, Pengembang membuat dan kemudian memelihara kontainer di masa mendatang.
• Untuk aplikasi baru, Lebih banyak pekerjaan untuk tim teknik Anda dan penurunan produktivitas
sumber
Setelah 4 tahun tren terlihat seperti ini:
Cluster Kubernetes menjadi semakin murah akhir-akhir ini dan lingkungan perkakas untuk kubernetes semakin baik.
Juga sebagian besar fitur kompetitif yang terdaftar oleh poster lain saat ini mudah ditiru di dalam kubernetes.
sumber