Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to analyze the Design of api aggregation Mechanism in kubernetes

2025-02-24 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

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

Today, the editor will show you how to analyze the design of api aggregation mechanism in kubernetes. The knowledge points in this article are introduced in great detail. Friends who feel helpful can browse the content of the article with the editor, hoping to help more friends who want to solve this problem to find the answer to the problem. Follow the editor to learn more about "how to analyze the design of api aggregation mechanism in kubernetes".

There is no doubt that the design of apiserver in kubernetes is complex, and it contains three kinds of api services internally. Today, let's speculate on its internal design and figure out the design essentials of aggregator, apiserver and apiExtensionsServer (crd server).

1. From web service to web gateway to CRD

Apiserver is still quite complicated. today we only discuss the design of its kube-aggregator/apiserver/apiextensions architecture, without paying attention to such as request authentication, admission control, permissions and so on.

1.1 the most basic REST service

A most basic Rest service usually consists of a resource resource and a set of HTTP request methods, which is called a REST in kubernetes and has an embedded Store (which can be understood as inheritance), which provides a collection of all operations for a specific resource, that is, what we often call the implementation of the final execution of the specific operation of the CRUD.

1.2 Service

With Rest, we can provide the management of various resources in K8s, but if I want to expand it, if I want to support some external resources that do not exist in K8s, the easiest way must be to have an external independent service, which manages the logic of data storage, change, control and so on.

1.3 APIAggregator

When expanding cluster resources through external services, how can we integrate such resources into the current apiserver? For this reason, APIAggregator components are designed in K8s (in fact, APIAggreator components also include functions such as proxy back-end services) to realize the integration of external services, so that developers can customize service information without modifying K8s code.

1.4 basic functions of a service

A basic business service usually includes data model, control logic, persistent storage, basic functions (authentication, monitoring, logging, etc.), etc., in order to create a service, we usually need the following operations (excluding the design phase): 1) choose the appropriate framework (complete the basic function) 2) define the data model 3) choose the data store 4) write the business control logic Apart from the business control logic, the rest may be generic in most cases, such as frameworks, data storage, etc., can it be simplified? Let's take a look at the big move CRD.

1.5 CustomResourceDefinitions

CRD is called custom resource type in Chinese, and its core provides data model definition, data storage and basic functions in k8s, so if we want to extend the service, we only need to write a business logic controller. Let's think about its scenario.

Usually, the processing flow of web request is deserialization, validation field, business logic processing, data storage, but in K8s, most of the business control logic is carried out by controller, so the rest of the work must be done in K8s to support CRD.

After we have finished defining the model, the crd module of K8s needs to construct, verify, transform and store the corresponding resource REST, which is undoubtedly resource-consuming, and on the data bus such as apiserver, CRD does not support large-scale data storage.

1.6 CRD server

CRDServer is mainly responsible for the management of CRD resources. It will monitor the changes of CRD resources, create corresponding REST interfaces for them, and complete the corresponding mechanisms such as authentication, transformation, verification, storage and so on.

2. ServerChan

ServerChan is designed to be more similar to a chain of responsibility pattern. To put it simply, if I can't handle the request, I'll leave it to the next person to handle it. This operation is called delegate in K8s, and then we start to understand its key implementation.

2.1 role division of services

So far, we have three server, of which APIAggregator is responsible for the integration of external services and forwarding of internal requests, apiserver service k8s aggregates the control of internal resources, and CRDServer is responsible for the processing of user-defined resources, and then we just need to connect the three together, which is our final apiserver.

2.2 layers of delegation on the responsibility chain

After APIAggregator receives the request, if it is found to be a service request, it will be forwarded directly to the corresponding service. Otherwise, it will be delegated to apiserver for processing. In apiserver, the corresponding REST interface is selected for processing according to the current URL. If the corresponding processing cannot be found, it will be handed over to CRD server for processing. CRD server detects whether the corresponding CRD resource has been registered, and processes it if registered.

2.3 Service registration on APIAggregator

APIAggreagtor listens for changes in the backend Service through informer. If a new service is found, a corresponding proxy forwarding is created to achieve the corresponding service registration.

Resource Awareness in CRD Server

When the corresponding CRD resource is created in the cluster, the corresponding CRD resource information is perceived through the internal controller, and then a corresponding REST processing interface is created for it, so that the corresponding resource can be received later for processing.

3. Basic overview map

Thank you for your reading, the above is the whole content of "how to analyze the design of api aggregation mechanism in kubernetes". Let's get started. I believe that the editor will certainly bring you better quality articles. Thank you for your support to the website!

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report