Wawancara Kubernetes: Panduan Lengkap Pods, Services, dan Deployments

Pertanyaan wawancara Kubernetes secara konsisten berfokus pada tiga objek fundamental: Pods, Services, dan Deployments. Memahami bagaimana ketiganya berinteraksi — dari penjadwalan container hingga routing jaringan hingga pembaruan bertahap — membedakan kandidat yang sekadar menghafal definisi dari mereka yang dapat merancang sistem produksi.

Panduan ini membahas setiap primitif dengan YAML tingkat produksi, menjelaskan internal yang menjadi perhatian pewawancara, dan mencakup pertanyaan-pertanyaan spesifik yang muncul dalam wawancara DevOps dan platform engineering.

Memahami Kubernetes Pods: Unit Terkecil yang Dapat Di-deploy

Pod adalah unit atomik penjadwalan dalam Kubernetes. Pod membungkus satu atau lebih container yang berbagi namespace jaringan yang sama, namespace IPC, dan volume penyimpanan. Setiap container di dalam Pod mendapatkan alamat IP yang sama dan dapat berkomunikasi dengan container saudara melalui localhost.

Pod dengan satu container adalah pola yang paling umum. Pod dengan multi-container ada untuk skenario sidecar — log collector, service mesh, atau init container yang menyiapkan filesystem sebelum proses utama dimulai.

# api-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: api-server
  labels:
    app: api
    version: v2
spec:
  containers:
    - name: api
      image: registry.example.com/api:3.1.0
      ports:
        - containerPort: 8080
      resources:
        requests:
          cpu: "250m"        # 0.25 CPU core reserved
          memory: "256Mi"    # 256 MB reserved
        limits:
          cpu: "500m"        # hard cap at 0.5 core
          memory: "512Mi"    # OOMKilled beyond this
      readinessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 10
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 20

Blok resources sangat krusial dalam wawancara. requests menentukan penjadwalan — scheduler menempatkan Pod pada node dengan kapasitas yang tersedia cukup. limits memberlakukan batas runtime — melebihi batas memori memicu OOMKill, sementara melebihi batas CPU menyebabkan throttling.

Fase Lifecycle Pod dan Restart Policy

Kubernetes melacak setiap Pod melalui lima fase: Pending, Running, Succeeded, Failed, dan Unknown. Pewawancara sering bertanya apa yang memicu setiap transisi.

| Fase | Arti | Penyebab Umum | |-------|---------|-------------| | Pending | Dijadwalkan tetapi tidak berjalan | Image pull, sumber daya tidak cukup | | Running | Setidaknya satu container aktif | Operasi normal | | Succeeded | Semua container keluar dengan kode 0 | Batch job, init container | | Failed | Setidaknya satu container keluar dengan kode non-zero | Crash aplikasi, OOMKill | | Unknown | Komunikasi node terputus | Partisi jaringan, kegagalan node |

Field restartPolicy mengontrol apa yang terjadi setelah container keluar. Always (default untuk Deployment) melakukan restart terlepas dari kode keluar. OnFailure melakukan restart hanya pada keluar non-zero — berguna untuk Job. Never membiarkan container tetap mati — digunakan untuk Pod debug sekali pakai.

# batch-job-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: data-migration
spec:
  restartPolicy: OnFailure   # restart only on crash
  containers:
    - name: migrate
      image: registry.example.com/migrate:1.0.0
      command: ["python", "migrate.py"]
      env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: connection-string

Pola valueFrom.secretKeyRef menjaga data sensitif tetap berada di luar manifest. Kubernetes Secret secara default di-encode base64 — bukan dienkripsi. Untuk produksi, aktifkan enkripsi at rest melalui API EncryptionConfiguration atau gunakan secret manager eksternal seperti HashiCorp Vault.

Kubernetes Deployments: Rollout dan Scaling Deklaratif

Deployment membuat dan mengelola ReplicaSet, yang pada gilirannya mengelola Pod. Controller Deployment memantau state yang diinginkan dan merekonsiliasikannya dengan kenyataan — menambahkan Pod saat scaling up, menggantinya selama rollout, dan melakukan rollback saat health check gagal.

Pembuatan Pod langsung hampir tidak pernah tepat dalam produksi. Deployment menyediakan manajemen replika, rolling update, riwayat rollback, dan kemampuan pause/resume.

# api-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  labels:
    app: api
spec:
  replicas: 3                    # run 3 identical Pods
  revisionHistoryLimit: 5        # keep 5 old ReplicaSets for rollback
  selector:
    matchLabels:
      app: api                   # must match Pod template labels
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1          # at most 1 Pod down during update
      maxSurge: 1                # at most 1 extra Pod during update
  template:
    metadata:
      labels:
        app: api
        version: v2
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

Bagian strategy.rollingUpdate mendefinisikan perilaku deployment tanpa downtime. Dengan maxUnavailable: 1 dan maxSurge: 1, Kubernetes membuat satu Pod baru, menunggu hingga lolos readiness check, kemudian menghentikan satu Pod lama. Siklus ini berulang sampai semua replika menjalankan versi baru.

Melakukan Rollback Deployment Kubernetes yang Gagal

Rollback adalah topik yang sering muncul dalam wawancara. Controller Deployment menyimpan ReplicaSet lama (dikontrol oleh revisionHistoryLimit) sehingga rollback bersifat instan — tidak perlu rebuild image.

# Check rollout status
kubectl rollout status deployment/api-server

# View revision history
kubectl rollout history deployment/api-server

# Roll back to previous version
kubectl rollout undo deployment/api-server

# Roll back to specific revision
kubectl rollout undo deployment/api-server --to-revision=3

Perintah undo melakukan patch pada spec Deployment agar sesuai dengan Pod template revisi target. Strategi rolling update kemudian diterapkan seperti biasa, secara bertahap mengganti Pod saat ini dengan versi rollback.

Kubernetes Services: Jaringan Stabil untuk Pod yang Dinamis

Pod bersifat ephemeral. Pod mendapatkan alamat IP baru setiap kali di-restart. Service menyelesaikan masalah ini dengan menyediakan IP virtual yang stabil (ClusterIP) dan nama DNS yang merutekan traffic ke Pod sehat yang cocok dengan label selector.

Komponen kube-proxy pada setiap node memprogram aturan iptables atau IPVS untuk mendistribusikan traffic di seluruh Pod backend. Ketika Pod gagal dalam readiness probe-nya, controller Endpoints menghapusnya dari Service — tidak ada traffic yang mencapai instance yang tidak sehat.

# api-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  type: ClusterIP               # internal-only by default
  selector:
    app: api                     # routes to Pods with this label
  ports:
    - name: http
      port: 80                   # Service port (what clients use)
      targetPort: 8080           # Pod port (where container listens)
      protocol: TCP

Setelah dibuat, Pod mana pun di cluster dapat menjangkau Service ini di api-service.default.svc.cluster.local (atau hanya api-service dalam namespace yang sama). CoreDNS menangani resolusi.

Tipe Service: ClusterIP, NodePort, dan LoadBalancer

Pewawancara mengharapkan kandidat untuk menjelaskan tiga tipe Service utama dan kapan masing-masing diterapkan.

| Tipe | Lingkup Akses | Kasus Penggunaan | |------|-------------|----------| | ClusterIP | Internal cluster saja | Backend API, database, cache | | NodePort | Eksternal melalui <NodeIP>:<Port> | Development, cluster bare-metal | | LoadBalancer | Eksternal melalui cloud LB | Traffic produksi pada AWS/GCP/Azure |

# api-loadbalancer.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-public
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"  # AWS NLB
spec:
  type: LoadBalancer
  selector:
    app: api
  ports:
    - name: https
      port: 443
      targetPort: 8080
      protocol: TCP

Tipe LoadBalancer memicu controller load balancer cloud provider untuk menyediakan endpoint eksternal. Pada AWS, ini membuat NLB atau ALB tergantung pada anotasi. Pada cluster bare-metal tanpa integrasi cloud, MetalLB atau kube-vip mengisi peran ini.

Menghubungkan Deployment ke Service dengan Label Selector

Tautan antara Deployment dan Service adalah label selector — tidak lebih. Tidak ada referensi eksplisit antara kedua objek. Service memantau Pod yang label-nya cocok dengan spec.selector-nya dan secara otomatis memelihara daftar Endpoints.

Arsitektur terpisah ini berarti satu Service dapat merutekan ke Pod dari beberapa Deployment (berguna untuk canary release), dan satu Deployment dapat diekspos oleh beberapa Service (port berbeda, tingkat akses berbeda).

# canary-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api                   # same label as main Deployment
  template:
    metadata:
      labels:
        app: api                 # Service picks this up automatically
        version: v3-canary
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.2.0-rc1
          ports:
            - containerPort: 8080

Dengan Deployment utama menjalankan 3 replika dan canary menjalankan 1, Service mendistribusikan sekitar 25% traffic ke canary. Tidak diperlukan perubahan konfigurasi Service — label matching menangani semuanya.

Horizontal Pod Autoscaling untuk Kubernetes Deployment

Jumlah replika statis membuang sumber daya selama traffic rendah dan kewalahan di bawah lonjakan. HorizontalPodAutoscaler (HPA) menyesuaikan jumlah replika berdasarkan metrik yang diamati.

# api-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70   # scale up above 70% CPU
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # wait 5 min before scaling down

HPA melakukan polling metrics server setiap 15 detik secara default. behavior.scaleDown.stabilizationWindowSeconds mencegah flapping — siklus scale-up/scale-down cepat yang disebabkan oleh pola traffic yang bursty.

Pertanyaan Wawancara Kubernetes Umum dan Jawabannya

Pertanyaan-pertanyaan ini muncul berulang kali dalam wawancara DevOps dan platform engineering. Setiap jawaban menargetkan kedalaman yang diharapkan pewawancara.

Apa yang terjadi ketika Pod melebihi batas memorinya? Kubelet mengirimkan SIGKILL melalui OOM killer. Container keluar dengan kode 137. Controller Deployment mendeteksi Pod yang gagal dan membuat pengganti, tunduk pada restart policy dan penundaan backoff apa pun.

Bagaimana Kubernetes merutekan traffic ke versi Pod tertentu selama canary release? Selector Service cocok dengan label bersama (misalnya, app: api). Deployment stabil dan canary keduanya menggunakan label ini. Distribusi traffic proporsional dengan jumlah endpoint yang siap — 3 replika stabil + 1 replika canary berarti ~25% traffic canary. Untuk pembagian traffic yang tepat (misalnya, 5%), gunakan Gateway API HTTPRoute dengan backend berbobot.

Apa perbedaan antara readinessProbe dan livenessProbe? Readiness probe mengontrol apakah Pod menerima traffic dari Service. Readiness probe yang gagal menghapus Pod dari daftar Endpoints tetapi tidak me-restart-nya. Liveness probe mengontrol apakah container di-restart. Liveness probe yang gagal memicu restart container. Keduanya dapat menggunakan pemeriksaan HTTP, TCP, atau exec.

Bagaimana rolling update menjamin zero downtime? Controller Deployment membuat Pod baru sebelum menghentikan yang lama, diatur oleh maxSurge dan maxUnavailable. Pod baru harus lolos readiness probe sebelum Pod lama di-drain. terminationGracePeriodSeconds (default: 30s) memberi waktu pada request yang sedang berjalan untuk selesai sebelum SIGKILL.

Persiapan untuk wawancara Kubernetes memerlukan praktik YAML langsung, bukan hanya teori. Pertanyaan wawancara DevOps di SharpSkill mencakup topik-topik ini dengan latihan interaktif.

Kesimpulan

• Pod adalah unit penjadwalan — selalu tetapkan requests dan limits sumber daya, dan konfigurasikan readiness dan liveness probe
• Deployment mengelola jumlah replika, rolling update, dan riwayat rollback melalui ReplicaSet — jangan pernah membuat Pod mentah dalam produksi
• Service menyediakan jaringan yang stabil melalui label selector dan IP virtual — ClusterIP untuk traffic internal, LoadBalancer untuk eksternal
• Tautan antara Deployment dan Service murni berbasis label, memungkinkan pola canary tanpa perubahan konfigurasi
• HPA menskalakan Deployment berdasarkan metrik CPU/memori — gunakan stabilizationWindowSeconds untuk mencegah flapping
• Gateway API menggantikan Ingress NGINX sejak Kubernetes v1.35 — proyek baru sebaiknya mengadopsinya dari awal
• Berlatih dengan manifest YAML nyata dan perintah kubectl daripada menghafal definisi