Shulou(Shulou.com)05/31 Report--

How to analyze the balance standard and extensibility of the new version of OAM v1alpha2, aiming at this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and easy way.

At present, OAM has become the core architecture of cloud products built by many companies, including Ali, Microsoft, Upbond, Harmony Cloud and so on. They built an "application-centric" and user-friendly Kubernetes PaaS; through OAM to give full play to the standardization and expansibility of OAM, realizing the core Controller of OAM while quickly accessing the existing Operator capabilities, and transversely connecting multiple modules through OAM, breaking the dilemma that the original Operator is isolated from each other and can not be reused.

Back to the point, let's take a look at what changes v1alpha2 has made.

Description of major changes

In order to facilitate your reading, only the most important changes are listed here, and some details are based on the upstream OAM Spec Github warehouse.

Terminology description

CRD (Custom Resource Definition): CRD in OAM is a general definition of a custom resource description. In the OAM implementation of K8s, it can exactly correspond to the CRD of K8s. In the implementation of non-K8s, the CRD of OAM needs to contain APIVersion/Kind and be able to describe fields for verification.

CR (Custom Resource), CR in OAM is an instance of CRD and is a resource description that conforms to the field format definition in CRD. The OAM implementation of K8s can exactly correspond to the CR of K8s, while in the implementation of non-K8s, you can need to align APIVersion/Kind and field format definitions.

Major change 1 defines Workload, Trait, and Scope using the Reference model

The original approach of v1alpha1 is as follows:

/ / the old version Only use apiVersion: core.oam.dev/v1alpha1kind: WorkloadTypemetadata: 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 schema, group/version/kind was a field, and the check of spec was indicated by jsonschema that the overall format was actually similar to CRD, but not exactly the same.

The new version of v1alpha2 has completely changed to the reference model, describing a reference relationship in the form of WorkloadDefinition TraitDefinition ScopeDefinition. You can directly refer to a CRD,name that is the name of CRD. For non-K8s OAM implementations, the name here is an index, and you can find a CRD-like check file that contains apiVersion and kind, as well as the corresponding schema check.

Workload

ApiVersion: core.oam.dev/v1alpha2kind: WorkloadDefinitionmetadata: name: containerisedworkload.core.oam.devspec: definitionRef: # Name of CRD. Name: containerisedworkload.core.oam.dev

Trait

ApiVersion: core.oam.dev/v1alpha2kind: TraitDefinitionmetadata: name: manualscalertrait.core.oam.devspec: appliesToWorkloads:-containerizedworkload.core.oam.dev definitionRef: name: manualscalertrait.core.oam.dev

Scope

ApiVersion: core.oam.dev/v1alpha2kind: ScopeDefinitionmetadata: name: networkscope.core.oam.devspec: allowComponentOverlap: true definitionRef: name: networkscope.core.oam.dev

Note:

For the OAM implementation of K8s, name is the name of CRD in K8s, which is composed of. Composition. The best practice in the community is that a CRD has only one version running in the cluster, and the new version is generally forward compatible and replaced with the latest version at one time when upgrading. If there are indeed scenarios where two version exist at the same time, the user can also select further through kubectl get crd.

The Definition layer is not oriented to end user and is mainly for platform implementation. For non-K8s implementation, if there are multiple version scenarios, the OAM implementation platform can show end users the choice of different version.

Major change 2 directly embeds K8s CR as Component and Trait instances

In the previous way, we only took out the spec part of CR at the Workload and Trait levels, and put it in the workloadSettings and properties fields, respectively.

Although this method has been able to "deduce" K8s CR, it is not conducive to CRD access in K8s ecology, and spec needs to be redefined in a different format.

/ / the old version, only comparing with the old version using apiVersion: core.oam.dev/v1alpha1kind: ComponentSchematicmetadata: name: redisclusterspec: workloadType: cache.crossplane.io/v1alpha1.RedisCluster workloadSettings: engineVersion: 1.0 region: cn// Only use apiVersion: core.oam.dev/v1alpha1kind: ApplicationConfigurationmetadata: 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

The current approach is to embed CR directly, and you can see that under the workload and trait fields is the complete CR description.

ApiVersion: core.oam.dev/v1alpha2kind: Componentmetadata: name: example-serverspec: prameters:-name: xxx fieldPaths:-"spec.osType" workload: apiVersion: core.oam.dev/v1alpha2kind: 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_SECRETapiVersion: core.oam.dev/v1alpha2kind: ApplicationConfigurationmetadata: name: cool-examplespec: components:-componentName: example-server traits:-trait: apiVersion: core.oam.dev/v1alpha2kind: ManualScalerTrait spec: replicaCount: 3

The benefits are obvious:

It is easy to interface with CRD in existing K8s system, even including resources such as native Deployment of K8s (as custom workload access).

The field definition at the K8s CR level is mature, and the parsing and verification are completely left to the CRD system.

Here, you notice that under traits is the structure of [] trait {CR} rather than [] CR. There is an extra layer of seemingly useless trait field, mainly for the following two reasons:

Leave room for subsequent extensions in the trait dimension, such as possible ordering, etc.

Non-K8s system in this layer can not be written in strict accordance with the CR, completely customized, not bound to K8s description format.

Major change 3 parameter passing uses jsonPath to replace the original fromParam

Research and development can set aside fields for operation and maintenance to cover, which has always been a very important function of OAM.

This is reflected in the process of OAM Spec: the R & D defines parameter in Component, and the operation and maintenance staff overrides the corresponding parameters through parameterValue in AppConfig.

The initial parameter passing is that there is a fromParam field after each field. After custom schema is supported, this method obviously cannot cover all scenarios:

/ / previous version, only comparing the use of apiVersion: core.oam.dev/v1alpha1kind: ComponentSchematicmetadata: name: redisclusterspec: workloadType: cache.crossplane.io/v1alpha1.RedisCluster parameters:-name: engineVersion type: string workloadSettings:-name: engineVersion type: string fromParam: engineVersion

Later, we proposed a plan like this:

/ / previous version, using apiVersion: core.oam.dev/v1alpha1kind: ComponentSchematicmetadata: name: redisclusterspec: workloadType: cache.crossplane.io/v1alpha1.RedisCluster parameters:-name: engineVersion type: string workloadSettings: engineVersion: "[fromParam (engineVersion)]"

The biggest problem with this solution is that dynamic functions are added to the static IaD (Infrastructure as Data), which brings complexity to understanding and use.

After many aspects of discussion, in the new scheme, we describe the location of the parameters to be injected in the form of JsonPath, which ensures that the AppConfig is static in the user's understanding.

ApiVersion: core.oam.dev/v1alpha2kind: Componentmetadata: name: example-serverspec: workload: apiVersion: core.oam.dev/v1alpha2kind: 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, and each element defines the parameters and the fields in the corresponding Workload.

ApiVersion: core.oam.dev/v1alpha2kind: ApplicationConfigurationmetadata: name: my-app-deploymentspec: components:-componentName: example-server parameterValues:-name: cacheSecret value: new-cache

In AppConfig or go to parameterValues to override the parameter in Component.

Major change 4 ComponentSchematic name changed to Component

The original concept of component is called ComponentSchematic, which is named mainly because there are some syntax descriptions and choices mixed in, for example, for Core Workload (container) and for extended Workload (workloadSettings), the writing is different. Container defines specific parameters, and workloadSettings is more like schema (description of how to fill parameters). The v1alpha1 version of WorkloadSetting also incorporates things like type/description, which makes it even more ambiguous.

/ / the old version, only comparing the use of apiVersion: core.oam.dev/v1alpha1kind: ComponentSchematicmetadata: name: redisclusterspec: containers:... WorkloadSettings:-name: engineVersion type: string description: engine version fromParam: engineVersion.

In the v1alpha2 version, the concept of components is changed to Component, which is explicitly an instance of Workload, and all syntax definitions are defined by the actual CRD referenced in WorkloadDefinition.

In the implementation of K8s, WorkloadDefinition refers to CRD, and the instance CR corresponding to CRD is written in Component.spec.workload.

ApiVersion: core.oam.dev/v1alpha2kind: Componentmetadata: name: example-serverspec: workload: apiVersion: core.oam.dev/v1alpha2kind: Server spec:... Major change 5 Scope is created separately by CR, not by AppConfig

The Scope in v1alpha1 is created by AppConfig, and as you can see from the example, it is essentially a CR that can be "inferred" to create a CR. But because the Scope is positioned to accommodate Component in different AppConfig, and the Scope itself is not an App, it has always been inappropriate to use AppConfig to create a Scope.

/ / previous version, using apiVersion: core.oam.dev/v1alpha1kind: ApplicationConfigurationmetadata: name: my-vpc-networkspec: 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"

The new version of v1alpha2 fully uses CR to correspond to instances. In order to make the concept of Scope clearer and more convenient to correspond to different types of Scope, take out the Scope and create it directly from the corresponding CR of the CRD defined by ScopeDefinition. Examples are as follows:

ApiVersion: core.oam.dev/v1alpha2kind: ScopeDefinitionmetadata: name: networkscope.core.oam.devspec: allowComponentOverlap: true definitionRef: name: networkscope.core.oam.devapiVersion: core.oam.dev/v1alpha2kind: NetworkScopemetadata: name: example-vpc-network labels: region: us-west environment: productionspec: networkId: cool-vpc-network subnetIds:-cool-subnetwork-cooler-subnetwork-coolest-subnetwork internetGatewayType: nat

Using scope references in AppConfig is as follows:

ApiVersion: core.oam.dev/v1alpha2kind: ApplicationConfigurationmetadata: 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/v1alpha2kind: NetworkScope name: my-vpc-network-componentName: backend scopes:-scopeRef: ApiVersion: core.oam.dev/v1alpha2 kind: NetworkScope name: my-vpc-network Major changes 6 remove Variable list and [fromVariable ()] dynamic function

Variable is included in the v1alpha1 version in order to reduce redundancy by referencing some public variables in AppConfig, so the Variable list is added. However, from a practical point of view, the reduced redundancy does not significantly reduce the complexity of OAM spec, on the contrary, increasing the dynamic function significantly increases the complexity.

On the other hand, capabilities like fromVariable can be done through tools such as helm template/ kustomiz, which render a complete OAM spec and then use it.

So here the variables list and related fromVariable are removed, and does not affect any function.

/ / the old version Only use apiVersion: core.oam.dev/v1alpha1kind: ApplicationConfigurationmetadata: name: my-app-deploymentspec: 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)]" main changes 7 replace the original six core Workload with ContainerizedWorkload

Now that we have uniformly defined Workload,Component in WorkloadDefinition as an instance, the original six core Workload have actually become the same WorkloadDefinition, with exactly the same field description, except for different constraints and demands on trait. Therefore, the spec of the original six core Workload has been modified to a Workload type called ContainerizedWorkload.

At the same time, it is planned to add the concept of policy to let R & D express the demand for the operation and maintenance strategy, that is, which trait can be expressed in Component.

ApiVersion: core.oam.dev/v1alpha2kind: WorkloadDefinitionmetadata: name: containerizedworkloads.core.oam.devspec: definitionRef: name: containerizedworkloads.core.oam.dev

An example of using ContainerizedWorkload:

ApiVersion: core.oam.dev/v1alpha2kind: Componentmetadata: name: frontend annotations: version: v1.0.0 description: "A simple webserver" spec: workload: apiVersion: core.oam.dev/v1alpha2kind: ContainerizedWorkload metadata: name: sample-workload spec: osType: linux containers:-name: web image: example/charybdis-single:latest@@sha256:verytrustworthyhash resources: cpu: Required: 1.0memory: 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 step

Application-level parameter transfer and dependency between components (workflow)

Policy scheme, which is convenient for R & D to make claims to trait in Component.

Component adds the concept of version, and gives the relevant ways to release the version of OAM solution application.

Common FAQ

What do we need to do to transform our original platform into an OAM model?

For the original application management platform on K8s, the implementation of access to OAM can be divided into two stages:

Implement OAM ApplicationConfiguration Controller (AppConfig Controller for short), this Controller also contains OAM's Component, WorkloadDefinition, TraitDefinition, ScopeDefinition and other CRD. AppConfig Controller pulls up the CRD Operator of the original platform according to the description in OAM AppConfig

The original CRD Operator is gradually divided into Workload and Trait according to the idea of separation of concerns. At the same time, access and reuse more Workload and Trait in the OAM community to enrich the functions in more scenarios.

What changes do existing CRD Operator need to make in order to access OAM?

The existing CRD Operator** can be smoothly connected to the OAM system, such as as an independent extended Workload access. However, in order to better let end users realize the benefits of the separation of OAM concerns, we strongly recommend that CRD Operator be separated into different CRD according to the different concerns of R & D and operation and maintenance. The CRD of R & D concern is connected to OAM as Workload, and the CRD of operation and maintenance is connected to OAM as Trait.

At present, the OAM specification and model have actually solved many existing problems, but its journey has only just begun. OAM is a neutral open source project, and we welcome more people to participate in it to define the future of cloud native application delivery.

This is the answer to the question about how to analyze the balance standard and scalability of the new version of OAM v1alpha2. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.