For DevOps: audits release inf…

# K8s 生产集群发布基础设施审计：多架构镜像完整性检查

由于我无法直接访问你的集群和镜像仓库，以下提供可落地的审计方法与检查清单，你按步骤执行即可。

一、明确审计范围与基线

• 整理12个微服务清单：服务名、镜像仓库地址、镜像tag、最近上线时间（标记3个新服务重点核查）
• 确认目标架构基线：linux/amd64 + linux/arm64
• 确认镜像tag策略：是否有统一的版本tag（避免仅用 latest 导致审计不可追溯）

二、镜像仓库层检查（核心）

• Manifest List 验证：对每个服务镜像执行

docker buildx imagetools inspect <镜像>:<tag>

确认返回的 manifest 中同时包含 linux/amd64 和 linux/arm64 两个 platform 条目

• 警惕假多架构：检查 arm64 manifest 是否指向真实镜像 digest，而非指向 amd64 镜像的复用（部分CI流水线会错误复制）
• tag一致性：同一版本号下双架构必须同digest组发布，不允许 amd64 有 v1.2.3 而 arm64 只有 older 版本

三、CI/CD 流水线检查

• 确认构建命令使用 docker buildx build --platform linux/amd64,linux/arm64 并一次性 push
• 重点排查3个新上线服务：其流水线是否遗漏 arm64 构建步骤，或 arm64 构建处于“静默失败”状态（构建任务存在但被跳过/容忍失败）
• 检查是否有架构维度的构建产物校验步骤（post-build verification）

四、集群运行层验证

• 逐个检查节点池：kubectl get nodes -o wide 确认集群是否真实存在 arm64 节点
• 对每服务执行 kubectl describe pod 查看 Image: 字段，并核对节点架构与镜像拉取记录
• 检查镜像拉取失败事件：kubectl get events --field-selector reason=Failed，ErrImagePull / no matching manifest for linux/arm64 是典型信号

五、3个新上线服务重点核查项

• 上线后是否曾在 arm64 节点调度成功（若从未调度过，可能掩盖镜像缺失）
• 滚动发布时双架构节点的 Pod 是否均正常 Running
• 回滚镜像是否也具备双架构

六、长效机制建议

• CI 中加入双架构断言门禁，缺任一架构则流水线失败
• 定期（如每周）跑镜像清单巡检脚本，输出缺失矩阵（服务 × 架构）
• 新服务上线 checklist 中加入“双架构镜像验证”必选项

如需，我可以提供 manifest 检查的批量化脚本模板，你贴出12个服务的镜像清单即可执行比对。