Ingress NGINX Retirement 2026: Vì sao Gateway API là tương lai và cách triển khai với NGINX Gateway Fabric

Thứ Ba, 06/01/2026, 17:00 (GMT+0)

Ingress NGINX Retirement 2026: Vì sao Gateway API là tương lai và cách triển khai với NGINX Gateway Fabric

Quay lại Trang chủ Blog

Trên trang này

Kubernetes đã chính thức công bố lộ trình đưa Ingress NGINX Controller vào giai đoạn nghỉ hưu (retirement) và ngừng bảo trì sau tháng 3/2026. Trong giai đoạn chuyển tiếp, dự án chỉ được duy trì ở mức best-effort và sau mốc retirement sẽ không còn phát hành phiên bản mới, sửa lỗi hay cập nhật bảo mật.

Việc retirement này chỉ áp dụng cho Ingress NGINX Controller, không ảnh hưởng đến Ingress API của Kubernetes, vì vậy các hệ thống hiện tại vẫn có thể tiếp tục vận hành trong ngắn hạn. Tuy nhiên, việc phụ thuộc lâu dài vào một controller không còn được cập nhật bảo mật sẽ tiềm ẩn rủi ro đáng kể đối với các môi trường production.

Thông báo này đánh dấu một bước chuyển quan trọng trong cách tiếp cận quản lý lưu lượng vào (north–south traffic) trên Kubernetes, đồng thời đặt ra yêu cầu rõ ràng cho các đội ngũ nền tảng và vận hành trong việc đánh giá lại kiến trúc ingress hiện tại và định hướng các giải pháp thay thế phù hợp hơn cho tương lai, tiêu biểu là Gateway API.

Trước những hạn chế ngày càng rõ ràng của Ingress và lộ trình ngừng bảo trì Ingress NGINX, cộng đồng Kubernetes đã giới thiệu Gateway API như một mô hình quản lý traffic thế hệ mới. Phần tiếp theo của bài viết sẽ làm rõ Gateway API là gì, vì sao nó được xem là hướng thay thế phù hợp, và cách triển khai thực tế với NGINX Gateway Fabric.

Hiểu về Gateway API

Gateway API là một tập hợp các tài nguyên mở rộng (Custom Resource Definitions – CRDs) do Kubernetes SIG-NETWORK phát triển, nhằm chuẩn hóa cách quản lý lưu lượng (traffic) đi vào và ra khỏi cluster Kubernetes. Gateway API được xem là thế hệ kế tiếp của Ingress, ra đời để khắc phục các hạn chế cố hữu như khó mở rộng, thiếu phân tách vai trò và phụ thuộc nhiều vào cách triển khai của từng controller.

Gateway API được thiết kế dựa trên ba nguyên tắc cốt lõi:

Role-oriented: Kiến trúc phân tách rõ vai trò giữa đội hạ tầng (Infra), nền tảng (Platform) và ứng dụng (Application), giúp quản trị và phân quyền hiệu quả hơn.
Generic: Chuẩn hóa cách định nghĩa Gateway và routing, không phụ thuộc vào một implementation cụ thể (NGINX, Istio, Cilium…).
Expressive: Hỗ trợ đa giao thức và các rule routing nâng cao, đáp ứng tốt hơn các kiến trúc cloud-native và microservices.

Kiến trúc Gateway API

Kiến trúc

Gateway API bao gồm một số resource chính, mỗi resource đảm nhiệm một vai trò rõ ràng trong luồng xử lý traffic:

GatewayClass: Đại diện cho một loại Gateway được triển khai bởi một Gateway Controller cụ thể (ví dụ: NGINX Gateway Fabric, Istio, Cilium…). Về mặt khái niệm, GatewayClass tương tự như IngressClass trong mô hình Ingress truyền thống, cho phép chuẩn hóa cách triển khai Gateway theo từng nhà cung cấp hoặc công nghệ
Gateway: Định nghĩa điểm vào (entry point) của traffic vào cluster, bao gồm port, protocol (HTTP, HTTPS, TCP…), cấu hình TLS và các chính sách ở mức hạ tầng. Gateway thường do đội nền tảng (platform / infra) quản lý.
Route: Xác định cách traffic được định tuyến đến các backend service. Gateway API hỗ trợ nhiều loại Route tương ứng với từng giao thức, giúp mở rộng khả năng quản lý traffic vượt xa Ingress truyền thống:
- HTTPRoute: Quản lý routing cho HTTP/HTTPS với các rule linh hoạt như path, host, header hoặc method, phù hợp cho web application và REST API.
- GRPCRoute: Hỗ trợ định tuyến traffic gRPC theo service và method, đáp ứng tốt các hệ thống microservices sử dụng gRPC.
- TCPRoute: Cho phép forward traffic TCP thuần, phù hợp với các dịch vụ không chạy trên HTTP như database hoặc message broker.
- TLSRoute: Định tuyến traffic ở tầng TLS (thường dựa trên SNI), hỗ trợ các kịch bản TLS passthrough hoặc multi-tenant.
- UDPRoute: Phục vụ các workload sử dụng UDP như DNS, streaming hoặc các dịch vụ real-time.

Việc tách biệt Gateway và Route cho phép phân chia rõ ràng trách nhiệm giữa quản lý hạ tầng và logic routing của ứng dụng. Cách tiếp cận này giúp hệ thống linh hoạt hơn, dễ mở rộng, đồng thời giảm sự phụ thuộc chặt chẽ giữa cấu hình hạ tầng và ứng dụng – một điểm hạn chế lớn của mô hình Ingress trước đây.

So sánh Gateway API và Ingress

Tiêu chí	Ingress	Gateway API
Chuẩn hóa	Không thống nhất giữa các Ingress Controller	Chuẩn chung do Kubernetes SIG-NETWORK định nghĩa
Phân tách vai trò	Không có, mọi cấu hình nằm trong Ingress	Có, tách rõ Infra / Platform / App
Hỗ trợ giao thức	Chỉ HTTP/HTTPS	HTTP, HTTPS, TCP, TLS, UDP, gRPC
Routing rule	Path, Host đơn giản	Path, Header, Query, Method, SNI
Routing nâng cao	Phụ thuộc annotation	Chuẩn hóa trong Route
Khả năng mở rộng	Hạ chế khó mở rộng chuyển đổi giữa các controller	Thiết kế mở, dễ mở rộng

Hướng dẫn cài đặt NGINX Gateway Fabric

Để cụ thể hóa các khái niệm đã trình bày ở trên, phần này sẽ đi vào triển khai Gateway API trong một môi trường Kubernetes đơn giản. Thông qua một ứng dụng demo chạy trên Minikube, sử dụng NGINX Gateway Fabric làm Gateway Controller, chúng ta sẽ lần lượt thiết lập Gateway, cấu hình các tài nguyên routing và kiểm chứng cách traffic được tiếp nhận và định tuyến từ bên ngoài cluster vào các service bên trong. Qua đó, người đọc có thể liên kết giữa lý thuyết Gateway API và cách áp dụng thực tế trong triển khai và vận hành Kubernetes.

Cài đặt môi trường

Tạo Cluster sử dụng Minikube:

curl -LO https://github.com/kubernetes/minikube/releases/latest/download/minikube-linux-amd64 



sudo install minikube-linux-amd64 /usr/local/bin/minikube && rm minikube-linux-amd64



minikube start


kubectl get po -A

NAMESPACE     NAME                               READY   STATUS    RESTARTS      AGE
kube-system   coredns-66bc5c9577-hbcf6           1/1     Running   0             56s
kube-system   etcd-minikube                      1/1     Running   0             62s
kube-system   kube-apiserver-minikube            1/1     Running   0             63s
kube-system   kube-controller-manager-minikube   1/1     Running   0             63s
kube-system   kube-proxy-lvsnm                   1/1     Running   0             56s
kube-system   kube-scheduler-minikube            1/1     Running   0             62s
kube-system   storage-provisioner                1/1     Running   1 (26s ago)   60s

Cài đặt thử nghiệm

Cài Gateway API: Trong bài này tôi sẽ sử dụng NGINX Gateway Fabric để triển khai Gateway API

Thực hiện cài NGINX Gateway Fabric Controller qua helm

Cài đặt Gateway API resources

kubectl kustomize "https://github.com/nginx/nginx-gateway-fabric/config/crd/gateway-api/standard?ref=v2.3.0" | kubectl apply -f -

Cài đặt NGINX Gateway Controller bằng helm chart

helm install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric --create-namespace -n nginx-gateway

kubectl get gatewayclass

NAME    CONTROLLER                                   ACCEPTED   AGE
nginx   gateway.nginx.org/nginx-gateway-controller   True       117s

kubectl get pod -n nginx-gateway

NAME                                       READY   STATUS    RESTARTS   AGE
ngf-nginx-gateway-fabric-5bff9d865-5brb7   1/1     Running   0          4m18s

Triển khai ứng dụng demo

Ta sử dụng Bookinfo (Istio sample) để làm ứng dụng minh họa.

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.11/samples/bookinfo/platform/kube/bookinfo.yaml

Các service chính:

productpage → /
details → /details

Kiểm tra

kubectl get pods


NAME                              READY   STATUS    RESTARTS   AGE
details-v1-75c85494bb-mkl9b       1/1     Running   0          60s
productpage-v1-7c9bf9c988-jv9fd   1/1     Running   0          60s

Create a Gateway

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: nginx-gateway
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    protocol: HTTP
    port: 80
EOF

kubectl get gateway


NAME            CLASS   ADDRESS       PROGRAMMED   AGE
nginx-gateway   nginx   10.104.4.90   True         70s

Tạo và cấu hình HTTPRoute

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: bookinfo-route
spec:
  parentRefs:
  - name: nginx-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /details
    backendRefs:
    - name: details
      port: 9080
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: productpage
      port: 9080
EOF

Kết quả

Lấy địa chỉ IP của Gateway

GATEWAY=$(kubectl get gateway nginx-gateway -o jsonpath='{.status.addresses[0].value}')

Kiểm tra Details Service:

curl --fail -s http://"$GATEWAY"/details/1 | jq

Kết quả

{
  "id": 1,
  "author": "William Shakespeare",
  "year": 1595,
  "type": "paperback",
  "pages": 200,
  "publisher": "PublisherA",
  "language": "English",
  "ISBN-10": "1234567890",
  "ISBN-13": "123-1234567890"
}

Kiểm tra Productpage Service:

curl http://$GATEWAY/

Bạn sẽ thấy trang HTML của Bookinfo.

<!DOCTYPE html>
<html>
  <head>
    <title>Simple Bookstore App</title>

. . .
<!-- Latest compiled and minified JavaScript -->
<script src="static/jquery.min.js"></script>

<!-- Latest compiled and minified JavaScript -->
<script src="static/bootstrap/js/bootstrap.min.js"></script>

  </body>
</html>

Việc Ingress NGINX bước vào lộ trình ngừng bảo trì đánh dấu một bước chuyển quan trọng trong cách Kubernetes quản lý north–south traffic. Gateway API, với kiến trúc phân tách vai trò rõ ràng, khả năng mở rộng cao và chuẩn hóa ở mức API, đang nổi lên như giải pháp thay thế hiện đại. Thông qua ví dụ triển khai với NGINX Gateway Fabric, các đội ngũ nền tảng và vận hành có thể áp dụng Gateway API ngay hôm nay, đồng thời chuẩn bị lộ trình chuyển đổi để đảm bảo tính ổn định, bảo mật và khả năng mở rộng lâu dài cho hệ thống Kubernetes.

#CloudWave Radar

Chúng tôi có 4 môi trường staging, 2 môi trường production, hàng chục microservice và rất nhiều phiên bản thử nghiệm. Lúc đầu dùng VPS tưởng là đủ, nhưng rồi mỗi lần cập nhật code là một lần lo… không biết lần này ‘tháo’ có làm hỏng cái gì không?

Tại sao doanh nghiệp hiện đại cần Kubernetes?