Kubernetes Gateway API: Chia Tay Ingress, Chào Gateway Mới

Ingress đã phục vụ Kubernetes tốt trong gần một thập kỷ. Nhưng đến tháng 11/2025, Kubernetes chính thức ngừng vá bảo mật cho Ingress NGINX. Không tính năng mới, không bản vá lỗi. Với các team đang chạy Ingress NGINX trên production, đây là hồi chuông báo động.

Gateway API ra đời để giải quyết chính xác những giới hạn này — không thay thế bằng annotation, mà bằng tài nguyên chuyên biệt.

Ingress đã chết, Ingress muôn năm

Vấn đề cốt lõi của Ingress không nằm ở NGINX. Nó nằm ở chính API. Ingress là một tài nguyên đơn giản, được thiết kế cho thời kỳ mà routing HTTP chỉ cần host + path. Khi nhu cầu phát triển vượt xa khả năng của spec, annotation trở thành lối thoát duy nhất.

Mỗi controller thêm annotation riêng. Kết quả: file Ingress 200 dòng, một nửa là annotation của NGINX, nửa còn lại là cách xử lý tạm. Không tương thích giữa các controller. Không hỗ trợ sẵn header-based routing, traffic splitting, hay mTLS.

Gateway API giải quyết bằng cách tách route khỏi phần triển khai. Ba tài nguyên chính:

• GatewayClass — chọn controller (Envoy, Istio, Traefik...)
• Gateway — khai báo listener (HTTP, HTTPS)
• HTTPRoute — định nghĩa routing rule (path, header, method, weight...)

Kết quả là cùng một HTTPRoute có thể chạy trên Envoy Gateway hôm nay và Istio ngày mai — không cần sửa.

Chọn controller Gateway API nào?

Không phải controller nào cũng như nhau. Một bài benchmark gần đây so sánh các lựa chọn chính:

• Envoy Gateway — CNCF project, được CNCF tự vận hành trên hạ tầng của mình. Hỗ trợ đầy đủ mTLS và request buffering. Đây là lựa chọn được nhiều team cân nhắc nhất hiện nay.
• Istio — đầy đủ tính năng nhất, nhưng đi kèm độ phức tạp service mesh.
• Traefik / NGINX Gateway Fabric — nằm ngoài CNCF, ít được ưu tiên trong các quyết định dài hạn.

Đối với hầu hết team, Envoy Gateway là điểm khởi đầu hợp lý: đủ mạnh, đủ nhẹ, và có một cộng đồng đang phát triển nhanh.

Di chuyển không downtime: bài toán thực tế

Điều khiến nhiều team chùn bước là nỗi sợ downtime trong quá trình chuyển đổi. Nhưng có một chiến lược đã được chứng minh hiệu quả: weighted DNS.

Thay vì chuyển toàn bộ traffic một lần, hãy:

1. Triển khai Envoy Gateway song song với Ingress NGINX
2. Dùng weighted DNS route 5-10% traffic sang Gateway mới
3. Theo dõi error rate và latency trong vài giờ
4. Tăng dần tỷ lệ cho đến khi đạt 100%
5. Gỡ Ingress NGINX sau 24 giờ xác nhận ổn định

Cách làm này cho phép rollback tức thì nếu có vấn đề — chỉ cần đưa DNS weight về 0.

Một công cụ hữu ích khác là ing-switch, có khả năng quét cluster hiện tại, map annotation sang tài nguyên Gateway API tương ứng, và sinh manifest di chuyển.

Kết

Ingress NGINX đã hoàn thành vai trò lịch sử. Gateway API không phải "nice to have" nữa — nó là hướng đi chính thức của Kubernetes networking. Bắt đầu đánh giá ngay hôm nay, trước khi buộc phải làm gấp vào ngày mai.