CFK Operator のインストールと運用ガイド（2026年最新版）

2026年7月25日

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

エンジニアの世界では、「いつでも動ける状態を作っておけ」とよく言われます。
技術やポートフォリオがあっても、自分に合う案件情報を日常的に見れていないと、いざ動こうと思った時に比較や判断が難しくなってしまいます。
普段から案件情報が集まる環境を作っておくと、良い案件が出た時にすぐ動きやすくなりますよ。
筆者自身も、メガベンチャー勤務時代に年収1,500万円を超えた経験があります。振り返ると、技術だけでなく「どんな案件や働き方があるか」を日頃から見ていたことが、キャリアの選択肢を広げるきっかけになりました。
このブログを読んでくれた方に感謝を込めて、実際に使っている情報収集サービスを紹介します。

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

Contents

1 1. CFK Operator のインストール
2 2. Kafka CRD 設定例とリソースチューニング
3 3. 認証・認可と TLS 設定
4 4. モニタリング・アラート（Prometheus/Grafana + Alertmanager）
5 5. スケーリング・リバランス・Zero‑downtime アップグレード
6 6. マルチクラウド連携・コスト最適化・トラブルシューティング
7 おわりに

スポンサードリンク

1. CFK Operator のインストール

このセクションでは、Helm と kubectl マニフェスト の2つの方法で CFK Operator をクラスタにデプロイする手順を示します。どちらも公式リポジトリから取得でき、環境や運用方針に合わせて選択してください。

1‑1. Helm Chart を使ったインストール

Helm はバージョン管理とパラメータ化が容易なため、本番環境での利用を推奨します。以下は最新版（2024‑12 時点）の v0.9.0 を例にした手順です。

# 1) Helm リポジトリ追加 &amp; 更新
helm repo add confluent https://packages.confluent.io/helm
helm repo update

# 2) values.yaml の作成（必要最低限の設定のみ掲載）
cat &gt; values.yaml &lt;&lt;'EOF'
image:
  repository: confluentinc/cfk-operator
  tag: &quot;0.9.0&quot;          # 最新タグを公式リリースノートで確認してください
rbac:
  create: true
watchNamespaces: []     # 空配列は全ネームスペース監視
EOF

# 3) Operator のインストール
helm install cfk-operator confluent/cfk-operator \
    -n cfk-system --create-namespace \
    -f values.yaml

# 1) Helm リポジトリ追加 & 更新

helm repo add confluent https://packages.confluent.io/helm

helm repo update

# 2) values.yaml の作成（必要最低限の設定のみ掲載）

cat > values.yaml <<'EOF'

image:

repository: confluentinc/cfk-operator

tag: "0.9.0" # 最新タグを公式リリースノートで確認してください

rbac:

create: true

watchNamespaces: [] # 空配列は全ネームスペース監視

EOF

# 3) Operator のインストール

helm install cfk-operator confluent/cfk-operator \

-n cfk-system --create-namespace \

-f values.yaml

ポイント：watchNamespaces を空にすると全ネームスペースを監視しますが、セキュリティ要件がある場合は対象の名前空間だけを列挙してください。

1‑2. kubectl マニフェストでのインストール

マニフェスト方式は Helm が利用できない環境（例：Air‑gapped クラスタ）向けです。CRD と Operator デプロイメントを個別に適用します。

前提条件 – cert-manager のインストール

TLS 証明書の自動生成には cert-manager が必須です。以下コマンドでインストールしてください。

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.3/cert-manager.yaml

1 2	kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.3/cert-manager.yaml

cert-manager のバージョンは公式ドキュメントに合わせて適宜更新してください。

CRD と Operator デプロイメントの適用

# 1) CFK 用 CRD（正しいパス）を適用
kubectl apply -f https://raw.githubusercontent.com/confluentinc/cfk-operator/main/crds/kafka.confluent.io_kafkas.yaml

# 2) Operator デプロイメント
kubectl apply -f https://raw.githubusercontent.com/confluentinc/cfk-operator/main/deploy/operator.yaml -n cfk-system --create-namespace

# 1) CFK 用 CRD（正しいパス）を適用

kubectl apply -f https://raw.githubusercontent.com/confluentinc/cfk-operator/main/crds/kafka.confluent.io_kafkas.yaml

# 2) Operator デプロイメント

kubectl apply -f https://raw.githubusercontent.com/confluentinc/cfk-operator/main/deploy/operator.yaml -n cfk-system --create-namespace

注意：上記 URL は cfk-operator リポジトリの公式パスです。Strimzi の CRD とは別物であることに留意してください。

1‑3. インストール後の動作確認

kubectl get pods -n cfk-system -l app=cfk-operator
# =&gt; READY が 1/1 の Pod が表示されていれば正常です

kubectl get pods -n cfk-system -l app=cfk-operator

# => READY が 1/1 の Pod が表示されていれば正常です

2. Kafka CRD 設定例とリソースチューニング

本節では、実運用で推奨される ブローカー数・レプリケーション、ティアードストレージ、そして CPU/メモリのリクエスト＆リミット の具体的な設定例を示します。適切にチューニングすることでスループットとコストのバランスが最適化されます。

2‑1. 基本構成（ブローカー数・レプリケーション）

以下は 3 台構成で、外部ロードバランサー経由の接続を想定した Kafka カスタムリソースです。レプリケーション係数はブローカー数と同等に設定し、単一ノード障害時でもデータ損失が起きないようにします。

apiVersion: kafka.confluent.io/v1beta2
kind: Kafka
metadata:
  name: cfk-cluster
spec:
  kafka:
    replicas: 3                     # 推奨は奇数で最低 3 台
    listeners:
      - name: external
        port: 9094
        type: loadbalancer
    config:
      offsets.topic.replication.factor: 3
      transaction.state.log.replication.factor: 3

apiVersion: kafka.confluent.io/v1beta2

kind: Kafka

metadata:

spec:

kafka:

replicas: 3 # 推奨は奇数で最低 3 台

listeners:

- name: external

port: 9094

type: loadbalancer

config:

offsets.topic.replication.factor: 3

transaction.state.log.replication.factor: 3

2‑2. ティアードストレージ構成

Hot データは高速 NVMe、Cold データはコスト効率の良い SSD に自動分散させる設定例です。クラウドごとのストレージクラス名は環境に合わせて置き換えてください。

    storage:
      type: persistent-claim
      class: &quot;standard-ssd&quot;          # GKE の PD‑SSD 例
      size: 500Gi
      tieredStorage:
        - class: &quot;high-performance-nvme&quot;
          size: 200Gi

storage:

type: persistent-claim

size: 500Gi

tieredStorage:

- class: "high-performance-nvme"

size: 200Gi

2‑3. リソースリクエスト／リミット（ベストプラクティス）

コンポーネント	CPU request	CPU limit	メモリ request	メモリ limit
Kafka ブローカー	2 cores	4 cores	8Gi	12Gi
ZooKeeper	0.5 core	1 core	1Gi	2Gi

CPU request は安定稼働の最低保証、limit はスパイク時に利用可能な上限です。
メモリは JVM ヒープサイズ（-Xmx）を考慮し、余裕を持たせることで GC 頻度が低減します。

Tip：リソース設定はクラスタの実測負荷に合わせて段階的に調整してください。過剰割り当てもコスト増につながります。

3. 認証・認可と TLS 設定

マネージド K8s 環境（GKE / EKS / AKS）では、クラウド固有の IAM と組み合わせた Workload Identity／IRSA／AAD Pod Identity が推奨されます。本節ではそれぞれの設定例と、TLS 証明書を cert-manager で自動生成する手順を示します。

3‑1. GKE – Workload Identity と TLS

# Workload Identity の有効化（gcloud）
gcloud container clusters update my-gke-cluster \
    --workload-pool=my-project.svc.id.goog

# Workload Identity の有効化（gcloud）

gcloud container clusters update my-gke-cluster \

--workload-pool=my-project.svc.id.goog

ServiceAccount の紐付け

apiVersion: v1
kind: ServiceAccount
metadata:
  name: cfk-sa
  annotations:
    iam.gke.io/gcp-service-account: cfk-operator@my-project.iam.gserviceaccount.com

apiVersion: v1

kind: ServiceAccount

metadata:

annotations:

iam.gke.io/gcp-service-account: cfk-operator@my-project.iam.gserviceaccount.com

cert-manager による証明書自動生成

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: kafka-tls
spec:
  secretName: kafka-tls-secret
  dnsNames:
    - &quot;*.my-gke-cluster.svc.cluster.local&quot;
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer

apiVersion: cert-manager.io/v1

kind: Certificate

metadata:

spec:

secretName: kafka-tls-secret

dnsNames:

- "*.my-gke-cluster.svc.cluster.local"

issuerRef:

kind: ClusterIssuer

ポイント：cert-manager がインストール済みであることが前提です（セクション 1‑2 の手順参照）。

3‑2. EKS – IRSA と SASL/OAuth

# IRSA 用 ServiceAccount 作成（eksctl）
eksctl create iamserviceaccount \
    --name cfk-sa \
    --namespace cfk-system \
    --cluster my-eks-cluster \
    --attach-policy-arn arn:aws:iam::123456789012:policy/KafkaAccess \
    --approve

# IRSA 用 ServiceAccount 作成（eksctl）

eksctl create iamserviceaccount \

--name cfk-sa \

--namespace cfk-system \

--cluster my-eks-cluster \

--attach-policy-arn arn:aws:iam::123456789012:policy/KafkaAccess \

--approve

OAuth 認証情報の格納

apiVersion: v1
kind: Secret
metadata:
  name: kafka-oauth-secret
type: Opaque
stringData:
  client-secret: &lt;BASE64_ENCODED_SECRET&gt;

apiVersion: v1

kind: Secret

metadata:

type: Opaque

stringData:

client-secret: <BASE64_ENCODED_SECRET>

Kafka CR に認証設定を追加

spec:
  auth:
    type: oauth
    oauth:
      clientId: my-client-id
      clientSecretRef:
        name: kafka-oauth-secret
        key: client-secret
      tokenEndpointUri: https://cognito-idp.&lt;region&gt;.amazonaws.com/&lt;user-pool&gt;/oauth2/token

spec:

auth:

type: oauth

oauth:

clientId: my-client-id

clientSecretRef:

key: client-secret

tokenEndpointUri: https://cognito-idp.<region>.amazonaws.com/<user-pool>/oauth2/token

3‑3. AKS – Azure AD Pod Identity と TLS

# AAD Pod Identity の有効化（Azure CLI）
az aks enable-addons -a azure-policy,azure-keyvault-secrets-provider \
    -g my-rg -n my-aks-cluster

# AAD Pod Identity の有効化（Azure CLI）

az aks enable-addons -a azure-policy,azure-keyvault-secrets-provider \

-g my-rg -n my-aks-cluster

Key Vault から証明書取得例（cert-manager 用 Issuer）

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: azure-keyvault-issuer
spec:
  vault:
    server: &quot;https://my-vault.vault.azure.net&quot;
    path: &quot;certs/kafka-tls&quot;
    auth:
      clientSecretRef:
        name: kv-secret
        key: client-secret

apiVersion: cert-manager.io/v1

kind: ClusterIssuer

metadata:

spec:

vault:

server: "https://my-vault.vault.azure.net"

path: "certs/kafka-tls"

auth:

clientSecretRef:

key: client-secret

落とし穴：Azure AD のアクセストークン有効期限は短いので、TokenRefreshInterval を適切に設定しないと認証エラーが頻発します。

4. モニタリング・アラート（Prometheus/Grafana + Alertmanager）

CFK Operator 本体には Kafka Exporter が同梱されていません。公式ドキュメントでは別途デプロイすることが推奨されています。このセクションでは、Exporter のインストール手順と、Grafana ダッシュボード・Alertmanager ルールの設定例を示します。

4‑1. Kafka Exporter のデプロイ

# Namespace 作成（任意）
kubectl create ns monitoring

# Exporter 用 ServiceAccount と RBAC
cat &gt; exporter-rbac.yaml &lt;&lt;'EOF'
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kafka-exporter-sa
  namespace: monitoring
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kafka-exporter-role
rules:
- apiGroups: [&quot;&quot;]
  resources: [&quot;pods&quot;, &quot;services&quot;]
  verbs: [&quot;get&quot;,&quot;list&quot;,&quot;watch&quot;]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kafka-exporter-binding
subjects:
- kind: ServiceAccount
  name: kafka-exporter-sa
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: kafka-exporter-role
  apiGroup: rbac.authorization.k8s.io
EOF
kubectl apply -f exporter-rbac.yaml

# Exporter デプロイメント
cat &gt; exporter-deployment.yaml &lt;&lt;'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kafka-exporter
  namespace: monitoring
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kafka-exporter
  template:
    metadata:
      labels:
        app: kafka-exporter
    spec:
      serviceAccountName: kafka-exporter-sa
      containers:
        - name: exporter
          image: confluentinc/kafka-exporter:0.11.2   # 最新タグは公式リポジトリで確認
          args:
            - --kafka.server=cfk-cluster-kafka-bootstrap.cfksystem.svc:9092
          ports:
            - containerPort: 9308
EOF
kubectl apply -f exporter-deployment.yaml

# Service（Prometheus がスクレイプできるように公開）
cat &gt; exporter-service.yaml &lt;&lt;'EOF'
apiVersion: v1
kind: Service
metadata:
  name: kafka-exporter
  namespace: monitoring
spec:
  selector:
    app: kafka-exporter
  ports:
    - port: 9308
      targetPort: 9308
      protocol: TCP
      name: metrics
EOF
kubectl apply -f exporter-service.yaml

# Namespace 作成（任意）

kubectl create ns monitoring

# Exporter 用 ServiceAccount と RBAC

cat > exporter-rbac.yaml <<'EOF'

apiVersion: v1

kind: ServiceAccount

metadata:

namespace: monitoring

---

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole

metadata:

rules:

- apiGroups: [""]

resources: ["pods", "services"]

verbs: ["get","list","watch"]

---

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding

metadata:

subjects:

- kind: ServiceAccount

namespace: monitoring

roleRef:

kind: ClusterRole

apiGroup: rbac.authorization.k8s.io

EOF

kubectl apply -f exporter-rbac.yaml

# Exporter デプロイメント

cat > exporter-deployment.yaml <<'EOF'

apiVersion: apps/v1

kind: Deployment

metadata:

namespace: monitoring

spec:

replicas: 1

selector:

matchLabels:

app: kafka-exporter

template:

metadata:

labels:

app: kafka-exporter

spec:

serviceAccountName: kafka-exporter-sa

containers:

- name: exporter

image: confluentinc/kafka-exporter:0.11.2 # 最新タグは公式リポジトリで確認

args:

- --kafka.server=cfk-cluster-kafka-bootstrap.cfksystem.svc:9092

ports:

- containerPort: 9308

EOF

kubectl apply -f exporter-deployment.yaml

# Service（Prometheus がスクレイプできるように公開）

cat > exporter-service.yaml <<'EOF'

apiVersion: v1

kind: Service

metadata:

namespace: monitoring

spec:

selector:

app: kafka-exporter

ports:

- port: 9308

targetPort: 9308

protocol: TCP

EOF

kubectl apply -f exporter-service.yaml

4‑2. Grafana ダッシュボードのインポート手順

Grafana にログイン → 「+」→「Import」。
Dashboard ID 1860（Confluent Kafka）を入力し、データソースに Prometheus を選択。
インポート後は以下のパネルが自動生成されます：
ISR 同期遅延
ディスク使用率(％)
プロデューサ／コンシューマレイテンシ

4‑3. Alertmanager のルール例

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: kafka-alerts
  namespace: monitoring
spec:
  groups:
    - name: kafka.rules
      rules:
        - alert: KafkaBrokerDown
          expr: up{job=&quot;kafka-exporter&quot;} == 0
          for: 2m
          labels:
            severity: critical
          annotations:
            summary: &quot;Kafka ブローカーが停止しています&quot;
            description: &quot;{{ $labels.instance }} のブローカーが 2 分以上応答なし&quot;

        - alert: ISRUnderReplicated
          expr: kafka_isr_under_replicated_partitions &gt; 0
          for: 1m
          labels:
            severity: warning
          annotations:
            summary: &quot;ISR がレプリケーション不足&quot;
            description: &quot;一部パーティションで ISR が期待値未満です。&quot;

apiVersion: monitoring.coreos.com/v1

kind: PrometheusRule

metadata:

namespace: monitoring

spec:

groups:

- name: kafka.rules

rules:

- alert: KafkaBrokerDown

expr: up{job="kafka-exporter"} == 0

for: 2m

labels:

severity: critical

annotations:

summary: "Kafka ブローカーが停止しています"

description: "{{ $labels.instance }} のブローカーが 2 分以上応答なし"

- alert: ISRUnderReplicated

expr: kafka_isr_under_replicated_partitions > 0

for: 1m

labels:

severity: warning

annotations:

summary: "ISR がレプリケーション不足"

description: "一部パーティションで ISR が期待値未満です。"

ポイント：Exporter の Service 名（kafka-exporter.monitoring.svc.cluster.local）と job ラベルは Prometheus 設定に合わせて調整してください。

5. スケーリング・リバランス・Zero‑downtime アップグレード

この章では、CFK Operator が提供する 水平スケーリング、自動パーティション再配置（KafkaRebalance）、そして ダウンタイムなしのバージョンアップ手順 を具体的に示します。

5‑1. 水平スケーリング

replicas フィールドを変更するだけで新ブローカーが追加されます。Operator が RollingUpdate ポリシーで安全に再起動します。

kubectl patch kafka cfk-cluster -n cfk-system \
  --type merge -p '{&quot;spec&quot;:{&quot;kafka&quot;:{&quot;replicas&quot;:5}}}'

kubectl patch kafka cfk-cluster -n cfk-system \

--type merge -p '{"spec":{"kafka":{"replicas":5}}}'

ベストプラクティス：スケールアウト後は KafkaRebalance ジョブでパーティションの再分配を実行し、リソース使用率を均等化します。

5‑2. 自動パーティション再配置（KafkaRebalance）

apiVersion: kafka.confluent.io/v1beta2
kind: KafkaRebalance
metadata:
  name: rebalance-job
spec:
  mode: add-brokers   # 新規ブローカーへ自動的にパーティションを移行

apiVersion: kafka.confluent.io/v1beta2

kind: KafkaRebalance

metadata:

spec:

mode: add-brokers # 新規ブローカーへ自動的にパーティションを移行

kubectl apply -f rebalance.yaml -n cfk-system

1 2	kubectl apply -f rebalance.yaml -n cfk-system

Operator が ISR を監視しつつ、均衡が取れるまで再配置を続行します。

5‑3. Zero‑downtime アップグレードフロー（例：v0.9.0 → v1.0.0）

バックアップ確認（ストレージスナップショット取得）。
PodDisruptionBudget (PDB) 作成 で同時停止数を制限。

yaml apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: kafka-pdb namespace: cfk-system spec: maxUnavailable: 1

Operator のイメージタグ更新（Helm 利用時は helm upgrade、kubectl 時は set image）。

bash # kubectl 例 kubectl set image deployment/cfk-operator \ cfk-operator=confluentinc/cfk-operator:1.0.0 -n cfk-system

RollingUpdate が自動的に実行され、ブローカーが順次新バージョンへ置き換わります。
アップグレード完了後は PDB を削除し、kubectl get pods -w で正常性を最終確認。

重要ポイント：PDB の maxUnavailable:1 により同時に 2 台以上が停止せず、サービスダウンなしでバージョンアップできます。

6. マルチクラウド連携・コスト最適化・トラブルシューティング

最後に Cluster Linking を用いたマルチクラウドレプリケーション例と、各クラウド別の ノード/永続ボリューム選定指針、そして実務で頻出する障害シナリオのチェックリストをまとめます。

6‑1. Cluster Linking によるデータレプリケーション例（GKE ↔ EKS）

apiVersion: kafka.confluent.io/v1beta2
kind: KafkaMirrorMaker2
metadata:
  name: cm2-link-gke-eks
spec:
  clusters:
    source-cluster:
      bootstrapServers: gke-kafka:9092
      tls:
        trustedCertificates:
          - secretName: gke-tls-secret
            certificate: ca.crt
    target-cluster:
      bootstrapServers: eks-kafka:9092
      iam:
        enabled: true
  mirrors:
    - sourceCluster: source-cluster
      targetCluster: target-cluster
      topicsPattern: &quot;.*&quot;

apiVersion: kafka.confluent.io/v1beta2

kind: KafkaMirrorMaker2

metadata:

spec:

clusters:

source-cluster:

bootstrapServers: gke-kafka:9092

tls:

trustedCertificates:

- secretName: gke-tls-secret

certificate: ca.crt

target-cluster:

bootstrapServers: eks-kafka:9092

iam:

enabled: true

mirrors:

- sourceCluster: source-cluster

targetCluster: target-cluster

topicsPattern: ".*"

詳細は公式ガイド Confluent Cluster Linking を参照してください。

6‑2. ノードタイプ・永続ボリュームの選定指針と概算月額（2024 年データ）

クラウド	推奨ノードタイプ	永続ボリューム種別	月額概算*
GKE	n2-standard-8 (8 vCPU, 32 GiB)	PD‑SSD 500 GiB	¥150,000
	e2-highcpu-4 (4 vCPU, 16 GiB)	PD‑Balanced 1 TiB	¥120,000
EKS	m5.large (2 vCPU, 8 GiB)	gp3 500 GiB	$95
	r6g.xlarge (4 vCPU, 32 GiB)	io2 1 TiB	$180
AKS	Dsv4_v5 (8 vCPU, 32 GiB)	Premium SSD 500 GiB	€140

* 注：為替レートは執筆時点（2024‑12）での概算です。実際の料金は各クラウドベンダーの価格ページをご確認ください。
- 最新料金はそれぞれの公式サイト → GCP Pricing、AWS EC2 Pricing 、Azure VM Pricing を参照してください。
- スポット／プリエンプティブインスタンスは最大 80 % の割引がありますが、ノードの 冗長性（最低 3 台） と PDB 設定 が必須です。

6‑3. 主な障害シナリオとチェックリスト

障害シナリオ	確認項目	推奨対処
ブローカー起動失敗	`kubectl logs <broker-pod>`、PVC バインド状態 (`kubectl get pvc`)	ストレージクラス権限確認、リソースリミット緩和
ネットワーク分離（Pod → Service）	Pod から内部 DNS 解決テスト (`kubectl exec -it <pod> -- nslookup <service>`)、Service Endpoints 確認	NetworkPolicy の見直し、クラウド LB 設定再確認
パーティションリーダー不在	メトリクス `kafka_partition_leader_missing` が 0 以上か	`KafkaRebalance` 実行、ブローカー数増加で ISR 回復

チェックリスト（障害発生時に実施すべき順序）
1. Pod 状態確認 → kubectl get pods -n cfk-system
2. ログ取得 → kubectl logs <対象ポッド>
3. PVC バインド状態 → kubectl get pvc -A
4. ネットワークテスト → nslookup / curl で Service 到達性確認
5. メトリクス確認 → Prometheus ダッシュボードで該当指標をチェック

おわりに

本稿では、CFK Operator の 最新インストール手順、セキュアな認証設定、モニタリングとアラート、スケーリング・ゼロダウンタイムアップグレード、そして マルチクラウド連携・コスト最適化 までを一貫した流れで紹介しました。実際にハンズオンしながら各設定を検証すれば、GKE・EKS・AKS のいずれの環境でも堅牢かつスケーラブルな Kafka 基盤が構築できます。