# Docker Swarm vs Kubernetes: Vonis Load Test Tim Kecil > Docker Swarm vs Kubernetes untuk tim kecil, diputuskan dengan load test saya sendiri dan autoscaler buatan sendiri: apa yang ditambah HPA, kapan Swarm tak cukup. URL: https://www.matthewswong.com/id/blog/docker-swarm-vs-kubernetes-small-team-load-test/ - Author: Matthews Wong (https://www.matthewswong.com/id/about/) - Published: 2026-10-17 - Updated: 2026-10-17 - Category: DevOps > **Key takeaway:** Untuk tim kecil, Docker Swarm sudah cukup sampai Anda butuh autoscaling bawaan, kontrol akses yang lebih rinci, atau tooling Kubernetes. Dalam load test saya, menggandakan replica Swarm nyaris tidak menaikkan throughput karena satu row lock database menjadi batasnya, jadi HPA Kubernetes pun tidak akan menolong. Hilangkan bottleneck sebenarnya dulu, baru pilih orchestrator. Pertanyaan yang paling sering saya terima setelah artikel Swarm saya kira-kira berbunyi: apa sebaiknya langsung pindah ke Kubernetes saja? Biasanya muncul setelah seminggu yang lambat, ketika seseorang sadar satu container sudah mentok di batas CPU-nya dan Swarm tidak menambah container kedua dengan sendirinya. Artikel ini menjawabnya untuk tim kecil, dengan satu-satunya bukti yang berani saya pertanggungjawabkan: load test dan autoscaler buatan sendiri yang saya bangun saat menjalankan layanan Java Spring Boot di Docker Swarm dalam riset skripsi. Angka-angka itu saya kutip hanya sebagai hasil saya, lengkap dengan tautan ke tulisan penuhnya, sedangkan semua pernyataan tentang perilaku Kubernetes dan Swarm saya ambil dari dokumentasi resminya. Saya tidak membenchmark Kubernetes, jadi sengaja tidak ada angka kecepatan Swarm versus Kubernetes di sini. ## Yang Swarm berikan, dan satu hal yang tidak Swarm mode sudah built-in di Docker Engine. Halaman overview resminya mencantumkan scaling, desired state reconciliation, rolling update, load balancing, service discovery, dan multi-host networking sebagai fitur utama, dan itu benar-benar cukup untuk menjalankan platform multi-service. Anda mendeklarasikan berapa task yang diinginkan untuk sebuah service, lalu manager menambah atau mengurangi task sampai kenyataan cocok dengan deklarasi. Yang tidak tercantum di halaman yang sama adalah autoscaling. Scaling di Swarm berarti mendeklarasikan sebuah angka, dan angka itu hanya berubah kalau ada sesuatu yang menjalankan perintah scale. Dalam kasus saya sesuatu itu tidak ada, sehingga setiap service berjalan dengan satu replica dan tak seorang pun tahu di mana titik patahnya. Celah itu, bukan rasa tidak suka pada Swarm, alasan jujur mengapa pertanyaan soal Kubernetes muncul. ## Apa kata load test saya soal menambah replica Sebelum berdebat soal orchestrator, ada baiknya tahu apa sebenarnya yang dibeli oleh replica tambahan. Saya menjalankan load test k6 pada endpoint tulis tersibuk di layanan itu, dengan 10 virtual user selama 120 detik di setiap perbandingan, sehingga tiap run apple to apple. Dalam load test saya, yang saya uraikan lengkap di artikel load testing Swarm pindah dari satu replica ke dua menurunkan latensi p95 dari 8,40 detik menjadi 4,50 detik, tetapi throughput hanya bergerak dari 1,72 ke 1,88 iterasi per detik. Satu replica dengan tuning PostgreSQL dan connection pool mencapai 2,27 iterasi per detik dengan p95 3,65 detik, dan dua replica yang sudah di-tuning justru lebih buruk dari satu replica itu, yaitu 2,00 iterasi per detik dengan p95 5,43 detik. Penyebabnya row lock: setiap request mengubah baris yang sama, jadi replica tambahan hanya berarti lebih banyak session yang mengantre. Ini temuan paling berguna untuk keputusan Swarm atau Kubernetes. Dari sudut pandang database, kedua orchestrator menambah replica dengan cara yang sama. Kalau batasnya adalah shared state, orchestrator yang Anda pilih tidak mengubah ceiling-nya. ## Autoscaling: daemon di bawah 80 baris versus HPA deklaratif Karena Swarm tidak punya autoscaler, saya menulis sendiri, dan artikel custom autoscaler memuat Bash lengkapnya. Daemon itu polling CPU tiap 10 detik, scale out setelah dua sampel berturut-turut di atas 70 persen, scale in setelah tiga sampel di bawah 30 persen, lalu menolak bertindak lagi selama cooldown 90 detik. Pada load test bertahap saya, ia menaikkan dari satu ke dua replica pada detik ke-52 dan menekan lonjakan palsu 92 persen selama cooldown. Kubernetes menyertakan loop ini. Dokumentasi HPA resmi menjelaskan control loop yang berjalan tiap 15 detik secara default dan menghitung jumlah replica yang diinginkan sebagai jumlah saat ini dikali rasio metrik saat ini terhadap target, dibulatkan ke atas. Scale down diredam oleh stabilization window default 300 detik, scale up tanpa window, dan perubahan dalam toleransi default 10 persen diabaikan. Menurut pembacaan saya atas rumusnya, HPA bekerja menuju satu nilai target, bukan dua ambang 70 dan 30 milik saya, sehingga asimetri saya dipetakan ke blok behavior. Harganya adalah prasyaratnya: metrik CPU berasal dari Metrics Server yang dipasang terpisah, dan Pod tanpa CPU request punya utilization yang tidak terdefinisi, sehingga autoscaler tidak melakukan apa pun untuknya. Satuan daemon saya dan HPA berbeda. Daemon saya membaca docker stats, yang melaporkan persen dari satu core sehingga container bisa melewati 100 persen. Utilization HPA adalah persentase dari CPU request container. Kalau ambang saya disalin mentah-mentah, scaling Anda akan salah dengan cara yang tampak masuk akal. ## Perbandingannya, tanpa bumbu marketing Tabel ini hanya memuat perbedaan yang bisa saya telusuri ke dokumentasi Docker atau Kubernetes, atau ke build saya sendiri. Di sel yang menggambarkan pekerjaan saya sendiri, hal itu disebutkan. | | | | | --- | --- | --- | | Autoscaling | Tidak ada bawaan. Scaling adalah jumlah replica yang dideklarasikan, diubah lewat docker service scale. Loop-nya saya tulis sendiri. | HorizontalPodAutoscaler bawaan, dengan loop default 15 detik, stabilization window, dan scaling policy. | | Sinyal untuk scaling | Apa pun yang bisa diukur script Anda. Punya saya hanya CPU, yang saya tandai sebagai keterbatasan. | Metrik resource, custom, object, dan external, meski custom dan external butuh metric adapter tambahan. | | Ketersediaan control plane | Manager menjalankan Raft. Tiga manager menoleransi satu kegagalan, lima menoleransi dua. Kalau quorum hilang, manajemen berhenti sementara task yang berjalan tetap jalan. | Dokumen menyebut control plane satu mesin tidak highly available dan menyarankan service control plane di minimal tiga mesin, plus backup etcd rutin. | | Kontrol akses | Anda mengakses swarm lewat manager. Izin per tim yang rinci bukan bagian dari yang diiklankan overview-nya. | Panduan production merekomendasikan RBAC dan policy untuk cluster bersama dengan lebih dari satu atau dua pengguna. | | Siapa yang menjalankan cluster | Anda sendiri. Overview Swarm tidak menjelaskan opsi managed. | Control plane, worker node, atau keduanya bisa diserahkan ke provider, seperti disarankan panduan production itu sendiri. | | Hal yang harus dipelajari | Sedikit. Satu Engine, service, stack, dan admin guide Raft. | Banyak. Komponen control plane, add-on seperti Metrics Server, dan object model di sekitarnya. | Baca tabel ini sebagai buku besar tentang apa yang harus Anda bangun atau beli. Kubernetes membuat baris autoscaling dan kontrol akses lebih murah dan baris belajar lebih mahal. Swarm kebalikannya. ## Kapan Swarm tidak lagi cukup untuk tim kecil Saya tidak akan pindah hanya karena Kubernetes adalah standar industri. Saya pindah bila salah satu ini benar, dan masing-masing didukung tabel atau pekerjaan saya sendiri: - Anda perlu autoscaling berdasarkan sinyal selain satu angka CPU, dan lelah merawat decision loop buatan sendiri beserta tes-nya. - Lebih dari beberapa orang melakukan deploy ke cluster yang sama dan Anda butuh pemisahan nyata atas apa yang boleh disentuh masing-masing. - Anda tidak bisa menerima bahwa hilangnya quorum manager membekukan semua perubahan, dan lebih memilih membayar provider untuk menjalankan control plane. - Anda bergantung pada tooling yang menargetkan Kubernetes dan tidak punya padanan di Swarm. Kegagalan yang akan saya waspadai berbeda. Autoscaler CPU, punya saya maupun HPA, terus menambah replica selama CPU menjadi sinyalnya, dan ketika batas sebenarnya adalah row lock, replica tambahan hanya mengantre. Dalam kasus saya, autoscaler akan konvergen ke ceiling 2,27 iterasi per detik yang sama dengan hasil tuning. Pindah orchestrator lebih dulu akan memakan berminggu-minggu dan angka itu tetap tidak berubah. ## Yang akan saya ubah, dan batas bukti ini Angka saya berasal dari satu layanan, satu endpoint, dan satu database staging dengan satu hot row, dan semuanya adalah pengukuran Swarm saja. Saya belum menjalankan tes yang sama di Kubernetes, jadi saya tidak bisa bilang Kubernetes lebih cepat, lebih lambat, atau setara. Ambang 70 dan 30, jumlah streak, dan cooldown 90 detik adalah pilihan desain untuk layanan itu, bukan rekomendasi. Kalau mengulang, saya akan memprofil database sebelum membangun logika scaling apa pun, dan sejak awal memakai metrik berbasis CPU request alih-alih docker stats mentah, supaya pindah ke HPA nanti berupa penerjemahan, bukan penulisan ulang. Saya juga akan menambah sinyal latensi di samping CPU, karena CPU saja buta terhadap lock itu. ## Checklist hari Senin Jalankan load test di jalur tulis tersibuk dengan profil tetap, dan bandingkan satu replica dengan dua sebelum menyentuh orchestrator. Query lock database selama tes itu dan cari banyak session yang menunggu baris atau tabel yang sama. Catat mana dari empat pemicu di bagian sebelumnya yang benar-benar berlaku untuk tim Anda hari ini. Kalau tetap di Swarm, hitung manager Anda, buat jumlahnya ganjil, dan uji apa yang terjadi pada deploy ketika satu mati. Kalau pindah, pasang CPU request di setiap container lebih dulu, karena HPA tidak bisa menghitung utilization tanpanya. Pilih Swarm atau Kubernetes berdasarkan apa yang harus Anda bangun atau beli, bukan berdasarkan kata benchmark soal replica. Load test saya menunjukkan replica hanya membantu sampai shared resource menjadi batasnya, dan tidak ada orchestrator yang memindahkan batas itu. Perbaiki bottleneck dulu, lalu bayar autoscaling dan kontrol akses yang bisa Anda sebutkan namanya. ## Sumber - Docker Docs: overview Swarm mode dan daftar fiturnya - Docker Docs: Administer and maintain a swarm (manager dan quorum Raft) - Kubernetes Docs: Horizontal Pod Autoscaling - Kubernetes Docs: Production environment - Docker Docs: referensi docker service scale ## Source links - https://docs.docker.com/engine/swarm/ - https://docs.docker.com/engine/swarm/admin_guide/ - https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/ - https://kubernetes.io/docs/setup/production-environment/ - https://docs.docker.com/reference/cli/docker/service/scale/ ## FAQ ### Apakah Docker Swarm punya autoscaling bawaan seperti HPA Kubernetes? Tidak. Overview Swarm mencantumkan scaling manual, yaitu Anda mendeklarasikan jumlah task per service, dan tidak menyebut autoscaling. Kubernetes menyertakan Horizontal Pod Autoscaler yang menjalankan control loop tiap 15 detik secara default. Di Swarm Anda butuh script, seperti daemon Bash buatan saya, untuk memutuskan kapan memanggil docker service scale. ### Apakah Docker Swarm cukup untuk tim kecil di production? Bisa, kalau Anda sanggup tanpa autoscaling bawaan dan kontrol akses yang rinci. Dari pengalaman saya menjalankan platform multi-service di Swarm, orchestrator bukan penyebab batas performanya. Pindahlah ketika muncul kebutuhan konkret, seperti izin multi-tim atau control plane managed. ### Apakah pindah dari Swarm ke Kubernetes akan menaikkan throughput saya? Tidak dalam kasus saya. Pada load test saya, menggandakan replica di Swarm hanya menaikkan throughput sekitar 9 persen karena setiap request mengunci baris database yang sama. Kubernetes menambah replica dengan cara yang sama, jadi row lock tetap menjadi ceiling-nya. Saya tidak membenchmark Kubernetes, jadi saya tidak membuat klaim kecepatan. ### Apa yang terjadi pada cluster Docker Swarm jika manager kehilangan quorum? Manajemen berhenti: Anda tidak bisa menambah atau menghapus node, maupun memulai, menghentikan, memindahkan atau memperbarui task. Task yang sudah berjalan di worker tetap berjalan. Admin guide Docker menyarankan mengembalikan manager yang hilang, dan sebagai upaya terakhir memakai docker swarm init dengan flag force-new-cluster. ### Apa yang saya butuhkan sebelum memakai HPA Kubernetes berbasis CPU? Anda butuh Metrics Server, yang menurut dokumen dijalankan terpisah, dan CPU request di setiap container. Utilization HPA adalah persentase dari request, jadi tanpanya utilization tidak terdefinisi dan autoscaler tidak bertindak. Itu juga sebabnya ambang dari docker stats tidak bisa disalin begitu saja. --- - HTML version: https://www.matthewswong.com/id/blog/docker-swarm-vs-kubernetes-small-team-load-test/ - English: https://www.matthewswong.com/en/blog/docker-swarm-vs-kubernetes-small-team-load-test/ - Site index for agents: https://www.matthewswong.com/llms.txt - Sitemap: https://www.matthewswong.com/sitemap.xml - API description (OpenAPI): https://www.matthewswong.com/openapi.json