云原生后端前端【免费下载链接】kubeappsA web-based UI for deploying and managing applications in Kubernetes clusters项目地址https://gitcode.com/gh_mirrors/ku/kubeapps点击查看免费下载Kubeapps 是一个用于在 Kubernetes 集群中部署和管理应用的开源 Web UI。当社区成员希望对 Kubeapps 引入重大变更时官方要求先走一套正式的提案Proposal流程在动手实现之前先对问题陈述与解决方案设计达成共识。本文基于仓库中的 proposals.md 与同目录下十余份历史提案文档系统讲解提案的适用场景、提交步骤、状态机、完整生命周期、评审标准与文档维护策略并结合仓库源码展示这些提案从设计到落地的真实轨迹。什么是 Proposal提案是一份设计文档用于在开始实现工作之前围绕一个问题陈述和解决方案设计建立共识。它有三个基本定义提案描述的是对 Kubeapps 的一项**重大significant**变更提案必须由至少一位 maintainer 赞助sponsored或共同撰写co-authored社区中的任何人都可以提交和评审提案。换句话说提案是 Kubeapps 的RFC 机制——它不是普通的功能请求而是带有明确设计边界、评审门槛和状态流转的工程决策载体。仓库中全部提案存放在 proposals 目录由 README.md 统一索引其中记录了每份提案的标题、作者、概述、审批日期与关联 Issue/PR。何时提交 Proposal何时提交 IssueKubeapps 的贡献流程将重大变更与常规问题做了明确区分场景推荐渠道原因潜在功能或工作方向存在重大风险复杂性高、实现成本大、产品可行性存疑等Proposal需要在实现前获得反馈与批准功能已被充分理解、风险低普通 GitHub Issue用于澄清细节即可计划创建 PR 修改 Kubeapps 源码但不确定变更是否足够重大询问 maintainers由维护者判断是否需要走提案流程只是想分享遇到的问题或功能想法不打算设计技术方案或提交实现 PR普通 GitHub Issue无需启动完整提案流程仓库的 Issue 模板体系.github/ISSUE_TEMPLATE 目录提供了 bug-report、feature-request、support-request 等不同模板提案流程则使用专门的 Proposal request 模板发起。如何提交 Proposal提交一份提案需要三个步骤在仓库中新建一个 GitHub Issue选择Proposal request的 Issue 模板。创建提案后记下该 Issue 的编号。这个 Issue 可以充当提案与实现 PR 之间、以及各轮讨论的交流场所。提案正文应以独立的 Markdown 文件形式通过 PR 推送到仓库的 proposals 目录 根目录。仓库中的历史提案恰好演示了这套提交方式。例如 error-handling.md 在文件头标注了作者migmartri、日期2018/10/02、类型Design Doc和关联 Issuekubeapps#657helm3.md 则在正文中说明了Helm 2 与 Helm 3 组件共存、部署时通过helm3true选择的设计决策。这些文件头信息正是Issue 记录讨论、PR 承载文档这一流程的落地形态。Proposal 的五个状态为了跟踪提案的推进情况流程定义了如下状态机状态定义draft提案正由作者积极撰写中尚未准备好接受评审in-review提案正在接受社区与项目 maintainer 的评审rejected提案已被项目 maintainer 拒绝accepted提案已被项目 maintainer 接受implemented提案已被接受并已完成实现从 README.md 的提案清单可以看出状态流转的节奏例如 AuthN/AuthZ in Kubeapps2018-04-09PR #218、Helm 3 support2019-11-04PR #1250、Replacing MongoDB support2019-12-03PR #1313等均已从accepted走向implemented而每份提案都保留了审批日期与关联 Issue/PR两列方便追溯决策历史。Proposal 生命周期全流程官方流程将提案从发起到落地或否决定义为 8 个环节作者创建 Proposal request Issue。作者以 draft 模式创建 PR允许作者随时保存工作进度。该 PR 必须在 proposals 目录 根目录包含一个 Markdown 文件引用 Proposal request通过附上其 GitHub Issue 编号。当作者认为提案已足够完善、可以接受评审时将 Proposal request 的状态改为in-review将 PR 标记为Ready for Review。社区评审提案通过提交 PR review 意见使提案不断成熟、收敛。当 maintainer 达成共识或**超多数supermajority**同意接受提案时将 Proposal request 状态改为accepted在提案的 Markdown 文件中加入Engineering Decision RecordEDR工程决策记录涵盖以下主题considered options已考虑的方案选项pros and cons各选项的利弊decision drivers决策驱动因素decision outcome决策结论。合并 PR将新提案并入main分支实现代码的 PR另行提交用来落地该方案。已接受提案的实现阶段每创建一个实现 PR都应更新 Proposal request 以链接到该实现 PR当所有实现 PR 合并后将 Proposal request 状态更新为implemented列出全部相关 PR然后关闭该 Proposal request提案 Markdown 文件应补充发布版本号即该功能随哪个版本发布如果实现过程中发现需要重大的、未预期的变更应暂停实现工作先更新提案内容并再次提交 maintainer 评审之后才能继续实现。当 maintainer 未达成共识或超多数时提案被拒绝此时可将 Proposal request 状态标记为rejected关闭 PR并附上解释拒绝原因的说明关闭 Proposal request。被拒绝的提案可以重新开启如果提案发生了实质性的修改、能够回应此前被拒的原因被拒的提案 PR以及对应的 Proposal request可以被重新打开并移回in-review状态。仓库中的 replacing-mongodb.md 就是 EDR 结构的典型示范它先描述问题MongoDB 的缺陷与许可证问题列出需求清单高可用、开源许可证、高性能、可扩展性、向后兼容随后逐一评估 Kubernetes Native Resources、Redis、PostgreSQL、FoundationDB Document Layer 四种备选方案并给出各自的 Pros/Cons最终得出采用 PostgreSQL、默认仍用 MongoDB 以避免破坏性变更、新大版本切换默认值的决策结论——这正是considered options → pros and cons → decision drivers → decision outcome的完整落实。提案评审标准一旦提案 PR 被标记为 Ready for Review社区与全体 maintainer 都会参与评审。评审的目标是理解要解决的问题与拟议方案的设计。Maintainer 会从以下维度综合考量问题是否属于项目的范围方案实现所带来的未来维护成本是否值得为解决该问题而付出方案与项目其余部分是否保持合理的一致性方案对 Kubeapps 的可用性、安全性、可扩展性、性能、可观测性与可靠性有何影响方案在实现上如何架构、如何通过自动化进行测试实现方案可能引入哪些风险如果由 maintainer 亲自实现实施所花费时间的机会成本是多少可以看到评审不仅关注能不能做更关注长期维护成本是否合理、是否与项目整体架构一致这类工程经济性判断。这也是为什么提案必须由 maintainer 赞助——只有维护者才能对这类长期成本做出承诺。已接受提案文档的维护策略提案文档反映的是某一时间点的设计与决策。一旦获批它们就变成了历史文档historical documents而非活跃文档living documents未来没有义务继续维护它们。与之相对如果某个源自先前提案的功能发生了重大变化应提出一份全新提案新提案在适当时应链接到旧提案以提供历史背景。这一策略解释了 proposals 目录 中为什么既有 2018 年的 authentication-and-authorization.md也有 2020 年的 multi-cluster-support.md 和 2023 年的 OCI-registries.md——它们是各自时代的决策快照阅读时应注意其中的技术前提可能已经演进。例如 authentication-and-authorization.md 文内就明确标注了DEPRECATED警示使用 Kubernetes Service Token / Kubeconfig 凭据做用户登录存在严重安全问题推荐改用前置认证代理auth-proxy通过标准 SSO 服务获取短期用户令牌。获取流程帮助对提案流程有任何疑问可以在 Kubernetes Slack 工作区的#kubeapps频道中联系 maintainer。从流程到实践仓库中提案的落地轨迹提案流程的价值最终体现在设计到实现的闭环上。以仓库源码为证可以清晰地看到多份提案的落地AuthN/AuthZ in Kubeapps2018-04-09提案最初讨论用 Kubernetes 凭据登录后来演进为 OIDC/SSO 方案。图表层落地在 chart/kubeapps/templates/frontend/oauth2-secret.yaml其中cookieSecret参数对应提案所述的 OAuth2 Proxy 认证层文档层见 using-an-OIDC-provider.md。Dashboard Error Handling2018-10-17提案提出用 React Error Boundary 实现全局兜底错误提示、用单一 ErrorContainer 连接 Redux 错误命名空间。当前 dashboard/src/components/Layout/Layout.tsx 中仍可找到 ErrorBoundary 相关的错误渲染逻辑。Helm 3 support2019-11-04提案主张以 Helm 3 actions 库替代 Tiller 代理用InClusterConfig替换用户 BearerToken。如今 Helm 插件实现位于 cmd/kubeapps-apis/plugins/helm/packages/v1alpha1如 repositories.go、server.go。Replacing MongoDB support2019-12-03提案将chartsvc更名为assetsvc、chart-repo更名为asset-syncer并改用 PostgreSQL。源码中 pkg/dbutils/postgresql_utils.go 与 cmd/asset-syncer 正是该决策的实现证据。Third party add repository2019-10-14提案定义外部系统如 Harbor通过 API 向 Kubeapps 添加仓库/触发部署的接口。对应的仓库创建逻辑在 repositories.go 中实现。Multi-cluster support2020-06-09提案设计在一个集群部署 Kubeapps、向其他集群安装应用的能力。前端命名空间/集群切换相关组件位于 dashboard/src/components/Header/ContextSelector.tsx。Operators support2020-03-05提案以 OperatorHub 为 Operator 来源、以 OLM 的 CRD 为数据源实现 PoC。前端相关视图位于 dashboard/src/components/OperatorList、dashboard/src/components/OperatorView 等目录。Kubeapps OCI Catalog2023-05-17提案评估 Kubeapps 在 OCI 世界的目录能力落地为独立的 cmd/oci-catalogRust 实现含 catalog/v1alpha1 协议。小结Kubeapps 的提案流程是一套轻量但严谨的工程决策机制用 Issue 承载讨论、用 PR 承载设计文档、用五状态机跟踪进展、用 EDR 沉淀决策依据、用独立实现 PR 完成落地。对于想要为 Kubeapps 贡献重大特性的开发者正确的路径是先评估风险 → 创建 Proposal request → 以 draft PR 提交设计文档 → 与社区和 maintainer 共同评审收敛 → 达成共识后获得accepted→ 再以独立 PR 逐步实现。想快速了解历史决策全貌可直接浏览 proposals 目录 的索引清单README.md并按需深入阅读各提案原文。赞分享云原生后端前端【免费下载链接】kubeappsA web-based UI for deploying and managing applications in Kubernetes clusters项目地址https://gitcode.com/gh_mirrors/ku/kubeapps点击查看免费下载相关推荐Wasmtime 与 Cranelift 的 RFC 流程重大变更如何通过社区提案达成共识Wasmtime 与 Cranelift 的 RFC 流程重大变更如何通过社区提案达成共识 本篇指南以 docs/contributing rfc proce语言运行时JIT编译编译器GDAL项目RFC流程详解如何规范提交重大代码变更GDAL项目RFC流程详解如何规范提交重大代码变更 什么是RFC流程 在GDAL项目中RFC Request For Comments 流程是针对重大代码变GIS遥感数据工程Mojo 提案RFC流程如何用书面设计文档驱动语言与标准库的重大变更Mojo 提案RFC流程如何用书面设计文档驱动语言与标准库的重大变更 在 MojoModular Platform仓库中任何超出常规贡献范围的重大改人工智能大模型编程语言编译器标准库算子库模型推理服务模型量化上一篇Palmer Penguins数据分析新手的终极入门指南下一篇ML.NET模型压缩与优化machinelearning-samples性能提升终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考