Pengenalan Kubernetes — Dasar Orchestrasi | Ilmu Komputer

Tahun 2014 Google merilis Kubernetes ke publik setelah bertahun-tahun menggunakannya secara internal untuk mengelola jutaan container di produksi (sistem internal mereka bernama Borg). Kini Kubernetes dikelola oleh Cloud Native Computing Foundation (CNCF) dan menjadi standar de facto untuk orkestrasi container, digunakan oleh Netflix, Spotify, dan Adidas.

Mengapa Container Perlu Orchestrator?

Docker memudahkan kita memaket aplikasi ke dalam container. Tapi saat kamu punya 50 container di 10 server, pertanyaan muncul: container mana ditaruh di server mana? Kalau satu server mati, siapa yang pindahkan container-nya? Kalau traffic naik 10x, siapa yang nambah replica? Jawabannya: Kubernetes.

4 Komponen Inti yang Wajib Kamu Pahami

• Pod — satuan terkecil di K8s. Bisa berisi 1 atau lebih container yang berbagi storage & jaringan. Aplikasi nyata hampir selalu 1 container per pod.
• Deployment — deklarasi "saya ingin 3 replica nginx selalu jalan". Kalau satu mati, Deployment otomatis ganti.
• Service — alamat stabil (IP + DNS) untuk mengakses pod, karena pod bisa hancur & ganti IP tiap saat.
• Node — server fisik/virtual tempat pod dijalankan. Terdiri dari control-plane (otak) dan worker (kuli).

Self-Healing: Fitur yang Bikin SysAdmin Tenang

Ini perbedaan besar K8s vs script manual. Coba jalankan kubectl delete pod nginx-abc123 — dalam hitungan detik Deployment akan membuat pod pengganti. Saya pernah uji di klaster lokal: menghapus 5 dari 5 pod sekaligus, dan dalam 3 detik semuanya hidup kembali. Itulah self-healing.

Contoh Deployment Nyata

Berikut manifest lengkap yang bisa kamu kubectl apply -f:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: nginx:1.27
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "500m"
            memory: "256Mi"
---
apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  selector:
    app: web
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

Perhatikan blok resources: requests memberi tahu scheduler berapa minimal yang dibutuhkan, limits mencegah satu pod makan semua CPU node. Tanpa ini, satu pod "nakal" bisa membuat node lain ikut tumbang (noisy neighbor).

Kapan Kamu TIDAK Perlu Kubernetes?

Juice tidak selalu sepadan. Untuk 1-2 container dengan traffic rendah, docker-compose di single VPS jauh lebih sederhana. K8s baru masuk akal saat: (1) butuh scaling otomatis, (2) tim & layanan sudah multipel, (3) butuh zero-downtime deploy via rolling update.

Troubleshooting Umum

Error 1 — ImagePullBackOff. Pod stuck di status ini artinya node gagal download image. Cek kubectl describe pod — biasanya salah tag image atau registry butuh auth (tambah imagePullSecrets).

Error 2 — CrashLoopBackOff. Container nyala lalu mati terus. Penyebab umum: aplikasi exit karena env var kosong atau DB belum siap. Solusinya kubectl logs untuk lihat stack trace aslinya.

Kesimpulan

Kubernetes bukan magic — ia mengotomatisasi hal yang dulu dilakukan SysAdmin manual: penempatan container, recovery saat gagal, dan scaling. Mulai dari kind (Kubernetes in Docker) di laptopmu, pelajari 4 objek di atas, lalu naik ke minikube. Jangan langsung produksi.

Tertarik belajar lebih dalam? Kunjungi Kuliah Ilmu Komputer untuk tutorial lengkap.

Lokasi:

Berbagi :