Ask any developer on a team that has recently adopted stricter Kubernetes governance and the word that comes up most often is "tickets." Tickets to create a namespace. Tickets to increase a resource quota. Tickets to add a new service account. Tickets to get an exemption from a policy that makes no sense for the specific workload in question.
The platform team that built these governance processes almost certainly did not intend to create a ticket-driven bottleneck. They were responding to real problems: runaway resource consumption, security misconfigurations, namespace sprawl, teams deploying without proper labels. The intent was to prevent chaos. The result was a different kind of chaos, where engineering velocity dropped and the platform team became a service desk.
This is a design failure, not an intent failure. Governance that slows down the teams it governs is not working governance. It is just overhead.
What Governance Is Actually For
Governance in the Kubernetes context serves three functions. The first is safety: preventing configurations that would destabilize shared infrastructure. A pod running with hostNetwork: true in a shared cluster is a genuine safety concern, not a bureaucratic one. The second is fairness: ensuring that one team's resource consumption does not impact another team's workload. ResourceQuotas and LimitRanges are the primary mechanism here. The third is auditability: being able to answer the question "who changed what and when" after an incident.
Notice what is not on this list: approval workflows for every routine deployment action. The governance machinery that adds the most friction tends to be exactly the governance that is not actually serving safety, fairness, or auditability. It is serving process for its own sake.
A useful diagnostic question is: what happens if this governance step is skipped? If the answer is "nothing bad, it just violates an internal process," the governance step is probably overhead. If the answer is "a tenant could exhaust cluster memory" or "a misconfigured container could gain host network access," the governance step is earning its friction.
Admission Control: Enforcement Without Human Review
The most effective governance mechanism in Kubernetes is one that developers never interact with directly: admission control. A ValidatingWebhookConfiguration or a Kyverno policy that blocks non-compliant resources at apply time gives you safety guarantees without a human reviewer in the loop for every deployment.
Consider the difference between these two approaches to enforcing label requirements:
- Process approach: Platform team reviews every new deployment request and checks for required labels before approving. Developer waits for review.
-
Admission control approach: A policy rejects any Deployment object that does not include
teamandapplabels. Developer gets an immediate, clear error at apply time. No review needed.
The admission control approach is faster for the developer (immediate feedback), more consistent (the policy runs for every apply, not just the ones a reviewer catches), and reduces load on the platform team. It also produces better behavior: developers who get an immediate rejection with a clear message about missing labels will add the labels. Developers who submit a ticket and wait a day may not understand what they did wrong.
This does not mean admission control is appropriate for everything. Complex resource requests that require human judgment about cluster capacity or security posture should still involve human review. The point is to move as much governance as possible from "human reviews this" to "policy enforces this at apply time."
A policy that enforces itself at apply time is governance that scales. A policy that requires a human reviewer for every deployment is governance that creates a bottleneck proportional to your deployment frequency.
ResourceQuotas That Reflect Actual Usage
ResourceQuotas are the primary mechanism for multi-tenancy fairness in shared clusters. They work well when they are set appropriately. They create significant friction when they are not.
The common failure mode is quoting namespaces based on initial estimates that are never updated. A team provisioned three months ago with a quota sized for their initial workload, which has since grown, is constantly hitting quota limits. They file tickets. The platform team adjusts the quota. This repeats every quarter.
A better approach: set initial quotas generously, with automatic alerting when a namespace reaches a threshold of its quota, and a defined self-service process for quota increases that does not require platform team approval for incremental changes within a defined range. A team that can increase their quota by 20% without filing a ticket, subject to cluster-wide capacity checks, has dramatically fewer interactions with the platform team for routine scaling.
The platform team's job here shifts from approving individual quota changes to monitoring overall cluster capacity and flagging namespaces that are systematically over-provisioned relative to actual utilization. That is a more interesting and more valuable function than being a quota increase approval desk.
The Role of Defaults in Reducing Governance Burden
Most governance enforcement work is corrective: catching configurations that are wrong and requiring fixes. A significant amount of this work can be eliminated by making the default configuration correct in the first place.
LimitRange objects set default resource requests and limits for pods in a namespace that do not specify their own. A developer who creates a Deployment without resource requests in a namespace with a LimitRange gets reasonable defaults automatically. They do not fail validation, do not need to file a ticket, and do not create a pod that could starve other workloads. The governance goal is achieved without any developer interaction.
Similarly, namespace-level default labels for the team and environment annotations, populated from a simple namespace provisioning template, mean that pods inherit correct attribution without developers having to know the label schema. The admission control policy that validates label presence passes automatically for pods in well-configured namespaces.
Neither of these mechanisms requires a new tool or a complex policy engine. They use standard Kubernetes objects. The investment is in designing the default configuration thoughtfully rather than adding more review steps to handle configurations that deviate from defaults that were never set.
Approval Workflows for the Cases That Actually Need Them
None of the above is an argument against human approval in governance. The argument is that human approval should be reserved for cases where human judgment genuinely adds value.
Changes that benefit from human review: elevated cluster-admin permissions in production, network policies that open broad egress to external IP ranges, production namespace provisioning for a new team, and anything involving PersistentVolume claims in production where data loss risk is real. These are cases where the risk of a wrong decision is high enough to justify a review latency.
Changes that do not benefit from human review: routine scaling events, adding a sidecar container to an existing deployment, updating a ConfigMap, creating a staging namespace, requesting standard resource quotas within defined ranges. These are cases where automated policy enforcement is faster and more consistent than review.
When approval workflows are scoped to the cases that actually need them, two things happen. First, the platform team's review load drops substantially, allowing them to actually do the review carefully on the cases that matter. Second, developer trust in the governance process increases because the approvals they do encounter are clearly there for a reason, not reflexive process for its own sake.
Governance as a Developer Tool
The mental model shift that makes governance work is thinking about it from the developer's perspective rather than the platform team's perspective. A developer interacting with governance is most likely trying to do something that is completely routine for their job. The question is not "how do we ensure they follow the process" but "how do we make the process invisible for routine cases while still achieving our safety and fairness goals."
Admission control that gives immediate, clear feedback at apply time is more developer-friendly than a review queue, even though it is also stricter. Smart defaults that eliminate the need to know the label schema are more developer-friendly than a wiki page listing required labels, even though they achieve the same compliance goal. A self-service quota increase within defined bounds is more developer-friendly than a ticket, even though both ultimately adjust the same configuration value.
This is not about lowering the bar for what is permitted. It is about reducing the friction for things that should be permitted. The goal is a platform where compliant behavior is the path of least resistance, not because you have blocked every other path, but because you have made the right path genuinely easy.