Kubernetes Gateway API

 (romaglushko.com)
4 điểm bởi GN⁺ 4 giờ trước | 2 bình luận | Chia sẻ qua WhatsApp
  • Vào tháng 11 năm 2025, Kubernetes công bố deprecation của NGINX Ingress Controller vào tháng 3 năm 2026, khi thành phần này đang được sử dụng trên hơn 40% tổng số cluster; quyết định này trở thành bước ngoặt đưa Gateway API trở thành hậu nhiệm của Ingress API
  • Gateway API bao quát phạm vi tính năng rộng hơn cần thiết cho việc quản lý lưu lượng inbound, có khả năng biểu đạt cao hơn Ingress API và làm rõ tách biệt mối quan tâm giữa các nhóm
  • Các hạn chế của Ingress API gồm phạm vi API hẹp, khả năng mở rộng cứng nhắc, thiếu cơ chế cưỡng chế chính sách, ranh giới sở hữu mơ hồ và không hỗ trợ cross-namespace an toàn
  • Gateway API cung cấp mô hình tài nguyên tách biệt như GatewayClass, Gateway, Listener, Route, cùng các cơ chế bảo mật và mở rộng như ReferenceGrant và Policy attachment
  • Các CVE lặp đi lặp lại của NGINX Ingress Controller bắt nguồn từ khiếm khuyết mang tính cấu trúc, và về dài hạn di chuyển sang Gateway API là giải pháp căn cơ duy nhất

Quá trình tiến hóa của Ingress

  • Trong Kubernetes giai đoạn đầu năm 2014, tài nguyên Service là phương tiện mặc định để công khai ứng dụng
    • ClusterIP chỉ cung cấp tên DNS nội bộ trong cluster, không thể truy cập từ bên ngoài
    • NodePort mở một cổng cụ thể trên mọi node để nhận lưu lượng từ bên ngoài; nếu IP của node được công khai thì có thể bị lộ ra ngoài
    • LoadBalancer provisioning một bộ cân bằng tải bên ngoài với IP công khai để chuyển tiếp lưu lượng
    • ExternalName cung cấp bí danh trong cluster cho dịch vụ bên ngoài bằng bản ghi CNAME
  • Trong bốn loại này, chỉ NodePort và LoadBalancer có thể trực tiếp công khai ra bên ngoài
    • NodePort là primitive cơ bản nhưng quá thấp cấp, phải tự triển khai cân bằng tải bên ngoài giữa các node và định tuyến dựa trên path
  • LoadBalancer bổ sung bộ cân bằng tải L4 (TCP/UDP) trên nền NodePort và tự động provisioning, do Cloud Controller Manager đảm nhiệm
    • Tuy nhiên, phải quản lý nhiều IP công khai và bộ cân bằng tải nên chi phí tăng, đồng thời thiếu một điểm quản lý tập trung cho lưu lượng
  • Thay vì dùng một bộ cân bằng tải riêng cho mỗi Service, mô hình để một Service LoadBalancer duy nhất nhận toàn bộ lưu lượng rồi chuyển tới Deployment reverse proxy như NGINX để định tuyến theo đường dẫn và hostname chính là điểm khởi đầu của Ingress API và Ingress Controller

Ingress Controller

  • Năm 2015, nhóm Kubernetes giới thiệu Ingress API như một cách định nghĩa quy tắc định tuyến lưu lượng HTTP(S) bên ngoài tới Service nội bộ

  • Ingress API gồm hai tài nguyên IngressClass và Ingress, chỉ định nghĩa giao diện chung và cần cài Ingress Controller để có hành vi thực tế

  • IngressClass

    • Tài nguyên cluster-wide chỉ định controller nào sẽ xử lý một tập hợp tài nguyên Ingress cụ thể
    • Cho phép vận hành song song nhiều Ingress Controller trong cùng một cluster, mỗi controller chỉ theo dõi các tài nguyên được chọn bởi IngressClass của nó
    • Controller cần quyền ClusterRole để đọc và sử dụng IngressClass

  • Tài nguyên Ingress

    • Ingress là tài nguyên chính của Ingress API, kết hợp nhiều yếu tố
      • Định nghĩa định tuyến tới Service nội bộ bằng các quy tắc khớp theo path (exact/prefix) và host
      • Định nghĩa cấu hình TLS cho lưu lượng inbound
    • Khi tài nguyên được tạo, Ingress Controller phát hiện và cập nhật cấu hình riêng của nó để áp dụng các quy tắc định tuyến

  • Các vấn đề của Ingress API

    • Trong môi trường vận hành thực tế xuất hiện các vấn đề sau: phạm vi API rất hạn chế, khả năng mở rộng cứng nhắc, thiếu cơ chế cưỡng chế chính sách, ranh giới sở hữu mơ hồ và không hỗ trợ cross-namespace an toàn

  • Phạm vi API rất hạn chế

    • Ingress API không phải là đơn giản theo nghĩa gọn nhẹ mà là quá sơ sài (simplistic), chỉ bao phủ mức tối thiểu cần thiết cho cấu hình lưu lượng ingress
    • Nó không trực tiếp hỗ trợ các tính năng thường được mong muốn trong NGINX sau
      • request timeout, CORS, giới hạn max body size, sticky cookie session, chia tách lưu lượng canary, rate limiting, định tuyến theo header/query/cookie, chỉnh sửa header
    • Vì vậy, custom annotation trở thành cách chuẩn để truyền cấu hình bổ sung; một số controller như Traefik thì dùng CRD riêng
    • Khi dùng đồng thời nhiều Ingress Controller, không có cách cấu hình thống nhất nên annotation khác nhau theo từng controller, làm giảm tính di động
    • Ingress chỉ xử lý định tuyến HTTP(S), còn gRPC (L7), TCP và UDP (L4) thì được xử lý bằng custom annotation tùy theo từng implementation

  • Khả năng mở rộng cứng nhắc

    • custom annotation chỉ là các cặp key-value dạng chuỗi, nên phải tuần tự hóa cấu hình phức tạp thành chuỗi và vì thế thiếu khả năng biểu đạt

  • Thiếu cơ chế cưỡng chế chính sách

    • Nhóm ứng dụng có thể thêm annotation tùy ý vào tài nguyên Ingress; ví dụ, họ có thể vô hiệu hóa rate limiting mà nhóm nền tảng mong muốn áp dụng cho toàn bộ route
    • Bản thân Ingress API không có cơ chế cưỡng chế hành vi toàn cục, nên phải phụ thuộc vào các policy engine bên ngoài như Kyverno hoặc OPA Gatekeeper

  • Ranh giới sở hữu mơ hồ

    • Tài nguyên Ingress trộn lẫn nhiều loại cấu hình
      • Các quy tắc định tuyến thường do nhóm ứng dụng sở hữu
      • Cấu hình hostname và port thuộc về nhóm nền tảng quản lý DNS, load balancer và networking
      • Cấu hình TLS thuộc về nhóm nền tảng chịu trách nhiệm provisioning chứng chỉ
      • custom annotation có thể thuộc về một trong hai nhóm
    • Trong các hệ thống phức tạp được triển khai bằng umbrella Helm chart, Ingress thường nằm trong subchart của ứng dụng nhưng nhóm nền tảng vẫn cần cập nhật hoặc cưỡng chế một phần
    • Theo góc nhìn của nguyên tắc trách nhiệm đơn nhất, Ingress có nhiều hơn một lý do để thay đổi, nên tốt hơn là tách nó thành các tài nguyên tập trung hơn
    Quảng cáo

  • Không hỗ trợ cross-namespace an toàn

    • Tài nguyên Ingress không thể tham chiếu tới Service hoặc TLS secret bên ngoài namespace của chính nó; trong rules[].backend.service thậm chí còn không có trường chỉ định namespace
    • Một cách lách là tạo Service ExternalName trong cùng namespace để trỏ tới tên DNS nội bộ cluster của Service đích
    • Tuy nhiên, cách này ngay lập tức kéo theo vấn đề thuộc loại confused deputy attack

Gateway API

  • Gateway API là phiên bản thế hệ tiếp theo của Ingress API, khắc phục các hạn chế thông qua những điểm sau
    • Bao quát phạm vi tính năng rộng hơn nhiều cần thiết cho việc quản lý lưu lượng inbound và tăng khả năng biểu đạt
    • Phản ánh các mẫu sở hữu tài nguyên phổ biến, từ đó làm rõ tách biệt mối quan tâm giữa các nhóm
    • Bao gồm cơ chế mở rộng được định nghĩa rõ là policies cùng khả năng tham chiếu đối tượng cross-namespace linh hoạt

GatewayClass

  • Tương tự IngressClass, nó định nghĩa một tập hợp Gateway do một deployment Gateway controller cụ thể sở hữu, về thực chất có cùng ý nghĩa và cấu trúc với IngressClass
  • Có thể tham chiếu tới custom resource chứa cấu hình Gateway bổ sung theo từng implementation
    • Bao gồm cách công khai Gateway proxy, cấu hình mặc định cho bootstrap và runtime, cách rollout và scale deployment, cùng các tùy chọn đặc thù khác của từng controller

Gateway

  • Tài nguyên Gateway đại diện cho một edge gateway được provisioning động, là lớp trừu tượng hạ tầng nhận lưu lượng inbound và định tuyến tới backend service phù hợp

    • Trong thiết kế Ingress, Ingress Controller đảm nhiệm vai trò này, nên có thể xem đó là một instance Gateway được provisioning tĩnh

  • Mỗi Gateway tham chiếu một GatewayClass để chỉ định controller nào sẽ provisioning và quản lý nó; thành phần cấu hình quan trọng nhất là danh sách listener

  • Listener

    • Định nghĩa cách Gateway tiếp nhận lưu lượng đi vào; mỗi listener là một điểm vào riêng biệt được mô tả bằng tổ hợp port·protocol·hostname
    • Có thể cấu hình TLS termination; trong thế giới Ingress, thông tin này nằm bên trong tài nguyên Ingress
    • Đơn vị chi tiết nhất mà Route có thể attach vào Gateway

  • ListenerSet

    • listener phù hợp để tập trung hóa cấu hình điểm vào, nhưng không phù hợp khi cần tới hàng trăm listener
    • Trường hợp điển hình là HTTPS listener có hostname·TLS riêng theo từng dịch vụ thay vì một chứng chỉ TLS wildcard duy nhất; số listener có thể tăng tương ứng với số lượng microservice
    • Khi mô hình hóa bằng một Gateway duy nhất sẽ phát sinh hai vấn đề
      • Gateway chỉ hỗ trợ tối đa 64 listener
      • Nếu nhiều đội cùng quản lý listener·TLS thì Gateway sẽ trở thành nút thắt cổ chai điều phối
    • Để phân tán và hỗ trợ đa tenant, sử dụng tài nguyên ListenerSet

  • Listener và Route được cho phép

    • Sau khi tách biệt khái niệm Gateway và Route, xuất hiện bài toán mới là kiểm soát tenant nào được attach Route vào listener nào
    • listener là hạ tầng dùng chung và có mục đích khác nhau; ví dụ, không phù hợp để gắn HTTPRoute vào listener tls-passthrough-db là kênh passthrough tới cơ sở dữ liệu, và cũng không phù hợp để gắn Route từ namespace ngoài db
    • Vì Route được thêm theo cách tự quản nên cơ chế allowedRoutes được dùng để ngăn cấu hình sai
    • allowedRoutes thiết lập quan hệ tin cậy giữa Gateway·ListenerSet và các Route thuộc namespace·loại route cụ thể

Routes

  • listener nhận lưu lượng nhưng không biết phải xử lý tiếp ra sao; việc này do tài nguyên Route đảm nhiệm, và đây là cốt lõi của tính linh hoạt trong Gateway API

  • Có năm loại tài nguyên Route để xử lý nhiều giao thức khác nhau

    • HTTPRoute: định tuyến lưu lượng HTTP được tăng cường và mở rộng
    • GRPCRoute: định tuyến nhận biết gRPC
    • TLSRoute: định tuyến dựa trên TLS SNI
    • TCPRoute·UDPRoute: chuyển tiếp trực tiếp lưu lượng TCP/UDP của cổng listener tới backend
    Quảng cáo

  • Tất cả tài nguyên Route (gọi chung là xRoutes) đều có cấu trúc envelope tương tự

    • parentRefs là typed object reference tới tài nguyên cha tiếp nhận Route (thường là Gateway, ListenerSet, Service trong service mesh, v.v.); có thể chỉ định listener cụ thể bằng tùy chọn sectionName·port
    • rules chứa quy tắc định tuyến·filter·cấu hình theo từng giao thức; mỗi rule gồm matches, filters tùy chọn và backendRefs tùy chọn; nếu filter xử lý hoàn toàn yêu cầu thì có thể bỏ qua backendRefs
    • Nếu giao thức cho phép, trường hostnames có thể dùng để định tuyến theo host ở cấp Route

  • HTTPRoute

    • Định nghĩa quy tắc định tuyến lưu lượng HTTP(S) ở mức L7

    • Traffic Matching

      • Hỗ trợ định tuyến theo path·host tương tự Ingress, cùng các quy tắc matching dựa trên header·query·method
      • Ví dụ: có thể dùng matching theo header để định tuyến canary release chỉ dành cho client nội bộ tới deployment thử nghiệm
      • Data plane sẽ áp dụng quy tắc cụ thể nhất, nên thứ tự định nghĩa quy tắc không quan trọng

    • URL Rewrites

      • Có thể rewrite một phần URL yêu cầu trước khi tới backend bằng filter

    • Header Modifications

      • Cung cấp filter HeaderModifier để thêm·xóa·sửa header request và response
      • Cung cấp filter CORS chuyên dụng để cấu hình Cross-Origin Resource Sharing; về mặt khái niệm đây là trường hợp đặc biệt của việc sửa response header, nhưng được tách thành loại filter riêng

    • Redirects

      • Có thể trả về phản hồi redirect cho client thay vì chuyển tới backend; hỗ trợ redirect theo path dạng 3xx và redirect từ HTTP sang HTTPS

    • Traffic Control

      • Có thể chia lưu lượng giữa các dịch vụ backend bằng weight, hữu ích cho triển khai blue-green và thử nghiệm A/B
      • traffic mirroring gửi bản sao lưu lượng production tới backend bổ sung và được cấu hình bằng filter RequestMirror; yêu cầu gốc vẫn tiếp tục tới backend mặc định
      • mirroring là thành phần cốt lõi của tap-and-compare testing, dùng để so sánh kết quả giữa phiên bản cũ và mới khi refactor hoặc migration

    • Sticky Sessions

      • Hỗ trợ session persistence; có thể đặt cookie·header làm dấu phiên để định tuyến nhất quán các yêu cầu từ cùng một client tới cùng một backend instance

    • External Authentication

      • Hỗ trợ filter external authentication thử nghiệm dựa trên gRPC hoặc HTTP; Gateway gửi header yêu cầu tới dịch vụ xác thực bên ngoài trước khi chuyển tới backend, còn phần thân yêu cầu chỉ được gửi khi bật rõ ràng
      • Với gRPC, dịch vụ xác thực bên ngoài phải triển khai protobuf API ext_authz của Envoy
      • Với HTTP, nếu xác thực thành công thì trả về 200, còn các trạng thái khác sẽ được xử lý là xác thực thất bại

    • Retries & Timeouts

      • Có thể cấu hình retry cho một route cụ thể; BackendTrafficPolicy cung cấp retry budget toàn cục để ngăn retry storm

  • GRPCRoute

    • Vì gRPC dựa trên HTTP/2 nên cũng có thể xử lý bằng HTTPRoute, nhưng vẫn có lý do để mô hình hóa thành tài nguyên riêng
      • Tách các tùy chọn không có ý nghĩa với gRPC như URL rewrite, để mỗi tài nguyên có thể phát triển độc lập theo đúng giao thức
      • Phản hồi gRPC có thể trả HTTP 200 nhưng vẫn biểu thị lỗi ứng dụng qua header grpc-status·grpc-message, điều này quan trọng cho retry và metric chính xác
      • Trải nghiệm người dùng tốt hơn khi định nghĩa quy tắc bằng các thuật ngữ gRPC ở mức cao
    • path matcher của HTTPRoute được thay bằng method matcher; nội bộ vẫn matching theo path nhưng được biểu diễn dưới dạng service·method
    • Có thể xử lý header request·response nhưng không giải mã payload gRPC, nên không thể định tuyến dựa trên các trường protobuf cụ thể
    • Hỗ trợ một phần các filter của HTTPRoute như traffic mirroring·weighted load balancing và sửa header

  • TCPRoute và UDPRoute

    • Đơn giản chuyển tiếp lưu lượng tới cổng listener sang dịch vụ backend; hiện chưa hỗ trợ matcher·filter
    • Cả hai loại đều hỗ trợ weighted load balancing giữa nhiều backend

  • TLSRoute

    • Định tuyến lưu lượng TLS đã mã hóa tới backend dựa trên SNI được cung cấp trong quá trình TLS handshake
    • Chủ yếu dùng cho TLS passthrough; Gateway kiểm tra SNI để chọn backend rồi chuyển tiếp kết nối đã mã hóa mà không thực hiện TLS termination, backend sẽ đảm nhiệm việc kết thúc TLS
    • Một số implementation như Envoy Gateway hoặc kgateway cũng hỗ trợ TLS termination ở edge, nhưng đây là tính năng mở rộng
    • Route bắt buộc phải khai báo hostname; giá trị này phải khớp với SNI và cần có phần giao với hostname của listener trên Gateway; không hỗ trợ matcher·filter nhưng có hỗ trợ weighted load balancing

  • Route Filter Extensions

    • HTTPRoute và GRPCRoute bao gồm cơ chế mở rộng xử lý request/response và filter tùy biến thông qua filter extensionRef, trỏ tới tài nguyên khác bằng typed object reference
    • Ví dụ: Envoy Gateway cung cấp CRD HTTPRouteFilter để trả phản hồi trực tiếp mà không cần dịch vụ backend

  • Mục tiêu backend

    • Mặc định hỗ trợ Service tiêu chuẩn (phổ biến nhất) và ServiceImport cho môi trường đa cụm làm mục tiêu backend
    • Vì được chỉ định bằng typed object reference, có thể mở rộng bằng custom resource theo từng implementation
    • Ví dụ: Envoy Gateway hỗ trợ tài nguyên Backend tùy biến để trỏ tới upstream bên ngoài như FQDN, IP, UNIX socket
    Quảng cáo

  • ReferenceGrant

    • Gateway API coi tham chiếu cross-namespace là khái niệm hạng nhất trong thiết kế tiêu chuẩn, nhưng có rủi ro bảo mật
    • Ví dụ về confused deputy attack: nếu kẻ tấn công chiếm được một namespace, chúng có thể lợi dụng quyền tạo Ingress, Service, EndpointSlice để làm rò rỉ quyền truy cập vào dịch vụ được bảo vệ
      • Ingress mới trỏ tới Service mới trong namespace đã bị xâm phạm
      • Service đó không có selector nên không khớp với deployment nào, do đó có thể cung cấp EndpointSlice thủ công
      • Kẻ tấn công giả mạo EndpointSlice để chứa IP pod backend được bảo vệ ở namespace khác, tạo lối vào thứ hai tới API được bảo vệ bằng cách căn chỉnh cổng
      • Cũng có thể đạt kết quả tương tự bằng Service kiểu ExternalName
    • Để giảm thiểu điều này, tài nguyên ReferenceGrant được đưa vào, là cơ chế tin cậy hai chiều cho phép một namespace định nghĩa namespace nào được phép tham chiếu tài nguyên của nó
    • Gateway Controller sẽ xét đến ReferenceGrant khi có tham chiếu cross-namespace tới mục tiêu backend hoặc TLS secret, khiến confused deputy attack trở nên khó thực hiện hơn
    • Tuy nhiên, ReferenceGrant chỉ đảm bảo tính hợp lệ của tham chiếu và không can thiệp vào hành vi sau khi lưu lượng được chuyển tiếp; có thể bổ sung bằng NetworkPolicies để chặn truy cập tới cổng API được bảo vệ

Policy

  • Policy attachment là một mẫu mở rộng mạnh mẽ, áp dụng hành vi và hiệu lực theo phân cấp lên một hoặc nhiều thành phần Gateway API mà không sửa đổi tài nguyên gốc
  • Xác thực là ví dụ tiêu biểu
    • Nếu áp dụng xác thực cho toàn bộ Gateway (hoặc ListenerSet), nó sẽ ảnh hưởng theo phân cấp tới mọi Route đang và sẽ được gắn vào, đồng thời vẫn cho phép ngoại lệ ở mức Route như route công khai
    • Việc xác thực có thể do một nhóm không liên quan tới Gateway hay Route kiểm soát, nên được thiết kế để không phải sửa trực tiếp các tài nguyên đó
    • Dù có các tiêu chuẩn như OAuth 2 và OIDC, cấu hình xác thực vẫn phụ thuộc nhiều vào implementation nên khó có một lớp trừu tượng dùng chung cho mọi implementation
  • Ví dụ: dùng tài nguyên SecurityPolicy của Envoy Gateway để cấu hình xác minh token JWT; Policy là cách hiện đại và giàu khả năng biểu đạt để thay thế cấu hình dựa trên annotation thời Ingress
  • Chỉ có hai Policy được cung cấp sẵn
    • BackendTLSPolicy: chỉ thị Gateway kết nối tới backend upstream bằng TLS
    • BackendTrafficPolicy: đặt retry budget cho một backend cụ thể; nếu vượt quá hạn mức retry toàn cục thì trả về 503, hoạt động như circuit breaker để ngăn retry storm

Quyền sở hữu

  • Tài nguyên Gateway API trong cụm thường do hai nhóm sở hữu
    • Platform team định nghĩa GatewayClass, Gateway, ListenerSet cùng cấu hình LoadBalancer và TLS, đồng thời có thể quản lý Policy toàn cục áp dụng cho một phần hoặc toàn bộ Gateway
    • Application/Service team chủ yếu tập trung vào tài nguyên Route của mình và có thể áp dụng Policy ở mức Route khi cần
  • Nhờ tính linh hoạt cao, có thể xây dựng nhiều mô hình sở hữu khác nhau, chẳng hạn platform team tập trung và sở hữu Route trong một namespace

Kiến trúc điển hình

  • Gateway API không giả định quá nhiều về kiến trúc implementation, nhưng cách phổ biến là tách biệt control plane và data plane
  • Gateway Controller đóng vai trò control plane dưới dạng Kubernetes operator, theo dõi tài nguyên Gateway API và CRD để tổng hợp cấu hình data plane mong muốn, đồng thời cần quyền mở rộng để đọc và sửa tài nguyên
  • Data plane của Gateway là proxy xử lý lưu lượng theo cấu hình, thường dùng Envoy Proxy, NGINX, Traefik..., và tùy implementation có thể provision proxy riêng cho từng Gateway hoặc dùng chung
  • Việc tách control/data plane là lựa chọn thiết kế có lợi để tránh những lỗ hổng bảo mật mang tính nền tảng từng được phát hiện trong NGINX Ingress Controller

Di chuyển khỏi Ingress

  • Có bốn lựa chọn để ứng phó với việc NGINX Ingress Controller bị deprecation, nên xem xét theo thứ tự từ ít xâm lấn nhất

  • Không làm gì cả

    • Dù không phải tốt nhất, trong một số trường hợp vẫn có thể chấp nhận; với homelab, động lực thay đổi có thể không nhiều

    • Trong doanh nghiệp, điều này khó được chấp nhận vì các khung quy định, bảo mật và tuân thủ thường kỳ vọng phần mềm đang vận hành phải được duy trì và vá lỗi

      • ISO 27001: kỳ vọng quản lý lỗ hổng, vá lỗi và theo dõi EOL
      • SOC 2 Type II: kỳ vọng quét lỗ hổng, quản lý vá lỗi và SLA khắc phục
      • HIPAA Security Rule: yêu cầu đưa phần mềm cũ hoặc chưa vá vào phân tích rủi ro
      • PCI DSS v4.0.1: yêu cầu nhận diện thành phần không còn được hỗ trợ, lập kế hoạch khắc phục và quy định thời hạn xử lý lỗ hổng nghiêm trọng
      • FedRAMP: kỳ vọng thay thế phần mềm không còn được hỗ trợ bằng lựa chọn còn được duy trì, với thời hạn khắc phục theo mức độ nghiêm trọng

    • Trong hầu hết khung tuân thủ, phần mềm EOL trở thành vấn đề thực tế khi có lỗ hổng mới được công bố

    • Phân tích CVE

      • Tình hình CVE của NGINX Ingress Controller trong 5 năm qua
        • Tổng cộng 20 lỗ hổng
        • Năm 2021 có 4 lỗ hổng mức High liên quan đến rò rỉ secret
        • Năm 2022 có 1 lỗ hổng mức High liên quan đến rò rỉ credential của controller
        • Giai đoạn 2023~2024 có 3 lỗ hổng mức High
        • Năm 2025 có 6 lỗ hổng, bao gồm 1 lỗ hổng Critical (IngressNightmare) và 4 lỗ hổng mức High liên quan đến chèn cấu hình NGINX
        • Năm 2026 có 6 lỗ hổng, bao gồm 3 lỗ hổng mức High liên quan đến chèn cấu hình NGINX
      • Các CVE giai đoạn 2021~2022 chủ yếu xuất phát từ cấu hình NGINX do người dùng cung cấp trong annotation nhưng không được làm sạch, gây chèn cấu hình, lộ thông tin và rò rỉ secret; Kubernetes đã bổ sung validation
      • Các CVE giai đoạn 2023~2024 chủ yếu là các cách vượt qua lớp validation annotation đó
      • IngressNightmare (CVE-2025-1974) khiến tình hình tệ hơn: trước đây cần quyền tạo hoặc sửa tài nguyên Ingress, nhưng chỉ cần có truy cập mạng tới admission controller là đã có thể thực thi mã từ xa trong ngữ cảnh của ingress-nginx controller thông qua lỗi tương tự chèn cấu hình; sau đó có thể làm rò rỉ các Secret mà controller truy cập được
      • Các lỗ hổng trong năm 2026 tiếp tục lặp lại mô hình chèn cấu hình qua annotation, path và comment
      • Những lỗ hổng này liên tục nhắm vào cùng một điểm yếu trong thiết kế
        • Controller quá linh hoạt, phơi bày nhiều tính năng NGINX nên rất khó validation hoàn hảo, khiến lỗi chèn cấu hình tái diễn
        • Controller chạy cả control plane và data plane trong cùng một pod và dùng chung filesystem, làm tăng phạm vi ảnh hưởng khi xảy ra sự cố
        • Controller thường có quyền truy cập Secret trên toàn cụm, nên một lần chèn cấu hình thành công có thể dẫn tới rò rỉ secret trên phạm vi toàn cụm
      • Do các vấn đề mang tính cấu trúc, có thể kỳ vọng sẽ còn thêm CVE trong tương lai; ở lại với controller gốc mà không có kế hoạch di chuyển là một lựa chọn rủi ro
      Quảng cáo

  • Dùng fork của NGINX Controller

    • Con đường đơn giản nhất là chuyển sang một fork còn được duy trì
      • Fork của Chainguard dường như không cung cấp image đã build sẵn, và đây có thể là một phần trong gói thương mại của họ
    • Cách này có thể giảm rủi ro phơi nhiễm trước các CVE mới và giữ hệ thống hoạt động mà không cần thay đổi lớn, nhưng chỉ là giải pháp ngắn hạn
    • Chainguard không có vẻ muốn tiếp tục phát triển controller như một dự án dài hạn, mà cung cấp các bản sửa CVE theo nỗ lực tốt nhất để giúp người dùng có thêm thời gian di chuyển

  • Sử dụng Ingress Controller khác

    • Bản thân tài nguyên Ingress không bị deprecated, nên việc chuyển sang một Ingress Controller khác vẫn được duy trì cũng là lựa chọn hợp lệ, tiêu biểu như HAProxy·Istio·Traefik
    • Cần migration annotation trên toàn hệ thống; độ khó khác nhau tùy theo mức độ phụ thuộc vào các tính năng đặc thù của NGINX
    • Trong tương lai sẽ có thêm nhiều dự án chuyển sang Gateway API và tỷ trọng của Ingress sẽ giảm, nhưng trong thời gian tới tiếp tục dùng Ingress vẫn hoàn toàn ổn

  • Migration sang Gateway API

    • Lựa chọn dài hạn duy nhất là chuyển từ Ingress API sang Gateway API
      • Cài đặt Gateway API CRD và implementation
      • Thiết lập tài nguyên GatewayClass·Gateway·và Policy nếu cần
      • Migration các tài nguyên Ingress hiện có sang Route
    • CLI ingress2gateway do đội ngũ Kubernetes tạo ra cung cấp chuyển đổi tự động theo kiểu best-effort, nhưng custom annotation vẫn cần tự kiểm tra lại sau đó
    • Cần migration chính xác các mục như timeout, giới hạn file upload, giới hạn body size; nếu bỏ sót hoặc ánh xạ sai có thể âm thầm phá vỡ các giả định của ứng dụng
    • Cần lập kế hoạch cẩn thận cho việc chuyển lưu lượng từ LoadBalancer của Ingress Controller sang LoadBalancer của Gateway proxy mới, và không nhất thiết phải làm theo kiểu big-bang
      • Có thể tạm thời giữ Ingress Controller làm điểm vào công khai, chỉ chuyển một phần lưu lượng sang Gateway API data plane để kiểm thử với lưu lượng thật rồi chuyển đổi dần dần

Nên chọn Gateway nào

  • Sau khi quyết định migration, câu hỏi lớn đầu tiên là nên dùng implementation Gateway API nào

  • Định nghĩa trường hợp API Gateway generic trong bài này: một gateway có thể mở rộng cho lưu lượng public North-South, được triển khai trong môi trường do bạn kiểm soát hoàn toàn, cung cấp sẵn các mẫu xác thực phổ biến và rate limiting linh hoạt

  • Ngoài API Gateway còn có LLM Gateway và Agent Gateway, nhưng phần này tập trung vào API Gateway theo nghĩa cổ điển

  • Gateway API Conformance

    • Đội ngũ Kubernetes đã chuẩn bị bộ kiểm thử conformance tiêu chuẩn để xác minh độ chính xác trong xử lý các giao thức cốt lõi của implementation; chủ yếu tập trung vào hành vi chức năng, không bao gồm các khía cạnh phi chức năng như độ tin cậy, hiệu năng, khả năng mở rộng hay độ phức tạp vận hành
    • Nên ưu tiên implementation conformant; nếu trang chính thức không có kết quả thì nên yêu cầu maintainer cung cấp báo cáo conformance

  • Public Benchmarks

    • Ngoài kiểm thử chính thức còn có các benchmark công khai về độ tin cậy và hiệu năng; John Howard, người đóng góp cho Istio và là nhân viên của Solo.io, đã tạo benchmark cho các implementation chính, và Solo.io là công ty mẹ của kgateway
    • Bao gồm các test case hữu ích như route attachment, propagation, scale và hiệu năng xử lý lưu lượng thông thường; do dựa trên kinh nghiệm cá nhân nên có thể thiên về một số trường hợp nhất định, nhưng vẫn hữu ích như một góc nhìn để đánh giá

  • OSS vs Proprietary

    • Hiện nay có nhiều implementation Gateway API OSS mạnh mẽ ở cấp production, nên cần nghiêm túc cân nhắc khi đánh giá; với nhiều tổ chức, OSS là điểm xuất phát mặc định
    • Những tính năng từng biện minh cho việc mua giải pháp thương mại trong quá khứ như OAuth2 hay OIDC nay đã trở thành commodity, và controller OSS cũng cung cấp sẵn
    • Với OSS, có thể tự đánh giá chất lượng trước khi commit, trong khi với giải pháp thương mại bạn phải sớm đặt niềm tin vào vendor

  • Recommendations

    • Nhóm theo data plane

      • Dựa trên Envoy Proxy: Envoy Gateway, Istio, Cilium, kgateway, v.v.
      • Dựa trên NGINX: NGINX Gateway Fabric, Kong
      • Proxy khác: HAProxy Ingress, Traefik

    • Envoy Gateway

      • Controller Gateway API mã nguồn mở dựa trên Envoy Proxy do đội ngũ Envoy Proxy phát triển; ánh xạ các tính năng của Envoy vào Gateway API trực tiếp nhất có thể, nên có ít lớp trừu tượng đặc thù sản phẩm hơn Istio và dễ hiểu hơn
      • Không hỗ trợ Ingress API; có thể mở rộng sang các tính năng LLM, MCP gateway và Inference Pools với Envoy AI Gateway
      • Nhẹ, đơn giản khi triển khai và vận hành, tập trung vào API Gateway (North-South), với các tính năng hỗ trợ gồm
        • các mẫu bảo mật như external authentication, xác minh JWT, authorization dựa trên JWT claim, OIDC, IP allowlisting, xác thực static API key, credential injection, v.v.
        • global rate limit policy linh hoạt với thiết lập ở mức toàn cục và route, shadow mode, cấu hình request cost, v.v.
        • giới hạn connection, bandwidth, kích thước file, định tuyến nhận biết availability zone, multi-cluster cơ bản dựa trên ServiceImport, nén phản hồi Brotli·gzip·zstd, direct response và response override
        Quảng cáo
      • Khả năng mở rộng cũng cao: có thể viết dịch vụ gRPC để sửa cấu hình request, response và xDS; cũng có thể viết plugin bằng Lua hoặc các ngôn ngữ biên dịch sang WASM như Go·Rust
      • Bao gồm tài nguyên Backend tùy chỉnh cho tài nguyên bên ngoài theo FQDN·IP, và trỏ tới UNIX socket cho sidecar
      • Hiện được liệt kê là partially conformant do một số bài test bị skip, nhưng về mặt tính năng gần như đáp ứng hầu hết các mục; cũng tích hợp với các dự án CNCF như KEDA và KNative
      • Nếu chỉ cần một API Gateway giàu tính năng thì đây là lựa chọn tốt

    • Istio

      • Service mesh dựa trên Envoy Proxy và là dự án CNCF Graduated, được liệt kê là conformant trong kiểm thử Gateway API
      • Là một gói bao gồm Ingress Controller, Gateway API controller và service mesh; có thể cung cấp các tính năng LLM, MCP và A2A gateway thông qua tích hợp agentgateway
      • Hỗ trợ multi-cluster nâng cao với Admiral, v.v.; có nhiều profile triển khai, cộng đồng lớn, tài liệu phong phú như sách của O'Reilly; mã hóa pod-to-pod dựa trên mTLS hữu ích trong môi trường chính phủ và FedRAMP
      • Nhược điểm là ở chế độ sidecar tiêu tốn nhiều tài nguyên và có nhiều khái niệm riêng nên đường cong học tập khá dốc
      • ambient mode cung cấp thiết lập nhẹ hơn, nhưng trong các trường hợp L7 nâng cao có thể không đầy đủ tính năng như sidecar; nếu cần chính sách mạnh hơn và kiểm soát L7 sâu hơn thì có thể cân nhắc dùng thêm Envoy Gateway làm ingress gateway và waypoint proxy
      • Tốt nhất khi service mesh là ưu tiên chính và Gateway API chỉ là phần phụ; nếu chỉ cần API gateway thì có thể sẽ thấy hơi thiếu

    • kgateway

      • Gateway mã nguồn mở CNCF Sandbox dựa trên dự án Gloo; hỗ trợ Envoy Proxy và agentgateway (tính năng AI gateway) làm data plane, đồng thời có thể dùng các instance data plane riêng được quản lý từ bên ngoài
      • Conformance Gateway API hoàn hảo, gần như là implementation duy nhất đáp ứng mọi hạng mục
      • Trên Envoy data plane hỗ trợ xác minh JWT, OAuth2/OIDC, external authentication, kiểm soát truy cập IP, Envoy global rate limiting, và phơi bày xử lý request·response dựa trên ext_proc; tuy nhiên có vẻ không phơi bày plugin Lua·WASM hoặc chỉnh sửa trực tiếp raw xDS
      • Với engine transformation mạnh mẽ dựa trên template MiniJinja, có thể định nghĩa khai báo việc biến đổi header, response body và status trong tài nguyên TrafficPolicy
      • Có thể tích hợp với Istio như edge proxy, nhưng bản thân không đóng vai trò service mesh; hỗ trợ Route phân cấp cho phép một Route ủy quyền xử lý lưu lượng cho Route khác, và có CRD AwsLambda tùy chỉnh để gọi trực tiếp AWS Lambda
      • Dù vendor tuyên bố có phạm vi triển khai rộng, vẫn chưa có nhiều phản hồi độc lập, nên từ góc nhìn cộng đồng công khai đây dường như vẫn là một dự án đang trong giai đoạn phát triển

  • Traefik

    • Reverse proxy mã nguồn mở phổ biến được viết bằng Go, hỗ trợ cả Ingress API và Gateway API; đặc biệt được ưa chuộng trong cộng đồng homelab nhờ tài liệu tốt, codebase gọn gàng, cấu hình đơn giản và triển khai dễ dàng

    • Hỗ trợ các tính năng cốt lõi của Gateway API và một số tính năng bổ sung, nhưng vẫn chưa hỗ trợ ListenerSet và traffic mirroring thông qua Gateway API (vẫn có thể mirroring bằng backend TraefikService tùy biến)

    • Mô hình mở rộng dựa trên middleware; dùng bộ lọc ExtensionRef để kết nối Route với Middleware CRD; middleware tích hợp sẵn cung cấp ForwardAuth (ủy quyền xác thực ra bên ngoài, tương tự Envoy ext_authz), IP allowlisting và CORS, giới hạn kết nối, retry, circuit breaker, nén và trang lỗi tùy biến

    • Có thể kết nối plugin tùy biến YAEGI và WASM bằng Plugin middleware (chủ yếu để chỉnh sửa request/response); việc xác minh JWT, OIDC và OAuth2 Client Credentials chỉ được cung cấp dưới dạng plugin trả phí

    • Hỗ trợ rate limiting phân tán cơ bản bằng Middleware CRD (bucket theo IP, host, header), nhưng cấu hình không linh hoạt và được gắn bằng ExtensionRef thay vì policy attachment, nên khó phân tầng kiểu áp dụng toàn cục rồi override ở cấp route

    • Không có sự tách biệt rõ ràng giữa control plane và data plane, nên kiến trúc gần với NGINX Ingress hơn; cùng một pod vừa theo dõi tài nguyên vừa xử lý lưu lượng; không cấp phát động proxy theo từng Gateway mà một deployment duy nhất quản lý mọi Gateway trong namespace được theo dõi, có thể gây điểm lỗi đơn và giảm khả năng cô lập, từ đó phát sinh vấn đề về khả năng phục hồi ở quy mô lớn

    • Nếu chọn dùng, nên load test với mức lưu lượng dự kiến; đặc biệt cần thận trọng hơn vì đã từng nghe nhiều phàn nàn về hiệu năng của Traefik

    • NGINX Gateway Fabric

      • Triển khai Gateway API chính thức của F5 dựa trên NGINX (NGF), có mức độ conformance vững chắc; ở các phiên bản gần đây đã bổ sung Gateway API 1.5 và hỗ trợ CORS cùng chỉnh sửa request/response header thông qua các bộ lọc HTTPRoute tiêu chuẩn
      • Một số tính năng như xác thực JWT và OIDC, session persistence dựa trên cookie, cập nhật upstream không cần reload NGINX vẫn phụ thuộc vào NGINX Plus; đây lại là các yêu cầu thường gặp của API Gateway
      • Với SnippetsPolicy và SnippetsFilter tùy biến, có thể chèn cấu hình NGINX tùy chỉnh ở nhiều cấp độ của config được tạo ra, giúp di chuyển dễ hơn mà không cần viết lại khối lượng lớn cấu hình tùy biến sẵn có từ NGINX Ingress
      • Hỗ trợ rate limiting bằng RateLimitPolicy tùy biến, nhưng đây là local rate limiting, nên trạng thái nằm trong data plane NGINX; khi chạy nhiều bản sao NGF, ngưỡng hiệu dụng sẽ thay đổi theo số lượng instance, khiến việc áp giới hạn nghiêm ngặt theo từng người dùng trở nên khó khăn
      • NGINX tự cung cấp các escape hatch để mở rộng như scripting JavaScript nhẹ và Lua, auth_request để ủy quyền xác thực ra dịch vụ bên ngoài (tương tự Envoy ext_authz và Traefik ForwardAuth), cùng các module C tùy biến; tuy nhiên không hỗ trợ kiểu chỉnh sửa request/response dựa trên dịch vụ bên ngoài theo mô hình ext_proc
      • Trong NGF 2.0, kiến trúc được cải tổ để tách control plane/data plane và hỗ trợ nhiều tài nguyên Gateway; trước đây kiến trúc từng là một mối lo ngại lớn

    • Cilium Service Mesh

      • Nhiều cluster dùng Cilium làm CNI; service mesh sidecar-less dựa trên eBPF này bao gồm cả triển khai Gateway API dựa trên Envoy Proxy, giúp giảm số lượng thành phần và tinh gọn stack công nghệ
      • Tuy vậy, trọng tâm chủ yếu vẫn là conformance của Gateway API, nên nhiều tính năng Envoy hữu ích ngoài Gateway API không được lộ ra dưới dạng cấu hình hạng nhất; ví dụ chưa có hỗ trợ hạng nhất cho extension và plugin của Envoy, IP allowlisting, xác minh JWT, phân quyền dựa trên claim và OIDC
      • Trừ khi bạn chắc chắn các tính năng Gateway API hiện tại của Cilium đã đủ dùng, còn không thì đây không được khuyến nghị là API Gateway đa dụng so với các lựa chọn giàu tính năng hơn như Envoy Gateway, kgateway hay Istio

    • Kong

      • API Gateway phổ biến dựa trên NGINX; Kong Operator hỗ trợ cả Ingress và Gateway API
      • Mối lo ngại chính là chiến lược OSS; có vẻ họ đã ngừng phát hành prebuilt Docker image cho các phiên bản Gateway mã nguồn mở mới, và image OSS dường như đã dừng lại quanh dòng phát hành 3.10, khiến người dùng có thể phải tự build, vá, harden và duy trì
      • Có suy đoán công khai rằng động thái này liên quan đến việc giảm tình trạng khách hàng enterprise rời bỏ, dù không thể xem là sự thật đã được xác nhận, nhưng vẫn khiến định hướng OSS trở nên kém dễ đoán hơn
      • Vì vậy, trừ khi bạn định mua giấy phép enterprise hoặc sẵn sàng tự gánh việc đóng gói và duy trì bản OSS, thì không nên chọn

Summary

  • Theo dõi quá trình tiến hóa của mô hình ingress trong Kubernetes từ giai đoạn đầu đến thời đại Gateway API, đồng thời đi sâu vào chính giao thức Gateway API
  • GAMMA (mở rộng ý tưởng Gateway API sang service mesh) và Inference Extension (định nghĩa và tối ưu hóa workload suy luận trên Kubernetes) được chủ ý loại khỏi phạm vi vì đây là những chủ đề cần thảo luận chuyên sâu riêng
  • Đồng thời xem xét các triển khai Gateway API hiện có và tiêu chí lựa chọn

Bài viết liên quan

2 bình luận

 
click 2 giờ trước

Năm ngoái tôi từng định thử dùng NGF, nhưng vì không có cách nào tạo cơ chế xác thực dựa trên header Authorization nên cuối cùng đã chuyển sang dùng envoy.
Tôi thích nginx hơn envoy, nên nếu sau này Gateway API được hỗ trợ đầy đủ thì có lẽ lần tới tôi sẽ thử dùng NGF.
 
hmmhmmhm 2 giờ trước

Có vẻ Envoy sẽ còn nổi hơn nữa.