Turn any of your APIs into a Kubernetes-native citizen

Table of Contents
⚡ Transforming APIs into Kubernetes-Native Citizens
The power of Kubernetes lies in its unified control plane and its resource model. But what if you could make any of your existing APIs or services behave like a native Kubernetes resource—complete with kubectl compatibility, cluster-level governance, and seamless integration?
Developing extensions via the Kubernetes Aggregation Layer has traditionally been a highly complex task, demanding deep knowledge of internal API structures, serialization, and resource handling. This steep learning curve often prevents developers from extending Kubernetes as much as they’d like.
This post introduces the kubernetes-aggregator-framework, an open-source tool designed to drastically simplify this process. We’ll show you how this framework hides the complexity of the Kubernetes API server internals, allowing you to rapidly turn existing microservices or custom data sources into Kubernetes-native citizens.
❓ What the Kubernetes Aggregation Layer Gives You
The Kubernetes Aggregation Layer allows you to extend the core Kubernetes API with your own custom APIs. Think of it as a gateway that lets you add new types of resources to your cluster that behave just like native Kubernetes objects (like pods or services).
🤹 The Difficulty of Developing an API Server Without Frameworks
Building a custom API server for Kubernetes from scratch is a complex and challenging task. It requires a deep understanding of the Kubernetes API’s internals, including:
This level of detail makes it very difficult to develop an API server without extensive, in-depth knowledge of Kubernetes’ inner workings.
💡 How This Framework Simplifies the Process
Recognizing these challenges, our framework provides a straightforward solution to make building custom Kubernetes API servers easy and accessible. It hides away much of the complex, low-level work, allowing you to focus on your core logic.
🔌 How to Use It
Kubernetes uses
HTTPSby default, so you need a certificate for the service. The most common way to automate this step is installing Cert-Manager to the cluster.
In the first step create an APIService and the related service manifests. Edit your Deployment to mount certificate.
| |
Creating raw endpoints, without any Kubernetes behaviour dependency
| |
Call API via kubectl.
| |
Create fully customized API endpoints for cluster and namespace scoped custom resource
| |
Call API via kubectl.
| |
| |
Create and API extending Kubernetes API capabilities, for example collecting events of Pods
| |
| |
| |
Call API via kubectl.
| |
🧠 Final Thoughts
We’ve explored how the kubernetes-aggregator-framework dramatically simplifies the complex world of the Kubernetes Aggregation Layer. The ability to expose any of your existing APIs as native Kubernetes Custom Resources is a game-changer.
By abstracting away the heavy lifting—like handling API registration, request routing, serialization, and proper Kubernetes API conventions—the framework allows you to focus purely on your core business logic. You gain the best of both worlds: the simplicity of standard API development coupled with the powerful, unified control plane that Kubernetes offers.
This framework is not just about making development easier; it’s about enhancing your cluster’s capabilities. You can now enforce consistent security policies, leverage standard tooling like kubectl, and achieve genuine Kubernetes-native integration for every microservice you build.
We hope this tool empowers you to unlock new levels of performance and simplicity within your data topology. Don’t let the complexity of Kubernetes API extensions hold you back any longer.
🙏 Share Feedback and Report Issues
Your feedback is invaluable in helping us improve this framework. If you encounter any issues, have a suggestion for a new feature, or simply want to share your experience, we want to hear from you!
- Report Bugs: If you find a bug, please open a GitHub Issue. Include as much detail as possible, such as steps to reproduce the bug, expected behavior, and your environment (e.g., Kubernetes version, Go version).
- Request a Feature: If you have an idea for a new feature, open a GitHub Issue and use the feature request label. Describe the use case and how the new feature would benefit the community.
- Ask a Question: For general questions or discussions, please use the GitHub Discussions.
This project is part of our journey to transform Kubernetes into a true Platform-as-a-Service. We not just dream about this but built for you. Read details here: [→].
That’s it! You’ve seen how the kubernetes-aggregator-framework completely removes the friction from extending your Kubernetes control plane. It’s time to stop treating your APIs as external services and start integrating them as first-class Kubernetes resources.
Thank you for reading, and feel free to share your thoughts.