How to use Kubernetes Custom Resource API in your software?
Decouple you platform with the Custom Resource API
What if I tell you that Kubernetes is not just infrastructure? What if I tell you that Kubernetes can help you to distribute your configuration?
In today’s issue, I will explain to you what is the Kubernetes Custom Resource API, why it’s important for you as Tech Lead to understand its possibilities, and the use cases for it.
Before going into the turrón, I want to bring up a common misconception I used to find about Kubernetes.
Yes, Kubernetes is about infrastructure for our services to run, and get profit of the great features this technology brings in terms of deployment, scalability, and resiliency.
Yes, Kubernetes is software as well. You can leverage Kubernetes API to have a decoupled, scalable, and resilient architecture for your system.
Here is where the Custom Resources API comes into play. Now, let’s go into the turrón.
☸️ What is the Custom Resource API?
From the official web page:
A resource is an endpoint in the Kubernetes API that stores a collection of API objects of a certain kind; for example, the built-in pods resource contains a collection of Pod objects.
And a Custom Resource is:
[…] an extension of the Kubernetes API that is not necessarily available in a default Kubernetes installation. It represents a customization of a particular Kubernetes installation. However, many core Kubernetes functions are now built using custom resources, making Kubernetes more modular. […]
In other words:
You define your resource.
You deploy it in Kubernetes.
And you will get a new kind of resource, a new endpoint, in the Kubernetes API to work with from your application.
🛠️ How does it work?
First, you have to define your Custom Resource. You will get a Custom Resource Definition (a.k.a. CRD). This is basically how your data will look like. For example:
The topic name to connect to in order to read domain events.
Kafka headers for the service to pay attention.
Once you deploy it, the Kubernetes system will create an API for creating, updating, listing, reading, and deleting objects (a.k.a CRs) of that resource (endpoint) definition. That’s part of the magic of Kubernetes API.
From here, a user of this resource (endpoint) will be able to deploy Custom Resource objects for that definition. For example:
Topic name with value `my-domain-events`.
Headers: `event-name`.
A Custom Resource Definition it’s not a Custom Resource. CRD is the definition that the CRs will have to respect to be deployed in Kubernetes.
💾 What to store?
In theory, you can save whatever you want if does not exceed 1MB.
My recommendation for you is to store configurations for your services, not data. Find some examples below.
✅ I would save information as Custom Resources, such as:
Parameters for services to connect to Kafka.
JSON Path expressions for a service to use them on their business logic.
Product flags.
🙅🏻♀️I would not save information as Custom Resources, such as:
Information about how much money your customers are paying for your product.
Images, neither binary data.
User’s information.
Hope you get the point.
🌈 Use cases
Taking into account that your system is deployed in a (or multi) Kubernetes cluster, these are the use cases I see interesting for using Kubernetes Custom Resources API.
Decoupling services. Imagine you have a database with certain configurations. You don’t want to expose it to all your services. Since all your services are 'running' in Kubernetes, you could store those configurations (via Saga pattern or similar) as data in a Custom Resource instead of exposing the database directly.
Configuring platform services. You have a platform service, such as one that provides auditing for all your services. Any service requiring data auditing could deploy a Custom Resource object to configure the audit service, allowing it to operate according to its specific needs.
You can see that those use cases are about best practices in system architecture. As Tech Lead, mastering these best practices is part of your responsibilities, helping you to ensure the quality, scalability, and maintainability of your system.
✨ Takeaways
Now, some general thoughts for you to keep in mind after this reading.
Kubernetes is not just about infrastructure, it’s about software as well.
Store configuration, not data.
The main use case for the Kubernetes Custom Resource API is about decoupling your system.
The CRDs are managed by the owners of the resource; The CR are managed by the users of the resource.
Hope you found this essay useful. I will write future essays about this API to explain more in detail how to squeeze this technology for decoupling and configuring platform services.
To receive that future post and others, just subscribe now 👇🏻
If you enjoyed this article, then click the 💜. It helps!
If you know someone else will benefit from this, ♻️ share this post.
I have never thought about this.
This is an interesting take, Marcos!
I'm continuing to learn API ins and out and this information is a great resource.