Compose vs Swarm vs Kubernetes

Tiga alat menempati spektrum orkestrasi container, dari satu berkas compose.yaml pada satu mesin hingga manifest Kubernetes pada ratusan mesin. Topik ini menyandingkan Compose, Swarm mode, dan Kubernetes berdasarkan skala, bentuk definisi, dan kebutuhan tim, kemudian menutupnya dengan panduan pemilihan yang berangkat dari kebutuhan, bukan dari gengsi. Hasil yang dituju adalah keputusan yang dapat dijelaskan alasannya.

Tiga tingkatan dalam satu spektrum#

Tabel berikut menyandingkan ketiganya pada aspek yang paling sering dipertimbangkan, mulai dari cakupan host, mesin tempat container dijalankan, hingga kompleksitas yang harus ditanggung.

Compose adalah titik nol spektrum. Satu berkas compose.yaml menjelaskan aplikasi catatan beserta basis datanya, dan satu perintah menjalankan semuanya pada satu host. Untuk pengembangan sehari-hari dan aplikasi kecil yang bebannya terkendali, Compose sering kali merupakan titik akhir yang wajar, bukan sekadar tahap awal.

Swarm mode adalah orkestrasi bawaan Docker Engine yang mengubah beberapa mesin menjadi satu cluster, gabungan mesin yang dikelola seolah-olah satu komputer. Konsepnya menyusul Compose, yaitu service dan stack pada berkas compose.yaml yang sama, sehingga jarak belajarnya terasa pendek bagi pengguna Compose. Ekosistemnya jauh lebih kecil dibandingkan Kubernetes, dengan lebih sedikit alat tambahan dan dokumentasi pihak ketiga. Keadaan ini perlu diperhitungkan ketika memilihnya.

Kubernetes menempati ujung lain spektrum. Ekosistemnya yang terbesar membuat hampir semua alat pemantauan dan penerbitan sertifikat dapat terhubung, sedangkan statusnya sebagai standar industri membuat orang yang menguasainya mudah dicari. Konsekuensinya adalah kompleksitas tertinggi, karena jumlah objek dan konsep yang harus dipahami jauh melebihi Compose.

Swarm mode menunjukkan jarak yang pendek itu dalam praktiknya. Dua perintah berikut mengubah satu mesin menjadi manager, peran pengatur dalam cluster swarm, lalu mengerahkan compose.yaml sebagai stack, paket service yang dikerahkan bersama.

# tidak-dijalankan: daemon Docker tidak tersedia di sandbox
# mesin pertama menjadi manager, lalu stack dikerahkan
docker swarm init
docker stack deploy -c compose.yaml catatan

Perintah kedua membaca berkas yang sama yang selama ini dipakai docker compose up, tetapi hasilnya tersebar ke seluruh anggota cluster. Pembandingnya pada Kubernetes juga mudah ditebak, yaitu sekumpulan manifest yang diterapkan dengan kubectl apply.

Panduan memilih berdasarkan kebutuhan#

Panduan yang paling aman adalah memulai dari alat paling sederhana yang masih memenuhi kebutuhan. Compose tetap menjadi pilihan bila aplikasi muat pada satu host dan tim yang menjaganya kecil. Pindah ke orkestrasi multi-host hanya ketika pemicunya benar-benar muncul, dan pemicu itu biasanya berupa salah satu dari daftar berikut.

• Layanan harus tetap berjalan meskipun satu mesin mati, yaitu kebutuhan ketersediaan tinggi (high availability).
• Jumlah mesin dan container sudah membutuhkan pengawasan otomatis, misalnya penjadwalan ulang dan penskalaan yang sering terjadi.
• Tim platform terbentuk, yaitu kelompok yang tugasnya memang mengelola infrastruktur untuk tim lain.

Di antara kedua ujung itu, Swarm mode menempati posisi tengah yang sah untuk tim yang menginginkan multi-host dengan konsep Docker yang sudah dikuasai. Dogma tidak membantu pada keputusan ini, karena alat dipilih dari kebutuhan dan bukan dari gengsi. Aplikasi kecil yang dipaksakan ke Kubernetes hanya menambah biaya belajar tanpa menambah kemampuan. Satu hal perlu ditegaskan agar keputusan berpijak pada fakta. Swarm mode tetap terdokumentasi pada Docker Docs dan tetap berjalan di dalam Docker Engine, sehingga memilih atau meninggalkannya adalah penilaian teknis atas kebutuhan saat ini.

Keputusan ini juga bukan keputusan sekali untuk selamanya. Aplikasi yang tumbuh dari satu mesin ke beberapa mesin dapat berpindah tingkat secara bertahap, dan berkas compose.yaml yang sudah ada tetap berguna sebagai dokumentasi tentang komposisi aplikasinya. Biaya yang perlu dihitung bukan hanya biaya server, melainkan juga waktu belajar dan waktu operasi yang dibutuhkan setiap tingkat, karena tingkat yang lebih tinggi selalu menuntut orang yang menjaganya.

Kesalahan umum#

• Memilih Kubernetes untuk aplikasi satu mesin demi kesan profesional. Kompleksitas belajar dan operasi naik, sedangkan masalah yang diselesaikan orkestrasi belum ada. Perbaikannya, tunda migrasi sampai pemicu multi-host yang disebut di atas benar-benar terjadi.
• Menganggap Swarm mode sudah tidak didukung karena jarang dibahas. Swarm mode masih terdokumentasi pada Docker Docs dan masih berjalan pada Docker Engine. Perbaikannya, periksa status sebuah alat pada dokumentasi resminya sebelum menilai.
• Mengira compose.yaml dapat langsung dikerahkan ke Kubernetes tanpa perubahan. Keduanya menggambarkan aplikasi yang sama dengan kosakata yang berbeda. Perbaikannya, perlakukan keduanya sebagai definisi terpisah, atau gunakan alat konversi yang dijaga terus-menerus.
• Menganggap pilihan orkestrator bersifat permanen sehingga migrasi ditunda tanpa batas. Kebutuhan tim berubah, dan setiap tingkat pada spektrum ini dirancang untuk rentang skala yang berbeda. Perbaikannya, tinjau kembali pilihan setiap kali pemicu pada panduan di atas mulai terlihat.

Ringkasan#

• Compose menutup satu host, Swarm mode mengangkat konsep Compose ke beberapa host dengan ekosistem yang lebih kecil, sedangkan Kubernetes menawarkan ekosistem terbesar dengan kompleksitas tertinggi.
• Pemicu naik tingkat adalah kebutuhan nyata, yaitu ketersediaan tinggi, skala yang melebihi pengawasan manual, atau hadirnya tim platform.
• Swarm mode tetap terdokumentasi pada Docker Docs, sehingga pilihannya adalah keputusan teknis dan bukan soal gengsi.

Referensi#

• Swarm mode — Docker Docs — Dokumentasi resmi Swarm mode, termasuk konsep node, service, dan stack.
• Concepts — Kubernetes Docs — Ikhtisar konsep Kubernetes sebagai pembanding ujung spektrum.