【无标题】

Kubernetes声明性API和补充开发工具（如Dapr）正在流行并成为主流的新领域。

Kubernetes是保持用不同语言编写和来自不同业务领域的应用程序所需状态的事实标准。Kubernetes的采用还远远没有结束，它的飞轮效应正在加速并扩展到新的领域。

Kubernetes正在转变为统一的声明性API和协调机制，不仅用于管理集群内应用程序，还用于管理集群外远程资源和多云部署。Dapr项目受到Kubernetes的启发，并基于相同的云原生原则，即多平台、异构应用程序和多云，通过提高开发人员的生产力（就像Kubernete提高运维团队的生产力一样），对Kubernets进行了补充。

在本文中，我们将探讨Kubernetes 声明性API和补充开发工具（如Dapr）正在流行并成为主流的新领域。

容器管理API

微服务部署使Kubernetes成为今天的样子。Kubernetes引入了一系列API和保证（有些是显式的，有些是隐式的），这些API和保证在开发人员以高速创建分布式应用程序和运维团队保持这些应用程序高规模运行的过程中充当了共同的公理。

这些公理是推理应用程序如何在任何基础设施上部署和运行并保持在所需状态的前提。这份合同是由什么组成的？它是应用程序和平台相关生命周期API和保证的组合，例如：

——具有资源约束的基于容器的应用程序打包

——运行状况检查和应用程序生命周期策略

——为无状态、有状态或基于作业的工作负载轻松扩展应用程序

——用于故障保存上线和回滚的声明性部署策略

——基于策略和依赖关系的自动应用程序放置等。

本质上，Kubernetes通过在应用程序和底层基础设施之间提供标准接口，隐藏基础设施的形状，并使其不可靠性对应用程序无关紧要，从而加快了分布式应用程序架构的采用。

Kubernetes API作为基础设施抽象

虽然这增强了运维团队大规模管理高度分布式应用程序的能力，但它并没有为创建此类应用程序的开发人员带来相同的收益。事实上，分布式架构增加了开发人员必须处理的偶然复杂性，而不是专注于实现应用程序业务逻辑。Kubernetes本身并没有提供一个统一的声明性API和一个可以隐藏网络复杂性和谬误的可移植实现。这是留给开发人员解决和其他项目完成的领域。

我们在本节中描述的内容并不新鲜，但它帮助我们了解Kubernetes API在何处传播以及在何处落后。

第三方服务管理API

Kubernetes API为管理任何公共或私有云上的计算、网络和存储提供了标准接口。但云计算不仅仅是原始基础设施，如今大型云提供商和小型专业SaaS提供商提供更高级别的服务，如数据库、缓存、关键值存储、文件桶、消息队列、流处理器等。

这些特定于供应商的服务托管在远程云网络上，并通过专用API访问。这是一个很有吸引力的产品，因为这样的服务可以快速调配、轻松扩展和即时更新。这种模式减少了安装和配置所花费的时间，与传统模式相比，它的租赁多租户性质提供了更低的成本。这些优势使第三方服务成为运行在Kubernetes上的许多应用程序的强制依赖。

使用第三方服务的一个挑战是，这些服务的生命周期管理因供应商而异。不同的云供应商有不同的控制平面API来提供和管理其服务。即使你正在提供相同类型和完全相同的软件（例如PostgreSQL服务器版本X），AWS和GCP、Azure等之间的API和语义也会有所不同。

不仅如此，这些服务的供应、管理、访问和持续管理将与Kubernetes上管理应用程序的方式有很大不同，这导致工具、实践和工作更加复杂和重复。

如果来自不同底层提供商的这些更高级别的服务可以通过相同的Kubernetes API交付，并为运行在Kubernete本身上的容器提供相同级别的一致性，会怎么样？如果可以使用相同的Kubernetes声明性方法和控制循环机制来实现呢？这将允许重用Kubernetes语义、API、工具和管理外部资源的实践，就像它们是Kubernete上的容器一样。这正是我们眼前正在发生的事情，比如：AWS Controllers for Kubernetes、Azure Service Operator、Google Config Connector、Crossplane。

这些项目使用Kubernetes自定义资源定义（CRD）作为一种新兴的统一标准，用于描述云服务和这些服务治理的协调模式。这允许运维人员与运行在Kubernetes上的应用程序一致地管理所有外部资源，并使用Kubernete资源公开服务端点和秘密。

 Kubernetes API作为多集群抽象

虽然这种方法使运维团队能够从丰富的Kubernetes工具和实践生态系统中受益，但它并不能为必须使用这些服务的开发人员提供相同的好处。开发人员仍然必须使用具有不同质量和语言语义的库和框架来与无数的第三方服务交互。当第三方库发生变化时，开发人员要自行修补和升级应用程序。

在与来自不同提供商的类似第三方服务交互时，由技术领导追求一致性、重用和最佳实践。这里列出的项目将帮助运维团队管理这些外部服务，而不是必须使用这些服务的开发人员——并不是很好的云原生开发者体验。

多集群管理API

拥有多个云部署（无论是公共云还是私有云）在企业中越来越普遍。这有时是故意的，因为需要仅在选定的云提供商、规模或隔离需求上提供特定的云服务，或者由于收购或影子IT而导致的意外。不管是什么原因，今天，多云复杂性是许多组织不得不面对的丑陋现实。

与多云类似，运行多个Kubernetes集群也不容易。多集群Kubernetes架构的一个主要驱动因素是需要工作负载隔离。同一组织内的团队可能需要空间来试验CRD和operator。

Kubernetes基于命名空间的隔离机制在这些场景中是不够的，特别是随着CRD和operator的普及，CRD和operator是集群范围内的实体，需要集群级访问。所有这些都是配置新的Kubernetes集群的原因，运维团队开始发现处理多个Kubernete集群是个挑战。

有许多新兴项目使用Kubernetes API来管理多个其他Kubernete集群和应用程序工作负载。一些较为知名的项目和管理服务包括：Azure Arc、Anthos、Red Hat Advanced Cluster Management、Hypershift、KCP。

这些项目在它们可以管理的受支持的集群类型以及可以使用它们做什么方面有所不同。但通常，它们为管理多个Kubernetes集群提供端到端的可见性和控制。这通常包括部署跨数据中心、边缘和多云环境的应用程序、确保安全性和合规性。

用于第三方服务编排的Kubernetes API

这使得运维可以从一个窗格中管理多个Kubernetes集群，就好像它们是一个Kubernet集群一样。这意味着同一应用程序不仅可以部署到同一Kubernetes集群内的多个区域，还可以部署到不同地区甚至不同云提供商上的多个Kubernete集群。这可以由应用程序的全局部署需求、迁移和现代化原因或时间关键型灾难恢复过程驱动。

然而，要实现这一点，仅靠Kubernetes是不够的。应用程序本身也必须在编写时考虑到多云。如果应用程序是用一个云提供商的客户端库实现和打包的，那么在另一个云供应商上运行它可能会限制其可移植性。

如果你已经将业务逻辑与云服务的低级功能相结合，那么在另一个云上运行应用程序之前，可能需要进行大量的重写。本质上，要创建可移植的多云和多集群应用程序，并在云中重用工具、实践和模式，你也需要在开发时应用相同的云原生运维原则。也就是说，使用云原生工具和自动化来抽象任何语言和第三方应用程序依赖关系和工具。

中间的空白

上述基于Kubernetes的API趋势带来了运维工具和实践的一致性和重用，从而提高了运维团队的效率。但它们并没有在同一层面上满足开发人员的需求。例如：

——Kubernetes帮助运维团队保持大量容器的运行，但它不能帮助开发人员使用他们选择的语言和框架实现可靠的服务交互。

——Kubernetes有助于运维统一提供和管理第三方资源，但它不能帮助开发人员使用不同语言的无数不同库以统一的方式使用这些第三方服务。

——Kubernetes帮助在多个集群中部署容器，但它无助于创建独立于云服务语义和集成模式的可移植多云应用程序。

应用程序的业务逻辑和其他系统之间有一个空白空间，留给开发人员来填充。它通常充满了只有少数编程语言或嵌入应用程序的框架才能使用的云前原生技术。

将这种专注于单一语言或单一云的云前原生技术与基于语言和云可移植性、声明性API、可插拔性和重用原则的类似Kubernetes的技术相结合，会导致技术阻抗不匹配和不必要的开发工作。

与运维团队从Kubernetes中受益的方式类似，我们需要声明性功能、可重用模式和可移植实现，以帮助开发人员以云原生方式创建分布式应用程序。

Dapr项目受容器的可移植性和声明性Kubernetes API的影响。它为应用程序创建者提供了可移植、多语言、API驱动的分布式系统原语，如第三方服务连接器、可移植弹性策略和多语言可观察性功能。

 

Dapr API帮助实现分布式应用程序，Kubernetes API帮助运维它们

Dapr允许开发人员专注于编写业务逻辑而不是解决分布式系统挑战，从而使开发人员更容易构建弹性、无状态和有状态的分布式应用程序。它提高了开发人员的生产力，就像Kubernetes提高了运维团队的生产力一样。

Dapr用于创建应用程序，就像Kubernetes用于运维应用程序一样。它的灵感来自Kubernetes，但其使命是填补Kubernete留下的空白。

随着软件堆栈越来越深，变化的速度越来越快，大代码时代已经来临。我们需要新的范式、模式和工具来帮助运维和开发团队掌握这种日益增加的复杂性。

Kubernetes的声明性API和控制循环机制在推理和管理分布式系统（无论是在集群上、集群外还是多个集群）方面引发了新的思考浪潮和变革浪潮。在这段旅程中，Kubernetes飞轮已经超越了容器。Kubernetes不再是容器编排器，而是一个全局资源管理API，无论这些资源是本地容器、远程集群还是其他第三方服务。