一个名为kubriX的新平台已经在开发者社区中发布，声称可以创建一个功能齐全的内部开发者平台（IDP）而无需大量定制开发。该平台由包括开发者倡导者Artem Lajko在内的贡献者开发，他撰写了一篇关于它的详细文章，集成了如Argo CD、Kargo、Backstage和Keycloak等成熟工具，成为其创作者描述的为寻求实施现代IDP的团队提供的即用型解决方案。

kubriX试图解决Lajko所指出的一个常见行业问题。当被问及自托管、开源的IDP是否能在部署后立即工作时，Lajko指出当前的平台很复杂，必须反映组织已经做出的许多架构选择，使团队面临适当工具的过多选择。

大多数公司已经运营基础设施，包括GitOps设置，如使用Argo CD或类似工具，通过Helm图表部署的第三方应用程序，云供应的Terraform模块，以及像Keycloak这样的认证系统。然而，Lajko解释说，这些实现通常缺乏一个真正的自助服务层，使开发者能够使用标准化模板来配置服务。Lajko继续解释说，kubriX试图通过提供一个由预定义组件构建的精选、主观但灵活的平台来填补这一空白。该系统使用Argo CD作为协调器，采用已建立的App of Apps模式以定义的顺序部署和管理其各种组件。

该平台的架构具有多层功能。对于持续交付，它提倡使用Argo CD的GitOps方法论。通过与Spotify的Backstage集成提供应用模板和脚手架功能。对于多租户和调度，kubriX部署Kubernetes并使用Capsule等附加工具提供适当的隔离。通过捆绑Cert-Manager进行证书管理，External Secrets Operator进行密钥管理，以及Kyverno进行策略管理，增加了安全性和合规性。

部署过程的前提条件很少：一个可用的Kubernetes集群和一个有效的kubeconfig文件。KubriX不提供集群，而是假设它已经存在。引导过程包括定义环境变量并运行一个设置脚本，该脚本在大约30分钟内触发完整部署。

KubriX声称对团队入职有全面的方法。该平台通过Backstage提供的模板自动创建拉取请求，并为GitHub组织内的团队建立App of Apps存储库。此过程包括定义团队可以从中部署资源的源存储库，并为团队特定的Argo CD应用程序构建所需结构。它还为Kubernetes集群的ApplicationSet控制器配置组织范围。

KubriX使用Kargo进行应用推广工作流，以便团队可以通过多个阶段一直部署应用到生产环境，并在应用通过团队的部署阶段时提供管道管理可视化。Argo CD AppProjects通过定义允许的存储库、目标集群、命名空间和Kubernetes资源，为共享的Argo CD实例中的应用提供多租户和适当的团队隔离。

Lajko强调了平台在实施时间表上的现实方法，与供应商承诺的即时功能形成对比。

在几周内获得一个完全运作的IDP，而不是几年——由经过验证的架构和模块化、灵活的构建块提供支持。

- Artem Lajko

整个平台试图通过提供自助服务能力、目录化的可重用服务、集成文档、管道集成、支持多租户的认证和API优先设计原则来满足具有多种组织角色的利益相关者。它并不试图完美地满足每个组织的要求；它旨在为团队通过主观IDP发展为现代平台开发提供一个全面的基础。它面向那些希望在没有大量开发开销或定制集成工作的情况下构建IDP的组织。

KubriX进入了一个竞争激烈的IDP市场，该市场已经有一些成熟的解决方案，尽管在内部平台开发方面的方法不同。Spotify的Backstage，可能是最知名的开源开发者门户，提供了一个可扩展的插件系统和全面的微服务目录功能。根据行业分析，Backstage受益于大型企业的采用和庞大的第三方生态系统，尽管它需要大量配置工作才能达到生产就绪状态。

• Port提供一个可组合的开发者门户，强调自助服务供应和治理功能。与kubriX的主观架构不同，Port专注于可扩展性和定制化，允许组织构建一个为其量身定制的解决方案。然而，这种灵活性可能会导致更长的实施时间。
• Argo CD虽然不是一个完整的IDP解决方案，但它是许多平台实现的基础组件，包括kubriX本身。作为一个CNCF采用的项目，推广GitOps实践已使其成为行业标准，尽管如此，组织通常需要额外的工具来完全满足开发者的需求。

竞争评估显示，尽管替代解决方案可能提供更广泛的集成或更成熟的生态系统，但它们通常需要更多的定制，特别是在需要合规控制的受监管行业中。

KubriX试图通过预先集成其所有组件提供即时功能来与众不同，尽管这种主观方法本质上限制了与更模块化替代方案相比的灵活性。然而，它声称兼容AWS、Azure、Google Cloud和本地部署。