Part 12 · Kubernetes · Ingress/Runtime

Failure labs: từ OCI image tới request qua Ingress

Chạy trên kind, minikube hoặc cluster lab tương đương. Mục tiêu không chỉ là “làm cho chạy”, mà là nối được triệu chứng với đúng layer, lưu evidence có thể kiểm chứng và chứng minh recovery/rollback an toàn.

Lab safety: chỉ dùng cluster/namespace thử nghiệm. Không dùng production certificate, credentials hay dữ liệu thật. Pin version của Kubernetes, ingress controller, Gateway API implementation và CNI để kết quả có thể lặp lại.

Setup chung

Prerequisites

Cluster lab có quyền tạo namespace, Deployment, Service, Ingress, NetworkPolicy và các Gateway API resource nếu Lab 5 được thực hiện.
Một ingress controller có thể bật/tắt hoặc cài lại; CNI của cluster cần được xác minh có enforce NetworkPolicy cho Lab 8.
Một ứng dụng test trả về hostname/pod name, request path và forwarded headers; có thể thêm endpoint sleep/health để tạo timeout và readiness failure.
Công cụ gửi traffic liên tục, kèm request ID để nối edge log → controller log → app log.

kubectl version
kubectl get nodes -o wide
kubectl get ingressclass
kubectl -n ingress-nginx get pods,svc

# Ghi lại version/digest của controller và image app trước khi bắt đầu.
# Dùng hostname local qua hosts file hoặc DNS lab.

Evidence baseline

Lưu manifests, output kubectl get/describe, Events, EndpointSlice, controller logs, application logs, request traces, image digest và timestamps. Snippet trong tài liệu chỉ là hướng dẫn; nó không thay thế executed evidence.

Lab 1 · Ingress object nhưng không có controller

Objective

Chứng minh API object tồn tại không đồng nghĩa data plane đang phục vụ traffic, và xác định controller/class ownership trong reconciliation.

Steps & failure injection

Deploy Deployment + Service healthy; xác nhận app truy cập được từ bên trong cluster.
Apply Ingress khi chưa có matching controller hoặc dùng ingressClassName không được controller nhận.
Quan sát Ingress status, Events và absence của controller reconciliation.
Cài/enable controller hoặc sửa class ownership; chờ controller reconcile.

Verification

Trước fix: Service/Pod healthy nhưng Ingress không có usable address/data plane.
Sau fix: controller nhận đúng class, status/address hội tụ và request thực sự tới backend.

Expected evidence: Ingress YAML/status trước-sau, Events, ingress class/controller logs và request thành công sau recovery.

Rollback/Cleanup

Xóa Ingress test hoặc trả controller/class về baseline. Xác nhận không còn listener/rule thừa sau cleanup.

Lab 2 · 404, 502, 503 và 504 matrix

Objective

Phân biệt status code theo layer thay vì gom tất cả thành “Ingress lỗi”.

Steps & failure injection

Tạo wrong host/path để nhận controller 404.
Đổi Service targetPort sang port backend không listen để tạo upstream connection failure/502 theo controller behavior.
Làm readiness fail để EndpointSlice không còn ready endpoints và quan sát 503 behavior.
Cho backend sleep vượt proxy timeout để tái hiện 504.
Thu controller access/error log và app log cho từng case.

Symptom	Layer cần kiểm tra đầu tiên	Evidence tối thiểu
404	Host/path routing hoặc default backend	Ingress rule + controller access log
502	Controller → upstream connection/protocol	Service port/targetPort + error log
503	Service/EndpointSlice readiness	EndpointSlice + Pod readiness/Events
504	Upstream response vượt timeout	Controller timeout + app request duration

Verification

Mỗi status phải map được tới một cause đã inject và evidence độc lập; không chấp nhận kết luận chỉ dựa trên HTTP code.

Recovery

Khôi phục rule, targetPort, readiness và timeout về baseline từng lỗi một; xác nhận traffic trở lại bình thường sau mỗi recovery để tránh che lấp nhiều lỗi cùng lúc.

Lab 3 · PathType, rewrite và SPA/API collision

Objective

Hiểu ownership của path, ảnh hưởng của rewrite và cách SPA fallback có thể biến API 404 thật thành HTML 200 giả.

Steps & failure injection

Route /api với Prefix và / tới frontend; test /api, /api/, /api/orders.
Thêm controller-specific rewrite; ghi path mà application thực sự nhận.
Cố tình rewrite API 404 thành SPA HTML 200.
Sửa rule ownership và giữ original URI/request ID trong logs.

Verification

Regression assertion kiểm tra cả status lẫn Content-Type; API không được trả HTML 200 khi resource không tồn tại.
Controller log và app log cho biết original URI và effective path sau rewrite.

Expected evidence: bảng request → matched rule → rewritten path → backend response trước/sau fix.

Lab 4 · TLS, SNI và forwarded headers

Objective

Kiểm tra certificate selection, rotation và trust boundary của client identity/scheme headers.

Steps & failure injection

Tạo certificate lab cho đúng host; test wrong host/SNI và default certificate.
Rotate TLS Secret/certificate; quan sát controller reload và traffic errors trong failure window.
Gửi spoofed X-Forwarded-For/X-Forwarded-Proto trực tiếp và qua trusted edge.
Cấu hình strip/overwrite/trusted proxy; assert scheme/client IP tại application.

Verification

HTTPS redirect không loop và secure-cookie behavior đúng.
Ứng dụng không tin forwarded headers từ caller không nằm trong trust boundary.
Certificate rotation không gây lỗi kéo dài ngoài cửa sổ chấp nhận của lab.

Security & recovery

Không dùng private key production. Giữ certificate cũ cho rollback trong lab, và lưu fingerprint/serial của certificate trước-sau để chứng minh controller đã nhận bản mới.

Lab 5 · Ingress sang Gateway API

Objective

Chuyển routing control từ Ingress sang Gateway + HTTPRoute, quan sát status conditions và rollback route độc lập application Deployment.

Steps & failure injection

Chuyển một host/path sang Gateway + HTTPRoute.
Kiểm tra Accepted, ResolvedRefs và parent attachment conditions.
Tạo canary backend 90/10; gửi đủ requests và đo distribution với tolerance đã định trước.
Thử cross-namespace backend khi chưa có và khi có ReferenceGrant.
Rollback route mà không đổi application Deployment.

Verification

Route chỉ được coi là ready khi status conditions, backend references và data-plane traffic cùng đúng. Distribution canary phải được đo bằng sample đủ lớn, không kết luận từ vài request.

Expected evidence: Gateway/HTTPRoute YAML + conditions, request-count distribution, failure của cross-namespace reference trước grant và success sau grant, cùng rollback proof.

Lab 6 · Docker image chạy được nhưng Pod fail

Objective

Chứng minh “docker run được” chưa đủ để image tương thích với Kubernetes security/resource/runtime constraints.

Steps & failure injection

Build image chạy local bằng root và writable filesystem.
Deploy với runAsNonRoot, read-only root filesystem và resource limit; quan sát permission/startup/OOM failures.
Sửa Dockerfile bằng fixed UID/GID, cấp writable path qua tmpfs/emptyDir và chừa JVM/native memory headroom phù hợp.
Test amd64/arm64 manifest hoặc inspect platform metadata để phát hiện architecture mismatch.

Verification

Lưu image digest, securityContext, mount ownership, Pod Events, container last state và exit reason.
Sau fix, Pod start bằng non-root, chỉ ghi vào path được phép và chịu resource limits mà không lặp crash.

Recovery

Rollback về digest đã biết tốt nếu fix image thất bại; không dùng mutable tag làm bằng chứng rollback.

Lab 7 · Graceful rollout qua Ingress

Objective

Đo ảnh hưởng rollout lên request đang chạy và request mới, thay vì chỉ nhìn Deployment Available.

Steps & failure injection

Gửi long-running requests và continuous short traffic qua Ingress.
Rollout version mới; log SIGTERM, readiness transition, request start/end và pod identity.
Inject application không handle SIGTERM hoặc đặt grace period quá ngắn; đo resets/5xx.
Sửa drain behavior, readiness/termination coordination và rollout strategy.

Verification

Committed request không bị xử lý hai lần.
Late request an toàn/idempotent theo semantics của app.
Rollout gate dựa trên user-facing SLI/5xx/reset, không chỉ controller status.

Expected evidence: SIGTERM timeline, readiness timeline, pod identity theo request, error-rate trước/trong/sau rollout và proof sau fix.

Rollback

Giữ previous ReplicaSet/image digest để rollback. Sau rollback phải tiếp tục traffic đủ lâu để xác nhận error rate và latency trở lại baseline.

Lab 8 · NetworkPolicy từng hop

Objective

Debug reachability theo từng hop và chứng minh policy được CNI enforce thật sự.

Steps & failure injection

Default-deny application namespace.
Allow ingress-controller namespace/pods tới app port, app tới DNS và dependencies tối thiểu.
Cố tình sai namespaceSelector, podSelector hoặc port; debug EndpointSlice, connection và policy.
Chứng minh CNI enforce bằng traffic test trước-sau policy; object tồn tại không đủ.

Verification

Ingress → app chỉ đi qua intended path/port.
DNS/dependency egress tối thiểu vẫn hoạt động.
Traffic không được allow theo selector sai và được restore khi policy sửa đúng.

Security & rollback

Áp policy theo từng bước để tránh self-lockout. Lưu baseline manifests; nếu mất observability hoặc control path trong lab, rollback policy gần nhất rồi mới tiếp tục.

Deliverables

Request-path diagram gồm DNS/LB/controller/Service/EndpointSlice/Pod.
Manifest Ingress và Gateway API kèm status conditions.
404/502/503/504 failure matrix có logs/traces chứng minh layer/cause.
TLS rotation và spoofed-header assertions.
Image → Pod compatibility matrix, image digest và SIGTERM timeline.
NetworkPolicy hop-by-hop proof và CNI enforcement evidence.
Repeatable commands, cleanup/rollback và kết luận mechanism/trade-off cho từng lab.

Completion rule: một lab chỉ hoàn tất khi có baseline, failure injection, observed evidence, recovery/rollback và post-recovery verification. “Manifest apply thành công” không phải bằng chứng production behavior.