Serverless Kubernetes: Subtract Kubernetes

As a general container arrangement system, Kubernetes bears a wide range of applications and scenarios, including CI/CD, data computing, online applications, AI, etc. However, due to its versatility and complexity, managing a Kubernetes cluster is still full of challenges for many users, mainly reflected in:

Serverless Kubernetes is an exploration of the future evolution direction of Kubernetes by Alibaba Cloud container service team. By subtracting Kubernetes, it reduces the burden of operation and maintenance management, simplifies cluster management, and makes Kubernetes from complex to simple.

We believe that in the future users will focus more on application development than infrastructure maintenance. In the Kubernetes cluster, we want users to focus on the semantics of application orchestration such as pod/service/ingress/job, and less on the underlying node.

No need to manage nodes can significantly reduce the cost of cluster operation and maintenance management. According to statistics, most of the common kubernetes abnormal problems are related to nodes, such as Node NotReady problem. There is no need to worry about the security of Node, as well as the upgrade and maintenance of basic system software.

In ASK cluster, we use virtual node Virtual-Kubelet instead of ECS node, the capacity of virtual node can be considered as “infinite”, users do not need to worry about the capacity of the cluster, there is no need to do capacity planning in advance.

Like the ACK hosted version, ASK’s Master(Apiserver, CCM, KCM, etc.) resources are hosted by the container service platform, so users do not need to manage the upgrade, operation and maintenance of these core components, and there is no cost.

In addition to eliminating the need to manage nodes and masters, kubernetes cluster management has been greatly simplified, including hosting many Adons by default so that users no longer need to manage or pay for basic Adons. Relying on aliyun’s native network and storage capabilities, as well as the unique hosting architecture design, we provide extremely simplified but fully functional Kubernetes basic operating environment.

Aliyun-disk-controller/FlexVolume not required (being supported) CNI network Terway/Flannel Daemonset Not required. Two coreDNS replicas are required for DISCOVERING the COREDNS service based on VPC network communication. Kube-proxy daemonset is required for accessing kube-proxy based on privateZone. Nginx-ingress-controller is not required for accessing the Ingress based on privateZone. Acr-credential-helper is not required for accessing ACR images based on SLB layer 7 forwarding. By default SLS log collection required Logtail daemonset required no deployment, metrics statistics required No deployment metrics- Server required no deployment, out-of-the-box mounting eIP required Terway required no deployment. Aliyun-disk-controller does not need to be deployed, and elastic scaling is supported by default. Cluster-autoscaler does not need to be deployed. GPU plug-in does not need to be deployed

To sum up, an ACK cluster requires at least 2 ECS machines to run these basic Adons, while an ASK cluster reduces these basic Adons to invisible and can create an out-of-box Kubernetes cluster at a cost of 0.

Since there is no need to manage nodes and capacity planning, when the cluster needs to be expanded, it does not need to consider the capacity expansion at the node level, but only needs to pay attention to the capacity expansion of POD, which greatly improves the speed and efficiency of capacity expansion. At present, some customers designate the use of ASK/ECI to quickly cope with business traffic peak.

At present, ASK/ECI supports 30 seconds to fully start 500 pods (to the Running state), and a single POD can be started within 10 seconds.

In addition to the low cost of creating the ASK cluster itself, the on-demand use of POD enables optimal resource utilization in many scenarios. For many Jobs or data computing scenarios, users do not need to maintain a fixed resource pool for a long time. In this case, ASK/ECI can well support these demands.

It has been proved that when pod runs less than 16 hours a day, the ASK/ECI approach is more economical than keeping the ECS resource pool.

When we talk about ASK, we must talk about ECI, the resource base of ASK. ECI is a stable, efficient and highly elastic container instance service provided by Ali Cloud based on ECS IaaS resource pool. ECI makes containers first class citizens of the public cloud. Users can deploy container applications directly without purchasing and managing ECS. This simplified container instance product form and ASK form a perfect combination. Users can directly use THE ECI Open API to create container instance resources, but in the container scenario, users generally need an orchestration system to be responsible for container scheduling, highly available orchestration and other capabilities, and ASK is such a Kubernetes orchestration layer.

For ASK, ECI frees the ASK container service from the need to build a background computing resource pool, let alone worry about the capacity of the underlying computing resource pool. Based on ECI means that based on the whole IaaS scale resource pool of Ali Cloud, it has natural inventory and elasticity advantages (for example, ecS specifications corresponding to the underlying ECI can be specified through annotations, and most ECS specifications can be used in ASK to meet the needs of a variety of computing scenarios). In addition, ECI and ECS reuse of resource pools means that we can maximize the scaling dividend and provide lower cost computing services to our users.

ASK provides complete support for the Kubernetes container ecosystem, and a number of customers are using ASK to support a variety of scenarios.

The original link

This article is the content of Ali Cloud, shall not be reproduced without permission.