如何在Kubernetes中基于特定镜像版本实现Deployment回滚并关联Revision与镜像信息

你提到的痛点确实很常见——Kubernetes的rollout undo默认依赖Revision编号，但这个编号本身没法直接关联到镜像版本，手动记录又容易出错。好在不用完全放弃rollout命令，有几个更优雅的方法可以实现按指定镜像回滚的需求：

方法1：先找到镜像对应的Revision，再执行回滚 #

每个Deployment的Revision都会对应一个ReplicaSet，而ReplicaSet的Spec里直接保存了该版本使用的镜像信息。你可以通过以下命令快速列出所有Revision与镜像的对应关系：

# 替换<your-deployment>为你的Deployment名称
kubectl get rs -l app=$(kubectl get deployment <your-deployment> -o jsonpath='{.spec.selector.matchLabels.app}') \
-o custom-columns='NAME:.metadata.name,REVISION:.metadata.annotations.deployment\.kubernetes\.io/revision,IMAGE:.spec.template.spec.containers[0].image'

这条命令会输出类似这样的结果：

NAME                          REVISION   IMAGE
httpd-deployment-7f89d76c89   1          httpd:latest
httpd-deployment-6dc4f789b4   2          httpd:1.9.1
httpd-deployment-5b7d987c62   3          nginx:1.91

找到目标镜像对应的Revision号后，就可以用熟悉的rollout undo命令回滚：

kubectl rollout undo deployment/<your-deployment> --to-revision=<目标Revision号>

在CI流水线中，你可以用脚本自动完成这个匹配过程，比如用jq处理JSON输出提取Revision：

TARGET_IMAGE="httpd:1.9.1"
DEPLOYMENT_NAME="httpd-deployment"

# 获取目标镜像对应的Revision号
REVISION=$(kubectl get rs -l app=$(kubectl get deployment $DEPLOYMENT_NAME -o jsonpath='{.spec.selector.matchLabels.app}') -o json | \
jq -r --arg img "$TARGET_IMAGE" '.items[] | select(.spec.template.spec.containers[0].image == $img) | .metadata.annotations."deployment.kubernetes.io/revision"')

# 执行回滚
kubectl rollout undo deployment/$DEPLOYMENT_NAME --to-revision=$REVISION

方法2：直接回滚到对应镜像的ReplicaSet #

如果你不想依赖Revision编号，也可以直接指定ReplicaSet名称回滚——毕竟每个ReplicaSet就是Deployment某个版本的实际载体：

# 先找到目标镜像对应的ReplicaSet名称
RS_NAME=$(kubectl get rs -l app=$(kubectl get deployment $DEPLOYMENT_NAME -o jsonpath='{.spec.selector.matchLabels.app}') -o json | \
jq -r --arg img "$TARGET_IMAGE" '.items[] | select(.spec.template.spec.containers[0].image == $img) | .metadata.name')

# 回滚到该ReplicaSet
kubectl rollout undo deployment/$DEPLOYMENT_NAME --to-replica-set=$RS_NAME

这种方式和指定Revision的效果完全一致，但更直接关联到镜像对应的实例集合。

为什么不推荐直接用kubectl set image？ #

你提到的直接重新部署旧镜像的方式，虽然能达到版本回退的效果，但本质是创建一个新的Revision，而不是利用Kubernetes内置的回滚机制。这样会导致Deployment的历史记录变得冗余，也无法保留原版本的ReplicaSet信息，后续如果需要再次回滚到其他旧版本会更麻烦。

而上面两种方法都是基于Deployment已有的历史版本操作，既保留了完整的版本追溯链，又符合Kubernetes的回滚语义。

关于CHANGE-CAUSE的补充 #

你说得没错，依赖--record生成的CHANGE-CAUSE确实不推荐——这个参数已经被废弃，而且CHANGE-CAUSE的信息是基于命令行输入的，可能存在拼写错误（比如你示例里的htppd-deployment笔误），可靠性远不如直接从ReplicaSet的Spec中读取镜像信息。

内容的提问来源于stack exchange，提问作者sam hassan