Custom Resources

Vários recursos no Kubernetes já foram utilizados durante o aprendizado, mas todos eram built-in do Kubernetes.

Deployments
Replicaset
Pods
Ingress
PersistentVolume
etc

Criamos um recurso apontando a API correta e um controller irá atuar em cima de cada um desses recursos para gerenciar o que é solicitado.

O que fazemos nada mais é do que solicitações para os controllers. Se não houvesse um controller para atuar em cima delas não teria efeito nenhum no cluster.

O Custom Resource Definition nada mais faz que estender a API do Kubernetes a fim de armazenar requests que controllers irão atuar em cima.

Podemos ter uma nova API sem que nenhum controller a use.

Vamos criar uma usando o exemplo abaixo

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 aplicar e observar o 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 simplesmente criar agora um 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 e 10. Se colocar um numero diferente teremos um erro

Vamos criar.

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>

Tem o descritivo de um recurso no Kubernetes que queremos, mas não temos um controller que atua sobre isso.

Para criar um controller podemos usar o projeto https://github.com/kubernetes/sample-controller como um guia, mas é necessário desenvolver uma lógica para isso que não faz sentido no momento.

Se quiser se aprofundar melhor é bom, mas não para a prova do CKAD.

O ideal é criar uma imagem para esse controller para que seja distribuída de forma funcional.

Operators Framework

Podemos encontrar vários operators em https://operatorhub.io/. Operators funcionam para deployar aplicação no Kubernetes assim como o Helm, mas com algumas diferenças. Enquanto o Helm busca fazer o deploy, operators vão um pouco além, criando custom resources para interagir diretamente com a aplicação e controlando o lifecycle. Não é algo que ainda está sendo pedido no exame, mas acredita-se que virá a ser pedido no futuro.

Operators Framework​

Operators Framework