GKEでOCMを導入した際のつまずき5点を整理　マルチクラスタ運用の実務論点

GKEでOCMを導入した際のつまずき5点を整理　マルチクラスタ運用の実務論点

編集: グリットアーツ編集部

公開日：2026年10月10日

GKEでOCMを導入した際のつまずき5点を整理　マルチクラスタ運用の実務論点

3行解説

  • CyberAgentが、GKEにOCMとFleetConfig Controllerを入れた際の失敗例を公開した。
  • 詰まりどころは、到達性、HubのEndpoint指定、イメージ取得権限、トークン期限だった。
  • マルチクラスタ運用をGitOps化する際の事前確認項目が具体化された。

ニュースの概要

CyberAgent Developers Blogは2026年9月29日、GKE上にOpen Cluster Management（OCM）と、そのAdd-onであるFleetConfig Controllerを導入した際のつまずきポイントをまとめた。記事では、Hub ClusterとSpoke ClusterをGKE Standard modeで構成し、Argo CD経由でHelm Chartとしてデプロイした流れを説明している。あわせて、clusteradm相当の処理をHub/Spokeのカスタムリソースで扱う構成を採用した理由も示した。

何が新しいのか

この投稿の新しさは、OCMの一般論ではなく、GKEで実際に導入したときの失敗点を5つに分けていることにある。特に、Spoke側のgcp_public_cidrs_access_enabledがfalseだと、master authorized networksに0.0.0.0/0を入れていてもHubからの接続が通らず、clusteradm joinがi/o timeoutになる点は、GKE特有の確認事項として重要だ。さらに、Hub CRのspec.apiServer未指定でHubのEndpointがin-clusterアドレスになり、Spoke側でTLS検証に失敗した点も、GKEでは見落としやすい。

GKEでOCM導入時の流れ
HubにOCM配置
→
Spokeを参加
→
Endpointと権限調整

記事では、この途中でネットワーク、証明書、イメージ取得、トークン期限の問題が順に表面化した。

また、klusterlet系はspec.klusterlet.values.images.overridesで上書きできた一方、fleetconfig-controller-agentはspec.addOns[].deploymentConfig.registries.sourceとmirrorの指定が別途必要で、漏れるとArtifact Registry経由で403 Forbiddenになった。つまり、同じ「イメージの向き先変更」でも、コンポーネントごとに設定経路が違う。GitOpsでまとめて管理したい場合ほど、この差分を把握しておく必要がある。

グリットアーツ編集部の分析

この事例で実務上の価値が高いのは、OCMそのものよりも、GKEでマルチクラスタ運用を始めるときの失敗パターンが具体化されている点だ。たとえば、Cloud NAT経由の到達性、HubのAPI Server URL明示、Artifact Registryの参照権限、bootstrap tokenの期限管理は、どれも設計段階で見落とすと後から切り分けに時間がかかる。逆に言えば、PoCの段階でここを確認できれば、本番移行時の手戻りを減らしやすい。Argo CDで管理している点も、増設や更新の手順を標準化したい企業には参考になる。

日本の現場で考えると

日本企業のGKE運用では、クラウド接続の制約や権限分離が厳しいことが多く、今回のような「見た目は通っているのに実際は弾かれる」問題が起きやすい。特に、HubとSpokeを別プロジェクトに分ける構成では、ネットワーク到達性とArtifact Registryの参照権限を別々に確認する必要がある。向いているのは、複数クラスタをGitOpsで揃えたい運用。慎重に見るべきなのは、公開IPや外部到達性を絞り込みたい環境、あるいは証明書やRBACの管理を厳格に分けたい環境だ。

導入・検討時に確認したいこと

  • HubからSpokeのkube-apiserverへ到達できる経路が、GKEの設定込みで成立するか。
  • gcp_public_cidrs_access_enabledやmaster authorized networksの組み合わせで、想定どおり接続できるか。
  • HubのEndpointをspec.apiServerで明示する必要があるか、環境ごとに確認すること。
  • klusterlet系とfleetconfig-controller-agentで、イメージ参照の設定経路が分かれていないか。
  • bootstrap tokenの有効期限と再発行手順を、運用手順として固定できるか。

現時点で分かっていないこと

記事では、最後にwebhookのClusterRoleBindingエラーでCrashLoopBackOffになったところまで触れているが、詳細原因と再発防止策は示されていない。また、今回の構成がどの規模のクラスタ数まで想定されているか、運用監視の具体的な設計も本文からは分からない。

マルチクラスタ運用は、設計よりも接続経路や権限、更新手順でつまずきやすい領域です。自社のGKEやKubernetes運用で同様の論点がある場合は、構成整理の観点から見直す価値があります。

ITインフラの構築・保守をご検討の方へ

「自社の環境にはどんな構成・保守体制が合うのか」お悩みではありませんか。貴社の現場課題に合わせたご提案をいたします。まずはご相談からお気軽にどうぞ。

お問い合わせ導入事例を見る

出典: CyberAgent Developers Blog