今天是第 21 天，想和大家聊聊 Operator。
在我過去的架構經驗裡，曾實際使用過幾種 Operator：

• Strimzi Operator：用來管理 Kafka，簡化叢集部署、升級與維護。
• Flink Operator：協調資料流作業，讓 Flink Job 的生命週期管理自動化。
• GCP Managed Prometheus：雖然是雲端託管，但底層仍延伸自 Operator 模型，幫助管理監控資源。

傳統的 Kubernetes 主要處理已被定義的資源，例如 Deployment、Service、ConfigMap 等；
而 Operator 的出現，則讓服務中的各種元件可以被抽象成 Kubernetes 資源，並透過 Controller 自動執行部署、擴縮、升級或錯誤修復等操作。
換句話說，Operator 將「運維知識」寫進程式碼，使系統管理可以像操作 Kubernetes 原生資源一樣簡單、可重複且可觀察。

這種邏輯通常由一個「控制迴圈（Reconcile Loop）」實現，它會持續觀察 CR 的期望狀態與實際狀態，並自動調整至一致。

那麼，Operator 是什麼？

Operator 是透過 Kubernetes 的 CRD（Custom Resource Definition）API，讓自定義資源能以 Kubernetes 原生資源的形式在叢集中運行的控制器。

簡單來說，我們透過 apiVersion: "apiextensions.k8s.io/v1" 和 kind: "CustomResourceDefinition" 告訴 Kubernetes：

「我想新增一種新的資源型別，並讓控制器負責協調它的生命週期。」

舉例來說，Flink Operator 的 CRD 定義如下：

# Generated by Fabric8 CRDGenerator, manual edits might get overwritten!
apiVersion: "apiextensions.k8s.io/v1"
kind: "CustomResourceDefinition"
metadata:
  name: "flinkbluegreendeployments.flink.apache.org"
spec:
  group: "flink.apache.org"
  names:
    kind: "FlinkBlueGreenDeployment"
    plural: "flinkbluegreendeployments"
    shortNames:
    - "flinkbgdep"
    singular: "flinkbluegreendeployment"
  scope: "Namespaced"
  versions:
  - name: v1alpha1
    served: true
    storage: true
    additionalPrinterColumns:
    - name: Status
      type: string
      description: "Deployment status"
      jsonPath: .status.state

從這份定義可以看出，每個自訂資源都會對應一組 Schema 與欄位規格，Operator 則根據這些欄位實作具體的行為邏輯。
例如 Flink Operator 就會監控該資源的狀態，並自動完成 Job 的部署、升級和回滾等操作。

👉 Flink Kubernetes Operator CRD 參考

CRD 與 Operator 的實務查詢

在實際操作與設定 CRD 時，最讓人困擾的往往是 YAML 的階層結構以及 各欄位的定義與含義。
此時，我們可以透過官方文件或 Kubernetes CLI 的方式，快速確認設定細節。

Flink Operator 參考

Flink CRD Reference

FlinkDeployment

Class: org.apache.flink.kubernetes.operator.crd.FlinkDeployment
Description: 表示 Application 與 Session 部署的自訂資源

Strimzi Operator 參考

Strimzi Kafka CRD Reference

Kafka

Schema Reference: Kafka

KafkaSpec

Schema Reference: KafkaSpec
用於 Kafka 自訂資源中，定義叢集的詳細配置，包括 broker、topic、listener、storage 等層級設定。
Strimzi 文件會將下層欄位與相關資源進行連結，使查詢更直觀。

使用 kubectl explain 逐層探索 CRD 結構

除了官方文件，也可以直接透過 CLI 查詢 CRD 的欄位結構。這裡以 FlinkDeployment 為例：

# 查詢 FlinkDeployment 自訂資源
kubectl explain flinkdeployment

示意輸出：

KIND:     FlinkDeployment
VERSION:  flink.apache.org/v1alpha1

DESCRIPTION:
     Custom resource that represents both Application and Session deployments.

FIELDS:
   apiVersion   <string>
   kind         <string>
   metadata     <object>
   spec         <object>
   status       <object>

接著查下一層 spec：

kubectl explain flinkdeployment.spec

示意輸出：

FIELD:    spec <object>
DESCRIPTION:
     Spec that describes a Flink application or session cluster deployment.

FIELDS:
   flinkVersion    <string>
   jobSpec         <object>
   serviceAccount  <string>
   ...

再查更深一層，例如 jobSpec：

kubectl explain flinkdeployment.spec.jobSpec

示意輸出：

FIELD:    jobSpec <object>
DESCRIPTION:
     Specification of the Flink job to deploy in the cluster.

FIELDS:
   parallelism     <integer>
   jarURI          <string>
   args            <[]string>
   ...

這種方式能 逐層探索 CRD 結構，在修改 Helm value 或撰寫 YAML 時尤其實用，能避免層級錯誤或漏填必需欄位。

了解 Operator 的運作方式與 API reference，對於除錯特別關鍵。
我曾遇過 Flink Operator 在 Application Mode 支援 jarURI: local:/// 指定本地 Jar，但在 Session Mode 中卻未實現這項功能。

若對 CRD 欄位與背後邏輯不熟悉，很容易誤以為兩種模式可共用設定，導致部署失敗或 Job 無法啟動。
透過查閱官方 reference 或使用 kubectl explain 逐層探索，就能明確知道哪些欄位可用、哪些尚未實作，快速釐清問題根源。

這正是為什麼熟悉 CRD 結構與 Operator 行為，是每位 DevOps 或資料平台工程師的基本功。

雖然 Operator 底層機制複雜，整合多種資源與邏輯，但對使用者而言依然直觀。
它讓我們不再侷限於通用資源（如 Deployment、StatefulSet），而能針對特定服務建立專屬的 Kubernetes 資源，進一步提升自動化與一致性。

以 Flink 為例，在 Session Cluster 模式中，任務被抽象成 FlinkSessionJob；
開發者專注於邏輯與參數，部署與監控則由 Operator 全權處理。
同樣地，Strimzi Kafka Operator 透過 KafkaNodePool 與 KafkaTopic 等資源，讓叢集與主題的管理進入 Kubernetes 資源層級，真正實現自動化與可觀察性。

總結來說，Operator 不只是自動化工具，更是一種讓「服務模組化」的實踐方式。它讓 Kubernetes 不再只是容器管理平台，而成為能自我協調、持續演進的系統基礎。

小結

今天介紹了 Operator 的基本概念與實務應用，主要包含以下幾個重點：

• Operator 的角色與價值：透過 CRD（CustomResourceDefinition）將自訂服務抽象為 Kubernetes 資源，讓部署、升級、監控都能自動化。
• 常見實例：如 Flink Operator、Strimzi Kafka Operator、GCP Managed Prometheus，都在各自領域中實現自動化協調與生命週期管理。
• CRD 結構探索與除錯方法：可利用官方 reference 或 kubectl explain 指令，逐層理解 CRD 的欄位與邏輯。
• 實際應用場景：以 Flink 與 Kafka 為例，Operator 將應用層與維運層清楚分離，使開發者能專注於業務邏輯，而運維則交由控制器自動完成。

總結來說，Operator 的價值在於讓「服務的行為」與「基礎設施管理」完美結合。
它讓 Kubernetes 不再僅僅是容器的管理平台，而成為能自我協調、持續演進的系統基礎。
隨著越來越多雲端與資料平台服務採用 Operator 模型，理解它的運作邏輯與設計哲學，已成為現代 DevOps 工程師的必修課題。

希望今天的分享，能讓大家對 Operator 的設計思維與實務應用 有更清晰的理解，
也能在未來面對不同雲端架構時，更從容地運用這項強大的 Kubernetes 擴展機制。

謝謝各位的閱讀，祝大家中秋佳節愉快，我們明天見！