I have been free recently, and I plan to learn the core components of Knative, Serving. I will continue to use the k8s source code learning method. I can see the leopard from small to big, and learn the main goals of Serving: observability infrastructure, automatic scaling, traffic management and other core components The design and implementation of the
1. Building a single application based on cloud native
Most of the company's services may have evolved into the popular microservice architecture through monolithic and SOA. Microservices bring us conveniences such as independent evolution, expansion, collaboration, and data autonomy, as well as stability and stability. For practical issues such as sexual security, maintenance, and service governance, let's come back to the single unit today. For example, if we want to open a new business and add a new small module, how does it work in the cloud-native scenario?
1.1 Monolithic application under cloud native
There are many big guys in cloud native and there are many explanations. I simply understand that it is built based on the cloud. It can use all the known existing services on the cloud, and enjoy the elasticity, pay-as-you-go, high-end services brought by the cloud. Native capabilities in terms of availability
A basic monolithic application usually relies on the following components: persistent data storage, high-performance caching, full-text indexing, message queues and other common components. Most cloud vendors will include these basic services, and we only need to introduce the corresponding The class library can complete our application logic, and then the program completes the coding of the code, and the next step is to deliver
1.2 Cloud-native delivery based on k8s
The cloud native based on k8s has become a de facto standard. The code and application data are packaged into docker images. The Pod-based delivery mode allows us to not pay attention to whether we use the physical machine in the IDC or the cloud of the public cloud. service, we only need to package it into a docker image, and then set the configuration data of the schedule environment, our single application can run, but usually we have some non-business requirements, such as monitoring, logs, etc., we will come to the next section solve these problems
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 going online. In the cloud-native environment based on k8s, a sidecar is usually used to achieve this. The enhancement of this basic function, by embedding a sidecar container to complete the reuse of this basic component, can realize basic functions such as logging, monitoring, distributed tracing, Https support, etc. based on the sidecar mode, and let the upper-layer application only focus on the realization of business logic
1.4 Service as Infrastructure
In a company, a business usually accesses some internal systems of the company, such as user, payment, operation and other services. If the company's services can also be treated the same as the 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 assumptions, we have built a basic single application. The application only needs to focus on the writing of application logic. All business logic is coupled in one application, and the rest of the infrastructure and non-business requirements are all implemented by other components. The next step is to deploy. Usually, we need to allocate a Pod configured by XHXG, and then we may need N replicasets for high availability. Then we will automatically scale under the HPA experience. After running for a while, we may find that it may be two times a day. The traffic of a slap, but still occupies the resources of N*XHXG, from this perspective, let's enter our today's theme Knative
2.Knative
Knative is still changing, and some design documents are not open to the public. It is more difficult to read than k8s, but the overall code size is relatively small. In the subsequent articles, we will still take a look at the leopard and read the code component by component. , but because there is no related Proposal, I mainly refer to the relevant articles of the Great God of Winter Island to read the code. It is just a personal understanding. If there is something wrong, please advise. Next, let's see how knative completes the functions and implementations mentioned above. Allocate key components as needed, we will introduce each component in turn starting from the traffic entry
2.1 Implementation of north-south traffic control based on Istio
In k8s, the north-south traffic is usually controlled by Ingress, while the implementation of kantive traffic control mainly depends on istio. Istio is a ServiceMesh framework. The integration of Knative with it mainly uses istio's north-south traffic control function. In fact, it is to use the function of ingress corresponding to istio. The main function is divided into the following two parts
2.1.1 Version Deployment Management
Knative supports release strategies such as blue-green and canary. The core of Knative is to use its own revision version management and the routing configuration function of ingress in istio, that is, we can set the corresponding traffic strategy according to our own needs, so as to carry out versioning Release configuration management
2.1.2 Automatic scaling (to zero)
Knative auto-scaling has two characteristics: automatic allocation on demand and scaling down to zero. When allocating on demand, knative can automatically calculate and realize automatic scaling according to the concurrency capability of the application, and the whole is basically in seconds, which is different from HPA , The second is to scale down to zero, that is, the corresponding service container Pod can be killed, but the new incoming request will be allocated immediately without affecting normal access (the initial delay may be relatively high)
2.2 Queue sidecar
I have seen the observability requirements above. Application services can usually be divided into three parts: logging, monitoring, and distributed tracking. In order to achieve these functions, Knative implements the Queue component. The current understanding of its responsibilities is mainly divided into two parts. : Complete observational data collection and access to proxy business containers. The Queue component implements the statistics of the above-mentioned indicators through proxy, and reports the corresponding data to the back-end log/monitoring/distributed tracking service, and also needs to report to the autoscaler Synchronize the current concurrency monitoring in order to realize the automatic scaling function. Queue is mainly a proxy application container, and Kantive supports the feature of scaling down to zero. When scaling down to zero, Knative will use an Activator Pod to replace the Queue and the application container. , thereby reducing the capacity to zero
2.3 Activator
The Activator container is the key to scaling down to zero. When the business container is not accessed, Knative will direct the corresponding ingress traffic to the Activator component. When scaling down to zero, if there is another business request at this time, the Activator will immediately notify the autoscaler Immediately pull up the business container and forward the traffic to the real business container, which can not only complete the lossless forwarding of the traffic, but also realize the payment on demand, and no longer need to start the Pod for the business without traffic. Activator does not Responsible for actual scaling decisions, scaling components are mainly implemented through Autoscaler
2.4 Autoscaler
Autoscaler is the key to automatic expansion in Knative. It calculates the monitoring data passed by the Activator and Queue components and calculates according to the configuration, and dynamically adjusts the number of copies of the business container in real time, thereby realizing automatic scaling.
2.5 Controller
Controller is the controller of Knative's corresponding resources. Its function is similar to the implementation of other components in k8s. It performs consistency adjustment according to the current state and expected state of resources to achieve eventual consistency.
2.6 webhook
Knative is implemented based on the CRD of k8s, and its webhook mainly includes the verification and modification of the corresponding resource data related to admissions.
3. Summary
Combining the above component function conjectures, we can probably guess the implementation of the core data flow. As shown in the figure, we can divide it into five layers to consider: the observation layer (Queue and Activator), the decision layer (Autoscaler), and the control layer (Controller) , admission layer (Webhook), routing layer (Istio INgress), obtain user request data in real time through the observation layer, send it to the decision-making layer for decision-making, and write the decision-making result to the Apiserver, the control layer is aware, and is responsible for updating the corresponding resources Finally, the routing layer perceives and distributes traffic, which realizes the core functions of overall traffic perception, decision-making, routing, etc. I understand these for the time being. I hope that with the deepening of the code, I will have a deeper experience. Good luck, good luck!
Original https://www.yuque.com/baxiaoshi/tyado3/up5efq
WeChat account: baxiaoshi2020
, pay attention to the announcement number to read more source code analysis articles,
more articles follow www.sreguide.com