今日目標

• 理解為什麼在微服務架構下，Service（NodePort / LoadBalancer）不足以應對複雜路由需求。
• 搞懂 Ingress（規則定義） 與 Ingress Controller（實體代理執行者） 的核心差異。
• 掌握七層（HTTP / HTTPS）網路路由機制：Path-based Routing 與 Name-based Routing。
• 實戰操作：在 Minikube 啟用 Ingress，並根據 URL 路徑將流量分流到不同 Service。

為什麼需要 Ingress？

在 Day 11 中，我們提到如果系統有數十個微服務：

• 用 NodePort 會造成 Port 號混亂（例如電商服務在 :30080、會員服務在 :30090）。
• 用 LoadBalancer 則需要為每個 Service 租用昂貴的雲端負載平衡器。

Ingress 就是 Kubernetes 世界裡的「七層反向代理總管」（類似於 Nginx、HAProxy 或 Traefik）。

它允許你只使用單一的外部 IP（標準 Port 80 / 443），就能依據請求的**「網域名稱（Domain）」或「網址路徑（Path）」**，精準把流量轉發到集群內部不同的 Service！

核心觀念：Ingress vs. Ingress Controller

很多新手最容易混淆這兩個名詞：

1. Ingress（規則清單）：

   • 它是 Kubernetes 的一種資源物件（透過 YAML 撰寫）。
   • 它只是一張規則說明書，上面寫著「如果網址是 /api，請轉給 api-service」。
   • Ingress 物件本身不會處理任何網路流量。

2. Ingress Controller（實體反向代理伺服器）：

   • 它是真正跑在集群中的應用程式（最常見的是 Ingress-NGINX）。
   • 它會持續監控 API Server 中的 Ingress 規則變化，並自動把這些規則轉換成 Nginx 的反向代理設定，負責真正接收外部流量並轉發。

比喻：Ingress 是「菜單上的點菜清單」，Ingress Controller 則是「真正炒菜送餐的廚師」。

實戰演練：在本地建置 Ingress 路由

步驟 1：在 Minikube 啟用 Ingress Controller

Minikube 內建了 Ingress-NGINX 插件，只需一行指令即可啟用：

minikube addons enable ingress

確認 Ingress Controller Pod 已經正常啟動（可能需要 30 秒至 1 分鐘）：

kubectl get pods -n ingress-nginx

步驟 2：準備兩組測試後端應用（App A 與 App B）

為了驗證路由分流，我們快速建立兩個帶有不同內容的 Pod 與 Service：

建立 apps.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-a
spec:
  replicas: 1
  selector:
    matchLabels:
      app: app-a
  template:
    metadata:
      labels:
        app: app-a
    spec:
      containers:
        - name: web
          image: hashicorp/http-echo
          args: ["-text=Hello from App A!"]
          ports:
            - containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: service-a
spec:
  selector:
    app: app-a
  ports:
    - port: 80
      targetPort: 5678
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-b
spec:
  replicas: 1
  selector:
    matchLabels:
      app: app-b
  template:
    metadata:
      labels:
        app: app-b
    spec:
      containers:
        - name: web
          image: hashicorp/http-echo
          args: ["-text=Hello from App B!"]
          ports:
            - containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: service-b
spec:
  selector:
    app: app-b
  ports:
    - port: 80
      targetPort: 5678

套用配置：

kubectl apply -f apps.yaml

步驟 3：撰寫 Ingress 路由規則

建立 my-ingress.yaml，設定路徑分流：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
    - http:
        paths:
          - path: /apple
            pathType: Prefix
            backend:
              service:
                name: service-a
                port:
                  number: 80
          - path: /banana
            pathType: Prefix
            backend:
              service:
                name: service-b
                port:
                  number: 80

套用 Ingress 規則：

kubectl apply -f my-ingress.yaml

步驟 4：測試路徑分流

取得 Minikube 的 IP 位址：

minikube ip

(假設取得的 IP 是 192.168.49.2)

使用 curl 測試不同路徑：

# 測試連線 /apple
curl http://$(minikube ip)/apple
# 預期輸出: Hello from App A!

# 測試連線 /banana
curl http://$(minikube ip)/banana
# 預期輸出: Hello from App B!

我們只透過同一個 IP 與 Port 80，就能根據不同的路徑存取到完全獨立的後端服務！

本日小結

今天我們搞懂了七層流量總管 Ingress 的強大威力：

• Ingress 定義路由清單，Ingress Controller 負責實體反向代理與轉發。
• 透過單一入口 IP，大幅降低了雲端負載平衡器的租用成本，也讓網址結構更優雅乾淨。

到目前為止，我們的應用程式都是「寫死在容器裡」的靜態設定。如果微服務需要切換測試/生產環境的資料庫連線字串，或是讀取環境變數，該如何優雅處理？

明天 Day 13，我們將學習設定解耦的關鍵物件：「設定分離實務：ConfigMap 將環境變數與程式碼解耦」！