4. 迁移场景分类：同集群内镜像仓库切换、跨集群迁移、镜像版本批量升级、私有仓库域名变更

ConfigMap 中镜像配置的迁移并非单一操作，实际生产中通常面临四种典型场景。每种场景的触发条件、风险等级、操作复杂度差异显著，需要采用不同的策略与工具链。本章逐一拆解这四类场景，并给出对应的迁移模式与关键控制点。

4.1 场景一：同集群内镜像仓库切换

触发条件：同一 Kubernetes 集群内，因镜像仓库服务迁移（如从 Docker Registry 切换到 Harbor）、仓库命名空间重组、或镜像仓库域名内部解析变更，导致 Pod 需要拉取新仓库地址的镜像。

风险等级：中。仅涉及镜像地址前缀变更，镜像内容不变，但需确保新仓库已同步旧镜像且凭证正确。

迁移模式：

• 模式 A（原地替换）：直接修改 ConfigMap 中 image: 字段的仓库地址前缀，然后滚动更新关联 Deployment/StatefulSet。
• 模式 B（新 ConfigMap + 灰度）：创建新 ConfigMap（如 app-config-v2），修改 Deployment 引用，通过 maxSurge/maxUnavailable 控制灰度比例。

4.2 场景二：跨集群迁移

触发条件：集群整体迁移（如从 IDC 迁移到云、从旧集群迁移到新集群），ConfigMap 中的镜像地址指向旧集群的私有仓库，新集群无法直接访问。

风险等级：高。涉及网络连通性、镜像同步延迟、凭证跨集群分发等多重因素。

迁移模式：

• 模式 A（镜像同步 + 地址不变）：在新集群搭建同名仓库域名，通过 DNS 或负载均衡将流量指向新仓库，ConfigMap 内容不变。
• 模式 B（地址重写 + 工具批量替换）：使用 sed、yq 或 kustomize 批量修改 ConfigMap 中的镜像地址，然后 apply 到新集群。

4.3 场景三：镜像版本批量升级

触发条件：安全漏洞修复、基础镜像更新（如 Alpine 3.18 → 3.19）、或业务版本迭代，需要批量修改 ConfigMap 中引用的镜像 Tag。

风险等级：中高。版本升级可能引入 API 不兼容、依赖库变更等隐性问题。

迁移模式：

• 模式 A（全量替换 Tag）：直接修改 ConfigMap 中 image: myapp:1.0.0 为 myapp:1.1.0，然后滚动更新。
• 模式 B（多版本灰度 + 金丝雀）：创建多个 ConfigMap 副本（如 app-config-v1.0.0、app-config-v1.1.0），通过 Service Mesh 或 Deployment 流量权重控制灰度比例。

#!/bin/bash
# 批量替换 ConfigMap 中镜像版本号
OLD_TAG=":1.0.0"
NEW_TAG=":1.1.0"
NAMESPACES=("default" "production" "staging")

for ns in "${NAMESPACES[@]}"; do
  kubectl get cm -n "$ns" -o json | \
    jq -c '.items[] | select(.data | tostring | contains("image")) | .metadata.name' | \
    while read -r cm_name; do
      kubectl get cm "$cm_name" -n "$ns" -o yaml | \
        sed "s|$OLD_TAG|$NEW_TAG|g" | \
        kubectl apply -f -
    done
done

4.4 场景四：私有仓库域名变更

触发条件：企业域名策略调整、仓库服务商更换、或 HTTPS 证书域名变更（如从 registry.old-company.com 改为 registry.new-company.com）。

风险等级：高。域名变更涉及 DNS 解析、TLS 证书、镜像拉取凭证（imagePullSecrets）的全面更新。

迁移模式：

• 模式 A（DNS 别名 + 双写）：在 DNS 层面将旧域名 CNAME 到新域名，同时在新旧仓库之间建立镜像同步，ConfigMap 内容不变。
• 模式 B（全量替换 + 凭证更新）：批量修改 ConfigMap 中的仓库域名，同时更新所有 Namespace 下的 imagePullSecrets。

4.5 场景对比总结