Phần 10 — Production: Observability, Backup, Upgrade và Disaster Recovery

Series Kubernetes Toàn Tập — 13 phần:

1. Phần 1 — Tổng quan và kiến trúc

2. Phần 2 — Cài đặt cluster

3. Phần 3 — Workloads

4. Phần 4 — Networking

5. Phần 5 — Storage

6. Phần 6 — Configuration

7. Phần 7 — Security

8. Phần 8 — Scheduling & Autoscaling

9. Phần 9 — Helm, Operator, CRD

10. Phần 10 — Production checklist ← bạn đang đọc

11. Phần 11 — Service Mesh: Istio, Linkerd, Cilium

12. Phần 12 — Multi-tenancy & Multi-cluster

13. Phần 13 — Cluster API, FinOps, AI/ML

Mở đầu

Cluster lên không khó. Vận hành cluster khỏi tay qua nhiều năm mới là phần thực sự khó. Phần cuối này gom checklist production: observability, backup/restore, cluster upgrade, disaster recovery, capacity planning và những thứ ai vận hành K8s lâu cũng từng vấp.

1. Observability — không thấy thì không sửa được

Bộ ba kinh điển: metrics, logs, traces. Thêm profiling và events.

1.1 Metrics

Stack chuẩn open-source:

• Prometheus (hoặc Mimir) — scrape và lưu metrics.

• kube-state-metrics — expose state K8s object (Deployment desired vs available, …).

• node-exporter — metrics node (CPU, RAM, disk, network).

• cAdvisor — đã embed trong kubelet, expose container metrics.

• Prometheus Operator — CRD ServiceMonitor/PodMonitor/PrometheusRule cho phép app khai báo scrape config trong YAML riêng.

• Grafana — dashboard.

Kubernetes Mixin có dashboard và alert built-in cho mọi component: monitoring.mixins.dev.

1.2 Logs

• App nên log JSON ra stdout/stderr — không log file.

• Collector chạy DaemonSet (Promtail / Alloy / Fluent Bit / Vector) đọc /var/log/containers/*.log.

• Lưu trong Loki / Elasticsearch / Cloud (CloudWatch, GCP Logging, Datadog).

Quan trọng: thêm label/tag namespace, app, pod, container. Không log secret hay PII.

1.3 Traces

OpenTelemetry là chuẩn. App instrument bằng OTel SDK, gửi span đến OTel Collector → Tempo / Jaeger / cloud.

Cho microservice, tracing là cách duy nhất hiểu được latency end-to-end qua nhiều hop.

1.4 Profiling và auto-instrumentation

Pyroscope + Grafana Beyla (eBPF) cho continuous profiling và auto-instrument app không sửa code.

1.5 Events

K8s tự generate event. Ship vào logs cho audit:

kubectl get events -A --sort-by='.lastTimestamp'
# Vẫn không đủ — chỉ giữ 1h mặc định. Cài kube-eventer hoặc event-exporter để ship sang Loki/Elastic.

1.6 SLO cơ bản nên có

1.7 Alert phải có

• Node NotReady > 5 phút.

• etcd leader change quá thường xuyên / disk space < 20%.

• API server error rate cao.

• CoreDNS pod crash loop.

• PVC sắp đầy (> 80%).

• Pod CrashLoopBackOff > 5 phút.

• Cert expired trong 14 ngày (kube cert + ingress cert).

2. Backup và Restore

2.1 Cần backup gì?

1. etcd — toàn bộ state cluster. Mất etcd là mất cluster.

2. PVC data — data app: database, file user upload.

3. Manifest source — đã ở Git nếu bạn GitOps.

4. Secrets ngoài Git — backup từ Vault/cloud KMS riêng.

2.2 Backup etcd

# Trên control plane
sudo ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /backup/etcd-$(date +%F-%H%M).db

# Verify
etcdctl snapshot status /backup/etcd-...db --write-out=table

Lưu snapshot off-site (S3, cloud), encrypted. Chạy CronJob trong cluster hoặc cron trên host.

Restore: dùng etcdctl snapshot restore vào thư mục data, đổi kubeadm config trỏ về data dir mới, restart etcd. Tài liệu chính thức có bước chi tiết — diễn tập định kỳ.

2.3 Velero — backup cluster + PVC

Velero là tool open-source de facto: backup mọi object K8s và PVC volume vào S3.

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.10.0 \
  --bucket my-velero-backups \
  --backup-location-config region=us-east-1 \
  --snapshot-location-config region=us-east-1

# Backup theo lịch
velero schedule create daily \
  --schedule="0 2 * * *" \
  --include-namespaces='*' \
  --ttl 720h

# Backup ad-hoc
velero backup create pre-upgrade --include-namespaces prod

# Restore
velero restore create --from-backup pre-upgrade

Velero hỗ trợ CSI snapshot và Restic / Kopia để backup file-level cho volume không snapshot được.

2.4 Backup theo app — không lười

Snapshot disk database không thay backup database logic. Postgres bị corrupt 4 giờ trước, snapshot 30 phút trước cũng corrupt. Backup app-level (pg_dump, WAL archiving) vẫn cần thiết, ship sang object storage.

2.5 Test restore — backup chưa restore = chưa có backup

Mỗi quý:

• Restore etcd snapshot lên cluster test.

• Velero restore namespace prod vào cluster test, verify app chạy.

• Restore DB từ pg_dump vào staging.

Đo RTO/RPO thực tế, không để giả định.

3. Cluster Upgrade

K8s phát hành minor mỗi ~4 tháng, hỗ trợ 12–14 tháng. Bạn phải upgrade — không có lựa chọn.

3.1 Quy tắc skew

• Control plane và node lệch tối đa ±2 minor.

• Upgrade từng minor một (1.28 → 1.29 → 1.30), không nhảy.

• kubectl lệch tối đa ±1 minor.

3.2 kubeadm upgrade

# Trên control plane đầu tiên
sudo apt-get update
sudo apt-mark unhold kubeadm
sudo apt-get install -y kubeadm=1.31.0-1.1
sudo apt-mark hold kubeadm

sudo kubeadm upgrade plan
sudo kubeadm upgrade apply v1.31.0

# Trên các control plane khác
sudo kubeadm upgrade node

# Upgrade kubelet + kubectl
sudo apt-mark unhold kubelet kubectl
sudo apt-get install -y kubelet=1.31.0-1.1 kubectl=1.31.0-1.1
sudo apt-mark hold kubelet kubectl
sudo systemctl daemon-reload
sudo systemctl restart kubelet

3.3 Drain worker và upgrade

# Trên control plane
kubectl drain worker-1 --ignore-daemonsets --delete-emptydir-data

# Trên worker
sudo apt-get update
sudo apt-mark unhold kubeadm kubelet kubectl
sudo apt-get install -y kubeadm=1.31.0-1.1 kubelet=1.31.0-1.1 kubectl=1.31.0-1.1
sudo apt-mark hold kubeadm kubelet kubectl
sudo kubeadm upgrade node
sudo systemctl daemon-reload
sudo systemctl restart kubelet

# Quay lại control plane
kubectl uncordon worker-1

3.4 Trước upgrade — luôn làm

1. Đọc Release Notes và Deprecation minor đó.

2. Chạy kube-no-trouble (kubent) phát hiện API deprecated trong cluster.

3. Backup etcd + Velero snapshot.

4. Upgrade add-on (CNI, ingress, cert-manager, operator) theo support matrix.

5. Upgrade staging cluster trước tối thiểu 1 tuần.

6. PDB cho workload quan trọng để drain không kéo cả app xuống.

7. Bảo trì thông báo trước, lịch ngoài giờ peak.

3.5 Managed cluster (EKS/GKE/AKS)

Cloud lo control plane. Bạn vẫn phải:

• Upgrade node group (rolling, blue/green node pool).

• Upgrade add-on (CNI, kube-proxy, CoreDNS) cũng phải bấm.

• Test workload trên node mới trước khi switch.

4. Disaster Recovery

Phải định nghĩa rõ:

• RTO (Recovery Time Objective) — bao lâu được phép down.

• RPO (Recovery Point Objective) — chấp nhận mất tối đa bao nhiêu data.

Lựa chọn architecture cluster:

• Single cluster multi-AZ — đa số use case. Cluster Autoscaler + topology spread.

• Federated / multi-cluster (Cluster API, Karmada, Argo CD multi-cluster) — đa region, complexity cao.

• Active/passive qua DNS + Velero — RPO tệ hơn nhưng simple.

5. Capacity Planning

• Theo dõi node:cpu_utilisation, node:memory_utilisation qua thời gian.

• Đặt buffer 20–30% (chỗ cho rolling update, node fail).

• Đo resource:requested/allocatable — đây là chỉ số scheduler thấy, không phải usage thực.

• Mỗi node 100% allocated requests = scheduler không nhét được gì → pod Pending dù CPU thật nhàn.

• Đa node group: 1 group on-demand baseline, 1 group spot/preemptible cho burst.

• Theo dõi pod_overhead (kubelet, daemonset, system) ~ 10–15% mỗi node.

6. Hygiene định kỳ

6.1 Hàng ngày

• Check alert chưa close.

• Check pod restart bất thường.

6.2 Hàng tuần

• Review log lỗi top.

• Review cost (kubecost, opencost).

• Image vuln scan (Trivy Operator) — fix critical.

6.3 Hàng tháng

• Patch OS node (kured cho reboot tự động).

• Rotate certificate (kubeadm renew, hoặc tự động).

• Review RBAC binding mới.

• Review network policy mới.

• Test restore Velero.

6.4 Hàng quý

• Upgrade minor K8s.

• DR drill: restore vào cluster phụ.

• Penetration test / kube-bench / kube-hunter.

• Review SLO, sửa burn rate.

7. Cost optimization

• Bật topology-aware routing để giảm cross-AZ traffic.

• Spot/Preemptible cho workload có thể chịu restart (web, batch). PDB + maxUnavailable đúng.

• Right-size requests bằng VPA recommend mode + Kubecost.

• Karpenter consolidation tự move pod xuống node ít, xoá node thừa.

• Set imagePullPolicy: IfNotPresent + image registry cache (Harbor pull-through).

• Đừng over-provision Loki/Mimir/Tempo — dùng object storage S3 thay block volume.

• Track cost theo namespace/team với labels (opencost project).

8. Common pitfalls — danh sách thực chiến

1. Không set readiness probe. User bị 502 mỗi lần rollout.

2. Liveness probe quá nhạy. App slow lúc GC → restart loop → tệ hơn nữa.

3. Không có PDB. Drain node = app down.

4. Không có anti-affinity. 3 replica chung 1 node, node chết = app chết.

5. Resource requests 0. BestEffort, evict đầu tiên.

6. Memory limit thiếu. Pod ăn RAM cả node → kubelet OOM-kill ngẫu nhiên.

7. CPU limit quá thấp. Throttling latency.

8. etcd disk chậm. Cluster chậm toàn bộ. Dùng SSD/NVMe dedicated.

9. Backup etcd nhưng chưa từng restore. Khi cần thì lạc.

10. kubectl apply -f với credentials master từ CI. Lúc bị leak là cluster mất. Dùng GitOps + workload identity.

11. CrashLoopBackOff vì image pull fail. Kiểm registry credentials, network egress.

12. Network policy default-deny rồi quên allow DNS — app gọi gì cũng fail name resolution.

13. StatefulSet PVC giữ luôn sau delete. Chiếm chỗ và $.

14. Ingress 504 timeout mặc định 60s — tăng theo workload nếu cần.

15. Cluster autoscaler không xoá được node vì pod không có PDB hoặc cluster-autoscaler.kubernetes.io/safe-to-evict annotation.

9. Tools bạn nên có sẵn

10. Khi mọi thứ cháy — playbook ngắn

1. Confirm scope: 1 app? 1 namespace? Toàn cluster?

2. Stop bleeding: rollback deploy gần nhất (kubectl rollout undo), scale up, evacuate node.

3. Diagnose: kubectl get events -A, log API server, log etcd, log CNI, Grafana.

4. Communicate: status page, channel team, không im lặng.

5. Postmortem blameless: timeline, root cause, action items.

11. Kết series cơ bản → production

Bạn đã đi qua 10 phần đầu:

• Hiểu vì sao K8s tồn tại và kiến trúc.

• Dựng được cluster local và production.

• Chạy mọi loại workload với probe, lifecycle đúng.

• Kết nối service qua DNS, expose qua Ingress/Gateway.

• Lưu data với PV/PVC, snapshot, expansion.

• Inject config/secret an toàn, dùng external secret store.

• Bảo mật với RBAC, SecurityContext, Pod Security Standards.

• Scale workload và cluster với HPA, VPA, KEDA, Cluster Autoscaler, Karpenter.

• Package + GitOps, mở rộng với CRD + Operator.

• Vận hành production: observability, backup, upgrade, DR, cost.

K8s là chặng đường, không phải đích. Mỗi minor version đổi vài thứ, mỗi vendor có gotcha riêng. Đọc kubernetes.io/docs mỗi khi release notes mới, lăn vào hands-on, và đừng ngại break/cài lại cluster lab.

Build it, break it, fix it — that's how you actually learn Kubernetes.

← Phần 9 | ↺ Về Phần 1