可观测性云原生【免费下载链接】pixieInstant Kubernetes-Native Application Observability项目地址https://gitcode.com/gh_mirrors/pixie/pixie点击查看免费下载Prow 是 Kubernetes 生态中一套以 Kubernetes 原生方式运行的 CI/CD 系统它以 GitHub 机器人、Webhook 和自定义控制器驱动 PR 检查、合入门禁与周期性任务。本文以 pixie 仓库 k8s/devinfra/prow 目录 中的部署笔记及配套清单文件为蓝本逐层拆解「用一条 tackle 命令拉起整套 Prow」的实战流程、核心组件职责、全局配置项与 ProwJob 任务模型。读完本文你将掌握在自有 Kubernetes 集群上复刻 pixie 这套 Prow 部署形态所需的全部配置要素与源码依据。一、部署笔记核心tackle 一条命令拉起 Prow仓库中的 README.md 是一份极简的 Prow 部署备忘全文围绕两个要点部署前置参考与一条核心命令。1.1 部署前置官方 Getting Started 指南README 明确指出部署前应遵循 Prow 官方提供的Getting Started 部署指南kubernetes/test-infra 仓库中的prow/getting_started_deploy.mdREADME 中给出了对应链接。该指南通常覆盖以下预备工作创建 GitHub App获取App ID与私钥cert用于 hook、deck、tide 等组件与 GitHub API 通信生成HMAC token用于校验 GitHub Webhook 请求签名准备GCS 服务账号凭据用于把构建日志与产物上传到对象存储桶准备可访问目标集群的 kubeconfig 与必要的云资源IP、证书等。1.2 核心命令tackle sops 一键部署README 中给出了 pixie 团队实际使用的部署命令tackle --repo pixie-io/pixie -github-token-path $(sops -d api_key_file) -starter prow-setup-starter.yaml逐参数拆解参数含义--repo pixie-io/pixie指定 Prow 服务的 GitHub 组织 / 仓库用于生成插件配置、Tide 查询等组织级设定-github-token-path $(sops -d api_key_file)用sops解密加密的 API key 文件将解密结果GitHub 令牌内容作为 GitHub token 路径传给 tackle$(...)命令替换确保明文令牌不落盘-starter prow-setup-starter.yaml指定本次部署的启动清单文件即同目录下的 prow_setup_starter.yaml这条命令的含义是tackle 以prow_setup_starter.yaml为「种子清单」配合解密后的 GitHub 凭据在集群中创建 Prow 的全部核心资源。prow_setup_starter.yaml文件头部也明确提醒该文件包含 Prow 最重要的组件清单不要直接编辑文件内的资源应把它们拆分到独立文件中管理。二、部署清单 prow_setup_starter.yaml一次看懂全部组件prow_setup_starter.yaml 全文件约 1234 行覆盖命名空间、配置、9 类 Deployment、4 类 Service、GKE 网络资源与完整的 RBAC 权限模型。下面按资源类型逐一展开。2.1 两个命名空间控制面与测试 Pod 隔离文件首先创建两个命名空间这是 Prow 的标准隔离模型prow部署 hook、deck、tide 等全部控制面组件test-pods专门承载由 Prow 调度出来的测试 Pod对应config.yaml中的pod_namespace: test-pods与控制面物理隔离避免作业 Pod 干扰 CI 服务。2.2 控制面组件矩阵starter 文件共定义了 9 个 Deployment外加 4 个 Service职责与关键参数如下组件副本数核心职责关键启动参数 / 特征hook2接收 GitHub Webhook派发事件给插件并触发 ProwJob--dry-runfalse、--github-endpointhttp://ghproxy、--github-app-id$(GITHUB_APP_ID)挂载hmac-token与github-token两个 Secret配置 liveness/readiness 探针/healthz、/healthz/readydeck2Prow Web UI 与 Spyglass 日志查看--spyglasstrue、--tide-urlhttp://tide/、--hook-urlhttp://hook:8888/plugin-help、--github-graphql-endpointhttp://ghproxy/graphql挂载gcs-credentialstide1依据标签与查询规则自动合入 PR--status-pathgs://px-prow/tide-status、--history-urigs://px-prow/tide-history.json、--gcs-credentials-file/etc/gcs-credentials/service-account.json部署策略为Recreate注释明确「Do not scale up」horologium1调度周期任务periodic job--dry-runfalse、--config-path/etc/config/config.yaml策略Recreate禁止扩容sinker1定期清理过期/失败的超龄 ProwJob 与测试 Pod--dry-runfalse通过leases与 ConfigMap 实现 leader 选举ghproxy1GitHub API 代理与缓存降低限流风险--cache-dir/cache、--cache-sizeGB99、--push-gatewaypushgateway使用 100Gi PVCPersistentVolumeClaimghproxy注释明确「GHProxy does not support HA」故单副本 Recreateprow-controller-manager1新一代控制器入口本部署启用 plank 控制器--enable-controllerplank、--dry-runfalse通过prow-controller-manager-leader-locklease 选主crier1把 ProwJob 状态上报到 GitHub 与对象存储--blob-storage-workers10、--github-workers10、--kubernetes-blob-storage-workers10statusreconciler1校准/恢复 PR 上的状态上下文处理不一致场景--continue-on-errortrue、--status-pathgs://px-prow/status-reconciler-status2.3 网络暴露NodePort GKE Ingress 托管证书三个控制面服务以 NodePort 方式暴露再通过 GKE Ingress 统一收敛到域名prow.px.devService端口映射类型hook8888NodePortdeck80 → 8080NodePorttide80 → 8888NodePortghproxy80 → 8888另有 9090 metrics 端口ClusterIP集群入口侧配套了三个 GKE 网络资源ManagedCertificatenetworking.gke.io/v1px-prow-managed-cert为域名prow.px.dev自动签发/轮换 TLS 证书FrontendConfignetworking.gke.io/v1beta1px-prow-frontend-config指定sslPolicy: gke-ingress-ssl-policy并显式关闭 HTTP→HTTPS 跳转Ingressnetworking.k8s.io/v1注解声明ingress.class: gce、静态 IPpx-prow-external-ipaddr、关联托管证书与 FrontendConfig默认后端指向deck:80路由规则为/→ deck、/hook→ hook:8888。这一设计让 Webhook 回调路径/hook与用户访问路径/共享同一域名与证书。2.4 RBAC 最小权限设计starter 文件为每个组件都定义了独立的ServiceAccountRoleRoleBinding权限粒度精确到资源与动词。几个代表性设计hook在prow命名空间对prowjobs可create/get/list/update对 ConfigMap 可create/get/updatedeck在prow命名空间可get/list/watchProwJobs在test-pods命名空间仅可getpods/log。文件中的注释特别警告只有当 deck 以--rerun-creates-jobtrue运行时才需要create权限且这会允许任何能访问 Deck 实例的人创建新 ProwJob公网实例慎用sinker对prowjobs可delete/list/watch/get并通过coordination.k8s.io/leases与 ConfigMapprow-sinker-leaderlock实现选主在test-pods可对pods执行delete/list/watch/get/patch用于回收测试 Podhorologium对prowjobs仅create/list/watch职责收敛为「创建周期任务」tide / crier / statusreconciler / prow-controller-manager各自只持有完成任务所需的最小集合例如 crier 对 ProwJobs 只get/watch/list/patch。这套「一组件一账号一角色」的模型从侧面印证了 Prow 控制面各组件之间低耦合、可独立授权的基本架构。三、config.yamlProw 全局配置逐项拆解starter 文件中的configConfigMap 内嵌了完整的config.yaml这是 Prow 的全局行为配置涵盖命名空间、仓库内配置、Deck 展示、Plank 装饰与 Tide 合入门禁。3.1 命名空间与 in-repo 配置prowjob_namespace: prow pod_namespace: test-pods in_repo_config: enabled: *: trueprowjob_namespace: prowProwJob 对象创建在prow命名空间pod_namespace: test-pods作业 Pod 运行在test-pods命名空间in_repo_config.enabled.*: true对所有仓库启用仓库内配置——即 presubmit/postsubmit/periodic 等作业定义可以直接维护在目标仓库自身的配置文件中由 Prow 动态读取无需改动集群侧 ConfigMap。3.2 Deck Spyglass 透镜lensesdeck: spyglass: lenses: - lens: name: metadata required_files: - started.json|finished.json - lens: config: name: buildlog required_files: - build-log.txt - lens: name: junit required_files: - .*/junit.*\.xml - lens: name: podinfo required_files: - podinfo.jsonSpyglass 是 Deck 中渲染构建产物的插件机制每种lens只在其required_files命中的产物文件存在时才被激活。本部署注册了 4 种透镜——元数据started.json|finished.json、构建日志build-log.txt、JUnit 测试结果.*/junit.*\.xml、Pod 信息podinfo.json。这些文件由「装饰」decoration过程生成并上传到 GCS见 3.3从而在 PR 页面直接查看日志、测试报告与运行环境。3.3 Plank作业 URL、PR 报告模板与装饰配置plank: job_url_prefix_config: *: https://prow.px.dev/view/ report_templates: *: - [Full PR test history](https://prow.px.dev/pr-history?org{{.Spec.Refs.Org}}repo{{.Spec.Refs.Repo}}pr{{with index .Spec.Refs.Pulls 0}}{{.Number}}{{end}}). [Your PR dashboard](https://prow.px.dev/pr?queryis:prstate:openauthor:{{with index .Spec.Refs.Pulls 0}}{{.Author}}{{end}}). default_decoration_configs: *: gcs_configuration: bucket: gs://px-prow path_strategy: explicit gcs_credentials_secret: gcs-credentials utility_images: clonerefs: gcr.io/k8s-prow/clonerefs:v20221011-5d4db25b24 entrypoint: gcr.io/k8s-prow/entrypoint:v20221011-5d4db25b24 initupload: gcr.io/k8s-prow/initupload:v20221011-5d4db25b24 sidecar: gcr.io/k8s-prow/sidecar:v20221011-5d4db25b24三个关键段落逐一说明job_url_prefix_config所有仓库的作业 URL 统一指向https://prow.px.dev/view/配合 GCS 上的对象路径拼出可点击的构建详情页report_templates在 PR 上生成评论模板使用 Go 模板语法引用{{.Spec.Refs.Org}}、{{.Spec.Refs.Repo}}、{{index .Spec.Refs.Pulls 0 .Number}}、.Author等 ProwJob 字段为 PR 作者输出「完整测试历史」与「我的 PR 面板」两个直达链接default_decoration_configs为所有作业启用默认「装饰」配置——把用户提供的 PodSpec 包装为带克隆、入口、上传能力的完整作业 Podgcs_configuration.bucket: gs://px-prow与path_strategy: explicit决定日志/产物的上传桶与路径策略gcs_credentials_secret: gcs-credentials指定上传凭据 Secretutility_images固定四个工具镜像clonerefs、entrypoint、initupload、sidecar的版本v20221011-5d4db25b24保证装饰行为与 Prow 版本一致。文件末尾的decorate_all_jobs: true进一步确认所有作业默认都会套用上述装饰流程。3.4 Tide合入门禁规则tide: queries: - labels: - lgtm - approved missingLabels: - needs-rebase - do-not-merge/hold - do-not-merge/work-in-progress - do-not-merge/invalid-owners-file orgs: - pixie-ioTide 的合入查询规则一目了然对于pixie-io组织的 PR只有同时具备lgtm与approved两个标签且不带needs-rebase、do-not-merge/hold、do-not-merge/work-in-progress、do-not-merge/invalid-owners-file任一阻断标签时才会进入自动合入队列。这套规则与「插件清单中的approve、lgtm、hold、wip」形成闭环机器人打标签Tide 按标签放行。3.5 周期任务示例periodics: - interval: 1m agent: kubernetes name: echo-test spec: containers: - image: alpine command: [/bin/date]配置了一个最小周期任务echo-test每 1 分钟由agent: kubernetesplank 控制器在集群中运行一个 alpine 容器执行/bin/date。它是验证 horologium → ProwJob → 测试 Pod 整条调度链路是否通畅的「冒烟测试」。四、plugins.yamlPR 机器人插件清单pluginsConfigMap 内嵌的plugins.yaml为pixie-io组织启用了 14 个 GitHub 机器人插件plugins: pixie-io: plugins: - approve - assign - blunderbuss - cat - dogs - help - heart - hold - label - lgtm - trigger - verify-owners - wip - yuks这些插件与 Tide 规则配合构成完整的 PR 协作流approve/lgtm产出合入所需标签hold/wip提供阻断标签trigger响应/test、/retest等命令触发作业assign、blunderbuss负责指派与自动分派 reviewerverify-owners校验 OWNERS 文件合法性对应 Tide 的do-not-merge/invalid-owners-file阻断标签cat、dogs、yuks、heart等属于社区趣味插件。五、ProwJob CRDProw 的任务数据模型同目录下的 prowjob_customresourcedefinition.yaml约 2.1 万行定义了 Prow 的核心自定义资源ProwJob是理解 Prow「任务即 Kubernetes 对象」这一设计的关键。5.1 CRD 元信息group/kindprow.k8s.io/ProwJob复数prowjobsscope: Namespaced版本v1附加打印列additionalPrinterColumnsJob.spec.job、BuildId.status.build_id、Type.spec.type、Org/Repo/Pulls.spec.refs.*、StartTime/CompletionTime、State——这意味着执行kubectl get prowjobs即可一眼看到任务名称、类型、归属仓库、PR 号与当前状态无需逐个 describe。5.2 spec任务的完整描述CRD Schema 中spec的核心字段可分为几组触发与报告type枚举presubmit/postsubmit/periodic/batch决定触发时机、context回写到 GitHub 的状态上下文名、report是否上报结果、rerun_commandPR 上触发该任务的命令文本、rerun_auth_config谁可以重跑allow_anyone、github_orgs、github_users、github_team_ids/slugs、reporter_config.slackSlack 频道与job_states_to_report代码引用refs待测代码org/repo/base_ref/base_sha/pulls[].author|number|sha以及clone_depth、path_alias、skip_submodules、workdir等克隆细节与extra_refs辅助仓库结构一致执行载体agent决定由哪个控制器执行如kubernetes、cluster、namespace、pod_spec用户提供的 PodSpec、max_concurrency/job_queue_name并发控制、error_on_evictionPod 被驱逐时置为 error 还是重建、hidden是否在 Deck 隐藏装饰配置decoration_config完整展开装饰模型——gcs_configurationbucket、path_strategy、job_url_prefix、gcs_credentials_secret、utility_imagesclonerefs/entrypoint/initupload/sidecar 四镜像、resources四个工具容器的资源请求/限制、timeout/grace_period、censor_secrets与censoring_options日志/产物脱敏含censoring_buffer_size默认 10MiB、censoring_concurrency默认 10、include_directories/exclude_directories、ssh_key_secrets/ssh_host_fingerprints、oauth_token_secret、github_app_id/github_app_private_key_secret、default_service_account_name、set_limit_equals_memory_request等可扩展执行方式jenkins_specJenkins 执行与pipeline_run_spec/pipelineSpecTekton Pipeline 执行含 params、tasks、results 等完整 Tekton 模型。5.3 status任务生命周期状态机status通过state枚举刻画任务生命周期triggered→pending→success/failure/aborted/errortriggered与pending为运行中状态其余为终态Schema 对终态强制要求completionTime。配套字段包括build_idGCS 分组标识、pod_name与 ProwJob 同名、startTime/pendingTime/completionTime、url、description、prev_report_states记录各 reporter 已上报的状态避免 crier 重复上报。由此可以串联整个执行链路horologium/hook按type生成 ProwJob → plank 控制器本部署为prow-controller-manager的--enable-controllerplank读取 ProwJob 并在test-pods命名空间创建装饰后的测试 Pod →sidecar采集日志/产物上传gs://px-prow→crier把最终状态回写 GitHub →deck Spyglass 供人查看。六、仓库 CI 形态的一点旁证从源码结构看pixie 的 CI 是「多形态并存」的仓库 ci/github 目录维护了基于 GitHub Actions 的 Bazel 构建配置其 bazelrc 中写有build_metadataHOSTgithub-actions、REPO_URL等元数据而k8s/devinfra/prow目录则保留了 Prow 集群的整套部署资产。两者并不冲突——Prow 侧重 PR 机器人、合入门禁与可复用的 Kubernetes 原生任务编排GitHub Actions 侧则承担常规构建矩阵对于想自建 PR 门禁流水线的团队prow_setup_starter.yaml 本身就是一份可直接参照的完整蓝图。七、部署与运维要点小结凭据先行tackle 部署依赖hmac-token、github-token含appid键与gcs-credentials三个 Secret其中 GitHub token 建议用sops加密保管部署时再解密注入版本一致性所有 Prow 组件镜像统一锁定在v20221011-5d4db25b24版本含 utility_images升级时需整体对齐单副本组件的约束tide、horologium、ghproxy、prow-controller-manager、crier、statusreconciler均为单副本且 tide/horologium/ghproxy 使用Recreate策略并明确注释「Do not scale up」——ghproxy 因不支持 HA其 100Gi PVC 缓存需要持久化保障网络与证书通过 GKEManagedCertificate为prow.px.dev托管 TLSIngress 将/与/hook分别路由到 deck 与 hook是 Webhook 与用户访问共域名的标准做法维护纪律starter 文件明确要求「不要直接编辑其中资源应拆分为独立文件」为后续增量维护预留了清晰的操作边界。赞分享可观测性云原生【免费下载链接】pixieInstant Kubernetes-Native Application Observability项目地址https://gitcode.com/gh_mirrors/pixie/pixie点击查看免费下载相关推荐Strimzi Helm Chart 深度解析用 Helm 在 Kubernetes 上部署与配置 Kafka Cluster OperatorStrimzi Helm Chart 深度解析用 Helm 在 Kubernetes 上部署与配置 Kafka Cluster Operator 本文基于 S云原生后端消息队列在 Kubernetes 上用 Helm 部署 Bytebase安装、升级与配置深度指南在 Kubernetes 上用 Helm 部署 Bytebase安装、升级与配置深度指南 导读 Bytebase 是一个面向 DevOps 团队、为开发者和后端数据库数据治理认证鉴权数据库客户端在 Kubernetes 上部署 GogsHelm Chart 安装、配置与架构解析在 Kubernetes 上部署 GogsHelm Chart 安装、配置与架构解析 GogsGo Git Service是一款用 Go 语言编写的轻量级上一篇Flow 代码现代化用 unknown 取代 mixed —— 以 Flow AI Evals 的 modernize_008_mixed 评测为例下一篇Pandoc 中 引用的双重语义示例列表引用与作者在文引用author-in-text citation的解析机制与测试验证创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考