企业官网建设流程全解析

microservices-demo 部署瘦身：用 without-loadgenerator Kustomize 组件排除流量压测器 loadgenerator

【免费下载链接】microservices-demoSample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.项目地址: https://gitcode.com/GitHub_Trending/mi/microservices-demo

导读

Online Boutique（microservices-demo）默认会在集群中随应用一起部署 loadgenerator 负载生成器，它持续对前端发起模拟用户流量。当你在开发、演示或资源受限环境（如本地 Kind、Minikube、小型 GKE 集群）中只需要验证微服务本身、而不希望压测流量持续消耗 CPU 与内存时，可以使用本仓库内置的without-loadgeneratorKustomize 组件一键移除该 Deployment。读完本文，你将掌握该组件的底层实现原理（$patch: delete策略删除）、标准接入命令、渲染验证与集群部署的完整流程，并了解它与 network-policies 等依赖 loadgenerator 的组件之间的兼容性边界。

为什么默认会部署 loadgenerator

在默认的 Kustomize 编排中，loadgenerator 是base的一部分。查看 kustomize/base/kustomization.yaml 的resources列表，其中第 24 行明确声明了- loadgenerator.yaml，与 adservice、frontend 等 10 个微服务并列。因此只要以kustomize/base为基底构建，负载生成器就会被一并渲染并部署。

对应的资源定义位于 kustomize/base/loadgenerator.yaml，它实际上包含两类对象：

• 一个apps/v1的Deployment（metadata.name: loadgenerator），运行us-central1-docker.pkg.dev/online-boutique-ci/microservices-demo/loadgenerator:v0.10.6镜像；
• 一个配套的ServiceAccount（metadata.name: loadgenerator），供 Pod 以非 root 用户（runAsUser: 1000）运行。

从 Deployment 的细节可以看到负载生成器的工作方式：它通过initContainers中的frontend-check容器（busybox）以wget轮询FRONTEND_ADDR=frontend:80，最多重试 12 次、每次间隔 10 秒，确认前端就绪后才启动主容器；主容器通过环境变量USERS=10、RATE=1控制模拟用户数与请求速率，并申请300m/512Mi级别的资源（limits 为500m/512Mi）。压测行为本身由 src/loadgenerator/locustfile.py 定义：基于 Locust 的FastHttpUser，以加权任务（浏览商品权重 10、加购 2、结账 1 等）模拟真实用户购物流程。

对于仅做功能演示、联调或资源有限的场景，这样一个持续产生流量的 Deployment 往往是不必要的——这正是without-loadgenerator组件存在的意义。

组件实现原理：一条$patch: delete即可删除

整个组件只有两个文件，逻辑极其精简：

• kustomize/components/without-loadgenerator/kustomization.yaml —— 声明这是一个kustomize.config.k8s.io/v1alpha1的Component，并通过patches引用删除补丁；
• kustomize/components/without-loadgenerator/delete-loadgenerator.patch.yaml —— 删除策略补丁。

补丁文件内容如下：

apiVersion: apps/v1 kind: Deployment metadata: name: loadgenerator $patch: delete

这段补丁是 Kustomize 标准的"按名称定位 + 删除"写法：它只给出apiVersion: apps/v1、kind: Deployment和目标对象的metadata.name: loadgenerator，配合顶层$patch: delete指令，Kustomize 就会在构建产物中整段删除与kustomize/base/loadgenerator.yaml中同名同类型的 Deployment 资源。

需要注意的关键点是：补丁只删除Deployment，并不会删除ServiceAccount。从 kustomize/base/loadgenerator.yaml 的源码结构看，ServiceAccount与Deployment位于同一文件、以---分隔；Kustomize 按资源类型与名称独立匹配补丁，因此构建结果中仍会保留一个孤立的loadgeneratorServiceAccount。这通常无害（没有 Pod 引用它），但如果你追求完全干净的清单，可以在后续清理时一并处理。

另外值得说明的是，Kustomize 的 patch 匹配默认基于kind+metadata.name，因此即使kustomize/base/loadgenerator.yaml后续增加了新资源或修改了字段，只要 Deployment 的名称不变，这个删除补丁就依然有效。

接入组件：一条命令完成配置

在仓库根目录下进入kustomize/文件夹，执行：

cd kustomize/ kustomize edit add component components/without-loadgenerator

这条命令会在根级 kustomize/kustomization.yaml 中追加组件引用。更新后的文件类似：

apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - base components: - components/without-loadgenerator

对比仓库中默认的 kustomize/kustomization.yaml，其components段当前全部以注释形式存在（包括被注释掉的# - components/without-loadgenerator），kustomize edit add component的作用就是把对应行取消注释（或追加为新条目），将组件正式纳入构建。

如果你的环境没有安装独立的kustomize二进制，也可以直接手动编辑kustomize/kustomization.yaml，在components:段下加入- components/without-loadgenerator一行，效果完全等价。可选地，也可以参考 kustomize/README.md 中"Prerequisites"一节的说明安装 kustomize 二进制，以便使用kustomize edit系列命令。

验证与部署：先渲染、再应用

组件接入后，可以先用渲染命令在本地检查构建产物，确认loadgenerator的 Deployment 已被移除、且其他微服务资源完整保留：

kubectl kustomize .

在输出中搜索loadgenerator，应当只看到残留的ServiceAccount定义，而不再有Deployment。此时不会对集群产生任何影响，是上线前最安全的一步验证。

确认无误后再真正部署到集群：

kubectl apply -k .

部署完成后，用kubectl get pods检查状态，正常的 Online Boutique 部署（kustomize/README.md 的示例输出）中会出现loadgenerator-665b5cd444-gwqdq这样的 Pod；接入本组件后，Pod 列表中将不再出现 loadgenerator，其余 10 个微服务（adservice、cartservice、checkoutservice、currencyservice、emailservice、frontend、paymentservice、productcatalogservice、recommendationservice、shippingservice）应全部处于Running状态。

兼容性注意事项

该组件的官方 README 明确给出了一条重要提示：此组件未与依赖 loadgenerator 的其他 Kustomize 组件进行过组合测试。

从仓库检索可以确认，确实存在与 loadgenerator 耦合的组件，典型的是 network-policies：其 kustomization.yaml 第 25 行引用network-policy-loadgenerator.yaml，而该策略文件（见 network-policy-loadgenerator.yaml）通过podSelector: app: loadgenerator为负载生成器 Pod 定义网络出入站规则。若同时启用without-loadgenerator与network-policies，前者删除的 Deployment 会使后者的 NetworkPolicy 失去匹配对象，虽然不会导致部署失败，但会留下一份语义上"悬空"的策略，这一点在组合使用前应当知晓。

同理，container-images-registry、container-images-tag、container-images-tag-suffix 等组件会批量改写镜像仓库/标签（包括 loadgenerator 镜像），与删除组件叠加时这些改写对 loadgenerator 自然不再生效——这不会报错，只是相应 patch 失去作用对象。

与其它组件的组合思路

without-loadgenerator遵循 Kustomize component 的"可组合"设计（详见 kustomize/README.md 对 variations 的说明），可以方便地与其他组件叠加使用。例如同时移除负载生成器并切换购物车存储后端：

kustomize edit add component components/without-loadgenerator kustomize edit add component components/memorystore

生成的kustomize/kustomization.yaml将包含多个组件条目，Kustomize 会按顺序依次应用各组件对base的增删改。组合时建议遵循根级kustomize/kustomization.yaml中的注释约定：container-images-tag、container-images-tag-suffix、container-images-registry这类镜像改写组件应放在最后执行。

小结

without-loadgenerator是 Online Boutique 仓库中实现最简洁、接入成本最低的 Kustomize 组件之一：一条删除补丁 + 一条kustomize edit add component命令，即可从默认 11 个工作负载中剔除持续消耗资源的压测器，让集群专注于验证微服务本身的链路（frontend → productcatalogservice、cartservice、checkoutservice 等）。其$patch: delete的定位删除机制也是理解 Kustomize 组件式清单裁剪的最佳入门范例，值得在阅读 kustomize/base/loadgenerator.yaml 与 src/loadgenerator/locustfile.py 后对照体会。

【免费下载链接】microservices-demoSample cloud-first application with 10 microservices showcasing Kubernetes, Istio, and gRPC.项目地址: https://gitcode.com/GitHub_Trending/mi/microservices-demo