Online Boutique 镜像版本锁定实战使用 Kustomize Component 统一更新容器镜像 Tag【免费下载链接】microservices-demoSample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.项目地址: https://gitcode.com/GitHub_Trending/mi/microservices-demo本文讲解如何在 microservices-demoOnline Boutique微服务示例项目中通过 Kustomize 组件Kustomize Component统一修改所有微服务的容器镜像 Tag实现按需锁定部署版本。读完本文你将掌握使用sed替换占位符、kustomize edit add component注册组件、kubectl kustomize本地渲染与kubectl apply -k部署的完整流程并理解镜像 Tag、Registry、Tag 后缀三类组件之间的组合顺序约束。背景为什么需要覆盖默认镜像 TagOnline Boutique 的 10 个微服务adservice、cartservice、checkoutservice、currencyservice、emailservice、frontend、loadgenerator、paymentservice、productcatalogservice、recommendationservice、shippingservice默认拉取的是公共容器仓库中最新发布版本的镜像。在kustomize/base/目录下每个 Deployment 的image:字段中可以看到默认的镜像引用例如 kustomize/base/frontend.yaml 中的image: us-central1-docker.pkg.dev/online-boutique-ci/microservices-demo/frontend:v0.10.6当我们需要将整个应用锁定到某个特定发布版本例如某个经过验证的稳定版本或需要回滚到历史版本时逐一手工编辑 11 个 YAML 文件显然低效且容易遗漏。这正是kustomize/components/container-images-tag组件要解决的问题它通过 Kustomize 的images转换器一次性覆盖所有 Deployment 中的镜像 Tag且不修改 base 目录中的任何原始文件。Kustomize 组件原理images 转换器如何工作该组件的核心定义位于 kustomize/components/container-images-tag/kustomization.yaml其结构如下节选apiVersion: kustomize.config.k8s.io/v1alpha1 kind: Component images: - name: us-central1-docker.pkg.dev/online-boutique-ci/microservices-demo/adservice newTag: CONTAINER_IMAGES_TAG - name: us-central1-docker.pkg.dev/online-boutique-ci/microservices-demo/cartservice newTag: CONTAINER_IMAGES_TAG - name: us-central1-docker.pkg.dev/online-boutique-ci/microservices-demo/checkoutservice newTag: CONTAINER_IMAGES_TAG # ...其余服务同理关键点解读kind: Component与apiVersion: kustomize.config.k8s.io/v1alpha1这是 Kustomize 的组件Component类型用于向主kustomization.yaml注入可复用的转换逻辑。与普通的resources不同组件不产出独立资源只对最终合并结果做变换因此非常适合镜像名/标签统一覆盖这类横切关注点。images[].name要匹配的镜像名不带 Tag。只有当 base 中某 Deployment 的image:字段完全匹配该 name 时转换才会生效。images[].newTag新的镜像 Tag 值。这里使用了占位符CONTAINER_IMAGES_TAG部署前需要把它替换为真实版本号。覆盖范围组件同时匹配仓库内全部 11 个服务的镜像从 kustomize/base/adservice.yaml 到 kustomize/base/shippingservice.yaml凡是image:字段形如.../microservices-demo/service:v0.10.6的 Deployment 都会被统一改写为.../microservices-demo/service:新 Tag。原文档特别注明该组件会更新所有 Deployment中image:字段的镜像 Tag。三步完成镜像 Tag 覆盖在仓库根目录的kustomize/目录下执行以下命令原文档步骤TAGv1.0.0 sed -i s/CONTAINER_IMAGES_TAG/$TAG/g components/container-images-tag/kustomization.yaml kustomize edit add component components/container-images-tag命令含义拆解TAGv1.0.0定义目标版本号变量按你的实际发布版本替换例如v0.10.6或仓库 Release 列表中的其他版本。sed -i s/CONTAINER_IMAGES_TAG/$TAG/g将组件配置文件中的所有CONTAINER_IMAGES_TAG占位符就地替换为真实版本号。因为占位符出现在组件内所有 11 条images[].newTag中一次替换即可全部生效。kustomize edit add component components/container-images-tag把该组件注册到kustomize/kustomization.yaml的components:列表。执行后kustomize/kustomization.yaml的内容类似apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - base components: - components/container-images-tag提示如果你不想安装独立的kustomize二进制也可以跳过kustomize edit命令直接手工编辑 kustomize/kustomization.yaml在components:列表中加入对应行即可详见 kustomize/README.md 的前置条件说明。本地渲染与部署完成配置后用以下命令验证与发布# 在 kustomize/ 目录下本地渲染最终清单不实际部署 kubectl kustomize . # 直接部署到当前 Kubernetes 集群 kubectl apply -k .其中kubectl kustomize .的输出中所有服务的image:字段应已变为.../microservices-demo/service:v1.0.0可用于在部署前确认 Tag 覆盖是否正确。kubectl apply -k .则是把渲染结果直接应用到集群。从源码结构看base 目录下的 11 个 Deployment 清单kustomize/base/kustomization.yaml 中的resources列表构成了渲染的输入而组件作为覆盖层在合并阶段改写镜像引用两者共同保证了base 不变、渲染结果随组件而变的可复用模式。与其他组件组合时的顺序约束如果同时使用多个镜像相关组件顺序至关重要。原文档明确给出的约束是components/container-images-tag必须放在components/container-images-registry之前。正确的组合示例apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - base components: - components/container-images-tag - components/container-images-registry顺序背后的原因可以从各组件定义推断container-images-tag组件改写newTag版本号而 container-images-registry 组件 改写newName仓库地址即CONTAINER_IMAGES_REGISTRY/adservice这类形式并且额外覆盖redis镜像。两个转换作用于镜像名name与标签tag的不同维度先匹配原始镜像名做 Tag 替换再统一改写仓库前缀才能保证匹配关系稳定。进一步组合时还有扩展约束如果需要同时追加 Tag 后缀例如区分同一版本的不同构建产物参考 kustomize/components/container-images-tag-suffix/README.md 的说明顺序应为container-images-tag→container-images-tag-suffix→container-images-registry。扩展阅读与注意事项Tag 后缀组件container-images-tag-suffix组件kustomization.yaml通过tagSuffix: CONTAINER_IMAGES_TAG_SUFFIX为 Tag 追加后缀需要留意其 README 中提到的已知问题该组件存在 Tag 后缀被重复追加的已知缺陷Kustomize issue #4814渲染与部署时需用sed s/$SUFFIX$SUFFIX/$SUFFIX/g临时规避单独使用kubectl apply -k .不会生效。仓库级总览镜像相关三个组件的说明与顺序约束也可以在 kustomize/kustomization.yaml 的注释中看到These must be run last and in this order该注释明确镜像类组件应放在其他功能组件之后、且三者内部保持固定顺序。整体部署流程完整的 Kustomize 部署指南含前置条件、默认部署、kubectl get pods验证、通过frontend-external的EXTERNAL_IP访问前端等步骤见 kustomize/README.md本文的镜像 Tag 覆盖是其中的一个可选变体variation。版本来源默认 Tag 跟随仓库发布的 Release 版本列表当前 base 清单中的默认值为v0.10.6替换时请使用实际存在且已推送到对应仓库的镜像 Tag否则 Pod 将拉取镜像失败。通过本文的组合用法你可以在不修改任何 base 清单的前提下用几行命令将 Online Boutique 全部微服务锁定到指定版本并将这一流程自然嵌入 CI/CD 流水线实现可重复、可审计的版本化发布。【免费下载链接】microservices-demoSample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.项目地址: https://gitcode.com/GitHub_Trending/mi/microservices-demo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Online Boutique 镜像版本锁定实战：使用 Kustomize Component 统一更新容器镜像 Tag
Online Boutique 镜像版本锁定实战使用 Kustomize Component 统一更新容器镜像 Tag【免费下载链接】microservices-demoSample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.项目地址: https://gitcode.com/GitHub_Trending/mi/microservices-demo本文讲解如何在 microservices-demoOnline Boutique微服务示例项目中通过 Kustomize 组件Kustomize Component统一修改所有微服务的容器镜像 Tag实现按需锁定部署版本。读完本文你将掌握使用sed替换占位符、kustomize edit add component注册组件、kubectl kustomize本地渲染与kubectl apply -k部署的完整流程并理解镜像 Tag、Registry、Tag 后缀三类组件之间的组合顺序约束。背景为什么需要覆盖默认镜像 TagOnline Boutique 的 10 个微服务adservice、cartservice、checkoutservice、currencyservice、emailservice、frontend、loadgenerator、paymentservice、productcatalogservice、recommendationservice、shippingservice默认拉取的是公共容器仓库中最新发布版本的镜像。在kustomize/base/目录下每个 Deployment 的image:字段中可以看到默认的镜像引用例如 kustomize/base/frontend.yaml 中的image: us-central1-docker.pkg.dev/online-boutique-ci/microservices-demo/frontend:v0.10.6当我们需要将整个应用锁定到某个特定发布版本例如某个经过验证的稳定版本或需要回滚到历史版本时逐一手工编辑 11 个 YAML 文件显然低效且容易遗漏。这正是kustomize/components/container-images-tag组件要解决的问题它通过 Kustomize 的images转换器一次性覆盖所有 Deployment 中的镜像 Tag且不修改 base 目录中的任何原始文件。Kustomize 组件原理images 转换器如何工作该组件的核心定义位于 kustomize/components/container-images-tag/kustomization.yaml其结构如下节选apiVersion: kustomize.config.k8s.io/v1alpha1 kind: Component images: - name: us-central1-docker.pkg.dev/online-boutique-ci/microservices-demo/adservice newTag: CONTAINER_IMAGES_TAG - name: us-central1-docker.pkg.dev/online-boutique-ci/microservices-demo/cartservice newTag: CONTAINER_IMAGES_TAG - name: us-central1-docker.pkg.dev/online-boutique-ci/microservices-demo/checkoutservice newTag: CONTAINER_IMAGES_TAG # ...其余服务同理关键点解读kind: Component与apiVersion: kustomize.config.k8s.io/v1alpha1这是 Kustomize 的组件Component类型用于向主kustomization.yaml注入可复用的转换逻辑。与普通的resources不同组件不产出独立资源只对最终合并结果做变换因此非常适合镜像名/标签统一覆盖这类横切关注点。images[].name要匹配的镜像名不带 Tag。只有当 base 中某 Deployment 的image:字段完全匹配该 name 时转换才会生效。images[].newTag新的镜像 Tag 值。这里使用了占位符CONTAINER_IMAGES_TAG部署前需要把它替换为真实版本号。覆盖范围组件同时匹配仓库内全部 11 个服务的镜像从 kustomize/base/adservice.yaml 到 kustomize/base/shippingservice.yaml凡是image:字段形如.../microservices-demo/service:v0.10.6的 Deployment 都会被统一改写为.../microservices-demo/service:新 Tag。原文档特别注明该组件会更新所有 Deployment中image:字段的镜像 Tag。三步完成镜像 Tag 覆盖在仓库根目录的kustomize/目录下执行以下命令原文档步骤TAGv1.0.0 sed -i s/CONTAINER_IMAGES_TAG/$TAG/g components/container-images-tag/kustomization.yaml kustomize edit add component components/container-images-tag命令含义拆解TAGv1.0.0定义目标版本号变量按你的实际发布版本替换例如v0.10.6或仓库 Release 列表中的其他版本。sed -i s/CONTAINER_IMAGES_TAG/$TAG/g将组件配置文件中的所有CONTAINER_IMAGES_TAG占位符就地替换为真实版本号。因为占位符出现在组件内所有 11 条images[].newTag中一次替换即可全部生效。kustomize edit add component components/container-images-tag把该组件注册到kustomize/kustomization.yaml的components:列表。执行后kustomize/kustomization.yaml的内容类似apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - base components: - components/container-images-tag提示如果你不想安装独立的kustomize二进制也可以跳过kustomize edit命令直接手工编辑 kustomize/kustomization.yaml在components:列表中加入对应行即可详见 kustomize/README.md 的前置条件说明。本地渲染与部署完成配置后用以下命令验证与发布# 在 kustomize/ 目录下本地渲染最终清单不实际部署 kubectl kustomize . # 直接部署到当前 Kubernetes 集群 kubectl apply -k .其中kubectl kustomize .的输出中所有服务的image:字段应已变为.../microservices-demo/service:v1.0.0可用于在部署前确认 Tag 覆盖是否正确。kubectl apply -k .则是把渲染结果直接应用到集群。从源码结构看base 目录下的 11 个 Deployment 清单kustomize/base/kustomization.yaml 中的resources列表构成了渲染的输入而组件作为覆盖层在合并阶段改写镜像引用两者共同保证了base 不变、渲染结果随组件而变的可复用模式。与其他组件组合时的顺序约束如果同时使用多个镜像相关组件顺序至关重要。原文档明确给出的约束是components/container-images-tag必须放在components/container-images-registry之前。正确的组合示例apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - base components: - components/container-images-tag - components/container-images-registry顺序背后的原因可以从各组件定义推断container-images-tag组件改写newTag版本号而 container-images-registry 组件 改写newName仓库地址即CONTAINER_IMAGES_REGISTRY/adservice这类形式并且额外覆盖redis镜像。两个转换作用于镜像名name与标签tag的不同维度先匹配原始镜像名做 Tag 替换再统一改写仓库前缀才能保证匹配关系稳定。进一步组合时还有扩展约束如果需要同时追加 Tag 后缀例如区分同一版本的不同构建产物参考 kustomize/components/container-images-tag-suffix/README.md 的说明顺序应为container-images-tag→container-images-tag-suffix→container-images-registry。扩展阅读与注意事项Tag 后缀组件container-images-tag-suffix组件kustomization.yaml通过tagSuffix: CONTAINER_IMAGES_TAG_SUFFIX为 Tag 追加后缀需要留意其 README 中提到的已知问题该组件存在 Tag 后缀被重复追加的已知缺陷Kustomize issue #4814渲染与部署时需用sed s/$SUFFIX$SUFFIX/$SUFFIX/g临时规避单独使用kubectl apply -k .不会生效。仓库级总览镜像相关三个组件的说明与顺序约束也可以在 kustomize/kustomization.yaml 的注释中看到These must be run last and in this order该注释明确镜像类组件应放在其他功能组件之后、且三者内部保持固定顺序。整体部署流程完整的 Kustomize 部署指南含前置条件、默认部署、kubectl get pods验证、通过frontend-external的EXTERNAL_IP访问前端等步骤见 kustomize/README.md本文的镜像 Tag 覆盖是其中的一个可选变体variation。版本来源默认 Tag 跟随仓库发布的 Release 版本列表当前 base 清单中的默认值为v0.10.6替换时请使用实际存在且已推送到对应仓库的镜像 Tag否则 Pod 将拉取镜像失败。通过本文的组合用法你可以在不修改任何 base 清单的前提下用几行命令将 Online Boutique 全部微服务锁定到指定版本并将这一流程自然嵌入 CI/CD 流水线实现可重复、可审计的版本化发布。【免费下载链接】microservices-demoSample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.项目地址: https://gitcode.com/GitHub_Trending/mi/microservices-demo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考