Environment Variable Pattern #

Environment variable adalah cara paling umum mengonfigurasi aplikasi di container — warisan dari tradisi Unix dan 12-Factor App. Di Kubernetes, env var bisa bersumber dari nilai literal, ConfigMap, Secret, atau metadata Pod itu sendiri melalui Downward API. Memilih sumber yang tepat untuk setiap jenis konfigurasi adalah bagian dari desain yang baik.

Sumber-sumber Environment Variable #

Empat sumber env var di Kubernetes:

1. Nilai literal — hardcode langsung di manifest
   Untuk: identifier statis seperti nama aplikasi, versi

2. ConfigMap — nilai non-sensitif yang bisa berubah
   Untuk: URL, hostname, feature flags, parameter tuning

3. Secret — nilai sensitif
   Untuk: password, API key, token

4. Downward API — informasi tentang Pod itu sendiri
   Untuk: nama Pod, namespace, node, resource limits

Nilai Literal #

env:
- name: APP_NAME
  value: "api-server"
- name: APP_VERSION
  value: "2.1.0"
- name: REGION
  value: "ap-southeast-1"

Gunakan nilai literal hanya untuk data yang benar-benar statis dan tidak berbeda antar environment. Jika nilai bisa berbeda di staging vs production, pindahkan ke ConfigMap.

Dari ConfigMap #

# Cara 1: inject satu key
env:
- name: DATABASE_HOST
  valueFrom:
    configMapKeyRef:
      name: app-config
      key: DATABASE_HOST
      optional: false    # default false; jika true, Pod tetap jalan walau key tidak ada

# Cara 2: inject semua key dari ConfigMap sekaligus (envFrom)
envFrom:
- configMapRef:
    name: app-config
    # Semua key jadi env var dengan nama yang sama persis
- configMapRef:
    name: feature-flags
    # Bisa dari beberapa ConfigMap

Dengan envFrom, semua key di ConfigMap menjadi env var. Hati-hati dengan konflik nama — jika dua ConfigMap punya key yang sama, yang terakhir menimpa.

Dari Secret #

# Cara 1: inject satu key dari Secret
env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: db-credentials
      key: password

# Cara 2: inject semua key dari Secret
envFrom:
- secretRef:
    name: db-credentials

Downward API: Metadata Pod sebagai Env Var #

Downward API memungkinkan Pod mengetahui informasi tentang dirinya sendiri tanpa harus query API Server:

env:
# Identitas Pod
- name: POD_NAME
  valueFrom:
    fieldRef:
      fieldPath: metadata.name

- name: POD_NAMESPACE
  valueFrom:
    fieldRef:
      fieldPath: metadata.namespace

- name: POD_IP
  valueFrom:
    fieldRef:
      fieldPath: status.podIP

- name: NODE_NAME
  valueFrom:
    fieldRef:
      fieldPath: spec.nodeName

# Label dan annotation Pod
- name: APP_LABEL
  valueFrom:
    fieldRef:
      fieldPath: metadata.labels['app']

# Resource limits container ini sendiri
- name: CPU_LIMIT
  valueFrom:
    resourceFieldRef:
      containerName: api
      resource: limits.cpu

- name: MEMORY_REQUEST
  valueFrom:
    resourceFieldRef:
      containerName: api
      resource: requests.memory

Use case umum Downward API:

Inject nama Pod ke log untuk identifikasi di log aggregation
Inject namespace ke aplikasi multi-tenant yang butuh tahu konteks-nya
Inject resource limits agar aplikasi bisa mengonfigurasi thread pool atau heap size yang sesuai

Urutan Prioritas dan Konflik #

# Jika ada konflik antara env dan envFrom:
envFrom:
- configMapRef:
    name: shared-config    # berisi LOG_LEVEL=debug

env:
- name: LOG_LEVEL          # explicit env menimpa envFrom
  value: "info"            # hasilnya: LOG_LEVEL=info

Explicit env selalu menimpa envFrom. Ini berguna untuk override nilai tertentu dari ConfigMap.

Batasan Environment Variable #

Yang tidak bisa dilakukan env var:

1. Update tanpa restart Pod
   → Env var di-set saat container dimulai dan tidak berubah
   → Perubahan ConfigMap tidak tercermin ke env var yang sudah running
   → Harus restart Pod untuk mendapat nilai baru

2. Hierarki atau struktur
   → Env var adalah flat key-value
   → Untuk konfigurasi terstruktur (nested), lebih baik pakai file YAML/JSON
     yang di-mount sebagai volume

3. Ukuran besar
   → Ada batas ukuran untuk semua env var dalam satu proses (~2MB total di Linux)
   → Untuk konfigurasi besar, gunakan file

4. Referensi ke env var lain (inter-referencing)
   → Tidak bisa $(VAR_A) di dalam nilai $(VAR_B) secara dinamis
   → Kubernetes mendukung $(VAR_NAME) substitution tapi hanya untuk
     env var yang didefinisikan sebelumnya di list yang sama

$(VAR_NAME) substitution yang didukung:

env:
- name: APP_HOST
  value: "api.example.com"
- name: APP_URL
  value: "https://$(APP_HOST)/v2"   # → "https://api.example.com/v2"

Kapan Pakai Env Var vs File Konfigurasi #

Gunakan environment variable untuk:
  ✓ Nilai tunggal yang simpel (URL, hostname, flag on/off)
  ✓ Konfigurasi yang sudah menjadi standar di framework (DATABASE_URL, etc.)
  ✓ Nilai yang jarang berubah dan tidak perlu hot reload

Gunakan file konfigurasi (ConfigMap sebagai volume) untuk:
  ✓ Konfigurasi dengan struktur kompleks (nested YAML/JSON/TOML)
  ✓ Konfigurasi yang butuh hot reload tanpa restart Pod
  ✓ File konfigurasi yang sudah ada format standarnya (nginx.conf, app.yaml)
  ✓ Data besar yang tidak cocok sebagai env var
  ✓ Konfigurasi yang sering berubah (tidak mau restart Pod setiap kali)

Ringkasan #

Empat sumber env var — literal, ConfigMap, Secret, Downward API; pilih berdasarkan jenis data dan kebutuhan keamanan.
envFrom untuk inject massal, env untuk override — envFrom semua key dari ConfigMap/Secret, lalu gunakan env untuk override nilai tertentu.
Downward API untuk self-awareness Pod — nama Pod, namespace, node, resource limits bisa diinject sebagai env var untuk logging dan konfigurasi adaptif.
Env var tidak bisa di-update tanpa restart — berbeda dari volume mount ConfigMap yang auto-update; pertimbangkan ini saat memilih antara keduanya.
$(VAR_NAME) substitution untuk komposisi — referensi env var lain dalam nilai; berguna untuk membangun URL dari bagian-bagian terpisah.
File konfigurasi untuk data kompleks dan hot-reload — env var cocok untuk nilai simpel; konfigurasi terstruktur atau yang sering berubah lebih baik sebagai volume mount.

← Sebelumnya: Secret Berikutnya: Secret Management Best Practice →