Intro 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 repository with replication and proper lifecycle management. They will also leverage all the built-in cluster management features which come with Kubernetes. etcd 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 if any of the following apply: ConfigMap There is an existing, well-documented config file format, such as a or . mysql.cnf pom.xml 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. Use a for sensitive data, which is similar to a ConfigMap but more secure. Note: secret Use a (CRD or Aggregated API) if most of the following apply: Custom Resource Definition You want to use Kubernetes client libraries and CLIs to create and update a new resource. You want top-level support from (for example: ). kubectl kubectl get my-object object-name You want to build new automation that watches for updates on the new object, and then CRUD other objects, or vice versa. You want to write automation that handles updates to the object. You want to use Kubernetes API conventions like , , and . .spec .status .metadata You want the object to be an abstraction over a collection of controlled resources or a summation of other resources. 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 . 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 git git 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 or ! CircleCI Gitlab Final thoughts 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 . He likes sharing his knowledge by regularly writing for , , and many more. And while he is not doing that, he must be fishing or playing chess. Javelynn Hackernoon DZone Appfleet Previously posted at https://appfleet.com/ .

Different

Mind

How To Make Docker Images with Jenkins Pipelines

Microservices and Service Mesh with Istio, Explained

Read My Stories

The Curious Techie

Too Long; Didn't Read

Make resilience your competitive advantage

Understanding and Extending Kubernetes with Custom Resource Definitions API

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

14 Steps to Debugging a Node.js Application Running in a Docker Container

Circle CI: How To Run Ruby and JavaScript Tests in Parallel

Continuous Integration for a Monorepo on CircleCI Example

Heroku and CircleCI : Automated CI/CD Process for a NuxtJS

How to Deploy Vlocity Components with Vlocity Build Tool

14 Steps to Debugging a Node.js Application Running in a Docker Container

Circle CI: How To Run Ruby and JavaScript Tests in Parallel

Continuous Integration for a Monorepo on CircleCI Example

Heroku and CircleCI : Automated CI/CD Process for a NuxtJS

How to Deploy Vlocity Components with Vlocity Build Tool

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps