Deployments

Workload y Controllers

En Kubernetes, un workload es una aplicación o conjunto de aplicaciones que se ejecutan en contenedores. Los workloads son las unidades que Kubernetes gestiona para ejecutar tus aplicaciones. Kubernetes se encarga de desplegarlos, escalarlos, monitorearlos y administrarlos de manera eficiente.

Existen varios tipos de workloads en Kubernetes, cada uno con características específicas para diferentes tipos de aplicaciones:

  1. Pod: La unidad básica de ejecución en Kubernetes. Un pod contiene uno o más contenedores que comparten almacenamiento, red y especificaciones sobre cómo deben ejecutarse. Sin embargo, un pod por sí solo no suele ser el principal objeto de trabajo en Kubernetes, ya que no se reinicia automáticamente si falla.

  2. Deployment: Un objeto que administra un conjunto de pods idénticos y asegura que siempre se ejecuta el número correcto de réplicas. Se utiliza para mantener la alta disponibilidad de la aplicación y permite actualizaciones sin tiempos de inactividad.

  3. StatefulSet: Similar al deployment, pero diseñado para aplicaciones con estado. Los pods gestionados por un StatefulSet tienen identificadores persistentes y una relación ordenada entre ellos, lo que es útil para bases de datos o servicios que necesitan un almacenamiento persistente.

  4. DaemonSet: Asegura que un pod específico se ejecute en todos o en algunos nodos del clúster. Es común para servicios que deben estar presentes en cada nodo, como monitoreo o herramientas de registro.

  5. Job: Se encarga de ejecutar una tarea específica una vez o un número fijo de veces. Es útil para trabajos por lotes o tareas programadas que deben ejecutarse y finalizar.

  6. CronJob: Extensión de los jobs, pero se ejecutan de manera periódica en base a un horario especificado, similar a un cron en sistemas Unix.

Cada tipo de workload tiene su propio propósito y se selecciona en función de las necesidades de la aplicación, ya sea para aplicaciones sin estado, con estado, tareas periódicas o servicios de fondo.

Los controllers en Kubernetes son componentes clave que supervisan y gestionan los workloads, asegurando que el estado actual de estos coincida con el estado deseado. Los controllers actúan como “bucle de control”, observando continuamente el estado del clúster y realizando las acciones necesarias para que los workloads funcionen correctamente.

Deployments

Porque usamos deployment y no pods?

Algunas desventajas de los pods:

desventajas_pod

Para solventar estas desventajas tenesmos que meter al pod dentro de una “burbuja” en este caso un deployment.

deployment-pods

Al igual que los pods , tenesmos que tener un deployment por cada servicio, por ejemplo 1back ,1front, 1db

Crear deployment de manera imperativa.

kubectl create deployment apache --image=httpd
deployment.apps/apache created

Al hacer deployment se crean como vimos en las fotos anteriores:

  1. deployment
  2. replica set
  3. pods.
kubectl get deploy

#obtener replica set 
kubectl get rs

#obtener pods 

kubectl get pods

Ver informacion del deploy

kubectl describe deploy apache

Crear deploy de manera declarativa

apiVersion: apps/v1 # i se Usa apps/v1beta2 para versiones anteriores a 1.9.0
kind: Deployment
metadata:
  name: nginx-d
spec:
  selector:   #permite seleccionar un conjunto de objetos que cumplan las condicione
    matchLabels:
      app: nginx
  replicas: 2 # indica al controlador que ejecute 2 pods
  template:   # Plantilla que define los containers
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Este manifiesto YAML de Kubernetes define un Deployment, que es una forma de gestionar un grupo de pods y controlar su ciclo de vida. El propósito del Deployment es asegurarse de que un conjunto de réplicas de tu aplicación (en este caso, dos réplicas de nginx) siempre esté en ejecución y se gestione de forma automática.

Aquí está el desglose de cada parte del manifiesto:

apiVersion: apps/v1

Este campo especifica la versión de la API que Kubernetes usa para el recurso. En este caso, apps/v1 se utiliza para los Deployments en las versiones modernas de Kubernetes (1.9.0 y posteriores). Si estuvieras trabajando con versiones anteriores a la 1.9.0, podrías haber usado apps/v1beta2.

kind: Deployment

Este campo indica el tipo de recurso que estás definiendo, en este caso un Deployment, que es un controlador que administra pods y los mantiene funcionando.

metadata:

Define información sobre el objeto que estás creando. Incluye el nombre del Deployment y otros metadatos:

  • name: nginx-d: Asigna el nombre nginx-d al Deployment. Este nombre será cómo te refieras al Deployment dentro del clúster.

spec:

Este es el bloque donde defines las especificaciones del Deployment. Aquí especificas cuántos pods quieres ejecutar y los detalles de su plantilla.

selector:

Este campo es crucial porque indica qué pods serán gestionados por este Deployment. Utiliza matchLabels para identificar los pods:

  • matchLabels:
    • app: nginx: Selecciona todos los pods que tengan la etiqueta app: nginx. Esto le indica al Deployment que estos serán los pods que debe gestionar.

replicas: 2

Este campo indica que quieres dos réplicas de tu aplicación (nginx) ejecutándose. El Deployment se asegurará de que siempre haya dos pods funcionando. Si uno falla, Kubernetes lo recreará automáticamente.

template:

Esta sección define la plantilla para los pods que serán creados. Aquí se especifica cómo deben ser esos pods (contenedores, etiquetas, configuración).

  • metadata:

    • labels:
      • app: nginx: Asigna la etiqueta app: nginx a cada pod creado. Esto asegura que el selector del Deployment pueda reconocer estos pods y gestionarlos.

  • spec: Aquí defines la especificación para los contenedores dentro de los pods.

    • containers: Este campo especifica los contenedores que el pod ejecutará. En este caso, el pod contiene un contenedor:

      • name: nginx: El nombre del contenedor es nginx.

      • image: nginx:latest: Se usa la imagen nginx:latest del registro de Docker para el contenedor, lo que instalará la versión más reciente del servidor web Nginx.

      • ports:

        • containerPort: 80: Expone el puerto 80 dentro del contenedor para recibir tráfico HTTP, ya que Nginx escucha por defecto en el puerto 80.

Resumen:

Este Deployment crea y administra 2 pods que ejecutan el servidor web nginx. El Deployment se asegura de que siempre haya dos réplicas del pod en ejecución, manejando la creación y destrucción de pods según sea necesario. Además, expone el puerto 80 para tráfico HTTP dentro del contenedor nginx.

Es un ejemplo básico para desplegar aplicaciones web con alta disponibilidad y escalabilidad.

Podemos ver todos lo detalles de los objetos generados de una sola vez con kubectl get deploy,pods,rs

Comando edit

Podemos modificar la configuración del deploy en caliente con kubectl edit deploy nginx-d

Lo ideal seria tenerlo en un archivo yaml, ya que de la otra manera q vimos recien no podremos replicarlo facilmente.

kubectl get deploy nginx-d -o yaml > el-backup.yaml

Escalar deployment

kubectl scale deployment nginx-d --replicas=5

Podemos escalar deployments por el valor de sus labels, si tenemos la label estado=“1” podemos hacer:

kubectl scale deployment -l estado="1" --replicas=10

apiVersion: apps/v1 
kind: Deployment
metadata:
  name: nginx-d
  labels:
    estado: "1"
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
mysql_cluster