ConfigMap #

ConfigMap adalah resource Kubernetes untuk menyimpan data konfigurasi non-sensitif dalam bentuk key-value. Ia memisahkan konfigurasi dari image container — sehingga image yang sama bisa digunakan di development, staging, dan production dengan konfigurasi berbeda tanpa harus membangun ulang. Ini adalah implementasi dari prinsip 12-Factor App untuk config: simpan konfigurasi di environment, bukan di kode.

Anatomi ConfigMap #

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: production
data:
  # Key-value sederhana
  APP_ENV: "production"
  LOG_LEVEL: "info"
  MAX_CONNECTIONS: "100"

  # File konfigurasi sebagai value (multi-line)
  nginx.conf: |
    server {
      listen 80;
      server_name api.example.com;
      location / {
        proxy_pass http://localhost:8080;
      }
    }    

  app.yaml: |
    database:
      host: postgres-service
      port: 5432
      name: appdb
    cache:
      host: redis-service
      port: 6379

Cara Membuat ConfigMap #

# Dari literal value
kubectl create configmap app-config \
  --from-literal=APP_ENV=production \
  --from-literal=LOG_LEVEL=info

# Dari file (key = nama file, value = isi file)
kubectl create configmap nginx-config \
  --from-file=nginx.conf

# Dari direktori (semua file di direktori jadi key-value)
kubectl create configmap app-configs \
  --from-file=./configs/

# Dari manifest YAML (cara yang direkomendasikan untuk GitOps)
kubectl apply -f configmap.yaml

Menggunakan ConfigMap sebagai Environment Variable #

spec:
  containers:
  - name: api
    image: my-api:v2

    # Cara 1: Inject key tertentu
    env:
    - name: APP_ENV
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: APP_ENV
    - name: LOG_LEVEL
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: LOG_LEVEL

    # Cara 2: Inject semua key dari ConfigMap sekaligus
    envFrom:
    - configMapRef:
        name: app-config
        # Semua key di app-config langsung jadi env var dengan nama yang sama

Keterbatasan env var dari ConfigMap: perubahan ConfigMap tidak otomatis tercermin ke Pod yang sudah berjalan. Pod harus di-restart agar env var baru ter-update.

Menggunakan ConfigMap sebagai Volume #

spec:
  volumes:
  - name: config-vol
    configMap:
      name: app-config
      # Optional: pilih key mana yang di-mount dan dengan nama apa
      items:
      - key: nginx.conf
        path: nginx.conf       # nama file di dalam container
      - key: app.yaml
        path: config/app.yaml  # bisa di subdirektori

  containers:
  - name: nginx
    image: nginx:1.25
    volumeMounts:
    - name: config-vol
      mountPath: /etc/nginx    # semua file ConfigMap ada di sini
      readOnly: true

Keuntungan mount sebagai volume dibanding env var: perubahan ConfigMap otomatis tercermin ke file dalam container — dengan delay sekitar 1-2 menit (sesuai dengan kubelet sync period). Namun, aplikasi tetap harus membaca ulang file tersebut secara aktif.

Auto-Update ConfigMap Volume #

Kubernetes menggunakan symbolic link untuk menjaga file ConfigMap selalu up-to-date:

Struktur di dalam container setelah mount:

/etc/config/
  ..2024_01_15_12_00_00.000000000/   ← direktori dengan timestamp
    nginx.conf
    app.yaml
  ..data → ..2024_01_15_12_00_00.000000000  ← symlink ke direktori aktif
  nginx.conf → ..data/nginx.conf             ← symlink ke file
  app.yaml   → ..data/app.yaml

Saat ConfigMap diperbarui:
  Kubernetes buat direktori timestamp baru
  Update symlink ..data ke direktori baru
  Symlink file otomatis menunjuk ke versi baru

Ini berarti jika aplikasi membaca file via symlink (behavior default), ia akan mendapat versi terbaru. Tapi jika file di-cache saat startup, update tidak akan terdeteksi tanpa reload.

Immutable ConfigMap #

Untuk ConfigMap yang tidak boleh berubah setelah dibuat — misalnya konfigurasi yang sudah di-test dan di-lock untuk versi tertentu:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config-v2.1.0
immutable: true    # ← tidak bisa diubah setelah dibuat, harus delete dan buat baru
data:
  APP_VERSION: "2.1.0"
  FEATURE_FLAGS: "dark-mode=true,new-dashboard=false"

Keuntungan ConfigMap immutable: Kubernetes tidak perlu watch perubahan ConfigMap ini, mengurangi beban API Server di cluster dengan banyak ConfigMap.

Batasan ConfigMap #

Batasan yang perlu diketahui:

Ukuran maksimal:
  → 1 MB per ConfigMap
  → Jika konfigurasi lebih besar, pertimbangkan mount file via volume
    atau gunakan dedicated config management tool

Tidak untuk data sensitif:
  → Nilai ConfigMap disimpan tanpa enkripsi di Etcd
  → Untuk password, API key, certificate → gunakan Secret

Namespace-scoped:
  → ConfigMap di namespace A tidak bisa langsung digunakan Pod di namespace B
  → Jika butuh sharing, buat ConfigMap duplikat atau gunakan external config store

Pola: Versioning ConfigMap #

Untuk menghindari update ConfigMap yang mempengaruhi Pod yang sedang berjalan, gunakan pola versioning:

# Buat ConfigMap baru dengan nama yang menyertakan versi
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config-v3   # ← nama baru, bukan update yang sama
data:
  APP_ENV: "production"
  NEW_FEATURE: "enabled"

# Update Deployment untuk merujuk ke ConfigMap baru
spec:
  template:
    spec:
      volumes:
      - name: config
        configMap:
          name: app-config-v3   # ← update referensi

Dengan pola ini, rolling update Deployment akan menggunakan ConfigMap baru, sementara Pod lama masih memakai ConfigMap lama selama proses update berlangsung.

Ringkasan #

  • ConfigMap memisahkan konfigurasi dari image — image yang sama bisa berjalan di env berbeda dengan ConfigMap berbeda; prinsip 12-Factor App untuk config.
  • Env var vs volume mount — env var mudah tapi butuh restart Pod untuk update; volume mount otomatis update tapi aplikasi harus membaca ulang file.
  • Perubahan ConfigMap volume memerlukan waktu 1-2 menit — Kubernetes memperbarui file via symlink swap; aplikasi harus mendukung hot reload untuk memanfaatkan ini.
  • Bukan untuk data sensitif — ConfigMap tidak dienkripsi; untuk password dan API key gunakan Secret.
  • Batas 1 MB — untuk konfigurasi sangat besar, pertimbangkan config management tool eksternal atau split ke beberapa ConfigMap.
  • Pola versioning untuk update aman — buat ConfigMap baru dengan nama berbeda daripada update in-place; rollback lebih mudah dan tidak mempengaruhi Pod yang sedang berjalan.

← Sebelumnya: Anti-Pattern Networking   Berikutnya: Secret →

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