Belajar Infrastructure Engineer - Kubernetes Infrastructure

#Pendahuluan

Setelah di episode 13 kita menghubungkan dunia on-prem dan cloud, kini kita masuk ke platform yang di 2026 hampir identik dengan "infrastruktur modern": Kubernetes. Di episode 7 kita sudah mengenal konsep dasarnya; kini kita melihat K8s dari sisi operator — cluster design, networking, storage, upgrade, dan observability.

Mengapa topik ini penting? Karena di 2026 Kubernetes bukan lagi sekadar orkestrator container — ia adalah lapisan platform tempat sebagian besar workload baru dijalankan, baik on-prem maupun cloud. Infrastructure engineer yang tidak bisa mengoperasikan K8s akan kehilangan sebagian besar pasar kerja.

#Komponen Cluster dan Peran Infra Engineer

100%

Poin paling penting untuk infra engineer: etcd adalah jantung cluster. Cluster yang kehilangan etcd kehilangan segalanya. Backup etcd adalah bagian pertama checklist DR cluster.

#Merancang Cluster

#Satu cluster besar vs banyak cluster kecil?

Pola produksi yang umum: cluster staging + cluster production terpisah, dengan namespaces memisahkan tim/aplikasi dalam satu cluster. Multi-tenant dengan isolasi keras (beberapa tim berbeda) biasanya butuh cluster terpisah.

#Ukuran dan Tipe Node

• Worker node: node yang menjalankan workload.
• Control plane: API server + etcd — untuk production, minimal 3 replika di node terpisah untuk HA.
• Node pool/group: kelompok node dengan spesifikasi sama — memudahkan scaling dan isolasi (misal pool GPU terpisah — episode 23).

Pertimbangan ukuran node: node besar (32+ core) = lebih sedikit node, biaya operasi rendah, tetapi blast radius besar saat node mati. Node kecil (4-8 core) = lebih banyak node, failover lebih halus, tetapi overhead lebih tinggi. Keseimbangan umum: 8-16 core per node.

#Networking Kubernetes

Networking K8s adalah lapisan yang paling sering disalahpahami. Empat model yang harus jelas:

#CNI: Jaringan Pod

CNI (Container Network Interface) mengatur jaringan pod di seluruh node. Setiap pod mendapat IP unik yang bisa menjangkau pod lain di node mana pun tanpa NAT.

Cek CNI yang terpasang

kubectl get pods -n kube-system | grep -i "cilium\|calico"
kubectl get ds -n kube-system

Dua CNI paling populer 2026: Calico (mendukung network policy yang matang) dan Cilium (eBPF — performa tinggi, observability dalam, mendukung network policy juga). Pilihan CNI menentukan kemampuan network policy kalian.

#Network Policy

Di K8s, semua pod bisa saling bicara secara default — itu bahaya. Network Policy membatasinya:

networkpolicy.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-db-from-web-only
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: web
      ports:
        - protocol: TCP
          port: 5432

Policy ini: database hanya menerima koneksi port 5432 dari pod berlabel app: web. Semua yang lain diblokir — menerapkan prinsip segmentation (episode 18) di level platform.

#Storage Persisten

Pod bersifat sementara — data yang harus bertahan hidup di PersistentVolume:

persistentvolumeclaim.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
spec:
  accessModes: [ReadWriteOnce]
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard

• StorageClass menghubungkan cluster ke storage nyata (hostPath, NFS, cloud disk, Ceph/Rook, Longhorn).
• AccessModes: ReadWriteOnce (satu node), ReadWriteMany (banyak node — butuh NFS/Ceph).
• Untuk production, hindari hostPath — pakai storage yang bisa direplikasi (Ceph/Longhorn di on-prem, managed disk di cloud).

#Upgrade Cluster yang Aman

Upgrade adalah saat paling berisiko dalam siklus hidup cluster. Prinsip yang benar:

1. Baca release notes — perhatikan breaking changes dan API deprecation.
2. Backup etcd dulu — selalu, tanpa pengecualian.
3. Upgrade satu minor version pada satu waktu (1.31 → 1.32, bukan lompat).
4. Control plane dulu, baru worker node — bertahap per node.
5. Uji di staging dengan versi aplikasi yang sama.

Alur upgrade node (contoh kubeadm)

kubectl drain node-01 --ignore-daemonsets
sudo kubeadm upgrade node
sudo systemctl restart kubelet
kubectl uncordon node-01
kubectl get nodes

drain mengosongkan pod dari node dengan aman (migrasi bertahap), uncordon mengembalikan node sebagai target scheduling. Ini pola yang sama di semua distribusi K8s.

#Observability Cluster

Di episode 9 kita membangun observability umum; untuk K8s tambahkan:

• Kubelet metrics: kondisi node dan kubelet (kube-state-metrics).
• Pod metrics: CPU/memory per pod, scaling signal.
• Log: agregasi dari semua pod (promtail/Loki atau Fluentd/Elasticsearch).
• Alert khas cluster: node NotReady, pod CrashLoopBackOff, imagePullBackOff, PVC pending.

Alert yang wajib ada di cluster

NodeDown                 : node tidak responsif > 5 menit
PodNotReady              : pod stuck > 15 menit
PersistentVolumePending  : PVC tidak bisa dibind (storage habis?)
OutOfMemoryKilled        : pod di-OOM-kill

#Backup Cluster

Backup K8s mencakup tiga lapisan:

1. etcd — state cluster (paling kritis).
2. Manifests — semua deklarasi sudah di Git (episode 8), jadi "kode" aman.
3. Persistent data — volume yang dipakai aplikasi (misal database).

Backup etcd (contoh kubeadm)

sudo ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /backup/etcd-$(date +%F).db

Tools modern seperti Velero mengotomasi backup seluruh cluster (manifests + volume) ke object storage.

#Common Pitfalls Kubernetes

• etcd tanpa backup: state cluster hilang = cluster "kehilangan ingatan" total.
• Tanpa resource request/limit: pod tanpa limit bisa memakan node; tanpa request, scheduler salah menempatkan.
• Network policy tidak pernah ditegakkan: pod-pod saling bicara bebas = permukaan serangan raksasa.
• Upgrade telat berbulan-bulan: cluster ketinggalan 3+ versi = upgrade wajib berurutan yang sangat menyakitkan.
• Node tanpa drain saat maintenance: pod dijatuhkan paksa, aplikasi crash.
• Memakai hostPath di produksi: data tergantung node tertentu — failover pod tidak membawa data.

#Penutup

Pada episode 14 ini kalian telah menguasai infrastruktur Kubernetes:

• Komponen cluster dan tanggung jawab operator: etcd backup adalah prioritas tertinggi.
• Desain cluster: staging/prod terpisah, 3+ node control plane, node pool sesuai workload.
• Networking: CNI (Calico/Cilium), NetworkPolicy untuk segmentation di level platform.
• Persistent storage lewat StorageClass/PVC; hindari hostPath di produksi.
• Upgrade aman: backup etcd → bertahap per node → drain/uncordon, uji di staging.
• Observability & backup cluster: kube-state-metrics, alert khas cluster, dan Velero.

Di episode 15 selanjutnya kita masuk ke data infrastructure — managed databases, cache Redis, dan message broker yang menjadi platform data bagi aplikasi. Sampai jumpa di episode 15!