Mobile
Streaming Platform Products
Virtual & Dedicated Servers Products
Containers Products
Serverless Computing Products
AI & Machine Learning Products
Private and Hybrid Solutions Products
Monitoring Products
Custom Services Products
Media & Entertainment
Financial Services
IT / Technology
Retail
Education
Website Acceleration
Video Streaming
Security & Protection
Cloud
Partnership Solutions
Corporate Solutions
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:
mysql.cnf
or pom.xml
.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
(for example: kubectl get my-object object-name
)..spec
, .status
, and .metadata
.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!
This CRD is called GitHook. It defines git
webhook events and a build pipeline. GitHook controller will subscribe webhook events to git
repo and when the events happen, it will run a build pipeline as defined in the CRD.
GitHook CRD controller’s job is:
With a little work and a good team, you could string some CRDs like this together and have a startup like CircleCI or Gitlab!
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!