2024年07月21日玄貓（BlackCat）

Kubernetes Pod 與節點自動擴充套件實務

本文探討 Kubernetes 中 Pod 和節點的自動擴充套件技術，涵蓋 Horizontal Pod Autoscaler (HPA) 和 Cluster Autoscaler (CA) 的使用方法，以及 KEDA 和 Karpenter 等進階工具的應用。文章將逐步講解如何在 Google Kubernetes

容器技術雲端原生

Kubernetes 自動擴充套件 HPA Cluster Autoscaler KEDA Karpenter

Kubernetes 自動擴充套件功能對於應對波動的工作負載至關重要。本文詳細介紹瞭如何使用 HPA 和 CA 根據 Pod 資源需求和 CPU 使用率自動擴充套件 Pod 和節點。同時也探討了 KEDA 和 Karpenter 等更進階的自動擴充套件工具，它們能夠根據更廣泛的指標和事件觸發擴充套件，提供更精細的控制和更高的效率。文章中包含了 GKE、EKS 和 AKS 等主流雲端平台的組態範例，方便讀者在不同環境中實踐。此外，文章也提供了一些常見問題的解決方案和最佳實務，幫助讀者更好地理解和應用 Kubernetes 自動擴充套件技術。

自動擴充套件 Kubernetes Pod 與節點

在前面的章節中，我們討論瞭如何使用 Horizontal Pod Autoscaler（HPA）來自動擴充套件 Pod。本章節將探討如何使用 Cluster Autoscaler（CA）來自動擴充套件 Kubernetes 節點，以滿足不斷變化的計算資源需求。

使用 Cluster Autoscaler 自動擴充套件 Kubernetes 節點

Cluster Autoscaler（CA）是 Kubernetes 的一部分，負責監控 Pod 和節點的狀態，並根據需要調整叢集的大小。CA 可以與 HPA 互補，當 HPA 決定需要更多的 Pod，但沒有足夠的節點資源時，CA 可以介入並增加叢集的大小。

CA 的運作原理

CA 定期檢查 Pod 和節點的狀態，並根據以下條件決定是否需要採取行動：

如果有 Pod 處於 Pending 狀態，因為叢集資源不足，CA 將增加節點，直到達到預定的最大大小。
如果節點利用率低，且所有 Pod 都可以被排程，即使節點數量減少，CA 也會將節點從叢集中移除，除非已經達到預定的最小大小。節點在被移除之前會被妥善地清空。

CA 的限制

CA 有一些限制，可能會影響其效能：

CA 請求新節點與節點變成可用之間存在延遲，這可能會影回應用程式在高需求期間的效能。
CA 的擴充套件決策僅根據 Pod 資源請求和限制，而不是實際的 CPU 或記憶體利用率。如果 Pod 請求的資源過多，可能會導致節點資源利用率低。
CA 主要設計用於雲端環境。在本地或其他基礎設施上使用 CA 需要額外的努力，包括自定義指令碼或工具來管理節點的供應和復原。

在 GKE 上啟用 CA

在 GKE 上啟用 CA 最簡單的方法是在建立叢集時啟用它。可以使用以下命令建立一個名為 k8sbible 的叢集：

$ gcloud container clusters create k8sbible \
--enable-autoscaling \
--num-nodes 3 \
--min-nodes 2 \
--max-nodes 10 \
--region=us-central1-a

命令引數說明

--enable-autoscaling：為叢集的節點池啟用自動擴充套件。
--num-nodes 3：設定初始節點數量為 3。
--min-nodes 2：設定最小節點數量為 2。
--max-nodes 10：設定最大節點數量為 10。
--region=us-central1-a：指定區域為 us-central1-a。

注意事項

為了使 CA 正常運作，Pod 容器必須指定計算資源的請求，並且這些值應該反映實際的使用情況。
需要謹慎組態 CA，以避免資源耗盡或效能下降。

自動擴充套件 Kubernetes Pod 與節點

在現有的叢集中，需要在現有的 Node 池上啟用 Cluster Autoscaler（CA）。例如，如果您有一個名為 k8sforbeginners 的叢集，其中包含一個名為 nodepool1 的 Node 池，那麼您需要執行以下命令：

$ gcloud container clusters update k8sforbeginners --enable-autoscaling --min-nodes=2 --max-nodes=10 --zone=us-central1-a --node-pool=nodepool1

更新將需要幾分鐘時間。使用 gcloud CLI 驗證自動擴充套件功能，如下所示：

$ gcloud container node-pools describe default-pool --cluster=k8sdemo | grep autoscaling -A 1
autoscaling:
  enabled: true

更多關於 GKE 中的自動擴充套件資訊，請參閱官方檔案：https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-autoscaler。

在 Amazon Elastic Kubernetes Service 中啟用 CA

在 Amazon EKS 中設定 CA 目前無法透過單一按鈕或單一命令完成。您需要建立適當的 IAM 策略和角色，將 CA 資源佈署到 Kubernetes 叢集，並執行手動設定步驟。因此，我們在本文中不涵蓋此內容，並建議您參考官方說明：https://docs.aws.amazon.com/eks/latest/userguide/cluster-autoscaler.html。

在 Azure Kubernetes Service 中啟用 CA

AKS 提供與 GKE 類別似的 CA 設定體驗 - 您可以使用單一命令程式來佈署新的叢集並啟用 CA，或更新現有的叢集以使用 CA。要從頭開始建立一個名為 k8sforbeginners-aks 的新叢集，請在 k8sforbeginners-rg 資源群組中執行以下命令：

$ az aks create --resource-group k8sforbeginners-rg \
  --name k8sforbeginners-aks \
  --node-count 1 \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 10 \
  --vm-set-type VirtualMachineScaleSets \
  --load-balancer-sku standard \
  --generate-ssh-keys

您可以使用 --min-count 引數控制自動擴充套件中的最小節點數量，並使用 --max-count 引數控制最大節點數量。

要在現有的 AKS 叢集 k8sforbeginners-aks 上啟用 CA，請執行以下命令：

$ az aks update --resource-group k8sforbeginners-rg --name k8sforbeginners-aks --enable-cluster-autoscaler --min-count 2 --max-count 10

更新將需要幾分鐘時間。更多資訊請參閱官方檔案：https://docs.microsoft.com/en-us/azure/aks/cluster-autoscaler。

使用 CA

我們剛剛為叢集組態了 CA，CA 可能需要一些時間來執行其第一個動作。這取決於 CA 的組態，這可能是供應商特定的。例如，在 AKS 的情況下，叢集將每 10 秒（scan-interval）進行評估，以檢查是否需要擴充套件或縮減。如果在擴充套件後需要縮減，則有 10 分鐘的延遲（scale-down-delay-after-add）。當請求資源總和除以容量低於 0.5（scale-down-utilization-threshold）時，將觸發縮減。

因此，叢集可能會在啟用 CA 後自動擴充套件、縮減或保持不變。

示範步驟

為了隔離測試，我們將使用 ca-demo Namespace：

# ca/ca-demo-ns.yaml
---
apiVersion: v1
kind: Namespace
metadata:
  labels:
    project: ca-demo
  name: ca-demo

要透過 Kubernetes API 查詢 Deployment，您需要設定額外的 RBAC 許可權。準備一個 Role 定義如下：

# ca/deployment-reader-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: ca-demo
  name: deployment-reader

詳細解說：

在步驟1中，我們建立了一個名為 ca-demo 的 Namespace，以隔離測試環境。這是為了避免幹擾其他 Namespace 中的資源。
在步驟2中，我們定義了一個 Role，用於授予對 Deployment 的查詢許可權。這是為了讓 Pod 能夠查詢 Kubernetes API 以取得目前的副本數量。

使用 hamster Deployment 示範自動擴充套件

我們將使用另一個 hamster Deployment（參考 GitHub 倉函式庫中的 Chapter20/ca 目錄）來建立一個 elastic-hamster Deployment。在容器中持續執行的 hamster.sh shell 指令碼將根據 TOTAL_HAMSTER_USAGE 值增加工作負載。

詳細解說：

hamster.sh 指令碼會查詢 Kubernetes API 以取得目前的副本數量，然後將總工作量除以副本數量，以確定每個 hamster 的工作量。
例如，如果我們設定所有 hamster 的總工作量為 1.0（代表叢集中的總 KCU 消耗），並佈署 5 個副本，那麼每個 hamster 將工作 0.2 秒，休息 0.8 秒。如果我們將 Deployment 縮放到 10 個副本，那麼每個 hamster 將工作 0.1 秒，休息 0.9 秒。

自動擴充套件流程圖示

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Kubernetes Pod 與節點自動擴充套件實務

package "Kubernetes Cluster" {
    package "Control Plane" {
        component [API Server] as api
        component [Controller Manager] as cm
        component [Scheduler] as sched
        database [etcd] as etcd
    }

    package "Worker Nodes" {
        component [Kubelet] as kubelet
        component [Kube-proxy] as proxy
        package "Pods" {
            component [Container 1] as c1
            component [Container 2] as c2
        }
    }
}

api --> etcd : 儲存狀態
api --> cm : 控制迴圈
api --> sched : 調度決策
api --> kubelet : 指令下達
kubelet --> c1
kubelet --> c2
proxy --> c1 : 網路代理
proxy --> c2

note right of api
  核心 API 入口
  所有操作經由此處
end note

@enduml

此圖示展示了 Cluster Autoscaler 的工作流程，從啟用到評估叢集資源，再到執行擴充套件或縮減操作。

詳細解說：

圖表展示了 Cluster Autoscaler 的工作流程，包括啟用、評估叢集資源、執行擴充套件或縮減操作等步驟。
圖表中的每個節點代表一個特定的操作或狀態，箭頭表示流程的方向。

Kubernetes 自動擴充套件 Pod 與 Node 實務

Kubernetes 的 Cluster Autoscaler (CA) 與 Horizontal Pod Autoscaler (HPA) 提供了動態調整資源的能力，能夠根據實際工作負載自動擴充套件或縮減 Pod 和 Node。本章節將透過實際範例展示 CA 和 HPA 如何協同工作，以實作 Kubernetes 叢集的最佳化資源管理。

實作步驟與程式碼解析

1. 建立 Role 與 RoleBinding

首先，我們需要為 ServiceAccount 定義一個 Role，使其能夠存取 Deployment 資源。以下是 deployment-reader-role.yaml 的內容：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployment-reader
  namespace: ca-demo
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "watch", "list"]

內容解密：

apiVersion 和 kind 定義了該資源的 API 版本和型別。
metadata 包含了 Role 的名稱和所屬的 Namespace。
rules 定義了該 Role 的許可權範圍，包括允許的操作（如 get、watch、list）和目標資源（Deployments）。

接著，建立對應的 RoleBinding，將該 Role 繫結到特定的 ServiceAccount。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-deployments
  namespace: ca-demo
subjects:
- kind: ServiceAccount
  name: elastic-hamster
  namespace: default
roleRef:
  kind: Role
  name: deployment-reader
  apiGroup: rbac.authorization.k8s.io

內容解密：

subjects 指定了繫結該 Role 的 ServiceAccount。
roleRef 定義了被繫結的 Role。

2. 建立 ServiceAccount 與 Deployment

建立一個名為 elastic-hamster 的 ServiceAccount，並將其與 Deployment 組態關聯。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: elastic-hamster
  namespace: ca-demo

apiVersion: apps/v1
kind: Deployment
metadata:
  name: elastic-hamster
  namespace: ca-demo
spec:
  serviceAccountName: elastic-hamster
  containers:
  - name: hamster
    image: quay.io/iamgini/elastic-hamster:1.0
    resources:
      requests:
        cpu: 500m
        memory: 50Mi
    env:
    - name: TOTAL_HAMSTER_USAGE
      value: "1.0"

內容解密：

serviceAccountName 指定了 Deployment 使用的 ServiceAccount。
resources.requests 定義了容器所需的最低資源量。

3. 設定 HPA

建立 HPA 以動態調整 Pod 的數量。

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: elastic-hamster-hpa
  namespace: ca-demo
spec:
  minReplicas: 1
  maxReplicas: 25
  metrics:
  - resource:
      name: cpu
      target:
        averageUtilization: 75
        type: Utilization
    type: Resource
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: elastic-hamster

內容解密：

minReplicas 和 maxReplicas 定義了 Pod 的數量範圍。
metrics 設定了 HPA 的擴充套件指標，本例中為 CPU 使用率。

操作與結果分析

當 HPA 發現 CPU 使用率超過設定的閾值（75%）時，會增加 Pod 的數量。由於設定的 maxReplicas 為 25，CA 將自動擴充套件 Node 以滿足新增 Pod 的資源需求。

$ kubectl get po -n ca-demo
NAME                                READY   STATUS    RESTARTS   AGE
elastic-hamster-87d4db7fd-4tmxn     0/1     Pending   0          7m20s
elastic-hamster-87d4db7fd-59lcd     1/1     Running   0          8m4s
...

結果分析：

部分 Pod 處於 Pending 狀態，因為叢集資源不足。CA 將自動增加 Node 以排程這些 Pending 的 Pod。

縮減規模

當工作負載減少時，可以透過調整 HPA 的 maxReplicas 設定來減少 Pod 的數量，從而觸發 CA 縮減 Node。

$ kubectl patch hpa elastic-hamster-hpa -n ca-demo -p '{"spec": {"maxReplicas": 2}}'

結果分析：

CA 將在縮減 Node 前等待一段時間（預設為10分鐘），以避免頻繁的擴充套件和縮減操作。

Kubernetes 自動擴充套件技術詳解

在現代雲端原生環境中，Kubernetes 已成為容器協調的標準工具。隨著工作負載的動態變化，自動擴充套件（Autoscaling）技術對於確保應用效能和成本最佳化至關重要。本章將探討 Kubernetes 中的自動擴充套件技術，包括 Pod 自動擴充套件和節點自動擴充套件。

為何需要自動擴充套件？

在 Kubernetes 叢集中，工作負載可能會因各種因素（如使用者請求、資料處理量等）而動態變化。手動調整資源無法及時回應這些變化，因此需要自動擴充套件機制來動態調整 Pod 和節點數量，以滿足當前需求。

KEDA：事件驅動的自動擴充套件

KEDA（https://keda.sh）是一款專為 Kubernetes 設計的事件驅動自動擴充套件工具。它允許根據自定義指標或外部事件來擴充套件 Pod 副本數量。與傳統的根據 CPU 或記憶體使用率的自動擴充套件不同，KEDA 可以根據各種事件來源（如訊息佇列、HTTP 請求率、自定義應用指標等）觸發擴充套件。

KEDA 的架構與元件

下圖展示了 KEDA 的架構和元件：此圖示展示了 KEDA 如何與 Kubernetes HPA（Horizontal Pod Autoscaler）整合，並支援多種事件來源。

KEDA 是一個由 CNCF（Cloud Native Computing Foundation）託管的開源專案，提供根據 GitHub 的最佳支援，用於提交錯誤和功能請求。許多廠商在其產品中包含 KEDA，例如 Azure Container Apps、Red Hat OpenShift Autoscaler with custom metrics 和 KEDA Add-On for Azure Kubernetes Service。

Karpenter：節點自動擴充套件的最佳化

Karpenter（https://karpenter.sh）是一款先進的 Kubernetes CA（Cluster Autoscaler），專注於最佳化叢集內的節點組態和擴充套件。它透過動態調整節點數量來滿足工作負載需求，從而提高效能和成本效率。

Karpenter 的工作原理

下圖展示了 Karpenter 在 Kubernetes 叢集中的工作原理：此圖示闡述了 Karpenter 如何自動調整節點數量以滿足工作負載需求。

Karpenter 提供快速且高效的節點擴充套件功能，包括容量最佳化和智慧組態。它確保提供適當型別和數量的節點來滿足工作負載需求，從而減少浪費和成本。

進一步閱讀

Horizontal Pod Autoscaling: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
Autoscaling Workloads: https://kubernetes.io/docs/concepts/workloads/autoscaling/
Cluster Autoscaling: https://kubernetes.io/docs/concepts/cluster-administration/cluster-autoscaling/
The Complete Kubernetes Guide
Getting Started with Kubernetes – Third Edition
Kubernetes for Developers
Hands-On Kubernetes on Windows

您也可以參考官方 Kubernetes 檔案：https://kubernetes.io/docs/home/，以取得最新的 Kubernetes 知識。