指导Kubernetes走向以应用程序为中心的未来

Kubernetes是云计算的突破成功案例。 在短短几年内，它已经从无到有发展成一个超级应用程序开发者，这种快速增长使开发人员寻求构建和管理Kubernetes托管应用程序的更好方法。

有很多解决方法和扩展。 Helm等工具使将资源轻松部署到集群变得容易，而CNAB（云原生应用程序捆绑包）则打包了应用程序及其所有依赖项以供部署。 在较低级别，诸如草稿之类的服务可帮助设计和构建基本服务。 您可以使用熟悉的容器构建代码并将其部署，然后可以将元素快速组装到Kubernetes应用程序中。 您甚至可以使用Azure Kubernetes Services自动化管理。

[发现InfoWorld的2019年Bossie奖获得者： 适用于软件开发，云计算，数据分析和机器学习的最佳开源软件 。 ]

对于来自服务基础架构背景的工具（Google在Borg上的工作）来说，Kubernetes及其周围的工具从根本上专注于运营可能并不奇怪。 分布式系统操作长期以来一直是一个问题，从Borg和Mesos到Docker Swarm和Kubernetes的整个数据中心OS运动都比devop的运维更多。

我们如何超越这种方法，将开发人员放回Kubernetes？ 我们已经完成了构建生态系统的大量工作，整理了基于微服务原理构建分布式应用程序所需的模式和实践。 现在是时候将所有内容放在一起并交付缺少的那部分了，这对开发人员来说是必不可少的：一种以应用程序为中心的Kubernetes观察方式。

引入开放式应用程序模型OAM

微软和阿里云最近宣布了开放应用程序模型 ， 该模型专注于构建和管理基于微服务的应用程序，同时了解角色和组成现代分布式应用程序的不同层之间的界限 。 尽管OAM清楚每个基于Kubernetes的环境都是不同的，但是仍然存在一些共性点，可以将应用程序与基础架构的支持服务区分开来，而不会脱离devops文化的好处。

开放应用程序模型首先定义参与构建和运行现代应用程序的团队的角色和职责。 它取代了开发人员和运营商之间的传统区别，它采用了更为精细的方法，并引入了应用程序运营商和基础架构运营商角色的概念。 这是一个有意义的模型。 从本质上讲，诸如Kubernetes之类的工具及其周围的平台服务是对底层数据中心和核心应用程序的抽象。

借助OAM，我们拥有应用程序运营商，他们可以管理和部署开发团队提供的微服务。 他们是管理和部署Pod和容器的团队，使用监视和可观察性工具确保应用程序的可靠性和可伸缩性。 他们也是使用服务网格组件来定义应用程序网络及其行为的团队，并使用声明性工具来构建服务策略。

基础架构运营商类似于传统的ops角色，尽管现在的责任仅限于基础架构服务，例如Kubernetes本身，或由服务网格策略管理的软件定义的网络。 他们不需要了解正在运行的应用程序，他们要做的就是确保他们提供的所有服务均可用并且其API正在运行。 这并不是要淡化角色的重要性，因为现代系统操作的日益复杂性要求服务级别的专家和专家：例如，管理和部署多租户数据库需要大量的知识和技能。

在OAM中定义应用程序

OAM的核心是应用程序的概念。 这将应用程序与部署方式以及与基础架构的集成方式分开。 这是一种理解方式，我将以与您的操作方式不同的方式部署和管理应用程序，并且Azure与其配合使用的方式与AWS的方式不同。

应用程序由组件组成 ，这些组件可以或可以不包括在任何部署程序包中。 应用程序组件可以是托管数据库服务，一组网络规则或一组消息端点。 这些内容的实现方式取决于基础平台，但是只有在适当的位置才能部署应用程序。 在清单中描述了应用程序各个组件之间的关系，这些清单随后可用于将应用程序微服务构建到可部署模块中。

这是打包应用程序的工具如CNAB所使用的步骤之外的一步。 在这里，您无需交付软件包，而是使用可用的平台资源交付组装到应用程序特定于站点或服务的版本中的组件 。 结果是一种非常不同的应用程序打包方法，它需要应用程序操作员更多的工作，而基础架构操作员却需要更少的工作。

使用特性处理基础架构

通过将应用程序包与平台分离，结果应该是一种更加不可知的方法开发方法，该方法可以处理标准化公共云之间的差异，其中无论您在哪里安装应用程序，所有组件和资源都相同，并且自定义本地私有云可以将现成的硬件与GCP的Anthos等工具混合使用。 关键是OAM的特质概念 。

特性用于描述应用程序环境应如何工作，以机器和人类可读的方式描述缩放和其他关键的分布式计算概念。 特性有一个名称和一组属性。 例如，自动缩放特征将定义允许的副本的最小和最大数量，然后可以将其转换为适用于Kubernetes安装的YAML，或转换为服务网格或KEDA（基于Kubernetes的事件-驱动自动缩放）。

最终，如果OAM取得成功，则应使用网络和安全工具以及我们在云中使用的其余基础架构自动化功能直接支持特征和特征定义。 目的是，特质和其他OAM应用程序概念应该与供应商无关，无论应用程序在谁的基础结构上运行，都可以安装和运行它们。 该方法对于边缘部署，代码在客户端附近运行，可用设备可能依赖于诸如Cloudflare之类的内容交付网络或依赖于AT＆T之类的城域电信运营商的边缘部署而言，应该是行之有效的。

Rudr：面向Kubernetes的OAM的参考实现

诸如OAM之类的规范需要参考实现， 并且Microsoft已发布Rudr （一种与Kubernetes一起使用的实现）。 Rudr使用自定义资源定义将您的OAM定义转换为Kubernetes组件和服务。 有趣的是，它是用Rust编写的，利用其内存安全功能来降低应用程序的风险。 您可以使用其发布的方法来创建一个承载简单Python应用程序容器的基本组件。

Rudr仍然是非常多的Alpha代码，因为它正在跟踪本身在快速变化的规范。 但是，它确实使您了解如何在私有云上管理OAM应用程序，以及诸如Azure之类的服务将如何在其规模更大的基础结构上实现它。

From: https://www.infoworld.com/article/3447556/steering-kubernetes-to-an-application-centric-future.html