My Awesome Project

Appearance

Production GKE Debugging Framework ​

Tại sao Chapter này khác Chapter 43? ​

Chapter 43 đặt nền tảng: hiểu Pod status, event history, và mental model cơ bản về failure cascade. Chapter này đi sâu hơn một bậc — đây là debugging framework hoàn chỉnh để xử lý production incident ở quy mô thật, nơi hệ thống đang cháy và bạn cần không phải trả lời "cái gì đang xảy ra" mà là "tại sao nó xảy ra và làm sao không xảy ra nữa".

Sự khác biệt cốt lõi:

Chapter 43Chapter 53
Methodology cơ bản, mental model ban đầuScientific debugging framework + incident methodology
Từng domain riêng lẻCross-layer correlation — synthesis toàn bộ stack
Công cụ và commandsCơ chế bên trong từng signal source
Giới thiệu debuggingRCA techniques, timeline reconstruction, action planning

Điều kiện tiên quyết ​

Chapter này giả định bạn đã đọc và hiểu:

Folder Structure ​

chapter-53-production-gke-debugging-framework/
├── index.md                              ← File này
├── 01-debugging-methodology-telemetry.md ← Hypothesis-driven debugging + telemetry model
├── 02-pod-debugging.md                   ← Pod states deep dive: pending, crashed, hung
├── 03-service-connectivity-debugging.md  ← DNS, routing, network policy internals
├── 04-infrastructure-debugging.md        ← Node pressure signals + control plane
├── 05-cross-layer-correlation-incident.md← Trace→logs→metrics + GKE dashboard + timeline
└── 06-root-cause-analysis.md             ← Five Whys, fishbone, action items

Các File Trong Chapter ​

1. Phương Pháp Debugging Khoa Học & Mô Hình Telemetry ​

Tại sao trial-and-error fail ở production, và cách áp dụng hypothesis-driven debugging — phương pháp đặt câu hỏi có cấu trúc trước khi chạy bất kỳ command nào. Internal model của từng telemetry source trong GKE: Kubernetes Events (etcd-backed, TTL), Cloud Logging (log types, latency, structured JSON), Cloud Monitoring (metrics pipeline, GKE system metrics, kube-state-metrics), Cloud Trace (sampling, context propagation), và cách chọn signal source phù hợp cho từng tình huống.

2. Pod Debugging: Pending, Crashed, Hung ​

Giải phẫu từng trạng thái lỗi của Pod ở mức internal model: Pending đi qua scheduling pipeline như thế nào, vì sao ResourceQuota block có thể vô hình, CrashLoopBackOff và cơ chế exponential backoff của kubelet, taxonomy exit code (137 = OOM kill, 143 = SIGTERM, 1 = application error), hung pod với liveness/readiness probe semantics, cgroup v1 vs v2 và cách OOM kill xảy ra khác nhau. Methodology debug từng state step-by-step với data thật.

3. Service Connectivity Debugging: DNS, Routing, Network Policy ​

Internal model của DNS trong GKE: CoreDNS resolution pipeline, resolv.conf và ndots problem, search domain overhead, NodeLocal DNSCache. Service routing: iptables vs eBPF (GKE Dataplane V2), DNAT chain, conntrack table và vấn đề exhaustion. Network Policy enforcement: cách eBPF compile policy thành BPF maps, testing methodology. Packet path từ pod-to-pod và cách isolate từng layer để tìm điểm fail.

4. Infrastructure Debugging: Node & Control Plane ​

Node layer: kubelet heartbeat model (kube-node-lease), node conditions và detection thresholds (MemoryPressure, DiskPressure, PIDPressure), PLEG stall và ảnh hưởng, node-problem-detector, eviction mechanics. Control plane layer: API server request lifecycle (etcd roundtrip anatomy), etcd watch fan-out và latency, controller manager reconciliation loop bottlenecks, scheduler binding failures. Giới hạn của GKE managed control plane — những gì bạn có thể observe vs những gì Google quản lý.

5. Cross-Layer Correlation, GKE Dashboard & Incident Timeline ​

Tại sao cross-layer correlation là kỹ năng hiếm — clock skew, sampling bias, log lag, và observer effect. Cơ chế propagate trace context từ request đầu vào đến final response, cách inject trace ID vào logs. Đọc GKE Observability Dashboard: ý nghĩa thực sự của mỗi chart, cluster health signals và ngưỡng đáng lo ngại. Xây dựng incident timeline từ nhiều signal source: event ordering, causality vs correlation, common trap khi assume correlation = causation.

6. Root Cause Analysis: Five Whys, Fishbone & Action Planning ​

Cơ chế và giới hạn của Five Whys trong distributed systems — khi nào nó hoạt động, khi nào nó dẫn bạn đến wrong root cause. Ishikawa (fishbone) diagram adapted cho Kubernetes: categories phù hợp với hệ thống phân tán. Phân biệt proximate cause (nguyên nhân gần) vs root cause (nguyên nhân gốc rễ). Framework action items 3 tầng: immediate mitigation (stop bleeding), tactical fix (giải quyết đúng triệu chứng), strategic improvement (address root cause để không tái phát). Detection improvement: từ "chúng ta phát hiện khi khách hàng complain" đến "chúng ta phát hiện trước khi ảnh hưởng production".

Learning Path ​

Đọc theo thứ tự:

01 (framework tư duy + telemetry)
  → 02 (pod deep dive)
  → 03 (network deep dive)
  → 04 (infrastructure deep dive)
  → 05 (synthesis: correlation + timeline)
  → 06 (conclusion: RCA + action planning)

File 01 đặt nền tảng tư duy. Files 02-04 là knowledge domains cụ thể. File 05 là kỹ năng synthesis — kết hợp tất cả lại. File 06 là phần thường bị bỏ qua nhất nhưng lại tạo ra sự khác biệt dài hạn.

References ​