1. はじめに
こんにちは。2026年2月～3月の間、Sreake事業部でインターンをしている中家です。
私は普段、開発系サークルの代表として活動しています。しかし、部で構築したシステムは現在、仮想サーバに置いただけの状態となっており、保守性に欠けるという課題があります。
この課題を解決し、今後のクリーンな開発環境を担保することを目標とした私は、GKEにおけるマルチクラスタ管理の簡素化を体現する”Fleet”に着目し、その周辺の技術について検証することにしました。
2. 用語の解説とマルチクラスタ基盤の概念
本章では、マルチクラスタ環境特有の課題と、それを解決するための「基盤（Fleet）」および「運用手法（GitOps）」それぞれの役割を明確に整理します。
2.1 Kubernetesにおけるマルチクラスタの管理の課題
Kubernetesの標準機能では、基本的にクラスタごとに独立した管理を行うことになります。そこには以下の課題があります。
- 分断された管理： デフォルトではクラスタごとに手作業で設定を適用する必要があるため、適用忘れなどが発生する。
- ガバナンス(ポリシー)の限界： 個別クラスタでのポリシー運用では、一部のクラスタへの適用漏れなどの管理ミスが起こりやすい。
- クラスタ間連携の難しさ： クラスタ間に渡るサービスを提供する際、個別での認証設定などが必要となり、数がスケールすると管理が破綻する。
2.2 物理的な枠を越える統合基盤「 Fleet」について
これらの課題を解決し、複数のクラスタを論理的に統合する「土台」となるのがGCPのGKE Fleetです。本節では、基盤全体を束ねる「Fleet」と、それをテナントごとに切り分ける「Fleet Scope」のそれぞれの役割を解説します。
2.2.1 GKE Fleet：複数クラスタを「1つのグループ」として束ねる
プロジェクトやリージョンに散らばる独立したKubernetesクラスタ群を、１つのグループとして論理的にまとめる機能です。
- 管理の単一化： 全体を一つのグループとして扱うことで、ポリシーや設定を各クラスタへ個別に適用するプロセスを削減します。
- 一括操作の土台： 管理者は「どのクラスタか」という物理的な制約を意識せず、一回の指示でフリート全体に対する操作や監視が可能になります。
2.2.2 Fleet Scope：グループの中にチームのワークスペースを構築する
Fleetという巨大な統合インフラの中に、実際の開発チームやシステム機能ごとの「専用区画」を設ける仕組みが 「Fleet Scope」です。
- 安全なマルチテナント管理： 「同一の役割を持つ Namespace は、複数のクラスタを貫く形で同一のチームが管理できる」という概念を提供します。
- 自律的な運用： インフラの全体管理者から権限を移譲された各チームは、他チームのシステム領域に影響を与えるリスクなく、自身の担当するScope内のみを全クラスタ横断で安全に操作可能になります。
2.3 宣言的な状態管理を実現する「GitOps」と必須要件
実際のアプリや設定を全てのクラスタへ自動配備するための手法が「GitOps」です。GitOpsの目標は、運用のプロセスから「ヒトによる不確実な手作業」を排除することにあります。
- 唯一の情報源： kubectl applyなどでクラスタを直接操作することを原則禁止し、Gitリポジトリをシステム状態の「唯一の情報源」とします。
- 監査可能性と即時切り戻し： 誰が・いつ・何を変更したかがGitのコミット履歴にすべて残り、万が一障害が起きても直前のコミットへ即座に切り戻しが可能です。
- レビューを通した安全なデプロイ： インフラやポリシーの変更も、アプリケーションコードと同様にプルリクエストを通したレビュー文化に乗せることができます。
2.4 Fleet と GitOps の相乗効果について
GitOps を実現するためのツールは複数存在しますが、本検証では Google Cloud マネージドの「Config Sync」を採用しました。 その最大の理由は、Fleet とConfigSyncを組み合わせることによる「運用保守の削減」と「エコシステム統合」のメリットが大きいからです。
- 運用ツール自体のライフサイクル管理からの解放： OSSのGitOpsエージェントを多数のクラスタにインストールし、バージョンアップやパッチ当てを自前で管理するのは膨大な運用コスを生みます。 しかし、Config Sync は Fleet を通して機能を有効化するだけで、Google 側が各クラスタへのプロビジョニングからアップデートまでのライフサイクルを全自動で管理してくれます。
- GCP エコシステムとのネイティブな統合： Config Sync は、Policy Controller と連携する構成管理スイートとして統合されており、さらに Workload Identity を利用したプライベートリポジトリへのキーレス認証も標準でサポートしています。
- 可観測性（Observability）の標準提供： Google Cloud Console 上に全クラスタの同期ステータスやエラーを一括表示するダッシュボードがデフォルトで用意されており、監視基盤（Grafana等）を自作しなくても全クラスタの状態を俯瞰できます。
※FleetとConfgiSyncによるGitOpsの依存関係について
上記のように、Config SyncやPolicy Controllerは、Fleetの拡張機能として提供されています。 つまり、GitOpsの仕組みを複数のクラスタへ一括導入するためには、システム実装の前提として「各クラスタをFleetに登録・有効化すること」が必須要件となります。 実実装上は「Fleetによるインフラ統合」が先立ち、その上に「GitOps」が展開される構成です。
2.5 セキュリティ・通信・ガバナンスを支える周辺技術
上記の「Fleet」と「GitOps」を支え、より堅牢な基盤を作るためのアーキテクチャ要素を以下のように整理しました。
Fleet拡張機能 (Fleet Features)
| 技術名 | 役割 | 概要 |
|---|---|---|
| Multi-cluster Services (MCS) | クラスタ間通信 | Fleet内のクラスタ間でServiceを共有し、内部DNSを使ったリージョン間Pod通信を可能にする。 |
| Policy Controller | ガバナンス運用 | OPA Gatekeeperベース。不適切なマニフェスト（latestダグ等）を全クラスタ横断でブロックする。 |
マニフェスト・コード管理技術
| 技術名 | 役割 | 概要 |
|---|---|---|
| Kustomize | 宣言的なマニフェスト管理 | Base（共通）とOverlay（環境別差分）を組み合わせ、東京・台湾でのGitOps配信を整理・最適化する。 |
認証・セキュリティ基盤
| 技術名 | 役割 | 概要 |
|---|---|---|
| Workload Identity | 認証の紐付け | KSA（K8sの権限）とGSA（GCPの権限）を紐付けし、キーレスでのアクセスを可能にする。 |
| External Secrets Operator (ESO) | 秘匿情報のエージェント | GCPのSecret Managerから情報を取得し、K8sのSecretとしてクラスター内に動的生成する。 |
| Google Secret Manager | 秘匿情報の保管庫 | GitHubの認証トークンなどの機密情報を、Gitリポジトリから隔離して安全に保管する。 |
3. インフラ設計と環境分離のアーキテクチャ
本章からは実際のタスク詳細に入ります。まずは基盤となるインフラ層の設計判断と、安全な環境分離のアプローチについて振り返ります。
3.1 組織のベストプラクティスと今回の環境分離の挑戦
複数のクラスタを有する企業環境において、本番環境と検証環境を切り分けて他環境への悪影響を防ぐことは極めて重要です。
- Google Cloud推奨のベストプラクティス： 本番環境と検証環境で「GCPのプロジェクト」自体を分割し、IAMやリソースの枯渇リスクを物理的に隔離する。
- 今回の環境の制約とアプローチ： 今回は単一プロジェクトという箱の中で、本番（東京main）と検証（台湾sub）のマルチリージョンを構築しました。 この制約を補うため、 Fleet Scopeを用いた論理的な権限分離 を厳密に適用し、単一プロジェクト下であっても「開発者は自身の担当システム領域しか操作できない」というマルチテナント環境を実現しました。
3.2 インフラとアプリの明確な責任境界線：デッドロック問題の解消
Terraformで基盤を構築・破棄するサイクルを回す中で、ステート（状態管理）のデッドロック問題に直面しました。
【課題の発生】
当初は、Terraformを用いてVPCやGKEの構築から、Kubernetes内部のNamespaceやアドオンのデプロイまでを一括で自動化しようとしていました。 しかし、GKE AutopilotやFleetが自動生成するネットワーク管理用リソースやWebhook（幽霊リソース）とTerraformのステートが競合し、「terraform destroy を実行してもリソースが消せずに永遠に止まる」というデッドロックに陥りました。
【解決策: 責任境界のアーキテクチャ再定義】
この事態を解決するため、インフラ管理とアプリ管理の分割点を以下のように引きました。
- インフラ基盤（Terraform）の役割： VPCネットワーク、GKEクラスタ作成、Fleet登録、Secret Managerなどの 「純粋な土台構築」 のみを担当する。K8s内部は一切触らない。
- アプリ基盤（GitOps/Config Sync）の役割： K8s内部のNamespace、Deployment、Service、拡張機能等の展開は 「すべてGitリポジトリを正として同期」 させる。するため、インフラ管理とアプリ管理の分割点を以下のように引きました。
TerraformからKubernetes APIの直接操作を排除した結果、何度同じ操作をしても確実に動作することが担保され、安定した環境の構築・破棄が可能となりました。
4. GitOps基盤の構築とFleet拡張機能の実践
インフラとアプリの領域が明確化されたことで、次は「どうやってK8s上に確実にマニフェストを配備・運用し、Fleetの価値を引き出すか」が課題となりました。
4.1 構成配信手法の最適化：Cluster SelectorからKustomizeへの移行
マルチクラスタ環境に対して、東京用・台湾用の構成をどのように送り分けるかについて、2つの手法を比較し実装を見直しました。
- 方式1：Cluster Selector( 当初の実装 )
ラベルなどを条件に同期先を振り分ける手法。 深い階層のマニフェストがサイレントスキップされたり、同名Namespaceで競合エラーが多発するなど、Gitの実態とクラスタの状態が一致しない不安定な運用となっていました。 - 方式2：Kustomize Overlay( 変更後の実装 )
設定のスコープを物理的なディレクトリ構造で明示的に分ける手法。 base/ フォルダで共通設定を定義しつつ、overlays/tokyo と overlays/taiwan で環境ごとのパッチだけを当ててConfig Syncに読み込ませる構成にしました。
このアーキテクチャへ移行したことで、意図した通りの完全なGitOps運用とヒューマンエラーの削減が実現しました。
4.2 外部Git連携におけるシークレット管理の壁と自動供給ライン
GitOpsの難所として、「GitHub（=プライベートリポジトリ）の認証情報をいかに安全にConfig Syncへ渡すか」という課題がありました。そこで、以下のコンポーネントを数珠繋ぎにして、「完全なキーレスの自動化ライン」を確立しました。
- Secret Manager： GitHubトークンを安全に保管。
- Workload Identity： GCP権限（GSA）とKubernetes権限（KSA）を鍵ファイルなしで安全に紐付ける。
- External Secrets Operator (ESO)：上記権限を用い、GCP APIを叩いて該当トークンを取得する。
- Kubernetes Secret：取得した情報を元にK8s内のSecretを動的生成し、Config Syncが認証に利用する。
4.3 統合基盤の真価：Fleetによる通信(MCS)とガバナンスの実証
GitOpsの土台が完成したことで、Fleet特有の強力な拡張機能を簡単に横展開できるようになりました。
① MCSを用いたリージョン間通信（通信の壁を超える）
台湾クラスタ内にデプロイされたバックエンドアプリに対し、ServiceExport を適用することでFleet全体へ内部公開しました。 結果として、東京クラスタのPodから 内部DNS名で直接通信を確立し、リージョンを跨いだサービス連携を実証しました。
② Policy-as-Code による統制（ガバナンスの壁を超える）
Policy Controllerを全クラスタにデプロイし、「latestタグの利用を禁止する」などのガードレールを実装しました。 違反するマニフェストをGitOps経由で適用しようとした際、Webhookが作動しクラスタへの適用が正しくブロックされることを確認。Fleet全体に対する強力なガバナンスを証明しました。
5. まとめ、反省点
5.1 全体の振り返りと成果
組織規模でのマルチクラスタ運用を目指し、GKE Fleetによるインフラの抽象化と、Config Sync/Kustomizeによる宣言的なGitOps運用を組み合わせることで、強固でスケーラブルな管理体制が実現できました。
5.2 AIを活用したインフラ構築の学び
今回の検証作業では、コーディングやトラブルシューティングにおいて生成AIをフル活用しました。 AIは、Terraformの土台となるコードの生成や、KNV1029 などのエラー原因の推測・言語化においては非常に強力なパートナーでした。
一方で、第3章で触れた「TerraformとGKE間のライフサイクル競合（デッドロック）」のような複雑な問題に対しては、インフラとアプリの責任分界点をどこに引くべきかという「抽象度の高いアーキテクチャの意思決定」が求められ、人間が方針を定める必要性を強く感じました。 技術の特性を理解した上で、AIをツールとして正しく指揮する力がこれからのエンジニアには不可欠だと実感しました。
5.3 今後の展望
今回の基盤構築を通じて、利用した技術の利点だけでなく、落とし穴（Cluster Selectorの限界など）にも気づくことができました。 今後は、導入したPolicy Controllerの自作ルールの拡張や、Github ActionsなどとのCI連携の領域へと踏み込み、より洗練された基盤運営へと還元していきたいと考えています。