> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # 2025 Updates Solution Admission Controllers > 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. *** ## Question 1: Function of Admission Controllers 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. *** ## Question 2: Enabling the Default Admission Controllers The next question examines which admission controller is not enabled by default. To determine this: 1. **List the control plane pods** in the kube-system namespace: ```bash theme={null} root@controlplane ~ ➜ kubectl get pods -n kube-system NAME READY STATUS RESTARTS AGE coreDNS-74ff55c5b-88v8r 1/1 Running 0 38m coreDNS-74ff55c5b-tng7p 1/1 Running 0 38m etcd-controlplane 1/1 Running 0 38m kube-apiserver-controlplane 1/1 Running 0 38m kube-controller-manager-controlplane 1/1 Running 0 38m kube-flannel-ds-wzlpx 1/1 Running 0 38m kube-proxy-hccb9 1/1 Running 0 38m kube-scheduler-controlplane 1/1 Running 0 38m ``` 2. **Inspect the kube-apiserver pod** (e.g., `kube-apiserver-controlplane`). Execute a shell inside the pod and search for the enabled admission plugins: ```bash theme={null} kubectl exec -it -n kube-system -- kube-apiserver -h | grep "enable admission plugins" ``` 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. *** ## Question 3: Admission Controller Enabled by Default (But Normally Disabled) This question asks which admission controller is active in the cluster that is usually disabled by default. To answer: 1. Open the kube-apiserver configuration file at `/etc/kubernetes/manifests/kube-apiserver.yaml`. 2. Run the following command to locate the admission plugin configuration: ```bash theme={null} kubectl exec -it -n kube-system -- grep enable-admission-plugins /etc/kubernetes/manifests/kube-apiserver.yaml ``` You should see an output similar to: ```yaml theme={null} apiVersion: v1 kind: Pod metadata: annotations: kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 10.49.219.9:6443 labels: component: kube-apiserver tier: control-plane name: kube-apiserver namespace: kube-system spec: containers: - command: - kube-apiserver - --advertise-address=10.49.219.9 - --allow-privileged=true - --authorization-mode=Node,RBAC - --client-ca-file=/etc/kubernetes/pki/ca.crt - --enable-admission-plugins=NodeRestriction - --enable-bootstrap-token-auth=true - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key - --etcd-servers=https://127.0.0.1:2379 - --insecure-port=0 - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt ``` 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: ```bash theme={null} kubectl run nginx --image nginx --namespace blue ``` Since the "blue" namespace does not exist, the command returns an error: ```bash theme={null} 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. *** ## Enabling the Namespace Auto-Provision Admission Controller To enable automatic namespace creation, update the API server manifest at `/etc/kubernetes/manifests/kube-apiserver.yaml` as follows: 1. Locate the line with `--enable-admission-plugins`. 2. Add the `NamespaceAutoProvision` plugin, making the line appear as shown below: ```yaml theme={null} apiVersion: v1 kind: Pod metadata: annotations: kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 10.49.219.9:6443 creationTimestamp: null labels: component: kube-apiserver tier: control-plane name: kube-apiserver namespace: kube-system spec: containers: - command: - kube-apiserver - --advertise-address=10.49.219.9 - --allow-privileged=true - --authorization-mode=Node,RBAC - --client-ca-file=/etc/kubernetes/pki/ca.crt - --enable-admission-plugins=NodeRestriction,NamespaceAutoProvision - --enable-bootstrap-token-auth=true - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key - --etcd-servers=https://127.0.0.1:2379 - --insecure-port=0 - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt ``` After saving the changes, the API server pod will restart. Allow a few minutes for it to come back online. Once the API server is up, create the NGINX pod again: ```bash theme={null} kubectl run nginx --image nginx -n blue ``` To verify that the blue namespace was auto-created, list all namespaces: ```bash theme={null} kubectl get ns ``` Expected output: ```bash theme={null} NAME STATUS AGE blue Active 7s default Active 50m kube-node-lease Active 50m kube-public Active 50m kube-system Active 50m ``` This confirms that the Namespace Auto-Provision admission controller is functioning correctly. *** ## 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. 1. Open the file `/etc/kubernetes/manifests/kube-apiserver.yaml`. 2. Directly after the `--enable-admission-plugins` flag, add the disable flag for the DefaultStorageClass plugin (`--disable-admission-plugins=DefaultStorageClass`) as shown below: ```yaml theme={null} apiVersion: v1 kind: Pod metadata: annotations: kubeadm.kubernetes.io/kube-apiserver.advertise-address.endpoint: 10.49.219.9:6443 creationTimestamp: null labels: component: kube-apiserver tier: control-plane name: kube-apiserver namespace: kube-system spec: containers: - command: - kube-apiserver - --advertise-address=10.49.219.9 - --allow-privileged=true - --authorization-mode=Node,RBAC - --client-ca-file=/etc/kubernetes/pki/ca.crt - --enable-admission-plugins=NodeRestriction,NamespaceAutoProvision - --disable-admission-plugins=DefaultStorageClass - --enable-bootstrap-token-auth=true - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key - --etcd-servers=https://127.0.0.1:2379 - --insecure-port=0 - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt ``` 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: ```bash theme={null} kubectl run nginx --image nginx -n blue kubectl 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: ```bash theme={null} root@controlplane ~ ➜ kubectl run nginx --image nginx -n blue pod/nginx created root@controlplane ~ ➜ kubectl get ns NAME STATUS AGE blue Active 7s default Active 50m kube-node-lease Active 50m kube-public Active 50m kube-system Active 50m ``` *** ## Summary To summarize, in this lab we: 1. Identified the function of admission controllers and clarified that they do not manage user authentication. 2. Determined which admission controllers are enabled by default. 3. Enabled the Namespace Auto-Provision admission controller to automatically create namespaces. 4. 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](https://kubernetes.io/docs/).