Belajar DevOps Engineer - Kubernetes Dasar

#Pendahuluan

Di episode 7 kita membungkus aplikasi menjadi image Docker dan menjalankannya dengan docker run. Sekarang bayangkan skala produksi: bukan satu container, tapi seratus container yang harus jalan di lima belas mesin, dengan request yang naik turun, node yang mati mendadak, dan rilis yang harus berjalan tanpa downtime. docker run tidak cukup — ini masalah yang diselesaikan Kubernetes (K8s), orkestrator container yang menjadi standar de facto industri.

Kubernetes adalah salah satu proyek terbesar di ekosistem CNCF dan hampir selalu menjadi syarat wajib lowongan DevOps Engineer. Di episode ini kalian membangun fondasi: mengenal arsitektur cluster dan objek inti, lalu men-deploy aplikasi nyata. Versi lanjutannya — Helm, RBAC, autoscaling, service mesh — menunggu di episode 13.

#Anatomi Cluster

Sebuah cluster Kubernetes terdiri dari dua kelompok mesin dengan peran yang sangat berbeda:

• Control plane — "otak" cluster: API Server (gerbang semua komunikasi), etcd (database cluster yang menyimpan seluruh state), Scheduler (memutuskan container jalan di node mana), dan Controller Manager (menjaga kondisi aktual sesuai yang diminta).
• Worker node — mesin yang menjalankan workload: kubelet (agen yang berkomunikasi dengan API Server) dan container runtime (containerd, cri-o) yang benar-benar menjalankan container.

Kalian berinteraksi dengan cluster melalui kubectl, yang semua perintahnya menuju API Server. Tidak ada akses langsung ke node.

#Objek Inti yang Wajib Dikuasai

Sebelum praktik, kenali lima objek yang akan kalian pakai setiap hari:

Pola penting yang harus kalian pahami: Deployment → Pod → Service. Deployment membuat Pod; Pod bersifat sementara dan IP-nya bisa berubah; Service menyediakan alamat stabil di depannya.

#Praktik: Deploy Aplikasi ke Cluster

Mari deploy aplikasi dari episode 7. Mulai dengan mengelompokkan konfigurasi ke ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: myapp-config
data:
  NODE_ENV: production
  APP_PORT: "3000"

Lalu Deployment yang menjalankan image kita dengan tiga replica:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: ghcr.io/username/myapp:1.2.0
          ports:
            - containerPort: 3000
          envFrom:
            - configMapRef:
                name: myapp-config

Dan Service yang membuat Pod terhubung ke dunia luar dengan alamat stabil:

apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 3000
  type: ClusterIP

Terapkan dan amati:

Terapkan ke cluster

kubectl apply -f configmap.yaml
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl get pods
kubectl get deployments
kubectl get svc myapp
kubectl port-forward svc/myapp 8080:80

Untuk menguji self-healing, hapus salah satu Pod dan perhatikan Deployment langsung membuat penggantinya:

Uji self-healing

kubectl delete pod myapp-<id>
kubectl get pods -w

#Ekspose ke Luar: Ingress

ClusterIP hanya bisa diakses dari dalam cluster. Untuk menerima traffic HTTP dari pengguna, pasang Ingress — gerbang L7 yang bisa mengatur path, host, dan TLS:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: myapp
                port:
                  number: 80

Verifikasi ingress

kubectl apply -f ingress.yaml
kubectl get ingress

#Pitfall Umum

• Menaruh rahasia di ConfigMap — ConfigMap disimpan sebagai plaintext. Secret (episode 16) adalah tempatnya.
• Lupa memilih image dengan tag — latest akan menimbulkan perilaku tidak terduga saat rollout.
• Mengedit Deployment langsung di prod — konfigurasi harus masuk Git (basis untuk GitOps di episode 14).
• Pod langsung, bukan Deployment — Pod tanpa controller tidak akan diganti saat mati.
• Resource request/limit tidak diset — satu Pod bisa melahap semua CPU node. Kita bahas HPA dan resource management di episode 13.

#Penutup

Inti yang harus dibawa pulang:

• Cluster = control plane (API, etcd, scheduler) + worker nodes (kubelet, runtime).
• Objek inti: Pod, Deployment, Service, ConfigMap/Secret, Ingress — dengan pola Deployment → Pod → Service → Ingress.
• kubectl apply membuat state yang diminta; controller di control plane yang mewujudkannya.
• Kubernetes memberi self-healing dan desired state — kalian deklaratif "ingin 3 replica", bukan "jalankan container ini".

Di episode 9 selanjutnya kita belajar Infrastructure as Code dengan Terraform — cara memprovision seluruh infrastruktur (VM, network, registry, bahkan cluster Kubernetes itu sendiri) sebagai kode yang bisa direview, diuji, dan di-reproduce. Konsep "desired state" yang kalian lihat di Kubernetes ternyata berulang di Terraform.