可观测性云原生【免费下载链接】pixieInstant Kubernetes-Native Application Observability项目地址https://gitcode.com/gh_mirrors/pixie/pixie点击查看免费下载本指南聚焦 Pixie 开源可观测性平台在 Kubernetes 上的部署配置管理方式如何使用Kustomize对大量 YAML 进行分层、可复用的组织与渲染如何使用Skaffold将镜像构建与清单渲染、部署动作串成一条流水线以及如何理解directory_per_deploy / directory_per_env的目录结构。读完本文你将能够独立定位 pixie_cloud、vizier 任一组件的配置入口读懂 base/dev/prod 等环境层之间的叠加关系并掌握通过 Skaffold profile 切换构建参数与环境清单的方法。部署配置的整体设计仓库根目录的 k8s/README.md 是整个 K8s 配置体系的总纲全文只有三句核心论断但信息量极大k8s 目录下存放的是部署用的配置文件Config files for deployment on K8s配置文件由 Kustomize 负责生成generation即所有 YAML 都不是手工维护的单份文件而是由 kustomization.yaml 逐层叠加、patch、重组出来的部署动作由 Skaffold 驱动Skaffold 负责把 Bazel 构建出的镜像与 Kustomize 渲染出的清单绑定起来统一推送到集群。因此k8s 目录是一个纯粹的静态配置源而真正的执行入口在 skaffold 目录 下的三个 Skaffold 配置中skaffold/skaffold_cloud.yaml面向 pixie_cloud云端控制面的部署流水线skaffold/skaffold_vizier.yaml面向 vizier部署在客户集群中的监控后端的部署流水线skaffold/skaffold_operator.yaml面向 operator 的部署流水线。这套设计把配置声明与构建部署解耦改环境只需要改 Kustomize 层或切换 Skaffold profile不需要动 Dockerfile 与构建逻辑改镜像只需要动 Bazel target不需要改 K8s 清单。目录结构directory_per_deploy / directory_per_env原文档用一段树形描述概括了整体布局directory_per_deploy/ (vizier, pixie_cloud, stirling_wrapper) directory_per_env/ (base, dev, prod)对照当前仓库可以还原出完整的实际结构。第一层按部署单元deploy划分k8s/vizier/运行在客户 Kubernetes 集群内的监控后端即 Pixie 的 data planek8s/cloud/云端控制面 pixie_cloud包含 api、auth、vzmgr、proxy 等大量微服务原文档提到的stirling_wrapper在仓库中已并入 vizier 的 PEM每个节点上的数据采集代理相关配置中体现为 k8s/vizier/pem 目录。第二层按环境env划分每个部署单元下都有base/跨环境共享的基准清单dev/、prod/面向开发与生产环境的具体化层额外的staging/、testing/、public/等环境目录仅 cloud 下存在对应不同发布渠道。以 vizier 为例k8s/vizier/base 内包含 kelvin 服务、query_broker 服务、metadata 服务、bootstrap 证书任务等组件而 k8s/vizier/persistent_metadata 与 k8s/vizier/etcd_metadata 则分别代表元数据持久化到磁盘与元数据存到 etcd两种架构选型各自再按x86/aarch64拆分平台差异。这种部署单元 × 环境的矩阵式目录让任何一个工程师都能凭路径立即判断这份配置属于哪个组件、服务于哪个环境这正是 Kustomize overlay 模式的典型组织方式。Kustomize 分层base 与 overlay 的叠加逻辑Kustomize 的核心机制是一个kustomization.yaml通过resources引用其它目录或文件通过patches/replicas/labels/namespace等字段对引用的内容做修改。Pixie 的每一层 kustomization.yaml 都严格遵循这一范式。顶层声明默认环境k8s/kustomization.yaml 只有一个resources: - dev字段说明仓库默认渲染的是 dev 环境同理 k8s/vizier/kustomization.yaml 与 k8s/cloud/kustomization.yaml 也都默认指向各自下的dev目录。也就是说在没有任何覆盖参数的情况下执行kustomize build .得到的就是开发环境清单。base 层共享组件与公共标签base 层定义该部署单元的全部共享资源。例如 k8s/cloud/base/kustomization.yaml通过commonLabels: app: pl-cloud给所有资源统一打上应用标签通过namespace: plc指定默认命名空间通过resources一次性声明三十多个资源文件覆盖auth、api、plugin、profile、project_manager、config_manager、metrics、proxy、vzconn、vzmgr、artifact_tracker、indexer、scriptmgr、cron_script等服务的 Deployment/Service以及db_config、tls_config、domain_config、service_config、ory_service_config等 ConfigMap 类配置。而 k8s/vizier/base/kustomization.yaml 则声明了 vizier 的公共资源app: pl-monitoring、component: vizier、命名空间pl并展示了 Kustomize patch 的经典用法——通过patches配合target选择器把 patch_sentry.yaml 应用到所有labelSelector: vizier-bootstrap!true的 Deployment 上同时把 arch_tolerations 下的调度容忍 patch 应用到 Deployment、Job、StatefulSet 三类资源上。环境层按需覆盖dev 层不复制 base 的内容而是叠加修改。以 k8s/cloud/dev/kustomization.yaml 为例resources: - ../base引入全部 base 资源再追加../overlays/exposed_services_ilb对内暴露代理与 vzconn 服务的 ILB与plugin_db_updater_job.yamlnamespace: plc-dev把整个集群资源改入 dev 命名空间replicas把 api-server、auth-server、vzmgr-server 等关键服务缩到 1 副本节省开发资源patches依次应用auth_deployment_patch.yaml、db_config.yaml、service_config.yaml等差异文件注释还记录了dev 集群默认不向 BigQuery 发数据因此bq_config.yaml被显式排除这是 overlay 层做环境语义裁剪的直接证据。vizier 侧的 dev 层 k8s/vizier/dev/kustomization.yaml 同样只做两件事引用../base与../pem从而把 PEM 守护进程集合并入 dev 清单。平台层x86 与 aarch64 的差异vizier 在 base 之上还叠加了平台维度。以 k8s/vizier/persistent_metadata/x86/kustomization.yaml 为例它引用../base与../../pem然后通过四个 patch 分别作用于 Deployment、Job、StatefulSet、DaemonSet以适配 x86 平台对应的aarch64目录则承载 ARM64 变体。etcd_metadata目录下也有完全对称的 x86/aarch64 结构说明元数据后端persistent vs etcd× 架构x86 vs aarch64构成了 vizier 部署矩阵的两个正交维度。Skaffold 编排把 Bazel 镜像与 Kustomize 清单串起来Kustomize 只解决清单怎么生成镜像怎么构建、怎么进集群则由 Skaffold 解决。两份核心配置展示了完整的声明式流水线。云端控制面skaffold_cloud.yamlskaffold/skaffold_cloud.yaml 的关键结构apiVersion: skaffold/v4beta1、kind: Configbuild.artifacts为 pixie_cloud 的十几个服务逐一声明镜像名 → Bazel target的映射例如cloud-api_server_image对应//src/cloud/api:api_server_image.tarcloud-vzmgr_server_image对应//src/cloud/vzmgr:vzmgr_server_image.tar每个 target 都构建出可加载的镜像 tartagPolicy: dateTime: {}用当前时间生成镜像 taglocal.push: true构建产物推送到本地 registrymanifests.kustomize.paths指向k8s/cloud/dev即 Skaffold 直接调用kustomize build产出清单profiles通过 patch 在运行时改写配置最典型的是minikubekubeContext: minikube时自动激活把local.push改为false本地集群无需推送镜像staging/testing/prod由环境变量PL_BUILD_TYPE激活把 Kustomize 路径切换到k8s/cloud/staging、k8s/cloud/testing、k8s/cloud/prod并追加公共 Bazel 参数--compilation_modeopt、--configstamp、--action_envGOOGLE_APPLICATION_CREDENTIALS、--configx86_64_sysroot见 YAML 顶部的common_bazel_args锚点ory_auth/ory_auth_prod把 Ory 认证服务k8s/cloud/base/ory_auth追加进清单路径。这里有一个值得注意的联动关系环境切换只发生在 Skaffold profile 层Kustomize 层完全不知情。Skaffold 通过--profile或环境变量激活 profile 后才把 Kustomize 的渲染目标指到对应环境目录这正是构建/部署编排与配置生成两个关注点分离的体现。客户集群后端skaffold_vizier.yamlskaffold/skaffold_vizier.yaml 结构相同但组件是 vizier 侧的 PEM、Kelvin、metadata server、query_broker、cloud_connector 与 cert_provisioner每个 artifact 的 Bazel target 都带有--compilation_modedbgdebug 构建便于开发期调试默认manifests.kustomize.paths指向k8s/vizier/persistent_metadata/x86即默认渲染持久化元数据 x86组合profiles 提供了丰富的切换维度dbg/opt切换 Bazel 编译模式heap追加 k8s/vizier/heap_profile 清单开启堆分析asan/tsan追加--configasan/--configtsan并把清单切到 k8s/vizier/sanitizer用于内存/线程竞态检测etcd/etcd_x86_64_sysroot/etcd_aarch64_sysroot切换到 k8s/vizier/etcd_metadata 对应架构目录同时注入对应 sysroot Bazel 配置aarch64_sysroot/x86_64_sysroot切换 k8s/vizier/persistent_metadata 下的架构目录。从这两个文件可以看到 Pixie 的统一套路镜像清单由 Bazel target 决定环境差异由 Kustomize 目录决定而用哪个组合最终由 Skaffold profile 拍板。从配置到集群的完整工作流综合 k8s/README.md、skaffold 配置与各层 kustomization.yaml可以还原出一次典型部署的完整调用链清单生成Skaffold 依据manifests.kustomize.paths调用kustomize build从 base 层开始逐层叠加 overlaydev/staging/prod、x86/aarch64、persistent/etcd最终产出完整的 K8s YAML镜像构建Skaffold 依据build.artifacts调用 Bazel 构建各*_image.tar目标产出带dateTimetag 的容器镜像镜像入库按 profile 决定local.push是否启用minikube 等本地环境通常关闭应用部署Skaffold 将镜像引用替换进 Kustomize 渲染出的清单然后kubectl apply到当前 kube context 指向的集群vizier 清单默认落在pl命名空间cloud 清单默认落在plcbase/plc-devdev命名空间。开发者在日常迭代中最常用的命令形态是# 在 skaffold/skaffold_vizier.yaml 所在目录部署 vizier 到本地集群 skaffold dev -f skaffold/skaffold_vizier.yaml --profile minikube # 部署 pixie_cloud 到 staging 环境由 PL_BUILD_TYPE 激活 staging profile PL_BUILD_TYPEstaging skaffold run -f skaffold/skaffold_cloud.yaml注上述命令基于仓库内 Skaffold 配置的字段语义推导实际执行前请确认本机已安装 skaffold、kubectl 与 Bazel且 kube context 指向目标集群。与源码的印证镜像 target 与配置文件的对应关系k8s 目录中的配置并非孤立存在它与src下的服务实现一一对应。例如skaffold_cloud.yaml中声明的cloud-vzmgr_server_image → //src/cloud/vzmgr:vzmgr_server_image.tar对应 src/cloud/vzmgr 目录中的 vzmgr 服务cloud-scriptmgr_server_image对应 src/cloud/scriptmgrvizier 侧的vizier-pem_image对应 src/vizier/services/agent/pem。base 清单中出现的api_deployment.yaml、auth_deployment.yaml、query_broker_deployment.yaml等文件名也都能在 src/cloud/api、src/cloud/auth、src/vizier/services/query_broker 等目录中找到对应的二进制入口。从源码结构看这套部署体系的设计意图非常明确镜像粒度的 target、服务粒度的 Deployment、环境粒度的 overlay 三者严格对齐新增一个云服务时开发者只需在src/cloud/svc增加 Bazel target在 base 层增加 Deployment/Service YAML并在 skaffold_cloud.yaml 的 artifacts 中登记镜像名即可被整套流水线自动拾取。小结Pixie 的 K8s 配置体系是一个教科书级的Kustomize Skaffold组合实践Kustomize 解决静态配置的组织问题以directory_per_deploy / directory_per_env为骨架用 base 承载共享、overlay 承载差异、labelSelector 承载定向 patch最终在 k8s/cloud 与 k8s/vizier 两棵目录树中演化出完整的矩阵化配置Skaffold 解决动态部署的编排问题把 Bazel 镜像构建、Kustomize 清单渲染、镜像推送与 kubectl apply 串成单条命令并用 profile 机制环境变量或 kubeContext 自动激活在 dev/minikube/staging/prod、dbg/opt/asan/tsan、x86/aarch64 等维度间自由切换。对读者而言理解这份体系的价值在于遇到某个环境行为异常时可以顺着skaffold_*.yaml → kustomize paths → 对应环境目录 → base的链路逐层定位差异来源需要新增或调整部署时也能清楚知道该改哪一层、不该改哪一层。赞分享可观测性云原生【免费下载链接】pixieInstant Kubernetes-Native Application Observability项目地址https://gitcode.com/gh_mirrors/pixie/pixie点击查看免费下载相关推荐终极视频下载助手告别看得见下不了的烦恼网页视频一键变本地文件终极视频下载助手告别看得见下不了的烦恼网页视频一键变本地文件 你是否经常遇到这样的困扰在网上看到一个精彩的教学视频、一段有用的会议录像或者一段有趣的后端前端移动开发AI 应用知识管理全文检索MCP 服务Karakeep Kubernetes 部署实战基于 Kustomize 的自托管部署、Ingress 与 TLS 配置指南Karakeep Kubernetes 部署实战基于 Kustomize 的自托管部署、Ingress 与 TLS 配置指南 导读 本文以 Karakeep后端前端移动开发AI 应用知识管理全文检索MCP 服务终极kkFileView使用指南如何快速搭建万能文件在线预览系统终极kkFileView使用指南如何快速搭建万能文件在线预览系统 kkFileView是一款基于Spring Boot开发的万能文件在线预览开源项目支持几乎后端上一篇CANN/asc-devkit: bfloat16转int32 API下一篇探索并保护你的GitHubGSIL - 实时敏感信息监测系统创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考