尧图网页设计 
Kubernetes SIG Testing 2021 年度报告全解读kubetest2 成熟、Prow 能力演进与 Bazel 移除【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community本篇技术文章以 Kubernetes 社区仓库中 sig-testing/annual-report-2021.md 为主体骨架系统解读 SIG Testing 在 2021 年的核心工作kubetest2 测试框架走向成熟、Prow 为外部开源社区输出 CI/CD 能力GitHub Apps、配置分片、多租户等、以及构建系统 Bazel 的彻底移除。同时结合仓库内 SIG Testing 章程、子项目清单、sigs.yaml 以及 端到端测试实战文档 等源码与文档证据为读者还原 2021 年 Kubernetes 测试基础设施的真实演进路径并给出可直接落地的 kubetest2 使用方法。一、SIG Testing 的使命与 2021 年度定位在深入年度报告之前先明确 SIG Testing 在 Kubernetes 项目中的职责边界。根据 sig-testing/charter.md 的定义SIG Testing 关注 Kubernetes 的有效测试与自动化消除项目苦差事automating away project toil在范围内项目 CI 与工作流自动化prow、tide、大规模运行 CI 的基础设施boskos、ghproxy、测试结果的上传与展示kettle、testgrid、triage、作业配置管理job configs、kubetest、GitHub 配置管理peribolos、label_sync、本地测试工具kind以及面向 Kubernetes 的测试框架e2e 测试框架等在范围外不为其他 SIG 所拥有的特性测试编写、修复或排障也不负责项目 CI Signal 的日常维护——但会产出去噪工具帮助提升信号质量。该使命在 sigs.yaml 中被精炼为一句 mission statement让社区更容易运行测试并贡献测试结果确保 Kubernetes 在各种集群配置和云提供商之上保持稳定。2021 年年度报告的所有内容本质上都是这句话的落地执行。二、2021 年核心工作亮点盘点1. kubetest2 框架走向成熟报告将kubetest2 is maturing列为年度首要成果。kubetest2 是 kubetest 的下一代迭代目标是启动并运行 Kubernetes 端到端测试的框架kubetest 后续将被弃用。在 sig-testing/README.md 的子项目清单中kubetest2 明确标注为Kubetest2 is the framework for launching and running end-to-end tests on kubernetes. It is the next significant iteration of kubetest. We will be deprecating kubetest going forward.仓库中的 e2e-tests-kubetest2.md 记录了 kubetest2 的具体用法详见本文第六节其插件体系覆盖 Google Cloud Compute Enginekubetest2-gce、Google Cloud Kubernetes Enginekubetest2-gke与 KINDkubetest2-kind三类部署目标支撑起本地开发与云端 CI 的同一套入口。2. Prow 的秘密同步自动化报告提到为 ProwJob secrets 实现了自动化的 secret syncing。这是 Prow 运维层面的重要改进Prow 作业往往需要访问各类凭证通过自动化同步机制替代人工维护降低了多集群、多仓库场景下凭证配置漂移的风险。这是 Prow 作为基于 Kubernetes 的 CI/CD 系统见 sig-testing/README.md 中 prow 子项目描述在自我运维能力上的增强。3. Prow 对外输出服务更多开源项目与社区2021 年 Prow 的另一条主线是为其他开源项目和社区提供 CI/CD 能力年度报告列举了七项具体改进能力项说明GitHub Apps 支持允许 Prow 以 GitHub App 而非传统 bot 账号身份接入提升权限粒度与安全性作业配置校验增强严格字段检查、构建集群存在性校验将配置错误前置到加载阶段In-repo 配置支持与性能改进支持在仓库内直接维护 Prow 配置并优化其解析与热加载性能配置文件分片支持将配置文件拆分从而更好地管理审批approval权限边界新监控栈采用 GKE Workload Metrics Cloud Monitoring摆脱对 Grafana 的依赖OSS-Fuzz 集成接入 OSS-Fuzz为 Prow 相关组件提供持续模糊测试能力私有仓库多租户支持多个私有前端multiple private front ends满足私有化部署场景这些能力使得 Prow 从一个Kubernetes 专用 CI逐步进化为可被其他社区直接复用的通用 CI/CD 平台这一点与后续 2022 年度报告中发布 Prow 文档站点、Prow API 服务Gangway 组件合入等进展形成了清晰的演进脉络见 sig-testing/annual-report-2022.md。4. Bazel 的彻底移除2021 年完成了两项与 Bazel 相关的里程碑kubernetes/kubernetes 仓库的 Bazel 移除达到 GA这正是 KEP 2420 - Reducing Kubernetes Build Maintenance1.23.stable的目标标志着 Kubernetes 主仓构建维护成本的显著下降kubernetes/test-infra 仓库的 Bazel 移除接近完成测试基础设施自身也摆脱了 Bazel进一步简化依赖与构建流程。三、KEP 工作与治理讨论1. 2021 年 KEP 状态一览年度报告记录了三个与 SIG Testing 直接相关的 KEP 进展StableKEP 2420 - Reducing Kubernetes Build Maintenance随 v1.23 达成 stable——即上文提到的 Bazel 移除 GABetaKEP 2539 - Continuously Deploy K8s Prowv1.21.beta——推动 Prow 自身的持续部署让 Prow 的发布流程也由 Prow 自己驱动BetaKEP 2464 - kubetest2 CI migrationv1.23.beta——将 Kubernetes 项目自身的 CI 逐步迁移到 kubetest2 之上是 kubetest2 成熟度的重要验证场景。2. 关于未被 KEP 跟踪的工作的自我反思报告坦诚指出SIG Testing 的大部分工作并未通过 KEP 跟踪并认为现有 KEP 流程更适合最终用户特性更多面向终端用户而非贡献者。这实际上反映了 SIG Testing 工作性质的特殊性——大量工作是测试基础设施与贡献者体验层面的很难用面向用户特性的 KEP 模板来表达。报告中明确表达了改进意愿We need to do better with bringing issues to groups and individuals to gain consensus.需要在把议题带给相关小组和个人、达成共识方面做得更好。这一自我认知与 sig-testing/charter.md 中的治理条款相互印证——章程允许在不使用 KEP 的前提下提出并做出决策只要决策被记录在可链接的媒介中优先使用 kubernetes/test-infra 上的 issue 记录技术决策说明 SIG Testing 的治理风格本就是轻 KEP、重 issue 共识。四、项目健康度风险点与社区健康指标1. 需要帮助的领域年度报告以任何拥有 2 个或更少 OWNER 的领域为标准识别出五个健康度风险点子项目/工具风险描述Boskos功能稳定但一旦坏了项目 CI 就陷入困境是项目 CI 的单点依赖K8s GSM Tool实习项目未获足够牵引力建议考虑归档并与相关负责人讨论后续 2022 年度报告 确认其在 2022 年被 Retiredkubetest2仅有一位活跃的 reviewer/approver报告点名 Ben存在单点维护风险Prow由于 Grafana 许可变更Google 无法继续维护 monitoring.prow.k8s.io已切换至 Google Cloud Monitoring但仪表盘无法公开可见需要 SIG-k8s-infra 接管否则公共监控仪表盘可能很快丢失其中 boskos 指标仪表盘是最显著的损失当前 Grafana 实例已被冻结Triage Kettle优先级不高但在排查 flaky 测试时被广泛使用这些工具在 sig-testing/README.md 与 sig-testing/charter.md 中均有对应描述boskos 是管理各类资源并在不同状态间迁移的资源管理器服务Kubernetes 项目用它管理 CI/CD 所需的 GCP 项目池triage/kettle 属于测试产物提取、展示与分析链路。2. 社区健康指标SIG Testing 在 2021 年关注的社区健康指标主要是Reviewers 与 Approvers 的数量——这与贡献者梯队contributor ladder直接挂钩参见 community-membership.md。3. 贡献者引导现状报告坦承sig-testing/CONTRIBUTING.md 当时并不存在。当前仓库中的 sig-testing/CONTRIBUTING.md 已补上该文件内容直接指向 kubernetes/test-infra 的 CONTRIBUTING 文档说明该缺口已在后续得到弥补。4. 多公司参与情况报告确认 SIG Testing 的 OWNERS 以 Google 和 Red Hat 为主力同时也有来自 ii.co、VMware 等公司的贡献者。在 sigs.yaml 中可以看到当前领导团队同样呈现多公司构成chairs 来自 Red Hat 与 Googletech leads 来自 Google 与 Intel印证了跨公司协作是 SIG Testing 的常态。5. 对社区参与的呼吁报告明确发出呼吁We need folks to show up and stick around to climb the contributor ladder.我们需要有人持续参与、留下来沿着贡献者阶梯向上攀登。这意味着除代码贡献外持续参与评审、担任 reviewer/approver 是 SIG 最需要的外部支持。五、社区规模数据2021 年年度报告给出的 Membership 数据如下指标数值主 Slack 频道成员数2117主邮件列表成员数341主会议参会人数估算10主会议互动人数估算6SIG 所属包唯一 reviewers 数未填写后续 2022 年报告给出 24SIG 所属包唯一 approvers 数未填写后续 2022 年报告给出 26对照 sig-testing/annual-report-2022.md次年 Slack 成员增至 2452、邮件列表增至 407并首次披露了 24 名唯一 reviewers 与 26 名唯一 approvers 的量化指标可见年度报告模板本身也在逐步完善统计口径。六、2021 年成果的实战落地kubetest2 使用速览kubetest2 的成熟并非停留在口号上——仓库中的 e2e-tests-kubetest2.md 给出了完整可用的操作流程这正是 2021 年 kubetest2 能力建设成果的直观呈现。Kubernetes 的端到端测试基于 Ginkgo/GomegaBDD 测试框架构建kubetest2 是管理这些测试的辅助工具。安装 kubetest2 及插件go install sigs.k8s.io/kubetest2/...latest可用插件包括 Google Cloud Compute Enginekubetest2-gce、Google Cloud Kubernetes Enginekubetest2-gke与 KINDkubetest2-kind。构建与启停集群# 构建 Kuberneteslegacy 模式 kubetest2 gce --build --legacy-mode # 拉起并启动测试集群 kubetest2 gce --gcp-project project --up # 关闭并销毁测试集群 kubetest2 gce --gcp-project project --down运行测试与传递 Ginkgo 参数在--之后的所有参数都会原样传给 Ginkgo例如# 运行匹配 [Feature:Performance] 的测试 kubetest2 gce --test ginkgo -- --focus-regex \[Feature:Performance\] # 排除匹配 Pods.*env 的测试 kubetest2 gce --test ginkgo -- --skip-regex Pods.*env # 跳过 [Serial] 并开启 2 个并行测试 kubetest2 gce --test ginkgo -- --skip-regex \[Serial\] --parallel 2 # 指定测试特定版本如 v1.26.0-alpha.2 kubetest2 gce --test ginkgo -- --test-package-version v1.18.0调试与清理测试集群的 kubeconfig 保存在工作目录的_artifacts/kubetest2-kubeconfig可用KUBECONFIG./_artifacts/kubetest2-kubeconfig kubectl cluster-info dump收集集群状态kubetest2在--up时还会自动把日志转储到_artifacts/cluster-logs/。若出现异常遗留资源执行kubetest2 gce --gcp-project project --down即可有序清理。七、2021 年报告与后续年度的连续性验证作为佐证sig-testing/annual-report-2022.md 中的多项条目与 2021 年报告形成前后呼应2021 年kubetest2 成熟→ 2022 年仍在推动 kubetest2 相关维护并延续对更多 reviewer/approver 的呼吁2021 年Prow 监控脱离 Grafana→ 2022 年 TestGrid API 上线testgrid-data.k8s.io、Prow API 服务Gangway合入Prow 的平台化路线持续深化2021 年k8s-gsm-tools 建议归档→ 2022 年正式 Retired2021 年CONTRIBUTING.md 缺失→ 2022 年报告确认该文件已就绪指向 test-infra 的 Issue Triage 流程。这组对照说明年度报告不仅是单年成绩单更是观察 SIG Testing 长期技术路线测试框架换代、CI 平台化、构建系统瘦身、监控栈重构的连续档案。结合仓库内 flaky-tests.mdtriage/testgrid 工具链的使用、testing-strategy.md测试金字塔与 CI 作业类型以及 sig-governance.md治理规范读者可以在本仓库内完成从年度成果到工程实践再到治理机制的完整知识闭环。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kubernetes SIG Testing 2021 年度报告全解读：kubetest2 成熟、Prow 能力演进与 Bazel 移除
Kubernetes SIG Testing 2021 年度报告全解读kubetest2 成熟、Prow 能力演进与 Bazel 移除【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community本篇技术文章以 Kubernetes 社区仓库中 sig-testing/annual-report-2021.md 为主体骨架系统解读 SIG Testing 在 2021 年的核心工作kubetest2 测试框架走向成熟、Prow 为外部开源社区输出 CI/CD 能力GitHub Apps、配置分片、多租户等、以及构建系统 Bazel 的彻底移除。同时结合仓库内 SIG Testing 章程、子项目清单、sigs.yaml 以及 端到端测试实战文档 等源码与文档证据为读者还原 2021 年 Kubernetes 测试基础设施的真实演进路径并给出可直接落地的 kubetest2 使用方法。一、SIG Testing 的使命与 2021 年度定位在深入年度报告之前先明确 SIG Testing 在 Kubernetes 项目中的职责边界。根据 sig-testing/charter.md 的定义SIG Testing 关注 Kubernetes 的有效测试与自动化消除项目苦差事automating away project toil在范围内项目 CI 与工作流自动化prow、tide、大规模运行 CI 的基础设施boskos、ghproxy、测试结果的上传与展示kettle、testgrid、triage、作业配置管理job configs、kubetest、GitHub 配置管理peribolos、label_sync、本地测试工具kind以及面向 Kubernetes 的测试框架e2e 测试框架等在范围外不为其他 SIG 所拥有的特性测试编写、修复或排障也不负责项目 CI Signal 的日常维护——但会产出去噪工具帮助提升信号质量。该使命在 sigs.yaml 中被精炼为一句 mission statement让社区更容易运行测试并贡献测试结果确保 Kubernetes 在各种集群配置和云提供商之上保持稳定。2021 年年度报告的所有内容本质上都是这句话的落地执行。二、2021 年核心工作亮点盘点1. kubetest2 框架走向成熟报告将kubetest2 is maturing列为年度首要成果。kubetest2 是 kubetest 的下一代迭代目标是启动并运行 Kubernetes 端到端测试的框架kubetest 后续将被弃用。在 sig-testing/README.md 的子项目清单中kubetest2 明确标注为Kubetest2 is the framework for launching and running end-to-end tests on kubernetes. It is the next significant iteration of kubetest. We will be deprecating kubetest going forward.仓库中的 e2e-tests-kubetest2.md 记录了 kubetest2 的具体用法详见本文第六节其插件体系覆盖 Google Cloud Compute Enginekubetest2-gce、Google Cloud Kubernetes Enginekubetest2-gke与 KINDkubetest2-kind三类部署目标支撑起本地开发与云端 CI 的同一套入口。2. Prow 的秘密同步自动化报告提到为 ProwJob secrets 实现了自动化的 secret syncing。这是 Prow 运维层面的重要改进Prow 作业往往需要访问各类凭证通过自动化同步机制替代人工维护降低了多集群、多仓库场景下凭证配置漂移的风险。这是 Prow 作为基于 Kubernetes 的 CI/CD 系统见 sig-testing/README.md 中 prow 子项目描述在自我运维能力上的增强。3. Prow 对外输出服务更多开源项目与社区2021 年 Prow 的另一条主线是为其他开源项目和社区提供 CI/CD 能力年度报告列举了七项具体改进能力项说明GitHub Apps 支持允许 Prow 以 GitHub App 而非传统 bot 账号身份接入提升权限粒度与安全性作业配置校验增强严格字段检查、构建集群存在性校验将配置错误前置到加载阶段In-repo 配置支持与性能改进支持在仓库内直接维护 Prow 配置并优化其解析与热加载性能配置文件分片支持将配置文件拆分从而更好地管理审批approval权限边界新监控栈采用 GKE Workload Metrics Cloud Monitoring摆脱对 Grafana 的依赖OSS-Fuzz 集成接入 OSS-Fuzz为 Prow 相关组件提供持续模糊测试能力私有仓库多租户支持多个私有前端multiple private front ends满足私有化部署场景这些能力使得 Prow 从一个Kubernetes 专用 CI逐步进化为可被其他社区直接复用的通用 CI/CD 平台这一点与后续 2022 年度报告中发布 Prow 文档站点、Prow API 服务Gangway 组件合入等进展形成了清晰的演进脉络见 sig-testing/annual-report-2022.md。4. Bazel 的彻底移除2021 年完成了两项与 Bazel 相关的里程碑kubernetes/kubernetes 仓库的 Bazel 移除达到 GA这正是 KEP 2420 - Reducing Kubernetes Build Maintenance1.23.stable的目标标志着 Kubernetes 主仓构建维护成本的显著下降kubernetes/test-infra 仓库的 Bazel 移除接近完成测试基础设施自身也摆脱了 Bazel进一步简化依赖与构建流程。三、KEP 工作与治理讨论1. 2021 年 KEP 状态一览年度报告记录了三个与 SIG Testing 直接相关的 KEP 进展StableKEP 2420 - Reducing Kubernetes Build Maintenance随 v1.23 达成 stable——即上文提到的 Bazel 移除 GABetaKEP 2539 - Continuously Deploy K8s Prowv1.21.beta——推动 Prow 自身的持续部署让 Prow 的发布流程也由 Prow 自己驱动BetaKEP 2464 - kubetest2 CI migrationv1.23.beta——将 Kubernetes 项目自身的 CI 逐步迁移到 kubetest2 之上是 kubetest2 成熟度的重要验证场景。2. 关于未被 KEP 跟踪的工作的自我反思报告坦诚指出SIG Testing 的大部分工作并未通过 KEP 跟踪并认为现有 KEP 流程更适合最终用户特性更多面向终端用户而非贡献者。这实际上反映了 SIG Testing 工作性质的特殊性——大量工作是测试基础设施与贡献者体验层面的很难用面向用户特性的 KEP 模板来表达。报告中明确表达了改进意愿We need to do better with bringing issues to groups and individuals to gain consensus.需要在把议题带给相关小组和个人、达成共识方面做得更好。这一自我认知与 sig-testing/charter.md 中的治理条款相互印证——章程允许在不使用 KEP 的前提下提出并做出决策只要决策被记录在可链接的媒介中优先使用 kubernetes/test-infra 上的 issue 记录技术决策说明 SIG Testing 的治理风格本就是轻 KEP、重 issue 共识。四、项目健康度风险点与社区健康指标1. 需要帮助的领域年度报告以任何拥有 2 个或更少 OWNER 的领域为标准识别出五个健康度风险点子项目/工具风险描述Boskos功能稳定但一旦坏了项目 CI 就陷入困境是项目 CI 的单点依赖K8s GSM Tool实习项目未获足够牵引力建议考虑归档并与相关负责人讨论后续 2022 年度报告 确认其在 2022 年被 Retiredkubetest2仅有一位活跃的 reviewer/approver报告点名 Ben存在单点维护风险Prow由于 Grafana 许可变更Google 无法继续维护 monitoring.prow.k8s.io已切换至 Google Cloud Monitoring但仪表盘无法公开可见需要 SIG-k8s-infra 接管否则公共监控仪表盘可能很快丢失其中 boskos 指标仪表盘是最显著的损失当前 Grafana 实例已被冻结Triage Kettle优先级不高但在排查 flaky 测试时被广泛使用这些工具在 sig-testing/README.md 与 sig-testing/charter.md 中均有对应描述boskos 是管理各类资源并在不同状态间迁移的资源管理器服务Kubernetes 项目用它管理 CI/CD 所需的 GCP 项目池triage/kettle 属于测试产物提取、展示与分析链路。2. 社区健康指标SIG Testing 在 2021 年关注的社区健康指标主要是Reviewers 与 Approvers 的数量——这与贡献者梯队contributor ladder直接挂钩参见 community-membership.md。3. 贡献者引导现状报告坦承sig-testing/CONTRIBUTING.md 当时并不存在。当前仓库中的 sig-testing/CONTRIBUTING.md 已补上该文件内容直接指向 kubernetes/test-infra 的 CONTRIBUTING 文档说明该缺口已在后续得到弥补。4. 多公司参与情况报告确认 SIG Testing 的 OWNERS 以 Google 和 Red Hat 为主力同时也有来自 ii.co、VMware 等公司的贡献者。在 sigs.yaml 中可以看到当前领导团队同样呈现多公司构成chairs 来自 Red Hat 与 Googletech leads 来自 Google 与 Intel印证了跨公司协作是 SIG Testing 的常态。5. 对社区参与的呼吁报告明确发出呼吁We need folks to show up and stick around to climb the contributor ladder.我们需要有人持续参与、留下来沿着贡献者阶梯向上攀登。这意味着除代码贡献外持续参与评审、担任 reviewer/approver 是 SIG 最需要的外部支持。五、社区规模数据2021 年年度报告给出的 Membership 数据如下指标数值主 Slack 频道成员数2117主邮件列表成员数341主会议参会人数估算10主会议互动人数估算6SIG 所属包唯一 reviewers 数未填写后续 2022 年报告给出 24SIG 所属包唯一 approvers 数未填写后续 2022 年报告给出 26对照 sig-testing/annual-report-2022.md次年 Slack 成员增至 2452、邮件列表增至 407并首次披露了 24 名唯一 reviewers 与 26 名唯一 approvers 的量化指标可见年度报告模板本身也在逐步完善统计口径。六、2021 年成果的实战落地kubetest2 使用速览kubetest2 的成熟并非停留在口号上——仓库中的 e2e-tests-kubetest2.md 给出了完整可用的操作流程这正是 2021 年 kubetest2 能力建设成果的直观呈现。Kubernetes 的端到端测试基于 Ginkgo/GomegaBDD 测试框架构建kubetest2 是管理这些测试的辅助工具。安装 kubetest2 及插件go install sigs.k8s.io/kubetest2/...latest可用插件包括 Google Cloud Compute Enginekubetest2-gce、Google Cloud Kubernetes Enginekubetest2-gke与 KINDkubetest2-kind。构建与启停集群# 构建 Kuberneteslegacy 模式 kubetest2 gce --build --legacy-mode # 拉起并启动测试集群 kubetest2 gce --gcp-project project --up # 关闭并销毁测试集群 kubetest2 gce --gcp-project project --down运行测试与传递 Ginkgo 参数在--之后的所有参数都会原样传给 Ginkgo例如# 运行匹配 [Feature:Performance] 的测试 kubetest2 gce --test ginkgo -- --focus-regex \[Feature:Performance\] # 排除匹配 Pods.*env 的测试 kubetest2 gce --test ginkgo -- --skip-regex Pods.*env # 跳过 [Serial] 并开启 2 个并行测试 kubetest2 gce --test ginkgo -- --skip-regex \[Serial\] --parallel 2 # 指定测试特定版本如 v1.26.0-alpha.2 kubetest2 gce --test ginkgo -- --test-package-version v1.18.0调试与清理测试集群的 kubeconfig 保存在工作目录的_artifacts/kubetest2-kubeconfig可用KUBECONFIG./_artifacts/kubetest2-kubeconfig kubectl cluster-info dump收集集群状态kubetest2在--up时还会自动把日志转储到_artifacts/cluster-logs/。若出现异常遗留资源执行kubetest2 gce --gcp-project project --down即可有序清理。七、2021 年报告与后续年度的连续性验证作为佐证sig-testing/annual-report-2022.md 中的多项条目与 2021 年报告形成前后呼应2021 年kubetest2 成熟→ 2022 年仍在推动 kubetest2 相关维护并延续对更多 reviewer/approver 的呼吁2021 年Prow 监控脱离 Grafana→ 2022 年 TestGrid API 上线testgrid-data.k8s.io、Prow API 服务Gangway合入Prow 的平台化路线持续深化2021 年k8s-gsm-tools 建议归档→ 2022 年正式 Retired2021 年CONTRIBUTING.md 缺失→ 2022 年报告确认该文件已就绪指向 test-infra 的 Issue Triage 流程。这组对照说明年度报告不仅是单年成绩单更是观察 SIG Testing 长期技术路线测试框架换代、CI 平台化、构建系统瘦身、监控栈重构的连续档案。结合仓库内 flaky-tests.mdtriage/testgrid 工具链的使用、testing-strategy.md测试金字塔与 CI 作业类型以及 sig-governance.md治理规范读者可以在本仓库内完成从年度成果到工程实践再到治理机制的完整知识闭环。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考