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

What is the core principle of OAM Kubernetes implementation, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

Why did OAM come into being

We know that since its birth, application container technology has quickly conquered almost all cloud vendors and data centers with the charm of "completely changing the way software is packaged and distributed". However, the innovation of software packaging and distribution has not changed the definition and description of the software itself, and the application management experience based on K8s has not made the work of business R & D and operation and maintenance easier.

In fact, the cloud native technology revolution brought about by Kubernetes lies in the standardization and abstraction of the infrastructure layer, but this abstraction is still too far away from business R & D and operation and maintenance. As the most typical example, to this day, there is no concept of "application" in Kubernetes, instead it provides finer-grained "workload" primitives, such as Deployment or DaemonSet.

In the real environment, an application is often composed of a series of independent components, such as an e-commerce website composed of a "PHP application container" and a "database instance", a machine learning and training task composed of a "parameter service node" and a "work node", and a micro-service application composed of "Deployment + StatefulSet + HPA + Service + Ingress".

The lack of the concept of "application" in the Kubernetes project is not only a deliberate design, but also causes the extreme fragmentation and high learning threshold of today's cloud native application management ecology. How to solve the problem of "what exactly is an application in Kubernetes" through a standardized way is the original motivation of OAM project release.

What's the point?

Before the release of OAM, there was no concept called "application" in the cloud native ecology. Even today, almost every team in the world that is native to the landing cloud has a self-defined concept of "applications" with uneven levels of abstraction and rich and diverse definitions. As a result, all the systems built around these "applications" have become one chimney after another.

For the whole cloud primary ecology, the fragmentation and chimney of the application layer is actually very disadvantageous to the whole ecological evolution. Today's current situation has also proved this point. After Kubernetes gradually standardized the access mode of infrastructure capabilities, the application management, which was closer to users and more important, has almost stagnated its evolution, and has not put forward any innovative ideas in recent years.

As a result of the stagnation of application management, business R & D and operations around the world have been forced to become "container experts" overnight, learning concepts in various areas of "infrastructure as data (Infrastructure as Data)" that they should not care about (such as declarative API, controllers, etc.), while complaining that Kubernetes is too complex and the design is too weird.

In short, as a system-level project for infrastructure engineers, Kubernetes is mainly responsible for providing loosely coupled infrastructure semantics, which makes users often feel that the concerns in these files are very low-level and the learning threshold is very high when they learn and manipulate Kubernetes YAML files.

In fact, for the real end-users of Kubernetes, such as business developers and operators, they do not want to configure such low-level resource information, but want a higher-dimensional abstraction. This requires an application definition that is really oriented to the end-user side and an application definition primitive that can provide their own perspective for business R & D and application operation and maintenance personnel. So, the first change brought about by OAM is to provide a standardized way to define a higher level of application level abstraction that everyone can follow, and to make "separation of concerns" as the core idea of this definition model.

The second change brought by OAM is that it brings the application definition to the Kubernetes project, or rather, it is a standard open source specification that defines and describes the application itself and its required operation and maintenance capabilities. From the point of view of the Kubernetes project, OAM is a Kubernetes native standard "application definition" project, and it is also a platform layer framework that focuses on encapsulating, organizing and managing various "operation and maintenance capabilities" in Kubernetes, as well as connecting "operation and maintenance capabilities" and "applications".

In detail, OAM standardizes the specification of application definition based on the Kubernetes API Resource Model (Kubernetes Resource Model), which emphasizes that a modern application is a collection of components, not a simple workload or K8s Operator. So in the context of OAM, a PHP container and the database it depends on, as well as the various cloud services it needs to use, are part of an "e-commerce website" application. Furthermore, OAM considers the "operation and maintenance strategy" required by this application as part of an application, such as the HPA (horizontal automatic extension policy) required by this PHP container:

Take the Crossplane project as an example, how has it changed since it was upgraded through OAM in this partnership?

"as a leader in the field of hybrid cloud management, Crossplane's OAM ensures that any running program, operation and maintenance capability, and cloud services on which it depends can drift seamlessly in a hybrid cloud environment as a whole."

This platform-independent application definition paradigm makes application developers only need to describe their application through the OAM specification, then the application can run on any Kubernetes cluster or Serverless application platform or even edge environment without any modification to the application description. The release of the Crossplane OAM version in this partnership means that the OAM community is unifying standard application definitions with standardized cloud service management capabilities to achieve true "cloud application delivery".

How does OAM work?

So how does OAM work in a project?

According to reports, OAM runs in Kubernetes as a native plug-in. OAM emphasizes that the whole model is a separation of concerns. That is, the business R & D staff is responsible for defining and maintaining components (Component) to describe the service unit, while the operation and maintenance personnel define the operation and maintenance characteristics (Trait) and attach them to the previous components, and finally form the OAM deliverables-ApplicationConfiguration.

This design is an important basis for OAM to provide business R & D and operation and maintenance personnel with the best experience and the lowest mental burden while being able to access various capabilities of Kubernetes indefinitely. At the same time, infrastructure engineers can add more workloads (such as FaaS) to Kubernetes at any time to run serverless functions, or add operations features (such as CronHPA) to define CronJob-type HPA policies. OAM manages application delivery capabilities and processes throughout the platform in a standard declarative way, and provides API primitives for each role to express their own demands, and finally implements these demands through Kubernetes.

What kind of projects require OAM?

In fact, almost all Kubernetes-based application management platforms have clear requirements for building their own application models in a standardized way through OAM. On the other hand, because OAM is a native Kubernetes API resource model, the migration process here is very easy, and the migration operation can be completed step by step through the grayscale tube of API objects (gradually taking over the existing Kubernetes objects through OAM objects).

Compared with the current situation that the traditional PaaS is closed and can not connect with the "cloud native ecology based on Operator", the modern cloud native application management platform based on OAM and Kubernetes is essentially an "application-centric" Kubernetes, which ensures that this application platform can seamlessly connect with the whole cloud native ecology. At the same time, OAM can further shield the complexity and differences of container infrastructure and bring platform users a low mental burden, standardized and consistent application management and delivery experience. This makes a Kubernetes application platform based on OAM can first hide the details of the underlying infrastructure (for example, cloud or Internet of things), focus on application layer abstraction, and provide an application-centric resource model.

Secondly, OAM divides the three roles of development, operation and maintenance and infrastructure on the application delivery path, which separates the concerns and makes the process clearer and easier to manage.

Third, OAM stands on the shoulder of K8s API resource model and provides portable application and infrastructure abstraction, so that an application description can be delivered and run directly in any environment, such as cloud, edge, end, etc., without modification.

In addition, OAM defines a set of core workload / operation and maintenance characteristics / application categories as the cornerstone of the application delivery platform. Platform developers can also add more workloads (such as FaaS or any cloud service), or add operation and maintenance features (such as CronHPA) to define CronJob-type HPA policies. OAM manages application delivery capabilities and processes throughout the platform in a standard declarative manner. As there are more and more modular Workload and Trait, there will be a component market. OAM is like the manager of this component market, dealing with the relationship between components, integrating many components into a product and delivering it to users. The Kubernetes application management platform supported by OAM can assemble underlying capabilities, operation and maintenance features, and development components as flexibly as Lego bricks. It makes the application management unified, but the function is more powerful.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

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.