Skip to main content
In this lesson, we will walk through the solutions for the admission controllers lab, explaining each step and providing the necessary commands and configuration snippets.
The image shows a KodeKloud practice test interface with a question about admission controller functions and a terminal window.

​
Understanding Admission Controller Functions

For the first question, you need to determine which option is NOT a function of admission controllers. The correct answer is “authenticate users” because admission controllers operate after authentication has already taken place; they do not handle user authentication.

​
Verifying Enabled Admission Controllers

The next question asks which admission controller is not enabled by default. To find out, start by listing the pods in the kube-system namespace using the following command:
The image shows a KodeKloud practice test interface with a terminal and a question about which admission controller is not enabled by default.
Next, run this command to check the enabled admission plugins:
The output lists default enabled plugins like NamespaceLifecycle, LimitRanger, ServiceAccount, among others. Notice that “namespace auto-provision” is not listed. Also, verifying the enabled webhooks gives you the following output:
Since “namespace auto-provision” is missing from the default list, it is the correct answer for the question.

​
Identifying Explicitly Enabled Admission Controllers

The following question asks which admission controller is enabled in the cluster but is generally disabled by default. You can inspect the kube-apiserver configuration file located at /etc/kubernetes/manifests/kube-apiserver.yaml to determine the enabled plugins. Use your preferred text editor or run the following search command:
A snippet from the configuration file might appear as follows:
In this configuration, the NodeRestriction admission controller is explicitly enabled, despite normally being disabled.
By inspecting the kube-apiserver configuration, you can verify which admission controllers are enabled and adjust your settings accordingly.

​
Enabling Namespace Auto Provision

The next task is to create an NGINX pod in the “blue” namespace. However, the lab specifies that the “blue” namespace has not been created yet. Attempting to run the following command:
results in an error because the exists admission controller rejects requests for non-existent namespaces. To automatically create the namespace during pod creation, enable the NamespaceAutoProvision admission controller. Edit the /etc/kubernetes/manifests/kube-apiserver.yaml file and update the --enable-admission-plugins flag. Insert NamespaceAutoProvision after NodeRestriction (separated by a comma). The updated configuration should look similar to this:
After saving and allowing the API server to restart, create the NGINX pod in the blue namespace:
As you can see, the blue namespace is automatically created due to the enabled NamespaceAutoProvision admission controller.

​
Disabling the Default Storage Class Controller

The final task is to disable the default storage class admission controller. To do this, update the /etc/kubernetes/manifests/kube-apiserver.yaml file by adding the --disable-admission-plugins flag on a new line immediately after the enabled plugins. For example:
Once the API server restarts, validate the changes by inspecting the running process with a command like:
This command will list both the enabled and disabled admission plugins.
With these steps, you have successfully completed the admission controllers lab by understanding plugin functions, verifying defaults, enabling automatic namespace creation, and disabling unwanted admission controllers.

Watch Video