k3s Kubernetes Ringan untuk Startup Indonesia: Setup Produksi di VPS Budget

Kubernetes upstream yang dipasang dengan kubeadm mensyaratkan minimal 2 GB RAM per mesin, termasuk worker, dan 2 CPU untuk mesin control plane, dan itu kendala nyata bagi startup Indonesia di paket VPS level awal Biznet, IDCloudHost, atau Hostinger (dulu Niagahoster). k3s, distribusi Kubernetes ringan yang dibuat Rancher dan kini menjadi proyek CNCF Sandbox, mensyaratkan minimum yang sama untuk node server, yaitu 2 core dan 2 GB, tetapi hanya 1 core dan 512 MB untuk agent, serta hadir sebagai satu binary dengan SQLite sebagai datastore default dan service load balancer bawaan. Panduan ini membahas cluster k3s 3-node tingkat produksi yang menjalankan workload nyata.

k3s vs Kubernetes Penuh: Apa yang Berbeda

k3s tetap konform dengan Kubernetes upstream dan saat ini hanya menghapus dua hal: storage driver in-tree dan cloud provider in-tree, yang keduanya punya pengganti out-of-tree (driver CSI dan cloud controller manager). Rilis awal k3s menghapus lebih banyak komponen, dan dari situlah deskripsi lama berasal. k3s memakai SQLite secara default untuk satu server (etcd tertanam untuk HA, atau MySQL, MariaDB, Postgres, maupun etcd eksternal) dan membawa containerd, Flannel CNI, CoreDNS, Traefik ingress, ServiceLB, network policy controller kube-router, serta local-path-provisioner. k3s mengirimkan hasil uji konformitas CNCF untuk setiap versi minor Kubernetes (1.35 hingga 1.37 per 17 Oktober 2026), sehingga perintah kubectl standar dan manifest Kubernetes bekerja tanpa modifikasi.

Perbandingan Kebutuhan Resource

Dokumentasi k3s mencantumkan minimum 2 core CPU dan 2 GB RAM untuk node server, serta 1 core dan 512 MB untuk agent; kubeadm meminta 2 GB RAM di setiap mesin dan 2 CPU di mesin control plane. Jadi penghematannya ada di worker, bukan di control plane. Resource profiling resmi k3s mengukur server dengan workload uji di sekitar 1,6 GB RAM pada persentil ke-95, dan agent di sekitar 275 MB. Siapkan server dengan 2 GB atau lebih dan jangan berharap banyak ruang tersisa untuk workload di sana; agent bisa jauh lebih kecil daripada worker kubeadm.

Kapan Memilih k3s daripada Managed Kubernetes

k3s adalah pilihan tepat ketika tim Anda punya kapasitas operasional untuk mengelola cluster kecil, workload Anda muat di 3–5 node, dan Anda ingin tidak terikat pada satu vendor cloud. Biaya control plane terkelola sering kali bukan biaya penentu: menurut halaman harga per 17 Oktober 2026, GKE mengenakan biaya tetap $0,10 per cluster per jam tetapi kredit free tier-nya menutup satu cluster zonal atau Autopilot per billing account, dan DigitalOcean menyertakan control plane DOKS tanpa biaya, hanya menagih tambahan untuk control plane high availability. Yang Anda bayar di kedua layanan itu adalah worker node; dengan k3s, Anda membayarnya dengan waktu 2–5 engineer untuk upgrade, backup, dan penanganan insiden.

Menginstal k3s: Node Server dan Agent

Instalasi k3s adalah satu perintah curl yang mengunduh, menginstal, dan menjalankan k3s sebagai layanan systemd atau openrc. Node server mengekspos API Kubernetes pada port 6443 dan menyimpan token node di /var/lib/rancher/k3s/server/node-token yang dipakai agent untuk bergabung. Untuk setup 3-node produksi di VPS budget, gunakan 1 node server dan 2 node agent: ini memberi redundansi workload, tetapi control plane tetap menjadi single point of failure. Control plane high availability dengan etcd tertanam membutuhkan tiga node server atau lebih (jumlah ganjil, demi quorum), atau dua server atau lebih dengan database eksternal seperti MySQL atau Postgres.

Perintah Instalasi Server dan Agent

Script instalasi menerima environment variable dan flag yang menyesuaikan k3s tanpa file konfigurasi terpisah. Memberikan --tls-san dengan IP publik atau domain server menambahkannya sebagai Subject Alternative Name pada sertifikat API server, yang dibutuhkan kubectl saat terhubung dari luar cluster. Kubeconfig admin dimiliki root dengan mode 600, jadi jalankan kubectl di server dengan sudo (atau atur --write-kubeconfig-mode). Setelah agent bergabung, periksa cluster dengan sudo kubectl get nodes -o wide; setiap node harus berstatus Ready.

#!/bin/bash
# 1. Install k3s server node (control plane)
curl -sfL https://get.k3s.io | sh -s - server \
  --disable traefik \
  --flannel-backend=vxlan \
  --tls-san=YOUR_PUBLIC_IP

# 2. Retrieve node token for agents
K3S_TOKEN=$(sudo cat /var/lib/rancher/k3s/server/node-token)
echo "Token: $K3S_TOKEN"

# 3. Join agent nodes (run on each worker VPS; paste the token from step 2)
curl -sfL https://get.k3s.io | K3S_URL=https://SERVER_IP:6443 \
  K3S_TOKEN=PASTE_NODE_TOKEN sh -

# 4. Verify cluster (the admin kubeconfig is root-owned, mode 600)
sudo kubectl get nodes -o wide

---
# sample-deployment.yaml — runs on k3s unchanged
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: production
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web-app
        image: nginx:1.30-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "50m"
          limits:
            memory: "128Mi"
            cpu: "200m"
---
apiVersion: v1
kind: Service
metadata:
  name: web-app-svc
  namespace: production
spec:
  selector:
    app: web-app
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

Mengonfigurasi kubectl untuk Akses Remote

k3s menulis kubeconfig admin ke /etc/rancher/k3s/k3s.yaml dengan alamat server diatur ke 127.0.0.1. Salin file ini ke mesin Anda dan ganti 127.0.0.1 dengan IP publik atau nama server. Arahkan KUBECONFIG ke file tersebut, atau gabungkan ke konfigurasi yang sudah ada dengan mengisi KUBECONFIG dengan kedua path lalu menyimpan output kubectl config view --flatten. k3s memperbarui sertifikat di salinannya sendiri setiap kali start, jadi perbarui salinan Anda ketika sertifikat berganti. Jangan pernah mengekspos port API (6443) secara publik tanpa allowlisting IP; batasi hanya ke alamat tim Anda dengan aturan firewall.

Storage Persisten dengan Longhorn

local-path-provisioner default k3s membuat PersistentVolume di disk lokal node tempat pod dijadwalkan; jika node itu gagal, datanya ikut hilang. Longhorn menyediakan block storage terdistribusi yang mereplikasi volume antar node, sehingga pod bisa dijadwalkan ulang tanpa kehilangan data, dan ia terintegrasi sebagai StorageClass sehingga PersistentVolumeClaim yang ada bekerja tanpa perubahan. Periksa perangkat kerasnya lebih dulu: dokumentasi Longhorn merekomendasikan minimal 3 node dengan masing-masing 4 vCPU dan 4 GiB RAM serta storage SSD atau NVMe, di atas paket VPS budget yang paling kecil. Pada node yang lebih kecil, simpan data stateful di volume local-path dengan backup yang sudah diuji, atau di database terkelola.

Menginstal dan Mengonfigurasi Longhorn

Longhorn diinstal dengan kubectl apply atau Helm chart; versi 1.13, rilis terbaru per 17 Oktober 2026, membutuhkan Kubernetes 1.34 atau lebih baru dan, untuk V1 data engine default-nya, open-iscsi di setiap node, yang bisa dicek dengan preflight check longhornctl. UI web disajikan oleh service ClusterIP longhorn-frontend tanpa autentikasi secara default, jadi aksesnya lewat kubectl port-forward atau Ingress yang memakai autentikasi. Jumlah replika default Longhorn adalah 3, dan panduannya sendiri menyarankan 3 jika Anda punya tiga node storage atau lebih, dan 2 jika kurang. Konfigurasikan backup target (kompatibel S3, NFS, SMB/CIFS, atau Azure Blob Storage) untuk backup pemulihan bencana.

Integrasi CI/CD dengan GitHub Actions

Men-deploy ke k3s dari GitHub Actions memerlukan akses ke API server (port 6443), baik dengan mengeksposnya di balik allowlist maupun lewat tunnel seperti Cloudflare Tunnel atau ngrok agar tidak terekspos publik. Simpan kubeconfig sebagai secret GitHub Actions, lalu gunakan action azure/setup-kubectl untuk memasang kubectl di pipeline. Workflow deploy lengkap mem-build Docker image, mem-push-nya ke registry, memperbarui tag image Deployment dengan kubectl set image, dan memverifikasi rollout dengan kubectl rollout status.

Resource Requests dan Limits di Node Budget

Pada node VPS budget, melupakan resource requests dan limits adalah jalan tercepat menuju cluster yang tidak stabil. Tanpa limits, pod yang bermasalah dapat menghabiskan semua memori yang tersedia dan memicu OOM killer, mengusir pod lain. Definisikan requests (jumlah yang dicadangkan untuk scheduling) dan limits (batas keras) untuk setiap deployment. Manifest di atas memulai web service kecil dengan 64Mi requests / 128Mi limits untuk memori dan 50m requests / 200m limits untuk CPU; anggap angka itu titik awal dan sesuaikan dengan pemakaian yang terukur.

Upgrade k3s dengan Zero Downtime

k3s mendukung upgrade otomatis melalui system-upgrade-controller dari Rancher, yang membaca custom resource Plan berisi node mana yang di-upgrade dan ke versi berapa, atau mengikuti release channel seperti stable (v1.36.5+k3s1 per 17 Oktober 2026). Contoh plan meng-upgrade server lebih dulu, lalu agent, satu node pada satu waktu dengan node di-cordon; drain bersifat opsional. Jangan melompati versi minor Kubernetes, karena controller tidak akan mencegah lompatan yang tidak didukung, dan tetaplah di jalur yang masih didukung: proyek Kubernetes memelihara tiga rilis minor terbaru, yaitu 1.37, 1.36, dan 1.35 per tanggal tersebut. Dengan drain diaktifkan, aplikasi yang punya minimal 2 replika dan PodDisruptionBudget tetap melayani selama setiap node di-upgrade.

Optimasi Biaya dan Strategi Skalabilitas

Biaya cluster adalah jumlah biaya node VPS-nya, jadi bandingkan daftar harga terbaru Biznet, IDCloudHost, atau Hostinger untuk ukuran di atas: server dengan minimal 2 core dan 2 GB, agent yang disesuaikan dengan workload, dan node 4 vCPU / 4 GiB jika Anda menjalankan Longhorn. Seiring workload bertumbuh, tambahkan node agent secara bertahap dengan menjalankan perintah join yang sama di setiap VPS baru. Ketika Anda melampaui 5–6 node, beralih ke layanan Kubernetes terkelola biasanya menjadi pilihan yang lebih masuk akal, karena overhead operasional mengelola lebih banyak node melebihi penghematannya.

Memantau k3s dengan Prometheus dan Grafana

Deploy Helm chart kube-prometheus-stack (Prometheus Operator, Grafana, dan Alertmanager) untuk observabilitas cluster dengan dashboard bawaan untuk CPU node, memori, disk, dan metrik workload. Pada node budget, kurangi retensi Prometheus menjadi 7 hari dan tetapkan resource requests sekitar 200m CPU / 512Mi RAM agar monitoring tidak menyesaki pod workload. Dashboard Grafana komunitas 15282 (K3S cluster monitoring) menambahkan tampilan pemakaian CPU, memori, dan filesystem per cluster, pod, container, dan layanan systemd yang dibangun dari metrik cAdvisor.

Istilah kunci dalam artikel ini meliputi k3s, Longhorn, etcd, and Flannel CNI.

Artikel Terkait

• Strategi Deployment Kubernetes: Blue-Green, Canary, dan Rolling Update
• Pipeline CI/CD dengan GitHub Actions: Dari Kode ke Produksi