Observability & Kesiapan Produksi — Belajar Kubernetes

Tumpukan Observability yang Lazim

Aplikasi (instrumentasi OpenTelemetry)
   │
   ▼
Grafana Alloy (DaemonSet)  ← mengumpulkan metrik, log, trace
   │        │        │
   ▼        ▼        ▼
Prometheus  Loki   Tempo
   └────────┴────────┘
            ▼
         Grafana

⚠️ Grafana Agent dan Promtail sudah tidak dikembangkan

Banyak tutorial masih memakai Grafana Agent atau Promtail. Keduanya sudah berakhir masa dukungannya. Penggantinya adalah Grafana Alloy, distribusi OpenTelemetry Collector yang juga memahami konfigurasi Prometheus dan komponen loki.source.* untuk pengumpulan log.

Memasang dengan kube-prometheus-stack

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install pemantauan prometheus-community/kube-prometheus-stack \
  -n pemantauan --create-namespace \
  --version 66.2.1 \
  -f nilai-pemantauan.yaml

Chart ini sekaligus memasang Prometheus, Alertmanager, Grafana, node-exporter, kube-state-metrics, beserta puluhan dasbor dan aturan alert yang sudah matang. Untuk sebagian besar kluster, ini titik awal yang jauh lebih baik daripada merakit sendiri.

ServiceMonitor: Scrape secara Deklaratif

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: layanan-pesanan
  labels:
    release: pemantauan      # HARUS cocok dengan selector Prometheus
spec:
  selector:
    matchLabels:
      app: layanan-pesanan
  endpoints:
    - port: metrics
      path: /metrics
      interval: 30s

📌 Bila metrik tidak muncul, periksa label ini dulu

Prometheus Operator hanya mengambil ServiceMonitor yang cocok dengan serviceMonitorSelector miliknya — biasanya berdasarkan label release. ServiceMonitor tanpa label yang tepat akan diabaikan sepenuhnya tanpa pesan kesalahan apa pun. Periksa dengan kubectl get prometheus -o yaml | grep -A5 serviceMonitorSelector.

Metrik Kubernetes yang Wajib Dipantau

# Pod yang restart berulang
increase(kube_pod_container_status_restarts_total[15m]) > 3

# Pod tidak Ready lebih dari 10 menit
kube_pod_status_ready{condition="false"} == 1

# Pod mendekati memory limit
container_memory_working_set_bytes
  / kube_pod_container_resource_limits{resource="memory"} > 0.9

# CPU di-throttle
rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0.5

# Node hampir kehabisan sumber daya
kube_node_status_condition{condition="MemoryPressure",status="true"} == 1

# PVC hampir penuh
kubelet_volume_stats_available_bytes
  / kubelet_volume_stats_capacity_bytes < 0.1

# Sertifikat akan kedaluwarsa
certmanager_certificate_expiration_timestamp_seconds - time() < 7*24*3600

💡 Beri alert pada gejala, bukan penyebab

Alert "CPU node 85%" jarang berguna — bisa jadi itu memang pemakaian normal. Yang benar-benar perlu membangunkan orang di tengah malam adalah hal yang dirasakan pengguna: tingkat error naik, latensi p99 melewati ambang, antrean menumpuk. Metrik sumber daya berguna sebagai konteks saat menyelidiki, bukan sebagai pemicu alert.

Daftar Periksa Kesiapan Produksi

Beban Kerja

Periksa	Kenapa
Resource request & memory limit disetel	Penjadwalan yang benar; menghindari kelas BestEffort
Liveness, readiness, dan startup probe ada	Penyembuhan otomatis dan rilis tanpa error
Liveness tidak memeriksa dependensi eksternal	Mencegah seluruh pod dibunuh saat dependensi lambat
Tag image spesifik, bukan `:latest`	Rilis dapat direproduksi
Minimal 2 replika untuk layanan penting	Satu replika berarti pasti ada downtime saat rilis
PodDisruptionBudget terpasang	Melindungi saat pemeliharaan node
Topology spread antar zona	Bertahan dari kegagalan satu zona
`preStop` dan grace period diatur	Menghindari 502 saat rilis
Aplikasi menangani SIGTERM	Menyelesaikan permintaan yang sedang berjalan

Keamanan

`runAsNonRoot: true`, UID numerik	Membatasi dampak bila kontainer diretas
`readOnlyRootFilesystem: true`	Penyerang tidak bisa menaruh berkas
`capabilities.drop: ["ALL"]`	Mencabut hak istimewa kernel
`automountServiceAccountToken: false`	Menghapus kredensial API yang tak dibutuhkan
Pod Security Admission `restricted`	Penegakan di tingkat namespace
NetworkPolicy tolak-semua sebagai dasar	Membatasi pergerakan lateral
Rahasia dari manajer rahasia eksternal	Tidak ada rahasia di Git
Image dipindai di pipeline CI	Menangkap CVE sebelum produksi

Operasi

Metrik, log, dan trace terhubung lewat trace_id	Investigasi insiden dari menit, bukan jam
Alert mengarah pada gejala yang dirasakan pengguna	Mengurangi kelelahan akibat alert palsu
Backup etcd terjadwal dan pemulihannya diuji	Backup yang belum pernah diuji bukan backup
Prosedur rollback tertulis dan pernah dilatih	Insiden bukan waktu yang tepat untuk belajar
Manifest di Git, diterapkan lewat GitOps	Dapat diaudit dan direproduksi
Rencana upgrade kluster berkala	Versi Kubernetes hanya didukung sekitar satu tahun

🚫 Dua hal yang paling sering diabaikan

1. Backup etcd yang tidak pernah diuji pemulihannya. Banyak tim rajin membuat backup tetapi tidak pernah mencoba memulihkannya. Saat benar-benar dibutuhkan, barulah ketahuan bahwa backup-nya tidak lengkap atau prosedurnya tidak berjalan.

2. Upgrade kluster yang terus ditunda. Setiap versi Kubernetes hanya didukung sekitar satu tahun. Menunda upgrade membuat Anda harus melompati beberapa versi sekaligus, yang jauh lebih berisiko daripada upgrade rutin. Jadwalkan sebagai pekerjaan berkala, bukan proyek besar sesekali.