将关键Kubernetes部署从默认命名空间迁移，实现零停机
内容提要
本文介绍如何在不中断服务的情况下，将Kubernetes集群中位于默认命名空间的认证服务auth-svc迁移至新命名空间。通过创建ExternalName服务作为转发地址，将旧DNS名指向新位置，实现零协调迁移。同时利用临时策略例外处理入口重叠问题，并先在小规模环境验证，确保安全后完成生产切换。
延伸解读
迁移的关键：区分两条访问路径
文章强调，迁移服务时需同时处理集群内部通过DNS名称的访问和外部通过Ingress的访问。仅关注一条路径可能导致另一条路径中断。这种双路径思维是设计零停机迁移方案的基础，也提醒读者在类似操作中先梳理所有访问入口。
ExternalName服务的巧妙应用
利用ExternalName服务将旧Service转换为转发地址，实现消费者无感知的迁移。这类似于邮政转发，无需协调所有调用方更新地址。但前提是消费者通过DNS名称访问，而非硬编码IP。若存在绕过DNS的调用，则此方法失效，需另寻方案。
策略例外与安全验证的必要性
面对OPA策略禁止重复Ingress的规则，作者采用临时注解创建例外，实现新旧Ingress短暂共存，避免流量空窗。同时，迁移前在开发、预生产环境验证，并保留旧Pod（缩容至零）以便快速回滚。这些措施降低了生产切换风险，值得借鉴。
Q&A
如何在不中断服务的情况下将Kubernetes服务从默认命名空间迁移到其他命名空间？
可以使用ExternalName服务作为转发地址。首先在新命名空间部署服务，然后将旧命名空间中的Service对象改为ExternalName类型，指向新命名空间的DNS名称，这样所有通过旧DNS名访问的流量都会被自动转发到新位置，无需修改消费者配置。
为什么不能直接移动Kubernetes中的服务？
直接移动服务需要同时更新所有引用该服务的其他服务，但这些服务由不同团队维护，发布周期不同，无法实现原子切换。此外，部署工具可能不支持同时部署到两个命名空间，而且OPA策略禁止两个命名空间存在相同的Ingress规则，导致迁移困难。
ExternalName服务在Kubernetes中有什么作用？
ExternalName服务将服务映射到外部DNS名称，而不是选择Pod。它类似于CNAME记录，可以将请求转发到集群内部或外部的其他服务。在迁移场景中，它可以将旧服务名指向新命名空间中的服务，实现无缝重定向。
在迁移过程中如何处理Ingress规则冲突？
通过临时策略例外解决。在目标命名空间添加注解（如policy.example.com/allow-duplicate-ingress: "true"）以允许短时间内的重复Ingress，然后创建新Ingress，验证流量正常后删除旧Ingress，最后移除注解。
迁移后如何验证服务是否正常工作？
在迁移过程中，通过监控指标确认流量是否真正到达新部署，而不是失败或循环。在确认流量正常后，才将旧Pod缩容到零，而不是直接删除，以便快速回滚。
为什么在迁移时选择将旧Pod缩容到零而不是直接删除？
缩容到零可以保留Pod定义，便于快速回滚。如果直接删除，一旦出现问题需要重新创建，耗时且风险高。缩容到零成本低，且提供了安全网。
迁移过程中如何确保集群内部和外部流量都不中断？
集群内部流量通过ExternalName服务重定向到新命名空间，外部流量通过Ingress迁移。先创建新Ingress并验证，再删除旧Ingress，确保两个路径都平滑过渡。
为什么默认命名空间中的服务会积累？
因为缺乏推动力。虽然可能有策略限制新服务进入默认命名空间，但已存在的服务没有明确的迁移计划或截止日期，导致它们长期留在默认命名空间，直到需要命名空间级功能时才被迫迁移。
