This article reviews lab solutions related to admission controllers, analyzing questions, demonstrating validation techniques, and showing manifest file edits for specific configurations.
In this article, we review the lab solutions related to admission controllers. We will analyze several questions, demonstrate validation techniques using command-line operations, and show manifest file edits to enforce specific configurations.
The first question asks which task admission controllers do not perform. The correct answer is that they do not handle user authentication. Admission controllers come into effect after authentication, enforcing policies by validating or mutating resources.
The output confirms that while plugins such as mutating and validating admission webhooks are present, the “namespace auto-provision” admission controller is absent. This controller is therefore not enabled by default.
From this configuration, it is clear that the “NodeRestriction” plugin is enabled, even though it is not typically activated by default in standard configurations.
Question 4: Creating an NGINX Pod without Pre-Creating the Namespace
In this task, we create an NGINX pod in a non-existent namespace called “blue.” This operation will help us understand how Kubernetes responds when the specified namespace is missing.Execute the following command:
Copy
Ask AI
kubectl run nginx --image nginx --namespace blue
Since the “blue” namespace does not exist, the command returns an error:
Copy
Ask AI
Error from server (NotFound): namespaces "blue" not found
This error occurs because the “namespace exists” admission controller (enabled by default) rejects requests for non-existent namespaces. To enable automatic creation of missing namespaces, the Namespace Auto-Provision admission controller must be activated.
Question 5: Disabling the Default Storage Class Admission Controller
The final task involves disabling the default storage class admission controller. This is accomplished by modifying the API server manifest.
Open the file /etc/kubernetes/manifests/kube-apiserver.yaml.
Directly after the --enable-admission-plugins flag, add the disable flag for the DefaultStorageClass plugin (--disable-admission-plugins=DefaultStorageClass) as shown below:
Ensure you allow the API server sufficient time to restart after making these changes. Validate the changes by checking the status of pods and namespaces.
After the API server restarts, test the configuration with:
Copy
Ask AI
kubectl run nginx --image nginx -n bluekubectl get ns
A successful pod creation and the updated namespace list confirm that the default storage class admission controller is disabled.Example command-line output:
Copy
Ask AI
root@controlplane ~ ➜ kubectl run nginx --image nginx -n bluepod/nginx createdroot@controlplane ~ ➜ kubectl get nsNAME STATUS AGEblue Active 7sdefault Active 50mkube-node-lease Active 50mkube-public Active 50mkube-system Active 50m
Identified the function of admission controllers and clarified that they do not manage user authentication.
Determined which admission controllers are enabled by default.
Enabled the Namespace Auto-Provision admission controller to automatically create namespaces.
Disabled the default storage class admission controller through modifications to the API server manifest.
This concludes the Admission Controllers Lab for the 2025 updates. For additional Kubernetes configuration guides, please refer to the Kubernetes Documentation.
