GKE中Ingress Nginx控制器从k8s.gcr.io迁移至registry.k8s.io方法及影响

一、现有工作负载迁移步骤 #

1. 排查使用旧镜像源的工作负载 #

先用命令批量找出集群中所有引用k8s.gcr.io镜像的Pod：

kubectl get pods --all-namespaces -o jsonpath='{.items[*].spec.containers[*].image}' | tr ' ' '\n' | grep 'k8s.gcr.io'

也可以针对Deployment、StatefulSet等资源单独排查：

kubectl get deployments --all-namespaces -o jsonpath='{.items[*].spec.template.spec.containers[*].image}' | tr ' ' '\n' | grep 'k8s.gcr.io'

2. 更新镜像源配置 #

手动单资源更新

对单个Deployment/StatefulSet等资源，直接编辑配置替换镜像前缀：

kubectl edit deployment <deployment-name> -n <namespace>

在编辑器中将image: k8s.gcr.io/xxx/xxx:tag修改为image: registry.k8s.io/xxx/xxx:tag，保存后GKE会自动触发滚动更新。

批量更新（适合大量资源场景）

如果集群中有大量资源需要更新，可先导出配置、批量替换后重新应用：

1. 导出所有Deployment配置到临时文件：

kubectl get deployments --all-namespaces -o yaml > deployments.yaml

2. 批量替换镜像前缀：

sed -i 's/k8s.gcr.io/registry.k8s.io/g' deployments.yaml

3. 重新应用配置：

kubectl apply -f deployments.yaml

注意：操作前请备份原配置文件，避免意外；建议先在测试集群验证后再在生产环境执行。

3. 验证迁移结果 #

更新完成后，确认所有Pod已拉取新镜像且运行正常：

# 检查是否还有旧镜像源的Pod
kubectl get pods --all-namespaces -o jsonpath='{.items[*].spec.containers[*].image}' | tr ' ' '\n' | grep 'k8s.gcr.io'
# 查看单个Pod的镜像拉取状态
kubectl describe pod <pod-name> -n <namespace> | grep -A5 "Image:"

二、迁移风险评估 #

1. Ingress IP地址变更 #

不会触发变更。Ingress的IP由其关联的GCP负载均衡器实例决定，迁移镜像仅涉及Pod层面的镜像源更新，不会修改Ingress或负载均衡器的网络配置，因此IP地址保持不变。

2. SSL证书问题 #

不会产生影响。SSL证书绑定在Ingress资源或GCP负载均衡器上，与Pod使用的镜像仓库无关联，只要证书处于有效期内且配置正确，服务的HTTPS访问不受影响。

3. 服务中断风险 #

正常操作下不会导致服务中断：

• GKE的Deployment默认采用滚动更新策略，更新镜像时会逐步终止旧Pod并启动新Pod，保证服务持续可用。
• 潜在风险点：若registry.k8s.io的镜像标签与旧仓库不一致，或集群无权限拉取新仓库镜像，可能导致Pod启动失败。建议先在测试环境验证镜像拉取权限和镜像一致性，再推进生产环境迁移。

补充：GKE自带的系统组件（如kube-proxy、coredns等）使用的旧镜像，GCP会自动完成迁移，无需用户手动操作。

内容的提问来源于stack exchange，提问作者Raz Buchnik