剑指 Kubernetes！微软发布开源平台 Radius：高效构建、运行云原生应用程序

Kubernetes 最大的缺点就在于它预先加载了大量复杂性要素。复杂性本身有其合理性，但也意味着很多东西需要预先学习。

对于部分开发者和 IT 运维人员而言，在不断发展且日益复杂的云原生环境中部署、管理和理解应用程序，正变得越来越令人头痛。尽管 Kubernetes 等云基础设施和平台技术的发展的确让微服务应用程序的开发灵活性、可扩展性和可移植性有所改善，但同时也给开发者和运维人员带来了更大的挑战。

对开发者而言，基础设施的管理复杂性以及缺乏对构成其应用程序资源的可见性已经成为障碍生产力提升的关键因素；对运维团队而言，部署过程中缺乏标准化/自动化机制，则很可能导致其失去对基础设施的控制能力、降低对所部署应用程序的信心。最终，开发团队交付的成果在平台和云服务商之间出现使用体验脱节。面对现实问题，陈旧的工件列表往往很难帮助开发者和运维者确切了解自己的应用程序在不同工具集中到底是怎么组合起来的。

10 月 18 日，微软 Azure 孵化团队正式发布开源应用平台 Radius，该平台将应用程序置于每个开发阶段的中心，重新定义应用程序的构建、管理与理解方式。目前，Radius 维护团队正在将 Radius 提交至 CNCF，微软、BlackRock、Comcast 和 Millennium BVP 等企业也在共同努力，确保 Radius 能够与更广泛的云原生社区同步发展。

GitHub 地址：

https://github.com/radius-project

解决 Kubernetes 复杂性，微软发布 Radius 平台

据悉，Radius 凭借 Recipes 和 Connections 等标准化部署及自动化资源配置功能，为开发人员/运维人员及其团队提供一套统一工具集，用以开发有效协作。由于资源之间的关系，本质上就是在应用程序的创作与部署活动中确定下来的，因此 Radius 可以通过其应用程序图形数据全面了解组织架。此外，Radius 在立项之初就明确了开源加跨多云的思路，保证应用程序在一次编写之后，即可使用相同的工具集加工作流程被部署至任意云/本地基础设施之上。

Radius 专注于解决支持跨本地基础设施和云服务商（包括微软 Azure 及亚马逊云科技）的应用程序，在实际部署中所面对的平台工程挑战。Radius 能够同时满足开发者和运维人员的需求，为 Dapr 等各类流行应用程序开发工具、以及 Terraform 和 Bicep 等基础设施即代码（IaC）语言提供内置支持。

Radius 强调适应、而非破坏现有开发任务和 CI/CD 管线，致力于帮助开发人员更好地理解构成其应用程序的所有组件，并处理权限、连接字符串等平台配置，简化整个任务流程。如此一来，运维团队也能确保所有应用程序部署均符合组织策略，并使用 Radius 管理应用程序及其配套资源。

Radius 引入了应用程序图、提供基础设施 Recipes，并为跨云和边缘位置构建云原生应用的团队提供简洁且统一的开发体验。

Radius 初始开源版本提供了哪些功能？

在首个版本中，Radius 平台主要强调其核心基础功能以及如何提高应用程序的开发生产力，具体包括：

• 简化和统一应用程序开发体验：使用相同的应用程序定义在任意云服务商或本地环境中完成部署，且全面提供统一的工具和体验。具体包括资源的自动化访问和配置能力，以及通过配置满足各开发阶段对于环境的需求等。

• Recipes 与环境：对部署做标准化及扩展，明确区分开发人员与运维人员间的关注点差异。Radius Recipes 属于可预定义的模板，能够自动配置基础设施资源和环境，确保在设计上符合成本、安全性及合规性等标准。

• 应用程序图：用于了解构成应用程序的资源与资源。Radius 能够在开发进程当中捕捉应用程序中各资源之间的关系，并进一步查询和理解这些关系。

为了满足多云架构上不断增长的业务和技术需求，使用 Radius 定义和管理的应用程序可以依托同一组工具在任意云上实现部署和运行，意味着其应用程序代码、定义和开发工作流程均保持统一。无论应用程序是被部署至 Azure、亚马逊云科技还是本地，其创作、部署和管理体验都将保持不变。 此外，Radius 还能轻松对接并使用多种流行服务，例如 Redis、Mongo、Dapr 以及 SQL。随着社区需求的发展和变化，未来还将有更多服务被纳入支持范围。

此外，开发人员与运维人员在工作中需要具体协调，这必然导致大量不必要的手动流程，进而影响开发速度。为此，大多数组织都采取构建自定义管线或工单系统的方式进行基础设施部署，但这只能缓和一部分问题，而无法解决手动流程这块最致命的短板。Radius Recipes 的价值也正在此：运维人员能够配置 IaC 模板（Terraform 模块及 Bicep 文件），开发人员则利用这些模板自助完成资源配置和部署。Recipes 还允许运维人员定义和执行公司策略，例如可以使用哪些云资源、如何进行配置以及哪些员工有权部署等。如此一来，开发人员在构建应用程序时不必再分神于基础设施部署中的种种细节，能够专心一意编写应用程序代码。

例如，运维人员可以定义一个 Recipe 来部署组织生产所需要的 Redis 缓存：至少两个节点，至少两套副本。运维人员还可以指定 Redis 缓存必须被部署至特定区域，并预先配置正确的连接字符串及必要凭证。在定义了 Recipe 之后，开发人员就能使用它来部署 Redis 缓存，而不必担心具体部署细节或者配置是否正确。这种关注点分离，将使得运维团队得以扩大对开发者部门的支持，同时确保应用程序的部署始终符合组织策略。

云原生应用程序的最大管理挑战之一，就是如何保证应用程序所使用的云基础设施始终满足成本、运营和安全要求。这是因为 IT 运维人员往往对于已部署应用程序究竟用到哪些资源一无所知，这也限制了他们有效管理企业基础设施的能力。Radius 则引入了包含环境、资源组和连接的应用程序结构，由此生成的应用程序图能够准确展示各应用程序及其基础设施的互连方式，帮助运维团队和开发团队通过视图直观了解应用程序的组成方式。此外，Radius 还与 Terraform 等流行基础设施工具及 GitHub Actions 等现有 CI/CD 系统相集成，带来无缝化的运维操作体验。

Kubernetes 太复杂，开发者怎么看？

Kubernetes 的复杂性问题一直饱受诟病，也成了很多企业部署路上的“绊脚石”。

2019 年，知名软件开发服务商 Atlassian 在尝试部署 Kubernetes 三年后公开表示：“过去三年，部署 Kubernetes 的过程非常艰难，并且不推荐大家尝试”。Google Kubernetes Engine（GKE）产品负责人 Drew Bradstock 也曾在一次公开声明中承认，“尽管我们过去几年看到越来越多的企业开始拥抱 Kubernetes，但是随后就陷入了困境。”

Kubernetes 的创建者之一，Heptio（VMware）的 Joe Beda 曾在 Twitter 上表示：“Kubernetes 是一个复杂的系统，它做并带来了很多新的抽象，但这并不适合所有问题。我确定，很多人通过更简单的工具实现 Kubernetes 的功能。”Beda 强调，相比于学习的复杂性，工程师往往更擅长削减构建复杂性。当工程师决定使用 Jenkins、Bash、Puppet、Terraform 等创建系统时，最终会得到一个独特的复杂系统，工程师本人会感到很舒适，这可能解决了某些问题。但对新人而言，试图了解这些系统太过复杂。但是，这种复杂性与某些特定系统中的复杂性还不同，Kubernetes 是存在行业标准的，基本只要学习一次就可以在各处应用。

在开发者群体中，关于 Kubernetes 是否太过复杂也分成了不同的阵营，有开发者直言自己花了一年的时间才把 Kubernetes 真正搞明白，时间成本非常高；也有开发者认为，Kubernetes 是否复杂取决于你想解决什么任务。开发者 Maruf Hossain 认为，“对于一些简单的任务，Kubernetes 可以说是最简单的解决方案了。当然，对于某些关键任务，Kubernetes 也确实表现得非常复杂繁琐。”

敏捷团队技术主管 Etienne Dilocker 也有相似的观点：“Kubernetes 到底是简单还是复杂，要取决于大家的实际设置流程。Kubernetes 用起来跟注册云服务一样简单，特别是谷歌、亚马逊云科技或者 Azure。三大云巨头都提供一次单击即可创建集群的功能。在拥有了自己的集群之后，大家可以使用简单的 kubectl run mydeployment —image=myimage 命令来部署容器。

真正的复杂性，来自不同的实际业务流程。当然，动态创建集群并以不可重现的方式通过本地计算机进行部署还远远不够。大家可能需要编写集群创建脚本（这属于基础设施即代码的典型应用），这往往要用到 Terraform 之类工具。当然，应用程序的部署过程也应该可重复，这就要求我们创建一条 CI 管线（使用 Jenkins、Travis、Circle CI、Google Cloud Build 之类的都行）。但是，我们并不需要担心更新过程：因为我们选择了 Kubernetes，它能帮我们轻松搞定滚动更新。也就是说，我们现在只需要把显式创建资源（比如部署）中的 kubectl run 用 kubectl apply 替换掉即可。如此一来，大家就能以幂等的方式来部署应用程序。您的应用程序中涉及依赖项吗？不用担心，把它们跟应用程序一起部署即可，Kubernetes 甚至还免费提供服务发现功能。

如果应用程序需要接受外部访问，那可能还得创建 Ingress 资源。需要往管线中添加 yaml，而相关资源管理工作交给 Helm（Kubernetes 的包管理器）之类工具就行。当然，所有这一切都要求应用程序能够在云端运行，所以它应当兼容十二大因素。但还是那句话，这些复杂性并不是 Kubernetes 所特有的，在云端运行弹性应用程序就是会带来这样的复杂性成本。

总而言之，复杂性确实存在，但很多时候跟 Kubernetes 本身关系不大。复杂性的真正来源，是在云环境中以可靠、可重复的方式运行应用程序这个基本要求。相信我，在 Kubernetes 诞生之前，这一切还可以更加复杂。”

参考链接：

https://cloudblogs.microsoft.com/opensource/2023/10/18/enabling-developer-collaboration-with-radius/

https://cloudplane.org/blog/why-kubernetes-is-so-complex

https://home.robusta.dev/blog/kubernetes-is-complex-because-you-want-complex-things

https://www.quora.com/Why-is-Kubernetes-too-complicated