Mastering Admission Control in Kubernetes: What You Need to Know
Admission control is essential for maintaining the integrity and security of your Kubernetes cluster. It acts as a gatekeeper, intercepting requests to the API server before they are persisted. This process happens after authentication and authorization, ensuring that only valid requests are processed. By implementing admission controllers, you can enforce policies, modify requests, and prevent unwanted changes to your resources.
The admission control process operates in two distinct phases. First, mutating admission controllers are executed, allowing modifications to the resource data. Next, validating admission controllers run, which can only validate but not alter the data. If any controller in either phase rejects a request, the entire request is denied, and an error is returned to the user. You can configure which admission plugins to enable or disable using the --enable-admission-plugins and --disable-admission-plugins parameters when starting the API server. For instance, you might enable plugins like NamespaceLifecycle and LimitRanger to enforce namespace policies and resource limits.
In production, it's crucial to be aware of the default admission controllers that come with Kubernetes 1.36, such as LimitRanger, PodSecurity, and ResourceQuota. These controllers help manage resources effectively, but you must ensure they align with your cluster's needs. Also, be cautious about how you apply these settings, as the method can vary based on your cluster's deployment. Always check your API server's configuration to avoid unexpected behavior.
Key takeaways
- →Understand the two phases of admission control: mutating and validating.
- →Configure admission plugins using `--enable-admission-plugins` and `--disable-admission-plugins`.
- →Be aware of default admission controllers in Kubernetes 1.36, like `LimitRanger` and `PodSecurity`.
- →Check your API server's configuration to ensure proper application of admission control settings.
Why it matters
Effective admission control can prevent misconfigurations and security breaches, ensuring that only compliant resources are deployed in your Kubernetes environment.
Code examples
kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ...kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ...kube-apiserver -h | grep enable-admission-pluginsWhen NOT to use this
The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.
Want the complete reference?
Read official docsIndustry-standard certifications built by the people behind Linux and Kubernetes. Earn the CKA — the gold standard Kubernetes administrator cert. OpsCanary readers get 30% off year-round with code OPSCANARY3.
Get CKA certified →Mastering Custom Resources in Kubernetes: A Guide for Operators
Custom resources in Kubernetes allow you to extend the API and tailor it to your needs. By combining them with custom controllers, you create a powerful declarative API that can manage complex applications. Dive into how this works and what you need to watch out for in production.
Forensic Container Checkpointing on Amazon EKS: What You Need to Know
Forensic container checkpointing is a game changer for stateful applications running on Amazon EKS. By leveraging the Kubelet Checkpoint API and CRIU, you can capture a container's full runtime state seamlessly. This article dives into the mechanics and real-world implications of implementing this powerful feature.
Why Your Controller's Cache Keeps the API Server Running Smoothly
Ever wonder how your Kubernetes controller can handle hundreds of calls per second without crashing the API server? The secret lies in the controller-runtime's local cache mechanism, which uses a combination of informers and stores to optimize data access. Dive in to understand the mechanics behind this powerful feature.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.