Ingress: The Production Gateway

Ở bài trước, chúng ta đã biết LoadBalancer Service là cách "giàu có" để expose ứng dụng: Mỗi Service bạn bỏ ra $10-$20/tháng cho một Public IP riêng. Nếu hệ thống của bạn có 100 Microservices? $2000/tháng chỉ để... mở cổng. 💸

Chào mừng đến với giải pháp của người trưởng thành: Ingress.

1. The Concept: Routing vs Exposure

Hãy tưởng tượng tòa nhà văn phòng HPN:

• LoadBalancer Service: Giống như việc mỗi nhân viên (Service) đều có một cửa ra vào riêng thông thẳng ra mặt đường. Tốn kém, khó quản lý bảo vệ.
• Ingress: Là Cửa Quay (Revolving Door) chính ở sảnh. Tất cả khách đều đi qua đây. Lễ tân (Ingress) sẽ hỏi: "Bạn gặp ai?" và chỉ đường dựa trên câu trả lời.

L4 vs L7

• Service (LoadBalancer/NodePort) hoạt động ở Layer 4 (Transport): Chỉ quan tâm IP và Port.
• Ingress hoạt động ở Layer 7 (Application): Nó hiểu HTTP. Nó đọc được:
  • Host: api.hpn.com hay web.hpn.com?
  • Path: /api/v1 hay /dashboard?

2. Architecture: "The Rules & The Police"

Đây là sai lầm phổ biến nhất của người mới (Newbie Mistake):

"Tôi đã tạo file ingress.yaml nhưng không có gì hoạt động cả!"

Trong Kubernetes, Ingress gồm 2 phần tách biệt:

1. Ingress Resource (The Rules): File YAML bạn viết, định nghĩa "Ai được vào đâu". Nó chỉ là tờ giấy quy định.
2. Ingress Controller (The Police): Một phần mềm (thường là Nginx, Traefik, HAProxy) chạy trong Cluster. Nó đọc tờ giấy quy định và thực thi việc điều phối giao thông.

⚠️ KHÔNG CÓ CONTROLLER = KHÔNG CHẠY

Kubernetes KHÔNG đi kèm Ingress Controller mặc định. Bạn phải tự cài đặt nó (thường dùng ingress-nginx).

3. HPN Standard Pattern

Tại HPN, chúng ta sử dụng mô hình "Cloud LB + Ingress Controller" để đạt hiệu quả tối đa về chi phí và hiệu năng.

Luồng đi của Request:

1. User kết nối tới Cloud LoadBalancer duy nhất (Public IP).
2. LoadBalancer chuyển traffic vào Ingress Controller (bên trong K8s).
3. Ingress Controller đọc HTTP Header, định tuyến tới Service A hoặc Service B.
4. Service chuyển tiếp tới Pod.

👉 Lợi ích: Bạn chỉ trả tiền cho 1 LoadBalancer, nhưng có thể expose hàng nghìn Services.

4. SSL/TLS Termination (Offloading)

Mã hóa HTTPS rất tốn CPU (Handshake, Exchange Keys). Tại Ingress, chúng ta áp dụng chiến thuật SSL Termination:

• Chặng 1 (User -> Ingress): Bảo mật tuyệt đối bằng HTTPS. Ingress sẽ giải mã gói tin tại đây.
• Chặng 2 (Ingress -> Pod): Giao tiếp bằng HTTP thường (trong mạng nội bộ Cluster an toàn).

Điều này giúp Pod "nhẹ gánh", tập trung CPU để xử lý Business Logic thay vì ngồi giải mã SSL.

5. Example Configuration

Dưới đây là file ingress.yaml chuẩn để định tuyến cho 2 domain frontend và api:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hpn-gateway
  annotations:
    # Báo cho K8s biết: "Nginx, hãy xử lý cái này!"
    kubernetes.io/ingress.class: nginx
    # Giới hạn kích thước Body (quan trọng cho API upload)
    nginx.ingress.kubernetes.io/proxy-body-size: "10m"
spec:
  rules:
  # Rule 1: Traffic cho web
  - host: app.penalgo.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80
  
  # Rule 2: Traffic cho API
  - host: api.penalgo.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: backend-service
            port:
              number: 8080

---

👉 Next: ⚔️ Challenge: The Silent Backend