专线切换到云原生环境，容易被忽略的不是设备配置，而是地址在各处被怎样使用。先整理一份网络专线迁移至云原生架构的地址改造清单，把网段、主机地址、域名、服务入口和依赖方放在同一张表里，能减少遗漏，也便于确定变更顺序。
先盘清地址从哪里来、被谁使用
不要只抄路由器配置。地址可能出现在服务器网卡、应用配置文件、域名解析记录、访问控制规则、监控探针和外部合作方的接入设置中。建议以现网配置、资产台账和 DNS 记录为线索，逐项核对实际用途。
- 记录专线两端的网段、网关、静态路由及动态路由通告；标出仍在使用的旧地址和计划保留的地址。
- 整理云侧 VPC 网段，并单独列出 Kubernetes 的节点网段、Pod CIDR 与 Service CIDR。它们由不同网络层使用，不能仅凭网段名称判断是否可以复用。
- 为每个地址标注所属系统、责任人、用途、依赖方和变更窗口；无法确认用途的地址先核实，不要直接删除。
- 查找配置中的固定地址，包括应用连接串、证书或许可绑定、监控目标，以及对端设置的来源地址白名单。
这一步的目标是形成可核验的地址规划，而不是立刻改配置。可用表格记录“现值、目标值、修改位置、验证人、回退值”，让每项变更都有对应责任人。
核对地址空间和云原生服务入口
云端网段需要与仍在运行的站点、办公网络及合作方网络一起检查。若地址重叠，路由设备无法仅凭目的地址判断应走哪一侧，需先调整网段，或设计经过评审的地址转换方案；不要把“专线已通”当成地址可达的证明。
还要区分云原生应用的访问地址。Kubernetes 中，Pod 地址可能随重建变化，通常不适合作为长期写入客户端配置的固定目标；集群内服务一般通过 Service 名称发现。集群外访问则要确认入口类型、负载均衡地址和域名记录由谁维护。具体做法取决于集群网络插件和云平台实现，不能假定所有集群的地址分配方式相同。
把 DNS、路由和访问规则一并改造
先处理名称解析
盘点内部域名的 A、AAAA、CNAME 等记录，确认旧地址是否仍被客户端缓存或写入本地 hosts 文件。切换前可按解析服务的能力提前调低 TTL，但缓存并不会因此立即全部刷新；验证时应同时检查解析结果和实际连接目标。集群内部常见的 DNS 服务包括 CoreDNS，集群外部域名则需确认由哪套 DNS 系统维护。
再检查路径和访问边界
根据目标地址更新相关路由表，核实去程与回程都指向预期网络。随后检查防火墙、安全组和主机访问控制中的源、目的地址与端口规则。应用若依赖来源地址白名单，迁移后实际出口地址可能变化，应由对接方确认并同步更新，不能只改本端配置。
按依赖顺序实施并保留回退条件
- 建变更表：列清地址映射、解析记录、路由、访问规则、关联应用和负责人。
- 先做预检查：核对网段冲突、解析结果、路由可见性及目标端口；不明确的依赖先安排验证。
- 分批切换：先处理低风险服务，再迁移有外部依赖的服务；每批记录实际生效的地址与时间。
- 验证双向通信：从真实调用方测试域名解析、连接和应用响应，同时查看目标端日志，确认访问来源符合预期。
- 设定回退门槛：预先写明失败现象、回退配置和执行人。旧记录或旧路径是否保留，应依据风险和变更窗口决定。
这样整理出的网络专线迁移至云原生架构的地址改造清单，至少应覆盖地址空间、服务入口、DNS、路由、访问规则、验证方式和回退项。迁移完成后，再清理确认无依赖的旧地址，避免过早删除造成后续排障困难。
常见问题
地址规划要不要先改应用，再改网络？
没有统一顺序。先画清依赖关系，再按解析、路由、访问规则和应用配置的实际耦合安排；每一步都要能验证，并明确回退方式。
Pod 地址可以直接给专线对端使用吗？
通常不建议把可能变化的 Pod 地址当作长期服务入口。应先确认集群网络设计和对外访问方式，再选择稳定的服务名或集群外入口。
切换后能否马上删除旧地址？
不要仅凭新地址已能访问就删除。还需检查 DNS 缓存、定时任务、监控和外部白名单等依赖，并按约定观察一段时间后再清理。
新手最先准备什么材料？
准备现网与云侧网段清单、域名记录、路由和访问规则、应用依赖方，以及逐项可执行的验证与回退方案。这些材料共同构成网络专线迁移至云原生架构的地址改造清单。