Kubernetes Operator 開發框架的演進
當台灣的企業將複雜的有狀態應用遷移到 Kubernetes 平台時，標準的 Deployment 與 StatefulSet 往往無法滿足特定應用的運維需求。資料庫叢集需要主從切換、備份恢復與效能調校，訊息佇列需要動態分區管理與資料遷移，監控系統需要自動發現目標與配置同步。這些領域特定的運維知識難以用通用的 Kubernetes 資源表達，Operator 模式應運而生。Operator 將應用的運維專業知識編碼為程式，透過自定義控制器持續監控應用狀態，自動執行部署、升級、備份與故障恢復等操作。
開發 Operator 的核心挑戰在於需要深入理解 Kubernetes API 機制、控制器調和迴圈、資源監聽與事件處理。為了降低開發門檻，Kubernetes 社群開發了多種框架工具。Kubebuilder 與 Operator-SDK 是兩個最主流的選擇，它們都採用 Go 語言開發，提供腳手架工具自動產生專案結構與樣板程式碼。有趣的是，這兩個專案在早期存在高度的功能重疊，社群一度預測它們會合併。然而實際的演進路徑展現了開源協作的智慧，社群選擇將重疊的核心功能統一到 Kubebuilder 專案，而 Operator-SDK 則基於 Kubebuilder 提供更豐富的功能與整合。
Operator-SDK 不僅支援 Go 語言開發 Operator，更透過外掛系統支援多種開發方式。對於熟悉 Ansible 的運維團隊，可以使用 Ansible Playbook 定義 Operator 的調和邏輯，無需撰寫 Go 程式碼。對於已有 Helm Charts 的應用，可以將 Helm 封裝為 Operator，提供更豐富的生命週期管理能力。Java 開發者則可以使用 Quarkus 執行時環境建構基於 Java 的 Operator。這種多語言支援大幅降低了 Operator 開發的技術門檻，讓不同背景的團隊都能將運維知識自動化。更重要的是，Operator-SDK 預設整合了 Operator Lifecycle Manager 與 Operator Hub，簡化了 Operator 的打包、發布與安裝流程。
@startuml
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 14
skinparam minClassWidth 100
package "Kubernetes Operator 開發生態系統" {
component "開發框架層" {
[Kubebuilder\n核心腳手架] as kubebuilder
[Operator-SDK\n多語言支援] as operator_sdk
[Metacontroller\n宣告式控制] as metacontroller
}
component "開發方式層" {
[Go 原生開發] as go_dev
[Ansible Playbook] as ansible_dev
[Helm Charts] as helm_dev
[Java Quarkus] as java_dev
[Webhook 函式] as webhook_dev
}
component "生命週期管理層" {
[OLM\n生命週期管理] as olm
[ClusterServiceVersion\nCSV 描述] as csv
[Operator Hub\n發現與分享] as hub
}
component "Kubernetes 平台層" {
[CRD\n自定義資源] as crd
[Controller Manager\n控制器執行] as controller
[API Server\n狀態管理] as api_server
}
}
operator_sdk --> kubebuilder: 依賴核心功能
operator_sdk --> go_dev: 支援
operator_sdk --> ansible_dev: 外掛支援
operator_sdk --> helm_dev: 外掛支援
operator_sdk --> java_dev: 外掛支援
metacontroller --> webhook_dev: 委託邏輯
operator_sdk --> olm: 預設整合
olm --> csv: 使用
olm --> hub: 發布到
go_dev --> crd: 定義
ansible_dev --> crd: 定義
helm_dev --> crd: 定義
crd --> controller: 註冊
controller --> api_server: 調和狀態
note right of kubebuilder
核心腳手架工具
自動產生專案結構
提供外掛系統
end note
note right of olm
簡化安裝流程
管理依賴關係
自動升級機制
end note
note right of metacontroller
委託控制邏輯
語言無關實作
webhook 整合
end note
@enduml上方架構圖清楚呈現了 Kubernetes Operator 開發生態系統的分層結構。開發框架層提供不同的開發工具選擇，開發方式層支援多種程式語言與技術棧，生命週期管理層處理 Operator 的安裝與升級，最底層則是 Kubernetes 平台提供的基礎設施。這種分層設計讓開發者可以根據團隊技術棧選擇最適合的開發方式。
Operator Lifecycle Manager 的價值
Operator 的強大功能也帶來了部署複雜性。自定義資源定義（CRD）只能在叢集範圍註冊，需要叢集管理員權限。這意味著一般的 Kubernetes 使用者雖然可以管理自己命名空間內的 Deployment 與 Service，卻無法安裝 Operator。這種權限限制在多租戶環境中造成了運維瓶頸，每次團隊需要使用新的 Operator 都必須請求叢集管理員協助安裝。Operator Lifecycle Manager 透過引入中介層解決了這個問題。
OLM 作為叢集級別的服務執行，擁有註冊 CRD 的權限。它引入了 ClusterServiceVersion（CSV）這個特殊的自定義資源，用於描述 Operator 的完整資訊。CSV 包含 Operator 的部署規格、所需的 CRD 定義、權限需求、依賴關係、升級策略等完整的元資料。當叢集管理員建立 CSV 資源時，OLM 會檢查所有的依賴條件是否滿足，包含相依的 CRD 是否已註冊、所需的權限是否可用、儲存類別是否存在等。只有當所有條件都滿足時，OLM 才會實際部署 Operator。
這種設計的優雅之處在於實現了權限的委託模型。叢集管理員只需要審核與核准 CSV 資源，不需要手動執行複雜的安裝步驟。一旦 CSV 被核准，OLM 會自動處理 CRD 註冊、RBAC 角色建立、Operator 部署等所有細節。對於非特權使用者，OLM 提供了請求安裝 Operator 的機制，使用者提交安裝請求後，叢集管理員可以透過審核工作流程核准或拒絕。這種流程化的管理方式既保證了安全性，又提升了使用者體驗。更進一步，OLM 還處理 Operator 的升級管理，透過頻道（Channel）機制讓使用者訂閱不同的發布流，例如穩定版、測試版或最新開發版，實現自動化的版本更新。
Operator Hub 的生態建設
當 Operator 開發完成後，如何讓其他團隊發現與使用這個 Operator 成為重要課題。Operator Hub 提供了類似應用程式商店的體驗，讓開發者能夠輕鬆發布 Operator，讓使用者能夠便捷地搜尋與安裝。Operator Hub 從 Operator 的 CSV 中提取元資料，包含名稱、圖示、描述、版本資訊、維護者聯絡方式、授權條款等，以友善的網頁介面呈現。使用者可以透過關鍵字搜尋、分類瀏覽、熱門排行等方式發現需要的 Operator。
Operator Hub 引入的頻道概念進一步豐富了發布策略。開發者可以為同一個 Operator 建立多個頻道，例如 stable 頻道提供經過充分測試的穩定版本，alpha 頻道提供最新的功能但可能存在問題，beta 頻道則介於兩者之間。使用者根據自己的風險承受度選擇訂閱不同的頻道。當開發者發布新版本到特定頻道時，訂閱該頻道的使用者會自動收到升級通知，可以選擇立即升級或延後處理。這種機制讓 Operator 的持續交付變得簡單可控，開發者可以逐步推出新版本，先在 alpha 頻道測試，穩定後推廣到 beta 與 stable 頻道。
Metacontroller 的宣告式範式
Metacontroller 代表了 Operator 開發的另一種思維模式。Kubebuilder 與 Operator-SDK 要求開發者撰寫完整的控制器程式碼，處理與 Kubernetes API 的互動、實作調和迴圈、管理資源的生命週期。雖然框架提供了腳手架與樣板，但開發者仍需要理解 client-go 函式庫、informer 機制、work queue 管理等複雜概念。Metacontroller 透過委託模式大幅簡化了這個過程。它本身是一個執行在叢集中的控制器管理器，但不是執行硬編碼的控制器邏輯，而是透過 CRD 動態定義控制器行為。
開發者使用 Metacontroller 時只需要實作一個 webhook 端點，這個端點接收描述資源狀態的 JSON 請求，回傳期望建立或刪除的資源定義。Metacontroller 負責所有與 Kubernetes API 的互動，包含監聽資源變化、觸發調和迴圈、呼叫 webhook、應用回傳的資源定義。這種委託模式的最大優勢是語言無關性，webhook 可以用任何能處理 HTTP 與 JSON 的語言實作，無論是 Python、Node.js、Ruby 還是其他語言都可以。webhook 函式甚至可以部署在 Kubernetes 外部，例如 AWS Lambda、Google Cloud Functions 等無伺服器平台。
這種架構特別適合簡單的控制器邏輯或是希望使用特定程式語言的場景。例如資料科學團隊熟悉 Python，可以用 Python 實作 Operator 邏輯而無需學習 Go 語言。DevOps 團隊可以用 Bash 腳本實作簡單的自動化任務。前端團隊可以用 Node.js 實作與前端系統整合的控制器。Metacontroller 降低了 Operator 開發的技術門檻，讓更多團隊能夠將運維知識自動化。
# 自定義資源定義範例：ConfigWatcher
# 監控 ConfigMap 變化並觸發 Pod 重啟
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
# CRD 的完整名稱
# 格式：<plural>.<group>
name: configwatchers.k8spatterns.io
spec:
# CRD 的作用域
# Namespaced: 命名空間級別
# Cluster: 叢集級別
scope: Namespaced
# API 群組名稱
# 用於組織相關的資源
group: k8spatterns.io
# 資源名稱定義
names:
# 資源的種類名稱（單數形式）
kind: ConfigWatcher
# 單數名稱，用於 CLI
singular: configwatcher
# 複數名稱，用於 API 路徑
plural: configwatchers
# 短名稱，用於 kubectl 縮寫
shortNames:
- cw
# 版本定義
versions:
- name: v1
# 是否儲存這個版本（只能有一個版本設為 true）
storage: true
# 是否透過 API 提供這個版本
served: true
# OpenAPI v3 schema 定義
# 定義自定義資源的結構
schema:
openAPIV3Schema:
type: object
# 必要欄位
required:
- spec
properties:
spec:
type: object
# spec 的必要欄位
required:
- configMap
- podSelector
properties:
# 要監控的 ConfigMap 名稱
configMap:
type: string
description: "要監控變化的 ConfigMap 名稱"
# 驗證規則：不能為空
minLength: 1
# Pod 選擇器
# 決定哪些 Pod 需要在 ConfigMap 變化時重啟
podSelector:
type: object
description: "標籤選擇器，用於選擇要重啟的 Pod"
# 允許任意鍵值對
additionalProperties:
type: string
# 至少需要一個標籤
minProperties: 1
---
# ConfigWatcher 資源實例範例
# 監控 webapp-config ConfigMap，當它變化時重啟 webapp Pod
apiVersion: k8spatterns.io/v1
kind: ConfigWatcher
metadata:
# ConfigWatcher 實例名稱
name: webapp-config-watcher
# 命名空間
namespace: production
# 標籤，用於組織與查詢
labels:
app: webapp
managed-by: platform-team
spec:
# 要監控的 ConfigMap 名稱
# 當這個 ConfigMap 的內容發生變化時
# 會觸發 Pod 重啟邏輯
configMap: webapp-config
# Pod 選擇器
# 符合這些標籤的 Pod 會在 ConfigMap 變化時被重啟
# 確保應用程式載入最新的配置
podSelector:
app: webapp
tier: frontend
# ConfigWatcher 的運作流程：
# 1. Operator 監聽 ConfigMap 資源的變化事件
# 2. 當 webapp-config ConfigMap 被修改時
# 3. Operator 查詢所有 ConfigWatcher 資源
# 4. 找到監控 webapp-config 的 ConfigWatcher
# 5. 根據 podSelector 找到符合條件的 Pod
# 6. 刪除這些 Pod 觸發重啟
# 7. ReplicaSet 控制器建立新的 Pod
# 8. 新 Pod 載入最新的 ConfigMap 配置
---
# RBAC 權限配置
# 授予 Operator 管理 ConfigWatcher 資源的權限
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
# 角色名稱
name: config-watcher-operator
namespace: production
rules:
# ConfigWatcher 資源的完整權限
- apiGroups:
# ConfigWatcher 所屬的 API 群組
- k8spatterns.io
# 可操作的資源類型
resources:
- configwatchers
# finalizers 子資源，用於清理邏輯
- configwatchers/finalizers
# status 子資源，用於更新狀態
- configwatchers/status
# 允許的操作
verbs:
- get # 取得單一資源
- list # 列出所有資源
- watch # 監聽資源變化
- create # 建立新資源
- update # 更新現有資源
- patch # 部分更新資源
- delete # 刪除資源
# ConfigMap 資源的讀取權限
# 需要監控 ConfigMap 的變化
- apiGroups:
- "" # 核心 API 群組
resources:
- configmaps
verbs:
- get
- list
- watch
# Pod 資源的刪除權限
# 需要刪除 Pod 以觸發重啟
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- delete
---
# RoleBinding 配置
# 將角色綁定到 Operator 的 ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: config-watcher-operator-binding
namespace: production
subjects:
# 主體：ServiceAccount
- kind: ServiceAccount
name: config-watcher-operator
namespace: production
roleRef:
# 綁定的角色
kind: Role
name: config-watcher-operator
apiGroup: rbac.authorization.k8s.io
彈性擴展的自動化機制
當應用程式的流量隨時間變化時，手動調整 Pod 數量既費時又容易出錯。台灣的電商平台在促銷活動期間流量可能暴增十倍，社群媒體應用在特定時段使用者活躍度顯著提升，企業應用在工作日與週末的負載差異明顯。這些場景都需要動態調整運算資源以維持服務品質。Kubernetes 的彈性擴展機制提供了自動化的解決方案，讓系統能夠根據實際負載自動增減 Pod 數量或調整容器資源配額。
彈性擴展分為水平擴展與垂直擴展兩個維度。水平擴展透過增加或減少 Pod 副本數量來調整總體運算能力，適用於無狀態應用程式，可以線性提升處理能力。垂直擴展則是調整單一 Pod 的資源配額，包含 CPU 與記憶體的請求量與限制，適用於無法透過增加副本提升效能的場景，例如需要大量記憶體的資料處理任務。在實務應用中，這兩種擴展方式常常搭配使用，水平擴展處理突發流量，垂直擴展優化資源利用率。
手動擴展雖然簡單直接，但需要持續監控與人工介入。管理員必須觀察應用程式的效能指標，預測負載變化趨勢，在適當時機執行擴展命令。這種方式的反應速度慢，容易錯過最佳擴展時機，且需要大量人力投入。命令式的手動擴展使用 kubectl scale 命令快速調整副本數量，適合應對緊急狀況或測試場景。宣告式的手動擴展則是修改 Deployment 或 StatefulSet 的 YAML 定義檔，將副本數量變更提交到版本控制系統，透過 GitOps 流程應用到叢集。這種方式確保配置的一致性與可追溯性，但仍需要人工決策與執行。
#!/bin/bash
# 命令式手動擴展範例
# 快速調整應用程式的副本數量
# 擴展 Deployment 到 5 個副本
# kubectl scale 命令會直接修改 Deployment 的 spec.replicas 欄位
# ReplicaSet 控制器會立即建立或刪除 Pod 以達到期望數量
kubectl scale deployment webapp --replicas=5
# 查看擴展後的狀態
# 輸出會顯示期望副本數、當前副本數、就緒副本數
kubectl get deployment webapp
# 輸出範例：
# NAME READY UP-TO-DATE AVAILABLE AGE
# webapp 5/5 5 5 10m
# 縮減到 2 個副本
# 適用於低峰時段節省資源
kubectl scale deployment webapp --replicas=2
# 擴展 StatefulSet
# 注意：縮減 StatefulSet 時不會自動刪除 PVC
# 需要手動清理不再使用的持久卷聲明
kubectl scale statefulset database --replicas=3
# 擴展 ReplicaSet（不建議直接操作）
# 通常應該透過 Deployment 管理
kubectl scale replicaset webapp-7d8f9c5b4d --replicas=4
# 擴展 Job 的並行度
# 注意：使用 --parallelism 而非 --replicas
# parallelism 控制同時執行的 Pod 數量
kubectl scale job batch-processor --parallelism=10
# 條件式擴展
# 只在當前副本數為 3 時才擴展到 5
# --current-replicas 參數提供原子性保證
kubectl scale deployment webapp --replicas=5 --current-replicas=3
# 監控擴展過程
# watch 命令持續顯示 Pod 狀態
watch kubectl get pods -l app=webapp
# 擴展多個資源
# 選擇器可以匹配多個資源
kubectl scale --replicas=3 deployment/webapp deployment/api-server
# 注意事項：
# 1. 命令式擴展不會更新 YAML 檔案
# 2. 從版本控制系統重新應用配置會覆蓋手動變更
# 3. 建議在緊急情況使用，日常管理使用宣告式方式
# 4. StatefulSet 縮減時保留 PVC，避免資料遺失
# 5. 擴展前確認叢集有足夠資源
# 宣告式擴展範例
# 透過修改資源定義檔案實現配置管理
apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp
namespace: production
# 標籤，用於組織與查詢
labels:
app: webapp
version: v2.1.0
spec:
# 副本數量
# 修改這個值並執行 kubectl apply 即可觸發擴展
# 變更會記錄在版本控制系統中，提供完整的審計追蹤
replicas: 5
# 滾動更新策略
# 確保擴展過程不影響服務可用性
strategy:
type: RollingUpdate
rollingUpdate:
# 更新時最多允許多少個 Pod 不可用
maxUnavailable: 1
# 更新時最多允許多少個額外的 Pod
maxSurge: 1
# 選擇器
selector:
matchLabels:
app: webapp
# Pod 模板
template:
metadata:
labels:
app: webapp
version: v2.1.0
spec:
containers:
- name: webapp
image: myregistry.io/webapp:2.1.0
# 資源配置
# 確保每個 Pod 有足夠資源執行
resources:
requests:
cpu: "250m"
memory: "512Mi"
limits:
cpu: "500m"
memory: "1Gi"
# 健康檢查
# 確保只有健康的 Pod 接收流量
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
# 應用配置變更
# kubectl apply -f webapp-deployment.yaml
# 宣告式擴展的優勢：
# 1. 配置儲存在版本控制系統
# 2. 變更有完整的審計追蹤
# 3. 支援程式碼審查流程
# 4. 可以透過 GitOps 自動化部署
# 5. 易於回滾到先前的配置
# 擴展流程：
# 1. 修改 YAML 檔案的 spec.replicas
# 2. 提交變更到 Git
# 3. 透過 CI/CD 流程或手動執行 kubectl apply
# 4. Kubernetes 檢測到配置變更
# 5. ReplicaSet 控制器調整 Pod 數量
# 6. 根據 strategy 配置執行滾動更新
Horizontal Pod Autoscaler 的智慧擴展
Horizontal Pod Autoscaler（HPA）是 Kubernetes 提供的自動水平擴展機制，能夠根據觀察到的指標自動調整 Pod 副本數量。HPA 定期查詢指標伺服器取得 Pod 的資源使用情況，將實際值與目標值比較，計算所需的副本數量並更新對應的 Deployment 或 ReplicaSet。這個調整過程完全自動化，無需人工介入，能夠在幾十秒內響應負載變化。
HPA 支援多種類型的指標。最常用的是資源指標，例如 CPU 使用率與記憶體使用量。當平均 CPU 使用率超過設定閾值時，HPA 會增加副本數量分散負載；當使用率降低時則減少副本節省資源。自定義指標讓 HPA 能夠根據應用程式特定的業務指標進行擴展，例如每秒請求數、訊息佇列長度、活躍連線數等。外部指標則允許根據外部系統的指標擴展，例如雲端負載平衡器的流量統計、資料庫的查詢負載等。透過組合多個指標，HPA 能夠實現更精確的擴展決策。
# Horizontal Pod Autoscaler 配置範例
# 根據 CPU 使用率自動調整 Pod 數量
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
# HPA 名稱
name: webapp-hpa
namespace: production
# 標籤
labels:
app: webapp
spec:
# 擴展目標
# 指定要自動擴展的資源
scaleTargetRef:
# 資源類型
apiVersion: apps/v1
kind: Deployment
# 資源名稱
name: webapp
# 副本數量範圍
# minReplicas: 最小副本數，確保基本可用性
minReplicas: 2
# maxReplicas: 最大副本數，防止資源耗盡
maxReplicas: 10
# 指標定義
# HPA 會根據這些指標計算所需的副本數量
metrics:
# CPU 使用率指標
- type: Resource
resource:
# 指標名稱
name: cpu
# 目標值配置
target:
# 類型：Utilization 表示使用率百分比
# 其他類型：AverageValue（平均值）、Value（總值）
type: Utilization
# 目標 CPU 使用率 70%
# 當平均 CPU 使用率超過 70% 時擴展
# 低於 70% 時縮減（考慮穩定窗口）
averageUtilization: 70
# 記憶體使用率指標
- type: Resource
resource:
name: memory
target:
type: Utilization
# 目標記憶體使用率 80%
averageUtilization: 80
# 自定義指標範例：每秒請求數
# 需要安裝 Metrics Server 與自定義指標 API
- type: Pods
pods:
metric:
# 自定義指標名稱
name: http_requests_per_second
target:
type: AverageValue
# 目標：每個 Pod 平均處理 1000 請求/秒
averageValue: "1000"
# 擴展行為配置（選用）
# 控制擴展與縮減的速度
behavior:
# 擴展行為
scaleUp:
# 穩定窗口：在這段時間內不會再次擴展
stabilizationWindowSeconds: 60
# 擴展策略
policies:
# 每次最多增加 100% 副本（翻倍）
- type: Percent
value: 100
periodSeconds: 60
# 每次最多增加 4 個 Pod
- type: Pods
value: 4
periodSeconds: 60
# 選擇策略：Max 表示使用允許最大擴展的策略
selectPolicy: Max
# 縮減行為
scaleDown:
# 穩定窗口：5 分鐘內不會縮減
# 避免頻繁的擴展與縮減（抖動）
stabilizationWindowSeconds: 300
policies:
# 每次最多減少 10% 副本
- type: Percent
value: 10
periodSeconds: 60
# 每次最多減少 1 個 Pod
- type: Pods
value: 1
periodSeconds: 60
# 選擇策略：Min 表示使用最保守的縮減策略
selectPolicy: Min
# HPA 運作流程：
# 1. HPA 控制器定期（預設 15 秒）查詢指標
# 2. 計算當前指標值與目標值的比率
# 3. 根據比率計算所需副本數：
# desiredReplicas = ceil(currentReplicas * (currentMetric / targetMetric))
# 4. 考慮 minReplicas 與 maxReplicas 限制
# 5. 應用擴展行為策略
# 6. 更新目標資源的 replicas 欄位
# 7. ReplicaSet 控制器建立或刪除 Pod
# 監控 HPA 狀態
# kubectl get hpa webapp-hpa
# 查看 HPA 詳細資訊
# kubectl describe hpa webapp-hpa
# 查看 HPA 事件
# kubectl get events --field-selector involvedObject.name=webapp-hpa
# 注意事項：
# 1. Pod 必須設定 resources.requests 才能使用資源指標
# 2. 需要安裝 Metrics Server
# 3. 自定義指標需要額外的指標收集器
# 4. 避免同時手動調整與自動擴展
# 5. 合理設定穩定窗口避免抖動
# 6. 考慮應用程式啟動時間設定延遲
@startuml
!define PLANTUML_FORMAT svg
!theme _none_
skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 14
skinparam minClassWidth 100
start
:HPA 控制器啟動;
note right
預設每 15 秒執行一次
end note
:查詢 Metrics Server;
:取得 Pod 指標;
note right
CPU 使用率
記憶體使用量
自定義指標
end note
:計算當前平均值;
if (當前值 > 目標值?) then (是)
:計算需要擴展的副本數;
note right
新副本數 = 當前副本數 × (當前值/目標值)
向上取整
end note
if (超過 maxReplicas?) then (是)
:限制為 maxReplicas;
else (否)
endif
:應用擴展策略;
note right
檢查穩定窗口
應用擴展限制
end note
:增加 Pod 副本;
else (否)
if (當前值 < 目標值?) then (是)
:計算需要縮減的副本數;
if (低於 minReplicas?) then (是)
:保持 minReplicas;
else (否)
endif
:應用縮減策略;
note right
檢查穩定窗口
應用縮減限制
end note
:減少 Pod 副本;
else (否)
:維持當前副本數;
endif
endif
:更新 HPA 狀態;
:等待下次檢查週期;
stop
@enduml上方流程圖展示了 HPA 的完整運作邏輯。HPA 控制器定期查詢指標伺服器，計算當前指標值與目標值的比率，決定是否需要擴展或縮減。在執行擴展操作時，會檢查副本數量限制、應用擴展策略、考慮穩定窗口等多重保護機制，確保擴展行為的穩定性與可預測性。
透過 Kubernetes Operator 開發框架與彈性擴展機制，台灣企業能夠建構高度自動化的雲端原生應用平台。從 Kubebuilder 與 Operator-SDK 簡化的開發體驗，到 OLM 與 Operator Hub 便捷的分發機制，再到 HPA 智慧的自動擴展能力，這些技術讓複雜應用的運維知識能夠編碼為程式，實現真正的自動化管理。無論是電商平台需要應對促銷流量、金融系統需要確保高可用性，還是 SaaS 服務需要彈性的資源調配，這些機制都提供了強大的技術支撐。掌握 Operator 開發與彈性擴展的實務技能,將協助團隊在雲端原生時代建構更穩定、更高效的應用系統。
