「Gitは単一の信頼できる情報源ではない」──9年間のGitOps実践が導いた、Platform Engineeringの現在地

【KubeCon + CloudNativeCon Japan 2026】The Evolution of GitOps in Platform Engineering

　GitOpsは2017年、4つのシンプルな原則から始まった。しかし、1万5000クラスタという規模に達したとき、config sprawlやKubernetes APIサーバーの過負荷という形でその限界が露呈した。iits-ConsultingでHead of Platform Engineeringを務めるArtem Lajko氏が、GitOpsの誕生からOCIベースの「Gitless GitOps」、420万ユーロを投じても64％のエンジニアに迂回されたIDP構築のつまづき、そしてAIエージェントの登場まで、約9年間の実務経験を振り返りその軌跡を語った。

GitOpsは4つの原則があったからスケールすることができた

　WeaveworksのCEOだったAlexis Richardson氏が2017年に「GitOps」と名付けたとき、解決したかったのはVM間をRDPやSSHで飛び回って設定ファイルを直接編集する、10台なら耐えられても300台では破綻するスケールの問題だった。

　Ansible・Terraform・Chef・Puppetといった「as Code」ツール群がインフラをコード化したが、それでも各エンジニアが自分のマシンから変更を実行する「Local Ops」の課題は解決しなかった。パイプラインに実行を委ねる「Pipe Ops」に移っても同じで、Artem Lajko氏は当時を「ツールを変えても、心構えは変わらない」と振り返る。行き着いたのが、ユーザーがGitやOCIに意図を宣言し、エージェントがそれを監視して実現するエージェントベースのアプローチだった。

iits-Consulting Head of Platform Engineering Artem Lajko氏

　GitOpsはここから、「宣言的であること」「バージョン管理され不変であること」「pullベースであること」「継続的に調整（リコンサイル）されること」という4つの原則に整理された。この4原則があったからこそ、GitOpsは単一クラスタの管理にとどまらず、10・100・1000クラスタといったフリート全体の管理へと拡張できた。

　必要なツール一式を「カタログ」としてまとめ、Argo CDやSveltosのようなコントロールプレーンにthird-partyのツールを取り込み、ラベル1つでクラスタ群に配布・調整させる。App of Apps、ApplicationSetとClusterGeneratorの組み合わせ、Kustomizeによるオーバーレイなど手法は複数あるが、狙いは同じだ。車輪の再発明を避け、構成をセルフサービスとして提供することにある。

third-partyツールをコントロールプレーンに取り込み、ラベルベースで複数クラスタに配布・調整する仕組み

スケールが生んだ代償と、Git自体のプロトコルの限界

　4原則に従っている限りは予測可能でスケーラブルだったはずのGitOpsだが、実際にはGitOpsエンジンにコードの実行そのものを任せるようになり、複雑性を押し流す先が増えていく。Helmのumbrella chartに値を積み重ね、クラスタごとのオーバーレイを重ねていくうちに、「今この環境で何が起きているか」を理解するのが難しくなる。これがconfig sprawl（設定の乱立）だ。

　2022年には、より深刻な事態も起きている。クラウドインフラをKubernetesリソースとして扱うCrossplaneが数千のCRD（Custom Resource Definition：カスタムリソースを自分で定義してKubernetesのAPIを拡張できる仕組み）を生成し、Kubernetes APIサーバーに大量のリクエストと巨大なスキーマの再計算を強いた結果、APIサーバーが不安定になり、Google Cloud Platform（Google Kubernetes Engine）では実際に再起動して一時的に利用不能になった。

Crossplaneが生成した大量のCRDがKubernetes APIサーバーを過負荷にし、GKEでは一時的に利用不能になった

　Git自体もプロトコルとしての限界に直面する。1000クラスタ・1000エージェントが同時に同期を試みれば、Gitのクローンとポーリングだけでは重荷になる。こうした乱立の中でチームは可視性を失い、「レンダリング」の必要性に気づいた。

　HelmやKustomizeが実際にクラスタへ適用されるKubernetesマニフェストを覆い隠してしまうという課題に対し、OCIファーストの配信ツール「Kokumi」、DevOpsの制御を取り戻すことを掲げる「ConfigHub」、そしてArgo CD自身がアルファ機能として提供する「Source Hydrator」やArgo CD Diff Previewといった、同期前にハイドレートされたマニフェストと実際の差分を確認できるツール群が登場してきた。