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 Boutiquemicroservices-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的Deploymentmetadata.name: loadgenerator运行us-central1-docker.pkg.dev/online-boutique-ci/microservices-demo/loadgenerator:v0.10.6镜像一个配套的ServiceAccountmetadata.name: loadgenerator供 Pod 以非 root 用户runAsUser: 1000运行。从 Deployment 的细节可以看到负载生成器的工作方式它通过initContainers中的frontend-check容器busybox以wget轮询FRONTEND_ADDRfrontend:80最多重试 12 次、每次间隔 10 秒确认前端就绪后才启动主容器主容器通过环境变量USERS10、RATE1控制模拟用户数与请求速率并申请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 匹配默认基于kindmetadata.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-loadgeneratorkustomize 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考