Why
While building a service for cloud resource management, we saw similarities between parts of our business logic and how the Kubernetes operators function.
Our interest in Kubernetes made us curious how custom operators are developed, and we used the opportunity to extract the core logic of our resource watcher and re-implement it as a custom operator.
For us, this project will serve as a ground base for a deeper focus into building solutions with custom Kubernetes resources.
What are the use cases
Being kind of a research project for us, learning from it was a priority. This still continues to be our goal, and by making the project public, we hope it can serve as another example on how Kubernetes operators can be used.
On a tech side, our main use case is managing cloud resources. Through a booking system, we can schedule machines to wake up, do some work, and then fall asleep again. Which in effect can cut server costs and make recurring computational jobs easier to set up.
In future, this can extend to managing different types of resources on a wide range of providers.
How it works
The custom resource operator provides a friendly interface to manage cloud resources through bookings.
We start by grouping our cloud instances under a common tag name. Next, we need to make the resources we plan to manage, on the cluster. We have two options of doing that:
- Create a resource monitor which depending of its type will scan for tagged instances and create the resources representation on the cluster automatically.
- Manually create resources on the cluster by applying the resource manifest.
Once we have resources, we can manage their state through bookings that have a resource name, start, and end time.
Example manifests can be found in the config/samples directory.
Check out Getting Started for a quick guide on how to use the operator.