Custom Resources

Varios recursos en Kubernetes ya fueron utilizados durante el aprendizaje, pero todos eran built-in de Kubernetes.

• Deployments
• Replicaset
• Pods
• Ingress
• PersistentVolume
• etc

Creamos un recurso apuntando la API correcta y un controller irá actuar en cima de cada uno de esos recursos para gerenciar lo que es solicitado.

Lo que hacemos nada más es que solicitaciones para los controllers. Si no hubiese un controller para actuar en cima de ellas no tendría efecto ninguno en el cluster.

El Custom Resource Definition nada más hace que extender la API de Kubernetes a fin de almacenar requests que controllers irán actuar en cima.

Podemos tener una nueva API sin que ningún controller la use.

Vamos a crear una usando el ejemplo abajo

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

Vamos a aplicar y observar lo que acontece.

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"
  }
}

Podemos simplemente crear ahora un recurso.

apiVersion: flights.com/v1
kind: FlightTicket
metadata:
  name: my-flight-ticket
spec:
  from: Brasilia
  to: Atlanta
  number: 3 # definimos que precisa ser entre 1 y 10. Si colocar un numero diferente tendremos un error

Vamos a crear.

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>

Tiene el descriptivo de un recurso en Kubernetes que queremos, pero no tenemos un controller que actúa sobre eso.

Para crear un controller podemos usar el proyecto https://github.com/kubernetes/sample-controller como un guía, pero es necesario desarrollar una lógica para eso que no hace sentido en el momento.

Si quiere se profundizar mejor es bueno, pero no para la prueba del CKAD.

El ideal es crear una imagen para ese controller para que sea distribuida de forma funcional.

Operators Framework

Podemos encontrar varios operators en https://operatorhub.io/. Operators funcionan para deployar aplicación en Kubernetes así como el Helm, pero con algunas diferencias. Mientras el Helm busca hacer el deploy, operators van un poco más allá, creando custom resources para interactuar directamente con la aplicación y controlando el lifecycle. No es algo que todavía está siendo pedido en el examen, pero se cree que vendrá a ser pedido en el futuro.