水平 Pod 自動擴展

在 Kubernetes 中，_HorizontalPodAutoscaler_ 會自動更新工作負載資源 (例如 Deployment 或 StatefulSet)，旨在自動擴展容量以符合需求。

水平擴展意味著增加負載時的應對方式是部署更多 Pod。這與_垂直_擴展不同，垂直擴展在 Kubernetes 中表示為已在工作負載中運行的 Pod 分配更多資源 (例如：記憶體或 CPU)。

如果負載減少，且 Pod 數量高於配置的最小值，HorizontalPodAutoscaler 會指示工作負載資源 (Deployment、StatefulSet 或其他類似資源) 縮減。

Pod 水平自動擴展不適用於無法擴展的物件 (例如：DaemonSet)。

HorizontalPodAutoscaler 作為 Kubernetes API 資源和控制器實現。該資源決定控制器的行為。Pod 水平自動擴展控制器在 Kubernetes 控制平面中運行，會定期調整其目標 (例如 Deployment) 的期望擴展，以符合觀察到的指標，例如平均 CPU 使用率、平均記憶體使用率或您指定的任何其他自訂指標。

這裡有使用 Pod 水平自動擴展的逐步範例。

HorizontalPodAutoscaler 如何運作？

graph BT hpa[HorizontalPodAutoscaler] --> scale[Scale] subgraph rc[Deployment] scale end scale -.-> pod1[Pod 1] scale -.-> pod2[Pod 2] scale -.-> pod3[Pod N] classDef hpa fill:#D5A6BD,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; classDef rc fill:#F9CB9C,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; classDef scale fill:#B6D7A8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; classDef pod fill:#9FC5E8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; class hpa hpa; class rc rc; class scale scale; class pod1,pod2,pod3 pod

圖 1. HorizontalPodAutoscaler 控制 Deployment 及其 ReplicaSet 的擴展

Kubernetes 將 Pod 水平自動擴展實現為間歇性運行的控制迴圈 (它不是連續的過程)。該間隔由傳遞給 kube-controller-manager 的 --horizontal-pod-autoscaler-sync-period 參數設定 (預設間隔為 15 秒)。

在每個週期中，控制器管理器會根據每個 HorizontalPodAutoscaler 定義中指定的指標查詢資源使用率。控制器管理器會找到由 scaleTargetRef 定義的目標資源，然後根據目標資源的 .spec.selector 標籤選取 Pod，並從資源指標 API (用於每個 Pod 的資源指標) 或自訂指標 API (用於所有其他指標) 獲取指標。

  • 對於每個 Pod 的資源指標 (例如 CPU)，控制器會從資源指標 API 中獲取 HorizontalPodAutoscaler 所針對的每個 Pod 的指標。然後，如果設定了目標使用率值，控制器會將使用率值計算為每個 Pod 中容器等效資源請求的百分比。如果設定了目標原始值，則直接使用原始指標值。控制器隨後會計算所有目標 Pod 的使用率或原始值 (取決於指定的目標類型) 的平均值，並產生一個用於擴展期望副本數量的比率。

    請注意，如果某些 Pod 的容器沒有設定相關的資源請求，則該 Pod 的 CPU 使用率將不會被定義，自動擴展器將不會對該指標採取任何動作。請參閱下方的演算法細節章節，以獲取有關自動擴展演算法如何工作的更多資訊。

  • 對於每個 Pod 的自訂指標，控制器功能與每個 Pod 的資源指標類似，只是它處理的是原始值，而不是使用率值。

  • 對於物件指標和外部指標，會獲取一個描述相關物件的單一指標。此指標會與目標值進行比較，以產生如上所述的比率。在 autoscaling/v2 API 版本中，此值在比較之前可以選擇性地除以 Pod 的數量。

HorizontalPodAutoscaler 的常見用途是將其配置為從聚合 API (metrics.k8s.io、custom.metrics.k8s.io 或 external.metrics.k8s.io) 獲取指標。metrics.k8s.io API 通常由名為 Metrics Server 的附加元件提供，需要單獨啟動。有關資源指標的更多資訊，請參閱Metrics Server。

指標 API 支援解釋了這些不同 API 的穩定性保證和支援狀態。

HorizontalPodAutoscaler 控制器會存取支援擴展的相應工作負載資源 (例如 Deployments 和 StatefulSet)。這些資源每個都有一個名為 scale 的子資源，這是一個介面，允許您動態設定副本數量並檢查它們各自的當前狀態。有關 Kubernetes API 中子資源的通用資訊，請參閱Kubernetes API 概念。

演算法細節

從最基本的角度來看，HorizontalPodAutoscaler 控制器是根據期望指標值與當前指標值之間的比率運作的

$$\begin{equation*} desiredReplicas = ceil\left\lceil currentReplicas \times \frac{currentMetricValue}{desiredMetricValue} \right\rceil \end{equation*}$$

例如，如果當前指標值為 200m，而期望值為 100m，則副本數量將加倍，因為 \( { 200.0 \div 100.0 } = 2.0 \)。
如果當前值為 50m，您將使副本數量減半，因為 \( { 50.0 \div 100.0 } = 0.5 \)。如果比率足夠接近 1.0 (在可配置的容忍度內，預設為 0.1)，控制平面會跳過任何擴展動作。

當指定 targetAverageValue 或 targetAverageUtilization 時，currentMetricValue 是透過計算 HorizontalPodAutoscaler 擴展目標中所有 Pod 的給定指標的平均值來獲得的。

在檢查容忍度並決定最終值之前，控制平面還會考慮是否有任何指標遺失，以及有多少 Pod 處於Ready狀態。對於每個 Pod 的資源指標，所有設定了刪除時間戳的 Pod (設定了刪除時間戳的物件正在關閉/移除過程中) 都會被忽略，所有失敗的 Pod 都會被丟棄。對於外部和物件指標，副本計數基於運行中和就緒的 Pod 數量；正在終止但仍處於就緒狀態的 Pod 會繼續計入總數。

如果特定 Pod 遺失指標，它會被暫時擱置；遺失指標的 Pod 將用於調整最終擴展數量。

當基於 CPU 擴展時，如果任何 Pod 尚未準備就緒 (它仍在初始化中，或者可能不健康)_或者_該 Pod 的最近指標點是在其準備就緒之前，則該 Pod 也會被擱置。

由於技術限制，HorizontalPodAutoscaler 控制器無法在決定是否擱置某些 CPU 指標時，精確地確定 Pod 首次準備就緒的時間。相反，如果一個 Pod 尚未就緒，並且自啟動以來在一個短暫的可配置時間窗內轉換為就緒狀態，則控制器會將該 Pod 視為「尚未準備就緒」。此值由 --horizontal-pod-autoscaler-initial-readiness-delay 命令列選項配置，預設為 30 秒。一旦 Pod 準備就緒，如果自啟動以來在一個較長的可配置時間內發生了任何轉換為就緒狀態，則控制器會將其視為首次。此值由 --horizontal-pod-autoscaler-cpu-initialization-period 命令列選項配置，預設為 5 分鐘。

然後，使用上述未擱置或丟棄的剩餘 Pod 來計算 \( currentMetricValue \over desiredMetricValue \) 基本擴展比率。

如果存在任何遺失的指標，控制平面會更保守地重新計算平均值，假設在縮減的情況下這些 Pod 消耗了 100% 的期望值，而在擴展的情況下則消耗了 0%。這會抑制任何潛在擴展的幅度。

此外，如果存在任何尚未就緒的 Pod，且在不考慮遺失指標或尚未就緒的 Pod 的情況下工作負載本會擴展，則控制器會保守地假設這些尚未就緒的 Pod 消耗了 0% 的期望指標，進一步抑制擴展的幅度。

在考慮了尚未就緒的 Pod 和遺失的指標之後，控制器會重新計算使用率比率。如果新的比率反轉了擴展方向，或在容忍度範圍內，則控制器不會採取任何擴展動作。在其他情況下，新的比率將用於決定 Pod 數量的任何更改。

請注意，即使使用新的使用率比率，HorizontalPodAutoscaler 狀態報告的平均使用率_原始_值，也不會將尚未就緒的 Pod 或遺失的指標納入考慮。

如果 HorizontalPodAutoscaler 中指定了多個指標，則會對每個指標進行此計算，然後選擇期望副本計數中最大的一個。如果這些指標中的任何一個無法轉換為期望的副本計數 (例如，由於從指標 API 獲取指標時出錯)，並且可獲取的指標建議縮減，則會跳過擴展。這意味著如果一個或多個指標給出的 desiredReplicas 大於當前值，HPA 仍然能夠擴展。

最後，在 HPA 擴展目標之前，會記錄擴展建議。控制器會考慮可配置時間窗內的所有建議，並選擇該時間窗內的最高建議。您可以使用 --horizontal-pod-autoscaler-downscale-stabilization 命令列選項來配置此值，其預設為 5 分鐘。這意味著縮減將會逐漸發生，以平滑快速波動的指標值的影響。

Pod 就緒狀態與自動擴展指標

HorizontalPodAutoscaler (HPA) 控制器包含兩個命令列選項，它們會影響在 Pod 啟動期間如何從 Pod 收集 CPU 指標

  1. --horizontal-pod-autoscaler-cpu-initialization-period (預設：5 分鐘)

這定義了 Pod 啟動後的時間窗，在此期間其 **CPU 使用率會被忽略**，除非：- Pod 處於 Ready 狀態 **且** - 指標樣本完全是在其處於 Ready 狀態期間取得的。

此命令列選項有助於在 HPA 擴展決策中，**排除**初始化中 Pod (例如：Java 應用程式預熱) **誤導性的高 CPU 使用率**。

  1. --horizontal-pod-autoscaler-initial-readiness-delay (預設：30 秒)

這定義了 Pod 啟動後的一段短暫延遲期，在此期間 HPA 控制器會將目前處於 Unready 狀態的 Pod 視為仍在初始化中，**即使它們之前曾短暫轉換為 Ready 狀態**。

其設計目的是：- 避免將在啟動期間在 Ready 和 Unready 之間快速波動的 Pod 納入考量。- 在 HPA 認為其指標有效之前，確保初始就緒訊號的穩定性。

您只能在叢集範圍內設定這些命令列選項。

Pod 就緒狀態的關鍵行為

  • 如果一個 Pod 處於 Ready 狀態並保持 Ready 狀態，即使在延遲期內，它也可以被計為提供指標。
  • 如果一個 Pod 在 Ready 和 Unready 之間快速切換，則指標會被忽略，直到它被認為是穩定地處於 Ready 狀態。

Pod 就緒狀態的最佳實踐

  • 配置一個 startupProbe，使其在高 CPU 使用率過去之後才通過，或
  • 使用 initialDelaySeconds 確保您的 readinessProbe 僅在 CPU 峰值消退**之後**才報告 Ready。

理想情況下，也應設定 --horizontal-pod-autoscaler-cpu-initialization-period 以**涵蓋啟動持續時間**。

API 物件

HorizontalPodAutoscaler 是 Kubernetes autoscaling API 群組中的一種 API 類型。目前的穩定版本可以在 autoscaling/v2 API 版本中找到，該版本支援根據記憶體和自訂指標進行擴展。在處理 autoscaling/v1 時，autoscaling/v2 中引入的新欄位會作為註解保留。

當您建立 HorizontalPodAutoscaler API 物件時，請確保指定的名稱是有效的DNS 子網域名稱。有關 API 物件的更多細節可以在HorizontalPodAutoscaler 物件中找到。

工作負載擴展的穩定性

當使用 HorizontalPodAutoscaler 管理一組副本的擴展時，由於所評估指標的動態特性，副本數量可能會頻繁波動。這有時被稱為_震盪_或_抖動_。它類似於控制論中的_遲滯_概念。

滾動式更新期間的自動擴展

Kubernetes 允許您對 Deployment 執行滾動式更新。在這種情況下，Deployment 會為您管理底層的 ReplicaSets。當您為 Deployment 配置自動擴展時，您會將 HorizontalPodAutoscaler 綁定到單個 Deployment。HorizontalPodAutoscaler 管理 Deployment 的 replicas 欄位。Deployment 控制器負責設定底層 ReplicaSets 的 replicas，以便它們在發布期間和之後加總到合適的數量。

如果您對具有自動擴展副本數量的 StatefulSet 執行滾動式更新，StatefulSet 會直接管理其 Pod 集 (沒有類似 ReplicaSet 的中間資源)。

資源指標支援

任何 HPA 目標都可以根據擴展目標中 Pod 的資源使用情況進行擴展。在定義 Pod 規格時，應指定 cpu 和 memory 等資源請求。這用於確定資源使用率，並由 HPA 控制器用於擴展目標。要使用基於資源使用率的擴展，請像這樣指定一個指標來源

type: Resource
resource:
  name: cpu
  target:
    type: Utilization
    averageUtilization: 60

使用此指標，HPA 控制器將保持擴展目標中 Pod 的平均使用率在 60%。使用率是資源當前使用量與 Pod 所請求資源之間的比率。有關使用率如何計算和平均的更多詳細資訊，請參閱演算法。

注意

由於所有容器的資源使用量會加總，因此總 Pod 使用率可能無法準確代表單個容器的資源使用情況。這可能導致單個容器以高使用率運行，而 HPA 不會擴展，因為總體 Pod 使用率仍在可接受的範圍內。

容器資源指標

功能狀態： Kubernetes v1.30 [穩定](預設啟用)

HorizontalPodAutoscaler API 也支援容器指標來源，HPA 可以追蹤一組 Pod 中各個容器的資源使用情況，以擴展目標資源。這允許您為特定 Pod 中最重要的容器配置擴展閾值。例如，如果您有一個 Web 應用程式和一個提供日誌記錄的 Sidecar 容器，您可以根據 Web 應用程式的資源使用情況進行擴展，而忽略 Sidecar 容器及其資源使用情況。

如果您修改目標資源以使用具有不同容器集的新 Pod 規格，則如果該新添加的容器也應用於擴展，您應該修改 HPA 規格。如果指標來源中指定的容器不存在或僅存在於部分 Pod 中，則這些 Pod 將被忽略並重新計算建議。有關計算的更多詳細資訊，請參閱演算法。要使用容器資源進行自動擴展，請定義如下指標來源

type: ContainerResource
containerResource:
  name: cpu
  container: application
  target:
    type: Utilization
    averageUtilization: 60

在上述範例中，HPA 控制器會擴展目標，使得所有 Pod 的 application 容器中 CPU 的平均使用率為 60%。

注意

如果您更改 HorizontalPodAutoscaler 正在追蹤的容器名稱，您可以按照特定順序進行更改，以確保在應用更改時擴展仍然可用且有效。在更新定義容器的資源 (例如 Deployment) 之前，您應該更新相關聯的 HPA 以追蹤新舊容器名稱。這樣，HPA 就能夠在整個更新過程中計算擴展建議。

一旦您將容器名稱更改推展到工作負載資源，請透過從 HPA 規格中移除舊容器名稱來進行清理。

依據自訂指標擴展

功能狀態： Kubernetes v1.23 [穩定]

(autoscaling/v2beta2 API 版本之前作為 Beta 功能提供此能力)

只要您使用 autoscaling/v2 API 版本，您就可以配置 HorizontalPodAutoscaler 根據自訂指標 (即非 Kubernetes 或任何 Kubernetes 元件內建的指標) 進行擴展。HorizontalPodAutoscaler 控制器隨後會從 Kubernetes API 查詢這些自訂指標。

有關要求，請參閱指標 API 支援。

依據多個指標擴展

功能狀態： Kubernetes v1.23 [穩定]

(autoscaling/v2beta2 API 版本之前作為 Beta 功能提供此能力)

只要您使用 autoscaling/v2 API 版本，您就可以為 HorizontalPodAutoscaler 指定多個指標進行擴展。然後，HorizontalPodAutoscaler 控制器會評估每個指標，並根據該指標提出新的擴展建議。HorizontalPodAutoscaler 會採用每個指標建議的最大擴展量，並將工作負載設定為該大小 (前提是不大於您配置的整體最大值)。

指標 API 支援

預設情況下，HorizontalPodAutoscaler 控制器從一系列 API 檢索指標。為了使其能夠存取這些 API，叢集管理員必須確保

  • 已啟用API 聚合層。

  • 相應的 API 已註冊

    • 對於資源指標，這是 metrics.k8s.io API，通常由 metrics-server 提供。它可以作為叢集附加元件啟動。

    • 對於自訂指標，這是 custom.metrics.k8s.io API。它由指標解決方案供應商提供的「轉接器」API 伺服器提供。請檢查您的指標管道，看看是否有可用的 Kubernetes 指標轉接器。

    • 對於外部指標，這是 external.metrics.k8s.io API。它可能由上面提供的自訂指標轉接器提供。

有關這些不同指標路徑及其差異的更多資訊，請參閱HPA V2、custom.metrics.k8s.io 和 external.metrics.k8s.io 的相關設計提案。

有關如何使用它們的範例，請參閱使用自訂指標的逐步指南和使用外部指標的逐步指南。

可配置的擴展行為

功能狀態： Kubernetes v1.23 [穩定]

(autoscaling/v2beta2 API 版本之前作為 Beta 功能提供此能力)

如果您使用 v2 HorizontalPodAutoscaler API，您可以使用 behavior 欄位 (請參閱 API 參考) 來配置單獨的擴展和縮減行為。您透過在 behavior 欄位下設定 scaleUp 和/或 scaleDown 來指定這些行為。

擴展策略允許您在擴展時控制副本的變化率。此外，兩個設定可用於防止抖動：您可以指定一個_穩定化時間窗_來平滑副本計數，以及一個容忍度來忽略低於指定閾值的輕微指標波動。

擴展策略

可以在規格的 behavior 部分中指定一個或多個擴展策略。當指定多個策略時，預設會選擇允許最大變更量的策略。以下範例顯示了在縮減時的此行為

behavior:
  scaleDown:
    policies:
    - type: Pods
      value: 4
      periodSeconds: 60
    - type: Percent
      value: 10
      periodSeconds: 60

periodSeconds 表示策略必須在過去多長時間內保持有效。您可以為 periodSeconds 設定的最大值為 1800 (半小時)。第一個策略 _(Pods)_ 允許在一分鐘內最多縮減 4 個副本。第二個策略 _(Percent)_ 允許在一分鐘內最多縮減當前副本數的 10%。

由於預設情況下會選擇允許最大變更量的策略，因此第二個策略僅在 Pod 副本數量超過 40 時使用。當副本數量為 40 或更少時，將應用第一個策略。例如，如果存在 80 個副本，並且目標必須縮減到 10 個副本，那麼在第一步中將減少 8 個副本。在下一次迭代中，當副本數量為 72 時，10% 的 Pod 為 7.2，但該數字會向上取整到 8。在自動擴展器控制器的每個迴圈中，要更改的 Pod 數量會根據當前副本數量重新計算。當副本數量下降到 40 以下時，第一個策略 _(Pods)_ 將被應用，並且每次將減少 4 個副本。

可以透過為擴展方向指定 selectPolicy 欄位來更改策略選擇。將值設定為 Min 將選擇允許副本計數中最小變更的策略。將值設定為 Disabled 會完全禁用該方向的擴展。

穩定化時間窗

當用於擴展的指標持續波動時，穩定化時間窗用於限制副本計數的抖動。自動擴展演算法使用此時間窗來推斷先前的期望狀態，並避免對工作負載擴展進行不必要的更改。

例如，在以下程式碼片段中，為 scaleDown 指定了一個穩定化時間窗。

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300

當指標指示目標應該縮減時，演算法會查看先前計算的期望狀態，並使用指定間隔中的最高值。在上述範例中，將考慮過去 5 分鐘內的所有期望狀態。

這近似於一個滾動最大值，並避免擴展演算法頻繁移除 Pod，結果卻在片刻之後又觸發重新建立等效的 Pod。

容忍度

功能狀態： Kubernetes v1.35 [beta]（預設啟用）

tolerance 欄位配置了指標變化的閾值，防止自動擴展器因低於該值的變化而進行擴展。

此容忍度定義為圍繞期望指標值的變化量，在此變化量以下不會發生擴展。例如，考慮一個配置了目標記憶體消耗為 100MiB 和擴展容忍度為 5% 的 HorizontalPodAutoscaler

behavior:
  scaleUp:
    tolerance: 0.05 # 5% tolerance for scale up

使用此配置，HPA 演算法只會在記憶體消耗高於 105MiB (即：高於目標 5%) 時才會考慮擴展。

如果您未設定此欄位，HPA 會應用預設的叢集範圍容忍度 10%。此預設值可以透過 kube-controller-manager 的 --horizontal-pod-autoscaler-tolerance 命令列引數來更新，適用於擴展和縮減。(您無法使用 Kubernetes API 配置此預設值。)

預設行為

要使用自訂擴展，並非所有欄位都必須指定。只能指定需要自訂的值。這些自訂值會與預設值合併。預設值與 HPA 演算法中的現有行為匹配。

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
    - type: Percent
      value: 100
      periodSeconds: 15
  scaleUp:
    stabilizationWindowSeconds: 0
    policies:
    - type: Percent
      value: 100
      periodSeconds: 15
    - type: Pods
      value: 4
      periodSeconds: 15
    selectPolicy: Max

對於縮減，穩定化時間窗為 _300_ 秒 (如果提供了 --horizontal-pod-autoscaler-downscale-stabilization 命令列選項，則為其值)。縮減只有一個策略，允許移除目前運行中 100% 的副本，這意味著擴展目標可以縮減到允許的最小副本數。對於擴展，沒有穩定化時間窗。當指標指示目標應該擴展時，目標會立即擴展。有 2 個策略，在 HPA 達到穩定狀態之前，每 15 秒最多可以添加 4 個 Pod 或目前運行中 100% 的副本。

範例：變更縮減穩定化時間窗

要提供一個 1 分鐘的自訂縮減穩定化時間窗，以下行為將添加到 HPA

behavior:
  scaleDown:
    stabilizationWindowSeconds: 60

範例：限制縮減速率

要限制 HPA 移除 Pod 的速率為每分鐘 10%，以下行為將添加到 HPA

behavior:
  scaleDown:
    policies:
    - type: Percent
      value: 10
      periodSeconds: 60

為確保每分鐘移除的 Pod 不超過 5 個，您可以添加第二個縮減策略，其固定大小為 5，並將 selectPolicy 設定為 minimum。將 selectPolicy 設定為 Min 意味著自動擴展器選擇影響 Pod 數量最少的策略

behavior:
  scaleDown:
    policies:
    - type: Percent
      value: 10
      periodSeconds: 60
    - type: Pods
      value: 5
      periodSeconds: 60
    selectPolicy: Min

範例：停用縮減

selectPolicy 的值為 Disabled 會關閉指定方向的擴展。因此，為防止縮減，將使用以下策略

behavior:
  scaleDown:
    selectPolicy: Disabled

kubectl 中對 HorizontalPodAutoscaler 的支援

HorizontalPodAutoscaler 像每個 API 資源一樣，受到 kubectl 的標準支援。您可以使用 kubectl create 命令建立新的自動擴展器。您可以透過 kubectl get hpa 列出自動擴展器，或透過 kubectl describe hpa 獲取詳細描述。最後，您可以使用 kubectl delete hpa 刪除自動擴展器。

此外，還有一個特殊的 kubectl autoscale 命令用於建立 HorizontalPodAutoscaler 物件。例如，執行 kubectl autoscale rs foo --min=2 --max=5 --cpu=80% 將為 ReplicaSet _foo_ 建立一個自動擴展器，目標 CPU 使用率設定為 80%，副本數量介於 2 到 5 之間。

隱式維護模式停用

您可以在無需更改 HPA 配置本身的情況下，隱式停用目標的 HPA。如果目標的期望副本計數設定為 0，且 HPA 的最小副本計數大於 0，HPA 將停止調整目標 (並將其自身的 ScalingActive 條件設定為 false)，直到您手動調整目標的期望副本計數或 HPA 的最小副本計數來重新啟用它。

將 Deployments 和 StatefulSets 遷移至水平自動擴展

當 HPA 啟用時，建議從 Deployment 和/或 StatefulSet 的清單(們)中移除 spec.replicas 的值。如果沒有這樣做，每次對該物件應用更改時，例如透過 kubectl apply -f deployment.yaml，這將指示 Kubernetes 將當前 Pod 數量擴展到 spec.replicas 鍵的值。這可能不是期望的，並且在 HPA 啟用時可能會造成困擾，導致震盪或抖動行為。

請記住，移除 spec.replicas 可能會導致 Pod 數量的一次性降級，因為此鍵的預設值為 1 (參考Deployment 副本)。更新後，除 1 個 Pod 之外的所有 Pod 都將開始其終止程序。之後的任何部署應用將正常運行，並根據需要遵守滾動式更新配置。您可以根據修改部署的方式，選擇以下兩種方法之一來避免這種降級

  1. kubectl apply edit-last-applied deployment/<deployment_name>
  2. 在編輯器中，移除 spec.replicas。當您儲存並退出編輯器時，kubectl 會應用更新。此步驟不會對 Pod 數量造成任何更改。
  3. 您現在可以從清單中移除 spec.replicas。如果您使用原始碼管理，也請提交您的更改，或採取任何其他適合您追蹤更新的方式來修改原始碼。
  4. 從現在開始，您可以運行 kubectl apply -f deployment.yaml

當使用伺服器端套用時，您可以遵循轉移所有權的指南，其中涵蓋了此精確使用案例。

接下來

如果您在叢集中配置了自動擴展，您可能還會考慮使用節點自動擴展以確保您運行了正確數量的節點。您還可以閱讀有關_垂直_ Pod 自動擴展的更多資訊。

有關 HorizontalPodAutoscaler 的更多資訊


上次修改時間：2026 年 3 月 15 日下午 3:21 PST：修正：將已棄用的引數 `--cpu-percent` 替換為 `--cpu` (af93a0a732)