こんにちは！クラウドインフラやSREの世界へようこそ。
日々、TerraformやArgo CD、そしてKubernetesのマニフェストの山と格闘しているあなたへ、今日はとびきりワクワクする技術を持ってきたよ。
「インフラストラクチャも、アプリケーションのコードも、すべてGitで宣言的に管理したい。しかも、Kubernetesの思想（コントローラーによる自動修復）をインフラ管理にも持ち込めないだろうか？」
そんなSREの夜な夜なの妄想を、完璧な形で実現してくれるのが「Pulumi Kubernetes Operator」だ。
今回は、このOperatorを使って、クラウドリソースとKubernetesリソースの境界を溶かす次世代のGitOps体験を、基礎から一緒に見ていこう。これをマスターすれば、インフラ管理の概念がガラリと変わり、毎日の作業が劇的に楽になるはずだ。肩の力を抜いて、リラックスしてついてきてほしい。
—
1. そもそも「Pulumi Kubernetes Operator」って何をするもの？
まず前提として、PulumiはTypeScriptやPython、Goといった使い慣れたプログラミング言語でインフラを定義できる画期的なIaC（Infrastructure as Code）ツールだよね。通常は、手元のPCやCI/CDパイプライン（GitHub Actionsなど）から `pulumi up` を叩いてインフラを更新する。
じゃあ、「Pulumi Kubernetes Operator」はどう動くのか？
こいつは、Kubernetesクラスターの中に常駐し、クラスター自身が自分のインフラ（AWSのS3バケットやRDS、あるいはK8s上のマニフェスト）の管理を自律的に行うためのコントローラーなんだ。
Argo CDとの違いと使い分けのコツ
ここで、KubernetesのGitOpsといえばお馴染みの「Argo CD」を思い浮かべるよね。「あれ？Argo CDじゃダメなの？」って思うかもしれない。
- Argo CD: クラスター内の「Kubernetesマニフェスト（YAML）」をGitから同期するスペシャリスト。純粋なK8sリソースの管理においては最強。
- Pulumi Kubernetes Operator: コード（TypeScriptやPythonなど）で書かれたPulumiプログラムそのものをGitから受け取り、AWSやGCP、Azureといったパブリッククラウドのリソースも含めてKubernetes上で構築・監視するスペシャリスト。
使い分けのコツ:
アプリケーションのデプロイやK8sネイティブな構成管理にはArgo CDを使い、「AWSのIAMロールやデータベースを作って、それをアプリから使いたい」といったクラウドインフラストラクチャを巻き込んだGitOpsをやりたい場合は、Pulumi Kubernetes Operatorの出番だ。両者は敵対せず、共存できる。
—
2. 導入のファーストステップ：Operatorのインストール
百聞は一見に如かず。実際に手を動かして、KubernetesクラスターにPulumi Operatorを迎え入れよう。
前提として、動いているKubernetesクラスター（minikubeやKind、EKSなど何でもOK）と、`kubectl` が手元にある状態を想定しているよ。
ステップ1: CRDとOperatorのデプロイ
Pulumi Operatorは、Kubernetesに `Stack` という新しいカスタムリソース（CRD）を追加する。これによって、「K8sの作法でPulumiを動かす」ことが可能になるんだ。
以下のマニフェストを `pulumi-operator-system.yaml` として保存して、クラスターに適用しよう。
厳選された公式マニフェストをベースにした、Operator導入の最小構成
apiVersion: v1
kind: Namespace
metadata:
name: pulumi-operator-system
—
Operator本体やRBAC権限を一括インストールする（公式の最新安定版URLを指定）
現場では必ずバージョンを固定してapplyしよう
※実際には、以下のコマンド一発で公式のインストールマニフェストを適用するのが一番確実だ。
kubectl apply -f https://raw.githubusercontent.com/pulumi/pulumi-kubernetes-operator/v2.1.0/deploy/yaml/pulumi-kubernetes-operator.yaml
インストールが成功したか、ポッドの状態を確認してみよう。
kubectl get pods -n pulumi-operator-system
`pulumi-operator-…` というポッドが `Running` になっていれば、無事に心臓部の設置完了だ！
—
3. 認証情報の安全な受け渡し（Secretの設定）
Kubernetesの中でPulumiが動くということは、AWSやGCPなどのクラウドプロバイダーを操作する権限（アクセスキーなど）をクラスターに安全に渡してあげる必要がある。
今回はAWSを例に、シークレットを作成しよう。
kubectl create secret generic pulumi-aws-creds \
–namespace=default \
–from-literal=AWS_ACCESS_KEY_ID=”あなたのアクセスキー” \
–from-literal=AWS_SECRET_ACCESS_KEY=”あなたのシークレットキー”
さらに、Pulumi自体のバックエンド（状態をどこに保存するか。Pulumi CloudやS3など）のトークンもSecretとして用意しておく必要があるよ。
kubectl create secret generic pulumi-api-secret \
–namespace=default \
–from-literal=PULUMI_ACCESS_TOKEN=”your-pulumi-access-token”
—
4. 精度高い「Hello World」：Stackリソースの投入
ここからが本番！KubernetesのマニフェストとしてPulumiプログラムの実行指示（Stackリソース）を定義する。今回は、Gitリポジトリ（GitHubなど）に置いてあるPulumiコードを、このOperatorに自動でpullして実行してもらう形をとるよ。
以下のマニフェストを `my-first-stack.yaml` として作成してほしい。
apiVersion: pulumi.com/v1
kind: Stack
metadata:
name: hello-pulumi-stack
namespace: default
spec:
# 実行するPulumiプログラムが入っているGitリポジトリのURL
repo: https://github.com/your-username/my-pulumi-gitops-repo.git
branch: refs/heads/main
projectFolder: aws-s3-example # リポジトリ内のディレクトリパス
# 使用するPulumiのスタック名（dev, prodなど）
stack: dev
# 先ほど作成したクラウド認証情報のSecretを紐付ける
envSecrets:
- name: AWS_ACCESS_KEY_ID
secret:
name: pulumi-aws-creds
key: AWS_ACCESS_KEY_ID
- name: AWS_SECRET_ACCESS_KEY
secret:
name: pulumi-aws-creds
key: AWS_SECRET_ACCESS_KEY
# Pulumi Cloudのアクセストークン
accessTokenSecret:
name: pulumi-api-secret
key: PULUMI_ACCESS_TOKEN
# 自動同期を有効にする（Gitにプッシュされたら自動でpulumi up走る！）
refreshSettings:
period: 1h
このYAMLをクラスターに適用してみよう。
kubectl apply -f my-first-stack.yaml
—
5. マジックの瞬間：動作品質の確認
YAMLをapplyした瞬間、何が起きているか？
Kubernetesの内部でPulumi Operatorが目を覚まし、指定されたGitリポジトリをクローンし、コンテナ上で `pulumi up` を自動実行してくれるんだ。
その様子は、以下のコマンドでリアルタイムに追跡できる。
Stackのステータスを確認
kubectl get stack hello-pulumi-stack
詳細なログを見てみよう（ここでPulumiがクラウドと対話するログが見れる！）
kubectl logs -l app.kubernetes.io/name=pulumi-kubernetes-operator -n pulumi-operator-system -f
もし指定したGitリポジトリの `aws-s3-example` 内に、「AWS上にS3バケットを1つ作る」というTypeScriptのコードが入っていれば、Kubernetesにマニフェストを放り込んだだけで、AWS上に本物のS3バケットが爆誕する。
これこそが、IaCとKubernetesコントローラーが融合した次世代のインフラ管理の姿だ。
誰かが手元のPCから `pulumi up` を叩く必要はもうない。Gitへのマージこそが、すべてのインフラ変更のトリガーになる。
—
さいごに
今回は、Pulumi Kubernetes Operatorの概要から、実際のインストール、そしてGitOpsによるインフラ自動構築の基礎までを駆け足で解説した。
「コードでインフラを書き、それをKubernetesの自己修復ループ（コントローラー）に乗せて常に理想の状態を維持し続ける」
このアプローチを一度体験してしまうと、もう古い手動デプロイや不安定なCI/CDパイプラインには戻れなくなるはずだ。ぜひ自分の検証クラスターで試して、この「すべてが自動で整っていく快感」を味わってみてほしい。
あなたのインフラストラクチャ管理が、よりエレガントで、より楽しいものになることを心から応援しているよ！