Topic starter
08/07/2026 6:52 pm
TL;DR: At scale, the first Kubernetes operator degraded because each secrets resource carried its own connection and authentication state, creating memory pressure, rate-limit bursts, and mass-edit overhead as clusters grew, according to Infisical. The rebuild shifts to shared connection and auth objects, showing that secrets management architectures must reduce per-resource identity duplication before scale turns convenience into operational risk.
Editorial analysis by NHI Mgmt Group, based on content published by Infisical: “Our Kubernetes Operator Didn’t Scale, So We Rebuilt It”.
Key questions
Q: What breaks when every Kubernetes secret resource carries its own credentials and endpoint state?
A: The controller repeats the same identity work across every resource, which inflates memory usage, increases authentication bursts after restarts, and makes simple changes expensive to propagate.
Q: Why does duplicated machine identity state create operational risk in Kubernetes?
A: Because Kubernetes workloads churn constantly, any identity model that assumes stable, long-lived resources turns normal restarts into retry storms and configuration sprawl.
Q: How should teams redesign Kubernetes secrets governance for scale?
A: Treat connection details, authentication, and secret delivery as separate governance objects, then reference them from workload resources.
Practitioner guidance
- Define shared connection objects Separate upstream endpoint configuration from individual secret sync resources so host changes do not require editing every workload definition.
- Reuse shared authentication objects Make one machine identity usable by many secret resources so the controller can cache by identity instead of instantiating a client per resource.
- Audit CRDs for duplicated identity state Check whether credentials, host details, and secret scope are embedded in each resource, then refactor those fields into reusable references.
Bottom line: The core problem is duplicated authentication and connection state, which turns a convenient Kubernetes secret pattern into a scaling liability.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
08/07/2026 7:13 pm
Per-resource identity duplication is the real scaling failure: the first operator did not fail because secrets management is inherently unscalable, but because each resource carried its own identity and connection state. That design creates unnecessary client replication, memory pressure, and mass-edit overhead as Kubernetes resources multiply. The implication is that identity architecture must be deduplicated before operational convenience collapses under cluster growth.
A few things that frame the scale:
- Kubernetes production adoption has surged from 66% in CNCF's 2023 survey to 82% in 2025.
A question worth separating out:
Q: What is the difference between per-resource secret syncing and reference-based secret syncing?
A: Per-resource syncing embeds credentials and endpoint details inside each secret object, so every object manages its own client. Reference-based syncing pulls those shared details into reusable objects, which lowers memory pressure, reduces update overhead, and creates a cleaner lifecycle boundary for machine identity.
👉 Read our full editorial: Kubernetes operator scaling exposes secrets management tradeoffs