技术专家李翔和张磊将解释OAM是什么，以及阿里巴巴的标准化集成应用管理架构如何使用来升级。

OAM 是什么意思？

2019年10月，阿里巴巴与微软共同宣布推出OAM（开放应用模型）。这一关键技术是在阿里巴巴的统一应用程序管理架构升级过程中逐渐演进而来。

OAM是用于定义和描述云原生应用和其运维功能的标准化开源规范。因此，OAM不仅是定义Kubernetes应用的标准项目（与非活动的Kubernetes应用的自定义资源定义（CRD）项目相比），还将各种O&M Kubernetes能力封装、整理和管理，是连接O&M能力和应用于平台层的项目。通过核心功能的应用定义和应用的O&M功能整理和管理，OAM项目成为阿里巴巴升级集成应用管理架构、构建下一代PaaS和无服务器架构的最佳选择。

此外，OAM不会实现应用程序或能力。相反，它们是通过Kubernetes提供的API原语和控制器来实现的。因此，OAM成为阿里巴巴构建Kubernetes原生PaaS架构的主要方法。

在OAM中，应用程序包括三个核心概念。

1、微服务、数据库、服务器负载均衡器（SLB）等是构成应用程序的组件。
2、自动扩展功能和入口功能等是应用程序的运维特性。这些特性在不同环境中的实现形式有所不同。
3、运维人员使用应用程序配置，将组件与相应特性结合，并将这些特性转化为特定应用程序后，才会创建和部署应用程序实例。

阿里巴巴在互联网场景中，提供了大量关于Kubernetes集群和阿里巴巴云产品管理的经验给OAM，在阿里巴巴将无数的内部应用CRD转移到基于OAM的标准应用定义过程中，特别是在这个过程中获得的。作为工程师，我们从失败和错误中学习，并持续进行创新和开发。

为了让更多的用户了解OAM，本文将详细解释有关OAM动机的内容。

背景

关于我们

我们是阿里巴巴的基础设施运维商，也被称为Kubernetes团队。我们负责大规模Kubernetes集群的维护，控制器和运维工具的实施，以及各种Kubernetes插件的开发等，涉及Kubernetes在不同层面的功能开发、安装和维护。在阿里巴巴，我们被称为平台构建者。

为了区分负责Kubernetes的PaaS工程师，本文将其称为基础设施运营者。在过去几年中，我们通过Kubernetes取得了巨大的成功，同时也得到了宝贵的教训。

2、各种Kubernetes集群的管理

为了支持阿里巴巴的电子商务业务，我们在管理全球最大、最复杂的Kubernetes集群。
这些集群仅用于支持阿里巴巴的电子商务业务。

• 10,000ノードまでスケールアップ可能。

 

• 10,000以上のアプリケーションをホストすることが可能。

 

ピーク時には毎日10万個のアプリケーションのデプロイメントを処理。

同时，阿里巴巴云原生容器服务（ACK）也得到支持。该服务能够承载大约1万个中小规模集群，并为外部客户提供与阿里巴巴云原生Kubernetes产品相同的服务。我们的内外部客户对于工作负载管理有着各种多样的需求和使用案例。

向研究开发人员提供服务的应用程序运营商提供服务。

阿里巴巴的技术堆栈是与其他互联网企业一样，基础设施提供商、应用程序提供商和业务开发人员共同实现的。业务开发人员和应用程序运营商的角色如下所示。

商务开发者

商务开发者通过代码提供商业价值。大部分商务开发者并不精通基础设施和Kubernetes，而是通过PaaS和CI流水线来管理应用程序。商务开发者的生产力对阿里巴巴来说具有重要价值。

应用程序操作员

应用程序操作员向业务开发人员提供有关集群容量、稳定性和性能方面的专业知识，并支持大规模应用程序的配置、部署和执行（包括应用程序的更新、扩展和恢复等）。应用程序操作员对Kubernetes的API和功能有一定的了解，但不直接操作Kubernetes。在很多情况下，应用程序操作员使用PaaS为业务开发人员提供Kubernetes的基本功能，因此他们中的许多人是PaaS工程师。

概括来说，基础设施运营商向商业开发者提供服务，并将其服务提供给应用程序运营商。

協同合作的問題

正如前面所述，这三方各自拥有不同的专业知识，但为了实现顺畅合作，Kubernetes需要进行复杂的协调。

在下面，我将解释这些相关方的痛点。总而言之，根本问题在于它们之间缺乏高效准确的互动标准。这导致了低效的应用管理过程和最终操作的失败。OAM是解决这个问题的关键。

基础设施运营商与应用服务提供商之间的互动。

Kubernetes具有高度可扩展性，基础设施提供商可以根据自己的意愿构建运维功能。然而，Kubernetes的灵活性也可能给这些功能的使用者（应用程序运营者）带来问题。

我們開發了一個基於CRON格式的Cron Horizontal Pod Autoscaler（CronHPA）Custom Resource Definition（CRD）來擴展應用程序。這對於需要在白天和晚上使用不同的擴展策略時非常有用。CronHPA是一個可選功能，僅在需要時才可以在集群中引入。以下是CronHPA的YAML文件樣本。

apiVersion: "app.alibaba.com/v1"
kind: CronHPA
metadata:
  name: cron-scaler
spec:
  timezone: America/Los_Angeles
  schedule:
  - cron: '0 0 6 * * ?'
    minReplicas: 20
    maxReplicas: 25
  - cron: '0 0 19 * * ?'
    minReplicas: 1
    maxReplicas: 9
  template:
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        name: php-apache
      metrics:
      - type: Resource
        resource:
          name: cpu
          target:
            type: Utilization
            averageUtilization: 50

这是一个典型的Kubernetes自定义资源定义（CRD），可以直接安装和使用。但是，在为应用程序操作员提供这些功能后，当应用程序操作员使用像CronHPA CRD这样的CRD时，问题就会立即出现。

1、Kubernetes CRD 的使用方法错误

应用程序操作员经常听到关于spec的抱怨声。spec可能会出现在CRD中，也可能会出现在ConfigMap中，或者以随机路径出现在配置文件中。此外，Kubernetes的许多插件如CNI和CSI（容器存储接口）插件的CRD仅仅是它们的安装步骤，并不能对应相应功能，如网络功能或存储功能，这让应用程序操作员感到困惑。

判断一个 Kubernetes 集群是否具备特定功能是困难的。

应用程序操作员通常对于操作与维护功能是否集成在群集中，并特别由新开发的插件提供时，不够了解。基础设施专员和应用程序专员需要进行多次沟通，以明确问题。另外，在管理方面也存在一些挑战。

有时 O&M 功能之间的冲突很难处理。

在Kubernetes集群中，可以将O＆M功能之间的关系分为以下类型。

• Orthogonal:能力は互いに独立しています。例えば、トラフィック管理にはingressを、ストレージ管理にはpersistent storageを使用します。

 

• Combinable:複数の機能を同じアプリケーションに協調して適用できます。例えば、アプリケーションのアップグレードにはrolloutを、プログレッシブトラフィックスイッチングにはcontrol ingressを使用します。

 

Conflicting:複数の機能を同じアプリケーションに適用することはできません。例えば、Horizontal Pod Autoscaler（HPA）とCronHPAは、同じアプリケーションに適用すると競合します。

直线能够灵活组合的能力具有高安全性，而相反的能力可能会导致意料之外或不可预测的操作。

Kubernetes无法提前发出冲突警告，应用操作员有可能在相同应用中使用两个冲突的O&M功能。一旦发生冲突，解决它所需的成本将会增加。在极端情况下，这些冲突可能导致灾难。

在抗争中，应用操作员将如何确定和管理可能相互竞争的运维功能？基础设施提供商是否能够构建有利于应用提供商的运维功能？

在OAM中的O&M特性

在OAM中，使用O&M特性来描述和构建平台层的可发现和可管理能力。这些平台层的能力基本上是应用程序的O&M特性。

1、建立可发现的O&M功能。

在ACK中，大多数特性由基础设施运营者定义，并通过使用Kubernetes的自定义控制器进行实现。例如，包括以下内容。

• Ingress

 

• Autoscaler

 

• Volume-mounter

 

Traffic-shifting and Security-policy

Traits并不等同于Kubernetes的插件。例如，集群可能有多个网络相关特性，如动态QoS（服务质量）、带宽控制和流量镜像等。所有这些特性都可以由一个CNI插件提供。

traits被安装在Kubernetes集群中，供应用操作者使用。当被展示为traits时，应用操作者可以通过执行kubectl get命令，发现集群支持的运维功能。

$ kubectl get traitDefinition
NAME                AGE
cron-scaler         19m
auto-scaler         19m

在前面的例子中，展示了集群支持cron-scaler和autoscaler的功能。用户可以将需要基于CRON的扩展策略的应用程序部署到集群中。

trait通过提供特定O&M能力的结构化说明，使得应用操作人员可以通过运行kubectl describe命令来轻松准确地理解特定能力。trait的说明包括工作负载和使用方法。

例如，您可以运行kubectl describe命令来查询TraitDefinition类型的cron-scaler能力。

apiVersion: core.oam.dev/v1alpha2
kind: TraitDefinition
metadata:
  name: cron-scaler
spec:
  appliesTo:
    - core.oam.dev/v1alpha1.ContainerizedWorkload
  definitionRef:
    name: cronhpas.app.alibaba.com

在OAM中，我们使用CRD来描述在DefinitionRef中使用trait的方法，并且它与Kubernetes的CRD是独立的。

trait 的规范与其实现是分离的。trait 的规范可以基于不同的技术，在不同的平台和环境中进行实现。实现层可以连接到已存在的CRD、具有统一描述的中间层，或者不同的底层实现。像Kubernetes的ingress这样的特定功能可能有多个实现方式，因此规范与实现的分离非常有用。trait 提供了统一的描述，以确保应用程序操作员可以准确理解和使用。

2、建立可管理的 O&M 能力。

应用程序操作员可以使用ApplicationConfiguration来设置安装在应用程序中的一个或多个特性。ApplicationConfiguration控制器将处理特性的冲突。以下是ApplicationConfiguration的示例。

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: failed-example
spec:
  components:
    - name: nginx-replicated-v1
      traits:
        - trait:
            apiVersion: core.oam.dev/v1alpha2
            kind: AutoScaler
            spec:            
              minimum: 1
              maximum: 9
        - trait:
            apiVersion: app.alibabacloud.com/v1
            kind: CronHPA
            spec:            
              timezone: "America/Los_Angeles"
              schedule: "0 0 6 * * ?"
              cpu: 50
              ...

在OAM中，ApplicationConfiguration控制器需要确保这些特性之间的兼容性。如果失败，应用程序部署将立即失败。因此，当应用程序操作员将YAML文件提交给Kubernetes时，OAM控制器将报告由trait冲突引起的部署失败。通过这种方式，应用程序操作员可以预见到O&M能力的冲突。

一般而言，我们的Kubernetes团队更喜欢使用OAM trait来提供基于Kubernetes的可发现且可管理的O&M能力，而不是使用冗长的维护规范和O&M指南来防止应用程序操作员的错误。通过这样做，应用程序运营者可以结合O&M功能，构建一个无冲突的应用程序O&M解决方案。

应用程序操作员与业务开发人员之间的互动

Kubernetes的API对应用程序操作员和业务开发人员都是公开的。换句话说，每个人都可以负责Kubernetes API的任何字段。这样的API被称为全能API，对初学者也非常友好。

当多个具有不同关注点的团队需要在同一个Kubernetes集群中进行协同工作时，尤其是当应用操作员和业务开发人员需要在同一个API上进行协同工作时，这种API的缺点就变得明显。以下是一个简单的YAML文件示例，用于部署。

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      deploy: example
  template:
    metadata:
      labels:
        deploy: example
    spec:
      containers:
        - name: nginx
          image: nginx:1.7.9
          securityContext:
            allowPrivilegeEscalation: false

在集群中，应用操作员和业务开发人员在完成YAML文件之前需要进行脱机会议。但为什么他们需要进行这样耗时复杂的合作呢？

领域不相关 bù

在这种情况下，对于业务开发人员来说，完成部署所需的YAML文件是最简单的方法。但是，您可能会意识到部署字段中存在与自己无关的内容。例如，让我们考虑以下问题。

有多少个商业开发者了解 allowPrivilegeEscalation 字段？

几乎没有人了解这个领域。在生产环境中，为了确保应用程序在主机内具有适当的权限，需要将该字段设置为false（默认值为true）。实际上，只有应用程序操作员才能设置该字段。业务开发人员可以猜测这种字段的含义，或者只能忽略这些字段。

在应用操作员和业务开发人员中，哪个负责领域呢？

可能有些了解Kubernetes的人可能会意识到确定填补Kubernetes领域的参与者是件困难的事。

比如说，假设一个业务开发人员在部署用的YAML文件中将副本数设置为3，那么我们假设该值在应用程序的整个生命周期中保持不变。

然而，大多数企业的研发人员并不知道Kubernetes的HPA控制器能够接管replicas字段，并根据Pod的负载情况进行值的更改。由系统自动进行的更改会引发以下问题：即使业务开发人员试图更改replicas的值，新值也不会生效。

在这种情况下，Kubernetes的YAML文件无法指定最终工作负载，这可能会让业务开发人员感到困惑。因此，我们尝试使用fieldManager来解决这个问题。由于无法理解为何需要进行更改，这将成为一项困难的工作。

在应用操作员和业务开发人员的分离下，问题是否能够解决？

如果使用Kubernetes的API，业务开发人员和应用程序操作员的关注点必然会混在一起。因此，多个参与者无法基于相同的API进行协同工作。

另外，我们还发现，阿里巴巴的PaaS等应用管理系统并没有全部公开Kubernetes的功能。也就是说，对于商务开发者来说，并没有公开太多关于Kubernetes的概念。

最简单的解决方案是在业务开发者和应用运营者之间设立界限。例如，可以让仅业务开发者能够设置部署所需的YAML文件的特定字段。这在阿里巴巴的许多PaaS平台上已经采用。然而，这种方法也可能不适用。

需要业务开发者向应用程序运营者提出建议。

在许多情况下，业务开发人员希望应用程序运营商接受他们关于运营和维护的意见。例如，业务开发人员定义了10个应用程序参数，但应用程序运营商可能会覆盖这些参数以适应不同的执行环境。那么，业务开发人员是否可以允许应用程序运营商只更改其中5个特定的参数？

在业务开发者和应用程序运营者分开的情况下，在应用程序管理过程中传达业务开发者的O&M意见非常困难。通常情况下，业务开发者希望向他们的应用程序传达大量的信息。

• スケールアウトできない（つまり、1つのインスタンスしか認められない）

 

• 長時間稼働するサービスではなく、バッチジョブであること

 

最高のセキュリティレベルを要求する

由于业务开发人员对应用程序最了解，所以上述要求都是合理的。在这种情况下，阿里巴巴Kubernetes需要为业务开发人员和应用程序运营者分别提供API，业务开发人员是否能有效传达运维需求成为了一个问题。

在OAM中的组件和应用程序设置。

在OAM中，我们将Kubernetes的API进行了逻辑分割，使业务开发人员可以根据领域对应用程序运营者提出要求。这不仅包括定义应用程序，还包括描述它们。

1、组件

在OAM中，组件是为了让业务开发者能够定义应用程序而设计的载体，而无需考虑O&M的详细信息。一个应用程序可以包含一个或多个组件。例如，Web应用程序由Java Web组件和数据库组件组成。下图是一个示例，显示了业务开发者定义的组件，以引入NGINX。

在OAM中，组件由以下部分组成。

• ワークロードの記述:コンポーネントの実行方法とコンテンツは、完全なKubernetesカスタムリソースを構成します。（CR.）

 

書き換え可能なパラメータリスト:ビジネスデベロッパーは、アプリケーションオペレータやシステムがオーバーライド可能なフィールドをこのパラメータリストで指定します。

在组件中，工作负载字段向应用操作员传递业务开发人员如何运行应用程序的信息。同时，OAM定义了ContainerizedWorkload用于容器化应用程序，并涵盖了典型的云原生应用模式。

通过使用OAM定义和扩展工作负载，可以声明用户的工作负载类型。我们始终在扩展工作负载方面努力，并使业务开发人员能够定义阿里巴巴云服务组件，例如函数计算。

在前面的例子中，业务开发者不需要设置副本。相反，HPA或应用程序的操作器将允许控制副本的值。通常情况下，使用组件使得业务开发者能够以自己的方式定义应用程序的声明性描述。此外，使用该组件，业务开发者可以随时准确地向应用程序运维人员传达意见和信息。该信息包括哪些参数是可重写的、如何运行应用程序等O&M需求。

2、应用程序配置

使用组件名称和应用程序绑定的特性，应用程序操作员可以使用ApplicationConfiguration实例化应用程序。以下是使用组件和ApplicationConfiguration的协同工作流示例。

• 様々なワークロードタイプがKubernetesにインストールされています。

 

• ビジネス開発者は、選択したワークロードタイプを使用してcomponent.yamlファイルを定義します。

 

• アプリケーションオペレータ（またはCIやCDシステム）は、kubectl apply -f component.yamlコマンドを実行してコンポーネントをインストールします。

 

• アプリケーションオペレータは、app-config.yamlコマンドを実行して、アプリケーションをインスタンス化するための- ApplicationConfigurationを定義します。

 

最後に、アプリケーションオペレーターは、kubectl apply -f app-config.yamlコマンドを実行して、アプリケーションのデプロイをトリガーします。

app-config.yaml文件的内容如下：

apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: my-awesome-app
spec:
  components:
    - componentName: nginx
      parameterValues:
        - name: connections
          value: 4096
      traits:
        - trait:
            apiVersion: core.oam.dev/v1alpha2
            kind: AutoScaler
            spec:            
              minimum: 1
              maximum: 9
        - trait:
            apiVersion: app.aliaba.com/v1
            kind: SecurityPolicy
            spec:           
                allowPrivilegeEscalation: false

以下展示了ApplicationConfiguration YAML文件中包含的主要字段。

• parameterValues:このフィールドは、アプリケーション・オペレータがコネクションの値を4096に更新するために使用します。このコンポーネントでは、connectionの初期値は1024です。このフィールドのスキーマはコンポーネント内で十分に定義されているため、アプリケーションオペレーターは「4096」という文字列の代わりに4096という整数を入力する必要があります。

 

• AutoScaler:このフィールドは、アプリケーションオペレータがHPAなどのオートスケーラートレインをコンポーネントにバインドするために使用します。そのため、レプリカの数はオートスケーラーによってのみ決定されます。

 

SecurityPolicy:このフィールドは、アプリケーション・オペレータがセキュリティ・ポリシーをコンポーネントに適用するために使用します。アプリケーションオペレーターは、トレイトリストを変更してより多くのトレイトをバインドすることもできます。例えば、Canary Deployment trait は、アプリケーションが後続のアップグレードにおいて段階的なリリース・ポリシーに従うことを示します。

ApplicationConfiguration的功能是使得应用操作员和系统能够理解和使用从业务开发人员传递的信息，并可以将O&M功能绑定到组件中，以用于最终的O&M。

超越应用程序管理的事物

总结起来，使用OAM可以解决应用程序管理中的以下问题。

• Kubernetesに発見可能、組み合わせ可能、管理可能なO&M機能を構築する。

 

• Kubernetesの複数の参加者が、単一のAPIを中心に正確かつ効果的にコラボレーションできるようにする。

 

そのため、OAMはAlibaba Kubernetesチームによって提案されたApplication CRD仕様となっています。これにより、すべての参加者が構造化された標準的な方法を使用して、アプリケーションとそのO&M機能を定義することができます。

此外，阿里巴巴正在开发 OAM，用于在混合云和多个环境中分发和交付软件。随着 Google Anthos 和微软 Arc 的推出，Kubernetes 正变得像新的 Android 系统，云原生生态系统的价值正在迅速转移到应用程序层面。本文介绍的案例由阿里巴巴云和蚂蚁金服的云原生团队提供。

OAM的未来

目前，OAM的规范和模型已经解决了许多问题，但这只是刚刚开始。例如，我们正在研究如何使用OAM来处理组件之间的依赖关系，以及将Dapr的工作负载与OAM整合的方法。

我們希望能與社群合作，來討論關於 OAM 規格和 Kubernetes 實現的相關事宜。OAM 是一個中立的開源項目，所有貢獻者都需要遵守非營利基金會的貢獻者許可協議（CLA）。

如果你有任何问题或意见，请务必联系我们。

您可以点击以下的链接之一参加。

• Gitterで議論に参加する

 

• オープンソースのOAM実装のURLを見る

 

GitHubのこのページをクリック

关于作者

李翔是阿里巴巴云的资深技术专家。他负责阿里巴巴的集群管理系统，并支持阿里巴巴集团推广Kubernetes的采用。在加入阿里巴巴之前，他担任CoreOS上游Kubernetes团队的负责人。此外，他也是etcd和Kubernetes Operators的创始人。

张磊是阿里巴巴云的高级技术专家。他是Kubernetes项目的维护人之一。他所属于阿里巴巴Kubernetes团队，负责处理Kubernetes和云原生应用管理系统。

从2019年开始，阿里巴巴云的原生云应用平台团队基于阿里巴巴整体经济的标准应用定义和交付模型，开始升级应用管理产品和项目的统一架构。

2018年末，Kubernetes 正式成为阿里巴巴应用基础设施的一部分，这导致了阿里巴巴和阿里云产品范围内应用管理的碎片化问题的出现。

随着云原生生态系统的迅速发展，阿里巴巴的PaaS（平台即服务）产品，包括阿里巴巴云在内的应用程序管理产品架构，必须接受云原生生态系统，并利用生态系统中不断变化的功能来构建更强大的PaaS服务。

然而，仅仅将PaaS转移到或整合到Kubernetes上并不能解决问题。PaaS和Kubernetes之间一直没有明确的界限，而且Kubernetes并非为终端用户设计的。

为了解决使用Kubernetes和PaaS时面临的问题，阿里巴巴的研发和运维人员应该能够享受到云原生技术创新的好处，无缝移植或整合现有的PaaS系统到Kubernetes，并思考如何使新的PaaS系统能充分利用Kubernetes技术和生态系统的功能和价值。

本部落格是从英语版翻译而来的。您可以在此查看原始内容。我们使用了部分机器翻译。如果有翻译错误，请您指正，不胜感激。

阿里巴巴云拥有两个数据中心，拥有超过60个可用区域，是亚太地区最佳的云基础设施服务提供商（2019年Gartner报告）。
请点击这里查看阿里巴巴云的详细信息。
阿里巴巴云日本官方网页。