Konfigurasi #

Salah satu keputusan desain paling fundamental di Kubernetes adalah bagaimana konfigurasi dikelola. Kubernetes menggunakan pendekatan declarative — kamu mendefinisikan apa yang kamu inginkan, bukan bagaimana cara mencapainya. Pendekatan ini berbeda dari cara operasional tradisional dan punya implikasi besar terhadap bagaimana kamu berinteraksi dengan cluster.

Declarative vs Imperative #

Perbedaan ini perlu dipahami sejak awal karena mempengaruhi seluruh cara kamu bekerja dengan Kubernetes.

Imperative (perintah langsung):
  "Buat container, jalankan image nginx, expose port 80, buat 3 replica"
  → Kamu mendiktekan setiap langkah
  → Jika ada kegagalan di tengah jalan, kamu harus tahu dari mana melanjutkan
  → Sulit direproduksi dan di-audit

Declarative (deklarasi keadaan):
  "Saya ingin ada 3 replica nginx yang berjalan dan bisa diakses di port 80"
  → Kubernetes yang mencari cara untuk mencapai keadaan itu
  → Jika ada kegagalan, Kubernetes yang mengambil tindakan korektif
  → File konfigurasi adalah sumber kebenaran yang bisa di-version control

Dalam praktiknya, ini berarti kamu menulis file YAML yang mendeskipsikan keadaan yang diinginkan, lalu mengirimkannya ke Kubernetes:

# Declarative — kirim manifest, Kubernetes yang urus sisanya
kubectl apply -f deployment.yaml

# Imperative — berikan perintah langsung (kurang direkomendasikan untuk produksi)
kubectl create deployment nginx --image=nginx --replicas=3

kubectl apply adalah cara declarative: jika resource belum ada, Kubernetes membuatnya. Jika sudah ada, Kubernetes hanya mengubah bagian yang berbeda. Kamu tidak perlu tahu kondisi sebelumnya.

Format Manifest Kubernetes #

Semua resource Kubernetes dikonfigurasi melalui manifest dalam format YAML (atau JSON). Setiap manifest memiliki empat field wajib di level atas:

apiVersion: apps/v1      # versi API untuk resource ini
kind: Deployment         # jenis resource
metadata:                # informasi identifikasi
  name: api-server
  namespace: production
  labels:
    app: api
spec:                    # spesifikasi keadaan yang diinginkan
  replicas: 3
  # ... detail resource

apiVersion — Kubernetes memiliki banyak API group. Resource inti seperti Pod menggunakan v1. Resource seperti Deployment menggunakan apps/v1. Resource networking menggunakan networking.k8s.io/v1. Selalu rujuk dokumentasi untuk apiVersion yang benar.

kind — jenis resource: Pod, Deployment, Service, ConfigMap, Secret, dll.

metadata — nama, namespace, dan label. Label adalah key-value pair yang bebas dan digunakan untuk mengelompokkan dan memfilter resource.

spec — isi spesifikasi yang berbeda-beda tergantung jenis resource.

Memisahkan Konfigurasi dari Kode #

Prinsip yang sudah menjadi standar industri: konfigurasi tidak boleh di-hardcode dalam container image. Database URL, API key, jumlah worker thread, feature flag — semua ini harus bisa berubah tanpa harus rebuild image.

Kubernetes menyediakan dua resource untuk ini:

ConfigMap — untuk konfigurasi non-sensitif:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DATABASE_HOST: "postgres-service"
  DATABASE_PORT: "5432"
  MAX_CONNECTIONS: "100"
  LOG_LEVEL: "info"

Secret — untuk data sensitif seperti password, token, dan sertifikat:

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
data:
  DATABASE_PASSWORD: cG9zdGdyZXMxMjM=    # base64 encoded
  API_KEY: c2VjcmV0LWtleS0xMjM=

Secret di Kubernetes hanya di-encode dengan base64, bukan dienkripsi. Siapa pun yang punya akses ke cluster bisa membaca nilai Secret. Untuk keamanan yang sesungguhnya, gunakan solusi seperti HashiCorp Vault atau AWS Secrets Manager yang diintegrasikan ke cluster via External Secrets Operator.

Cara Menggunakan ConfigMap dan Secret di Pod #

Ada dua cara utama menginjeksikan konfigurasi ke container:

Sebagai environment variable:

spec:
  containers:
  - name: api
    image: my-api:v1
    env:
    - name: DATABASE_HOST              # nama env var di container
      valueFrom:
        configMapKeyRef:
          name: app-config             # nama ConfigMap
          key: DATABASE_HOST           # key dalam ConfigMap
    - name: DATABASE_PASSWORD
      valueFrom:
        secretKeyRef:
          name: app-secret             # nama Secret
          key: DATABASE_PASSWORD       # key dalam Secret

Sebagai file (volume mount):

spec:
  containers:
  - name: api
    image: my-api:v1
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config          # lokasi file di dalam container
  volumes:
  - name: config-volume
    configMap:
      name: app-config                # ConfigMap yang di-mount sebagai file

Pendekatan volume mount lebih fleksibel untuk konfigurasi yang panjang (seperti file nginx.conf atau application.yaml) dan mendukung pembaruan tanpa restart Pod — meski aplikasi perlu di-desain untuk membaca ulang konfigurasi saat file berubah.

Prinsip Immutable Infrastructure #

Kubernetes mendorong pola immutable infrastructure: ketika kamu perlu memperbarui aplikasi, kamu tidak memodifikasi container yang sedang berjalan — kamu membuat container baru dengan image versi baru, lalu mengganti yang lama secara bertahap.

ANTI-PATTERN: modifikasi container yang berjalan
  kubectl exec -it pod-name -- bash
  → edit file konfigurasi di dalam container
  → perubahan hilang saat Pod restart
  → kondisi tidak konsisten antar replica

BENAR: semua perubahan melalui manifest
  → update ConfigMap
  → update image tag di Deployment
  → kubectl apply -f deployment.yaml
  → Kubernetes rolling update semua Pod

Pendekatan ini memastikan setiap Pod dalam satu Deployment selalu dalam kondisi yang identik, dan semua perubahan terdokumentasi dalam version control.

Ringkasan #

Declarative > Imperative — deklarasikan keadaan yang diinginkan lewat YAML, Kubernetes yang menentukan cara mencapainya dan mempertahankannya.
kubectl apply adalah cara utama — gunakan ini untuk semua perubahan di produksi; idempotent dan aman untuk dijalankan berulang kali.
Empat field wajib manifest — apiVersion, kind, metadata, dan spec harus ada di setiap resource Kubernetes.
ConfigMap untuk config non-sensitif — pisahkan konfigurasi dari image; gunakan ConfigMap untuk nilai yang boleh terlihat.
Secret untuk data sensitif — gunakan Secret untuk password dan token, tapi ingat bahwa Secret hanya base64 bukan enkripsi; pertimbangkan external secret manager untuk produksi.
Immutable infrastructure — jangan modifikasi container yang berjalan; semua perubahan dilakukan melalui update manifest dan rolling deployment.

← Sebelumnya: Pod Berikutnya: Kontrak Infrastruktur →