Docker Swarm vs Kubernetes: Vonis Load Test Tim Kecil

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.

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.

# Swarm: the whole scaling API is one imperative command.
# Something you write has to decide WHEN to run it (see the daemon post).
docker service scale my-stack_api=3

# Kubernetes: the decision loop is built in. You declare the target and
# the damping instead of writing the loop.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 1
  maxReplicas: 4
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70   # percent of the container's CPU REQUEST
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0      # react at once (the default)
    scaleDown:
      stabilizationWindowSeconds: 300    # wait before removing replicas

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.

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.

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

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.

Bacaan terkait

• Orkestrasi Docker Swarm untuk production
• Docker Compose vs Kubernetes untuk tim kecil
• Kubernetes HPA scale to zero untuk worker antrean GPU