This article explains solutions for the admission controllers lab, detailing steps, commands, and configuration snippets.
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.
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.
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 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:
Copy
Ask AI
root@controlplane ~ ➜ kubectl exec -it kube-apiserver-controlplane -n kube-system -- kube-apiserver -h | grep 'enable-admission-plugins'--enable-admission-plugins strings admission plugins that should be enabled in addition to default enabled ones (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, VolumeClasses, CertificateApproval, CertificateSigning, CertificateSubjectRestrictions, DefaultIngressClass, DefaultTolerations, CertificateExemption, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota).
Since “namespace auto-provision” is missing from the default list, it is the correct answer for the question.
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:
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:
Copy
Ask AI
root@controlplane ~ ➜ kubectl run nginx --image nginx --rm
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:
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
As you can see, the blue namespace is automatically created due to the enabled NamespaceAutoProvision admission 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:
Copy
Ask AI
ps -ef | grep kube-apiserver
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.
