OAM v1alpha2 New: standard balancing and scalability

Author | Sun Jianbo (Tianyuan) Ali cloud technology experts

Introduction : OAM Spec after almost three months of iterations, v1alpha2  version finally released it! On the basis of the new version of platform-independent OAM Spec insist on the whole become more Kubernetes-friendly technology, to a large extent balance the standards and scalability, better support CRD. If you have written off the shelf CRD Operator, you can smooth access to the OAM system, and enjoy the dividends of OAM model.

Currently OAM has become the core architecture, including Ali, Microsoft, Upbond, harmonic cloud and other companies to build cloud offerings. They constructed by the OAM "application-centric" user-friendliness of the Kubernetes PaaS; give full play to the standardization and scalability of OAM, the OAM core Controller at the same time, rapid access to the existing capacity of the Operator; open laterally through OAM multiple modules, get rid of the original Operator isolated from each other, we can not reuse the dilemma.

• To understand the background and origin of the OAM, refer to "the depth of interpretation! Lessons and practice "Ali unified application management infrastructure upgrades ;

• What value can bring OAM for end users? You can refer to the "OAM depth interpretation: OAM native applications for the cloud which bring value? "

Below Closer to home, let us look at v1alpha2 in the end do what changes?

The main changes explained

In order to facilitate reading, here only lists the most important changes to the point, some of the details or the upstream OAM Spec Github repository prevail.

Term Description

• CRD (Custom Resource Definition): In the OAM said the CRD is a custom resource description refers to the definition of. K8s implemented in the OAM may correspond exactly to the CRD of K8s, in the implementation of the non-K8s, OAM comprises the CRD need APIVersion / Kind and can verify the description field;

• CR (Custom Resource), OAM CR is an example of the CRD, a resource is described in line with the definition field format of CRD. K8S implemented in the OAM of the corresponding CR K8s completely in achieving non K8S, the alignment may be required APIVersion / Kind and field format definition.

The main changes to the use of 1 Reference model definitions Workload, Trait and Scope

v1alpha1 original way is this:

// 老版本，仅对比使用
apiVersion: core.oam.dev/v1alpha1
kind: WorkloadType
metadata:
  name: OpenFaaS
  annotations:
    version: v1.0.0
    description: "OpenFaaS a Workload which can serve workload running as functions"
spec:
  group: openfaas.com
  version: v1alpha2
  names:
    kind: Function
    singular: function
    plural: functions
  workloadSettings: |
    {
      "$schema": "http://json-schema.org/draft-07/schema#",
      "type": "object",
      "required": [
        "name", "image"
      ],
      "properties": {
        "name": {
          "type": "string",
          "description": "the name to the function"
        },
        "image": {
          "type": "string",
          "description": "the docker image of the function"
        }
      }
    }

In the original model, group / version / kind are field, spec check jsonschema represented by the overall format is actually the CRD is similar to, but not identical.

The new v1alpha2 thoroughly changed the reference model, through WorkloadDefinition  TraitDefinition  ScopeDefinitionthe form of a reference to describe the relationship. Can be a direct reference to a CRD, name is the name of the CRD. For OAM achieve non K8s of it, here is the name of an index, you can find similar CRD checksum file, check the file contains apiVersion and kind, and the corresponding schema validation.

• Workload

apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: containerisedworkload.core.oam.dev
spec:
  definitionRef:
    # Name of CRD. 
    name: containerisedworkload.core.oam.dev

• Trait

apiVersion: core.oam.dev/v1alpha2
kind: TraitDefinition
metadata:
  name: manualscalertrait.core.oam.dev
spec:
  appliesToWorkloads:
    - containerizedworkload.core.oam.dev
  definitionRef:
    name: manualscalertrait.core.oam.dev

• Scope

apiVersion: core.oam.dev/v1alpha2
kind: ScopeDefinition
metadata:
  name: networkscope.core.oam.dev
spec:
  allowComponentOverlap: true
  definitionRef:
    name: networkscope.core.oam.dev

note:

1. Here for OAM achieve K8s of it, name CRD is K8s inside the name, by the <plural-kind>.<group>composition. Best practice is a community of CRD only one version running in the cluster, it will be forward-compatible with most of the new version, are replaced by a one-time upgrade to the latest version. If there is a scene 2 are simultaneously present version, the user can kubectl get crd <name>further select the way;

2. Definition This layer does not face the end user, the main platform for use, for non K8s implementation, if a plurality of scenes version exists, the OAM implementation platform to an end user can select a different version of the show.

Directly into major changes K8s CR 2 Component as examples and Trait

Workload and original way Trait level, we are only part of the spec out of CR, respectively, on workloadSettingsand propertiesfield.

Although this manner may "derive" K8s CR, but is not conducive to the access in the CRD K8S ecological, need to change formats redefined again spec.

// 老版本，仅对比使用
apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: rediscluster
spec:
  workloadType: cache.crossplane.io/v1alpha1.RedisCluster
  workloadSettings:
    engineVersion: 1.0
    region: cn

// 老版本，仅对比使用
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: custom-single-app
  annotations:
    version: v1.0.0
    description: "Customized version of single-app"
spec:
  variables:
  components:
    - componentName: frontend
      instanceName: web-front-end
      parameterValues:
      traits:
        - name: manual-scaler
          properties:
            replicaCount: 5

Now directly embedded CR manner, it can be seen in workloadand traitdescribed below is a complete field CR.

apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: example-server
spec:
  prameters:
    - name: xxx
      fieldPaths: 
        - "spec.osType"
  workload:
    apiVersion: core.oam.dev/v1alpha2
    kind: Server
    spec:
      osType: linux
      containers:
      - name: my-cool-server
        image:
          name: example/very-cool-server:1.0.0
        ports:
        - name: http
          value: 8080
        env:
        - name: CACHE_SECRET

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: cool-example
spec:
  components:
  - componentName: example-server
    traits:
    - trait:
        apiVersion: core.oam.dev/v1alpha2
        kind: ManualScalerTrait
        spec:
          replicaCount: 3

The advantage is obvious:

1. Can easily K8s docking system in the conventional CRD, even K8s native Deployment(as a custom workload access) and other resources;
2. K8s CR field defines the level of mature, full parsing and validation also referred CRD system.

Here we note that the following traits is []trait{CR}not the []CR  structure, more than a layer of seemingly useless traitfield, mainly by the following two reasons:

• In this dimension for the subsequent trait do leave room for expansion, such as the possible arrangement ( ordering) and so on.
• Non K8s system in this layer may not be in strict accordance with the wording of CR, fully customizable, does not bind K8s description format.

3 major changes transmission parameters used jsonPath replace the original fromParam

R & D can leave a field to cover operation and maintenance , it has been a very important function OAM.

It is reflected in the flow of the OAM Spec: Component development inside the defined parameter, operation and maintenance to cover the corresponding parameters parameterValue AppConfig inside.

The initial parameter passing, there is a field at the back of each fromParam  field, support for custom schema, in this way clearly can not cover all the scenarios:

// 老版本，仅对比使用
apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: rediscluster
spec:
  workloadType: cache.crossplane.io/v1alpha1.RedisCluster
  parameters:
  - name: engineVersion
    type: string
  workloadSettings:
    - name: engineVersion
      type: string
      fromParam: engineVersion

Later we had proposed such a scheme:

// 老版本，仅对比使用
apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: rediscluster
spec:
  workloadType: cache.crossplane.io/v1alpha1.RedisCluster
  parameters:
  - name: engineVersion
    type: string
  workloadSettings:
    engineVersion: "[fromParam(engineVersion)]"

The biggest problem of this program is static IaD (Infrastructure as Data) which functions have been added dynamic to understand and use brings complexity.

After much discussion, we describe a new program in the parameter position to be injected in the form of JsonPath, on the user's understanding to ensure the AppConfig is static.

apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: example-server
spec:
  workload:
    apiVersion: core.oam.dev/v1alpha2
    kind: Server
    spec:
      containers:
      - name: my-cool-server
        image:
          name: example/very-cool-server:1.0.0
        ports:
        - name: http
          value: 8080
        env:
        - name: CACHE_SECRET
          value: cache
  parameters:
  - name: instanceName
    required: true
    fieldPaths:
    - ".metadata.name"
  - name: cacheSecret
    required: true
    fieldPaths:
    - ".workload.spec.containers[0].env[0].value"

fieldPaths is an array, each element defines the parameters and the corresponding Workload in the field.

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: my-app-deployment
spec:
  components:
    - componentName: example-server
      parameterValues:
        - name: cacheSecret
          value: new-cache

In AppConfig in parameterValues ​​or go to cover Component of the parameter.

The main changes name to Component 4 ComponentSchematic

Original components of this concept called ComponentSchematic, the main reason for this name is mixed up inside some of the syntax and options description, such as for Workload Core ( container) and for the extension Workload ( workloadSettings), not the same as the wording container in the definition of specific parameters, workloadSettings like It is the schema (explain how to fill out the parameters). v1alpha1 version of WorkloadSetting also integrated into the type / description of the class, even more ambiguous.

// 老版本，仅对比使用
apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: rediscluster
spec:
  containers:
     ...
  workloadSettings:
    - name: engineVersion
      type: string
      description: engine version
      fromParam: engineVersion
     ...

In v1alpha2 version, the components of this concept changed Component, clear as an example of Workload, all syntax definitions are referenced in WorkloadDefinition CRD actually defined.

In K8s implementation, WorkloadDefinition is a reference to CRD, Component.spec.workload is written in the corresponding instance CRD CR.

apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: example-server
spec:
  workload:
    apiVersion: core.oam.dev/v1alpha2
    kind: Server
    spec:
   ...

5 Scope major changes created solely by CR, no longer created by AppConfig

Scope of v1alpha1 AppConfig is created, it can be seen from the example, it is also essentially a CR can be "derived" to create CR. However, due to the positioning of the Scope can accommodate different AppConfig in Component, and Scope in itself is not an App, so use AppConfig create Scope been inappropriate.

// 老版本，仅对比使用
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: my-vpc-network
spec:
  variables:
    - name: networkName
      value: "my-vpc"
  scopes:
    - name: network
      type: core.oam.dev/v1alpha1.Network
      properties:
        network-id: "[fromVariable(networkName)]"
        subnet-ids: "my-subnet1, my-subnet2"

v1alpha2 full use of the new version of the CR to the corresponding instance, in order to make the concept Scope of clearer and more convenient to correspond to different types of Scope, the Scope out directly defined by the corresponding ScopeDefinition CRD CR created. Examples are as follows:

apiVersion: core.oam.dev/v1alpha2
kind: ScopeDefinition
metadata:
  name: networkscope.core.oam.dev
spec:
  allowComponentOverlap: true
  definitionRef:
    name: networkscope.core.oam.dev

apiVersion: core.oam.dev/v1alpha2
kind: NetworkScope
metadata:
  name: example-vpc-network
  labels:
    region: us-west
    environment: production
spec:
  networkId: cool-vpc-network
  subnetIds:
  - cool-subnetwork
  - cooler-subnetwork
  - coolest-subnetwork
  internetGatewayType: nat

Used in the scope AppConfig referenced as follows:

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: custom-single-app
  annotations:
    version: v1.0.0
    description: "Customized version of single-app"
spec:
  components:
    - componentName: frontend
      scopes:
        - scopeRef:
            apiVersion: core.oam.dev/v1alpha2
            kind: NetworkScope
            name: my-vpc-network
    - componentName: backend
      scopes:
        - scopeRef:
            apiVersion: core.oam.dev/v1alpha2
            kind: NetworkScope
            name: my-vpc-network

Variable list 6 changes mainly removed and [fromVariable ()] dynamic function

There Variable v1alpha1 version for open source reference AppConfig in some public variables reduce redundancy, joined the Variable list. But the practical point of view, significantly reducing the redundant and not reduce the complexity of OAM spec, on the contrary, to increase the dynamic function significantly increases the complexity.

On the other hand, fromVariable by such a capability can helm template / kustomiz do other tools, these tools to render a complete OAM spec, then used.

So here a list of variables and associated fromVariable are removed, it does not affect any functionality.

// 老版本，仅对比使用
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: my-app-deployment
spec:
  variables:
    - name: VAR_NAME
      value: SUPPLIED_VALUE
  components:
    - componentName: my-web-app-component
      instanceName: my-app-frontent
      parameterValues:
        - name: ANOTHER_PARAMETER
          value: "[fromVariable(VAR_NAME)]"
      traits:
        - name: ingress
          properties:
            DATA: "[fromVariable(VAR_NAME)]"

The main changes to 7 to replace the original six core Workload with ContainerizedWorkload

It is now uniformly defined by WorkloadDefinition Workload, Component become an example of, so the original six core Workload actually turned into the same WorkloadDefinition, field description exactly the same, the only difference is a trait is not the same constraints and demands. Therefore, the original six core Workload of spec, unified modify Workload type is called ContainerizedWorkload of.

Meanwhile, here it planned to increase by concepts such as policy, research and development to make express their demands for operation and maintenance strategies that can be expressed hope Component which trait increases.

apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: containerizedworkloads.core.oam.dev
spec:
  definitionRef:
    name: containerizedworkloads.core.oam.dev

Use ContainerizedWorkload a sample:

apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: frontend
  annotations:
    version: v1.0.0
    description: "A simple webserver"
spec:
  workload:
    apiVersion: core.oam.dev/v1alpha2
    kind: ContainerizedWorkload
    metadata:
      name: sample-workload
    spec:
      osType: linux
      containers:
      - name: web
        image: example/charybdis-single:latest@@sha256:verytrustworthyhash
        resources:
          cpu:
            required: 1.0
          memory:
            required: 100MB
        env:
        - name: MESSAGE
          value: default
  parameters:
  - name: message
    description: The message to display in the web app.  
    required: true
    type: string
    fieldPaths:
    - ".spec.containers[0].env[0].value"

Next Steps

1. Between application-level components and parameter passing dependencies ( Workflow );
2. Policy programs , to facilitate research and development put forward demands for trait in Component;
3. Component increase concept version, while giving an OAM address application release relevant way .

Common FAQ

1. Transformation of our original platform OAM model to achieve what needs to be done?

For application management platform was originally on K8s, access transformation of OAM implementations can be divided into two stages:

• Implement OAM ApplicationConfiguration Controller (abbreviated AppConfig Controller), that contains the OAM Controller Component, WorkloadDefinition, TraitDefinition, ScopeDefinition like CRD. The OAM AppConfig AppConfig Controller as described in, pull CRD Operator original platform;
• Gradually the original CRD Operator in accordance with the idea of ​​separation of concerns, divided into Workload and Trait. At the same time access and reuse OAM community more Workload, Trait, rich in more scenes.

2. CRD Operator to access existing OAM what needs to be done to change?

Existing CRD Operator ** OAM functions smoothly access system, such as an extension Workload independent access. However, in order to better enable end-users to realize the benefits of OAM separation of concerns, we strongly recommend CRD Operator Depending on R & D and operational concerns separated into different CRD, CRD research attention as Workload access OAM, operational concerns CRD is a Trait access OAM.

Currently, OAM specifications and model actually solve many existing problems, but its journey has just begun. OAM is a neutral open source project, we welcome more people to participate, jointly define the future of native cloud application delivery.

way of participation:

• Nails scan code to enter the Chinese OAM project discussion groups

• By Gitter directly involved in the discussion
• Open source implementation of OAM address
• Click star look

About the Author

Sun Jianbo (nickname: Tianyuan) Ali cloud technology expert, is one of the major makers OAM specifications, committed to promoting the standardization of cloud-native applications. While also participating in large-scale cloud Alibaba native application delivery and application management related work. Team invites application delivery, expert Serverless, PaaS field to join, please contact jianbo.sjb AT alibaba-inc.com

Recruit people it!

Native cloud application platform invites Kubernetes / Serverless / PaaS / application delivery specialists (P6-P8) to join:

• Work Experience: recommendations from P6-7 three years, five years from P8, specifically to see the actual capacity;
• Location: China (Beijing / Hangzhou / Shenzhen); Overseas (San Francisco Bay Area / Seattle);
• Posts include: architects, technologists, engineers and other full stack.

Resume immediately reply, 2 to 3 weeks the results, resume delivery: jianbo.sjb AT alibaba-inc.com.

" Alibaba Cloud native concern micro service, Serverless, container, Service Mesh and other technical fields, focusing cloud native popular technology trends, cloud native large-scale landing practice, most do understand the developer's native cloud technology circles."