Pod #

Pod adalah unit terkecil yang bisa kamu deploy di Kubernetes. Bukan container — Pod. Ini perbedaan yang penting dan sering membingungkan developer yang baru masuk ke ekosistem Kubernetes. Pod adalah lapisan tipis yang membungkus satu atau lebih container, memberikan mereka lingkungan eksekusi yang terisolasi dan identitas jaringan yang sama.

Pod vs Container #

Di dunia Docker, kamu menjalankan container secara langsung: docker run nginx. Di Kubernetes, kamu tidak pernah menjalankan container secara langsung — kamu mendeklarasikan Pod yang berisi container tersebut.

Docker:
  Container A    Container B    Container C
  (berjalan      (berjalan      (berjalan
   sendiri)       sendiri)       sendiri)

Kubernetes:
  ┌─── Pod 1 ─────────┐   ┌─── Pod 2 ───────────────┐
  │  Container A      │   │  Container B (main)     │
  │                   │   │  Container C (sidecar)  │
  └───────────────────┘   └─────────────────────────┘

Kenapa ada lapisan Pod? Karena Kubernetes butuh abstraksi yang bisa mengelompokkan container yang perlu berjalan bersama — berbagi filesystem, berbagi network interface, dan dijadwalkan ke mesin yang sama sebagai satu unit.

Anatomi Sebuah Pod #

Setiap Pod memiliki beberapa elemen kunci:

apiVersion: v1
kind: Pod
metadata:
  name: api-server          # nama Pod, unik dalam namespace
  namespace: production     # namespace tempat Pod berada
  labels:
    app: api                # label untuk grouping dan selection
    version: v2
spec:
  containers:
  - name: api               # nama container di dalam Pod
    image: my-api:v2        # container image yang dijalankan
    ports:
    - containerPort: 8080   # port yang di-expose container
    resources:
      requests:
        cpu: "250m"         # minimum CPU yang dibutuhkan
        memory: "128Mi"     # minimum memory yang dibutuhkan
      limits:
        cpu: "500m"         # maksimum CPU yang boleh dipakai
        memory: "256Mi"     # maksimum memory yang boleh dipakai
    env:
    - name: DB_HOST
      value: "postgres-service"

Beberapa poin penting dari manifest di atas:

resources.requests — jumlah resource yang dijamin untuk Pod ini. Kubernetes scheduler menggunakan angka ini untuk memilih node yang cukup kapasitasnya.

resources.limits — batas maksimum resource yang boleh dikonsumsi. Jika container melampaui memory limit, ia akan di-kill dengan OOMKilled. Jika melampaui CPU limit, ia akan di-throttle (diperlambat, tidak di-kill).

Siklus Hidup Pod #

Pod tidak dibuat untuk selamanya. Ia memiliki siklus hidup yang jelas:

Pending
  │  (menunggu scheduling dan image pull)
  ▼
Running
  │  (minimal satu container sedang berjalan)
  ├─── Succeeded (semua container selesai dengan exit code 0)
  └─── Failed    (setidaknya satu container exit dengan error)

Kondisi khusus:
  Unknown  ← tidak bisa berkomunikasi dengan node (masalah jaringan)
  CrashLoopBackOff ← container terus crash dan restart berulang kali

CrashLoopBackOff adalah status yang sering ditemui dan menandakan container terus crash. Kubernetes mencoba restart container tersebut, tapi dengan delay yang semakin lama (exponential backoff) untuk menghindari restart loop yang terlalu agresif memakan resource.

# Lihat status Pod
kubectl get pods

# Lihat detail termasuk event (berguna untuk debug)
kubectl describe pod api-server

# Lihat log container dalam Pod
kubectl logs api-server

# Lihat log container jika Pod punya banyak container
kubectl logs api-server -c api

Pod Jarang Dibuat Langsung #

Ini poin penting yang perlu dipahami sejak awal: dalam praktik produksi, kamu jarang membuat Pod secara langsung. Mengapa?

Karena Pod itu mortal — ia tidak dibuat ulang jika mati. Jika node tempat Pod berjalan crash, Pod itu hilang selamanya.

Untuk memastikan Pod selalu berjalan dan bisa pulih dari kegagalan, kamu menggunakan workload resource seperti Deployment, StatefulSet, atau DaemonSet. Resource-resource ini yang bertanggung jawab membuat dan mengelola Pod, bukan kamu secara langsung.

ANTI-PATTERN: membuat Pod langsung di produksi
  kubectl apply -f pod.yaml
  → Pod mati → tidak ada yang membuat ulang → layanan down

BENAR: gunakan Deployment untuk Pod yang perlu selalu ada
  kubectl apply -f deployment.yaml
  → Pod mati → Deployment mendeteksi → membuat Pod pengganti otomatis

Membuat Pod langsung berguna untuk debugging dan eksperimen, tapi bukan untuk workload produksi.

Pod dengan Beberapa Container #

Meski sebagian besar Pod hanya berisi satu container, ada pola yang valid untuk menempatkan beberapa container dalam satu Pod. Container-container ini berbagi:

Network namespace — mereka semua bisa saling komunikasi via localhost
Storage volumes — bisa mount volume yang sama

# Contoh Pod dengan sidecar container untuk log forwarding
spec:
  containers:
  - name: app                      # container utama
    image: my-app:v1
    volumeMounts:
    - name: log-volume
      mountPath: /var/log/app

  - name: log-forwarder            # sidecar — mengirim log ke sistem terpusat
    image: fluentd:v1
    volumeMounts:
    - name: log-volume
      mountPath: /var/log/app      # baca log dari volume yang sama
      readOnly: true

  volumes:
  - name: log-volume
    emptyDir: {}

Pola ini (sidecar pattern) berguna ketika kamu butuh fungsionalitas pendukung yang berjalan berdampingan dengan aplikasi utama — log forwarder, metrics collector, atau proxy seperti Envoy.

Semua container dalam satu Pod selalu dijadwalkan ke node yang sama dan hidup-mati bersama. Jika butuh scaling yang berbeda untuk dua komponen, pisahkan mereka ke Pod yang berbeda.

Ringkasan #

Pod bukan container — Pod adalah pembungkus satu atau lebih container yang berbagi network dan storage; abstraksi ini diperlukan Kubernetes untuk mengelompokkan dan menjadwalkan container.
Setiap Pod punya IP sendiri — komunikasi antar Pod dilakukan via IP Pod, bukan IP container; ini bagian dari model networking flat Kubernetes.
Pod bersifat ephemeral — Pod yang mati tidak dibuat ulang secara otomatis kecuali dikelola oleh workload resource seperti Deployment.
Gunakan Deployment, bukan Pod langsung — untuk workload produksi, selalu gunakan abstraksi yang lebih tinggi agar Pod bisa pulih dari kegagalan.
Multi-container Pod untuk pola sidecar — valid ketika container perlu berbagi localhost dan volume, dan lifecycle mereka memang satu kesatuan.
CrashLoopBackOff — tanda container terus crash; periksa log dengan kubectl logs dan event dengan kubectl describe pod.

← Sebelumnya: Node Berikutnya: Konfigurasi →