如何配置AKS集群自动拉取Azure Container Registry新版本镜像

存在成熟可落地的技术方案，生产环境常用的实现路径主要有三类，你可以根据自身的运维流程和技术栈选择：

方案1：ACR Webhook + 集群侧轻量接收器（最轻量，无额外云服务依赖） #

• ACR原生支持镜像事件触发Webhook，你可以直接在ACR实例的Webhook配置页新建规则，触发事件选择「镜像推送」，支持配置监听范围，只针对特定仓库、特定tag规则的镜像推送生效，不用全量监听所有镜像事件。
• AKS侧只需要部署一个轻量Webhook接收服务，接收到ACR推送的事件后，自动解析事件里带的镜像名、新版本tag，匹配集群内使用该镜像的Deployment、StatefulSet等工作负载：
  • 如果你用固定tag（比如latest），服务自动给对应工作负载的Pod模板patch一个带当前时间戳的重启注解，K8s就会触发滚动更新，拉取最新版本镜像
  • 如果你用语义化唯一tag，服务直接patch工作负载的镜像字段为新版本tag，K8s会自动拉取对应新镜像完成更新
• 注意配置Webhook鉴权，通过自定义请求头做合法性校验，不要把接收服务裸暴露在公网。

方案2：Azure Event Grid + 托管服务编排触发（适合需要多流程联动的场景） #

• 给ACR配置事件订阅，将镜像推送事件统一路由到Event Grid，事件自带镜像名、tag、推送时间、推送身份等完整元数据。
• 后续可以对接Azure Logic Apps或者Azure Functions编写自定义触发逻辑：比如先过滤掉测试tag的镜像，先触发镜像漏洞扫描，扫描通过后再调用AKS的API执行工作负载更新，还可以按需加灰度发布、更新后告警、人工审批节点。
• 这个方案不需要在AKS集群内部署额外组件，所有逻辑跑在Azure托管服务上，运维成本低，扩展灵活。

方案3：GitOps组件自动同步（适合已经落地GitOps流程的集群） #

• 如果你用Argo CD这类GitOps工具管理AKS集群配置，只需要开启配套的镜像自动更新组件，配置好ACR的访问凭证，给需要自动更新的工作负载加对应注解，指定监听的ACR仓库、tag匹配规则（比如只匹配v*开头的正式版本tag，忽略测试tag）即可。
• 组件会定期轮询ACR的镜像列表，发现符合规则的新版本后，自动更新Git仓库里K8s配置清单中的镜像tag，再由Argo CD把变更同步到AKS集群，触发新镜像拉取和滚动更新。
• 这个方案所有变更都在Git仓库留提交记录，可追溯、可快速回滚，符合云原生运维最佳实践，适合多环境、多集群的规模化场景。

通用注意事项：如果使用固定tag（如latest）部署工作负载，必须配置imagePullPolicy: Always，否则节点本地存在同名tag旧镜像时，不会主动向ACR拉取新版本；如果使用commit hash、语义化版本号这类全局唯一tag，只要工作负载的镜像tag字段更新为新值，K8s会自动拉取对应版本镜像，无需额外配置拉取策略。

内容的提问来源于stack exchange，提问作者Bertrand Pons