Soul torture, what is the business value of Kubernetes?

The topic of today’s talk is related to application management or cloud native application delivery. First we want to answer the question: why do we build an application management platform based on Kubernetes?

The picture above is an essential problem that we often encounter in landing K8s. In particular, our business side will ask the question, what is the business value of us on Kubernetes? At this time as our K8s engineers are often difficult to answer. Why? In fact, this is related to the positioning of K8s. As for the K8s project, if we do an analysis, we will find that K8s is not a PaaS or application management platform. In effect, it is a standardized capability access layer. What is the capability access layer? You can take a look at the picture below.

What is really exposed to the user through Kubernetes is a set of declarative apis, both Pod and Service, that are abstractions of the underlying infrastructure. For example, Pod is an abstraction from a set of containers, while Deployment is an abstraction from a set of PODS. Service, as the Pod access point, is actually an abstraction of cluster infrastructure: network, gateway, and iptables. Node is an abstraction of the host. Kubernetes also provides Custom objects that we call CRDS (Custom Resources). An abstraction that allows you to customize the underlying infrastructure.

And these abstractions themselves, or apis themselves, are implemented through another pattern called controllers. The controller drives our underlying infrastructure toward my abstraction, or an end state that satisfies my abstract definition. So essentially, Kubernetes focuses on “how standardized access comes from the underlying capabilities, whether container, virtual machine, load balancer, and so on, and then exposes it to the user through declarative apis.” This means that the actual users of Kubernetes are not business r&d, nor are they business operations. Who is that? It’s our platform developer. I hope the platform developers can do the upper framework or platform based on Kubernetes. As a result, our business r&d and business operations today don’t feel very friendly to the layer of abstraction that Kubernetes directly exposes.

The key point here is that Kubernetes abstractions these infrastructures from a completely different perspective than business r&d and business operations view systems. This level of abstraction is also different from the level of abstraction desired by business R&D and business operations. The semantics are completely wrong, and there is a huge gap in usage habits. So in order to solve such a problem, are thinking about some solutions. How can the infrastructure abstraction provided by Kubernetes satisfy one of my business research and development and business operations? How can Kubernetes become a preferred platform for business development and operations?

If all of us are Kubernetes experts, then of course we will like the service Kubernetes provides to me. Here I send him a PhD of Kubernetes. Here I strongly recommend aliyun and CNCF to host the cloud native technology open class. See if you can become a Kubernetes expert after you finish this course. This method has a high threshold, because everyone has different levels of interest in the system itself and different learning abilities.

The common approach in the industry is to build a user-oriented application management platform based on Kubernetes, or a PaaS, some people directly make a Serverless.

So how do you do that? On top of Kubernetes, it will build something called the upper application management platform, which exposes an upper API for business research and development and business operation and maintenance. For example, on the business development side, it is less likely to expose abstractions such as Pod and Deployment. It just exposes the CI/CD pipeline. Or an application, WordPress, an external website, exposes this kind of upper level concept, this is the first part.

Second, it also exposes a set of operational apis to business operations. For example: horizontal expansion, release policy, batch policy, access control, traffic configuration. One advantage of this is that the API for business development and operation is not Kubernetes’ underlying API, not Node, not Service, not Deployment, not our CRD. This is a set of abstracted and encapsulated apis. This kind of business development and business operation would fit into the Ops pipeline he expected, and it would have a natural connection with the physical examination it was familiar with.

So only by doing that can we tell our business leaders that Kubernetes has value. In fact, the business value is not in the Kubernetes layer, but in the layer above Kubernetes –” your solution “. So when such a system is built, it is actually another layer of encapsulation for Kubernetes. A lot of companies have it, like Kubernetes. This is a very common practice. It would be more realistic for us to make r&d operations Kubernetes experts.

But whether we are in Ali or in the actual scene in many communities, it often comes with this question. The problem is: today Kubernetes ecology is very, very prosperous, the following is my CNCF cut of the map, hundreds of projects, thousands of can let us Kubernetes plug and play ability. Istio, KEDA, Promethues and so on are all plug-ins of Kubernetes. It is based on such a highly extensible declarative API architecture that the Kubernetes ecosystem thrives. So you can think of Kubernetes as unlimited and very powerful.

But such an unlimited capability, if to receive a very traditional, very classic application management platform. For example, on our PaaS, Cloud Foundry. An immediate problem is that PaaS provides a user-friendly API, but the API itself is limited and difficult to extend. For example, Cloud Foundry has a Buildpack concept for users, not all of Kubernetes’ capabilities. Almost all PaaS have this problem. What it exposes is a user API that is not extensible and is a finite set.

Below is a very large and prosperous Kubernetes ecosystem that cannot be directly exposed to users. You may need to iterate over your PaaS and redeliver your PaaS with every plug-in you use. This is hard to accept.

This problem is a pervasive one that we call the “capability dilemma” of traditional PaaS.

What does this dilemma mean in essence? There is a traditional PaaS between the diverse application infrastructure capabilities of the K8s ecosystem and the growing application management demands of business developers, which can become a bottleneck. The unlimited capabilities of K8s are not immediately available to your R&D and operations. So traditional PaaS can be an obvious bottleneck. This gives me a thought: can we abandon a practice of traditional PaaS and build a highly scalable application management platform based on K8s? How can we provide seamless penetration of K8s capabilities to users, while providing traditional PaaS with a more user-friendly experience for R&D operation and maintenance? There’s another way to think about it: how to build a highly scalable application management platform based on K8s is the same as how to build an “application-centric” Kubernetes. Or can it be encapsulated based on Kubernetes, so that it can be used for my actual users like PaaS? That’s what we’re talking about.

Feature 1: Exposes upper-level semantics and abstractions for end users through a native declarative API and plug-in architecture

We are not talking about putting a PaaS on Kubernetes, or a big hat, and not doing this. Because K8s itself is extensible, we can write a set of CRDS to put the API we want on it. For example, CI/CD pipeline can be used directly like Tektong system. Applications can also be exposed directly through some projects. You can install an Operator to solve problems in the release and expansion of the o&M side. Of course, some technology is needed to bind these operations and maintenance policies to the application or pipeline. This is our first point. Application-centric K8s is primarily about semantics and apis exposed to the user, rather than very low-level things like Services, Nodes, or Ingress. Maybe the user doesn’t even know what it means or how to write it.

Feature 2: Upper level semantics and abstractions are pluggable and extensible, without abstraction level lock-in and any capability limitations

The second important point is that the upper semantics and abstractions must be pluggable, extensible, and seamlessly compatible with the extensibility of K8s. Nor should there be a lock on the level of abstraction.

For example, an application can itself be Deployment, which is a low level of abstraction. It can also be a Knative Service, which is a relatively high level of abstraction and relatively simple compared to Deployment, with only one PodTemplate. It could be even simpler, it could be a Service, or it could be a Function. This is a high level of abstraction. If you build an application-centric framework based on K8s, it should be able to expose multiple levels of abstraction in the workload. Instead of using Knative alone, only the Knative Service is exposed. If I wanted to deploy a Statefulset using Knative, of course I couldn’t. The degree of abstraction is completely inconsistent. So I want this application-centric K8s to be non-abstract-locked.

There should also be no limits to what you can do. What are limits to what you can’t do? On the o&M side, for example, there are many, many expansion strategies, release strategies, etc. If I wanted to add a new policy capability, it should be very simple, just like installing an Operator in K8s, it could be done by helm Insatll, the answer is a must. If you need to add a horizontal expansion, helm install VPA directly can solve this problem. This is the way to make an application-centric Kubernetes.

You can see that it’s very different from our traditional PaaS, and it’s very, very scalable. It is essentially a K8s, but it is also different from proprietary services, Knative, and OpenFaaS. It does not lock the level of abstraction into a Workload; your Workload can be defined at will. The capabilities of the operation and maintenance side can also be defined at will and pluggable. This is what we call an application-centric Kubernetes. So what does a Kubernetes do?

We will explain how to build “application-centric” Kubernetes in more detail in the next article. And building such a user-centric Kubernetes requires several levels of work.

Author: Alibaba Cloud native assistant

The original [link] (https://yq.aliyun.com/articles/769933?utm_content=g_1000170483)

This article is the original content of Aliyun and shall not be reproduced without permission.