Gateway API Kubernetes: Tại sao lựa chọn Controller lại quyết định rủi ro vận hành

Gateway API đã chính thức được đưa vào trạng thái GA kể từ Kubernetes phiên bản 1.31. Mô hình phân quyền rõ ràng giữa GatewayClass, Gateway và HTTPRoute giúp tách biệt rõ ràng giữa các khía cạnh hạ tầng điều khiển lưu lượng và các nhóm phát triển ứng dụng quản lý routing.

Tuy nhiên, điều ít được nhắc đến chính là quyết định chọn controller để vận hành Gateway API mới là nơi chứa đựng rủi ro kiến trúc thực sự. API chỉ định nghĩa cách route, còn controller chính là thành phần chạy thực tế xử lý lưu lượng, đảm bảo hiệu năng và khả năng chịu lỗi trong các tình huống tải cao hay sự cố.

Hiểu đúng điểm này là rất quan trọng để tránh các sự cố vận hành không đáng có trong Kubernetes.

Sự khác biệt giữa Ingress API và Gateway API

• Ingress API (networking.k8s.io/v1) đã quá quen thuộc, ổn định và được hỗ trợ rộng rãi. Tuy nhiên, nó hạn chế ở phần routing HTTP/HTTPS cơ bản và phần lớn các tính năng nâng cao phải dùng annotations tùy biến, dẫn đến nợ kỹ thuật theo thời gian.

• Gateway API là phiên bản kế nhiệm, được thiết kế với các tài nguyên có kiểu dữ liệu rõ ràng, phân quyền qua ReferenceGrant và tập trung lưu trữ cấu hình routing trong manifest thuộc hệ thống kiểm soát phiên bản (Git,...). Đây là lựa chọn mặc định phù hợp cho các cụm Kubernetes mới, tuy nhiên với các hệ thống cũ có nhiều annotations phức tạp, việc di trú cần được tính toán kỹ lưỡng.

Việc quyết định chọn API nào trước làm cơ sở sẽ ảnh hưởng đến việc lựa chọn controller sao cho phù hợp.

Những hạn chế và thất bại thực tế của các Ingress Controller phổ biến

Khi ingress-nginx tuyên bố ngừng phát triển, nhiều nhóm phải đánh giá lại lựa chọn controller mới. Phần lớn đánh giá tập trung vào tính năng, nhưng các vấn đề vận hành mới là điểm mấu chốt:

• Reload Storms Under Churn: Controller dựa trên NGINX reload worker process mỗi khi có thay đổi config, gây ra hiện tượng giật lag, mất kết nối WebSocket hoặc gRPC khi có autoscaling hoặc deploy tần suất cao.

• Annotation Sprawl & Config Drift: Annotation lưu trữ các cấu hình như rate limiting, authentication... dễ gây loạn cấu hình và khó bảo trì theo thời gian.

• TLS & cert-manager Edge Cases: Các trình quản lý chứng chỉ như cert-manager gây ra các khoảng thời gian ngắn cấp chứng chỉ cũ vẫn được dùng do reload controller chậm, làm lỗi handshake TLS ngẫu nhiên.

• Cold-Start Reconciliation Window: Controller phải kiểm tra lại toàn bộ tài nguyên routing khi khởi động lại, với các cụm có nhiều route thì thời gian này đủ dài để gây gián đoạn traffic nếu probe readiness không phù hợp.

Những hạn chế này không xuất hiện trong tài liệu controller nhưng sẽ hiện diện trong thực tế vận hành.

Kiến trúc quan trọng nhất: Reload-based vs Dynamic Configuration

• Các controller NGINX-based reload lại tiến trình trên mỗi thay đổi; tần suất reload cao gây ảnh hưởng tiêu cực tới latency và kết nối.

• Các controller dựa trên Envoy như Contour, Istio Gateway, AWS Gateway Controller sử dụng xDS dynamic configuration: thay đổi cấu hình được cập nhật toàn bộ mà không cần restart, rất thích hợp cho hệ thống có autoscaling và pod churn cao.

Nguồn lực cấp cho pod controller (CPU, RAM) cũng là yếu tố then chốt. Pod controller thiếu tài nguyên dễ bị kill khi cao tải, gây mất kết nối toàn bộ ingress.

Bảng so sánh các Controller theo mô hình vận hành

Controller	Mô hình config	Gateway API	Phù hợp với	Cần lưu ý
ingress-nginx	Reload on change	Partial	Cụm ổn định, dùng Ingress cũ	Reload dồn dập khi autoscaling
NGINX Inc.	Hot reload (Plus)	Partial	Doanh nghiệp có hợp đồng hỗ trợ	Chi phí license, thiếu tính tương thích annotation
Contour	Dynamic xDS	Native (GA)	Cụm mới, thiết kế Gateway API	Hệ sinh thái nhỏ, ít mở rộng
Traefik	Dynamic	Beta	Dev/staging, môi trường vận hành mạnh	Gateway API còn mới, nhiều CRD
AWS LB Controller	ALB/NLB native	Yes	Chỉ EKS, workloads AWS	Khóa nhà cung cấp AWS, chi phí cao ALB
Istio Gateway	Dynamic xDS	Native	Mesh đã triển khai	Phức tạp vận hành, chồng chéo sidecar

3 câu hỏi định hướng lựa chọn Controller

• Tần suất thay đổi của cụm bạn là bao nhiêu? (auto-scaling, deploy, đổi chứng chỉ…). Nếu cao, controller reload từng lần dễ gây sự cố.

• Bạn có bao nhiêu annotations và logic routing custom? Nếu lớn, chi phí di trú sang Gateway API cần được lên kế hoạch thận trọng.

• Ai sẽ vận hành controller lúc 2 giờ sáng? Controller phải dễ debug, phù hợp với năng lực đội ngũ vận hành.

Checklist vận hành Day-2 cần chuẩn bị

• Cập nhật controller có zero-downtime khi rolling update không?

• Cách controller xử lý xoay vòng chứng chỉ TLS dưới tải liên tục ra sao? Khoảng thời gian phục vụ chứng chỉ cũ có được đo?

• Metrics controller cung cấp là gì? Reload frequency có monitor không?

• Thời gian reconcile khi khởi động là bao lâu? Có đo đạc thực tế không?

• Đã cấu hình PodDisruptionBudget và tính đến thời gian reconcile chưa?

• Kịch bản hỏng hóc khi pod controller bị đuổi vì thiếu tài nguyên ra sao, có trong runbook không?

• Với môi trường service mesh, controller có nằm trong data plane không? Quyết định này có rõ ràng không?

Các lỗi vận hành thường không hiện ra lúc cài đặt ban đầu mà xuất hiện trong môi trường production khi hệ thống có tải thực và tình huống phức tạp.

Kết luận từ góc nhìn kiến trúc sư

Gateway API là hướng đi đúng cho các cụm Kubernetes mới trong năm 2026. Tuy nhiên, quyết định chọn controller kèm theo mới là yếu tố then chốt về rủi ro vận hành.

• Với hệ thống mới: dùng Gateway API với Contour là lựa chọn hợp lý, cấu hình xDS tránh rủi ro reload. Trên EKS, AWS Load Balancer Controller là lựa chọn thực tiễn nếu bạn cam kết với AWS.

• Với cụm hiện tại dùng ingress-nginx: không nên di trú chỉ để di trú. Hãy đánh giá các phương án kỹ theo đặc thù cụm của bạn.

Quan trọng nhất vẫn là đo đạc tần suất reload, hiểu rõ thất bại có thể gặp, chuẩn bị runbook phù hợp và thiết lập probe chính xác. Chỉ có vậy mới hạn chế sự cố và đảm bảo vận hành ổn định.

---

Bài viết được trích dịch và biên tập từ series Kubernetes Ingress Architecture trên Rack2Cloud, nguồn gốc tại https://www.rack2cloud.com/gateway-api-kubernetes-controller-decision/

Gateway API Kubernetes Controller Failure Modes

Reload-based vs Dynamic Configuration

Kubernetes ingress controller production readiness checklist