● 前言

在前面幾天，我們已經透過 Minikube 了解 Pod 與 Deployment 的運作，也知道如何透過 Service 將 Pod 對外暴露。
不過在實際上線環境中，除了 Deployment 與 Service，還需要一個統一的流量入口 —— Ingress。
今天就來梳理 Kubernetes 中這三個核心元件，如何串接成完整的服務存取流程。

● 服務存取流程

● Service(L4) vs Ingress(L7)

● 核心元件

1. Deployment

• 概念：用來定義與管理 Pod 的「期望狀態」（desired state），包含要跑幾個副本、使用什麼映像檔、如何更新
• 特色：支援滾動更新、回滾機制，確保應用版本控制更穩定

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
  labels: { app: demo-app }
spec:
  replicas: 2                         # 至少 2 副本方便滾動更新
  strategy:
    rollingUpdate: { maxSurge: 1, maxUnavailable: 0 }
  selector:
    matchLabels: { app: demo-app }    # 必須與 template.labels 完全一致
  template:
    metadata:
      labels: { app: demo-app }
    spec:
      containers:
        - name: app
          image: ghcr.io/your/repo:1.0.0
          ports: [{ containerPort: 8000 }]
          readinessProbe:             # 就緒探針避免未就緒就收流量
            httpGet: { path: /healthz, port: 8000 }
            initialDelaySeconds: 5
            periodSeconds: 5
          livenessProbe:              # 存活探針避免僵死
            httpGet: { path: /healthz, port: 8000 }
            initialDelaySeconds: 10
            periodSeconds: 10

2. Service

• 概念：用來將一組 Pod 暴露成為穩定的網路服務。
  即使 Pod 被刪除或重建，Service 都能透過 Label Selector 對應到正確的 Pod。
• 三種類型：
  1. ClusterIP（預設）：僅能在 cluster 內部存取
  2. NodePort：將服務開放到 Node 的指定 Port
  3. LoadBalancer：在雲端環境可直接配置雲端 LB，對外提供存取

# ClusterIP：預設，僅叢集內部可存取
apiVersion: v1
kind: Service
metadata:
  name: demo-svc
  labels: { app: demo-app }
spec:
  type: ClusterIP
  selector: { app: demo-app }
  ports:
    - port: 80            # 對外給 Service 的埠
      targetPort: 8000    # Pod 內部埠

---
# NodePort：本機/內網測試好用（固定節點埠）
apiVersion: v1
kind: Service
metadata:
  name: demo-svc-nodeport
spec:
  type: NodePort
  selector: { app: demo-app }
  ports:
    - port: 80
      targetPort: 8000
      nodePort: 30080     # 可指定 30000–32767

---
# LoadBalancer：雲端直接配公網 IP（L4 LB）
apiVersion: v1
kind: Service
metadata:
  name: demo-svc-lb
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local  # 需要保留來源 IP 時使用
  selector: { app: demo-app }
  ports:
    - port: 80
      targetPort: 8000

3. Ingress

• 概念：負責將外部的 HTTP/HTTPS 請求導向到正確的 Service，可做路由規則、TLS 憑證、多網域/多路徑管理
• 優點：比 NodePort 或 LoadBalancer 更彈性，支援同一個 IP/Domain 底下多個服務

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: edge
spec:
  ingressClassName: nginx
  tls:
    - hosts: ["example.com"]
      secretName: tls-cert           # 事先建立的 TLS Secret
  rules:
    - host: example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: demo-svc       # 與 Ingress 同命名空間的 Service
                port: { number: 80 }
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-svc        # 另一個前端服務（示例）
                port: { number: 80 }

● 注意事項

🔸 Deployment：記得設置 readinessProbe，確保滾動更新不會導致服務中斷
🔸 Service：若是跨 Namespace，需要確認 DNS 規則
🔸 Ingress：

• 需搭配 Ingress Controller（如 Nginx Ingress Controller、Traefik）
• 測試時 Minikube 需啟用：minikube addons enable ingress

● 總結

🔸 Deployment → 控制 Pod 的生命週期與版本管理
🔸 Service → 提供穩定的內外部存取入口
🔸 Ingress → 統一對外流量，支援更複雜的路由與憑證設定

三者的關係可以簡化成：
👉 外部使用者 → Ingress → Service → Pod（由 Deployment 管理）

👉 下一篇

Day 14｜ConfigMap × Secret：Kubernetes 設定與敏感資訊管理