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

How to build an application-centric Kubernetes, 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.

The following will share with you how to build an "application-centric" Kubernetes.

How to build an "application-centric" Kubernetes?

Building such a user-centric Kubernetes requires several levels of work.

Application layer driver

First of all, let's take a look at the core part, the blue part of the image above, that is, Kubernetes. You can define a set of CRD and Controller on top of Kubernetes. You can do the API on the user side in CRD. For example, pipeline is an API, and the application is also an API. Such as the expansion strategy on the operation and maintenance side, these can be installed through CRD.

# # Application layer abstraction

So the first problem we need to solve is to apply abstraction. If you do application layer abstraction in Kubernetes, it is equivalent to defining CRD and Controller, so Controller can be called application layer abstraction. It can be in the community, such as Tekton,istio, which can be used as your application driver layer. This is the first problem, which solves the abstract problem. It's not that hard.

Plug-in capability management

Many functions are not provided by K8s, the built-in Controller is limited, and most of the capabilities come from the community or self-developed Controller. At this time, a lot of plug-ins will be installed in my cluster. If I want to build an application-centric Kubernetes, I must be able to manage these capabilities, otherwise the entire cluster will be out of control. If the user wants such an ability, I need to tell him whether he has it or not. An API needs to be exposed to tell him whether the cluster has the capabilities he needs. Suppose you need to split the traffic of istio, and you need an interface to tell the user whether this capability exists. Users cannot be expected to get whether crd is appropriate and check whether Controller is running. This is not called application-centric K8s, this is called naked K8s.

So there must be a capability called plug-in capability management. If I install Tekton,kEDA,istio these components, I must register these components with the capability registry so that users can discover these capabilities and query them. This is called: plug-in capability management.

User experience layer

With the application layer driver, application layer abstraction, and plug-in capability management, we can better consider how to expose a friendly API or interface to the user. There are several ways, such as the CLI client command line tool, or a Dashboard, or a Docker Compose on the R & D side. Or you can let users write code and implement DSL with python or go.

What the user experience layer does depends entirely on how the user accepts it. The key point is that the application-centric Kubernetes,UI layer can be easily done based on the application layer abstraction. For example, CLI can directly create an assembly line and application, instead of walking around to create Deployment and Pod, the two converge in a completely different way. Pipeline only needs to be generated and it is over. Then go to Pod and Deployment to form a Pipeline, then the work is very tedious. This is very important, when you have the application layer driver, application layer abstraction, plug-in capability management, and then to build the user experience layer will be very simple.

Open Application Model (OAM)

If you want to build an application-centric Kubernetes, is there a standardized and simple solution?

The following is going to introduce you: Open Application Model (OAM).

The essence of OAM is to help you build an "application-centric" Kubernetes standard specification and framework. Compared to the previous solutions, OAM focuses on these three levels.

Application component Components

The first is called application layer abstraction, and OAM exposes its own definition of application layer abstraction to users, and the first abstraction is called Components. Components actually helps us define Workload such as Deployment and StatefulSet. Expose to the user to define the semantics of these applications.

Apply feature Traits

The second is called the application feature, which is called Traits. The concepts of the operation and maintenance side, such as expansion strategy and release strategy, are exposed to users through an API called Traits. First of all, OAM gives you a way to define abstractions in the application layer, called Components and Traits, respectively. Since you need to associate Traits application features with the application component Components, such as Deployment requires some kind of expansion strategy or release strategy, how to relate them together?

Apply configuration Application Configuration

This requires a third configuration called the Application Configuration application configuration. Eventually, these concepts and configurations will become CRD. If you install the Kubernetes Runtime component of OAM in your K8s, then you can parse the policy and Workload defined by your CRD, and finally give it to K8s to run. Just one component helps you better define the abstract application layer and provides several standardized methods.

Capability definition object Definitions

After leaving these abstractions and capabilities to K8s, where is the Controller plug-in I need for these capabilities? Is there a Ready? Do you already have these versions? can you install them automatically? This is the fourth ability: the ability to define the object. This is the last API provided by OAM, through which you can register all the plug-ins of K8s, such as Tekton, KEDA, istio, etc.

Register it as an ability or a feature of a component. Flager, for example, can register it as a canary publishing ability, and users can use it as long as they find that the publishing strategy exists, indicating that the cluster supports Flager. This is an application-centered game. Taking the user side as the starting point, rather than the cluster side as the starting point, the user side understands his system and operates his system through an upper api, features and components. These are the strategies and methods provided by OAM.

To sum up, OAM can help platform builders or developers define user-side and application-side abstractions in a standardized way. The second point is to provide plug-in capabilities to register with the management mechanism. And with these abstractions and mechanisms, it is very convenient to build an extensible UI layer. This is the core function and value of OAM.

How will OAM provide an API to the user? Components

Component is a versioned definition of a workload. For example, creating a Component in the figure above is actually creating a Deployment. After such a Component is handed over to K8s, a Component is first created to manage the Workload. When you modify the Component, a corresponding version of deployment is generated. This Component is actually a template for Deployment. For example, if I modify the version of image, this action will trigger the OAM plug-in to generate a new version of Deployment, which is the first point. In fact, the version of the management mechanism to manage Component.

The second point is that the Workload part is completely custom, or pluggable.

Today can be defined as Deployment, tomorrow can be defined as a very simple version. In other words, the abstraction of my Components depends entirely on the user's own decision. Later, it can also be changed to Knative Service, or even to an Open PaaS. So you are free to define your own abstractions in the Workload section of Components. As long as you install the corresponding CRD in advance, this is a very advanced game.

In addition, in OAM, "cloud service" is also a kind of Workload, as long as you can define your cloud service in CRD, you can directly define it as a component that an application depends on in OAM. For example, the redis in the figure above is actually Aliyun's Redis service, which is probably played like this.

Trait and Application Configuration

First of all, Trait is a description of declarative operation and maintenance capabilities, which is actually a Kubernetes API object. Any component and capability of managing and operating Workload can be defined as a Trait in this way of CER. So the Virtual Services in HPA,API gateway,istio is all Trait.

Application Configuration is like an envelope that binds Traits to Component, which is explicitly bound. Loosely coupled approaches such as Label are not recommended in OAM to correlate your workload. It is recommended that you explicitly bind your features and workloads through CRD in this structured way. The advantage is that my binding relationship is manageable. You can see this binding relationship through kubectl get. As an administrator or user, it is very easy to see what all the operation and maintenance capabilities bound to a component are, which can be shown directly, and it is difficult to do so through label. At the same time, the problem with Label itself is that it is not versioned or structured, so it is difficult to upgrade and expand. With such a structured definition, subsequent upgrade extensions will become very simple.

In a user configuration, multiple Components can be associated. It believes that all the components needed for an application to run and the operation and maintenance capabilities it depends on should be defined as a file called ApplicationConfiguration. So in any environment, as long as you have the file, after it is submitted, the application will take effect. OAM is hoping to provide a self-contained application declaration.

Definition Object

In addition, it is mentioned that the corresponding administrator provides Definition Object, which is an API object used to register and discover plug-in capabilities.

For example, I would like to define Knative Service as a workload supported by the platform. As shown in the figure above, you only need to simply write a file. You can refer to service.serving.knative.dev in definitionRef. The advantage of this is that you can view Knative Service's Workload directly with kubectl get Workload. So this is a mechanism for registering and discovering plug-in capabilities, making it very easy for users to see if there is currently a workload in the system called Knative Service. Instead of asking users to look at CRD, to see if plug-ins are installed, and to see whether Controller is running, this is a very troublesome thing. So there must be such a plug-in registration and discovery mechanism.

There are other additional capabilities in this section that allow you to register Trait and allow registered Trait-An and Trait-B to conflict. This information can also be brought in, so that when deployed, it is checked that An and B are in conflict, resulting in an error message. Otherwise, the deployment will end up knowing nothing, and the two capabilities are in conflict, so delete the rollback and recreate it. OAM will expose the conflict of operation and maintenance ability when registering, which is also done by Definition.

In addition, OAM's model layer has some other additional capabilities that allow you to define more complex applications.

Summary

We mentioned earlier that many enterprises are building an upper application management platform based on Kubernetes. Kubernetes is actually for platform developers, not for R & D and application operations. It is designed in this way, so it needs to be based on Kubernetes to build application management platform. To better serve R & D and operation and maintenance, this is also a very natural choice. This is not to say that you have to use K8s to serve your users. If your users are all K8s experts, this is no problem. If not, it is natural for you to do such an application platform.

But we don't want to build a traditional PaaS like Cloud Foundry before K8s. Because it will completely obscure the power of K8s. It has its own set of API, its own ideas, its own models, its own way of using it. It is different from Kubernetes, it is difficult to expose the ability of Kubernetes. This is a use of the classic PaaS, but we don't want such an idea. Our goal is not only to provide users with an experience, but also to give full play to the capabilities of Kubernetes. And the experience is exactly the same as Kubernetes. OAM is essentially oriented to development and operation and maintenance, or to application-centric Kubernetes.

So today's introduction of OAM is a unified, standard, highly scalable application management platform, can be application-centered brand-new Kubernetes, which is a focus of today's discussion. The OAM project is the core dependency and mechanism that underpins this concept. Simply put, OAM allows you to do this in a unified, standardized way. For example, standardize the definition of application layer abstraction, standardize the preparation of underlying application drivers, and standardize the management of K8s plug-in capabilities.

For platform engineers, can daily work make it easier and faster for platform engineers to do this with a standardized framework or reliance. This is the value that OAM brings to platform engineers. Of course, it also has some additional benefits, based on the new API exposed by OAM, your upper UI will be very easy to build.

Your OAM is naturally divided into two categories, one is called workload, and the other is called operation and maintenance features. So your UI layer can be directly docked, which will reduce a lot of front-end work. GitOps / continuous integration discovery based on CI/CD will also become very simple. Because it defines an application in a self-contained way, rather than writing many yaml files. And this file contains not only the workload, but also the operation and maintenance characteristics. So after creating this file and submitting it to Kubernetes, the application needs to do canary release or blue-green release, flow control, all clearly defined in this application configuration file. Because whether GitOps or continuous integration, you don't want to care about how your pod or Deployment is generated, how the application is operated and maintained, and how to run, you still have to rely on Kubernetes plug-ins or built-in capabilities. These capabilities are defined into a self-contained file that applies to all clusters. So this will make your GitOps and continuous integration easier.

These are some of the unique values that OAM brings to platform engineers. To put it simply, it is a unified, standard API that distinguishes between R & D and operation and maintenance strategies, making your UI and GitOps particularly easy to build. Another point is that it provides a highly scalable ability to manage K8s plug-ins. Such a system really achieves the standard, self-operation and maintenance, an application-centric and user-centered Kubernetes platform.

OAM community

Finally, I hope all of you will join the OAM community and participate in the discussion. In the above picture, there is a nail group QR code, there are currently thousands of people, the discussion is very heated, we will discuss GitOps,CI/CD, building OAM platform and so on. OAM also has weekly meetings in the Asia-Pacific region, which you can attend. The link above is the address of the open source project, and you can use the capabilities we mentioned above by installing this into Kubernetes.

QA link

Q1: if the example of Function is asked, can it be understood as Serverless or PaaS?

A1: it is correct to understand this. It can be understood as a Function of Ali Cloud, or Knative Service.

Q2: is there a norm that allows me to define the corresponding rules freely?

A2: yes, there is a specification in OAM called spec. There is a specification for submitting containerization in spec. More abstract specifications will be added later. Of course, there are also categories, some of which are very standardized and need to be strictly observed. Some of them are relatively loose and do not have to be strictly observed.

Can we talk about the example of Q3:docker-compose again?

A3: there is no example of docker-compose in this ppt, but this is easy to understand, because OAM divides Kubernetes API into two categories, one is called Components and the other is called T raits. With such a Componets file, you can directly map the concept of OAM. There is a concept in docker-compose called Service, which actually corresponds to the Component in OAM. This is a complete one-to-one correspondence. There is a Deployment under Service and a deployment strategy, which actually corresponds to the Trait of OAM.

Q4: has the redis that defines Aliyun been implemented?

A4: it has been implemented, but the functionality is limited. A more powerful feature has been implemented internally to create all the resources of Ali Cloud through OAM. At present, this is done in Crossplane. But the more complete internal implementation has not yet been fully released. We are still planning to expose it through a way called Alibaba Opreator.

Q5: whether it is understandable that OAM packages Components and Traits by managing metadata and writing CRD.

A5: it can be said to be right. You classify or encapsulate your CRD or the CRD in the community and expose it to users. So users only need to understand two concepts-Components and Traits. The content of Components is determined by your CRD, so this is a relatively lightweight abstraction.

Q6: suppose there are four Components and five Traits, can it be understood that there are 20 encapsulation capabilities?

A6: that's not how it works. No matter how many Components and Trait there are, how many abilities ultimately depend on the actual CRD you sign up for. Components and Traits are decoupled from the capabilities behind them.

Can Q7:OAM be generated using Kustomize?

A7: of course, Kustomize makes it a tool for manipulating yaml files. You can use this tool to generate any yaml file you want, or you can use other files, such as another google project called kpt, such as you use DSL,json. All tools that can manipulate yaml files can manipulate OAM files, and the yaml file of OAM is no different from the yaml in normal K8s. To K8s, OAM is nothing more than a CRD.

Is Q8:OAM available for production?

A8: there are several points here, and OAM itself is divided into two parts. The first part is the specification, which is in the alpha version, and plans to release the beta version within 2020. Beta is a stable version, which is a relatively clear plan. The current spec is likely to change, but there is another version called the oam-kubernetes-runtime plug-in, which operates as a stand-alone project and plans to release a stable version in Q3. Even if my spec changes, but the plug-in will be backward compatible to ensure that spec changes will not affect your system, our runtime will release a stable version ahead of time, which should be relatively fast. If you build a platform, it is recommended that you use runtime first.

Is there any stability consideration for Q9:OAM? For example, high availability.

A9: there is. At present, the runtime project is doing a lot of stable things, which is a demand within Ali and Microsoft. This piece is all being done, and there must be some consideration in this respect, including a coverage of the boundary conditions.

Q10: can you tell me how many Pod are supported in Singles Day holiday?

A10: this number will be relatively large, probably on a scale of more than one hundred thousand, and the number of application containers is also large. This is not of great reference value to everyone, because Ali's architecture and applications are different from what most students see, most of them are a monolithic framework, and the micro-services of each application are very detailed. The number of pod and the number of containers are very large.

Q11: at present, there are only Ali and Microsoft in OAM. Will big companies like google join in the future?

A11: I'm sure it will. The next plan will introduce new partners. Currently, both google and aws have some community support for OAM. As a specification of cloud origin, there are also some ideas. In the early days, the speed at which big factories join will be relatively slow, and what is more desirable is for users to use it. Big companies are not necessarily the main users of OAM, they are more commercial considerations.

Will Q12:OAM be associated with Mesh?

A12: certainly, but it doesn't mean that Mesh is a core capability, but it is more used as an OAM trait, such as describing the topological relationship of a traffic.

Q13:OAM 's highly available solution?

A13:OAM itself is a stateless service, and its own highly available solutions are not very complex.

Does Q14:OAM consider single cluster or multi-cluster?

A14: at present, it is a single cluster, but we will also release a multi-cluster model soon, which is already a multi-cluster model within Ali. To put it simply, multi-cluster is a two-tier model. The concept of multi-cluster is defined in Scope, and Scope is used to determine which cluster Workload or Components is placed in. We'll release it in the community as soon as possible.

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.