It's not totally clear from reading this if this is actually referring to production deployments. It says this, but then devotes some of the article to explaini

It's not totally clear from reading this if this is actually referring to production deployments. It says this, but then devotes some of the article to explaining how they developed a subtyping system for clusters allowing them to deploy multiple development clusters that individual teams can play with and not step on each other. I understand why you would update that 125,000 times a year, because it's your developer feedback loop, same as compile/test/rewrite on a single machine but for distributed system development. I have to do the same thing. But that isn't a production deployment. I'm really curious what could possibly have change frequency that necessitates that many production deployments. Something I noticed when trying to see why my local homelab network is constantly getting contention throttling when I'm trying to run a minimal local cluster is storing HelmRelease for FluxCD where the source is a GitRepository rather than a HelmRepository means you pull in changes every reconcile even if they aren't changes to the chart and don't do anything to the cluster. You need to be really disciplined about having a git repo be a Helm chart and only a Helm chart. Otherwise, you pull in documentation updates, typo fixes, and all kinds of stuff that doesn't actually change your deployment state but kills your network anyway. One of the downsides of a polling based git ops deployment model.