George Sims explains in an article published on the CNCF blog on September 3, 2026, an experience migrating a core authentication service in a Kubernetes cluster from the default namespace to a dedicated namespace without stopping the service. The service, which the author called auth-svc, was continuously used by dozens of services and was responsible for authenticating users in an entire area of the cluster; therefore, its outage would have prevented logins in that area.
The problem was not simply moving a Deployment object to another namespace. Consumers inside the cluster accessed the service through the name auth-svc.default.svc.cluster.local, while users outside the cluster accessed it through a separate Ingress. The consuming services were also owned by different teams and operated according to varying release schedules, making it impractical to modify all references at once.
Why Isn’t Moving the Service and Updating References Enough?
The author notes that the deployment pipeline supported deploying the service in only one namespace and was not designed to run two versions simultaneously. Modifying the shared pipeline logic would have affected other teams, which the team wanted to avoid. There was also an OPA-based policy that prevented identical Ingress rules from existing in two namespaces at the same time, to prevent ambiguous routing resulting from an incomplete migration.
For this reason, the solution was not based on forcing every consumer to know the new address, but on keeping the old address temporarily valid and redirecting it to the migrated service.
ExternalName as a Redirection Address
After deploying the actual version of the service in the new authentication namespace, the old Service object in default was converted into a service of type ExternalName. Its name was made to point to auth-svc.authentication.svc.cluster.local, allowing services that used the old address to continue reaching the new version without immediate changes to their code or redeployment.
The author compares this mechanism to a mail-forwarding service: there is no need to contact everyone who has the old address; requests are simply directed to the new location until consuming parties gradually update their addresses. However, this approach depends on consumers using a DNS name. If some systems connect to a fixed IP address or bypass DNS, the situation will not be the same, and the migration will require different handling.
Before shutting down the old version, the team monitored metrics to ensure that requests arriving at the old address actually reached the new Deployment and did not fail or enter a redirection loop. After verification, the number of old replicas was reduced to zero instead of deleting them immediately. This provided a quick rollback path by restarting the old replicas if a problem emerged, while postponing final deletion until later.
Handling the Ingress Conflict
The external access path required an Ingress in the new namespace before removing the old Ingress. However, the OPA policy prevented both identical rules from being created at the same time. The team therefore used a temporary, targeted exception instead of disabling the policy entirely: a label was added to the authentication namespace to allow bypassing the duplicate Ingress check during the migration, using the key policy.example.com/allow-duplicate-ingress: "true".
During the short overlap window, the new Ingress was run alongside the old one, and the team then verified that traffic reached the new Deployment. After that, the old Ingress was deleted, and the temporary exception was allowed to expire rather than being treated as a permanent setting.
What Changes in Practice?
The experience shows that migrating a sensitive service does not necessarily require synchronous coordination with every consumer if there is a clear DNS-based boundary. However, this does not eliminate the need for phased testing, careful monitoring, and a rollback plan. The team first carried out the process in the development environment, then in the testing environment, and waited two weeks after the testing phase succeeded before performing it in production.
The broader lesson is that the accumulation of services in the default namespace may remain unnoticed until a service needs policies or resources restricted to a dedicated namespace. At that point, the operational debt becomes a real problem. ExternalName provides a practical path for services that rely on DNS, but it is not a universal solution for systems that use fixed addresses. Likewise, the overlap window and security exception must be intentional and temporary, and must be accompanied by clear measurements.