Giới thiệu

Trong Kubernetes, một trong những nhiệm vụ quan trọng nhất là quản lý cách thức các dịch vụ bên trong cụm được tiếp xúc với thế giới bên ngoài. Trong thời gian dài, API Ingress đã là tiêu chuẩn để xử lý lưu lượng HTTP(S), hoạt động như cổng để điều hướng các yêu cầu từ khách hàng bên ngoài đến các dịch vụ phù hợp trong cụm. Mặc dù Ingress đã thực hiện tốt nhiệm vụ của nó, nhưng nó cũng có những hạn chế, đặc biệt là về khả năng mở rộng, sự nhất quán giữa các triển khai và hỗ trợ cho các kịch bản quản lý lưu lượng nâng cao.

Để khắc phục những thiếu sót này, Kubernetes đã giới thiệu API Gateway, một lựa chọn thế hệ tiếp theo cho Ingress. Khác với Ingress, thường chỉ tập trung vào việc định tuyến đơn giản, API Gateway cung cấp một mô hình phong phú hơn, dựa trên vai trò. Nó được thiết kế để biểu đạt tốt hơn, linh hoạt hơn và trung lập về nhà cung cấp, giúp dễ dàng định nghĩa các hành vi mạng phức tạp trong khi vẫn duy trì trải nghiệm người dùng nhất quán trên các môi trường khác nhau.

Nếu tổ chức của bạn hiện đang dựa vào Ingress và đang xem xét việc chuyển đổi sang API Gateway, hướng dẫn này sẽ hướng dẫn bạn qua quy trình. Chúng ta sẽ khám phá lý do tại sao API Gateway đáng để áp dụng, những thay đổi mà bạn cần lưu ý và các bước thực tiễn để chuyển đổi từ cài đặt Ingress hiện tại sang API Gateway hiện đại trong một cụm Kubernetes đang hoạt động.

Thách Thức Khi Chuyển Đổi Sang Gateway API 🔥

Mặc dù API Gateway mang lại những cải tiến mạnh mẽ so với Ingress, việc chuyển đổi sang nó không phải lúc nào cũng đơn giản. Các tổ chức nên chuẩn bị cho những thách thức sau:

• Hỗ Trợ Bộ Điều Khiển: Không phải tất cả các bộ điều khiển Ingress đều có sự tương thích đầy đủ với API Gateway. Điều này có thể hạn chế các tính năng hoặc yêu cầu lựa chọn một bộ điều khiển mới hỗ trợ natively cho Gateway.
• Đường Cong Học Tập: Gateway giới thiệu các tài nguyên mới (Gateways, Routes, Policies) và một thiết kế dựa trên vai trò. Các nhóm cần thời gian và đào tạo để điều chỉnh quy trình làm việc của họ.
• Khoảng Trống Tính Năng: Mặc dù API Gateway biểu đạt tốt hơn, một số trường hợp sử dụng nâng cao có thể vẫn phụ thuộc vào các mở rộng cụ thể của nhà cung cấp, giảm khả năng di động.
• Chi Phí Vận Hành: Trong quá trình chuyển đổi, bạn có thể cần chạy cả Ingress và Gateway song song, điều này làm tăng độ phức tạp trong cấu hình và tiêu thụ tài nguyên.

Các Thực Hành Tốt Nhất Khi Chuyển Đổi Sang Gateway API 🌟

• Bắt Đầu Nhỏ: Bắt đầu với các dịch vụ không quan trọng để kiểm tra quy trình chuyển đổi. Điều này cho phép đội ngũ của bạn xây dựng sự tự tin, tinh chỉnh quy trình và phát hiện các thách thức trước khi chuyển đổi các ứng dụng quan trọng.
• Tận Dụng Sự Phân Tách Vai Trò: Một trong những điểm mạnh của API Gateway là thiết kế dựa trên vai trò của nó. Rõ ràng định nghĩa quyền sở hữu: các đội hạ tầng có thể quản lý Gateways, trong khi các nhà phát triển ứng dụng tập trung vào Routes. Sự phân tách này cải thiện bảo mật, khả năng mở rộng và hiệu suất của đội.
• Áp Dụng Thực Hành GitOps: Lưu trữ cấu hình Gateway và Route trong các hệ thống kiểm soát phiên bản như Git. Điều này cho phép hợp tác, kiểm tra và nhanh chóng hoàn tác nếu có vấn đề xảy ra trong quá trình chuyển đổi.
• Giám Sát và Quan Sát: Sử dụng các công cụ ghi chép, theo dõi và giám sát để xác thực hành vi định tuyến, đảm bảo hiệu suất và phát hiện bất thường sớm.
• Cập Nhật Thông Tin: API Gateway tiếp tục phát triển, với các tính năng như mTLS, định tuyến gRPC và phân chia lưu lượng đang được chuẩn hóa. Giữ thông tin cập nhật giúp tổ chức của bạn tận dụng các khả năng mới khi chúng trở nên ổn định.

Chiến Lược Chuyển Đổi: Từ Ingress Sang Gateway API 🎯

Chuyển đổi từ Ingress sang API Gateway yêu cầu lập kế hoạch, kiểm tra và áp dụng theo từng giai đoạn. Dưới đây là các bước được khuyến nghị.

Nghiên Cứu & Lập Kế Hoạch:

• Kiểm tra cấu hình hiện tại: Thu thập thông tin về các đối tượng Ingress hiện có, các bộ điều khiển, hosts, paths, cấu hình TLS, chú thích và các dịch vụ backend. kubectl get ingress -A -o yaml > all-ingresses.yaml
• Chọn một bộ điều khiển Gateway tương thích: API Gateway chỉ là một thông số kỹ thuật. Bạn sẽ cần một triển khai. Các ví dụ bao gồm:
  1. NGINX ➡︎ NGINX Gateway Fabric
  2. Traefik ➡︎ Traefik Proxy với API Gateway
  3. HAProxy ➡︎ Bộ Điều Khiển Ingress của HAProxy với API Gateway
  4. Istio ➡︎ API Gateway của Istio

Bản Đồ Ingress Sang API Gateway

1. IngressClass ➡︎ GatewayClass
2. Ingress ➡︎ Gateway + HTTPRoute
3. Xem lại các thay đổi RBAC, vì API Gateway giới thiệu kiểm soát truy cập chi tiết hơn.

Chứng Minh Khái Niệm

• Triển khai tài nguyên API Gateway trong một không gian tên không phải sản xuất.
• Xác thực định tuyến, TLS và kết nối dịch vụ trước khi triển khai thêm.

Chạy Cả Hai Tài Nguyên Song Song

• Giữ Ingress cho lưu lượng sản xuất.
• Triển khai tài nguyên Gateway + HTTPRoute tương đương song song.
• Sử dụng các tên miền staging (ví dụ: myapp.example.com) để xác thực hành vi.

Chuyển Đổi TLS

• Khác với Ingress (thường sử dụng chú thích), API Gateway coi TLS là một tài nguyên chính.
• Tạo bí mật TLS và tham chiếu chúng trong các listener của Gateway.

Xử Lý Chú Thích Cụ Thể Của Nhà Cung Cấp

Ingress thường dựa vào các chú thích như nginx.ingress.kubernetes.io/rewrite-target. Trong API Gateway, những điều này được thay thế bằng các trường gốc:

• Khớp tiêu đề ➡︎ matches.headers
• Chuyển hướng đường dẫn ➡︎ filters.requestRedirect, filters.urlRewrite
• Phân chia lưu lượng ➡︎ backendRefs.weight Ví dụ:

rules:
- backendRefs:
  - name: v1-service
    port: 80
    weight: 80
  - name: v2-service
    port: 80
    weight: 20

Chuyển Lưu Lượng Sản Xuất

• Cập nhật DNS để trỏ đến bộ cân bằng tải Gateway.
• Giám sát lưu lượng bằng cách sử dụng các nhật ký và số liệu.
• Quay lại Ingress nếu cần (vì nó vẫn chạy song song).

Ngừng Sử Dụng Ingress

• Xóa các đối tượng Ingress cũ.
• Gỡ cài đặt bộ điều khiển Ingress.
• Giữ lại các tài nguyên API Gateway như nguồn thông tin duy nhất cho mạng dịch vụ.

Chuyển Đổi Tài Nguyên Ingress Hiện Tại Sang API Gateway

Điều Kiện Tiên Quyết ⚙️

Một cụm Kubernetes đang chạy (1.24+) có các triển khai, dịch vụ, pod đang chạy với tài nguyên ingress.

Bước 1: Cài Đặt Tài Nguyên API Gateway

# Cài đặt tài nguyên API Gateway
kubectl kustomize "https://github.com/nginx/nginx-gateway-fabric/config/crd/gateway-api/standard?ref=v1.5.1" | kubectl apply -f -

# Xác minh cài đặt
kubectl get crd | grep gateway

Bước 2: Cấu Hình NGINX Gateway Fabric

Chúng ta sẽ cài đặt NGINX Gateway Fabric làm bộ điều khiển API Gateway:

# Triển khai các CRD của NGINX Gateway Fabric
kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.6.1/deploy/crds.yaml

# Triển khai NGINX Gateway Fabric với NGINX OSS sử dụng loại Dịch vụ NodePort
kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v1.6.1/deploy/nodeport/deploy.yaml

# Xác minh việc triển khai
kubectl get pods -n nginx-gateway

Bước 3: Tạo Tài Nguyên GatewayClass và Gateway

Chúng ta hãy tạo GatewayClass và Gateway. Lưu YAML sau vào một tệp có tên gateway-resources.yaml:

---
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: nginx
spec:
  controllerName: gateway.nginx.org/nginx-gateway-controller

---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: nginx-gateway
  namespace: nginx-gateway
spec:
  gatewayClassName: nginx # Sử dụng lớp gateway tương ứng với bộ điều khiển của bạn
  listeners:
  - name: https
    port: 443
    protocol: HTTPS
    hostname: myweb.k8s.local
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: web-tls-secret
        namespace: web-app
    allowedRoutes:
      namespaces:
        from: All
  - name: http
    port: 80
    protocol: HTTP
    hostname: myweb.k8s.local
    allowedRoutes:
      namespaces:
        from: All

Lưu ý: ở đây, trong mã trên chúng tôi đã sử dụng “web-tls-secret”. Điều này đã được sử dụng bởi tài nguyên Ingress.

# Áp dụng YAML:
kubectl apply -f gateway-resources.yaml
# Xác minh tài nguyên Gateway
kubectl get gateway -n nginx-gateway

Bước 4: Tạo Tài Nguyên HTTPRoute

Tạo tệp YAML cho HTTPRoute cho http với tên http.yaml.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web-route
  namespace: web-app
spec:
  parentRefs:
  - name: nginx-gateway
    kind: Gateway
    namespace: nginx-gateway
    sectionName: http
  hostnames:
  - myweb.k8s.local
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: web-service
      port: 80

Tạo tệp YAML cho HTTPRoute cho https với tên https.yaml.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web-route-https
  namespace: web-app
spec:
  parentRefs:
  - name: nginx-gateway
    kind: Gateway
    namespace: nginx-gateway
    sectionName: https
  hostnames:
  - myweb.k8s.local
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: web-service
      port: 80

Lưu ý: Ở đây, chúng tôi đã chọn namespace=web-app trong phần metadata của tài nguyên, điều này giống với namespace của tài nguyên Deployment.

# Áp dụng tài nguyên YAML:
kubectl apply -f http.yaml
kubectl apply -f https.yaml

# Xác minh tài nguyên HTTPRoute
kubectl get httproute -n web-app

Bước 5: Xác Minh Cấu Hình API Gateway

# Kiểm tra trạng thái Gateway
kubectl describe gateway nginx-gateway -n web-app

# Kiểm tra trạng thái HTTPRoute
kubectl describe httproute web-route -n web-app

# Kiểm tra xem HTTPRoute có được liên kết đúng cách với Gateway không
kubectl get httproute web-route -n web-app -o jsonpath='{.status.parents[0].conditions[?(@.type=="Accepted")].status}'
kubectl get httproute web-route-https -n web-app -o jsonpath='{.status.parents[0].conditions[?(@.type=="Accepted")].status}'

Đầu ra cho lệnh cuối cùng nên là "True" nếu HTTPRoute được chấp nhận đúng cách bởi Gateway.
Lưu ý: Nếu bạn gặp lỗi với listener, hãy chắc chắn rằng bí mật đã được tạo trong cùng một namespace với gateway, nếu không, hãy tạo grant tham chiếu dưới đây.

cat <<EOF | kubectl apply -f -
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-gateway-to-web-app-secrets
  namespace: web-app 
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: Gateway
    namespace: nginx-gateway 
  to:
  - group: "" 
    kind: Secret
    name: web-tls-secret
EOF

Bước 6: Kiểm Tra Cấu Hình API Gateway

Bây giờ, chúng ta sẽ kiểm tra xem ứng dụng có thể truy cập thông qua API Gateway mới hay không.

# Kiểm tra điểm / 
curl -v -H "Host: myweb.k8s.local" http://$NODE_IP:30080/

# Thêm mục vào /etc/hosts
# ${NODE_IP}   myweb.k8s.local

# Kiểm tra điểm / 
curl -v -k https://myweb.k8s.local:30081/

Bước 7: Sau Khi Xác Minh Thành Công, Xóa Tài Nguyên Ingress Cũ

kubectl get ingress -A
kubectl delete ingress <ingress-name> -n web-app

Những Suy Nghĩ Cuối Cùng 📝

Chuyển đổi từ Ingress sang API Gateway không chỉ là một sự thay thế công cụ. Nó còn là một cách để bảo vệ nền tảng Kubernetes của bạn trong tương lai. Với các vai trò rõ ràng hơn, các tính năng phong phú hơn và ít bị khóa vào nhà cung cấp hơn, API Gateway giúp các đội hợp tác tốt hơn trong khi xử lý mạng phức tạp một cách dễ dàng. Hãy bắt đầu từ những bước nhỏ, thử nghiệm và mở rộng dần. Mỗi bước tiến gần hơn đến một nền tảng đáng tin cậy, linh hoạt và hiện đại cho các ứng dụng của bạn và các đội ngũ xây dựng chúng.