Quản lý lưu lượng cloud-native dựa trên Kubernetes Gateway API

1. Tổng quan

Định nghĩa: Kubernetes Gateway API là API mạng dịch vụ có khả năng mở rộng và nhận biết giao thức, kết nối lưu lượng từ bên ngoài hoặc bên trong cụm bằng các tài nguyên khai báo là Gateway và Route, đồng thời tách biệt trách nhiệm giữa người phụ trách hạ tầng·người vận hành cụm·lập trình viên ứng dụng.

Chuẩn lưu lượng bên ngoài ban đầu của Kubernetes là Ingress. Ingress cung cấp mô hình lối vào HTTP đơn giản ánh xạ host và đường dẫn tới Service, nhưng ngay khi phụ thuộc vào annotation riêng của từng bản triển khai, tính di động và tính nhất quán vận hành bị giảm sút. Để biểu diễn việc chia tách lưu lượng, định tuyến theo header, đa giao thức, phân tách quyền theo tổ chức, người dùng phải học cấu hình riêng của từng Ingress Controller.

Gateway API không giải quyết vấn đề này chỉ đơn giản bằng "một Ingress có nhiều trường hơn". Nó tách đối tượng tạo hoặc chọn hạ tầng khỏi đối tượng viết quy tắc lưu lượng ứng dụng, để ranh giới vận hành thực tế của tổ chức được phản ánh vào mô hình tài nguyên Kubernetes. Nhờ đó có thể cộng tác theo cách nhóm nền tảng quản lý GatewayClass và Gateway, còn nhóm dịch vụ quản lý HTTPRoute hay GRPCRoute.

Bản thân Gateway API không phải là proxy data plane. Nó cũng không phải một bộ cân bằng tải duy nhất được tích hợp sẵn trong Kubernetes; controller triển khai Gateway API sẽ đọc tài nguyên và dịch thành cấu hình thực tế của Envoy, NGINX, bộ cân bằng tải đám mây, thiết bị phần cứng, v.v. Nếu bỏ qua sự phân biệt này, người ta sẽ hiểu lầm rằng chỉ cần YAML được áp dụng là việc xử lý lưu lượng đã được bảo đảm.

Theo tài liệu chính thức tính đến ngày 25/9/2026, GatewayClass, Gateway, HTTPRoute, GRPCRoute được mô tả là các loại API ổn định, và trang phát hành chính thức của dự án hiển thị v1.6.2 là bản phát hành mới nhất. Khi áp dụng thực tế, cần xác nhận riêng phiên bản Gateway API mà controller hỗ trợ và mức độ hỗ trợ của từng trường.

1.1 Bối cảnh ra đời và sự cần thiết

Thứ nhất, chu kỳ thay đổi của nền tảng và ứng dụng khác nhau. Người phụ trách nền tảng phải vận hành ổn định các nền tảng như IP công khai dùng chung, chứng chỉ TLS, tường lửa, proxy L4/L7. Ngược lại, người phụ trách ứng dụng thực hiện thay đổi thường xuyên như chỉ gửi 10% /checkout sang phiên bản mới hoặc chỉ gửi các yêu cầu có header cụ thể sang dịch vụ thử nghiệm. Nếu hai mối quan tâm này trộn lẫn trong một đối tượng Ingress, quyền sẽ bị cấp quá mức hoặc xảy ra xung đột thay đổi.

Thứ hai, khi số lượng microservice tăng, lưu lượng ngoài HTTP cũng trở nên quan trọng. gRPC thực hiện giao tiếp giữa các dịch vụ dựa trên HTTP/2, còn TLS passthrough hay tích hợp thiết bị dựa trên TCP khó biểu diễn chỉ bằng quy tắc đường dẫn HTTP đơn giản. Gateway API đi theo hướng duy trì quan hệ tài nguyên chung trong khi mở rộng Route theo từng giao thức.

Thứ ba, vận hành khai báo phát huy hiệu quả lớn khi tách "muốn gì" khỏi "triển khai như thế nào". HTTPRoute khai báo yêu cầu /v1 sẽ được gửi tới Service nào, còn controller chuyển đổi cùng ý định đó cho phù hợp với cách triển khai của data plane. Tính di động không có nghĩa là mọi chi tiết triển khai đều giống nhau, mà có nghĩa là ý định chung có thể biểu diễn bằng chuẩn có thể di chuyển giữa các bản triển khai.

1.2 Góc nhìn cốt lõi của bài làm

Trong bài thi Kỹ sư chuyên nghiệp (Professional Engineer), quan trọng hơn việc liệt kê tên tài nguyên là giải thích luồng "phân tách trách nhiệm → ranh giới tin cậy → điều phối của controller → phản ánh vào data plane → quan sát trạng thái". Đặc biệt, phải phân biệt spec của Gateway API là trạng thái mong muốn, còn các điều kiện trong status và sự kiện của controller thể hiện trạng thái hội tụ thực tế.

Ngoài ra, nếu trình bày rằng Gateway API loại bỏ Ingress ngay lập tức thì không chính xác. Tài liệu chính thức của Kubernetes giải thích rằng Ingress API vẫn được duy trì ở trạng thái ổn định và không có kế hoạch gỡ bỏ, nhưng API đã bị đóng băng nên việc phát triển tính năng mới được khuyến nghị dùng Gateway API. Do đó, chiến lược thực tế là giữ nguyên Ingress hiện có, áp dụng Gateway API từ các dịch vụ mới, xác nhận các chỉ số tính năng·hiệu năng·vận hành rồi chuyển đổi dần dần.

2. Sơ đồ khái niệm và kiến trúc tổng thể

flowchart LR
    U[Client / User] --> DNS[DNS]
    DNS --> G[Gateway<br/>Listener: 443]
    GC[GatewayClass<br/>Chọn controller] --> G
    G --> HR[HTTPRoute<br/>Host/Path/Header/Weight]
    G --> GR[GRPCRoute<br/>Service/Method]
    HR --> S1[Service: checkout-v1]
    HR --> S2[Service: checkout-v2]
    GR --> S3[Service: payment-grpc]
    S1 --> P1[Pods]
    S2 --> P2[Pods]
    S3 --> P3[Pods]
    C[Gateway Controller] -. watches .-> GC
    C -. reconciles .-> G
    C -. reconciles .-> HR
    C -. programs .-> DP[Proxy / Load Balancer]
    DP --> S1
    DP --> S2
    DP --> S3

Trong cấu trúc trên, GatewayClass biểu thị loại Gateway do một controller triển khai cụ thể cung cấp. Ví dụ, nếu tách lớp dùng cho Internet công cộng và lớp dùng cho mạng riêng trong cùng một cụm, có thể ngăn nhóm ứng dụng tùy ý tạo bộ cân bằng tải công khai. Điểm cốt lõi là GatewayClass không phải là một instance đang chạy, mà là căn cứ cho chính sách chung và lựa chọn controller.

Gateway là điểm vào logic nhận lưu lượng thực tế. Nó khai báo địa chỉ, cổng, giao thức, tham chiếu chứng chỉ, phạm vi chấp nhận Route theo từng listener. Nó có thể là một bộ cân bằng tải đám mây hoặc một instance proxy trong cụm, vì vậy không nên cố định rằng "một đối tượng Gateway = một proxy của một sản phẩm cụ thể".

HTTPRoute biểu diễn quy tắc HTTP đi từ listener của Gateway tới Service. Vì các điều kiện như host, đường dẫn, so khớp header và trọng số backend được biểu diễn bằng trường tài nguyên, việc kiểm chứng và review dễ hơn so với annotation riêng của từng bản triển khai. Tuy nhiên, không phải controller nào cũng hỗ trợ mọi trường tùy chọn ở cùng một mức, nên phải xem đồng thời conformance và tài liệu của bản triển khai.

GRPCRoute mô hình hóa ý định theo đơn vị dịch vụ và phương thức gRPC. gRPC dùng stream HTTP/2, mã trạng thái và kết nối dài hạn, nên chỉ sao chép cấu hình proxy HTTP đơn giản là không đủ. Phải kiểm chứng bản triển khai Gateway có thực sự hỗ trợ các tính năng liên quan đến HTTP/2 và gRPC không, và chính sách timeout, retry có làm hỏng ngữ nghĩa stream không.

2.1 Quan hệ tài nguyên và ranh giới trách nhiệm

flowchart TB
    IP[Infrastructure Provider] --> GC[GatewayClass]
    CO[Cluster Operator] --> G[Gateway]
    CO --> POL[Policy / TLS / Network Boundary]
    AD[Application Developer] --> R[HTTPRoute / GRPCRoute]
    G -->|listener accepts| R
    R -->|backendRefs| SV[Service]
    RG[ReferenceGrant] -. cross-namespace trust .-> R
    CTRL[Controller] -->|status conditions| GC
    CTRL -->|status conditions| G
    CTRL -->|status conditions| R
    CTRL --> DP[Data Plane]

Mô hình hướng vai trò của Gateway API phải được thiết kế cùng với RBAC. Nhà cung cấp hạ tầng định nghĩa GatewayClass cho nhiều tenant sử dụng, người vận hành cụm quản lý địa chỉ, listener·chứng chỉ·chính sách chấp nhận của Gateway. Lập trình viên ứng dụng có thể bị giới hạn quyền chỉ được thay đổi Route trong namespace mình phụ trách.

Sự phân tách này không tự động an toàn. Nếu cấp cho lập trình viên cả quyền sửa Gateway thì ưu điểm của mô hình vai trò biến mất, còn nếu yêu cầu người vận hành có quyền trên mọi Route thì tốc độ triển khai chậm lại. Phải chi tiết hóa quyền get, list, watch, create, update theo từng tài nguyên cho phù hợp với hệ thống phê duyệt thay đổi của tổ chức, và làm cho quyền sở hữu thư mục trong kho GitOps khớp với Kubernetes RBAC.

Khi Route tham chiếu Service ở namespace khác hoặc gắn vào Gateway ở namespace khác, phải chỉ rõ ranh giới tin cậy. Mặc định để trong cùng namespace, và khi cần thì dùng cơ chế cho phép tường minh như allowedRoutes, ReferenceGrant. Nếu để mở liên namespace như một mặc định tiện lợi, rủi ro một nhóm chặn đường lưu lượng của nhóm khác hoặc kết nối tới backend nhạy cảm sẽ tăng lên.

2.2 Control plane và data plane

Controller theo dõi các đối tượng Gateway API, tính toán quan hệ phụ thuộc rồi điều chỉnh cấu hình data plane. Quá trình này là bất đồng bộ, nên kubectl apply thành công không có nghĩa là việc lan truyền DNS, chuẩn bị chứng chỉ, cấp phát bộ cân bằng tải, cấu hình lại proxy đã hoàn tất. Người vận hành phải xem đồng thời các điều kiện status.parents, Accepted, Programmed, ResolvedRefs của tài nguyên và log của controller.

Data plane xử lý các gói tin thực tế. Có nhiều cách triển khai như bộ cân bằng tải L4, reverse proxy L7, sidecar của service mesh, tầng chuyển tiếp dựa trên kernel. Dù cùng một HTTPRoute, độ trễ và dạng sự cố vẫn khác nhau tùy theo vị trí kết thúc TLS, tái sử dụng kết nối, bộ đệm, cách retry của data plane, nên kiểm thử hiệu năng nhất định phải thực hiện trên bản triển khai thực tế.

Controller có vòng lặp điều phối để giảm chênh lệch giữa trạng thái khai báo và trạng thái quan sát. Khi Route bị xóa, đường dẫn cũ trong proxy phải được gỡ bỏ, và khi EndpointSlice của Service backend thay đổi, endpoint đích cũng phải được cập nhật. Khi có sự cố, phải liên kết sự kiện, phiên bản cấu hình, người thay đổi, Git commit để có thể truy vết chênh lệch giữa cấu hình được phản ánh bình thường lần cuối và trạng thái mong muốn hiện tại.

3. Các tài nguyên chính và quy trình xử lý lưu lượng

3.1 GatewayClass

GatewayClass là lớp dùng để chọn controller quản lý Gateway. Tương tự StorageClass, nó trừu tượng hóa loại triển khai mà nền tảng cung cấp, nhưng tính năng hỗ trợ thực tế, chi phí, vị trí mạng, cách xử lý TLS khác nhau theo từng controller. Không nên chỉ nhìn tên mà giả định tính năng giống nhau; phải ghi kết quả conformance và ràng buộc vận hành của bản triển khai vào danh mục dịch vụ.

parametersRef của GatewayClass có thể được dùng làm điểm mở rộng để liên kết cấu hình bổ sung riêng của bản triển khai. Khi đó, nếu để mọi nhóm chỉ định tham số tùy ý, chính sách nền tảng có thể bị vượt qua, nên phải dùng chính sách để giới hạn loại tham số được phép và phạm vi giá trị. Nhóm nền tảng nên phân biệt và tài liệu hóa riêng các trường chuẩn và phần mở rộng của bản triển khai.

3.2 Gateway và Listener

Gateway khai báo điều kiện tiếp nhận bằng một hoặc nhiều listener. Listener kết hợp cổng và giao thức, tên host, tham chiếu chứng chỉ, quy tắc chấp nhận Route. Khi vận hành nhiều host trên cùng một cổng, phải xác nhận tên host và việc chọn chứng chỉ khớp nhau, và so sánh đồng thời yêu cầu bảo mật và yêu cầu hiệu năng để quyết định kết thúc TLS tại Gateway hay chuyển tiếp tới backend.

Địa chỉ Gateway có thể được báo cáo trong status.addresses dưới dạng IP bên ngoài hoặc tên DNS do controller cấp phát. Bản ghi DNS phải được kết nối sau khi xác nhận trạng thái sẵn sàng của địa chỉ này, và thiết kế cũng phải bao gồm chi phí bộ cân bằng tải đám mây, cạn kiệt IP, chính sách địa chỉ đặt trước. Tách Gateway chỉ dùng nội bộ và Gateway công khai ra bên ngoài thành các lớp riêng có thể thu hẹp phạm vi sự cố.

3.3 HTTPRoute

HTTPRoute trỏ tới Gateway cấp trên bằng parentRefs, và khai báo ý định định tuyến bằng hostnames và rules. Một quy tắc kết hợp điều kiện so khớp như đường dẫn·header·query với tham chiếu backend, bộ lọc, trọng số. Thứ tự ưu tiên so khớp càng phức tạp thì càng phải kiểm thử sự chồng lấn giữa các quy tắc, và phải xác nhận kỳ vọng "đường dẫn cụ thể hơn được áp dụng trước" bằng hành vi chính thức của bản triển khai và kết quả kiểm thử.

Chia tách lưu lượng hữu ích cho triển khai canary. Ví dụ, gán trọng số 90 cho Service v1 và 10 cho Service v2 thì có thể gửi một phần lưu lượng tới phiên bản mới. Nhưng trọng số là tỷ lệ logic tính theo số yêu cầu, không tự động bảo đảm cố định phiên theo người dùng hay phân chia theo số tiền. Với các yêu cầu mà retry và tính nhất quán trạng thái quan trọng như thanh toán, phải thiết kế riêng tính nhất quán dựa trên định danh người dùng, xử lý trùng lặp ở ứng dụng và chỉ số quan sát.

Bộ lọc cung cấp các hành vi mà bản triển khai hỗ trợ như sửa header yêu cầu·phản hồi, chuyển hướng, viết lại URL, nhân bản yêu cầu (mirroring). Thứ tự và tương tác của bộ lọc có thể khác nhau theo giao thức·proxy, nên phải kiểm thử việc có xóa header xác thực trước khi gửi tới backend không, và thay đổi host gốc và host chuyển tiếp theo thứ tự nào.

3.4 GRPCRoute và Route mở rộng

GRPCRoute cung cấp so khớp theo đơn vị dịch vụ và phương thức, cho phép viết chính sách phù hợp với ranh giới của API gRPC. Tuy nhiên, RPC streaming có vòng đời và ngữ nghĩa retry khác với yêu cầu HTTP ngắn thông thường. Nếu tự động retry khi kết nối bị ngắt, tác dụng phụ phía máy chủ có thể bị lặp lại, nên phải xem xét đồng thời tính lũy đẳng·deadline·chính sách kết nối lại của client.

Các tài nguyên xử lý giao thức bổ sung như TCPRoute, TLSRoute, UDPRoute có thể có mức độ trưởng thành khác nhau theo kênh và phiên bản. Tài nguyên chưa có trong kênh ổn định dù nhiều tính năng vẫn có khả năng thay đổi API, và trước khi áp dụng vào production phải kiểm tra việc có cài kênh thử nghiệm không cùng lộ trình nâng cấp·rollback. Khi dùng lẫn kênh chuẩn và kênh thử nghiệm trong cùng một cụm, cũng phải chú ý xung đột phiên bản CRD.

3.5 Kết nối Route và mô hình tin cậy

Route chỉ định Gateway hoặc listener bằng parentRefs, còn listener của Gateway quyết định loại Route và phạm vi namespace mà nó chấp nhận. Điều kiện hai chiều này là cơ chế an toàn giảm vấn đề ứng dụng tùy ý gắn Route vào Gateway công khai dùng chung. Không nên coi sự tồn tại của Route là đã được phản ánh vào data plane mà phải xác nhận trạng thái Accepted và Programmed.

Kết nối trong cùng namespace vận hành đơn giản, nhưng khi nhiều namespace dịch vụ dùng chung Gateway trong namespace nền tảng chung thì cần kết nối liên namespace. Khi đó phải kết hợp nhãn namespace được phép, phê duyệt ReferenceGrant, quyền service account và review thay đổi. Kết hợp nhãn và chính sách thể hiện nhóm·môi trường·cấp dữ liệu sẽ an toàn hơn chỉ tin vào tên namespace.

4. Kiến trúc vận hành và thiết kế bảo mật

4.1 TLS và chứng chỉ

Nếu kết thúc TLS bên ngoài tại Gateway thì dễ áp dụng quản lý chứng chỉ tập trung và chính sách bảo mật chung. Ngược lại, nếu cần mã hóa đầu cuối tới tận backend thì có thể chọn TLS passthrough hoặc mã hóa lại từ Gateway tới backend. Hai cách khác nhau về khả năng quan sát, điểm quản lý chứng chỉ, chi phí mã hóa và cách truyền thông tin client gốc tới ứng dụng.

Tham chiếu chứng chỉ có thể vượt qua ranh giới namespace nên phải chỉ rõ việc cho phép tham chiếu. Giám sát ngày hết hạn chứng chỉ và kiểm chứng listener không mất trạng thái Programmed trong khi gia hạn. Phải định nghĩa thành chuẩn vận hành: TLS 1.2 trở lên, bộ mã hóa được phép, khớp SNI và tên host, quy trình thay thế khẩn cấp khi bị thu hồi·rò rỉ.

4.2 Xác thực·phân quyền và thực thi chính sách

Gateway API mô hình hóa đường đi lưu lượng và quan hệ tài nguyên, nhưng không chuẩn hóa toàn bộ việc xác thực·phân quyền người dùng·chính sách API chi tiết. Kiểm chứng JWT, tích hợp OAuth2, WAF, rate limit, mTLS, giới hạn kích thước yêu cầu được đặt ở tầng phù hợp trong số controller·phần mở rộng chính sách·service mesh·thiết bị bảo mật bên ngoài. Nếu không phân biệt Route chuẩn và phần mở rộng của bản triển khai trong cùng một tài liệu, kiểm soát bảo mật có thể biến mất khi chuyển sang controller khác.

Giá trị mặc định của chính sách nên gần với từ chối. Chỉ rõ host và đường dẫn công khai, phương thức cho phép, cổng backend, nguồn CORS, kích thước yêu cầu tối đa, và các yêu cầu không được chỉ định phải kết thúc ở trạng thái mong muốn như 404·403·429. Đặc biệt, khi đặt đường dẫn quản trị trên cùng Gateway, trước tiên nên xem xét phương án tách mặt quản trị bằng listener riêng·Gateway riêng·network policy.

4.3 Khả năng quan sát và ứng phó sự cố

Các hạng mục quan sát tối thiểu là lượng yêu cầu, tỷ lệ thành công, tỷ lệ 4xx·5xx, độ trễ p50/p95/p99, lỗi bắt tay TLS, kết nối đang hoạt động, trạng thái Endpoint backend. Trong canary dựa trên trọng số, phải xem đồng thời tỷ lệ yêu cầu và lỗi·độ trễ theo từng phiên bản; nếu chỉ xem trung bình tổng thể có thể bỏ sót sự cố ở lượng lưu lượng nhỏ.

Trong truy vết phân tán, liên kết trace context do Gateway tạo·truyền và ID yêu cầu gốc với log dịch vụ. Log ghi lại host, mẫu đường dẫn, tên Route, tên Gateway, Service backend, mã phản hồi, kết quả quyết định chính sách, nhưng phải che (masking) token·thông tin cá nhân·giá trị query nhạy cảm. Đồng bộ thời gian giữa log controller và log data plane cũng là điều kiện thiết yếu để phân tích nguyên nhân sự cố.

Trước khi thay đổi, lần lượt chạy kubectl diff, kiểm chứng schema tĩnh, kiểm thử conformance, kiểm thử chính sách, lưu lượng tổng hợp. Sau khi thay đổi, xác nhận status của Route và cấu hình proxy thực tế, kết nối DNS·chứng chỉ·backend. Rollback có thể không chỉ cần hoàn tác Git commit, nên phải xác nhận trước tính tương thích của các phiên bản CRD·controller·data plane trước đó.

5. Phân tích so sánh

5.1 Ingress và Gateway API

Ingress vẫn hiệu quả cho việc công khai HTTP/HTTPS ra bên ngoài một cách đơn giản. Đây là API ổn định, hệ sinh thái controller hiện có rộng, và dịch vụ quy mô nhỏ có thể vận hành với ít tài nguyên. Tuy nhiên, nếu mở rộng tính năng nâng cao bằng annotation, tên và ý nghĩa annotation khác nhau theo từng controller, làm giảm tính di động cấu hình·khả năng kiểm chứng chính sách.

Gateway API đi theo hướng cung cấp phân tách vai trò, đa giao thức, Route có cấu trúc, báo cáo trạng thái, điểm mở rộng dưới dạng tài nguyên chuẩn. Đổi lại, số lượng tài nguyên nhiều và phải quản lý việc cài controller·vòng đời CRD·khác biệt tính năng giữa các bản triển khai. Do đó, thay vì chuyển đổi hàng loạt mọi Ingress, chuyển đổi bắt đầu từ các dịch vụ cần định tuyến phức tạp hoặc ranh giới tổ chức sẽ có hiệu quả cao so với chi phí.

Phân loại	Ingress	Gateway API
Đối tượng chính	Công khai HTTP/HTTPS đơn giản ra bên ngoài	Mạng dịch vụ dựa trên vai trò và quản lý lưu lượng nâng cao
Cách cấu hình	Quy tắc Ingress + annotation của bản triển khai	Phân cấp GatewayClass, Gateway, Route
Phân tách trách nhiệm	Dễ bị trộn lẫn trong một đối tượng	Tách vai trò hạ tầng·vận hành·ứng dụng
Giao thức	Chủ yếu HTTP/HTTPS	HTTP, gRPC và mở rộng theo bản triển khai·kênh
Chia tách lưu lượng·so khớp header	Phụ thuộc phần mở rộng của từng controller	Cung cấp phạm vi biểu diễn được bằng trường chuẩn
Độ khó chuyển đổi	Thấp trong môi trường hiện có	Cần hệ thống CRD·controller·quyền·kiểm thử
Chiến lược hiện tại	Duy trì ổn định, API đóng băng	Khuyến nghị cho tính năng nâng cao mới và thiết kế mới

5.2 API Gateway và Service Mesh

API Gateway có thế mạnh trong kiểm soát lưu lượng bắc-nam giữa bên tiêu thụ bên ngoài và cụm hoặc ranh giới dịch vụ. Dễ quản lý DNS công khai, TLS, WAF, xác thực bên tiêu thụ, quota tại một ranh giới. Gateway API là mô hình tài nguyên Kubernetes chuẩn hóa để khai báo ranh giới này, không phải sản phẩm tự động cung cấp quản lý sản phẩm API·cổng thông tin lập trình viên·tính phí.

Service Mesh tập trung vào lưu lượng đông-tây giữa các dịch vụ, định danh dịch vụ, mTLS nội bộ, retry, ngắt mạch, quan sát chi tiết. Dùng Gateway API cùng mesh cho phép xác định ranh giới: Gateway phụ trách lối vào bên ngoài, còn mesh phụ trách lời gọi dịch vụ nội bộ. Tuy nhiên, nếu cấu hình trùng retry·timeout·rate limit ở cả hai phía, bùng nổ yêu cầu và độ trễ có thể bị khuếch đại, nên phải xác định một chủ sở hữu duy nhất cho chính sách.

Trục so sánh	Tầng lối vào dựa trên Gateway API	Service Mesh
Hướng chính	Bắc-nam bên ngoài→cụm/dịch vụ	Đông-tây dịch vụ↔dịch vụ
Đối tượng cốt lõi	GatewayClass, Gateway, Route	Định danh dịch vụ, proxy, chính sách
Mối quan tâm tiêu biểu	DNS, TLS, host·đường dẫn·giao thức	mTLS, khám phá dịch vụ, retry·ngắt mạch
Rủi ro vận hành	Đường dẫn công khai·chứng chỉ·bề mặt tấn công bên ngoài	Chi phí proxy·bùng nổ chính sách·vòng lặp
Cách kết hợp	Lối vào bên ngoài và định tuyến dùng chung	Giao tiếp nội bộ và tin cậy workload

6. Ví dụ áp dụng

6.1 Triển khai canary cho thương mại điện tử

Giả sử một nền tảng thương mại điện tử vận hành đồng thời checkout-v1 và checkout-v2. Nhóm nền tảng tạo Gateway có cổng 443 và chứng chỉ dùng chung, còn nhóm ứng dụng đặt trọng số HTTPRoute là 95:5. Nếu tỷ lệ lỗi và độ trễ p99 ở 5% lưu lượng vượt ngưỡng, chỉ cần đưa Route về trọng số trước đó để giảm thiểu mà không cấp phát lại toàn bộ data plane.

Tuy nhiên, nếu chia yêu cầu thanh toán theo tỷ lệ ngẫu nhiên đơn giản, yêu cầu xem và thanh toán của cùng một người dùng có thể đi tới các phiên bản khác nhau. Giỏ hàng và phiên thanh toán phải dùng chung kho phiên của ứng dụng, và phải phân biệt yêu cầu có thể retry với yêu cầu không thể retry. Ngoài ra, phải có chỉ số riêng về tỷ lệ thanh toán thành công, phê duyệt trùng lặp, tỷ lệ hoàn tiền theo từng phiên bản canary.

6.2 Nền tảng đa tenant

Giả sử trong cụm Kubernetes dùng chung, nhóm A và nhóm B mỗi nhóm dùng namespace riêng. Nhóm nền tảng cung cấp GatewayClass chỉ dùng nội bộ, và nhóm vận hành chỉ cho phép Route của namespace team-a và team-b trên listener cụ thể. Mỗi nhóm có thể thay đổi HTTPRoute mình sở hữu, nhưng không thể thay đổi địa chỉ bên ngoài·chính sách TLS·namespace được phép của Gateway.

Cấu trúc này giảm quyền tài nguyên, nhưng không tự động bảo đảm cả ranh giới dữ liệu. Phải cấu hình riêng mức độ nhạy cảm và network policy của Service mà Route kết nối, xác thực backend, quyền truy cập log. Cũng cần bổ sung kiểm chứng quyền sở hữu tên host và workflow phê duyệt để các tenant không tranh chấp yêu cầu cùng một tên host.

6.3 Liên kết gRPC nội bộ·bên ngoài

Khi backend di động nhận yêu cầu gRPC tại Gateway bên ngoài và chuyển tới Service payment-grpc bên trong, có thể chia đường theo dịch vụ·phương thức trong GRPCRoute. Nếu timeout, kích thước thông điệp tối đa, yêu cầu xác thực của Login và Authorize khác nhau, chính sách theo đơn vị phương thức sẽ hữu ích.

Ngược lại, RPC streaming dài hạn duy trì kết nối lâu hơn yêu cầu HTTP thông thường, nên phải quản lý đồng thời idle timeout của bộ cân bằng tải và drain kết nối khi triển khai. Nếu cưỡng chế kết thúc stream hiện có khi chuyển sang phiên bản mới, trải nghiệm người dùng sẽ kém đi, nên phải kiểm chứng graceful shutdown, kết nối lại của client, xử lý sự kiện trùng lặp phía máy chủ.

7. Chuyên sâu: chiến lược áp dụng·chuyển đổi và điểm ra đề dự kiến

Áp dụng Gateway API không phải là dự án thay YAML mà là chuyển đổi mô hình vận hành nền tảng. Trước tiên, phân loại annotation Ingress hiện tại thành tính năng chuẩn, phần mở rộng của controller, logic ứng dụng. Với tính năng không thể chuẩn hóa, quyết định để ở phần mở rộng chính sách Gateway API hay chuyển sang dịch vụ hoặc tầng bảo mật riêng, rồi ước tính chi phí chuyển đổi.

Ở giai đoạn 2, cài đặt cùng GatewayClass và controller trên cụm phát triển·staging, và cấu hình song song các đường dẫn tiêu biểu trên cả Ingress và Gateway API. So sánh tỷ lệ yêu cầu, header phản hồi, chuỗi TLS, IP gốc, timeout, chuyển hướng, hành vi WebSocket·gRPC. Nếu chỉ kiểm tra có trả về HTTP 200 hay không thì không phát hiện được khác biệt ngữ nghĩa của proxy.

Ở giai đoạn 3, ưu tiên áp dụng Gateway API cho dịch vụ mới và dịch vụ có tần suất thay đổi cao. Làm rõ chủ sở hữu của Gateway dùng chung và Route theo nhóm, đưa phê duyệt GitOps·kiểm tra chính sách·kiểm thử conformance vào pipeline triển khai. Không xóa ngay Ingress hiện có mà chuyển đổi theo từng dịch vụ trong khi vẫn duy trì DNS và quy trình rollback.

Trong bài làm dự kiến, nên liên kết thành một chuỗi nhân quả: "phân cấp GatewayClass–Gateway–Route", "thiết kế hướng vai trò và tin cậy liên namespace", "trường chuẩn và tính di động so với Ingress", "tách controller·data plane", "vận hành dựa trên điều kiện trạng thái". Cuối cùng, phải nêu các đánh đổi gồm phụ thuộc bản triển khai và khả năng thay đổi của kênh thử nghiệm, kiểm chứng hiệu năng·bảo mật, chuyển đổi dần dần.

8. Các điểm cần lưu ý và hàm ý

Phải quản lý ranh giới giữa chuẩn và bản triển khai. Dù có tài nguyên chuẩn của Gateway API, phạm vi hỗ trợ thực tế của TLS, WAF, rate limit, chuyển hướng, tính năng quan sát khác nhau theo từng controller. Phải quản lý trường chuẩn và phần mở rộng của bản triển khai thành danh sách riêng, và với dịch vụ coi trọng tính di động thì chỉ dùng tính năng đã được xác nhận conformance.
Phải thiết kế đồng thời quyền và ranh giới mạng. Quyền tạo Route tương đương quyền thay đổi lưu lượng. Phải áp dụng đồng thời RBAC, allowedRoutes, ReferenceGrant, quyền sở hữu tên host, NetworkPolicy, xác thực backend để tách "có thể kết nối" với "có thể truy cập dữ liệu".
Phải kiểm chứng an toàn thay đổi bằng trạng thái và chỉ số. Accepted cho biết kết nối được cho phép, Programmed cho biết bản triển khai đã phản ánh — đây là manh mối vận hành, không phải bằng chứng cuối cùng về việc ứng dụng hoạt động bình thường. Phải xác nhận tỷ lệ thành công·độ trễ·lỗi backend·lưu lượng theo phiên bản thực tế và chuẩn bị tiêu chí rollback tự động.
Hiệu năng phải được đo bao gồm cả tầng proxy. Kết thúc·mã hóa lại TLS, stream HTTP/2 và gRPC, thao tác header, thu thập dữ liệu quan sát, proxy nhiều bước có thể làm tăng CPU·bộ nhớ·độ trễ. Phải kiểm thử tải trên data plane thực tế với RPS mục tiêu và độ trễ p99, số kết nối, thời gian drain khi có sự cố.
Phải quản lý vòng đời CRD và controller như một sản phẩm. Tài nguyên kênh thử nghiệm có thể bị thay đổi·xóa trong tương lai, nên cần có tiêu chí áp dụng production và cửa sổ nâng cấp riêng. Runbook vận hành phải bao gồm cả sao lưu CRD, rollback controller, fallback về Ingress hiện có, quy trình thu hồi chi phí·địa chỉ bộ cân bằng tải đám mây.
Phải tránh trùng lặp chính sách. Nếu đặt retry và timeout riêng ở Gateway, Service Mesh, WAF, ứng dụng, một lần thất bại có thể bị khuếch đại nhiều lần. Phải xác định tầng sở hữu yêu cầu, và tài liệu hóa xác thực bên ngoài·định tuyến dùng chung·tin cậy nội bộ·quyền nghiệp vụ như những trách nhiệm khác nhau.
Về mặt chiến lược, phải danh mục hóa chuẩn nền tảng thành danh mục dịch vụ. Thay vì để mỗi nhóm tự diễn giải Gateway, cung cấp lớp dùng chung, template Route khuyến nghị, mặc định bảo mật, dashboard quan sát, quy trình phê duyệt ngoại lệ sẽ bảo đảm được cả tính tự chủ phát triển lẫn khả năng kiểm soát. Gateway API là nền tảng để biểu diễn chuẩn đó bằng mã, nhưng không thay thế được quản trị vận hành của tổ chức.

Tài liệu tham khảo

Tài liệu Gateway chính thức của Kubernetes: https://kubernetes.io/docs/concepts/services-networking/gateway/
Tài liệu Ingress chính thức của Kubernetes: https://kubernetes.io/docs/concepts/services-networking/ingress/
Tổng quan API chính thức của Gateway API: https://gateway-api.sigs.k8s.io/concepts/api-overview/
Mô hình bảo mật chính thức của Gateway API: https://gateway-api.sigs.k8s.io/concepts/security-model/
Hướng dẫn chính thức và kênh cài đặt Gateway API: https://gateway-api.sigs.k8s.io/guides/
Bản phát hành chính thức của Gateway API: https://github.com/kubernetes-sigs/gateway-api/releases

Tóm tắt một câu: Kubernetes Gateway API là API mạng dịch vụ cloud-native tách biệt trách nhiệm giữa hạ tầng và ứng dụng bằng GatewayClass·Gateway·Route, cho phép quản lý lưu lượng đa giao thức được chuẩn hóa và vận hành dựa trên trạng thái.