Life of a Request in Kubernetes: Understanding API Server Processing with Examples

In Kubernetes, each request sent to the API server goes through a detailed, multi-step process that ensures security, compliance, and resource correctness. Let’s explore each stage in processing a request, using an example of creating a new Pod to highlight how these stages work in practice.

---

1. Authentication: Verifying Who Is Making the Request

• Example: Imagine we run kubectl create -f pod.yaml to create a Pod. The pod.yaml file contains the configuration of the Pod we want to create.

• Process: The API server first authenticates the user to verify their identity. Kubernetes supports several authentication methods:

  • Bearer Tokens: Our request might carry a token that the API server validates.

  • Client Certificates: Alternatively, we could use a client certificate that links to our user account.

• Outcome: Let’s assume our user is authenticated using a Bearer Token. The API server successfully identifies the user making the request and confirms access to the cluster.

2. Authorization: Verifying Permissions with RBAC

• Example: Once authenticated, the API server checks if the user is authorized to perform this action.

• Process: Kubernetes uses a Role-Based Access Control (RBAC) system to define permissions. The API server checks if our user’s roles include permission to create a Pod in the default namespace.

• Outcome: If the user has the necessary permissions, the request moves forward. If not, the API server returns a 403 Forbidden error, denying the request.

• Scenario: Suppose our user has a Role that only permits reading Pods, not creating them. In this case, the request would fail at this stage because it requires create permissions.

3. Admission Control: Enforcing Policies and Modifying Requests

• Example: With authentication and authorization complete, the request moves to the admission control stage.

• Process: Here, admission controllers apply additional checks and modifications:

  • Policy Enforcement: For example, if an admission controller enforces a rule that all Pods must have a specific label (e.g., environment=production), it will ensure this label is present.

  • Mutating Admission Controllers: A controller might add extra containers to the Pod configuration for things like monitoring or networking (e.g., adding a sidecar container for a service mesh like Istio).

• Outcome: If an admission controller finds an issue with the request, it can either modify it (e.g., adding missing labels) or reject it with an error.

• Scenario: Let’s say the cluster has a policy requiring each Pod to have a team label. If our Pod configuration in pod.yaml lacks this label, the admission controller could either add team: dev as a default value or reject the request with an error saying, “Missing required label: team.”

4. Validation: Checking Resource-Specific Requirements

• Example: After admission control, the request goes through validation to ensure it meets resource-specific requirements.

• Process: Validation confirms that the Pod configuration adheres to Kubernetes’ specifications:

  • For instance, it checks that the Pod name follows DNS naming conventions and that all required fields (like container images) are included.

• Outcome: If the request passes validation, the Pod is created. If validation fails (e.g., due to an invalid name or missing fields), the API server returns an error detailing the issue.

• Scenario: Suppose the name in our Pod configuration has uppercase letters, which violates Kubernetes’ DNS rules. The API server would reject the request with an error like "Invalid name: Pod names must be lowercase."

---

Example Summary

In our example, the request to create a Pod would succeed if it passes through each stage:

1. Authenticated using a Bearer Token.

2. Authorized to create Pods in the default namespace.

3. Admission Control adds a missing team: dev label.

4. Validation checks that the Pod name and configuration follow Kubernetes standards.

The Pod is then successfully created in the cluster! However, if any stage fails, Kubernetes responds with an error message detailing the specific failure point.