Shulou(Shulou.com)06/01 Report--

This article mainly explains "what is the demand of Kubernetes operation and maintenance". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the demand of Kubernetes operation and maintenance".

1. The ability of operation and maintenance is numerous, but it is difficult to manage.

The CRD Operator mechanism of K8s is very flexible and powerful. Not only complex applications can be realized by writing CRD Operator, but our operation and maintenance capabilities are also greatly expanded through Operator, such as grayscale publishing, traffic management, flexible capacity expansion and so on.

We often admire the flexibility of K8s, which makes it very convenient for our basic platform team to provide external capabilities, but it becomes a bit difficult for application operators to use the operation and maintenance capabilities we provide.

For example, if we launch a CronHPA, you can set the range of the number of instances that will be adjusted according to the CPU at each stage. Application OPS does not know that there will be conflicts with native HPA without timing feature, and we do not have a unified channel to help manage so many complex expansion capabilities, which naturally leads to failures. This bloody lesson reminds us to check before doing things, and being familiar with the mechanism of K8s can easily make us think of adding admission webhook to every Operator.

This admission webhook needs to get all the operation and maintenance capabilities bound to the application as well as the operation mode of the application itself, and then make a unified verification. If these operation and maintenance capabilities are provided by one party, and if there are expansion capabilities provided by two or even three parties, we do not have a unified way to know.

In fact, if we think further, we need a unified model to negotiate and manage these complex scalability capabilities.

two。 Cloud resources are difficult to describe and deliver uniformly

When we have written the Operator of the application and the corresponding operation and maintenance capabilities, it is easy for us to package and deliver the application, so that both public and proprietary clouds can interact in a unified way. At present, the mainstream way of the community is to use Helm to package applications, and we also use this way to deliver to our users, but find that our users need much more than that.

Cloud native application has a great feature, that is, it often depends on cloud resources, including database, network, load balancing, cache and other resources.

When we use Helm packaging, we can only target K8s native API, but it will be more difficult if we still want to start the RDS database. If you don't want to go to the interactive page of the database and want to manage it through the API of K8s, you have to write a CRD to define it, and then use Operator to call the API of the actual cloud resource.

This complete set of deliverables is actually a complete description of an application, what we call an "application definition". But in fact, we found that the "application definition" is actually missing in the entire cloud native community. This is why many teams within Alibaba began to try to design their own "application definition".

In this way, all the configurations will eventually be stacked in one file, which is the same or even more serious as the problem with K8s API all-in-one. Moreover, these application definitions eventually become black boxes, in addition to the corresponding project itself can be used, other systems can not be reused, naturally can not make multi-party cooperative reuse.

3. Each company and team are defining their own applications.

In fact, almost every company and team that manages applications based on K8s are defining their own applications. As shown below, I found the application definitions of the two companies:

Application definition is actually an integral part of application delivery / distribution. However, in practice, we feel that these internal application definitions are faced with the following problems:

Is the definition open enough and reusable?

How to collaborate with open source ecology?

How to iterate and evolve?

The challenges posed by these three questions are enormous. As I mentioned above, an application definition needs to be easy to use, but flexible, let alone a black box. Application definition also needs to be closely integrated with open source ecology. Application definition without ecology is doomed to have no future, and it is naturally difficult to continuously iterate and evolve.

Distinguish between user's hierarchical model and modular encapsulation

Let's go back and re-examine the challenges we face. in the final analysis, the All in One API of K8s is designed for platform providers, and we cannot let application development, operations and maintenance face this API like the K8s team, as shown on the left side of the figure below.

A reasonable application model should have a hierarchical structure that distinguishes the roles of users and modularizes the ability of operation and maintenance. Let different roles use different API, as shown on the right side of the figure above.

Thank you for your reading, the above is the content of "what is the demand of Kubernetes operation and maintenance". After the study of this article, I believe you have a deeper understanding of what the demand of Kubernetes operation and maintenance is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.