Kontrak Infrastruktur #

Kubernetes bukan hanya tentang menjalankan container — ia mendefinisikan ulang bagaimana developer dan tim operasional berkolaborasi. Di pusat kolaborasi ini ada sebuah konsep yang jarang dibahas secara eksplisit tapi sangat fundamental: kontrak infrastruktur. Ini adalah kesepakatan implisit antara aplikasi dan platform tentang apa yang masing-masing pihak butuhkan dan apa yang masing-masing pihak sediakan.

Apa Itu Kontrak Infrastruktur? #

Ketika kamu mendeploy aplikasi ke Kubernetes, kamu membuat sejumlah “janji” ke platform tentang kebutuhan aplikasimu. Kubernetes sebaliknya membuat “janji” tentang apa yang akan disediakan. Ini adalah kontrak dua arah.

Developer/Aplikasi berjanji ke Kubernetes:
  ✓ "Aplikasi saya butuh minimal 250m CPU dan 128Mi memory"
  ✓ "Aplikasi saya sehat jika /health mengembalikan HTTP 200"
  ✓ "Aplikasi saya siap terima traffic jika /ready mengembalikan HTTP 200"
  ✓ "Aplikasi saya bisa diidentifikasi dengan label app=api, version=v2"

Kubernetes berjanji ke Developer/Aplikasi:
  ✓ "Saya akan menjamin minimal resource yang kamu minta selalu tersedia"
  ✓ "Saya akan berhenti kirim traffic jika readiness probe gagal"
  ✓ "Saya akan restart container jika liveness probe gagal"
  ✓ "Saya akan pastikan selalu ada N replica yang berjalan"

Kontrak ini yang membuat Kubernetes bisa beroperasi secara otonom — ia tahu kapan intervensi diperlukan berdasarkan janji yang diberikan aplikasi.

Kontrak Resource: Request dan Limit #

Saat kamu mendefinisikan resources.requests dan resources.limits di Pod spec, kamu sedang menandatangani kontrak resource dengan scheduler Kubernetes.

resources:
  requests:
    cpu: "250m"      # kontrak: "saya perlu minimal 250 millicore CPU"
    memory: "128Mi"  # kontrak: "saya perlu minimal 128 MiB memory"
  limits:
    cpu: "500m"      # kontrak: "saya tidak akan pakai lebih dari 500 millicore"
    memory: "256Mi"  # kontrak: "saya tidak akan pakai lebih dari 256 MiB"

Apa yang terjadi jika kontrak dilanggar:

Jika aplikasi memakai LEBIH dari memory limit (256Mi):
  → Container di-kill dengan status OOMKilled
  → Kubernetes restart container
  → Ini "hukuman" karena melanggar kontrak

Jika aplikasi memakai LEBIH dari CPU limit (500m):
  → CPU di-throttle, proses melambat
  → Container tidak di-kill, tapi performa turun

Jika node tidak punya cukup resource untuk memenuhi request:
  → Pod tetap di status Pending
  → Kubernetes tidak akan memaksa Pod jalan di tempat yang tidak cukup
  → Ini "perlindungan" dari Kubernetes untuk menjaga kontrak

Mendefinisikan request dan limit bukan opsional untuk produksi — ini adalah fondasi yang membuat scheduling dan resource management Kubernetes bisa bekerja dengan benar.

Kontrak Ketersediaan: Health Check #

Kubernetes tidak bisa tahu apakah aplikasimu sehat hanya dengan melihat apakah prosesnya berjalan. Sebuah proses bisa berjalan tapi dalam kondisi deadlock, kehabisan koneksi database, atau dalam state yang tidak bisa melayani request. Untuk itu, kamu perlu mendefinisikan apa artinya “sehat” bagi aplikasimu.

Kubernetes menyediakan tiga jenis probe:

Liveness Probe — menjawab pertanyaan: “Apakah container masih hidup dan perlu di-restart?”

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30    # tunggu 30 detik sebelum mulai cek
  periodSeconds: 10          # cek setiap 10 detik
  failureThreshold: 3        # restart jika gagal 3 kali berturut-turut

Readiness Probe — menjawab pertanyaan: “Apakah container sudah siap menerima traffic?”

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  failureThreshold: 3        # keluarkan dari load balancer jika gagal 3 kali

Perbedaan kunci Liveness vs Readiness:

Liveness gagal  → container di-RESTART
Readiness gagal → container di-KELUARKAN dari Service (tidak terima traffic)
                  tapi TIDAK di-restart

Ini penting: aplikasi yang sedang warm-up atau sedang busy
tidak perlu di-restart — cukup tidak menerima traffic baru dulu.

Startup Probe — untuk aplikasi yang butuh waktu lama untuk startup:

startupProbe:
  httpGet:
    path: /health
    port: 8080
  failureThreshold: 30       # toleransi 30x gagal (30 * 10 detik = 5 menit)
  periodSeconds: 10

Startup probe memberikan waktu ekstra untuk aplikasi yang butuh waktu startup panjang, sebelum liveness probe mulai dipantau.

Kontrak Identitas: Label dan Selector #

Label adalah mekanisme paling fleksibel di Kubernetes untuk mengidentifikasi dan mengelompokkan resource. Ini terlihat sederhana, tapi implikasinya sangat luas.

metadata:
  labels:
    app: api              # nama aplikasi
    version: v2           # versi yang berjalan
    environment: prod     # environment deployment
    team: platform        # tim yang bertanggung jawab

Label yang kamu definisikan di Pod menjadi “kontrak identitas” yang digunakan oleh komponen lain:

Service menggunakan label untuk menemukan Pod mana yang dilayani:

  Service selector:  { app: api }
                          │
                          ├─ Pod A (labels: { app: api, version: v1 })  ✓ dilayani
                          ├─ Pod B (labels: { app: api, version: v2 })  ✓ dilayani
                          └─ Pod C (labels: { app: worker })            ✗ tidak dilayani

Jika label tidak konsisten, Service bisa gagal menemukan Pod yang benar.

Label juga digunakan oleh Deployment untuk melacak Pod mana yang dikelolanya (melalui spec.selector), oleh HorizontalPodAutoscaler untuk mengetahui Pod mana yang perlu di-scale, dan oleh monitoring tools untuk mengelompokkan metric.

Kontrak Shutdown: Graceful Termination #

Kubernetes juga mendefinisikan kontrak tentang bagaimana container harus berhenti. Ketika Kubernetes perlu menghentikan Pod (karena scaling down, rolling update, atau drain node), ia tidak langsung mematikan container secara paksa.

Urutan graceful termination:

1. Kubernetes mengirim sinyal SIGTERM ke container
   → Aplikasi HARUS menangkap sinyal ini dan mulai shutdown gracefully

2. Kubernetes menunggu selama terminationGracePeriodSeconds (default: 30 detik)
   → Aplikasi idealnya menyelesaikan request yang sedang diproses
   → Tutup koneksi database, flush cache, simpan state jika perlu

3. Jika setelah 30 detik container masih berjalan:
   → Kubernetes mengirim SIGKILL
   → Container mati paksa
   → Request yang sedang diproses hilang

spec:
  terminationGracePeriodSeconds: 60   # beri waktu 60 detik untuk shutdown
  containers:
  - name: api
    # Aplikasi harus menangani SIGTERM untuk graceful shutdown

Aplikasi yang tidak menangani SIGTERM akan di-kill paksa setelah 30 detik, menyebabkan request yang sedang diproses gagal di tengah jalan. Ini adalah detail yang sering diabaikan tapi sangat terasa dampaknya saat rolling update.

Ringkasan #

  • Kontrak infrastruktur adalah kesepakatan dua arah — aplikasi mendefinisikan kebutuhannya, Kubernetes menjamin pemenuhannya; keduanya perlu memegang janji masing-masing.
  • Resource request adalah kontrak minimum — scheduler hanya menempatkan Pod di node yang bisa memenuhi request; tanpa request, scheduling menjadi tidak terprediksi.
  • Liveness vs Readiness probe punya tujuan berbeda — liveness untuk “restart jika mati”, readiness untuk “stop traffic jika belum siap”; jangan gunakan endpoint yang sama untuk keduanya.
  • Label adalah kontrak identitas — konsistensi label menentukan apakah Service, Deployment, dan HPA bisa menemukan Pod yang tepat.
  • Graceful termination perlu di-desain di aplikasi — tangani SIGTERM, selesaikan request yang berjalan, baru keluar; jangan biarkan Kubernetes mematikan aplikasi secara paksa.
  • Kontrak ini yang membuat Kubernetes bisa otonom — semakin lengkap informasi yang diberikan aplikasi, semakin cerdas keputusan yang bisa dibuat Kubernetes.

← Sebelumnya: Konfigurasi   Berikutnya: Architecture Overview →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact