In-depth Demystification of Alibaba Cloud Serverless Kubernetes

Story, starting with Docker

Although the story begins with Docker, we cannot ignore the efforts of the ancestors of IaaS (Infrastructure as a Service) to overcome the difficulties ahead, as well as the cloud computing development plan that has been determined long ago by cloud computing leaders.

More than a decade ago, ancestors divided the cloud into three layers based on the dimension of user usage (cloud platform providing capabilities):

• IaaS: Infrastructure as a Service, which provides virtual machines or other basic resources as services to users;

• PaaS: Platform as a Service, which provides the platform as a service to users, such as on-demand access to various middleware services on the platform;

• SaaS: Software as a Service, which provides applications to users as services, such as email services.

As shown in the figure below, from IaaS to PaaS, users (development and operation and maintenance) are less and less aware of basic resources and more focused on the business.

Let professional people do professional things to maximize overall efficiency. For example, a start-up internet grocery company does not need to build computer rooms, purchase hardware, configure network storage, and install operating systems on its own, but rather should focus on business development and operation.

After more than ten years of development, IaaS has become relatively mature, and various basic resources, such as ECS, VPC, and EBS, have been deeply rooted in the hearts of the people, but the development of PaaS is very slow.

As early as 2008, Google launched the App Engine service to create a development platform that allows developers to write business code and run on the App Engine. This idea is too advanced for developers to fully accept. In addition to the public cloud, the open source community PaaS platform is also moving from left to right. Among them, IBM's Cloud Foundry and Redhat's OpenShift are the most famous. They both hope to provide a platform for rapid release of applications, but both are tepid and increasingly difficult to use due to various compatibility issues.

Until the birth of Docker in 2013, a fully developer friendly, one command can pull up a service, and an extremely simple operation method made Docker one of the most popular open source projects in the community.

The advantages of Docker are mainly reflected in: Docker images package the environment and applications that should be relied on into a compressed file, which can be directly run on any machine with Docker installed, solving the deployment issues of applications from development, testing, to production, and ensuring environmental consistency.

Docker's success lies in its ultimate simplicity rather than technological innovation. Technologies such as cgroup and namespace have long been incorporating kernel features. Therefore, Cloud Foundry did not consider Docker a competitor earlier, as these technologies have long been used on Cloud Foundry. On the contrary, the unintentional function of Dcoker mirroring allows Docker to truly achieve "Build once, Run anywhere".

Kubernetes determines the status of the Jianghu

The original Docker was a stand-alone version, requiring a management platform for large-scale deployment scenarios, just like OpenStack managing VMs.

In the early days, container management platforms were also contested by a hundred schools of thought, such as Mesos and Swarm. However, none of them deviated from the inherent thinking of IaaS and remained focused on managing containers as virtual machines. It was not until the emergence of Kubernetes that he truly began to unify the Jianghu. In addition to Google's endorsement and mature architecture derived from Borg, what's more important is that Kubernetes has already figured out how to manage containers (Replica sets) and provide services externally (services) since its inception.

Among them, the most regrettable is Docker's own management system, Swarm. At that time, Docker had already emerged, but the Docker company itself had not achieved profitability. So the company launched Swarm Enterprise Edition. Although Swarm also introduced a lot of Kubernetes concepts in the later stage, but the trend has gone, and the cloud native ecosystem has flourished around Kubernetes.

Although dominated by Google, Kubernetes maintains sufficient openness and abstracts resource management from interface specifications, such as CRI for container runtime, CNI for network, CSI for storage, device management Device Plugins, various access controls, and CRDs. Kubernetes is gradually evolving into a cloud operating system, and various cloud native components are system components running on top of this operating system.

Public cloud hosting Kubernetes

Although Kubernetes has established its leadership position, its operation and maintenance are not so easy. In this context, public clouds have tried to launch cloud Kubernetes hosting services, such as Alibaba Cloud's hosting master solution, ACK, in 2017.

In ACK (Alibaba Cloud Container Service for Kubernetes), the installation and operation and maintenance of Kubernetes management components are hosted to the public cloud, using ECS or bare metal as Kubernetes computing nodes, which greatly reduces the cost of Kubernetes users. Users can directly manage the cluster through the kubectl command line or the Restful API by obtaining a kubeconfig file from the cloud platform.

If you need to expand the cluster capacity, you only need to adjust the number of ECSs, and the newly created ECS will be automatically registered with the Kubernetes Master. Not only that, ACK also supports one-click upgrade of cluster versions and various plug-ins. ACK transfers complex operation and maintenance work to the cloud, and with the flexibility of the cloud, it can achieve resource expansion at the minute level.

Carry out free shipping and flexibility to the end

Public clouds pay more attention to costs than private clouds, because in private clouds, users' infrastructure costs are basically fixed, and it is impossible for users to go to the computer room and park a server after offline for a service. In contrast, public clouds provide a pay as you go model.

If most of the tasks running in the cluster are long runs and the resource requirements are fixed, there is no problem using ACK. However, if there are a large number of job type tasks or there is sudden traffic, ACK, a temporary expansion scheme for virtual machines to enable containers on virtual machines, lacks flexibility.

For example, an online education company will temporarily expand the capacity of tens of thousands of Pods during the rush hour of classes at 7-9 pm every day. If you use ACK, you need to evaluate the capacity of these Pods in advance, then convert it to the computing power of the ECS, purchase a corresponding number of computing nodes in advance, and add them to Kubernetes, and also need to release these ECSs after 9 pm, which is very cumbersome.

So, is there a solution that is both compatible with Kubernetes usage and capable of starting Pod in seconds and charging by Pod dimension (ACK charging by Node dimension)?

AWS was the first to propose Fargate, which can be added to the Kubernetes cluster as a Pod dimension without a real node. Alibaba Cloud also launched a similar product ECI (Elastic Container Instance) in 2018. Each ECI is a Pod, but this Pod is hosted on the cloud.

Kubernetes uses ECI in two ways: ASK (Alibaba Serverless Kubernetes) and ACK+Virtual Node. In ASK, the computing node completely becomes a Virtaul node. Virtaul Node is a virtual infinite capacity computing node responsible for ECI lifecycle management. The Virtaul node will be registered in Kubernetes, which is a normal node for Kubernetes. Users only need to submit a native Kubernetes Yaml to create a Pod, which is fully compatible with the use of Kubernetes.

Virtaul nodes can also be mixed with ordinary ACK nodes. Users can schedule long run tasks to ECS nodes to run, and then use the rapid startup of ECI (pulling up the container within 10 seconds) to schedule burst or short cycle tasks to ECI to achieve optimal cost.

Currently, ECI has been adopted by many Internet and artificial intelligence companies. In subsequent articles, we will gradually share several technical issues and challenges encountered by typical users during the migration of ECI.

To summarize, we reviewed the development of containers and k8s from the perspective of technological development today, and we can see that public technology is gradually settling to the bottom layer. Both k8s and ServiceMesh are trying to sink service management and traffic management into infrastructure, respectively. However, these components themselves also have management costs, so they have evolved into cloud hosting. In the future, as technology sinks, the capabilities provided by cloud computing will continue to move upward, providing more comprehensive and rich capabilities, allowing development to focus on the business.