在K8s Operator模式下，雲原生數據庫的水平擴縮容（Horizontal） 和 垂直擴縮容（Vertical） 本質都是通過修改自定義資源（Custom Resource）的聲明式配置，由Operator監聽並驅動集羣狀態向目標狀態收斂。

下面這個對比表格，清晰地展示了兩種擴縮容方式的核心區別：

特性維度

水平擴縮容 (Horizontal Pod Autoscaling)

垂直擴縮容 (Vertical Pod Autoscaling)

核心目標

增減 Pod副本數量，應對流量變化，提高可用性。

調整 單個Pod的CPU/內存 資源限制，應對單Pod負載變化。

Operator觸發方式

修改CR中對應組件（如 TiKV, FE）的 replicas 字段。

修改CR中Pod模板的 spec.resources（requests/limits）字段。

Operator核心動作

1. 擴容：創建新Pod，加入集羣，等待數據同步/負載均衡。

2. 縮容：安全驅逐數據，刪除指定Pod。

1. 執行滾動更新：基於新資源配置，逐個重啓Pod。

2. 確保新Pod調度成功。

對服務影響

小。新Pod就緒後服務能力線性變化，縮容時Operator會確保數據安全。

較大。每個Pod重啓時會有秒級中斷，需應用具備重連機制。

主要耗時

擴容：分鐘級（拉鏡像、啓動、數據同步）。

縮容：分鐘級（數據遷移或驅逐）。

滾動更新：依賴Pod重啓速度和健康檢查，通常為分鐘到十分鐘。

存儲考慮

有狀態組件需依賴持久卷（PVC），縮容時Operator通常只刪除Pod，保留PVC以備後用。

若使用本地持久卷（Local PV），新Pod可能因原節點資源不足而無法調度，導致更新失敗。

🔍 Operator內部工作流程詳解

當你修改了CR（如 TidbCluster）中的字段並應用後，Operator的Controller會開始工作：

  1. 監聽與調和（Reconcile Loop）：Operator的控制器持續監聽它所管理的CR對象。一旦檢測到 spec 字段（如 replicas 或 resources）發生變化，調和循環會被觸發。
  2. 計算差異與生成動作：Operator將CR中聲明的期望狀態（Desired State） 與集羣的實際狀態（Current State） 進行比較，計算出需要執行的具體操作（如創建/刪除Pod、更新Deployment）。
  3. 執行與狀態更新：Operator調用Kubernetes API執行上述操作，並再次監聽結果，更新CR的 status 字段，直到實際狀態與期望狀態一致。

📝 詳細操作步驟與最佳實踐

以擴縮容一個假設的雲原生數據庫集羣為例：

第一步：變更前檢查與準備

# 1. 查看當前集羣狀態
kubectl get pods -l app=example-db -o wide
kubectl get crd <your-database-crd-name> -o yaml

# 2. 備份關鍵數據與CR配置
kubectl get <crd-kind> <cluster-name> -n <namespace> -o yaml > backup.yaml

# 3. 檢查資源餘量（垂直擴容時尤其重要）
kubectl describe nodes | grep -A 5 "Allocatable"

第二步：執行擴縮容操作

# 水平擴容示例（修改 replicas）
spec:
  tikv:
    replicas: 5 # 從3擴容到5
    resources:
      requests:
        memory: "8Gi"

# 垂直擴容示例（修改 resources）
spec:
  tidb:
    replicas: 2
    resources: # 增加單個Pod的資源
      requests:
        cpu: "1000m"
        memory: "4Gi"
      limits:
        cpu: "2000m"
        memory: "8Gi"
# 應用變更
kubectl apply -f your-cluster-cr.yaml
# 或使用patch命令直接修改
kubectl patch tidbcluster <cluster-name> --type='merge' -p '{"spec":{"tikv":{"replicas":5}}}'

第三步：監控與驗證

# 1. 觀察Pod狀態變化
kubectl get pods -w -l app.kubernetes.io/component=tikv
# 2. 查看Operator日誌
kubectl logs -f deployment/<operator-deployment-name> -n <operator-namespace>
# 3. 查看CR狀態字段
kubectl get tidbcluster <cluster-name> -o jsonpath='{.status}'
# 4. 驗證服務
kubectl exec -it <client-pod> -- mysql -h <db-service> -u root -e "SHOW DATABASES;"

⚠️ 關鍵注意事項與風險控制

  1. 數據安全（縮容時）：對於有狀態組件（如TiKV），Operator應在縮容前自動遷移或驅逐其上的數據副本。務必確認數據庫自身狀態顯示數據副本數充足、健康，再執行縮容。
  2. 業務影響（垂直擴縮容）：垂直擴縮容會導致Pod滾動重啓。需確保：
  • 在業務低峯期操作。
  • 應用客户端配置了優雅重連機制。
  • 使用 PodDisruptionBudget 來保證最小可用副本數。
  1. 資源與調度：垂直擴容時，新Pod的資源請求可能超過原節點的可用資源，導致Pod無法調度（Pending）。請確保節點有足夠資源，或集羣有自動擴縮節點能力。
  2. 順序依賴：某些數據庫的擴縮容操作有順序要求（如TiKV縮容未完成時不能擴容）。請遵循官方文檔建議。

💡 高級實踐與建議

  • 藍綠/金絲雀發佈：對於重大垂直擴縮容（如大版本升級伴隨規格變更），可考慮先創建一個新版本的數據庫集羣，通過流量切換來驗證，而非直接滾動更新。
  • 自動化與HPA/VPA：可結合Kubernetes原生HPA（根據CPU等指標自動水平擴縮）或使用數據庫特定的AutoScaler（如TiDB的AutoScaler），實現自動化擴縮容。

如果需要針對特定數據庫（如TiDB、MongoDB、Redis Operator等）進行更具體的流程分析，或者想了解如何結合監控指標實現自動化擴縮容，我可以提供更深入的信息。