升级JupyterHub Helm Release后仍使用旧Docker镜像的问题

从你描述的异常事件Container image "<AWS_ACCOUNT>.dkr.ecr.eu-west-1.amazonaws.com/<REPO>:NEW_TAG" already present on machine，以及kubectl显示标签更新但实际内容没变化的情况来看，核心问题大概率是你上传的新镜像和旧镜像的哈希值完全一致——也就是说，你修改了代码但Docker构建时因为缓存机制，没真正更新镜像内容，导致ECR里的新标签只是指向了旧镜像的哈希。下面是具体的排查和解决步骤：

1. 确认镜像哈希是否重复 #

先验证新旧镜像的ID是否一致：

• 本地查看旧镜像ID：

  docker inspect <AWS_ACCOUNT>.dkr.ecr.eu-west-1.amazonaws.com/<REPO>:OLD_TAG | grep Id
  

• 再查看新标签的镜像ID：

  docker inspect <AWS_ACCOUNT>.dkr.ecr.eu-west-1.amazonaws.com/<REPO>:NEW_TAG | grep Id
  

如果两个输出的Id值完全相同，那就能确定是构建缓存导致镜像内容没更新。

2. 修复镜像构建问题 #

要确保构建出真正的新镜像，你可以：

• 构建时强制跳过所有缓存：

  docker build --no-cache -t <AWS_ACCOUNT>.dkr.ecr.eu-west-1.amazonaws.com/<REPO>:NEW_TAG .
  

• 长期优化：调整Dockerfile的步骤顺序，把经常修改的内容（比如你的业务代码、依赖清单）放在构建的后期步骤，这样修改这些内容时，只会重新构建后面的层，不会触发前面层的缓存；如果必须修改前面的步骤（比如基础镜像更新），再用--no-cache。

3. 验证ECR中的镜像是否正确 #

推送新镜像后，用AWS CLI确认ECR里的新标签确实指向新的镜像哈希：

aws ecr describe-images --repository-name <REPO> --image-ids imageTag=NEW_TAG

查看输出中的ImageDigest，确保和你本地新构建的镜像哈希一致。

4. 清理Kubernetes节点上的旧镜像残留 #

如果已经确认镜像是全新的（哈希不同），但节点上仍残留旧镜像导致Pod没更新：

• 先找到运行JupyterHub Hub Pod的节点：

  kubectl get pods -n jhub -o wide
  

• 登录对应节点（可以通过EKS控制台的节点连接功能，或者SSH），删除旧镜像：

  docker rmi <旧镜像ID>
  

• 或者直接删除Hub Pod，让Kubernetes重新拉取镜像：

  kubectl delete pod <hub-pod-name> -n jhub
  

因为你已经设置了imagePullPolicy: Always，当K8s发现远程镜像哈希和本地不同时，会自动拉取新镜像。

5. 优化开发流程避免重复踩坑 #

为了以后更新镜像时能快速验证，建议调整你的工作流：

• 用镜像哈希替代标签：在config.yaml里直接指定镜像的哈希（比如<AWS_ACCOUNT>.dkr.ecr.eu-west-1.amazonaws.com/<REPO>@sha256:xxxxxx），这样完全避免标签重复的问题，每次构建后把新的哈希复制到配置文件中。
• 添加唯一构建标记：把Git commit ID或者时间戳作为标签的一部分（比如v0.1-abc123），这样标签本身就具备唯一性，不会和旧标签混淆。
• 配置Pod滚动更新：在Helm配置中添加滚动更新策略，确保镜像更新后Pod能自动重建，无需手动删除。

为什么之前的排查步骤没用？ #

• 删Release和命名空间没用：因为节点上已经缓存了和新标签哈希一致的旧镜像，重装后K8s会直接使用本地缓存。
• imagePullPolicy: Always无效：这个策略只有在远程镜像的哈希和本地不同时才会触发拉取，如果哈希相同，K8s会认为是同一个镜像，不会重新下载。

内容的提问来源于stack exchange，提问作者James Wierzba