Last week, Microsoft and Alibaba jointly launched an open application model (OAM), a specification used to define the application of the model to deploy anywhere. Rudr is Microsoft-based OAM standards Kubernetes environment implementation.
I spent a weekend to understand the problem OAM trying to solve, and I also Rudr to reconstruct some of my favorite applications is based on the basis of micro-services. This article and the following tutorial will help ordinary Kubernetes users understand the motivations behind the OAM.
As we all know, Kubernetes is a sophisticated platform that contains many active components. When scheduling and deploy a simple two-tier Web application, you need involves the creation of Storage Classes, PVC, PV, Secret, ConfigMap, Service, Deployment and Ingress. In the actual production deployment also requires a sound log collection, monitoring, alarm, security, high availability and scalability, we will use StatefulSet (stateful applications), network policy, RBAC, access control, Pod transverse automatic retractable etc. Knowledge.
For the transition from a traditional IT environment, development engineers and operation and maintenance engineers, Kubernetes strong momentum of development people feel afraid. Even some of the familiar container DevOps professionals have found want to completely understand Kubernetes is a very tricky thing.
When converted to a file that can be deployed, a simple two-tier Web application may have a dozen YAML file, which contains the application-defined description for each object.
One of the core design principles of Kubernetes is decoupling the object. For example a service may exist independently of the Pod, to create a PV without any user, you may also be configured to handle a back-end without any Ingress request. Based on a set of labels, annotations and a selector, these features can be pieced together at runtime commonly used. A service forwards the request to the one or more eligible Pod. Ingress traffic is routed to a service is the same usage.
Kubernetes Each object is completely independent and self-governance. Although this design allows Kubernetes is highly scalable, but its drawback is the lack of application context. Kubernetes an application is a collection of autonomous objects in a series of collaborative work. When converted to a file that can be deployed, a simple two-tier Web application may have a dozen YAML file, which contains the application-defined description for each object. Management and maintenance of these layout files in a single environment is the biggest challenge facing contact with Kubernetes.
Helm tool you want to solve this problem through the concept of the chart. But even so, you tend to lose context or after deployment. More Kubernetes objects defined only after all applications running Helm required to arrange the collection file generation tool.
One of the other challenges Kubernetes is to have a very fuzzy boundaries between developers and the operation and maintenance personnel. In order to effectively use the platform, developers need to have some understanding of the runtime environment. They need to know how ConfigMap visible Pod packaging containers. They need to know which part of the initialization code should be packaged as Init container. Operation and maintenance personnel responsible for ensuring the correct naming convention to ensure the normal operation of service discovery. They need to know all environment variables to be passed to the Pod. Operation and maintenance personnel should be deployed to determine container ReplicationController, DaemonSet or StatefulSet according to the characteristics of the application. When they need a production environment deployment, or choose to use ClusterIP NodePort.
As noted above, which developers expect the necessary decision-making process needs to be familiar with running, and operation and maintenance personnel should knowledge of software design. OAM want to solve these problems in the following ways:
- The application context into micro-services deployment
- Clear focus between the developer and the operation and maintenance personnel
- Application model has nothing to do with the run-time
From the higher level is, OAM specification is used to define a set of micro-micro-services or service components belonging to the application. Each component has one or more worker nodes, which can be used as a service, or a consumer, or is required to complete the task. And characterized in having a possible configuration of an association between each working node. These configuration to the parameters passed to the working node, these characteristics can affect the operation of the assembly environment, a set of components belonging to the same class of an application.
OAM central premise is that developers work with the source code from the container when building a mirrored end, and operation and maintenance personnel responsible work right from the start here. A set of containers Mirror Ops team will be responsible for a single application to configure and deploy.
OAM in the assembly intended to enable developers to statement format independent of the infrastructure, the operation characteristic to distinguish between the execution units. Component defines the CPU, GPU, memory, and disk requirements on the basis of the system structure.
Each assembly work node type is as follows:
Configuration typically passed as parameters to the working node after treatment. Defined, for example the string to the connection to the database application service work nodes in the configuration.
These characteristics define the runtime behavior of nodes working to define an application. Rudr is the reference implementation of OAM, and have the following characteristics:
If we examine the concept of Workload and Trait description, they can easily apply these concepts to correspond to Kubernetes. Deployment is the nature of the service, and the service is Singleton has a replica of Deployment. They have to use ClusterIP or NodePort. Worker and Worker alone is not associated with the service Pods. Task is a parallelizable Kubernetes Job, and a single task is running a single Job.
These same properties also correspond to the concept of the automatic expansion Kubernetes, Ingress, Deployment and PVC.
Thus using the OAM and Rudr, developers can submit code and build the work can be converted to a mirror node container. Operation and maintenance person configuration defined by the characteristics of these components, which formed a working node.
Technically, OAM this specification can be applied to a virtual machine infrastructure platform (IaaS), PaaS, and container management platform (CaaS). Each OAM building blocks can be mapped to the appropriate environment. That OAM defined in YAML files can be deployed in any environment without any modification.
In the next article in this series, I will take you step by step tutorial to understand Rudr end of which shows to Node.js Web application deployment components, configure workflows involved in their properties. Stay tuned ~
Author | Janakiram MSV
translation | Big dimple
description link https://thenewstack.io/what-does-the-open-application-model-oam-and-rudr-mean-for-kubernetes-developers/ been authorized translation of the original author reproduced
"Alibaba Cloud native micro-channel public number (ID: Alicloudnative) focus on micro service, Serverless, container, Service Mesh and other technical fields, focusing popular technology trends in cloud native, cloud native large-scale landing practice, do most understand cloud native developers technology public number. "