--- title: Migrating a critical Kubernetes deployment from the... description: A detailed walkthrough describes moving a critical authentication service out of Kubernetes' default namespace without downtime, despite dozens of internal... canonical: https://daily.dev/posts/migrating-a-critical-kubernetes-deployment-from-the-default-namespace-without-any-downtime-4hrd2zfrz twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Migrating a critical Kubernetes deployment from the default namespace without any downtime | daily.dev og:description: A detailed walkthrough describes moving a critical authentication service out of Kubernetes' default namespace without downtime, despite dozens of internal... og:url: https://daily.dev/posts/migrating-a-critical-kubernetes-deployment-from-the-default-namespace-without-any-downtime-4hrd2zfrz og:image: https://api.daily.dev/og/posts/4Hrd2zfrZ.png og:image:alt: Migrating a critical Kubernetes deployment from the default namespace without any downtime og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Migrating a critical Kubernetes deployment from the default namespace without any downtime **[CNCF](https://daily.dev/sources/cncf)** · 7 min read · 16 upvotes · 3 comments ## Summary A detailed walkthrough describes moving a critical authentication service out of Kubernetes' default namespace without downtime, despite dozens of internal consumers referencing it by DNS name and an external ingress path. The key technique uses a Kubernetes ExternalName Service as a forwarding CNAME so internal callers keep resolving the old address while traffic is silently redirected to the new namespace. For the ingress side, a temporary OPA policy exception allows both old and new ingress rules to coexist briefly during a controlled cutover window, after which the old resources are scaled to zero (not deleted) for safe rollback before eventual cleanup. The approach was validated in dev and staging weeks before the production cutover, which ended up being uneventful because the design work absorbed all the risk. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How do I move a Kubernetes service out of the default namespace without breaking consumers that reference it by DNS name? Deploy the real service in its new namespace, then convert the old Service object in the default namespace into an ExternalName service pointing to the new one, for example externalName auth-svc.authentication.svc.cluster.local. This acts like a CNAME, so consumers still resolving auth-svc.default.svc.cluster.local get silently redirected to the new location with zero code changes on their end. _Engineers planning namespace migrations can find patterns like this ExternalName trick surfaced on daily.dev._ ### How can I have two ingress objects with identical rules active during a migration if a policy blocks duplicate ingress across namespaces? Add a temporary annotation to the new namespace that bypasses the duplicate-ingress check just for the migration window, such as policy.example.com/allow-duplicate-ingress: true. This lets the new ingress run alongside the old one briefly so traffic can be verified before the old ingress is deleted and the exception allowed to age out. _Teams navigating policy constraints during cutovers often track these workaround patterns on daily.dev._ ### Should I delete old Kubernetes pods immediately after cutting traffic over to a new deployment during a migration? No, scale the old pods to zero instead of deleting them right after a migration cutover. Scaling to zero costs nothing while preserving an instant rollback path (just scale back up) if something looks wrong downstream, whereas deleting them outright would mean rebuilding from scratch if the cutover needs to be reversed. _daily.dev helps engineers weighing rollback safety against cleanup speed during service migrations._ ## Community discussion Top comments from developers on daily.dev. **@trevorsuna** · 0 upvotes > Using an ExternalName service as a temporary forwarding address is a clean way to preserve old DNS contracts during the move. Scaling the original deployment to zero before deletion is equally important; it keeps rollback cheap while metrics and client behavior prove the new namespace is actually safe. **@kelvin\_lima** · 0 upvotes > This is the kind of migration that looks terrifying on paper but goes smoothly when you actually plan it right, and the real hero here is all the testing they did beforehand. **@agustinbarrientos** · 0 upvotes > That temporary OPA exception got an expiration date, right? ## Similar posts on daily.dev - [Stop Hardcoding External URLs in Kubernetes: A Guide to ExternalName Services](https://daily.dev/posts/stop-hardcoding-external-urls-in-kubernetes-a-guide-to-externalname-services-gu3w6spqv) · Medium · 0 upvotes · 0 comments - [No Downtime Migration from Ingress NGINX to Gateway on DOKS](https://daily.dev/posts/no-downtime-migration-from-ingress-nginx-to-gateway-on-doks-e412kb7ku) · DigitalOcean Community · 2 upvotes · 0 comments - [Zero-Downtime migration from ingress NGINX to Envoy Gateway](https://daily.dev/posts/zero-downtime-migration-from-ingress-nginx-to-envoy-gateway-kze8pl5lt) · CNCF · 49 upvotes · 3 comments --- Tags: [#kubernetes](https://daily.dev/tags/kubernetes), [#dns](https://daily.dev/tags/dns) [View this post on daily.dev](https://daily.dev/posts/migrating-a-critical-kubernetes-deployment-from-the-default-namespace-without-any-downtime-4hrd2zfrz) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Migrating a critical Kubernetes deployment from the default namespace without any downtime","url":"https://daily.dev/posts/migrating-a-critical-kubernetes-deployment-from-the-default-namespace-without-any-downtime-4hrd2zfrz","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/migrating-a-critical-kubernetes-deployment-from-the-default-namespace-without-any-downtime-4hrd2zfrz"},"datePublished":"2026-09-03T11:04:58.098Z","dateModified":"2026-09-03T11:15:25.551Z","description":"A detailed walkthrough describes moving a critical authentication service out of Kubernetes' default namespace without downtime, despite dozens of internal...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/bbb7498bc2a279854c968f979e98dfa2?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/bbb7498bc2a279854c968f979e98dfa2?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"CNCF","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"CNCF","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/55536a03390741eebd96d2f9b74d2d8d","url":"https://daily.dev/sources/cncf"},"commentCount":3,"discussionUrl":"https://daily.dev/posts/migrating-a-critical-kubernetes-deployment-from-the-default-namespace-without-any-downtime-4hrd2zfrz","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":16},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":3}],"keywords":"kubernetes,dns","timeRequired":"PT7M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"CNCF","item":"https://daily.dev/sources/cncf"},{"@type":"ListItem","position":3,"name":"Migrating a critical Kubernetes deployment from the default namespace without any downtime"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/migrating-a-critical-kubernetes-deployment-from-the-default-namespace-without-any-downtime-4hrd2zfrz","comment":[{"@type":"Comment","text":"Using an ExternalName service as a temporary forwarding address is a clean way to preserve old DNS contracts during the move. Scaling the original deployment to zero before deletion is equally important; it keeps rollback cheap while metrics and client behavior prove the new namespace is actually safe.","datePublished":"2026-09-06T01:55:25.888Z","url":"https://daily.dev/posts/4Hrd2zfrZ#c-5IrtCmUiz","author":{"@type":"Person","name":"Trevor Suna","url":"https://daily.dev/trevorsuna","image":"https://media.daily.dev/image/upload/s--dZ7gXxpp--/f_auto/v1784081551/avatars/avatar_EMoP47rpuw8DNjhp6R1b6?_a=BAMAMicg0"}},{"@type":"Comment","text":"This is the kind of migration that looks terrifying on paper but goes smoothly when you actually plan it right, and the real hero here is all the testing they did beforehand.","datePublished":"2026-09-08T08:34:09.361Z","url":"https://daily.dev/posts/4Hrd2zfrZ#c-GqrFAN3NN","author":{"@type":"Person","name":"Kelvin Lima","url":"https://daily.dev/kelvin_lima","image":"https://media.daily.dev/image/upload/s--aETMiQc5--/f_auto/v1787513560/avatars/avatar_asGeTu7mKynRnhXcOxYVt?_a=BAMAMicg0"}},{"@type":"Comment","text":"That temporary OPA exception got an expiration date, right?","datePublished":"2026-09-09T11:46:11.843Z","url":"https://daily.dev/posts/4Hrd2zfrZ#c-JPJeocO43","author":{"@type":"Person","name":"Agustin Barrientos","url":"https://daily.dev/agustinbarrientos","image":"https://media.daily.dev/image/upload/s--5ayxQnqn--/f_auto/v1788281802/avatars/avatar_wQYYVe5Tbj0NJ7C7qPoa8?_a=BAMAMicg0"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/migrating-a-critical-kubernetes-deployment-from-the-default-namespace-without-any-downtime-4hrd2zfrz#faq","mainEntity":[{"@type":"Question","name":"How do I move a Kubernetes service out of the default namespace without breaking consumers that reference it by DNS name?","acceptedAnswer":{"@type":"Answer","text":"Deploy the real service in its new namespace, then convert the old Service object in the default namespace into an ExternalName service pointing to the new one, for example externalName auth-svc.authentication.svc.cluster.local. This acts like a CNAME, so consumers still resolving auth-svc.default.svc.cluster.local get silently redirected to the new location with zero code changes on their end. Engineers planning namespace migrations can find patterns like this ExternalName trick surfaced on daily.dev."}},{"@type":"Question","name":"How can I have two ingress objects with identical rules active during a migration if a policy blocks duplicate ingress across namespaces?","acceptedAnswer":{"@type":"Answer","text":"Add a temporary annotation to the new namespace that bypasses the duplicate-ingress check just for the migration window, such as policy.example.com/allow-duplicate-ingress: true. This lets the new ingress run alongside the old one briefly so traffic can be verified before the old ingress is deleted and the exception allowed to age out. Teams navigating policy constraints during cutovers often track these workaround patterns on daily.dev."}},{"@type":"Question","name":"Should I delete old Kubernetes pods immediately after cutting traffic over to a new deployment during a migration?","acceptedAnswer":{"@type":"Answer","text":"No, scale the old pods to zero instead of deleting them right after a migration cutover. Scaling to zero costs nothing while preserving an instant rollback path (just scale back up) if something looks wrong downstream, whereas deleting them outright would mean rebuilding from scratch if the cutover needs to be reversed. daily.dev helps engineers weighing rollback safety against cleanup speed during service migrations."}}]} ```