Despliegue con Kubernetes

Del pod al despliegue

1. Pod

Hemos visto que es posible crear un pod utilizando un contenedor tomcat-eni-todo :v24.04-tomcat-h2-env:dev. Usaremos esta versión primero, añadiendo la externalización de la base de datos más tarde.

Así que lanzamos un pod eni-todo-h2 con el contenedor usando esta imagen. Tenemos que asegurarnos de que el contenedor ha arrancado y funciona correctamente. 

$ kubectl run eni-todo-h2 \ 
   --image=registry.diehard.net:5000/tomcat-eni-todo:v24.04-
tomcat-h2-env \ 
   --env=" 
DB_DTB_JDBC_URL="jdbc:mysql://mariadb.diehard.net:3306/db_todo" \ 
   --env="DB_DTB_USERNAME=springuser" ... 
pod/eni-todo-h2 created 

También puede lanzar el contenedor con un archivo YAML y el siguiente comando: 

$ kubectl apply -f eni-todo-h2.000.pod.yaml 
pod/eni-todo-h2 created 

Los archivos YAML utilizados en este capítulo se encuentran en la carpeta src/main/kubernetes del repositorio git de la aplicación eni-todo (https://github.com/halnx-todo/k8s-manifests).

a. Sensores y control de estado

Kubernetes ofrece un sistema de sondas para comprobar el estado (healthcheck) de un pod. Hay tres tipos de sonda:

• livenessprobe

• readinessprobe

• startupprobe

Las tres se configuran de la misma manera, utilizando objetos en la definición del contenedor.

Existen tres posibles mecanismos de sondeo:

• tcpSocket: el kubelet en el nodo comprueba que el contenedor ha abierto el puerto definido en los parámetros para esta sonda.

• Exec: el kubelet presente en el nodo comprueba que el script definido en los parámetros de esta sonda se ejecuta correctamente (código de retorno 0) en el contenedor observado.

• httpGet: el kubelet presente en el nodo comprueba que la llamada HTTP definida en los parámetros de esta sonda, devuelve un código de retorno como el definido (200 por defecto).

Figura 1: Especificaciones de la sonda de un pod

Las sondas tienen:

• un retardo antes de activarse (initialDelaySeconds),

• una frecuencia de ejecución (periodSeconds),

• un umbral o número de errores (failureThreshold),

• un tiempo máximo de espera (timeoutSeconds).

Figura 2: Calendario y frecuencia de los controles de estado

Los tres tipos de sonda tienen mecanismos de análisis idénticos: esperan el retardo inicial...

Servicios y Endpoints

Hemos repasado rápidamente la necesidad de tener varios pods para mantener el servicio, pero es precisamente esta redundancia la que permite mantener esta alta disponibilidad.

Así que necesitamos un mecanismo para distribuir el flujo de peticiones a los pods. Esta es la función de los objetos Service. Esta abstracción se utiliza para proporcionar al clúster la información que necesita para configurar la red para la comunicación dentro del clúster y con el mundo exterior.

Como se ha mencionado en los capítulos anteriores, las etiquetas se utilizan para seleccionar objetos en Kubernetes. El mecanismo de etiquetas es omnipresente en un clúster. Las etiquetas también se utilizan para asociar (mapping) pods a un servicio mediante un selector.

<service>.<namespace>.svc.cluster.local 

apiVersion: v1 
kind: Service 
metadata: 
  labels: 
    app: eni-todo 
  name: eni-todo 
spec: 
  ports: 
  - port: 80 
    name: http8080 
    protocol: TCP 
    targetPort: 8080 
  selector: 
    app: eni-todo 
  sessionAffinity: ClientIP 
  type: ClusterIP 

$ kubectl get po -l app=eni-todo 
NAME                       READY   STATUS    RESTARTS   AGE 
eni-todo-95755d699-gldr6   1/1     Running   0          55m 
eni-todo-95755d699-jrzrg   1/1     Running   0          55m...

Secret y ConfigMap

Hemos visto que escribimos variables de entorno directamente en la definición del pod (pod template). Siempre es mejor externalizar los archivos de configuración, que para eso están ConfigMap y Secret.

Figura 9: ConfigMaps y Secret

Es posible almacenar pares variable/valor en objetos ConfigMap y Secret. Pero mientras que un ConfigMap almacena información directamente en formato de texto plano, un Secret requiere un valor codificado en formato base64, por ejemplo:

mysql_root_password: cjAwdC1hZWtpZThhaHdhaV8= 

El almacenamiento en la base de datos etcd también es diferente, ya que los secretos se cifran en la base de datos si la opción está activada en kube-apiserver (--encryption-provider-config).

También es posible almacenar archivos en ambos tipos de objetos.

En un ConfigMap:

apiVersion: v1 
kind: ConfigMap 
metadata: 
  name: mariadb-init 
data: 
  init.sh: | 
    #!/bin/sh 
 
    if [[ true ]]; then 
      echo "[mysqld]" >>...

StatefulSet

Habiendo visto cómo acceder a una base de datos externa, ahora veremos cómo poner una base de datos en nuestro clúster.

Un pod se puede instanciar en cualquier nodo en función de los recursos disponibles. Si bien esto funciona muy bien para los servicios sin conservación de estado (stateless), no es el caso de las bases de datos, cuya función misma es conservar los datos.

Al inicio de Kubernetes, un truco era forzar la ejecución de un pod en un nodo específico, a través de una selección utilizando el atributo nodeName, o utilizar los mecanismos nodeAffinity o nodeSelector para asegurarse de que un pod se instanciaba en un nodo con directorios dedicados a almacenar los datos del pod, que el pod podía montar directamente utilizando hostpath. 

apiVersion: v1 
kind: Pod 
metadata: 
  labels: 
    app: mariadb 
  name: mariadb 
spec: 
  volumes: 
  - name: test-volume 
    hostPath: 
      path: /data/mariadb 
      type: DirectoryOrCreate 
  containers: 
  - image: mariadb:10.5.8 
    name: mariadb 
    nodeName: k8s-worker01 
    env: 
    - name: MYSQL_USER 
      value: "springuser" 
    - name: MYSQL_PASSWORD 
      value: "mypassword-quoor-uHoe7z" 
    - name: MYSQL_DATABASE 
      value: "db_todo" 
    - name: MYSQL_ROOT_PASSWORD 
      value: "r00t-aeKie8ahWai_" 
    volumeMounts: 
    - mountPath: /var/lib/mysql 
      name: test-volume 
    ports: 
      - name: mariadb 
        containerPort: 3306 
        protocol: TCP 

No es un truco muy bueno, de hecho, es un hack infame. Pero durante mucho tiempo se utilizó para satisfacer las demandas de los gerentes...

PersistentVolume

Como hemos mencionado varias veces, Kubernetes es un orquestador que selecciona el nodo en el que instanciar el pod de su pool de nodos, según los criterios que le hayamos dado. Esto significa que, para proporcionar persistencia de datos, éstos deben poder ser utilizados por el pod en cualquier nodo. Los contenedores que componen los pods tendrán que montar los volúmenes presentes en su nodo. El propio nodo probablemente tendrá que montar un sistema de s adicional (NFS, Gluster FS, etc.). Los objetos PersistentVolume y PersistentVolumeClaim proporcionan a los clústeres (nodo, kubelet, etc.) la información que necesitan para montar estos diferentes sistemas de s.

Figura 10: Especificaciones de un volumen persistente

Un volumen persistente (Persistent Volume o PV) tiene varios atributos:

StorageClass

Figura 12: Especificaciones de la clase de almacenamiento

La clase de almacenamiento (StorageClass) es el recurso utilizado para abastecer dinámicamente de los PVC (y los PV detrás de ellos).

Tiene varios atributos:

En la nube, por ejemplo, la creación de un PVC con una clase de almacenamiento específica del proveedor crea automática y dinámicamente...

Rutas ingress

Job y CronJob

Es posible lanzar tareas (jobs) en Kubernetes. Los jobs son únicos: solo se ejecutan una vez.

Figura 14: Especificaciones de un Job y CronJob

Los atributos del job son los siguientes:

También es posible programar tareas recurrentes para determinadas fechas: cronjobs.

Los atributos más importantes de un cronjob son:

Para eni-todo, por ejemplo, puede usar un cronjob...