Docker-Swarm, Kubernetes, Mesos & Core-OS Armada


153

Saya relatif baru untuk semua ini, tetapi saya kesulitan mendapatkan gambaran yang jelas di antara teknologi yang terdaftar.

Meskipun, semua ini mencoba menyelesaikan masalah yang berbeda, tetapi memiliki kesamaan juga. Saya ingin memahami apa saja hal-hal yang umum dan apa yang berbeda. Sangat mungkin bahwa kombinasi beberapa akan sangat cocok, jika demikian, apakah mereka?

Saya daftar beberapa dari mereka bersama dengan pertanyaan, tetapi akan lebih baik jika seseorang mendaftar semuanya secara rinci dan menjawab pertanyaan.

  1. Kubernetes vs Mesos:

    Link ini

    Apa perbedaan antara Apache Mesos dan Kubernet Google

    memberikan wawasan yang baik tentang perbedaan, tetapi saya tidak dapat memahami mengapa Kubernet harus berjalan di atas Mesos. Apakah ini lebih berkaitan dengan menyatukan dua solusi opensource?

  2. Armada Kubernetes vs Core-OS:

    Jika saya menggunakan kubernet, apakah diperlukan armada?

  3. Bagaimana Docker-Swarm cocok dengan semua hal di atas?



1
Saya memelihara daftar alat orkestrasi di github: datacenteroperatingsystem.io Jangan ragu untuk berkontribusi.
CMCDragonkai

Jawaban:


152

Pengungkapan: Saya seorang insinyur utama di Kubernetes

Saya pikir bahwa Mesos dan Kubernetes sebagian besar ditujukan untuk memecahkan masalah yang sama dalam menjalankan aplikasi yang dikelompokkan, mereka memiliki sejarah dan pendekatan yang berbeda untuk menyelesaikan masalah.

Mesos memfokuskan energinya pada penjadwalan yang sangat umum, dan menghubungkan banyak penjadwal yang berbeda. Ini berarti memungkinkan sistem seperti Hadoop dan Marathon untuk hidup berdampingan dalam lingkungan penjadwalan yang sama. Mesos kurang fokus menjalankan wadah. Mesos ada sebelum minat luas pada wadah dan telah difaktorkan ulang pada beberapa bagian untuk mendukung wadah.

Sebaliknya, Kubernetes dirancang dari bawah ke atas untuk menjadi lingkungan untuk membangun aplikasi terdistribusi dari kontainer. Ini termasuk primitif untuk replikasi dan penemuan layanan sebagai primitif inti, di mana hal-hal seperti itu ditambahkan melalui kerangka kerja di Mesos. Tujuan utama Kubernetes adalah sistem untuk membangun, menjalankan, dan mengelola sistem terdistribusi.

Armada adalah distributor tugas tingkat rendah. Berguna untuk bootstrap sistem cluster, misalnya CoreOS menggunakannya untuk mendistribusikan agen kubernetes dan biner ke mesin dalam sebuah cluster untuk mengaktifkan cluster kubernetes. Ini tidak benar-benar dimaksudkan untuk memecahkan masalah pengembangan aplikasi terdistribusi yang sama, pikirkan lebih seperti systemd / init.d / pemula untuk cluster Anda. Ini tidak diperlukan jika Anda menjalankan kubernetes, Anda dapat menggunakan alat lain (misalnya Garam, Wayang, Ansible, Chef, ...) untuk mencapai distribusi biner yang sama.

Swarm adalah upaya Docker untuk memperluas API Docker yang ada untuk membuat sekelompok mesin terlihat seperti API Docker tunggal. Pada dasarnya, pengalaman kami di Google dan tempat lain menunjukkan bahwa API node tidak cukup untuk API cluster. Anda dapat melihat banyak diskusi tentang ini di sini: https://github.com/docker/docker/pull/8859 dan di sini: https://github.com/docker/docker/issues/8781

Semoga itu bisa membantu! Bergabunglah dengan kami di IRC @ # google-container jika Anda ingin berbicara lebih banyak.


Terima kasih, ini sangat berguna, Anda tidak menyebutkan bisa menjalankan penjadwal Anda sendiri di kubernetes .. apakah itu mungkin?
user2851943

33

Saya pikir jawaban yang paling sederhana adalah tidak ada jawaban yang sederhana. Kenaikan cepat ke kekuatan kontainer, dan Docker khususnya telah meninggalkan kekosongan daya untuk "penjadwalan kontainer dan orkestrasi", apa pun artinya. Pada kenyataannya, itu berarti Anda memiliki sejumlah teknologi yang dapat bekerja secara harmonis pada beberapa tingkatan, tetapi dengan aspek-aspek tertentu dalam persaingan. Sebagai contoh, Kubernetes dapat digunakan sebagai toko serba ada untuk menyebarkan dan mengelola kontainer pada cluster komputasi (seperti yang dirancang Google awalnya), tetapi juga bisa duduk di atas Armada, memanfaatkan tingkat ketahanan yang disediakan Armada di CoreOS.

Karena vid Google ini menyatakan Kubernetes bukan solusi penskalaan kotak kontainer lengkap, tetapi merupakan pernyataan yang baik untuk memulai. Dengan cara yang sama, Anda pada tahap tertentu mengharapkan Apache Mesos untuk dapat bekerja dengan Kubernetes, tetapi tidak dengan Marathon, sebanyak Marathon tampaknya memenuhi peran yang sama dengan Kubernetes. Di suatu tempat saya pikir saya pernah membaca ini bisa menjadi bagian dari upaya yang sama, tetapi saya bisa salah tentang itu - ini benar-benar tentang arah strategis Mesosphere dan penerapan prinsip Kubernet yang sesuai.

Dalam keynote DockerCon, Solomon Hykes menyarankan Swarm akan menjadi tier yang dapat menyediakan antarmuka umum ke banyak kerangka kerja orkestrasi dan penjadwalan. Dari apa yang saya lihat, Swarm dirancang untuk menyediakan alur kerja penyebaran Docker yang lancar, bekerja dengan beberapa kerangka kerja alur kerja kontainer yang ada seperti Deis, tetapi cukup fleksibel untuk menghasilkan penyebaran "kelas berat" dan manajemen sumber daya seperti Mesos.

Semoga ini bisa membantu - ini bisa menjadi posting yang sangat besar. Saya pikir kuncinya adalah bahwa ini adalah layanan muda yang terus berkembang yang kemungkinan akan bergabung dan menjadi interoperable, tetapi kita perlu keluar 12 bulan ke depan untuk melihat bagaimana hasilnya. Ada beberapa orang yang sangat pintar dalam masalah ini, sehingga masa depan terlihat sangat cerah.


21

Sejauh yang saya mengerti:

Mesos, Kubernetes, dan Armada semuanya mencoba memecahkan masalah yang sangat mirip. Idenya adalah Anda memisahkan semua perangkat keras dari pengembang dan 'alat manajemen kluster' mengurutkan semuanya untuk Anda. Maka semua yang perlu Anda lakukan adalah memberikan sebuah wadah ke cluster, berikan beberapa info (tetap berjalan secara permanen, tingkatkan jika X terjadi dll) dan manajer cluster akan mewujudkannya.

Dengan Mesos, itu melakukan semua manajemen cluster untuk Anda, tetapi itu tidak termasuk penjadwal. Penjadwal adalah bit yang mengatakan, ok proses ini membutuhkan 2 procs dan RAM 512MB, dan saya punya mesin di sana dengan yang gratis, jadi saya akan menjalankannya di mesin itu. Ada beberapa penjadwal plugin yang tersedia untuk Mesos: Marathon dan Chronos dan Anda dapat menulis sendiri. Ini memberi Anda banyak kekuatan distribusi sumber daya dan penskalaan klaster dll.

Armada dan Kubernetes tampaknya mengaburkan detail-detail semacam itu (jadi pada dasarnya Anda tidak harus menulis sendiri penjadwal). Ini berarti Anda harus mendefinisikan tugas Anda dan mengirimkannya dalam format / cara yang ditentukan oleh Armada atau Kubernetes dan kemudian mereka mengambil alih dan menjadwalkan tugas (wadah) untuk Anda.

Jadi saya kira: Menggunakan Mesos mungkin berarti sedikit lebih banyak pekerjaan dalam menulis penjadwal Anda sendiri, tetapi berpotensi memberikan lebih banyak fleksibilitas jika diperlukan.

Saya pikir ide menjalankan Kubernetes di atas Mesos adalah bahwa Kubernet bertindak sebagai penjadwal untuk Mesos. Secara pribadi saya tidak yakin manfaat apa yang didapat dari menjalankan satu atau yang lainnya sendiri (mudah-mudahan seseorang akan melompat masuk dan menjelaskan!)

Seperti yang dikatakan MikeB .. ini adalah hari-hari awal, dan itu semua untuk diperebutkan (mengawasi ECS Amazon juga) sehingga ada banyak standar yang bersaing dan banyak tumpang tindih!

-edit- Saya tidak menyebutkan Docker berkerumun karena saya tidak benar-benar memiliki banyak pengalaman dengannya.


5

Bagi siapa pun yang datang ke sini setelah 2017 armada sudah usang. Jangan gunakan lagi.

Dokumen armada mengatakan "armada tidak lagi dikembangkan atau dikelola secara aktif oleh CoreOS" dan tautan ke orkestrasi kontainer: Pindah dari armada ke Kubernetes . Armada dihapus dari Container Linux ( sebelumnya dikenal sebagai CoreOS Linux ) dan diganti dengan Kubernetes kubelet (agen). Ini bertepatan dengan poros perusahaan untuk menawarkan Tectonic (distro Kubernetes) sebagai produk utama mereka.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.