今日目標

• 理解在企業多團隊或多專案情境下，多租戶隔離（Multi-Tenancy）的核心需求。
• 掌握 Kubernetes Namespace 的作用邊界與命名空間隔離機制。
• 搞懂如何透過 ResourceQuota 限制團隊的總算力額度（CPU、Memory、Pod 數量）。
• 掌握 LimitRange 為個別 Pod 設定預設資源配置。
• 實戰操作：建立一個受資源配額保護的開發環境 Namespace，並實測超額被拒絕的場景。

痛點場景：沒有隔離的集群會發生什麼事？

在前面 18 天的實作中，如果我們沒有特別指定，所有的資源（Pod、Deployment、Service、PVC 等）都會被丟進預設的 default 命名空間。

當公司內部有多個團隊共用同一個 Kubernetes 集群時，這會引發嚴重的維運災難：

1. 命名衝突（Name Collisions）：A 專案的資料庫 Service 想叫 db-service，B 專案的資料庫也想叫 db-service，在同一空間內會直接覆蓋衝突。
2. 算力被吃光（Resource Starvation）：某個團隊的程式碼寫出無窮迴圈或 Memory Leak，把整個集群節點的 CPU 和記憶體全部耗盡，導致其他團隊的關鍵業務 Pod 一起被連帶重啟或無法排程。
3. 權限混亂：無法對不同部門實施精準的權限管理（例如：實習生只能操作測試區，不能碰到生產區）。

為了解決這些問題，Kubernetes 提供了 Namespace 與 ResourceQuota 機制。

核心概念一：什麼是 Namespace（命名空間）？

Namespace 是 Kubernetes 在同一個實體集群內部劃分出的**「虛擬工作區（Virtual Cluster）」**：

• 它是邏輯上的隔離，不是實體的硬體隔離。
• 在不同 Namespace 內，物件名稱可以重複（例如 dev 和 prod 空間可以同時存在名為 web-app 的 Deployment）。
• 無法被 Namespace 隔離的資源：像是 Node、PersistentVolume (PV)、StorageClass、ClusterRole 等屬於整個集群級別（Cluster-wide）的資源。

系統預設的 Namespace

• default：預設的工作空間。
• kube-system：Kubernetes 核心系統元件（如 API Server、CoreDNS 等）運行的空間。
• kube-public：所有使用者均可讀取的公共空間。
• kube-node-lease：用於節點心跳檢測（Heartbeat）的租約空間。

核心概念二：ResourceQuota（配額限制）

劃分了 Namespace 之後，我們需要給這個虛擬空間設定**「算力上限」**，這就是 ResourceQuota：

• 運算資源限制：限制該 Namespace 最多能消耗的 CPU 總核心數與記憶體總量（如：最多 4 顆 CPU、8Gi RAM）。
• 儲存資源限制：限制 PVC 的申請總量（如：最多 50Gi 儲存空間）。
• 物件數量限制：限制最多能建立幾個 Pod、Service、Secret 或 ConfigMap。

實戰演練：建立隔離環境與實測配額防禦

步驟 1：建立開發環境 Namespace

建立 dev-namespace.yaml：

apiVersion: v1
kind: Namespace
metadata:
  name: development

套用配置：

kubectl apply -f dev-namespace.yaml

也可以直接使用快速指令建立：kubectl create namespace development。

步驟 2：為 development 命名空間套用 ResourceQuota

我們設定這個環境：

• 最多只能跑 2 個 Pod。
• CPU 請求上限為 1 顆核心（1000m），記憶體上限為 1Gi。

建立 dev-quota.yaml：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-resource-quota
  namespace: development # 明確指定套用的 Namespace
spec:
  hard:
    pods: "2"
    requests.cpu: "1"
    requests.memory: "1Gi"
    limits.cpu: "2"
    limits.memory: "2Gi"

套用配置並檢查配額使用狀況：

kubectl apply -f dev-quota.yaml

# 查看該 Namespace 的配額現況
kubectl get resourcequota -n development

步驟 3：在 Namespace 中部署 Pod（必須聲明 resources）

重要規則：當 Namespace 啟用了 CPU/Memory 配額限制後，該空間內的任何 Pod 建立時，**必須明確宣告 resources.requests 與 resources.limits**，否則會直接被 API Server 拒絕！

建立 dev-pod.yaml：

apiVersion: v1
kind: Pod
metadata:
  name: app-pod-1
  namespace: development
spec:
  containers:
    - name: nginx
      image: nginx:1.25
      resources:
        requests:
          cpu: "200m"
          memory: "256Mi"
        limits:
          cpu: "500m"
          memory: "512Mi"

套用配置並建立第 1 個 Pod：

kubectl apply -f dev-pod.yaml

建立第 2 個 Pod（將名稱改為 app-pod-2 後再次 apply）：

kubectl run app-pod-2 --image=nginx:1.25 -n development \
  --requests='cpu=200m,memory=256Mi' \
  --limits='cpu=500m,memory=512Mi'

檢查當前配額使用率：

kubectl describe resourcequota dev-resource-quota -n development

你會看到 pods 的使用量已經達到 2/2（100% 滿載）。

步驟 4：實測超額防禦機制

現在我們嘗試建立第 3 個 Pod，測試 Kubernetes 是否會阻擋：

kubectl run app-pod-3 --image=nginx:1.25 -n development \
  --requests='cpu=200m,memory=256Mi' \
  --limits='cpu=500m,memory=512Mi'

預期錯誤訊息：

Error from server (Forbidden): pods "app-pod-3" is forbidden: exceeded quota: dev-resource-quota, requested: pods=1, used: pods=2, limited: pods=2

API Server 在第一道防線就直接拒絕了這個請求！ 這確保了該團隊永遠不會無節制地超量佔用集群資源。

實用小技巧：切換 kubectl 的預設 Namespace

如果不想每次下指令都要加上 -n development，可以透過切換 context 預設命名空間：

kubectl config set-context --current --namespace=development

切換後，執行 kubectl get pods 就會自動查詢 development 空間中的資源。

本日小結

今天我們搞懂了如何為團隊建立安全隔離的虛擬空間：

• Namespace 解決了命名衝突與邏輯邊界隔離。
• ResourceQuota 設定了算力天花板，防止單一服務或團隊吃光全集群資源。

目前為止，我們部署一套應用程式往往需要寫 3 到 5 個 YAML 檔（Deployment, Service, PVC, Secret...）。如果要把整套架構複製給別人，或是要部署像 WordPress 這樣複雜的開源專案，一個個 YAML 改參數會非常痛苦。

明天 Day 20，我們將學習 Kubernetes 的套件包裝神器：「K8s 包裝神器：Helm Chart 概念與 Helm Repo 操作」！