# Wawancara Kubernetes: Panduan Lengkap Pods, Services, dan Deployments

> Panduan lengkap pertanyaan wawancara Kubernetes tentang Pods, Services, dan Deployments dengan contoh YAML, internal networking, dan strategi scaling untuk tahun 2026.

- Published: 2026-04-04
- Updated: 2026-04-04
- Author: SharpSkill
- Tags: kubernetes, devops, interview, pods, services, deployments
- Reading time: 12 min

---

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.

> **Referensi Cepat**
>
> Sebuah Pod menjalankan satu atau lebih container pada satu node. Sebuah Deployment mengelola replika Pod dan rollout. Sebuah Service menyediakan endpoint jaringan yang stabil untuk menjangkau Pod-Pod tersebut. Ketiga objek ini menangani 80% manajemen workload di cluster Kubernetes mana pun yang menjalankan v1.35 atau lebih baru.

## 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.

```yaml
# 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.

> **Jebakan Umum dalam Wawancara**
>
> Menetapkan batas memori tanpa requests menyebabkan penjadwalan yang tidak dapat diprediksi. Kubelet dapat menempatkan Pod pada node yang sebenarnya tidak dapat mempertahankan workload. Selalu tetapkan baik `requests` maupun `limits` untuk Pod produksi.

## 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.

```yaml
# 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](https://kubernetes.io/docs/concepts/workloads/controllers/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.

```yaml
# 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.

```bash
# 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](https://kubernetes.io/docs/concepts/services-networking/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.

```yaml
# 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 |

```yaml
# 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.

> **Gateway API Menggantikan Ingress**
>
> Sejak Kubernetes v1.35, controller Ingress NGINX telah resmi dihentikan. [Gateway API](https://gateway-api.sigs.k8s.io/) kini menjadi pendekatan yang direkomendasikan untuk HTTP routing, TLS termination, dan traffic splitting. Cluster baru sebaiknya mengadopsi Gateway API dari awal.

## 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).

```yaml
# 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](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) menyesuaikan jumlah replika berdasarkan metrik yang diamati.

```yaml
# 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](/technologies/devops/interview-questions/kubernetes-basics) 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

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/id/blog/devops/kubernetes-interview-pods-services-deployments-explained