在學習 Kubernetes 的過程中,我曾經有一個疑問:「Operator Framework 到底是怎麼運作的?為什麼單純一個 CustomResourceDefinition (CRD) 可以幫助系統管理員完成像 etcd 備份這樣的任務?」
這個問題來自我聽到的其中一個應用:etcd 應用程式往往會搭配一個備份 Operator,讓管理員能透過宣告的方式建立備份,而不需要手動跑指令。但背後的原理是什麼?CRD 與 Operator 是怎麼協同工作的?
這篇文章就以這個實際的疑問為出發點,從案例切入,說明 CRD 與 Operator Framework 如何幫助系統管理員,並用 etcd 備份 作為例子展開。
在原生的 Kubernetes 世界裡,API Server 提供的物件類型有限,例如 Pod、Deployment、Service、ConfigMap 等。但隨著應用越來越複雜,系統管理員往往需要更多「原生」的方式來管理應用程式,例如資料庫叢集、備份排程、快取服務等等。
這時候,CRD (CustomResourceDefinition) 就登場了。它允許我們擴充 Kubernetes API,新增自訂的資源型別。例如:
apiVersion: etcd.database.coreos.com/v1beta2
kind: EtcdBackup
metadata:
name: daily-backup
spec:
clusterName: etcd-cluster
storageType: S3
s3:
path: "s3://my-etcd-backups/2025-08-17/"
透過 CRD,我們可以直接在 Kubernetes 裡操作 EtcdBackup
這樣的物件,就像操作 Pod 一樣:
kubectl get etcdbackup
不過,CRD 本身只是定義一個「新的 API 物件」。如果沒有後端邏輯,它什麼事都不會做。這時候就需要 Controller,也就是 Operator 的核心。
所謂的 Operator,就是 CRD 與對應的 Controller 的組合。
EtcdBackup
。以 Etcd Backup Operator 為例:
kubectl apply -f backup.yaml
,建立一個新的 EtcdBackup
物件。EtcdBackup
建立。etcdctl snapshot save
。這整個過程中,系統管理員只需要寫一個 YAML 檔案,不需要自己打 etcdctl
指令、寫備份腳本或處理重試邏輯。
etcdctl snapshot save
。kubectl get
查詢,並能透過 GitOps 管理。Kubernetes 的設計哲學是 宣告式 (Declarative)。透過 CRD + Operator:
這也是為什麼 Kubernetes 生態系有這麼多 Operator,例如:
如果你想探索更多現成的 Operator,可以到 OperatorHub 查詢。
CRD 提供了擴充 API 的能力,Operator 則賦予這些 API 真正的「行為」。透過 Operator Framework,Kubernetes 管理員能把複雜的運維工作,轉化成簡單的 YAML 宣告。
就像我們今天看到的例子——只要一個 EtcdBackup
的物件,Operator 就會自動完成整個備份流程。這不只是省時省力,更重要的是一致性與可追蹤性,讓基礎架構管理更加可靠。