Understanding and Extending Kubernetes with Custom Resource Definitions API
Solution Architect | Technical Content Writer
So, let's say you had a service or application that was built on an orchestration platform such as Kubernetes. In doing so, you must also address an overflowing array of architectural issues, including security, multi-tenancy, API gateways, CLI, configuration management, and logging.
Wouldn't you like to save some manpower and development time and focus on creating something unique to your problem?
Well, it just so happens that your solution lies in what's called a Custom Resource Definition, or CRD. The CRD enables engineers to plug in your own Object and application as if they were a native Kubernetes component. This is extremely powerful in creating tool and services built on Kubernetes
By doing this, you can build out the custom resources for your application as well as use Kubernetes RBAC to provide security and authentication to your application. These custom resources will be stored in the integrated etcd
repository with replication and proper lifecycle management. They will also leverage all the built-in cluster management features which come with Kubernetes.
Why do I need a CRD?
The easiest way to answer this is that you might not! It really depends on your specific project and needs. The Kubernetes Docs answer this question like so:
Use a ConfigMap if any of the following apply:
- There is an existing, well-documented config file format, such as a
- You want to put the entire config file into one key of a ConfigMap.
- The main use of the config file is for a program running in a Pod on your cluster to consume the file to configure itself.
- Consumers of the file prefer to consume file via a Pod or an environment variable in a Pod, rather than the Kubernetes API.
- You want to perform rolling updates via Deployment, etc., when the file is updated.
Note: Use a secret for sensitive data, which is similar to a ConfigMap but more secure.
Use a Custom Resource Definition (CRD or Aggregated API) if most of the following apply:
Everyone has different goals in mind and context surrounding those goals, however if your project needs a flexible way to extend Kubernetes and is trying to stick heavily to the "Kubernetes-native" way of doing things then CRDs are right up your alley. You might be asking now, what are some typical CRDs? I'm glad you asked!
Githook example CRD
This CRD is called GitHook
. It defines
webhook events and a build pipeline. GitHook controller will subscribe webhook events to
repo and when the events happen, it will run a build pipeline as defined in the CRD.
GitHook CRD controller’s job is:
- Make sure that webhook is registered to git repo with correct information.
- Make sure that there is a service running and wait for the webhook events. It uses Knative service to receive that webhook since it is easy to implement and can scale to 0 when it is not in use.
With a little work and a good team, you could string some CRDs like this together and have a startup like CircleCI
So in closing, CRDs are really amazing extensions of the Kubernetes API and allow a lot of flexibility in the creation of K8s native applications. Hope this helps you wrap your head around CRDs and their uses a bit more, thanks for reading!
About the author - Sudip is a Solution Architect with more than 15 years of working experience, and is the founder of Javelynn
. He likes sharing his knowledge by regularly writing for Hackernoon
and many more. And while he is not doing that, he must be fishing or playing chess.
Subscribe to get your daily round-up of top tech stories!