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

Today I will show you how to analyze the basic design of Serving, the core component of Knative. The content of the article is good. Now I would like to share it with you. Friends who feel in need can understand it. I hope it will be helpful to you. Let's read it along with the editor's ideas.

Recently, I intend to study Serving, the core component of Knative, and will continue to use K8s source code to learn. The main goal of learning serving is the design and implementation of observable infrastructure, automatic scaling, traffic management and other core components. Today, let's make a simple guess. If you are interested, let's learn together.

1. Monomer Application Construction based on Cloud Native

The services of most companies may have evolved from monomer and SOA to the popular micro-service architecture. Micro-services have brought us the convenience of independent evolution, expansion, collaboration and data autonomy, as well as practical problems such as stability assurance, maintenance, service governance and so on. Let's return to the monomer today, for example, we are going to open a new business and a new small module. How do you play in the cloud native scene?

1.1 monomer applications under the original cloud

Cloud native has many bosses and many explanations. I simply understand that it is built on the cloud and can use all the known existing services on the cloud. At the same time, enjoy the flexibility, pay-on-demand, high availability and other native capabilities brought by the cloud.

A basic monolithic application usually relies on the following components: persistent data storage, high-performance caching, full-text indexing, message queuing and other common components. Most cloud vendors include these basic services. We only need to introduce the corresponding class library to complete our application logic. Then the program completes the coding of the code, and the next step is to deliver.

1.2 Native cloud delivery based on K8s

K8s-based cloud native has become a de facto standard, packaging code and application data into docker images and Pod-based delivery models, so that we don't need to pay attention to whether we use physical machines in IDC or cloud services in public clouds, we just need to package them into docker images, and then set up the configuration data of the scheduled environment. Our single application can run, but usually we have some non-business requirements, such as monitoring, logging, etc., which we will solve in the next section.

1.3 sidecar mode

In the early stage of application development, we may not consider the observability requirements of monitoring and logging, which are usually considered when we go live. However, in a cloud native environment based on K8s, we usually use a sidecar to enhance this basic function and reuse this basic component by embedding a sidecar container. The basic functions such as logging, monitoring, distributed tracking and Https support can be implemented based on sidecar mode, while the upper layer applications only focus on the implementation of business logic.

1.4 Services as infrastructure

In a company, a business usually accesses some internal systems, such as users, payment, operations, etc., if the company's services can be treated in the same way as infrastructure, and these services can also be delivered in the form of k8s, then we can only focus on the expansion of the single application itself (small foreground).

Through the above assumption, we have built a basic single application. The application only needs to pay attention to the writing of the application logic, all the business logic is coupled in one application, and the rest of the infrastructure and non-business requirements are all implemented by other components. Then it is time to deploy. Usually we need to allocate a Pod configured by XHXG, and then we may need N more replicaset for high availability. Then we have a HPA experience of automatic scaling. After running for a period of time, we may find that there may be only two slaps a day, but it still takes up the resources of N*XHXG. From this point of view, let's enter our topic Knative today.

2.Knative

Knative is still constantly changing, and some design documents are not open to the public, which is more difficult to read than K8s, but the overall code volume is also less. In the follow-up articles, we still take a peek in the following articles and read the code component by component, but because there is no relevant Proposal, we mainly refer to the relevant articles of the Winter Island God to read the code, just personal understanding, if there is something wrong, welcome to comment. Next, let's take a look at how knative accomplishes the above-mentioned functions and implements the key components of allocating on demand. Let's start with the traffic entry and introduce each component in turn.

2.1 Management and control of north-south flow based on Istio

In K8s, north-south flow is usually controlled by Ingress, while the implementation of kantive traffic control mainly depends on istio. Istio is a ServiceMesh framework, and its integration in Knative mainly uses the north-south flow management and control function of istio. In fact, it uses the function of ingress corresponding to istio, and the main functions are divided into the following two parts

2.1.1 deployment Management

Knative supports blue-green, canary and other release strategies, and its core is through its own revision version management and the routing configuration function of ingress in istio, that is, we can set the corresponding traffic policy according to our own needs, so as to manage the release configuration of the version.

2.1.2 automatic scaling (to zero)

Knative automatic scaling has two characteristics: automatically allocate and scale down to zero on demand, and knative can automatically calculate and realize automatic capacity expansion according to the concurrency ability of the application, and the whole is basically seconds, which is different from HPA. The second is to scale down to zero, that is, the corresponding business container Pod can be killed, but it will be allocated immediately after the new request. Does not affect normal access (perhaps the initial delay will be relatively high)

2.2 Queue sidecar

Observability requirements have been discussed above, which can be divided into three parts in application services: logging, monitoring and distributed tracking. In order to achieve these functions, Knative implements Queue components. At present, its responsibility is mainly divided into two parts: to collect observational data and to access the proxy business container. The Queue component implements the statistics of the above-mentioned indicators through the agent, and reports the corresponding data to the back-end log / monitoring / distributed tracking service. At the same time, it also needs to synchronize the current concurrency monitoring with autoscaler in order to achieve automatic scaling function. Queue mainly acts as a proxy application container. Kantive supports scaling down to zero. When scaling down to zero, Knative will use an Activator Pod instead of Queue and application container. So as to reduce the capacity to zero.

2.3 Activator

The Activator container is the key to reducing the capacity to zero. When the business container is not accessed, Knative will direct the corresponding ingress traffic to the Activator component. When the container is reduced to zero, if there is a business request at this time, Activator will immediately inform autoscaler to pull up the business container immediately and forward the traffic to the real business container. In this way, it can not only achieve lossless forwarding of traffic, but also achieve on-demand payment, and no longer need to be for businesses without traffic traffic. Pod has been started all the time. Activator is not responsible for the actual scaling decision. Scalable components are mainly implemented through Autoscaler.

2.4 Autoscaler

Autoscaler is the key to automatic capacity expansion in Knative. Through the monitoring data transmitted by Activator and Queue components and calculated according to configuration, it adjusts the number of copies of the business container in real time and dynamically, so as to achieve automatic scaling.

2.5 Controller

Controller is the controller of the resource corresponding to Knative, and its function is similar to that of other components in K8s. It adjusts the consistency according to the current state and expected state of the resource, thus achieving the final consistency.

2.6 webhook

Knative is implemented based on CRD of K8s, and its webhook mainly includes admission correlation such as verification and modification of corresponding resource data.

3. Summary

Combined with the above component function conjecture, we probably guess the implementation of the core data flow. As shown in the figure, we can be divided into five layers to consider: observation layer (Queue and Activator), decision layer (Autoscaler), control layer (Controller), access layer (Webhook), routing layer (Istio INgress). The user request data is obtained in real time through the observation layer, sent to the decision layer for decision, and the decision result is written to Apiserver, and the control layer perceives it. Responsible for updating the corresponding resources, and finally perceived by the routing layer, traffic distribution, so as to achieve the overall traffic perception, decision-making, routing and other core functions.

The above is how to analyze the whole content of Knative core component Serving basic design, more content related to how to analyze Knative core component Serving basic design can search the previous article or browse the following article to learn ha! I believe the editor will add more knowledge to you. I hope you can support it!

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.