Admission Controllers in Kubernetes with Istio: In Simple Words

Kubernetes admission controllers are plugins that help manage how a cluster is used by intercepting API requests. They act like gatekeepers, ensuring that any request to the Kubernetes API server is appropriate and meets the cluster’s policies before it is allowed to proceed.

In essence, admission controllers in Kubernetes ensure that every action in the cluster complies with predefined rules, enhancing security, consistency, and resource management. They do this by possibly modifying requests or validating them to enforce policies before allowing them to proceed.

Here’s a simple breakdown of how they work:

1. Interception:
When a request is made to the Kubernetes API server (like creating a new pod), it first goes through an authentication process. Once authenticated, the request reaches the admission controllers.

2. Two Phases:
Mutating Phase: This phase happens first. Controllers can modify the request if needed. For example, they might add default values or inject additional containers into a pod.

Validating Phase: This phase follows the mutating phase. Controllers check the request against the cluster’s policies. If the request doesn’t meet the requirements, it can be denied.

3. Types of Controllers:
Mutating Controllers: These can change the request. For instance, the Limit Ranger controller can add default resource limits to a pod.

Validating Controllers: These ensure the request adheres to certain rules. For example, they might check if the resources requested by a pod are within the allowed limits for a namespace.

Example:

Kubernetes Resource Quotas: Validating Pod Resource Requests

Let’s break down how Kubernetes admission controllers, particularly the ResourceQuota controller, work to enforce resource limits within a namespace using a practical example.

Step 1: Define a Resource Quota

First, we define a ResourceQuota to limit the amount of CPU and memory resources that can be used within a namespace.

# resource-quota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
 name: res-quota
spec:
 hard:
 cpu: “0.5”
 memory: 2Gi

We apply this ResourceQuota using the following command:

kubectl apply -f resource-quota.yaml

This sets a hard limit on the CPU (0.5 cores) and memory (2Gi) that can be requested by pods in the namespace.

Step 2: Define a Pod

Next, we define a pod that requests more resources than allowed by the ResourceQuota.

# pod.yaml
apiVersion: v1
kind: Pod
metadata:
 name: pod1
spec:
 containers:
 — name: ubuntu-pod
   image: ubuntu
   command: [“/bin/sh”]
   args: [“-c”, “while true; do echo hello; sleep 20;done”]
   resources:
     requests:
       memory: “5Gi”
       cpu: “500m”
     limits:
       memory: “10Gi”
       cpu: “500m”

When we try to create this pod using:

kubectl apply -f pod.yaml

Step 3: Validation by the ResourceQuota Controller

Upon this request, the following sequence occurs:
1. The request is sent to the Kubernetes API server.
2. The ResourceQuota admission controller intercepts the request during the validation phase.
3. It checks if the pod’s requested resources exceed the defined quota.

Given our initial quota (CPU: 0.5, Memory: 2Gi), the pod’s request for 500m CPU and 5Gi memory exceeds the limits.

Expected Error

Because the requested resources exceed the quota, the admission controller will deny the request, resulting in an error:

Error from server (Forbidden): error when creating “pod.yaml”: pods “pod1” is forbidden: exceeded quota: res-quota, requested: cpu=500m, used: cpu=0, limited: cpu=500m

Step 4: Adjust the Resource Quota

To allow the pod’s creation, we update the ResourceQuota to accommodate the requested resources.

# updated resource-quota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
 name: res-quota
spec:
 hard:
 cpu: “2”
 memory: 5Gi

We apply the updated ResourceQuota:

kubectl apply -f updated-resource-quota.yaml

Step 5: Create the Pod Again

Now, when we try to create the pod again using the same command:

kubectl apply -f pod.yaml

The ResourceQuota controller validates that the requested resources are within the updated limits, and the pod is successfully created.

Kubernetes admission controllers, such as the ResourceQuota controller, ensure that resource requests comply with defined policies. Initially, the pod creation failed because the requested resources exceeded the set quota. After updating the ResourceQuota, the pod creation succeeded, demonstrating how admission controllers enforce resource management policies.

Thank you for reading! For understanding more about Istio ,please refer
https://medium.com/@eshant.sah/istio-in-simple-words-with-hands-on-34fef2b2735d