Why Custom Resource Definitions (CRDs) in Kubernetes? - Purpose & Use Cases

The Big Idea

What if you could teach Kubernetes to understand and manage anything you want, just like its built-in parts?

The Scenario

Imagine you want to manage a new type of resource in your Kubernetes cluster, like a special database or a custom app setting, but Kubernetes doesn't know about it yet.

You try to track and update these resources manually outside Kubernetes, using scripts or external tools.

The Problem

This manual way is slow and risky. You have to write lots of custom code, keep track of resource states yourself, and it's easy to make mistakes or lose sync with the cluster.

Also, you miss out on Kubernetes features like automatic updates, validation, and easy querying.

The Solution

Custom Resource Definitions (CRDs) let you tell Kubernetes about your new resource types directly.

With CRDs, you can create, update, and manage your custom resources just like built-in ones, using the same tools and commands.

This makes your cluster smarter and your work simpler and safer.

Before vs After

✗ Before

curl -X POST http://external-system/api/create -d '{"name":"mydb"}'
# then separate script to check status

✓ After

kubectl apply -f mydb-cr.yaml
kubectl get mydb mydb-instance

What It Enables

It enables you to extend Kubernetes seamlessly to manage any resource you need, all within the same powerful system.

Real Life Example

A company creates a CRD to manage custom backup jobs for their databases, so they can schedule, monitor, and automate backups using Kubernetes commands.

Key Takeaways

Manual resource management outside Kubernetes is slow and error-prone.

CRDs let you add new resource types directly into Kubernetes.

This makes managing custom resources easier, safer, and integrated.