Belajar Solution Architect - Container & K8s Solutions

#Pendahuluan

Setelah di episode 13 kalian bisa menimbang serverless dengan matematika biaya dan merancang rantai event yang idempotent, sekarang kita bahas pasangan sekaligus pesaingnya dalam hampir setiap diskusi arsitektur modern: container dan Kubernetes. Hampir setiap brief solusi hari ini menyebut salah satunya — dan tugas SA adalah menjawab pertanyaan yang lebih mendasar dulu: apakah ini masalah yang butuh K8s?

Mengapa penting menimbang? Karena K8s adalah investasi besar: bukan hanya biaya infrastruktur, melainkan kurva belajar tim, kompleksitas operasional, dan kecepatan delivery awal. K8s yang diambil tanpa kebutuhan nyata menghasilkan platform mahal yang dipakai seperti VPS biasa — pemborosan berlapis.

#Containerization Sebagai Langkah Dasar

Sebelum bicara orkestrator, container sendiri sudah memberi nilai independen:

• Konsistensi environment — aplikasi + dependency dibungkus satu image; "jalan di laptop saya" berhenti menjadi alasan.
• Densitas efisien — banyak proses per host tanpa VM terpisah; biaya turun dibanding satu VM per app.
• Deployment unit standar — image sama dipakai di dev, staging, production; rollback = jalankan image versi lama.

Untuk migrasi aplikasi lama (lanjutan strangler pattern episode 12), strategi bertahapnya:

1. Repackage — bungkus aplikasi existing apa adanya ke image (base OS mirip server lama), tanpa refactor. Cukup untuk pindah runtime.
2. Externalize config — pindahkan semua konfigurasi ke environment variable/secret manager; 12-factor style.
3. Health check & logging — endpoint /healthz dan log ke stdout agar cocok dengan pola orchestrator.
4. Baru kemudian refactor internal bila ada nilai bisnisnya.

Contoh Dockerfile produksi multi-stage yang menjaga image tetap kecil:

FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
 
FROM node:22-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/node_modules ./node_modules
COPY --from=build /app/src ./src
USER node
EXPOSE 3000
HEALTHCHECK CMD wget -qO- http://localhost:3000/healthz || exit 1
CMD ["node", "src/server.js"]

Detail USER node dan non-root adalah bagian dari security baseline episode 8 — image yang jalan sebagai root adalah temuan audit klasik.

#Kapan K8s Layak, Kapan Overkill

Keputusan paling bernilai di episode ini adalah tabel keputusan ini:

Poin yang sering luput: container tanpa K8s itu sah. Cloud Run atau Fargate memberi scaling, health check, dan zero server management dengan operasional sepersepuluh K8s. Jika requirement kalian tercapai di sana, berhentilah di sana — simplicity first (episode 2).

Jika memutuskan K8s, pilih managed control plane (EKS/GKE/AKS) — jangan pernah self-host control plane di production kecuali kalian vendor K8s. Pertanyaan lanjutannya: node pool managed vs serverless nodes (Fargate/KEDA-style), dan apakah data plane juga dikelola.

#Mendesain Deployment K8s Siap Produksi

Inti desain platform K8s untuk tim aplikasi adalah manifest yang mengandung guardrail. Contoh deployment dengan praktik wajib:

deployment.yaml dengan resource limit dan probe

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  labels: { app: order-service, env: prod }
spec:
  replicas: 3
  selector:
    matchLabels: { app: order-service }
  template:
    metadata:
      labels: { app: order-service }
    spec:
      containers:
        - name: api
          image: registry.internal/order-service:1.42.0
          ports:
            - containerPort: 3000
          resources:
            requests: { cpu: "250m", memory: "512Mi" }
            limits:   { cpu: "500m", memory: "768Mi" }
          readinessProbe:
            httpGet: { path: /healthz/ready, port: 3000 }
            initialDelaySeconds: 5
          livenessProbe:
            httpGet: { path: /healthz/live, port: 3000 }
            periodSeconds: 10
          securityContext:
            runAsNonRoot: true
            allowPrivilegeEscalation: false
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels: { app: order-service }

Perhatikan empat hal yang membuat manifest ini "siap review SA":

• resources.requests/limits — dasar kapasitas dan proteksi noisy neighbor; angka ini juga input estimasi biaya episode 9.
• Dua probe terpisah — readiness (boleh dilayani trafik?) vs liveness (proses hidup?). Menggabungkannya adalah penyebab restart storm klasik.
• securityContext non-root — kelanjutan baseline Dockerfile tadi.
• topologySpreadConstraints — pod disebar lintas AZ, menerjemahkan aturan multi-AZ episode 5 ke dunia K8s.

Di atas level manifest, keputusan platform lain yang harus tertulis di ADR:

• Ingress/gateway: satu pintu trafik dengan TLS termination (ingress controller atau gateway API).
• Secret management: integrasi secret manager eksternal (external-secrets), bukan Secret object mentah di Git.
• Autoscaling dua dimensi: HPA untuk pod, cluster autoscaler untuk node — kapasitas klaster ikut elastis.
• Namespace & quota per tim/environment — isolasi logis minimal; network policy untuk isolasi trafik antar-layanan.
• GitOps delivery (Argo CD/Flux): klaster menyatu dengan alur review repository, bukan kubectl apply manual dari laptop.

#Platform Team vs App Team

Kesalahan organisasi paling umum di adopsi K8s: semua engineer dipaksa jadi ahli K8s. Desain yang sehat memisahkan dua lapisan:

Tim aplikasi mengonsumsi platform lewat template (Helm chart terkurasi) sehingga deploy layanan baru butuh jam, bukan pekan riset. Inilah nilai sebenarnya dari K8s: platform self-service — dan SA yang mendesain kontrak antara kedua tim ini.

#Cost & Capacity di Dunia Container

Menutup lingkaran dengan episode 9: container memberi granularitas biaya yang lebih baik jika diukur benar:

• Requests = biaya minimum yang kalian bayar (kapasitas direservasi); limits = batas burst. Right-size berbasis metrik utilization aktual, bukan tebakan.
• Spot/preemptible nodes untuk stateless workload (episode 9) — di K8s ditangani rapi via node pool terpisah + toleration, dengan graceful drain saat reklaim.
• Scale-to-zero untuk environment preview per pull request: namespace dibuat saat PR dibuka, dihancurkan saat merge. Fitur developer experience yang sekaligus penghemat besar.
• Chargeback per tim via metrik usage namespace — melanjutkan budaya tagging episode 9.

#Penutup

Inti yang harus dibawa pulang:

• Container memberi nilai mandiri (konsistensi, densitas, deployment standar) — adopsinya bisa berhenti sebelum K8s.
• K8s layak untuk banyak layanan + tim platform + kebutuhan portabilitas; overkill untuk tim kecil dengan beberapa aplikasi.
• Selalu managed control plane; manifest produksi wajib punya resource guardrail, dual probe, non-root, dan spreading lintas AZ.
• Pisahkan lapisan platform dan aplikasi; nilai K8s sejati adalah platform self-service dengan template terkurasi.
• Biaya container diatur lewat requests/limits, spot node pool, dan scale-to-zero — semuanya terhubung ke disiplin FinOps episode 9.

Di episode 15 selanjutnya kita akan membahas resilience & DR solutions — high availability versus disaster recovery, RTO/RPO sebagai kontrak desain, topologi DR dari backup-and-restore sampai active-active, serta strategi backup yang benar-benar bisa di-restorasi. Sampai jumpa di episode 15!