AI
Why Custom Controllers Are the Wrong Tool for Namespace Lifecycle
Teams create ephemeral namespaces to test pull requests, then need best-practice resources provisioned and old namespaces removed when the PR merges. The obvious answer is a custom controller watching namespaces. That controller then needs scaling logic, monitoring, and reporting bolted on over time. What starts as a small automation project grows into a dedicated engineering effort. Kyverno, a YAML and CEL policy engine built for Kubernetes, handles all three phases without any controller code.
Mutating Policy: Enforcing Compliance Before Resources Persist
Kyverno made the mutating policy stable in version 1.17. It intercepts resources before they reach the Kubernetes database and rewrites them to meet platform requirements. Unlike native Kubernetes admission webhooks, this policy can mutate not just the namespace itself but all underlying child resources as well. Platform engineers encode their compliance rules once in YAML. Every new namespace and its dependents conform automatically, with no manual review step.
Generating Policy: Provisioning Network Policies and Role Bindings Automatically
The generating policy creates specified resources, network policies, role bindings, or anything else, at the moment a namespace is created. All generated resources link back to the parent policy. If the policy is later updated or deleted, every resource it created is updated or deleted in sync. Teams get consistent namespace scaffolding across every environment without scripting per-namespace setup, and auditors get a single policy file that explains every generated object.
Deleting Policy: TTL-Based Cleanup Without a Cron Job
The deleting policy completes the lifecycle. It runs on a schedule, such as hourly, checks namespaces against a TTL annotation, and removes expired ones. This replaces the manual pattern of writing and maintaining cleanup cron jobs per cluster. Once a pull request merges, the namespace ages out and disappears automatically. No operator intervention, no forgotten namespaces accumulating in production clusters.
Three YAML Files Replace a Controller
The full namespace-as-a-service workflow now fits in three YAML policy files checked into a Git repository. Teams can audit them, diff them, and gate changes through pull request review. Nothing is baked into compiled controller code. Kyverno ships integrated reporting and fine-grained exceptions alongside these policies. The talk closes by noting that a deeper session with code examples ran at KyvernoCon the same afternoon.
Notable Quotes
Kano is just not for guardrails but it’s really a platform automation tool and you can use it to do really complicated stuff. Luke Mowski · ▶ 04:05
we have three YAML policies that you can put in your GitHubs pipelines in your um GitHub repositories that you can audit um instead of a controller uh where everything is baked into the code Luke Mowski · ▶ 03:47
if at some point you delete the policy or update it, all the resource will be deleted or updated as well. Luke Mowski · ▶ 03:03
Key Takeaways
- Kyverno 1.17 made the mutating policy stable, covering namespaces and child resources.
- The generating policy links created resources to itself, so updates and deletes cascade automatically.
- Three YAML files in Git replace a custom controller, its scaling logic, and its cleanup cron jobs.
About the Speaker(s)
Ammar Yasser is a software engineer at Nirmata specializing in distributed systems, cloud infrastructure, and container orchestration. He has built expertise in Kubernetes internals and Go programming, contributing to complex platform engineering work including Kyverno maintainership. The talk was delivered by fellow Kyverno maintainer Luke Mowski, who stepped in when Ammar could not attend KubeCon.