Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

はじめに — Operatorは一体何を自動化するのか

Kubernetesをある程度触ったことがある人なら、「Operator」という言葉を数えきれないほど聞いたはずです。ところが「Operatorとは何か」と問われると、「CRDとコントローラー」という抽象的な答えしか返ってきません。定義としては正しいのですが、それが実際に何の問題を解決するのかは伝わってきません。

この記事は定義ではなく事例からアプローチします。データベース、メッセージング、キャッシュ、監視、証明書、シークレット、GitOps、バックアップ、サービスメッシュ、機械学習まで — 現場で最も広く使われるOperatorを領域別に整理し、それぞれが**どんな運用労働をコードに置き換えたのか**を具体的に示します。このカタログを読み終えれば、「ああ、Operatorはこういうところに使うのか」という感覚がつかめるはずです。

核心から言うと、Operatorの本質は**人間のオペレーター(operator)の知識をコードに移したもの**です。「Postgresのマスターが死んだらレプリカを昇格させ、DNSを更新し、バックアップを確認する」といった手順を、人間が深夜に起きて行う代わりに、コントローラーがreconcileループで自動的に行います。だからこそ、データベースやメッセージブローカーのように**状態を持ち、運用手順が複雑なシステム**ほど、Operatorの価値が大きくなります。

Operatorの基本動作原理(3分の復習)

本格的な事例に入る前に、すべてのOperatorが共有する動作原理を短くまとめます。

ユーザーがCR(Custom Resource)を宣言

+------------------------+

| Operator(コントローラー)|

| reconcileループ |

| desired vs actual 比較 |

+-----------+------------+

v 足りないものを作成/修正/削除

+------------------------+

| StatefulSet / Service |

| ConfigMap / PVC / Job |

| (実際のK8sリソース) |

+------------------------+

ユーザーは「Postgresクラスタ、レプリカ3個、バージョン16、毎日バックアップ」という**望ましい状態(desired state)**だけを宣言します。Operatorは現在の状態(actual state)を観察し、両者の差を埋める行動をします。このループが冪等(idempotent)に、繰り返し回りながらシステムを宣言された状態へ収束させます。

このモデルが強力な理由は**障害復旧がタダで付いてくる**からです。レプリカが死んでactualが2個になると、次のreconcileで差を発見し、再び3個にします。人間の介入は不要です。

1. データベース — Operatorが最も輝く領域

ステートフルなデータベースはOperatorのキラーアプリケーションです。バックアップ、復元、フェイルオーバー、スケール、バージョンアップグレード — すべて繊細で危険な運用作業であり、まさにそれゆえに自動化の価値が最も大きくなります。

CloudNativePG (PostgreSQL)

CloudNativePGはCNCFサンドボックスプロジェクトで、「Kubernetesネイティブに」Postgresを運用するよう設計されています。StatefulSetを使わずPodを直接管理する点が特徴で、これはフェイルオーバー時のより精密な制御のためです。

apiVersion: postgresql.cnpg.io/v1

kind: Cluster

metadata:

spec:

instances: 3

imageName: ghcr.io/cloudnative-pg/postgresql:16.3

storage:

size: 100Gi

backup:

barmanObjectStore:

destinationPath: s3://my-backups/pg-prod

s3Credentials:

accessKeyId:

key: ACCESS_KEY_ID

secretAccessKey:

key: SECRET_ACCESS_KEY

retentionPolicy: "30d"

この一枚のYAMLが自動化するもの:プライマリ1台 + レプリカ2台構成、ストリーミングレプリケーション設定、プライマリ障害時の自動フェイルオーバー(レプリカ昇格)、S3への継続的バックアップ(WALアーカイブ)、30日保持ポリシー。人間が手で行っていた全手順が宣言に変わります。

Zalando Postgres Operator

Zalandoが自社の数千個のPostgresクラスタを運用しながら作ったOperatorです。Patroni(HAソリューション)を内蔵し、マニフェストが簡潔なのが利点です。

apiVersion: acid.zalan.do/v1

kind: postgresql

metadata:

spec:

teamId: "acid"

numberOfInstances: 2

postgresql:

version: "16"

volume:

size: 10Gi

Vitess (MySQLシャーディング)

VitessはMySQLを水平シャーディングしてペタバイト級に拡張するシステムで、YouTubeで始まりました。Vitess OperatorはシャードやセルやタブレットといったVitess固有の概念をCRDとして公開します。単一MySQLでは対応できない規模で輝きます。

2. メッセージング — Strimzi (Apache Kafka)

Kafkaを直接運用したことがある人は分かります。ブローカー、ZooKeeper(またはKRaft)、トピック、パーティション、リバランス、ローリングアップグレード — どれ一つ簡単なものはありません。StrimziはこのすべてをCRDに抽象化します。

apiVersion: kafka.strimzi.io/v1beta2

kind: Kafka

metadata:

spec:

kafka:

version: 3.9.0

replicas: 3

listeners:

- name: tls

port: 9093

type: internal

tls: true

config:

offsets.topic.replication.factor: 3

min.insync.replicas: 2

storage:

type: persistent-claim

size: 100Gi

entityOperator:

topicOperator: {}

userOperator: {}

興味深い点は、Strimziが**Operatorの中にさらに別のOperatorを抱える**ことです。Topic OperatorとUser Operatorがそれで、トピックすらCRDで宣言します。

apiVersion: kafka.strimzi.io/v1beta2

kind: KafkaTopic

metadata:

labels:

strimzi.io/cluster: my-cluster

spec:

partitions: 12

replicas: 3

config:

retention.ms: 604800000

トピック作成をGitOpsで管理できるようになります。「トピック追加 = PRマージ」になります。

3. キャッシュ — Redis Operator

Redisも単独インスタンスを超えてSentinelベースのHAやClusterモードのシャーディングに進むと運用が急激に複雑になります。複数のRedis Operator(例:Spotahome、OT-CONTAINER-KIT)がこれを自動化します。

apiVersion: databases.spotahome.com/v1

kind: RedisFailover

metadata:

spec:

sentinel:

replicas: 3

redis:

replicas: 3

storage:

persistentVolumeClaim:

metadata:

spec:

accessModes: ["ReadWriteOnce"]

resources:

requests:

storage: 10Gi

Sentinel3台がマスターを監視し、障害を検知するとレプリカを昇格させ、アプリケーションはSentinelに問い合わせて新しいマスターを見つけます。このフェイルオーバーオーケストレーション全体をOperatorが担います。

4. 監視 — Prometheus Operator

Prometheus Operatorは最も広く使われるOperatorの一つです。kube-prometheus-stackの中核として、Prometheus設定ファイルを直接いじる代わりにCRDで監視対象を宣言させます。

apiVersion: monitoring.coreos.com/v1

kind: ServiceMonitor

metadata:

labels:

release: kube-prometheus-stack

spec:

selector:

matchLabels:

app: my-app

endpoints:

- port: metrics

interval: 30s

path: /metrics

ServiceMonitorを作るとOperatorがPrometheusのscrape設定を自動更新します。アラートルールもPrometheusRule CRDで宣言します。

apiVersion: monitoring.coreos.com/v1

kind: PrometheusRule

metadata:

spec:

groups:

- name: my-app

rules:

- alert: HighErrorRate

expr: rate(http_requests_total{code=~"5.."}[5m]) > 0.05

for: 10m

labels:

severity: critical

annotations:

summary: "5xx error rate is high"

アラートルールがコードでバージョン管理され、アプリケーションのデプロイとともにアラート設定が付いていくパターンが可能になります。

5. 証明書 — cert-manager

cert-managerはTLS証明書の発行・更新・配布を自動化します。Let's Encrypt(ACME)、Vault、社内CAなど多様な発行者をサポートし、証明書の有効期限前の自動更新が核心的価値です。

apiVersion: cert-manager.io/v1

kind: Certificate

metadata:

spec:

secretName: example-tls-secret

dnsNames:

- app.example.com

issuerRef:

kind: ClusterIssuer

「証明書の更新を忘れてサイトが落ちる」という古典的事故をcert-managerが根絶します。Certificateを宣言すればOperatorがACMEチャレンジを実行し、Secretに証明書を埋め、有効期限前の更新まで自動で行います。

6. シークレット — External Secrets Operator

シークレットをGitに平文で入れることはできません。External Secrets Operator(ESO)はAWS Secrets Manager、HashiCorp Vault、GCP Secret Managerといった外部ストアのシークレットをKubernetes Secretに同期します。

apiVersion: external-secrets.io/v1beta1

kind: ExternalSecret

metadata:

spec:

refreshInterval: 1h

secretStoreRef:

kind: SecretStore

target:

data:

- secretKey: password

remoteRef:

key: prod/db/password

Gitには「どのシークレットを取得するか」だけを宣言し、実際の値は外部の金庫に置きます。Operatorが定期的に同期するため、外部でシークレットをローテーションすると自動的に反映されます。

7. GitOps — Argo CD

Argo CD自体がOperatorパターンで動作します。Application CRDが「どのGitリポジトリのどのパスをどのクラスタに同期するか」を宣言します。

apiVersion: argoproj.io/v1alpha1

kind: Application

metadata:

namespace: argocd

spec:

project: default

source:

repoURL: https://github.com/my-org/my-app-config

targetRevision: main

path: overlays/prod

destination:

server: https://kubernetes.default.svc

namespace: my-app

syncPolicy:

automated:

prune: true

selfHeal: true

selfHealがオンなら、誰かがクラスタで手動でリソースを変えてもArgo CDがGitの状態に戻します。Gitが単一の信頼できる情報源(single source of truth)になります。

8. バックアップ — Velero

Veleroはクラスタリソースとパーシステントボリュームをバックアップ・復元します。Backup、Restore、ScheduleといったCRDを提供します。

apiVersion: velero.io/v1

kind: Schedule

metadata:

namespace: velero

spec:

schedule: "0 2 * * *"

template:

includedNamespaces:

- production

storageLocation: aws-s3

ttl: 720h0m0s

毎日深夜2時にproductionネームスペースをバックアップし30日間保持します。クラスタ移行やDRシナリオの中核ツールです。

9. サービスメッシュ — Istio

Istioはサイドカー(またはambientモード)でトラフィックを横取りし、ルーティング、mTLS、観測を提供します。VirtualService、DestinationRule、GatewayといったCRDでトラフィックポリシーを宣言します。

apiVersion: networking.istio.io/v1

kind: VirtualService

metadata:

spec:

hosts:

- reviews

http:

- route:

- destination:

host: reviews

subset: v1

weight: 90

- destination:

host: reviews

subset: v2

weight: 10

カナリアデプロイを「トラフィック90対10」と宣言すればメッシュがそのまま作ってくれます。IstiodがこれらのCRDをEnvoy設定に変換するコントローラーの役割をします。

10. 機械学習 — Kubeflow

KubeflowはMLワークフローをKubernetes上で運用するプラットフォームで、複数のOperatorの集合体です。代表的にはTraining Operatorが分散学習ジョブをCRDで扱います。

apiVersion: kubeflow.org/v1

kind: PyTorchJob

metadata:

spec:

pytorchReplicaSpecs:

Master:

replicas: 1

template:

spec:

containers:

- name: pytorch

image: my-registry/pytorch-train:latest

Worker:

replicas: 4

template:

spec:

containers:

- name: pytorch

image: my-registry/pytorch-train:latest

分散学習のマスター・ワーカートポロジー構成、環境変数の注入(RANK、WORLD_SIZEなど)、失敗したワーカーの再起動をOperatorが担当します。データサイエンティストはインフラを知らなくても分散学習を回せるようになります。

比較表 — 何を自動化し、どれだけ成熟しているか

CNCF Operator Capability LevelはOperatorの成熟度を5段階に分けます。Level 1(基本インストール)からLevel 5(オートパイロット:オートスケール・自動チューニング・異常検知)までです。

| --- | --- | --- | --- | --- |

成熟度は絶対的な等級ではなく傾向である点にご注意ください。同じOperatorでもどの機能を使うかで体感レベルが異なります。

自作する価値のある社内Operatorアイデア10選

既存のOperatorを使うことを超えて、組織固有の運用知識をOperatorとしてコード化することもできます。社内で作ってみる価値のあるアイデアを整理します。

1. オンボーディングOperator

- Tenant CR一つでネームスペース + RBAC + クォータ + 既定NetworkPolicyを一括作成

2. 証明書/ドメインOperator

- 内部サービス登録時にDNSレコード + 証明書 + Ingressをまとめてプロビジョン

3. コストラベル強制Operator

- cost-centerラベルがないワークロードを拒否または自動タグ付け

4. 夜間省電力Operator

- devネームスペースを業務時間外にreplicas=0にスケールダウン

5. データベースセルフサービスOperator

- DevDatabase CRで隔離されたテストDBを即席作成/期限切れ削除

6. シークレットローテーションOperator

- 社内ポリシーに合わせてAPIキーを定期的にローテーションしワークロードをローリング再起動

7. バックアップ検証Operator

- バックアップを使い捨てクラスタに復元して整合性を自動検証

8. カナリア分析Operator

- デプロイ後のメトリクスを評価して自動昇格またはロールバック

9. コンプライアンススキャンOperator

- イメージ脆弱性スキャン結果をCR statusに公開しポリシー違反をブロック

10. マルチクラスタ配置Operator

- PlacementPolicy CRでワークロードを複数クラスタに分配

これらのアイデアの共通点は、**反復的で、手順が明確で、人間がミスしやすい運用作業**であることです。まさにその地点がOperatorのスイートスポットです。

作る価値があるか — 判断基準

既存Operatorがあるのに自作すれば無駄であり、作る価値がないのに作れば保守の負債になります。次の基準で判断してください。

[自作する価値が高いシグナル]

- 運用手順が明確で反復的だ(ランブックが既に存在する)

- その手順を人間が頻繁にミスする(深夜対応、ヒューマンエラー)

- 組織固有のドメインで既存Operatorがない

- 宣言的に表現するのが自然だ(desired stateが明確)

- reconcileで収束可能だ(冪等にできる)

[自作すべきでないシグナル]

- 一回限りの作業だ(Jobやスクリプトで十分)

- 手順が毎回人間の判断を要求する(自動化が危険)

- すでに成熟した既存Operatorがある(cert-managerを再発明しない)

- 状態がなくreconcileするものがない(単なるwebhookやコントローラーで十分)

- チームにコントローラー運用能力がない(放置されると負債)

特に最後の項目が重要です。Operatorは作ることよりも**長期保守**が難しいのです。CRDのバージョン管理、Kubernetesバージョンアップグレードへの対応、reconcileバグによる大量リソースの誤作動リスクまで — 主のいないOperatorは時限爆弾になります。

既存Operatorを選ぶときに見るもの

自作せず既存Operatorを導入するときは次を確認してください。

| 確認項目 | なぜ重要か |

| --- | --- |

| CNCF/公式か | ガバナンスと持続性のシグナル |

| リリース周期 | K8s新バージョン対応が速いか |

| Capability Level | フェイルオーバー/バックアップまで自動化するか |

| CRDバージョンポリシー | v1alpha1に留まっていないか |

| セキュリティ(RBAC範囲) | クラスタ管理者を丸ごと要求しないか |

| 運用事例 | 大規模プロダクションのリファレンスがあるか |

おわりに

Operatorを一文で要約すると**「運用知識をreconcileループに込めたもの」**です。データベースのフェイルオーバー、証明書の自動更新、シークレットの同期 — すべて以前は人間が深夜に起きて行っていたことで、今はコントローラーが黙々と行います。

このカタログから一つだけ持ち帰るなら、「私の組織で最も頻繁に反復され、最も頻繁にミスする運用手順は何か」という問いであってほしいと思います。その答えが明確で宣言的に表現可能なら、それがあなたの作る最初のOperatorの候補です。次の記事ではその中でも最も挑戦的なデータベースOperatorを自作してみます。

参考資料

- Kubernetes Operatorパターン公式ドキュメント: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/

- Operator Framework: https://sdk.operatorframework.io/

- OperatorHub.io(Operatorカタログ): https://operatorhub.io/

- CloudNativePG: https://cloudnative-pg.io/

- Zalando Postgres Operator: https://github.com/zalando/postgres-operator

- Vitess: https://vitess.io/

- Strimzi(Kafka Operator): https://strimzi.io/

- Prometheus Operator: https://prometheus-operator.dev/

- cert-manager: https://cert-manager.io/

- External Secrets Operator: https://external-secrets.io/

- Argo CD: https://argo-cd.readthedocs.io/

- Velero: https://velero.io/

- Istio: https://istio.io/latest/docs/

- Kubeflow Training Operator: https://www.kubeflow.org/docs/components/training/

- Operator Capability Levels: https://sdk.operatorframework.io/docs/overview/operator-capabilities/