Deploy Kubernetes di VPS Anti-Drama: Pakai 8 Strategi Ini

Banyak yang mengira Kubernetes hanya cocok untuk cloud besar seperti EKS atau GKE. Padahal, kamu bisa deploy Kubernetes di VPS selama resource dan konfigurasinya tepat. Strategi deploy Kubernetes di VPS mencakup setup cluster, pemilihan metode rilis, hingga rollback agar aplikasi tetap stabil saat diperbarui. Artikel ini membahas langkah setup dan strategi yang bisa kamu pilih.

Apakah Bisa Deploy Kubernetes di VPS?

Jawabannya: bisa.

Kubernetes bukan layanan yang hanya berjalan di AWS, Google Cloud, atau penyedia cloud computing tertentu. Pada dasarnya, Kubernetes adalah platform orkestrasi container yang bisa dijalankan di infrastruktur milik sendiri, termasuk VPS.

Yang perlu diperhatikan adalah kapasitas VPS. Menjalankan satu aplikasi container sederhana jelas berbeda dengan menjalankan cluster berisi beberapa worker, database, monitoring, dan ingress controller.

Untuk belajar atau testing, satu VPS dengan resource terbatas masih cukup. Namun, untuk produksi, idealnya control plane dan worker node dipisahkan agar kegagalan satu mesin tidak langsung membuat seluruh aplikasi berhenti.

Baca Juga: Perbedaan Docker vs Kubernetes, Bisakah Digunakan Bersama?

Sebagai gambaran, setup cluster Kubernetes sederhana membutuhkan:

• Linux 64-bit, misalnya Ubuntu LTS.
• Akses root atau sudo.
• Minimal 2 GB RAM untuk node dengan beban ringan; lebih lega jika tersedia 4 GB atau lebih.
• Minimal 2 vCPU untuk kebutuhan belajar/testing.
• Swap dinonaktifkan sesuai konfigurasi Kubernetes yang digunakan.
• Network antar-node yang stabil.
• Port Kubernetes dan kebutuhan networking antar-node dapat saling terhubung.
• Container runtime seperti containerd.

Jadi, pertanyaannya bukan sekadar “bisa atau tidak”, melainkan seberapa besar cluster yang ingin kamu jalankan.

Baca Juga: Scaling Server Cloud: Horizontal atau Vertical, Pilih Mana?

Kenalan Dulu dengan Deployment di Kubernetes

Sebelum masuk ke strategi deployment, ada satu konsep yang perlu dipahami: objek Deployment di Kubernetes.

Apa itu Deployment?

Deployment adalah objek yang mengelola sekumpulan Pod dengan konfigurasi aplikasi yang sama.

Misalnya aplikasi web kamu membutuhkan tiga instance. Daripada membuat dan mengelola tiga Pod secara manual, Deployment akan memastikan jumlah replika tersebut tetap tersedia.

Kalau satu Pod mati, Kubernetes dapat membuat penggantinya. Kalau aplikasi perlu scale dari tiga menjadi lima replika, jumlah tersebut juga bisa dikelola melalui Deployment.

Di sinilah Kubernetes mulai terasa praktis: kamu lebih banyak mendefinisikan kondisi yang diinginkan, sementara Kubernetes menangani proses untuk mempertahankannya.

Pod, ReplicaSet, dan Deployment

Hubungannya cukup sederhana:

• Pod: unit terkecil tempat container aplikasi berjalan.
• ReplicaSet: memastikan jumlah Pod sesuai target.
• Deployment: mengelola ReplicaSet sekaligus proses update versi aplikasi.
• Label: penanda untuk mengelompokkan dan memilih resource.
• Service: menyediakan endpoint stabil untuk mengarahkan traffic ke Pod.

Contohnya, kamu menentukan replicas: 3. Deployment kemudian membuat ReplicaSet yang menjaga agar selalu ada tiga Pod aktif.

Kalau satu Pod crash, ReplicaSet akan membuat penggantinya. Jadi, kamu tidak perlu terus-menerus mengecek apakah setiap Pod masih hidup.

Anatomi Manifest Deployment

Manifest Kubernetes biasanya ditulis dalam YAML. Beberapa bagian yang penting antara lain:

spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: web

replicas menentukan jumlah Pod, selector menentukan Pod yang dikelola, template menjadi cetak biru Pod, sedangkan strategy menentukan bagaimana perubahan versi dilakukan.

Nah, bagian strategy inilah yang nantinya menentukan apakah proses deployment kamu mulus atau justru bikin drama.

8 Strategi Deploy Kubernetes yang Bisa Kamu Pakai

Setelah cluster siap, tantangan berikutnya adalah menentukan bagaimana versi baru aplikasi menggantikan versi lama.

Tidak semua deployment harus menggunakan strategy yang sama. Pertimbangkan tiga hal: risiko perubahan, kebutuhan downtime, dan resource VPS yang tersedia.

#1. Recreate Deployment

Recreate adalah pendekatan paling sederhana: Pod versi lama dihentikan terlebih dahulu, kemudian Pod versi baru dibuat.

Konsekuensinya jelas: ada downtime.

Strategi ini cocok untuk aplikasi yang memang membutuhkan semua instance menggunakan versi yang sama dalam waktu bersamaan, atau workload seperti batch job yang tidak sensitif terhadap downtime.

#2. Rolling Update Kubernetes

Kalau kamu ingin menghindari downtime, rolling update Kubernetes biasanya menjadi pilihan pertama.

Pod lama diganti secara bertahap sehingga sebagian instance tetap melayani traffic selama proses update.

Dua parameter penting adalah:

• maxUnavailable: jumlah maksimum Pod yang boleh unavailable.
• maxSurge: jumlah Pod tambahan yang boleh dibuat selama update.

Readiness probe juga penting. Kubernetes sebaiknya tidak langsung menganggap Pod baru siap menerima traffic hanya karena containernya berhasil berjalan.

Dengan readiness probe, Pod baru harus benar-benar siap terlebih dahulu sebelum traffic diarahkan kepadanya.

#3. Blue/Green Deployment

Pada blue green deployment, kamu menjalankan dua versi aplikasi secara bersamaan.

Misalnya:

• Blue = versi lama.
• Green = versi baru.

Traffic awalnya diarahkan ke Blue. Setelah Green selesai diuji dan dianggap aman, Service diarahkan ke Green.

Keunggulannya adalah rollback cepat. Kalau versi baru bermasalah, traffic bisa dikembalikan ke Blue.

Kekurangannya: resource yang dibutuhkan bisa hampir dua kali lipat karena dua versi aplikasi berjalan bersamaan.

Untuk VPS dengan RAM terbatas, ini perlu dihitung sejak awal.

#4. Canary Deployment

Canary deployment memungkinkan kamu memperkenalkan versi baru secara bertahap.

Misalnya, hanya sebagian traffic yang diarahkan ke versi baru. Kalau metrik kesehatan aplikasi tetap bagus, porsi traffic bisa dinaikkan.

Pendekatan sederhana bisa dilakukan dengan mengatur jumlah replika. Namun, kontrol traffic berdasarkan persentase yang presisi biasanya membutuhkan ingress controller, service mesh, atau deployment controller tertentu.

Canary cocok untuk aplikasi dengan traffic tinggi karena kesalahan versi baru tidak langsung berdampak ke seluruh pengguna.

#5. A/B Testing Deployment

A/B testing deployment berbeda dari canary.

Di sini, pembagian traffic tidak harus berdasarkan persentase. Routing bisa ditentukan berdasarkan karakteristik request, misalnya header, jenis pengguna, lokasi, atau kelompok eksperimen.

Contohnya, pengguna dengan header tertentu diarahkan ke versi B, sedangkan pengguna lainnya tetap menggunakan versi A.

Pendekatan ini biasanya membutuhkan Ingress atau service mesh agar aturan routing bisa dibuat lebih granular.

#6. Shadow Deployment

Pada shadow deployment, traffic produksi dicerminkan ke versi baru, tetapi respons dari versi baru tidak diberikan kepada pengguna.

Dengan begitu, kamu bisa menguji versi baru menggunakan pola traffic nyata tanpa mempertaruhkan pengalaman pengguna.

Strategi ini menarik untuk perubahan yang berisiko tinggi, terutama ketika synthetic testing belum cukup menggambarkan kondisi produksi.

#7. Best-Effort Controlled Rollout

Pendekatan ini mirip canary, tetapi perpindahan traffic dilakukan secara lebih terkontrol berdasarkan kondisi tertentu.

Misalnya, traffic dinaikkan bertahap dari 20%, 40%, hingga 100%, dengan jeda untuk memeriksa error rate, latency, CPU, atau metrik lainnya.

Tool seperti Argo Rollouts dapat membantu mengotomatisasi proses tersebut.

#8. Ramped Slow Rollout

Ramped slow rollout juga mengganti Pod secara bertahap, tetapi memberikan jeda di antara setiap tahap.

Tujuannya sederhana: jangan buru-buru.

Setelah sebagian kecil Pod diperbarui, kamu punya waktu untuk memeriksa log dan metrik sebelum melanjutkan ke tahap berikutnya.

Untuk deployment yang cukup sensitif, pola ini bisa menjadi kompromi menarik antara rolling update sederhana dan canary yang lebih kompleks.

Perbandingan Strategi Deployment Kubernetes

Strategi	Downtime	Rollback	Resource	Kompleksitas	Cocok untuk
Recreate	Ada	Sedang	Rendah	Rendah	Batch/job
Rolling	Minim/tidak ada	Sedang	Rendah	Rendah	Aplikasi stateless
Blue/Green	Minim	Sangat cepat	Tinggi	Sedang	Aplikasi kritis
Canary	Minim	Cepat	Sedang	Sedang	Traffic tinggi
A/B Testing	Minim	Cepat	Sedang-tinggi	Tinggi	Eksperimen fitur
Shadow	Tidak untuk user	Cepat	Tinggi	Tinggi	Pengujian production traffic
Controlled Rollout	Minim	Cepat	Sedang	Tinggi	Deployment bertahap
Ramped Slow	Minim	Cepat	Sedang	Sedang-tinggi	Update berisiko

Strategi Mana yang Cocok untuk VPS?

Di VPS, resource adalah pertimbangan utama.

Kalau RAM hanya pas-pasan, blue green deployment bisa menjadi pilihan yang kurang ideal karena kamu harus menjalankan dua environment sekaligus.

Untuk aplikasi stateless, rolling update biasanya sudah lebih dari cukup.

Aplikasi stateful perlu perhatian ekstra. Dalam banyak kasus, StatefulSet lebih tepat daripada Deployment karena identitas dan storage Pod perlu dipertahankan.

Untuk aplikasi kritis, blue/green bisa masuk akal jika VPS memiliki resource cadangan. Sementara itu, aplikasi dengan traffic tinggi dapat memanfaatkan canary agar perubahan tidak langsung diberikan kepada seluruh pengguna.

Untuk batch processing atau background job, recreate atau rolling deployment sering kali sudah memadai.

Prinsip yang paling aman: mulai dari strategi paling sederhana yang memenuhi kebutuhanmu.

Tidak perlu memasang Istio atau Argo hanya karena terdengar lebih canggih. Setiap komponen tambahan berarti ada konfigurasi, resource, monitoring, dan maintenance yang harus kamu tangani.

Dalam banyak kasus, kombinasi rolling update + canary sudah menjadi fondasi deployment yang solid.

Best Practice Biar Deploy Kubernetes Anti-Drama

Strategi deployment yang bagus tetap membutuhkan fondasi yang benar.

• Hindari image tag latest untuk produksi. Gunakan tag versi yang spesifik supaya kamu tahu persis image mana yang sedang berjalan.
• Gunakan readiness probe dan liveness probe. Keduanya membantu Kubernetes membedakan container yang sekadar hidup dengan aplikasi yang benar-benar siap menerima traffic.
• Tetapkan requests dan limits CPU/RAM. Ini sangat penting di VPS karena resource lebih terbatas dibanding cluster cloud besar.
• Selalu uji deployment sebelum production. Minimal periksa log, endpoint utama, error rate, latency, dan resource consumption.
• Siapkan monitoring. Prometheus dan Grafana atau solusi observability sejenis dapat membantu melihat masalah sebelum pengguna yang menemukannya.

Untuk produksi yang serius, jangan lupakan backup etcd, redundansi control plane, RBAC, firewall, serta update keamanan secara berkala.

Deployment tanpa monitoring ibarat menyetir malam-malam tanpa dashboard. Aplikasinya mungkin tetap berjalan, tetapi kamu tidak punya cukup informasi saat sesuatu mulai bermasalah.

Kesimpulan

Deploy Kubernetes di VPS bukan berarti memaksakan teknologi besar ke server kecil. Justru, dengan pemilihan distribusi, resource, dan strategi deployment yang tepat, VPS bisa menjadi fondasi cluster yang efisien untuk development maupun aplikasi produksi skala tertentu.

Mulai dari yang sederhana. Untuk kebanyakan aplikasi stateless, rolling update Kubernetes adalah titik awal yang masuk akal. Saat kebutuhan meningkat, kamu bisa berkembang ke canary, blue green deployment, A/B testing deployment, shadow, atau controlled rollout.

Yang tidak kalah penting, hitung resource sejak awal. Kalau kamu membutuhkan VPS untuk menjalankan Kubernetes dengan resource yang lebih lega tanpa langsung masuk ke infrastruktur cloud yang kompleks, VPS Murah dari IDwebhost bisa menjadi salah satu opsi yang layak dipertimbangkan sebagai fondasi cluster.

Dengan spesifikasi VPS yang sesuai, konfigurasi keamanan yang benar, dan strategi deployment yang tidak berlebihan, proses rilis aplikasi bisa tetap cepat tanpa harus berubah menjadi sesi debugging tengah malam.