水平 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[Horizontal Pod Autoscaler] --> scale[Scale] subgraph rc[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 將用於調整最終的擴縮量。

當基於 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 收集 CPU 指標的方式

  1. `—horizontal-pod-autoscaler-cpu-initialization-period`（預設值：5 分鐘）

這定義了 Pod 啟動後的一段時間視窗，在此期間其**CPU 使用率將被忽略**，除非：- Pod 處於 `Ready` 狀態**並且**- 指標樣本完全是在 Pod 處於 `Ready` 狀態期間採集的。

此標誌有助於 HPA 擴縮決策中**排除初始化 Pod（例如，Java 應用程式預熱）中誤導性的高 CPU 使用率**。

  1. `—horizontal-pod-autoscaler-initial-readiness-delay`（預設值：30 秒）

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

其目的是：- 避免在啟動期間包含在 `Ready` 和 `Unready` 之間快速切換的 Pod。- 確保初始就緒訊號的穩定性，然後 HPA 才認為其指標有效。

關鍵行為

  • 如果 Pod 處於 `Ready` 狀態並保持 `Ready` 狀態，即使在延遲期內，它也可以被計入指標貢獻。
  • 如果 Pod 在 `Ready` 和 `Unready` 之間快速切換，則在它被認為穩定 `Ready` 之前，指標將被忽略。

最佳實踐

如果你的 Pod 在啟動階段有較高的 CPU 使用率

  • 配置一個 `startupProbe`，只有在 CPU 使用率高峰過去後才透過，或者
  • 使用 `initialDelaySeconds` 確保你的 `readinessProbe` 僅在 CPU 峰值消退**後**報告 `Ready`。

理想情況下，還要將 `—horizontal-pod-autoscaler-cpu-initialization-period` 設定為**覆蓋啟動持續時間**。

API 物件

Horizontal Pod Autoscaler 是 Kubernetes `autoscaling` API 組中的一個 API 資源。當前穩定版本可以在 `autoscaling/v2` API 版本中找到，該版本支援基於記憶體和自定義指標的擴縮。在處理 `autoscaling/v1` 時，`autoscaling/v2` 中引入的新欄位將作為註解保留。

建立 HorizontalPodAutoscaler API 物件時，請確保指定的名稱是有效的DNS 子域名。有關 API 物件的更多詳細資訊，請參閱HorizontalPodAutoscaler 物件。

工作負載擴縮的穩定性

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

滾動更新期間的自動擴縮

Kubernetes 允許你對 Deployment 執行滾動更新。在這種情況下，Deployment 會為你管理底層的 ReplicaSet。當你為 Deployment 配置自動擴縮時，你將 HorizontalPodAutoscaler 繫結到一個 Deployment。HorizontalPodAutoscaler 管理 Deployment 的 `replicas` 欄位。Deployment 控制器負責設定底層 ReplicaSet 的 `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 請求資源量之間的比率。有關利用率如何計算和平均的更多詳細資訊，請參閱演算法。

容器資源指標

特性狀態： Kubernetes v1.30 [stable] (預設啟用：true)

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%。

基於自定義指標進行擴縮

特性狀態： Kubernetes v1.23 [stable]

（`autoscaling/v2beta2` API 版本以前將此功能作為 Beta 功能提供）

假設你使用 `autoscaling/v2` API 版本，你可以配置 HorizontalPodAutoscaler 以基於自定義指標（即未內建到 Kubernetes 或任何 Kubernetes 元件中的指標）進行擴縮。HorizontalPodAutoscaler 控制器然後從 Kubernetes API 查詢這些自定義指標。

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

基於多個指標進行擴縮

特性狀態： Kubernetes v1.23 [stable]

（`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 [stable]

（`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）允許在 1 分鐘內最多縮減 4 個副本。第二個策略（Percent）允許在 1 分鐘內最多縮減當前副本的 10%。

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

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

穩定視窗

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

例如，在以下示例片段中，為 `scaleDown` 指定了一個穩定視窗。

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300

當指標表明目標應該縮減時，演算法會檢視之前計算出的期望狀態，並使用指定時間間隔內的最高值。在上面的示例中，將考慮過去 5 分鐘內的所有期望狀態。

這近似於滾動最大值，避免了擴縮演算法頻繁刪除 Pod，只為在片刻之後觸發重新建立等效 Pod。

容差

特性狀態： Kubernetes v1.33 [alpha] (預設啟用：false)

`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 個策略，其中每 15 秒最多可以新增 4 個 Pod 或當前執行副本的 100%，直到 HPA 達到穩定狀態。

示例：更改縮容穩定視窗

要提供一個 1 分鐘的自定義縮容穩定視窗，以下行為將被新增到 HPA：

behavior:
  scaleDown:
    stabilizationWindowSeconds: 60

示例：限制縮容速率

要將 HPA 移除 Pod 的速率限制為每分鐘 10%，以下行為將被新增到 HPA：

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

為確保每分鐘移除的 Pod 數量不超過 5 個，你可以新增第二個縮容策略，固定大小為 5，並將 `selectPolicy` 設定為最小值。將 `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-percent=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`

使用伺服器端應用時，你可以遵循轉移所有權指南，其中涵蓋了此確切用例。

下一步

如果你在叢集中配置自動擴縮，你可能還需要考慮使用節點自動擴縮，以確保你運行了正確數量的節點。

有關 HorizontalPodAutoscaler 的更多資訊

上次修改於 2025 年 5 月 26 日下午 4:34 PST：修訂自動擴縮的最佳實踐 (cfb84597c4)