> ## 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. # Demo Admission Webhooks in Action > Demo of Kubernetes admission controllers showing how mutating LimitRanger injects resource defaults and validating ResourceQuota enforces quotas during pod and deployment creation. Authentication tells Kubernetes who you are.\ Authorization tells Kubernetes what you are allowed to do. There is a third gate after authentication and authorization: admission control. Even if a request is authenticated and authorized, it still must pass through admission controllers. This is where platform governance typically lives: injecting defaults, enforcing quotas, validating configurations, and other policy enforcement. In this walkthrough we: * Inspect which admission plugins are active on the cluster. * Demonstrate how a mutating admission controller (LimitRanger) injects defaults. * Show how a validating admission controller (ResourceQuota) enforces limits based on those injected values. Mutating admission plugins run first and may change the object. Validating admission plugins run afterward and can accept or reject the request but cannot mutate it. This sequence allows validating controllers (like ResourceQuota) to see the final values injected by mutating controllers (like LimitRanger). ## 1) Check enabled admission plugins Run the kube-apiserver help and filter for the `enable-admission-plugins` flag to see which plugins are enabled: ```bash theme={null} kubectl exec -n kube-system kube-apiserver-controlplane \ -- kube-apiserver -h 2>&1 | grep enable-admission | head -5 ``` Typical relevant excerpt: ```text theme={null} --enable-admission-plugins strings admission plugins that should be enabled in addition to default enabled ones (..., LimitRanger, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota) ``` From the list, this demo focuses on: * LimitRanger — a mutating admission controller that injects defaults (LimitRange). * ResourceQuota — a validating admission controller that enforces resource and object count limits. ## 2) LimitRange defaults (LimitRanger) Describe the LimitRange that provides defaults in the `admission-lab` namespace: ```bash theme={null} kubectl describe limitrange default-limits -n admission-lab ``` Example summarized output as a table for clarity: | Type | Resource | Default Request | Default Limit | | - | - | - | - | | Container | cpu | 100m | 500m | | Container | memory | 128Mi | 512Mi | This LimitRange means: * Containers created without resource `requests` will receive defaults: `cpu: 100m` and `memory: 128Mi`. * Containers created without `limits` will receive defaults: `cpu: 500m` and `memory: 512Mi`. LimitRanger is implemented as a mutating admission controller that injects these defaults at admission time — the injected fields are persisted on the stored object. ## 3) Create a pod with no resource fields Catalog the pod manifest we’ll create (no `resources.requests` or `resources.limits` specified): ```yaml theme={null} # pod-no-resources.yaml apiVersion: v1 kind: Pod metadata: name: test-pod spec: containers: - name: app image: nginx ``` Apply the pod into the `admission-lab` namespace: ```bash theme={null} kubectl apply -f pod-no-resources.yaml -n admission-lab # pod/test-pod created ``` Describe the created pod to see what was admitted: ```bash theme={null} kubectl describe pod test-pod -n admission-lab ``` Relevant snippet showing injected resources: ```text theme={null} Containers: app: Image: nginx State: Running Ready: True Limits: cpu: 500m memory: 512Mi Requests: cpu: 100m memory: 128Mi ... Events: Normal Scheduled