Belajar System Engineer - Kubernetes System Ops

#Pendahuluan

Episode 7 memperkenalkan container; episode 15 ini membawa container ke skala platform. Kubernetes (K8s) telah menjadi standar orkestrasi container di dunia — dan hampir setiap System Engineer pada akhirnya akan bersinggungan dengannya, entah sebagai operator cluster maupun pengelola workload. Series ini tidak mengajarkan Kubernetes dari nol (itu tugas series Belajar Kubernetes); fokus kita di sini adalah operasi sistem — bagaimana cluster dirawat, node dikelola, dan workload dijaga tetap sehat.

Mengapa episode ini penting? Karena K8s bukan aplikasi yang "dipasang sekali lalu dilupakan". Node rusak, versi usang, pod tak terjadwal, disk penuh — semua ini adalah pekerjaan harian System Engineer yang mengoperasikan cluster. Episode ini membekali kalian mental model operasional yang benar.

#Mental Model: Cluster dan Komponen

Sebuah cluster terdiri dari control plane (otak) dan worker nodes (pekerja):

• Control plane: API server, scheduler, controller manager, etcd.
• Worker node: kubelet, container runtime, kube-proxy.

Sebagai System Engineer, kalian tidak perlu memahami setiap detail internal, tetapi wajib bisa menjawab: "di mana otak cluster, di mana data cluster (etcd), dan bagaimana cara melihat kesehatannya?"

#Operasi Cluster: Status dan Kesehatan

#Melihat Kesehatan

kubectl get nodes
kubectl get nodes -o wide
kubectl get pods -A
kubectl get events -A --sort-by=.lastTimestamp | tail -20

Perhatikan status node: Ready, NotReady, atau SchedulingDisabled. NotReady berarti kubelet di node tersebut bermasalah — biasanya karena resource habis, kubelet crash, atau koneksi ke control plane terputus.

#Menangani Node Bermasalah

Saat node perlu dipelihara (update kernel, perbaikan hardware), jangan langsung reboot. Gunakan cordon (berhenti menerima pod baru) dan drain (pindahkan pod yang ada):

kubectl cordon node-03              # stop penjadwalan pod baru
kubectl drain node-03 --ignore-daemonsets --delete-emptydir-data
# ... maintenance node ...
kubectl uncordon node-03            # aktifkan kembali

drain memindahkan pod dengan hormat (graceful). Setelah node sehat kembali, uncordon membuatnya bisa menerima pod lagi.

#Mengelola Workloads

#Deployments, Pods, Services

Model workload inti: Deployment mengelola pod yang identik; Service memberikan alamat stabil di depan pod.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: ghcr.io/corp/app-web:1.4.2
          ports:
            - containerPort: 3000
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 256Mi
          readinessProbe:
            httpGet:
              path: /healthz
              port: 3000

kubectl apply -f deployment.yaml
kubectl rollout status deployment/app-web
kubectl get pods -l app=web

Dua hal penting di manifest di atas:

• resources: requests (jaminan) dan limits (batas). Tanpa ini, satu aplikasi bisa melahap seluruh memory node — sumber "node NotReady" paling umum.
• readinessProbe: pod baru hanya menerima trafik setelah siap. Tanpa probe, pod yang masih boot bisa menerima request dan gagal.

#Troubleshooting Pod

kubectl get pods
kubectl describe pod app-web-xyz            # lihat event & kondisi
kubectl logs app-web-xyz --previous         # log kontainer sebelumnya (crash)
kubectl exec -it app-web-xyz -- sh          # masuk ke kontainer
kubectl top nodes && kubectl top pods       # penggunaan resource aktual

kubectl describe adalah langkah pertama: di bagian Events tercantum alasan pod gagal — image tidak ada, resource tidak cukup, atau probe gagal. Biasakan membaca ini sebelum bertanya ke orang lain.

#Memperbarui dan Rollback

Update image adalah operasi sehari-hari:

kubectl set image deployment/app-web web=ghcr.io/corp/app-web:1.5.0
kubectl rollout status deployment/app-web
kubectl rollout history deployment/app-web
kubectl rollout undo deployment/app-web     # rollback ke versi sebelumnya

Kubernetes melakukan rolling update: pod baru dijadwalkan, diverifikasi (readiness probe), baru pod lama dihapus. Jika rollout gagal, rollout undo mengembalikan versi.

#Pemeliharaan Rutin Cluster

Catatan: backup etcd adalah backup cluster itu sendiri (episode 11). Tanpa backup etcd, cluster yang rusak harus dibangun ulang dari nol — termasuk semua manifest yang di-apply.

#Kesalahan Umum

1. Node di-reboot tanpa drain — pod hilang tidak wajar, aplikasi down.
2. Workload tanpa resources limits — satu aplikasi melahap memory node.
3. Tanpa readiness probe — pod belum siap tapi sudah menerima trafik.
4. Menghapus pod manual untuk restart — gunakan rollout restart.
5. Tidak backup etcd — kehilangan konfigurasi seluruh cluster saat bencana.

#Penutup

Inti yang harus dibawa pulang:

• Kenali komponen: control plane (otak) vs worker nodes (pekerja); cek kesehatan dengan kubectl get nodes/events.
• Maintenance node: cordon → drain → maintenance → uncordon.
• Deployment dengan resources + readinessProbe; update via rolling update dengan rollback.
• Backup etcd adalah jaminan kelangsungan cluster.

Di episode 16 selanjutnya kita mengoptimalkan sistem yang sudah berjalan: performance & tuning — profiling CPU/mem/IO, parameter kernel, dan tuning aplikasi. Sampai jumpa di episode 16!