Online Boutique 使用 container-images-tag-suffix 组件时镜像 tag 后缀重复怎么绕过？

Online Boutique 使用 container-images-tag-suffix 组件时镜像 tag 后缀重复怎么绕过【免费下载链接】microservices-demoSample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.项目地址: https://gitcode.com/GitHub_Trending/mi/microservices-demo用 Kustomize 把 Online Boutiquemicroservices-demo部署到 Kubernetes 集群时如果希望给所有容器镜像的 tag 统一加一个后缀来指向某个特定版本会遇到一个卡住部署的问题加入container-images-tag-suffix组件后直接kubectl apply -k .不可用——Kustomize 的一个已知问题会让tagSuffix在渲染结果里被重复导致清单里镜像 tag 的后缀出现两次。项目文档给出的绕行方式temporary workaround是先把清单渲染出来在管道里用sed把重复的后缀收敛成一份再应用到集群。以下内容按 kustomize/components/container-images-tag-suffix/README.md 的说明操作。后缀为什么会被重复组件的组件定义在 kustomize/components/container-images-tag-suffix/kustomization.yaml它在images:一节里为 base 中 11 个服务adservice、cartservice、checkoutservice、currencyservice、emailservice、frontend、loadgenerator、paymentservice、productcatalogservice、recommendationservice、shippingservice逐一配置了tagSuffix: CONTAINER_IMAGES_TAG_SUFFIX占位符。组件 README 说明其作用this Kustomize component will add a suffix to the container image tag of theimage:field in allDeployments.即给所有Deployment的image:字段追加同一个后缀。但同一份 README 明确警告对这个组件kubectl apply -k .alone wont work因为 Kustomize 存在一个已知问题issue 4814会让tagSuffix被重复应用。因此这个组件的部署必须走渲染 → 去重 → 应用的管道而不是标准的-k流程。配置步骤前置条件来自 kustomize/README.md有一个可用于部署 Online Boutique 清单的 Kubernetes 集群可用的kubectl可选kustomize二进制。文档说明它是 optional作用是免去手工编辑kustomization.yaml不安装的话可以跳过kustomize edit命令直接把组件路径手工写入顶层 kustomize/kustomization.yaml 的components:列表。进入仓库根目录下的kustomize/目录执行文档中的命令SUFFIX-my-suffix sed -i s/CONTAINER_IMAGES_TAG_SUFFIX/$SUFFIX/g components/container-images-tag-suffix/kustomization.yaml kustomize edit add component components/container-images-tag-suffix三步各自的用途SUFFIX-my-suffix定义后缀值的 shell 变量。-my-suffix是文档给出的示例值读者按实际要指向的发布版本替换——文档说明加后缀的目的就是 target a specific version。sed -i会原地修改 components/container-images-tag-suffix/kustomization.yaml把其中tagSuffix的CONTAINER_IMAGES_TAG_SUFFIX占位符替换成具体后缀。注意该命令会直接改写这个文件后续渲染/部署命令都依赖$SUFFIX变量需在同一 shell 会话中执行换会话后要先重新赋值SUFFIX。kustomize edit add component把组件追加到顶层kustomize/kustomization.yaml的components:列表更新后应类似文档给出的示例apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - base components: - components/container-images-tag-suffix绕过方案先渲染、用 sed 去重再部署文档给出的绕行命令是用kubectl kustomize .渲染清单并在同一管道里用sed s/$SUFFIX$SUFFIX/$SUFFIX/g把连续出现两次的后缀替换成一次。本地渲染只检查不动集群kubectl kustomize . | sed s/$SUFFIX$SUFFIX/$SUFFIX/g部署kubectl kustomize . | sed s/$SUFFIX$SUFFIX/$SUFFIX/g | kubectl apply -f注意文档原文末尾是kubectl apply -f而前面是标准输入管道。实际执行时如果 kubectl 提示缺少文件参数在-f后补-即kubectl apply -f -表示从标准输入读取。验证结果直接运行kubectl kustomize .不加sed管道时可以看到渲染出的 tag 上后缀出现两次——这就是文档所说的tagSuffixduplicated 现象加上sed s/$SUFFIX$SUFFIX/$SUFFIX/g管道后检查输出中每个Deployment的image:字段后缀只出现一次说明去重生效。部署后按 kustomize/README.md 的流程确认集群状态kubectl get pods等所有 Pod 的STATUS变为Running。文档提示变更反映到 Deployment 上可能需要 2–3 分钟。通过 frontend 的外部 IP 用浏览器访问页面kubectl get service frontend-external | awk {print $4}GCP 配置负载均衡器期间可能输出pending文档说明此时等几分钟再重跑该命令即可。与其他组件组合时的顺序如果同一份部署里还用到container-images-tag改镜像 tag或container-images-registry改镜像仓库地址components:列表的书写顺序会影响最终渲染结果。组件 README 与顶层 kustomize/kustomization.yaml 中的注释These must be run last and in this order给出的顺序是components/container-images-tag在最前components/container-images-tag-suffix在 tag 之后、registry 之前components/container-images-registry在最后。apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - base components: - components/container-images-tag - components/container-images-tag-suffix - components/container-images-registry绕行方案的性质项目文档把这条sed管道定性为 temporary workaround后缀重复的根因在 Kustomize 工具本身已知问题 4814只要该问题未修复只要清单里包含container-images-tag-suffix组件部署就得走渲染 sed 去重管道不能用标准的kubectl apply -k .。如果不需要后缀功能则不应引入该组件继续使用kubectl apply -k .的常规流程即可。【免费下载链接】microservices-demoSample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.项目地址: https://gitcode.com/GitHub_Trending/mi/microservices-demo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考