Kubernetes Operator 開發與 Helm Chart 佈署實戰：從架構到生產環境的完整指南

– 18 分鐘閱讀

在 Kubernetes 生態系統的演進過程中,應用程式的生命週期管理始終是一個複雜且具挑戰性的議題。傳統的佈署方式雖然能夠滿足基本需求,卻難以應對現代雲端原生應用程式對於自動化、可擴展性與高可用性的嚴格要求。Operator Framework 的出現,為這個挑戰提供了一個優雅的解決方案。透過將領域知識編碼為程式邏輯,Operator 能夠像經驗豐富的維運工程師一樣,自動處理應用程式的安裝、升級、備份與故障恢復等複雜任務。

當 Operator Framework 與 Helm Chart 技術相結合時,這種能力得到了進一步的強化。Helm 作為 Kubernetes 生態系統中最成熟的套件管理工具,提供了標準化的應用程式打包與佈署機制。透過 Helm-based Operator,開發者能夠充分利用既有的 Helm Chart 資源,同時獲得 Operator 模式帶來的自動化管理能力。這種結合不僅降低了 Operator 開發的門檻,更讓組織能夠以漸進式的方式引入 Operator 模式,逐步提升基礎設施的自動化水平。

從技術架構的角度來看,Helm-based Operator 透過監控 Custom Resource 的狀態變化,自動觸發對應的 Helm Chart 安裝或更新操作。這種聲明式的管理方式,讓應用程式的期望狀態與實際狀態能夠持續保持一致。當環境中發生變化或故障時,Operator 會自動執行修復動作,確保應用程式始終運行在預期的狀態。這種自癒能力大幅降低了人工介入的需求,提升了系統的可靠性與可維護性。

Operator Framework 的核心概念與技術價值

在深入實作細節之前,我們需要先理解 Operator 模式的核心概念與其在 Kubernetes 生態系統中的定位。Operator 本質上是一種軟體擴充機制,它透過 Custom Resource Definition 擴展 Kubernetes API,讓開發者能夠定義專屬的資源類型與控制邏輯。

從設計理念來看,Operator 模式體現了「基礎設施即程式碼」的思想。傳統的維運工作往往依賴大量的手動操作與文件記錄,這種方式不僅效率低下,更容易因為人為疏失導致系統故障。Operator 將這些維運知識轉化為可執行的程式碼,讓系統能夠自動執行原本需要人工處理的任務。這種轉變不僅提升了維運效率,更確保了操作的一致性與可重複性。

在 Kubernetes 的控制迴圈機制中,Operator 扮演著自定義控制器的角色。它持續監控特定類型的 Custom Resource,當資源狀態發生變化時,Operator 會比較當前狀態與期望狀態的差異,並執行相應的協調動作。這種持續監控與自動修復的機制,是 Kubernetes 聲明式管理模型的核心特性,也是 Operator 能夠實現自動化管理的基礎。

Operator Framework 提供了一套完整的工具鏈來簡化 Operator 的開發過程。其中最重要的工具是 operator-sdk,它能夠自動生成專案架構、管理相依套件,並提供測試與佈署的輔助功能。透過 operator-sdk,開發者可以專注於實作業務邏輯,而不需要處理大量的模板程式碼與基礎設施配置。

從實務應用的角度來看,Operator 特別適合管理有狀態應用程式。資料庫、訊息佇列、分散式儲存系統等有狀態服務,往往需要複雜的初始化、擴容、備份與恢復流程。透過 Operator,這些複雜的操作可以被封裝為簡單的資源宣告,大幅降低了這類應用程式的管理複雜度。

建構 Guestbook Operator 的專案架構

建構一個 Helm-based Operator 的第一步,是使用 operator-sdk 工具生成專案架構。這個工具會自動建立所需的目錄結構、組態檔案與範本程式碼,為後續的開發工作奠定基礎。

在實際操作中,我們需要先確保開發環境已經安裝了 operator-sdk CLI 工具。這個工具提供了完整的 Operator 開發生命週期管理功能,從專案初始化到測試與佈署都能夠得到支援。安裝完成後,我們可以使用以下指令來建立 Guestbook Operator 專案。

# 使用 operator-sdk 建立新的 Operator 專案
# --type=helm 參數指定建立 Helm-based Operator
# --kind=Guestbook 定義 Custom Resource 的類型名稱
# --helm-chart 參數指定要使用的 Helm Chart 來源
operator-sdk new guestbook-operator \
  --type=helm \
  --kind=Guestbook \
  --helm-chart=./guestbook-chart

# 進入專案目錄
cd guestbook-operator

這個指令會建立一個名為 guestbook-operator 的目錄,其中包含了 Operator 運行所需的所有基礎元件。專案架構的設計遵循 Operator 開發的最佳實踐,將不同功能的檔案組織在對應的子目錄中。

生成的專案目錄結構具有明確的組織邏輯。頂層目錄包含了專案的主要組態檔案,如 Dockerfile、Makefile 與專案說明文件。build 目錄存放了容器映像建構所需的檔案,包括 Dockerfile 與相關的建構腳本。deploy 目錄則包含了在 Kubernetes 環境中佈署 Operator 所需的所有資源定義檔案。

helm-charts 目錄是 Helm-based Operator 的核心部分,它包含了原始的 Helm Chart 定義。Operator 在運行時會使用這個 Chart 來安裝與管理目標應用程式。開發者可以根據實際需求修改這個 Chart,添加自定義的組態選項或調整資源定義。

watches.yaml 檔案定義了 Operator 需要監控的資源類型。對於 Helm-based Operator,這個檔案會自動生成,指定 Operator 應該監控對應的 Custom Resource,並在資源狀態變化時觸發 Helm Chart 的安裝或更新操作。

容器映像的建構與推送流程

完成專案架構的建立後,下一步是將 Operator 打包成容器映像。容器化是 Kubernetes 應用程式佈署的基礎,它確保了應用程式能夠在不同環境中以一致的方式運行。

Operator 的容器映像建構過程與一般的應用程式容器化流程類似,但有一些特殊的考量。Operator 需要包含 Helm 二進位檔案以及相關的 Chart 定義,這些元件都需要正確地打包到映像中。幸運的是,operator-sdk 提供了專門的建構指令,能夠自動處理這些細節。

# 設定容器映像儲存庫的環境變數
# 這裡使用 Quay.io 作為容器映像儲存庫
export QUAY_USERNAME="your-quay-username"
export IMAGE_NAME="quay.io/${QUAY_USERNAME}/guestbook-operator"

# 使用 operator-sdk 建構容器映像
# 這個指令會讀取專案目錄中的 Dockerfile
# 並使用 Docker 引擎建構映像
operator-sdk build ${IMAGE_NAME}

# 驗證映像是否建構成功
# 這個指令會列出本地的所有容器映像
# 我們應該能夠看到剛剛建構的 guestbook-operator 映像
docker images | grep guestbook-operator

建構過程會執行 Dockerfile 中定義的所有步驟。典型的 Operator Dockerfile 會從基礎映像開始,安裝必要的相依套件,複製 Operator 的執行檔與 Helm Chart,最後設定容器的啟動指令與環境變數。整個過程可能需要幾分鐘的時間,具體時間取決於網路速度與系統效能。

當建構完成後,我們會得到一個包含完整 Operator 功能的容器映像。這個映像存放在本地的 Docker 環境中,下一步需要將它推送到容器映像儲存庫,讓 Kubernetes 叢集能夠存取。

推送映像到儲存庫需要先進行身份驗證。對於 Quay.io 這類公開的容器映像儲存庫,我們需要使用帳號密碼或存取權杖進行登入。完成驗證後,就可以使用 docker push 指令將映像上傳。

# 設定 Quay.io 的登入密碼
export QUAY_PASSWORD="your-quay-password"

# 登入到 Quay.io 容器映像儲存庫
# --username 參數指定使用者名稱
# --password 參數提供登入密碼
docker login quay.io \
  --username ${QUAY_USERNAME} \
  --password ${QUAY_PASSWORD}

# 推送容器映像到 Quay.io
# 這個過程會將本地建構的映像上傳到遠端儲存庫
# 上傳時間取決於映像大小與網路頻寬
docker push ${IMAGE_NAME}

# 驗證映像是否成功推送
# 登入 Quay.io 網頁介面
# 在 Repository Tags 區域應該能看到新推送的映像標籤
echo "請前往 https://quay.io/repository/${QUAY_USERNAME}/guestbook-operator 確認映像已成功上傳"

推送過程會將映像的各個層級依序上傳到儲存庫。Docker 使用層級化的儲存結構,只有變更的層級需要重新上傳,這能夠大幅節省傳輸時間與頻寬消耗。對於首次推送的映像,所有層級都需要上傳,可能會花費較長時間。

完成推送後,我們可以透過 Quay.io 的網頁介面確認映像是否成功上傳。在儲存庫的標籤列表中,應該能夠看到新建立的映像標籤。這個標籤通常預設為 latest,也可以在建構時透過參數指定特定的版本號。

容器映像建構與推送的整個流程,體現了容器化應用程式佈署的標準模式。透過將應用程式封裝為不可變的容器映像,我們確保了在不同環境中佈署的一致性。這種一致性是實現可靠的持續交付流程的關鍵因素。

Custom Resource Definition 的設計與實作

Custom Resource Definition 是 Operator 模式的核心元件,它定義了 Operator 管理的資源類型。透過 CRD,我們可以擴展 Kubernetes API,引入符合業務需求的自定義資源。

在 Guestbook Operator 的案例中,operator-sdk 會自動生成 CRD 的定義檔案。這個檔案位於 deploy/crds 目錄中,定義了 Guestbook 這個自定義資源的結構與驗證規則。

# 這是自動生成的 CRD 定義檔案
# 位於 deploy/crds/charts.helm.k8s.io_guestbooks_crd.yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  # CRD 的名稱遵循 <複數形式>.<群組名稱> 的格式
  name: guestbooks.charts.helm.k8s.io
spec:
  # 定義 CRD 所屬的 API 群組
  group: charts.helm.k8s.io
  
  # 定義資源名稱的各種形式
  names:
    # API 端點中使用的複數形式
    kind: Guestbook
    # 列表資源的名稱
    listKind: GuestbookList
    # 複數形式,用於 API URL
    plural: guestbooks
    # 單數形式
    singular: guestbook
  
  # 定義資源的作用範圍
  # Namespaced 表示資源屬於特定命名空間
  scope: Namespaced
  
  # 定義支援的 API 版本
  versions:
  - name: v1alpha1
    # 標記此版本為已服務狀態
    served: true
    # 標記此版本為儲存版本
    storage: true
    # 定義資源的結構描述
    schema:
      openAPIV3Schema:
        type: object
        # 定義資源的屬性
        properties:
          spec:
            type: object
            # spec 中的欄位對應 Helm Chart 的 values.yaml
            # 這些欄位用於客製化應用程式的佈署組態

CRD 的定義包含了資源的完整規格說明。metadata 區段定義了資源的基本識別資訊,包括名稱與標籤。spec 區段則詳細描述了資源的結構,包括 API 群組、版本、作用範圍與結構描述。

對於 Helm-based Operator,CRD 的 spec 欄位會自動對映到 Helm Chart 的 values.yaml 檔案。這意味著使用者在建立 Custom Resource 時,可以透過 spec 欄位覆寫 Chart 的預設值,實現客製化的佈署組態。

除了 CRD 定義檔案,operator-sdk 還會生成一個範例的 Custom Resource 檔案。這個檔案展示了如何建立 Guestbook 資源的實例,為使用者提供了參考範本。

# 範例 Custom Resource 定義檔案
# 位於 deploy/crds/charts.helm.k8s.io_v1alpha1_guestbook_cr.yaml
apiVersion: charts.helm.k8s.io/v1alpha1
kind: Guestbook
metadata:
  # 定義資源實例的名稱
  name: example-guestbook
spec:
  # 這裡的每個欄位都對應到 Helm Chart 的 values.yaml
  # 使用者可以根據需求覆寫這些值
  
  # 定義應用程式的副本數量
  replicaCount: 2
  
  # 定義容器映像的組態
  image:
    # 容器映像的儲存庫位置
    repository: gcr.io/google-samples/gb-frontend
    # 映像的拉取策略
    pullPolicy: IfNotPresent
    # 映像的標籤版本
    tag: "v5"
  
  # 定義服務的組態
  service:
    # 服務的類型,可以是 ClusterIP、NodePort 或 LoadBalancer
    type: NodePort
    # 服務暴露的埠號
    port: 80
  
  # 定義資源限制與請求
  resources:
    # 資源限制定義容器可使用的最大資源量
    limits:
      cpu: 100m
      memory: 128Mi
    # 資源請求定義容器啟動時需要的最小資源量
    requests:
      cpu: 100m
      memory: 128Mi

這個範例展示了如何透過 spec 欄位客製化應用程式的佈署組態。使用者可以根據實際需求調整副本數量、容器映像版本、服務類型與資源配額等參數。當這個 Custom Resource 被建立時,Operator 會讀取這些參數,並使用它們來覆寫 Helm Chart 的預設值。

CRD 的設計需要仔細考慮資源的結構與驗證規則。良好的 CRD 設計應該提供清晰的欄位定義、合理的預設值與完善的驗證機制。這不僅能夠提升使用者體驗,更能夠避免因組態錯誤導致的佈署失敗。

RBAC 權限配置的深入解析

在 Kubernetes 環境中,安全性是一個不可忽視的考量。Operator 作為一個控制器,需要適當的權限才能存取與管理 Kubernetes 資源。Role-Based Access Control 提供了細緻的權限管理機制,確保 Operator 只能執行必要的操作。

operator-sdk 會自動生成 RBAC 相關的資源定義檔案,包括 ServiceAccount、Role 與 RoleBinding。這些檔案共同定義了 Operator 的身份與權限範圍。

ServiceAccount 是 Kubernetes 中用於識別 Pod 身份的機制。每個 Operator Pod 都需要一個專屬的 ServiceAccount,用於與 Kubernetes API Server 進行身份驗證。

# ServiceAccount 定義檔案
# 位於 deploy/service_account.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  # ServiceAccount 的名稱
  # 這個名稱會在後續的 RoleBinding 中被引用
  name: guestbook-operator
  # ServiceAccount 所屬的命名空間
  # 應與 Operator 佈署的命名空間一致
  namespace: default

Role 定義了具體的權限規則,指定 Operator 可以對哪些資源執行哪些操作。對於 Helm-based Operator,需要的權限包括管理 Helm Release、讀取 Secret、操作 Pod 等。

# Role 定義檔案
# 位於 deploy/role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: guestbook-operator
  namespace: default
rules:
# 定義對 Guestbook Custom Resource 的完整管理權限
- apiGroups:
  - charts.helm.k8s.io
  resources:
  - guestbooks
  - guestbooks/status
  - guestbooks/finalizers
  verbs:
  - create  # 建立新的 Guestbook 資源
  - delete  # 刪除 Guestbook 資源
  - get     # 讀取 Guestbook 資源的詳細資訊
  - list    # 列出所有 Guestbook 資源
  - patch   # 部分更新 Guestbook 資源
  - update  # 完整更新 Guestbook 資源
  - watch   # 監控 Guestbook 資源的變化

# 定義對 Deployment 資源的管理權限
# Operator 需要這些權限來佈署與管理應用程式的 Deployment
- apiGroups:
  - apps
  resources:
  - deployments
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch

# 定義對 Service 資源的管理權限
# Operator 需要這些權限來建立與管理服務
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch

# 定義對 Pod 資源的讀取權限
# Operator 需要監控 Pod 的狀態來確認應用程式是否正常運行
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch

# 定義對 Secret 資源的讀取權限
# Helm Release 的元資料會儲存在 Secret 中
- apiGroups:
  - ""
  resources:
  - secrets
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch

# 定義對 ConfigMap 資源的管理權限
# 某些應用程式會使用 ConfigMap 來儲存組態資訊
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch

# 定義對 PersistentVolumeClaim 資源的管理權限
# 如果 Helm Chart 包含持久化儲存的定義,需要這些權限
- apiGroups:
  - ""
  resources:
  - persistentvolumeclaims
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch

這個 Role 定義涵蓋了 Operator 運行所需的所有權限。每個規則都明確指定了 API 群組、資源類型與允許的操作動詞。這種細緻的權限控制確保了 Operator 只能執行必要的操作,降低了安全風險。

在實際應用中,如果 Helm Chart 包含額外的資源類型,我們需要手動更新 Role 定義,添加對應的權限規則。例如,如果 Chart 中包含 Job 或 StatefulSet 資源,就需要在 Role 中增加對這些資源的管理權限。

RoleBinding 將 Role 與 ServiceAccount 綁定在一起,完成權限的授予過程。

# RoleBinding 定義檔案
# 位於 deploy/role_binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: guestbook-operator
  namespace: default
# subjects 定義權限的接收者
subjects:
- kind: ServiceAccount
  name: guestbook-operator
  namespace: default
# roleRef 定義要綁定的 Role
roleRef:
  kind: Role
  name: guestbook-operator
  apiGroup: rbac.authorization.k8s.io

RoleBinding 建立了 ServiceAccount 與 Role 之間的關聯。當 Operator Pod 使用這個 ServiceAccount 運行時,它就會獲得 Role 中定義的所有權限。

RBAC 配置的正確性對於 Operator 的運行至關重要。權限不足會導致 Operator 無法執行必要的操作,而過度的權限則可能帶來安全隱患。在配置 RBAC 時,應該遵循最小權限原則,只授予 Operator 完成任務所需的最低權限。

Operator 佈署流程的完整實作

完成所有準備工作後,我們可以開始將 Operator 佈署到 Kubernetes 環境中。這個過程涉及多個步驟,包括建立 CRD、佈署 Operator Pod 與驗證運行狀態。

在佈署之前,我們需要先修改 Operator 的部署定義檔案,指定正確的容器映像位置。這個檔案位於 deploy/operator.yaml,其中包含了 Operator Pod 的完整定義。

# Operator Deployment 定義檔案
# 位於 deploy/operator.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: guestbook-operator
  namespace: default
spec:
  # 定義 Operator 的副本數量
  # 通常設定為 1,因為 Operator 會使用 Leader Election 機制
  replicas: 1
  
  # 定義 Pod 的選擇器
  selector:
    matchLabels:
      name: guestbook-operator
  
  # 定義 Pod 的範本
  template:
    metadata:
      labels:
        name: guestbook-operator
    spec:
      # 指定使用的 ServiceAccount
      serviceAccountName: guestbook-operator
      
      # 定義容器
      containers:
      - name: guestbook-operator
        # 指定容器映像的位置
        # 這裡需要替換為實際推送的映像位置
        image: quay.io/${QUAY_USERNAME}/guestbook-operator:latest
        
        # 定義映像拉取策略
        # Always 表示每次啟動都嘗試拉取最新的映像
        imagePullPolicy: Always
        
        # 定義環境變數
        env:
        # WATCH_NAMESPACE 定義 Operator 監控的命名空間
        # 空值表示監控所有命名空間
        - name: WATCH_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        
        # POD_NAME 儲存 Pod 的名稱
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        
        # OPERATOR_NAME 定義 Operator 的識別名稱
        - name: OPERATOR_NAME
          value: "guestbook-operator"

在實際佈署時,我們需要將 ${QUAY_USERNAME} 替換為實際的使用者名稱。這可以透過手動編輯檔案,或使用 sed 等工具進行自動替換。

# 設定容器映像的完整路徑
export IMAGE_NAME="quay.io/${QUAY_USERNAME}/guestbook-operator:latest"

# 使用 sed 指令替換 operator.yaml 中的映像位置
# 這個指令會在 macOS 與 Linux 系統上正確運作
sed -i.bak "s|REPLACE_IMAGE|${IMAGE_NAME}|g" deploy/operator.yaml

# 確認替換是否成功
grep "image:" deploy/operator.yaml

完成映像位置的設定後,我們可以開始執行佈署流程。首先需要建立 CRD,這會在 Kubernetes API Server 中註冊新的資源類型。

# 建立 Guestbook CRD
# 這個指令會將 CRD 定義提交到 Kubernetes API Server
kubectl apply -f deploy/crds/charts.helm.k8s.io_guestbooks_crd.yaml

# 驗證 CRD 是否建立成功
# 這個指令會列出所有已註冊的 CRD
kubectl get crd | grep guestbooks

# 查看 CRD 的詳細資訊
kubectl describe crd guestbooks.charts.helm.k8s.io

建立 CRD 後,Kubernetes API Server 就能夠接受 Guestbook 類型的資源請求。接下來,我們需要建立 RBAC 相關的資源與 Operator Deployment。

# 建立命名空間
# 這個命名空間將用於隔離 Operator 與其管理的應用程式
kubectl create namespace chapter8

# 佈署 Operator 所需的所有資源
# 包括 ServiceAccount、Role、RoleBinding 與 Deployment
kubectl apply -f deploy/ -n chapter8

# 監控 Operator Pod 的啟動狀態
# -w 參數會持續監控,直到 Pod 進入 Running 狀態
kubectl get pods -n chapter8 -w

# 查看 Operator Pod 的詳細資訊
# 這個指令會顯示 Pod 的事件歷史與狀態資訊
kubectl describe pod -l name=guestbook-operator -n chapter8

# 查看 Operator 的日誌輸出
# 這對於診斷問題非常有用
kubectl logs -f -l name=guestbook-operator -n chapter8

當 Operator Pod 進入 Running 狀態且容器就緒檢查通過時,表示 Operator 已經成功佈署並開始運行。此時,Operator 會開始監控 Guestbook Custom Resource 的變化,等待使用者建立資源實例。

整個佈署流程的關鍵在於確保各個元件的正確配置與順序。CRD 必須在 Operator 之前建立,因為 Operator 的啟動過程會驗證 CRD 的存在。RBAC 資源也需要在 Operator Pod 啟動前建立,否則 Pod 會因為缺乏必要的權限而無法正常運行。

應用程式佈署與生命週期管理

當 Operator 成功運行後,我們可以透過建立 Custom Resource 來觸發應用程式的佈署。這個過程展示了 Operator 模式的核心價值,將複雜的佈署流程封裝為簡單的資源宣告。

建立 Guestbook Custom Resource 會觸發 Operator 執行一系列的協調動作。Operator 會讀取 CR 中定義的 spec 欄位,使用這些值來覆寫 Helm Chart 的預設組態,然後執行 Helm 安裝操作。

# 建立 Guestbook Custom Resource
# 這會觸發 Operator 安裝 Guestbook 應用程式
kubectl apply -f deploy/crds/charts.helm.k8s.io_v1alpha1_guestbook_cr.yaml -n chapter8

# 監控應用程式 Pod 的建立過程
# Operator 會根據 CR 的定義建立對應的 Deployment
# 這些 Deployment 會創建實際運行應用程式的 Pod
kubectl get pods -n chapter8 -w

# 查看建立的所有資源
# 這個指令會顯示 Deployment、Service、ConfigMap 等所有資源
kubectl get all -n chapter8

# 驗證 Helm Release 是否建立成功
# Operator 會使用 Helm 來管理應用程式
# 我們可以透過 helm list 指令查看 Release 的狀態
helm list -n chapter8

執行這些指令後,我們應該能夠看到 Guestbook 應用程式的各個元件逐步建立。Operator 會先建立 Deployment,然後建立 Service 與其他相關資源。整個過程完全自動化,使用者只需要建立一個簡單的 CR 即可。

在 Helm 輸出中,我們會看到一個名為 example-guestbook 的 Release,狀態為 deployed。這個 Release 包含了 Guestbook 應用程式的所有 Kubernetes 資源,由 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 16
skinparam minClassWidth 100

title Operator 佈署與應用程式管理流程

start

:開發者建立 Custom Resource;
note right
  定義應用程式的
  期望狀態與組態參數
end note

:Operator 監控到 CR 變化;
note right
  透過 Watch 機制
  即時感知資源變化
end note

:讀取 CR 規格定義;
note right
  解析 spec 欄位
  取得組態參數
end note

:準備 Helm Chart 參數;
note right
  使用 CR 的 spec
  覆寫 Chart 預設值
end note

:執行 Helm 安裝操作;
note right
  呼叫 Helm API
  佈署應用程式資源
end note

:建立 Kubernetes 資源;
note right
  包括 Deployment
  Service 與 ConfigMap
end note

:監控應用程式狀態;
note right
  持續檢查 Pod
  與服務的健康狀態
end note

if (狀態符合預期?) then (是)
  :更新 CR Status 為 Ready;
  note right
    記錄成功佈署
    的狀態資訊
  end note
else (否)
  :執行修復動作;
  note right
    根據錯誤類型
    執行對應的處理
  end note
  
  :重新嘗試協調;
  note right
    進入下一個
    協調循環
  end note
endif

:持續監控與維護;
note right
  確保應用程式
  始終處於期望狀態
end note

stop

@enduml

這個流程圖清楚地展示了 Operator 如何管理應用程式的完整生命週期。從使用者建立 Custom Resource 開始,Operator 會自動執行一系列的協調動作,包括讀取組態、準備參數、執行 Helm 安裝、監控狀態與處理異常。整個過程完全自動化,體現了 Operator 模式的核心價值。

當應用程式成功佈署後,Operator 會持續監控其狀態。如果應用程式因為某些原因偏離了期望狀態,例如 Pod 被意外刪除或組態被修改,Operator 會自動執行修復動作,將應用程式恢復到正確的狀態。這種自癒能力大幅提升了系統的可靠性。

除了初始佈署,Operator 也能夠處理應用程式的更新與刪除操作。當使用者修改 CR 的 spec 欄位時,Operator 會檢測到變化並執行 Helm 升級操作。當 CR 被刪除時,Operator 會執行 Helm 解除安裝操作,清理所有相關的資源。

# 更新 Guestbook 應用程式的組態
# 修改 CR 檔案中的 spec 欄位,例如調整副本數量
# 然後重新套用 CR
kubectl apply -f deploy/crds/charts.helm.k8s.io_v1alpha1_guestbook_cr.yaml -n chapter8

# 監控更新過程
# Operator 會執行滾動更新,確保服務不中斷
kubectl get pods -n chapter8 -w

# 查看 Helm Release 的歷史版本
# 這個指令會顯示所有的升級記錄
helm history example-guestbook -n chapter8

# 如果需要回滾到先前的版本
# 可以使用 helm rollback 指令
helm rollback example-guestbook 1 -n chapter8

# 刪除 Guestbook 應用程式
# 刪除 CR 會觸發 Operator 執行清理操作
kubectl delete -f deploy/crds/charts.helm.k8s.io_v1alpha1_guestbook_cr.yaml -n chapter8

# 驗證資源是否已清理
# 所有由 Helm Release 建立的資源都應該被刪除
kubectl get all -n chapter8

這些操作展示了 Operator 如何簡化應用程式的生命週期管理。使用者不需要直接操作底層的 Kubernetes 資源,只需要透過修改或刪除 Custom Resource,Operator 就會自動執行相應的操作。這種抽象層次的提升,讓複雜的維運任務變得簡單且可靠。

技術挑戰與實踐經驗總結

在實際開發與佈署 Kubernetes Operator 的過程中,會遇到各種技術挑戰。理解這些挑戰並掌握相應的解決策略,對於成功實施 Operator 模式至關重要。

第一個常見的挑戰是 RBAC 權限配置的完整性。Helm Chart 可能包含各種不同類型的資源,而這些資源的類型可能會根據組態值動態變化。例如,當啟用持久化儲存時,Chart 會建立 PersistentVolumeClaim 資源。如果 Role 定義中沒有包含對 PVC 的管理權限,Operator 在嘗試建立這些資源時就會遇到權限錯誤。

解決這個問題的策略是仔細檢查 Helm Chart 的範本定義,識別所有可能建立的資源類型,然後確保 Role 定義涵蓋所有這些資源。在實際操作中,可以先在測試環境中使用較為寬鬆的權限配置,觀察 Operator 實際需要存取哪些資源,然後根據實際需求調整 Role 定義。

第二個挑戰是容器映像的版本管理。在開發過程中,我們可能會頻繁地更新 Operator 的程式碼並重新建構映像。如果每次都使用相同的標籤,可能會遇到映像快取導致的問題。Kubernetes 的 imagePullPolicy 預設行為是,如果本地已有相同標籤的映像,就不會重新拉取。

針對這個問題,建議在開發階段使用 imagePullPolicy: Always 策略,確保每次都拉取最新的映像。在生產環境中,則應該使用明確的版本標籤,例如使用 Git commit hash 或語義化版本號,避免映像版本的混淆。

第三個挑戰是 Operator 的錯誤處理與回復機制。當 Helm 安裝或升級操作失敗時,Operator 需要能夠正確地處理錯誤,並在條件允許時重試操作。Helm-based Operator 的預設行為是在遇到錯誤時持續重試,但這可能會導致大量無效的 API 請求。

改善錯誤處理的方法包括實作指數退避策略,在重試之間增加等待時間,以及在 Custom Resource 的 Status 欄位中記錄錯誤資訊,讓使用者能夠了解失敗的原因。對於某些不可恢復的錯誤,Operator 應該停止重試,並透過事件或狀態更新通知使用者。

第四個挑戰是多租戶環境中的資源隔離。在共享的 Kubernetes 叢集中,不同的團隊可能會使用相同的 Operator 來管理各自的應用程式實例。確保這些實例之間的隔離性,避免互相干擾,是一個重要的考量。

實現資源隔離的策略包括使用命名空間來分隔不同的應用程式實例,配置適當的資源配額與限制,以及在 Operator 的設計中考慮多租戶的需求。對於需要共享資源的場景,可以使用標籤與選擇器來實現精細的資源管理。

第五個挑戰是 Operator 的可觀測性。在生產環境中,我們需要能夠監控 Operator 的運行狀態,快速診斷與解決問題。這需要實作完善的日誌記錄、指標收集與追蹤機制。

提升可觀測性的方法包括使用結構化日誌格式,記錄關鍵操作的執行過程與結果,暴露 Prometheus 格式的指標,以及整合分散式追蹤系統。透過這些機制,維運人員能夠全面了解 Operator 的運行狀況,快速定位問題的根源。

從實踐經驗來看,成功實施 Operator 模式需要對 Kubernetes 架構有深入的理解,熟悉 Helm 的運作機制,並掌握良好的軟體工程實踐。投資於完善的測試與文件,能夠大幅降低後續的維護成本,提升系統的可靠性與可維護性。

在台灣的技術環境中,Operator 模式正逐漸被更多的組織採用。從金融服務到電子商務,從物聯網到人工智慧,各個產業都在探索如何利用 Operator 來簡化複雜應用程式的管理。掌握 Operator 開發技術,不僅能夠提升個人的技術能力,更能夠為組織帶來實質的價值。

Kubernetes Operator 與 Helm Chart 的結合,代表了雲端原生應用程式管理的先進實踐。透過將維運知識編碼為可執行的程式邏輯,Operator 實現了真正的自動化管理,讓應用程式能夠自主地維持健康狀態。從專案初始化到生產環境佈署,從日常維運到故障恢復,Operator 模式為整個生命週期提供了一致且可靠的管理框架。隨著 Kubernetes 生態系統的持續發展,Operator 模式將會在更多場景中發揮關鍵作用,成為雲端原生時代不可或缺的技術基礎。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。