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.
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:
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:
kubectl get my-object object-name
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:
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, DZone, Appfleet and many more. And while he is not doing that, he must be fishing or playing chess.
Previously posted at https://appfleet.com/.