Azure Kubernetes Service （AKS） 部署與叢集可靠性最佳實踐

適用於: ✔️ AKS 自動化 ✔️ AKS 標準

AKS 叢集的可靠性指的是 Azure Kubernetes Service 叢集能夠維持可用性、從故障中恢復，以及在最小停機時間內處理中斷的能力。 本文提供在部署層級與叢集層級實作叢集可靠性的最佳實務，適用於您的 Azure Kubernetes Service （AKS） 工作負載。 本文適用於負責在 AKS 部署及管理應用程式的叢集作業人員和開發人員。

重要心得

• 為所有 Pod 設定 CPU 與記憶體限制 ，以防止資源耗盡並防範服務威脅，如 DDoS 攻擊。
• 使用 Pod 中斷預算 (PDB)，確保在升級或意外刪除等自願性中斷期間維持 Pod 的最低可用性。
• 在叢集建立時啟用可用區域，以確保在區域下落情境下保持高可用性（建立後無法更改）。
• 至少部署兩個應用程式副本 ，以確保在節點故障情境下具備高可用性與韌性。
• 配置準備度、活態狀態及啟動探測 ，以提升應用程式韌性並減少不必要的容器重啟。
• 使用Standard Load Balancer處理生產工作負載，以支援多個可用區域及高韌性。
• 啟用容器洞察 以監控並診斷您的容器化應用程式的效能。

本文提供在部署層級與叢集層級實作叢集可靠性的最佳實務，適用於您的 Azure Kubernetes Service （AKS） 工作負載。 本文適用於負責在 AKS 部署及管理應用程式的叢集作業人員和開發人員。

本文的最佳做法分門別類成下列類別：

AKS 叢集模式與可靠性

AKS 支援兩種叢集模式： AKS 自動模式 與 AKS 標準模式。 許多工作負載層級的可靠性實務同樣適用於兩種模式，例如設定資源請求、定義 Pod Disruption Budgets（PDB）、配置探測器，以及執行多個副本。 然而，群組層級的職責會依模式而異：

• AKS 自動 提供更多預先設定的可靠性預設，包括管理系統節點池、節點自動配置（NAP）、自動叢集升級、自動節點作業系統映像升級、標準層級及 LocalDNS。
• AKS 標準 提供更廣泛的直接配置控制，並要求操作員明確啟用及管理更多叢集層級的可靠性功能。

欲了解更多資訊，請參閱 「什麼是AKS自動？」

部署層級的最佳做法

下列部署層級最佳做法有助於確保 AKS 工作負載的高可用性和可靠性。 這些最佳做法是您可在 pod 和部署的 YAML 檔案實作的本機組態。

快速參考清單：

• 為所有生產工作負載設定 PDB
• 為所有 pod 設定 CPU 和記憶體限制
• 至少部署 2 個複本，以支援具區域備援能力的工作負載
• 為所有容器設定準備狀態、活絡性及啟動探針
• 在關鍵應用中使用莢艙拓撲擴散約束

Pod CPU 和記憶體限制

最佳做法指引

設定所有 Pod 的 Pod CPU 和記憶體限制，以確保 Pod 不會耗用節點的所有資源，並在服務威脅 (例如 DDoS 攻擊) 期間提供保護。

Pod CPU 和記憶體限制定義了 Pod 可使用的最大 CPU 和記憶體數量。 如果 Pod 超過已定義的限制，就會標示移除。 如需詳細資訊，請參閱 Kubernetes 的 CPU 資源單位和 Kubernetes 的記憶體資源單位。

設定 CPU 和記憶體限制有助於維護節點健康情況，並將節點上其他 Pod 受到的影響降到最低。 避免將 Pod 的限制設為高於節點所能支援的容量。 每個 AKS 節點都會保留一定數量的 CPU 和記憶體給核心 Kubernetes 元件使用。 如果您設定的 Pod 限制高於節點的支援上限，您的應用程式可能會嘗試耗用過多資源，並對節點的其他 Pod 造成負面影響。 在需要設定資源要求和限制的命名空間，叢集管理員必須設定資源配額。 如需詳細資訊，請參閱在 AKS 強制執行資源配額。

叢集管理員也可以透過命名空間層級的配額和政策控制來強化這些設定。 在 AKS 自動中，部署防護措施可協助執行資源相關的最佳實務，但操作者仍應明確定義符合工作負載的請求與限制。 如需詳細資訊，請參閱在 AKS 強制執行資源配額。

在下列範例 Pod 定義檔案，resources 區段設定了 Pod 的 CPU 和記憶體限制：

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 250m
        memory: 256Mi

kubectl describe node <node-name>

# Example output
Capacity:
 cpu:                8
 ephemeral-storage:  129886128Ki
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             32863116Ki
 pods:               110
Allocatable:
 cpu:                7820m
 ephemeral-storage:  119703055367
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             28362636Ki
 pods:               110

如需詳細資訊，請參閱將 CPU 資源指派給容器和 Pod，以及將記憶體資源指派給容器和 Pod。

垂直 pod 自動調整程式 (VPA)

最佳做法指引

使用垂直 Pod 自動調整器 (VPA) 根據 Pod 的實際使用情況自動調整 CPU 和記憶體請求。

雖然 Vertical Pod Autoscaler（VPA）並非直接透過 pod YAML 實作，但它能自動調整 Pod 的 CPU 與記憶體請求，來優化資源分配。 這確保你的應用程式擁有足夠資源，能有效運作，避免過度配置或不足配置。

在 AKS Automatic 中，叢集預設已啟用 VPA。 在 AKS 標準中，操作員可自行決定是否啟用此功能。

VPA 有三種運作模式：

• 關閉：只提供建議，不做任何變更。
• 自動：在 Pod 重新啟動時，自動更新 Pod 資源請求。
• 初始：僅在 pod 建立時設定資源請求。

以下範例展示了如何在 Kubernetes 中配置 VPA 資源：

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: my-deployment
  updatePolicy:
    updateMode: "Auto" # Options: Off, Auto, Initial

欲了解更多資訊，請參閱 垂直艙自動調整器文件。

Pod 中斷預算 (PDB)

最佳做法指引

使用 Pod 中斷預算 (PDB) 以確保在自主中斷 (例如升級作業或意外刪除 Pod) 期間，仍可使用最少的 Pod 數目。

Pod 中斷預算 (PDB) 可讓您定義部署或複本集在自主中斷 (例如升級作業或意外刪除 Pod) 期間的回應方式。 您可以使用 PDB 來定義無法使用的資源計數下限或上限。 PDB 只對自主中斷的收回 API 有影響。

舉例來說，假設您需要執行叢集升級，且已定義 PDB。 在執行叢集升級之前，Kubernetes 排程器可確保在 PDB 定義的 Pod 數目最小值可用。 如果升級會導致可用的 Pod 數目低於在 PDB 定義的最小值，排程器就會先排程其他節點上的額外 Pod，再讓升級繼續進行。 如果您未設定 PDB，排程器就不會對升級期間無法使用的 Pod 數目設定任何限制，這可能導致資源不足並發生叢集中斷。

AKS Automatic 中的叢集層級升級自動化可減輕部分營運負擔，但中斷期間工作負載可用性仍依賴應用層級控制，如 PDB。

在下列範例 PDB 定義檔案，minAvailable 欄位會設定自主中斷期間必須維持可用的最低 Pod 數目。 此值可為絕對數字 (例如 3) 或所需 Pod 數目的百分比 (例如 10%)。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
   name: mypdb
spec:
   minAvailable: 3 # Minimum number of pods that must remain available during voluntary disruptions
   selector:
    matchLabels:
      app: myapp

如需詳細資訊，請參閱使用 PDB 規劃可用性，以及指定應用程式的中斷預算。

若要自動建立未受保護部署的 PDB，並防止升級期間發生與 PDB 相關的清空失敗，請參閱 AKS 的自動 PDB 管理（預覽）。

pod 正常終止

最佳做法指引

利用 PreStop 掛鉤並設定適當的 terminationGracePeriodSeconds 數值，確保 pod 能順利終止。

柔性終止會確保 pod 有足夠的時間清理資源、完成正在進行的任務，或通知依賴的服務，然後才會終止。 這對於需要適當關機程序的有狀態應用程式或服務尤其重要。

使用 PreStop 勾點

在容器因 API 要求或管理事件 (例如先佔、資源爭用或活躍度/啟動探查失敗) 而終止之前，系統會先立即呼叫 PreStop 勾點。 這個 PreStop 鉤子讓你能定義自訂指令或腳本，在容器停止前執行。 例如，你可以用它來清除日誌、關閉資料庫連線，或通知其他服務關閉。

下列範例 Pod 定義檔示範如何使用 PreStop 勾點來確保容器的柔性終止：

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "nginx -s quit; while killall -0 nginx; do sleep 1; done"]

配置 terminationGracePeriodSeconds

欄位 terminationGracePeriodSeconds 指定了 Kubernetes 在強制終止 pod 前等待的時間。 這段時間包括執行 PreStop 鉤子的時間。 如果 PreStop 勾點在寬限期內未完成，pod 就會強制終止。

例如，以下 Pod 的定義中設定了30秒的終止寬限期：

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  terminationGracePeriodSeconds: 30
  containers:
  - name: example-container
    image: nginx

如需詳細資訊，請參閱容器生命週期勾點和 Pod 終止。

升級期間的高可用性

使用 maxSurge 以加快更新

最佳做法指引

設定 maxSurge 欄位，以允許在滾動更新期間建立更多 Pods，從而實現快速更新並將停機時間降至最低。

該 maxSurge 欄位指定在一次滾動更新期間，新增的額外 pod 數量最多可超過期望數量。 這讓新 pod 能在舊 pod 終止前就已建立並準備好，確保更新更快並降低停機風險。

以下部署清單範例示範如何配置 maxSurge：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 33% # Maximum number of additional pods created during the update

將 3 設定 maxSurge 後，此配置確保在滾動更新期間最多可新增三個 pod，加快部署流程同時維持應用程式可用性。 欲了解更多資訊，請參閱 Kubernetes 中的滾動更新。

使用 maxUnavailable 進行受控更新

最佳做法指引

設置maxUnavailable欄位以限制滾動更新期間不能使用的 Pod 數量，確保應用程式維持運行並將中斷降至最低。

此 maxUnavailable 領域對於需要計算密集型或具備特定基礎設施需求的應用特別有用。 它會指定在滾動更新期間的任何特定時間，無法使用的 pod 上限。 這確保在部署新 Pod 和終止舊 Pod 的同時，應用程式的一部分仍能正常運作。

你可以設定 maxUnavailable 為絕對數（例如 1），或是目標 pod 數量的百分比（例如 25%）。 例如，如果你的應用程式有四個副本，且你設定 maxUnavailable 為 1，Kubernetes 確保在更新過程中至少有三個 Pod 可用。

以下部署清單範例示範如何配置 maxUnavailable：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1 # Maximum number of pods that can be unavailable during the update

在此範例中，設定 maxUnavailable 為 1，確保在滾動更新期間的任何時候，不會有超過一個 pod 不可用。 此配置非常適合需要專門運算的應用，因為維持最低服務可用性至關重要。

欲了解更多資訊，請參閱 Kubernetes 中的滾動更新。

Pod 拓撲分散條件約束

最佳做法指引

使用 Pod 拓撲分散條件約束，可確保 Pod 分散到不同的節點或區域，以改善可用性和可靠性。

您可以使用 Pod 拓撲分散條件約束來控制 Pod 如何根據節點的拓撲分散到叢集，並將 Pod 分散到不同節點或區域，以改善可用性和可靠性。

在 AKS Automate 中，部署保障措施可協助套用部分工作負載分配最佳實務，但應用專屬拓撲要求仍應明確定義於工作負載清單中。

下列範例 Pod 定義檔示範如何使用 topologySpreadConstraints 欄位，將 Pod 分散到不同節點：

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  # Configure a topology spread constraint
  topologySpreadConstraints:
    - maxSkew: <integer>
      minDomains: <integer> # optional
      topologyKey: <string>
      whenUnsatisfiable: <string>
      labelSelector: <object>
      matchLabelKeys: <list> # optional
      nodeAffinityPolicy: [Honor|Ignore] # optional
      nodeTaintsPolicy: [Honor|Ignore] # optional

如需詳細資訊，請參閱 Pod 拓撲分散條件約束。

整備度、活躍度和啟動探查

最佳做法指引

如果適用於改善負載過高的復原能力與降低容器重新啟動，請設定整備度、活躍度和啟動探查。

即使 AKS Automatic 提供了基線防護，探測器配置仍依工作負載而定，仍應在應用程式清單中撰寫。

整備度探查

在 Kubernetes，kubelet 會使用整備度探查來得知容器何時可開始接受流量。 如果 Pod 的所有容器都就緒，Pod 即為就緒。 如果 Pod 尚未就緒，就會從服務 Load Balancer 中遭到移除。 如需詳細資訊，請參閱 Kubernetes 的整備度探查。

下列範例 Pod 定義檔會示範整備度探查組態：

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

如需詳細資訊，請參閱設定整備度探查。

活躍度探查

在 Kubernetes，kubelet 會使用活躍度探查來得知何時重新啟動容器。 如果容器沒有通過活躍度探查，就會重新啟動。 如需詳細資訊，請參閱 Kubernetes 的活躍度探查。

下列範例 Pod 定義檔會示範活躍度探查組態：

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy

另一種活躍度探查會使用 HTTP GET 要求。 下列範例 Pod 定義檔示範 HTTP GET 要求的活躍度探查組態：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

如需詳細資訊，請參閱設定活躍度探查和定義活躍度 HTTP 要求。

啟動探查

在 Kubernetes，kubelet 會使用啟動探查來得知容器應用程式何時啟動。 如有設定啟動探查，在啟動探查成功之前，整備度和活躍度探查都不會啟動，這能確保整備度和活躍度探查不會干擾應用程式啟動。 如需詳細資訊，請參閱 Kubernetes 的啟動探查。

下列範例 Pod 定義檔會示範啟動探查組態：

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

多複本應用程式

最佳做法指引

至少部署兩個應用程式的複本，以確保節點關閉時的高可用性和復原。

在 Kubernetes，您可以在部署時使用 replicas 欄位來指定您要執行的 Pod 數目。 執行多個應用程式執行個體有助於確保節點關閉時的高可用性和復原。 AKS Automatic 可提升作業就緒性與擴縮行為，但可用性仍取決於是否執行足夠數量的複本，並使用適當的放置控制機制。 如果您已啟用可用性區域，可以使用 replicas 欄位來指定您要在多個可用性區域執行的 Pod 數目。

下列範例 Pod 定義檔示範如何使用 replicas 欄位來指定您要執行的 Pod 數目：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

如需詳細資訊，請參閱 AKS 建議的主動/主動高可用性解決方案概觀和部署規格的複本。

叢集和節點集區層級最佳做法

下列叢集和節點集區層級最佳做法有助於您確保 AKS 叢集的高可用性和可靠性。 您可以在建立或更新 AKS 叢集時實作這些最佳做法。 與部署層級相比，AKS 自動與 AKS 標準之間的責任差異更大。

快速參考清單：

• 在叢集建立時啟用可用區域（建議設置 3 個可用區域）
• 對所有生產工作負載使用 Standard Load Balancer
• 每個 系統節點池至少設定 2 個節點
• 啟用 Container Insights 以進行監控
• 製作時請使用標準或高級定價層級

可用性區域

最佳做法指引

建立 AKS 叢集時，請使用多個可用性區域，以確保區域停機時的高可用性。 請記住，您在建立叢集之後就無法變更可用性區域組態。

可用性區域是區域內的個別資料中心群組。 這些區域足夠接近，可在彼此之間形成低延遲連線，但也足夠遠，可減少超過一個區域受到地區中斷或天氣影響的可能性。 使用可用性區域可協助您的資料在區域停機時保持同步且可存取。 如需詳細資訊，請參閱在多個區域執行。

AKS Automatic 簡化了第 2 天作業，但無法免除在叢集建立期間規劃拓撲的需求，而區域部署是設計的一部分。

叢集自動調整

最佳做法指引

使用叢集自動調整來確保叢集可處理增加的負載，並在低負載期間降低成本。

為了符合 AKS 的應用程式需求，您可能需要調整執行工作負載的節點數目。 叢集自動調整程式元件可以監看叢集中由於資源限制而無法排程的 Pod。 叢集自動調整程式偵測到問題時，會擴大節點集區的節點數目，以符合應用程式需求。 它也會定期檢查節點是否缺少執行中的 Pod，然後視需要減少節點的數目。 如需詳細資訊，請參閱 AKS 的叢集自動調整。

縮放行為依叢集模式而異：

• AKS 自動：節點自動配置為預先設定，且預設啟用 HPA、KEDA 及 VPA 等工作負載擴展功能。
• AKS 標準：營運者明確啟用並調整叢集自動擴展器、節點自動配置及工作負載自動擴展功能。

在 AKS Standard 中，你可以在建立叢集時使用以下 --enable-cluster-autoscaler 參數：

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 2 \
    --vm-set-type VirtualMachineScaleSets \
    --load-balancer-sku standard \
    --enable-cluster-autoscaler  \
    --min-count 1 \
    --max-count 3 \
    --generate-ssh-keys

您也可以在現有的節點集區啟用叢集自動調整程式，並變更整個叢集的自動調整程式設定檔預設值，藉此設定叢集自動調整程式的精細詳細資料。

如需詳細資訊，請參閱在 AKS 使用叢集自動調整程式。

進入與離開的可靠性

最佳做法指引

使用符合你 AKS 叢集模式和可靠性需求的叢集網路模型。

對於 AKS 標準，Standard Load Balancer 仍是進出流量情境中常見且推薦的可靠選擇。

對於 AKS Automatic，ingress 和 egress 的預設值會由系統管理得更多：

• 託管虛擬網路預設是預先設定好的。
• 受管理的 NAT 閘道器已預先設定為支援的受管理虛擬網路情境。
• 針對受支援的叢集版本，透過應用程式路由的受控輸入已預先完成設定。

如果您使用 AKS Standard，以下Standard Load Balancer 指導方針仍然適用：

Standard Load Balancer

最佳做法指引

使用 Standard Load Balancer 提供更高的可靠性與資源，支援多重可用性區域、HTTP 探測，以及跨多個資料中心的功能。

在Azure中，Standard Load Balancer SKU 設計用於需要高效能與低延遲時，用於負載平衡網路層流量。 Standard Load Balancer 會在區域內和區域間路由流量，並路由到可用性區域以提高復原力。 Standard SKU 是建立 AKS 叢集時建議使用的預設 SKU。

以下範例展示了使用 Standard Load Balancer 的 LoadBalancer 服務清單：

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-ipv4 # Service annotation for an IPv4 address
  name: azure-load-balancer
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-load-balancer

如需詳細資訊，請參閱在 AKS 使用 Standard Load Balancer。

系統節點集區

使用專用的系統節點集區

AKS Automatic 使用由 AKS 建立、擴展、升級及操作的管理系統節點池。 操作員的重點從手動建置系統池拓撲轉向驗證工作負載的配置、容量行為及命名空間層級的控制。

以下指引仍適用於AKS標準：

最佳做法指引

使用系統節點集區來確保其他使用者應用程式都不會在相同節點執行，否則可能導致資源短缺並影響系統 Pod。

使用專用的系統節點集區來確保其他使用者應用程式都不會在相同節點執行，否則可能會因為爭用而造成資源短缺和潛在的叢集中斷。 若要使用專用系統節點集區，您可以使用系統節點集區的 CriticalAddonsOnly 污點。 如需詳細資訊，請參閱在 AKS 使用系統節點集區。

系統節點集區自動調整

最佳做法指引

設定系統節點集區的自動調整程式，以設定節點集區的調整限制上下限。

在 AKS Automatic 中，系統節點池容量由 AKS 管理。 在 AKS 標準中，使用自動縮放器配置，讓系統節點池能隨時擴展以滿足系統 Pod 的需求。

使用節點集區的自動調整程式來設定節點集區的調整限制上下限。 系統節點集區應一律可調整以符合系統 Pod 的需求。 如果系統節點集區無法調整，叢集就會用盡資源，以利管理排程、調整和負載平衡，導致叢集沒有回應。

如需詳細資訊，請參閱在節點集區使用叢集自動調整程式。

每個系統節點池至少有兩個節點

最佳做法指引

確保系統節點池至少有兩個節點，以防範凍結或升級情境，避免節點被重啟或關閉。

在 AKS 標準中，系統節點池應至少有兩個節點，以提升重啟或升級事件中的韌性。 在 AKS Automatic 中，系統節點集區的韌性由服務管理，但工作負載設計仍應假設系統元件可能會在平台作業過程中升級或移轉。

系統節點集區會用於執行系統 Pod，例如 kube-proxy、coredns 和 Azure CNI 外掛程式。 我們建議 您確保系統節點池至少有兩個節點 ，以防範凍結或升級情境，避免節點被重新啟動或關閉。 如需詳細資訊，請參閱在 AKS 管理系統節點集區。

節點池的升級配置

升級擁有權依叢集模式而異：

• AKS 自動：叢集升級預設使用穩定通道，節點作業系統映像升級預設使用 NodeImage 通道。 營運商專注於工作負載準備、中斷控制、維護時程及安全部署驗證。
• AKS 標準：營運商明確配置升級通道及節點池設定，如 maxSurge 與 maxUnavailable。

用於 maxSurge 進行節點集區升級

最佳做法指引

設定 maxSurge 節點池升級設定，以提升可靠性並減少升級操作中的停機時間。

設定指定 maxSurge 升級過程中可新增的最大節點數量。 這確保新節點在舊節點被清除前就已配置並準備好，降低應用程式停機的風險。

例如，以下Azure CLI指令將節點池的 maxSurge 設為 1：

az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name myNodePool \
  --max-surge 1

透過配置 maxSurge，您可以確保升級更快完成，同時維持應用程式可用性。

欲了解更多資訊，請參閱 AKS 中的升級節點池。

用於 maxUnavailable 進行節點集區升級

最佳做法指引

設定 maxUnavailable 節點池升級設定，以確保升級操作期間應用程式的可用性。

此設定maxUnavailable指定升級過程中最多可有多少節點無法使用。 這確保節點池的一部分在升級過程中仍能運作。

例如，以下Azure CLI指令將節點池的 maxUnavailable 設為 1：

az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name myNodePool \
  --max-unavailable 1

透過配置 maxUnavailable，您可以控制升級對工作負載的影響，確保整個過程中仍有足夠資源可用。

欲了解更多資訊，請參閱 AKS 中的升級節點池。

加速化網路

最佳做法指引

使用加速網路可降低延遲、減少抖動，與縮減 VM 的 CPU 使用率。

加速網路可在支援的 VM 類型啟用單一根目錄 I/O 虛擬化 (SR-IOV)，大幅提升網路效能。

下圖說明兩個 VM 在有與沒有加速網路的情況下分別如何通訊：

如需詳細資訊，請參閱加速網路概觀。

映像版本

最佳做法指引

映像不應使用 latest 標籤。

容器映像標籤

將 latest 標籤用於容器映像可能導致無法預期的行為，且難以追蹤叢集執行的映像版本。 您可以在建置和執行時間整合及執行容器的掃描和補救工具，以將風險降至最低。 如需詳細資訊，請參閱 AKS 的容器映像管理最佳做法。

節點映像升級

節點映像升級行為會依叢集模式而異：

• AKS 自動：Node OS 映像升級是透過 NodeImage 通道預先設定的。
• AKS 標準：操作員可選擇手動管理或自動升級通道。

AKS 提供多個自動升級通道來進行節點 OS 映像升級。 您可以使用這些通道來控制升級的時機。 建議您加入這些自動升級通道，確保您的節點執行最新的安全性修補程式和更新。 如需詳細資訊，請參閱 AKS 的自動升級節點 OS 映像。

生產工作負載的標準定價層級

最佳做法指引

使用標準定價層級來處理產品工作負載，以獲得更高的叢集可靠性與資源，支援叢集中最多 5,000 個節點，且預設啟用 Uptime SLA。 如果您需要 LTS，建議使用進階層。

Azure Kubernetes Service (AKS) 的標準層會為您的生產工作負載提供從財務支援執行時間達 99.9% 的服務等級協定 (SLA)。 標準層也提供更高的叢集可靠性和資源、支援多達 5,000 個叢集節點，且預設啟用的執行時間 SLA。 如需詳細資訊，請參閱 AKS 叢集管理的定價層。

叢集模式備註：

• AKS Automatic 已預先設定標準層、執行時間 SLA 與 Pod 整備度 SLA。
• 除非你明確選擇標準或高級，否則 AKS 標準版預設為免費版。

LocalDNS 用於 DNS 可靠性

最佳做法指引

在您的節點池啟用 LocalDNS ，以提升 DNS 解析的可靠性，並在短暫 DNS 中斷時維持服務連線。

LocalDNS 會在每個 AKS 節點部署 DNS 代理，提供低延遲且具韌性的 DNS 解析。 透過在本地解決查詢，LocalDNS 減少了對集中式 CoreDNS Pods 的依賴，並避免資料表耗盡，這是高吞吐量環境中 DNS 查詢常見的丟失原因。 LocalDNS 也支援在上游 DNS 無法使用時，提供可設定時效的過時快取回應，幫助在中斷時維持 Pod 連線。 關於設定說明與最佳實務，請參閱 AKS 中的 Local DNS 配置。

叢集模式備註：

• AKS 自動：LocalDNS 是預先設定好的。
• AKS 標準：LocalDNS 為選用，必須明確啟用。

Azure CNI 的動態IP分配

最佳做法指引

設定 Azure CNI 進行動態 IP 分配，以提升 IP 利用率，並防止 AKS 叢集的 IP 耗盡。

對於 AKS 標準，Azure CNI 動態 IP 分配有助於提升 IP 利用率並防止 IP 耗盡。 對於 AKS Automatic，預設的網路路徑是透過 Cilium 支援的 Azure CNI Overlay 管理虛擬網路，並在支援情境下可選擇自訂虛擬網路設定。

Azure CNI 的動態 IP 分配功能會將 pod IP 從與 AKS 叢集子網不同的子網中分配，並提供以下好處：

• 更有效地利用 IP：IP 會從 Pod 子網路動態分配給叢集 Pod。 相較於為每個節點靜態分配 IP 的傳統 CNI 解決方案，此方式可更有效利用叢集中的 IP。
• 可擴充且有彈性：節點和 Pod 子網路均可獨立調整。 在叢集的多個節點集區或部署在相同 VNet 的多個 AKS 叢集都可以共用單一 Pod 子網路。 此外，您也可以為節點集區設定個別 Pod 子網路。
• 高效能：由於網繭已獲指派虛擬網路 IP，因此它們可以直接連線到 VNet 中的其他叢集網繭和資源。 此解決方案可支援大量的叢集，且不會導致效能降低。
• 為 Pod 設定個別 VNet 原則：由於 Pod 具有個別子網路，您可設定不同於節點原則的個別 VNet 原則。 這讓許多有用的情境得以實現，例如只允許 pod 連接網際網路，不允許節點連接;使用 Azure NAT 閘道 固定節點池中 Pod 的來源 IP;以及使用 NSG 來過濾節點池間的流量。
• Kubernetes 網路政策：Azure 網路政策與 Calico 皆可使用此解決方案。

欲了解更多資訊，請參閱 配置 Azure CNI 網路以實現 IP 動態分配及增強子網支援。

v5 SKU VM

最佳做法指引

在更新期間和更新之後使用 v5 VM SKU 可改善效能、降低整體影響，並獲得更可靠的應用程式連線。

如為 AKS 的節點集區，使用具有暫時性 OS 磁碟的 v5 SKU VM，可為 kube 系統的 Pod 提供足夠的計算資源。 如需詳細資訊，請參閱 AKS 大型工作負載效能和調整最佳做法。

請勿使用 B 系列 VM

最佳做法指引

請勿將 B 系列 VM 使用在 AKS 叢集，因為它效能不彰，且不適用於 AKS。

B 系列 VM 的效能不彰，且不適用於 AKS。 反之，我們建議使用 v5 SKU VM。

Azure 進階 SSD

最佳做法指引

使用高級 SSD 在一台虛擬機（VM）中實現 99.9% 可用性。

Azure Premium SSD 管理硬碟提供穩定的亞毫秒磁碟延遲，以及高 IOPS 和吞吐量。 高級 SSD 設計用於提供低延遲、高效能且穩定的磁碟效能給虛擬機。

下列範例 YAML 資訊清單示範進階磁碟的儲存體類別定義：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: premium2-disk-sc
parameters:
   cachingMode: None
   skuName: PremiumV2_LRS
   DiskIOPSReadWrite: "4000"
   DiskMBpsReadWrite: "1000"
provisioner: disk.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true

更多資訊請參閱 使用 Azure Premium SSD v2 磁碟於 AKS。

容器深入解析

最佳做法指引

啟用容器深入解析來監控及診斷容器化應用程式的效能。

Container Insights是Azure 監視器的一項功能，用於收集並分析來自 AKS 的容器日誌。 您可以使用檢視集合和預先建置的活頁簿來分析收集的資料。

叢集模式備註：

• AKS Automatic： Container Insights 預設已啟用於支援的 Azure CLI 和 Azure portal 創建流程中。
• AKS 標準：容器洞察為可選且明確啟用。

您可以使用各種方法，在 AKS 叢集啟用容器深入解析監控。 以下範例說明如何使用 Azure CLI 在現有的 AKS Standard 叢集上啟用容器洞察監控：

az aks enable-addons -a monitoring --name myAKSCluster --resource-group myResourceGroup

如需詳細資訊，請參閱啟用 Kubernetes 叢集的監控。

Azure 原則

最佳做法指引

使用 Azure 原則 為您的 AKS 叢集套用並執行安全與合規要求。

你可以使用 Azure 原則 在 AKS 叢集上套用並執行內建安全政策。 Azure 原則 協助執行組織標準並評估大規模合規性。 安裝 AKS 的 Azure 原則 外掛後，你可以將個別的政策定義或稱為倡議的政策定義群組套用到叢集上。

叢集模式備註：

• AKS Automatic：部署防護機制及基準 Pod 安全性標準已預先設定為強制模式。
• AKS 標準：Azure 原則 與部署防護為可選，且需明確設定。

欲了解更多資訊，請參閱 Secure your AKS clusters with with Azure 原則。

相關內容

本文聚焦於 Azure Kubernetes Service （AKS） 叢集部署的最佳實務與叢集可靠性。 欲了解更多相關主題資訊，請參閱以下文章：

• 什麼是 AKS Automatic？
• AKS 的高可用性和災害復原概觀
• 大規模執行 AKS 叢集
• AKS 叢集的基準架構