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に意図を宣言し、エージェントがそれを監視して実現するエージェントベースのアプローチだった。
GitOpsはここから、「宣言的であること」「バージョン管理され不変であること」「pullベースであること」「継続的に調整（リコンサイル）されること」という4つの原則に整理された。この4原則があったからこそ、GitOpsは単一クラスタの管理にとどまらず、10・100・1000クラスタといったフリート全体の管理へと拡張できた。
必要なツール一式を「カタログ」としてまとめ、Argo CDやSveltosのようなコントロールプレーンにthird-partyのツールを取り込み、ラベル1つでクラスタ群に配布・調整させる。App of Apps、ApplicationSetとClusterGeneratorの組み合わせ、Kustomizeによるオーバーレイなど手法は複数あるが、狙いは同じだ。車輪の再発明を避け、構成をセルフサービスとして提供することにある。
スケールが生んだ代償と、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）では実際に再起動して一時的に利用不能になった。
Git自体もプロトコルとしての限界に直面する。1000クラスタ・1000エージェントが同時に同期を試みれば、Gitのクローンとポーリングだけでは重荷になる。こうした乱立の中でチームは可視性を失い、「レンダリング」の必要性に気づいた。
HelmやKustomizeが実際にクラスタへ適用されるKubernetesマニフェストを覆い隠してしまうという課題に対し、OCIファーストの配信ツール「Kokumi」、DevOpsの制御を取り戻すことを掲げる「ConfigHub」、そしてArgo CD自身がアルファ機能として提供する「Source Hydrator」やArgo CD Diff Previewといった、同期前にハイドレートされたマニフェストと実際の差分を確認できるツール群が登場してきた。
