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

How to analyze the access controller in Kubernetes, I believe that many inexperienced people are at a loss about it. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

What is an admission controller?

Every operation request against a Kubernetes resource object is subject to layers of review by kube-apiserver before it is released. For read operations, you need to be authenticated (whether you are a legitimate user) and authenticated (whether you have permission or not). For write operations, in addition to authentication and authentication, you also need to check that the request meets the requirements. Only if you successfully pass these reviews will it be persisted to etcd storage.

The admission controller (Admission Controller) is a component used to review requests, which hijacks requests to kube-apiserver, reviews requests (and modifies the contents of requests if necessary), is an important part of the kube-apiserver review chain, and unreasonable requests are rejected.

Kube-apiserver supports the configuration of multiple admission controllers, which are divided into modified (Mutating) controllers and check (Validating) controllers. The modified controller automatically modifies the request according to the specified policy, while the validating controller simply checks whether the request meets the requirements and acts as a watchdog.

Multiple admission controllers are organized in the form of plug-ins (Webhook Plugin). When reviewing the request, kube-apiserver will first send the request to the modified controller to make the necessary modifications to the request, and then submit the request to the check controller for review. The following figure shows the full review path of the request and the location of the admission controller:

After the API request arrives at kube-apiserver, authentication (Authentication) and authentication (Authorization) are performed first, and then the request is handed over to the modified admission controller for necessary modifications (multiple modified admission controllers are executed sequentially). When all modified admission controllers are executed, the OpenAPI check function is used for preliminary syntax verification. The request is then handed over to the validating admission controller for syntax or semantic verification (multiple modified admission controllers are executed in parallel), and finally written to etcd. Failure to return any of the above review sessions and any access controller will cause the request to be rejected.

Admission controller configuration

According to its deployment form, admission controller can be divided into two types: built-in controller and dynamic controller. The built-in controller is integrated in kube-apiserver and is provided as a plug-in, each plug-in can be enabled or disabled by parameter control, while the dynamic controller is a service implemented according to a certain standard. More about the dynamic controller will be introduced in the following chapters, this section mainly introduces the configuration method of the built-in controller.

Kube-apiserver provides dozens of admission controller plug-ins, some of which are enabled by default, and which plug-ins can be explicitly controlled by parameters.

Open the controller plug-in

Use the-enable-admission-plugins parameter of kube-apiserver to set the plug-ins that need to be enabled in addition to the controller plug-ins that are enabled by default. The names of multiple plug-ins are separated by commas, for example, the following parameters enable NodeRestriction and ResourceQuota plug-ins.

-- enable-admission-plugins=NodeRestriction,ResourceQuota

This parameter is mainly used when you need to enable plug-ins that are disabled by default.

Close the control plug-in

Disabled controller plug-ins can be set through the-disable-admission-plugins parameter of kube-apiserver, and the same multiple plug-in names are separated by commas, for example, the following parameters turn off the PodNodeSelector and AlwaysDeny plug-ins.

-- disable-admission-plugins=PodNodeSelector,AlwaysDeny

This parameter is mainly used when you need to disable plug-ins that are enabled by default.

After reading the above, have you mastered the method of how to analyze the admission controller in Kubernetes? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

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.