Skip to content

Chương 21: GKE Ingress & Gateway API — Expose Ứng Dụng Ra Bên Ngoài

Tại sao chương này quan trọng

Mọi ứng dụng chạy trên GKE cuối cùng đều cần được tiếp cận từ bên ngoài — dù là từ internet, từ các dịch vụ nội bộ trong cùng VPC, hay từ các cluster khác. GKE cung cấp nhiều cơ chế để làm điều này, và việc chọn sai cơ chế hoặc cấu hình sai không chỉ gây lỗi kết nối mà còn dẫn đến các vấn đề nghiêm trọng hơn: lỗ hổng bảo mật khi TLS được cấu hình sai, downtime khi health check không phản ánh trạng thái thực của Pod, hay 502 errors khi backend service không hiểu mô hình routing.

Điểm then chốt cần hiểu là: GKE Ingress và Gateway API không chỉ là hai cách viết YAML khác nhau — chúng tạo ra các kiến trúc GCP infrastructure khác nhau về cơ bản, với các constraint, failure mode, và trade-off hoàn toàn khác nhau. Hiểu rõ cơ chế bên trong của từng loại là điều kiện tiên quyết để thiết kế hệ thống expose đúng cách ở production.

Bản đồ chương

FileChủ đềTrọng tâm kiến thức
01. Tổng quan GKE Load BalancingGateway vs Ingress vs LoadBalancer ServiceBa cơ chế expose, khi nào dùng cái gì, mental model chọn đúng
02. GKE Ingress Controller InternalsCơ chế reconciliation, External vs Internal ALB, packet pathController hoạt động thế nào, tại sao Ingress đang ở maintenance mode
03. BackendConfig & FrontendConfig CRDsHealth check tuning, Cloud Armor, session affinity, CDN, SSL policyCách các CRD này bind vào Ingress/Service và reconcile với GCP
04. Gateway API ArchitectureGatewayClass, Gateway, HTTPRoute, TLS, traffic splittingRole-separated design, controller model, tại sao Gateway thay thế Ingress
05. Container-native LB & NEG InternalsNEG với Pod IPs, Pod-level health, standalone NEGsTại sao NEG loại bỏ node hop, NEG controller lifecycle
06. Multi-cluster Ingress & Multi-cluster GatewayCross-cluster routing, config cluster, global LBMulti-cluster Ingress vs Multi-cluster Gateway: kiến trúc và constraints

Điều kiện tiên quyết

Chương này giả định bạn đã nắm vững:

  • Chương 7: GKE Networking Internals — VPC-native, CNI, packet path
  • Chương 20: Cloud Load Balancing — Application LB architecture, NEG concepts, GFE
  • Kubernetes Services: ClusterIP, NodePort, LoadBalancer type

Mental model nền tảng

Trước khi đi vào chi tiết từng cơ chế, cần thiết lập một mental model nền:

GKE không tự build load balancer. Khi bạn tạo một Ingress hay Gateway resource, GKE controller đọc spec đó và provision các GCP resources tương ứng — Forwarding Rule, Target Proxy, URL Map, Backend Service, NEG. GKE là control plane; GCP Load Balancing là data plane.

Điều này có nghĩa: mọi thứ bạn viết trong Ingress/Gateway spec cuối cùng phải ánh xạ được sang một GCP LB construct. Nếu một tính năng không tồn tại trong GCP LB, nó không thể được thực hiện qua Ingress/Gateway dù bạn viết YAML thế nào.

Lộ trình học

Với engineers mới tiếp cận topic này:

  1. Đọc 01 để xây dựng mental model chung về ba cơ chế
  2. Đọc 05 để hiểu container-native LB và NEG — đây là nền tảng cho cả Ingress và Gateway
  3. Đọc 0203 để hiểu Ingress legacy nếu cần maintain hệ thống cũ
  4. Đọc 04 để hiểu Gateway API cho các hệ thống mới
  5. Đọc 06 khi cần thiết kế multi-cluster architecture

References