The API Aggregation Layer
Key Takeaways for AI & Readers
- API Extension Beyond CRDs: The API Aggregation Layer allows extending the Kubernetes API with custom logic and storage, beyond what CRDs can provide alone.
- Proxying External APIs: The main
kube-apiserveracts as a proxy, forwarding requests for specific API groups to external services running within the cluster. - Dedicated Logic and Storage: Aggregated APIs can manage their own storage and implement custom business logic, offering greater flexibility and performance for specialized functions.
- APIService Resource: The
APIServiceobject is used to register these external API services with the main Kubernetes API.
Sometimes CRDs (Custom Resource Definitions) aren't enough. If you need a custom API that handles its own storage or logic (like the Metrics Server), you use the Aggregation Layer.
1. The Traffic Cop
Visualize how the main API Server acts as a proxy for external APIs.
Aggregator (kube-apiserver)
🚦
💾
Local Registry (etcd)
🛠️
Extension API Server
Metrics-Server / Prometheus
The Aggregation Layer allows you to provide custom APIs that look and act like native Kubernetes objects but are handled by external services.
2. CRDs vs. Aggregation
| Feature | CRD | Aggregation Layer |
|---|---|---|
| Complexity | Low (YAML only) | High (Requires a custom server) |
| Storage | Uses K8s etcd | Can use its own database |
| Performance | Standard | Optimized for specific logic |
| Example | Cert-Manager | Metrics-Server, Service Catalog |
3. APIService Resource
To register an aggregated API, you create an APIService object. This tells the main kube-apiserver that any request for metrics.k8s.io should be forwarded to a specific Service IP in your cluster.