# Day 29 - Kubernetes Custom Resources

Kubernetes normally supports built-in resources like:

* **Deployment**
    
* **Service**
    
* **Pod**
    
* **ConfigMap**
    
* **Secret**
    
* **Ingress**
    

These are called **native resources**.

Sometimes companies (Istio, ArgoCD, Prometheus Operator, Kyverno, etc.) want to add **new features** that Kubernetes does not support by default.

To do this, Kubernetes allows you to:

👉 **Extend the Kubernetes API**  
This extension is done using:

1. **CRD — Custom Resource Definition**
    
2. **CR — Custom Resource**
    
3. **Custom Controller**
    

---

# 🟦 **1\. CRD — Custom Resource Definition**

**CRD = Definition / Schema of a new Kubernetes API.**

It tells Kubernetes:

* What is the **name** of the new resource?
    
* What are the **fields** allowed?
    
* What is the **API version** and **kind**?
    
* What does the YAML structure look like?
    

Example: Istio defines a new resource called **VirtualService**.

Istio provides a **CRD** so Kubernetes understands:

```plaintext
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
```

CRD is installed **once** by DevOps engineers (usually via Helm or operator).

### Purpose of CRD:

✔ Introduces a **new type of resource** into Kubernetes  
✔ Validates all CR created by users  
✔ Extends Kubernetes API

---

# 🟦 **2\. CR — Custom Resource**

**CR = User-created object based on the CRD.**

Example: After installing the Istio VirtualService CRD, a user can create:

```plaintext
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-app
spec:
  ...
```

This YAML is the **Custom Resource**.

### Summary:

* CRD = Template / Model / Schema
    
* CR = Actual object created by the user
    

Same logic as:

* Deployment resource definition (built-in)
    
* Deployment YAML (your object)
    

---

# 🟦 **3\. Custom Controller**

CRD + CR **alone do nothing**.  
Like Ingress without an Ingress controller → **useless**.

A **Custom Controller** is required to *watch* the CR and take action.

For example:

### In Istio:

* VirtualService CRDs define the API
    
* VirtualService CRs define the config
    
* Istio Controller watches those CRs
    
* Then configures Envoy proxy accordingly
    

### Controller Responsibilities:

✔ Watches for **create / update / delete** of CR  
✔ Performs actions on cluster  
✔ Maintains desired state

---

# ⭐ **Flow Diagram (Short & Clear)**

```plaintext
DevOps Engineer:
    1. Install CRD → Adds new API to Kubernetes
    2. Install Controller → Logic to handle CRs

User / Developer:
    3. Creates Custom Resource (CR)

Controller:
    4. Watches CR
    5. Performs required actions
```

---

# ⭐ **Simple Example Using Istio**

### Step 1: DevOps installs CRDs

Istio CRDs include:

* VirtualService
    
* DestinationRule
    
* Gateway
    
* PeerAuthentication  
    …
    

### Step 2: DevOps installs Istio Controller

This controller will watch all Istio CRs.

### Step 3: User creates CR

```plaintext
kind: VirtualService
...
```

### Step 4: Istio Controller sees it and configures Envoy proxies.

---

# ⭐ **How Custom Controllers Are Written**

Usually written in **Go** because:

* Kubernetes itself is written in Go
    
* Official client library **client-go**
    
* Best support + ecosystem
    

Process (high-level):

1. Set watchers for CR events (Add/Update/Delete)
    
2. Add events to a workqueue
    
3. Process each event
    
4. Take action → create/update Kubernetes resources or external systems
    

Frameworks used:

* **controller-runtime**
    
* **operator-sdk** (for building operators)
    

---

# ⭐ **Key Points to Remember (Interview-Friendly)**

* **CRD** adds a new resource type to Kubernetes.
    
* **CR** is an instance of that resource.
    
* **Controller** makes the CR actually do something.
    
* **CRD = schema**, **CR = object**, **Controller = brain/logic**.
    
* Without the controller, CR does nothing.