Custom Resources

Several resources in Kubernetes have already been used during learning, but they were all Kubernetes built-in.

Deployments
Replicaset
Pods
Ingress
PersistentVolume
etc

We create a resource pointing to the correct API and a controller will act on each of these resources to manage what's requested.

What we do is nothing more than requests to the controllers. If there were no controller to act on them, it would have no effect on the cluster.

The Custom Resource Definition does nothing more than extend the Kubernetes API to store requests that controllers will act on.

We can have a new API without any controller using it.

Let's create one using the example below:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: flighttickets.flights.com
spec:
  group: flights.com
  scope: Namespaced
  names:
    plural: flighttickets
    singular: flightticket
    kind: FlightTicket
    shortNames:
    - ft
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              from:
                type: string
              to:
                type: string
              number:
                type: integer
                minimum: 1
                maximum: 10

Let's apply and observe what happens:

kubectl apply -f crd.yaml
customresourcedefinition.apiextensions.k8s.io/flighttickets.flights.com created

kubectl api-resources | grep flight
flighttickets                     ft                                 flights.com/v1                    true         FlightTicket

kubectl proxy
Starting to serve on 127.0.0.1:8001

❯ curl localhost:8001/apis/flights.com
{
  "kind": "APIGroup",
  "apiVersion": "v1",
  "name": "flights.com",
  "versions": [
    {
      "groupVersion": "flights.com/v1",
      "version": "v1"
    }
  ],
  "preferredVersion": {
    "groupVersion": "flights.com/v1",
    "version": "v1"
  }
}

We can simply create a resource now:

apiVersion: flights.com/v1
kind: FlightTicket
metadata:
  name: my-flight-ticket
spec:
  from: Brasilia
  to: Atlanta
  number: 3 # we defined that it needs to be between 1 and 10. If we put a different number we'll get an error

Let's create:

kubectl apply -f flight.yaml
flightticket.flights.com/my-flight-ticket created

kubectl get ft
NAME               AGE
my-flight-ticket   7s

kubectl describe ft my-flight-ticket
Name:         my-flight-ticket
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  flights.com/v1
Kind:         FlightTicket
Metadata:
  Creation Timestamp:  2024-05-14T14:19:50Z
  Generation:          1
  Resource Version:    2883446
  UID:                 3e7afbf6-0608-4fcd-90a6-090f44b8be39
Spec:
  From:    Brasilia
  Number:  3
  To:      Atlanta
Events:    <none>

It has the description of a Kubernetes resource that we want, but we don't have a controller acting on it.

To create a controller, we can use the project https://github.com/kubernetes/sample-controller as a guide, but it's necessary to develop logic for this which doesn't make sense at the moment.

If you want to go deeper, it's good, but not for the CKAD exam.

The ideal is to create an image for this controller so that it can be distributed functionally.

Operators Framework

We can find several operators at https://operatorhub.io/. Operators work to deploy applications in Kubernetes just like Helm, but with some differences. While Helm seeks to deploy, operators go a bit beyond, creating custom resources to interact directly with the application and controlling the lifecycle. It's not something that's being asked for in the exam yet, but it's believed it will be asked for in the future.

Operators Framework​

Operators Framework