Ruta de aprendizaje Kubernetes 2

Gestión de Aplicaciones Deployments, ReplicaSets y DaemonSets.

Enunciado

La aplicación web frontend‑web está ganando popularidad. Necesitas desplegarla de forma robusta, asegurando que siempre haya un número mínimo de réplicas funcionando.

Asignación:

  1. Crea un Deployment llamado web-deployment usando la imagen httpd:2.4.
  2. El Deployment debe tener 3 réplicas.
  3. Expón el Deployment como un servicio de tipo NodePort para acceder a la web desde tu navegador.
  4. Simula una alta carga y escala el Deployment a 5 réplicas usando kubectl scale.
  5. Escala el Deployment de vuelta a 2 réplicas y observa cómo el ReplicaSet gestiona la terminación de los Pods.

Herramientas

  • Docker
  • Kubernetes

Requisitos previos

Se utiliza Minikube para simular el cluster K8s en un servidor, en primer lugar lo iniciamos:

Configuracion K8s


Pasos realizados

  1. Generar el manifiesto YAML del Deployment
    Con el siguiente comando creamos un archivo deployment.yaml con la configuración deseada:

    kubectl create deployment web-deployment --image=httpd:2.4 --replicas=3 --dry-run=client -o yaml > deployment.yaml
    
  2. Aplicar el Deployment

    kubectl apply -f deployment.yaml
    
  3. Exponer el servicio como NodePort
    Para acceder desde el navegador, creamos un servicio de tipo NodePort.
    (Nota: Kubernetes solo permite puertos en el rango 30000‑32767 para NodePort).

    kubectl expose deployment web-deployment --type=NodePort --port=80 --target-port=80 --name=web-service
    

    Luego podemos obtener la URL de acceso con:

    minikube service web-service --url
    
  4. Escalar a 5 réplicas

    kubectl scale deployment web-deployment --replicas=5
    
  5. Escalar de vuelta a 2 réplicas

    kubectl scale deployment web-deployment --replicas=2
    

    Al reducir el número de réplicas, el ReplicaSet elimina gradualmente los Pods sobrantes (normalmente los más recientes o los que están en estado Running), manteniendo el número deseado. Puedes observar el proceso con:

    kubectl get pods -w
    

Actualización de una Aplicación usando Rolling Update

Contexto: Los desarrolladores han lanzado una nueva versión de la imagen para web-deployment: httpd:2.4.58. Debes actualizar el Deployment sin tiempo de inactividad.

Asignación:

  1. Actualiza la imagen del Deployment web-deployment del ejercicio anterior a httpd:2.4.58 usando kubectl set image.
  2. Observa cómo se realiza la actualización gradual (rolling update). Usa kubectl rollout status para monitorear el progreso.
  3. Simula un error en la nueva versión y realiza un rollback a la versión anterior usando kubectl rollout undo.

Pasos realizados

  1. Actualizar la imagen

    kubectl set image deployment web-deployment httpd=httpd:2.4.58
    

    Nota: El nombre del contenedor es httpd (definido en el YAML). Si el contenedor tiene otro nombre, ajústalo.

  2. Monitorear el progreso del rolling update

    kubectl rollout status deployment web-deployment
    

    Verás cómo Kubernetes va reemplazando los Pods antiguos por nuevos de forma gradual, garantizando que siempre haya réplicas disponibles.

  3. Realizar un rollback (deshacer la actualización)

    kubectl rollout undo deployment web-deployment
    

    Este comando revierte el Deployment a la revisión anterior (en este caso, a httpd:2.4). Puedes confirmar la reversión con:

    kubectl rollout status deployment web-deployment
    kubectl get pods -o jsonpath='{.items[*].spec.containers[*].image}' | tr ' ' '\n'
    

Despliegue de un Agente de Monitoreo con DaemonSet

Contexto: El equipo de operaciones quiere desplegar un agente de monitoreo llamado node‑exporter en todos los nodos del clúster para recolectar métricas del sistema.

Asignación:

  1. Crea un DaemonSet llamado node-exporter con la imagen prom/node-exporter.
  2. Asegúrate de que el DaemonSet se ejecute en todos los nodos (en Minikube solo hay un nodo).
  3. Verifica que el Pod se haya creado y esté corriendo.
  4. Investiga qué sucede si etiquetas un nodo con disktype=ssd y modificas el DaemonSet para que solo se ejecute en nodos con esa etiqueta (usando nodeSelector). ¿Qué ocurre con el Pod existente?

Pasos realizados

  1. Crear el DaemonSet

    Como el comando kubectl create daemonset --image no funcionó en algunos entornos, se optó por un manifiesto YAML:

    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      name: node-exporter
      labels:
        app: node-exporter
    spec:
      selector:
        matchLabels:
          app: node-exporter
      template:
        metadata:
          labels:
            app: node-exporter
        spec:
          containers:
          - name: node-exporter
            image: prom/node-exporter
            ports:
            - containerPort: 9100
              name: metrics
    

    Aplicar el DaemonSet:

    kubectl apply -f node-exporter-daemonset.yaml
    
  2. Verificar la ejecución en todos los nodos

    kubectl get daemonset node-exporter
    kubectl get pods -o wide | grep node-exporter
    

    En Minikube (un solo nodo) verás un único Pod en estado Running sobre el nodo minikube.

  3. Etiquetar el nodo y añadir nodeSelector

    • Etiquetar el nodo minikube con disktype=ssd:

      kubectl label nodes minikube disktype=ssd
      
    • Modificar el DaemonSet para que solo se ejecute en nodos con esa etiqueta usando kubectl patch:

      kubectl patch daemonset node-exporter -p '{"spec":{"template":{"spec":{"nodeSelector":{"disktype":"ssd"}}}}}'
      
  4. Comportamiento observado

    • El Pod existente fue eliminado y recreado con la nueva especificación que incluye el nodeSelector.
    • Como el nodo minikube tiene la etiqueta disktype=ssd, el nuevo Pod se programa correctamente y sigue ejecutándose.
    • Si no se hubiera etiquetado el nodo, el DaemonSet habría eliminado el Pod y no habría creado ninguno nuevo (desired=0), quedando el agente sin ejecutarse hasta que se añadiera la etiqueta.

Actualización de Imagen con Patch

Contexto: Se descubre una vulnerabilidad crítica en la imagen nginx:1.21. El equipo de seguridad pide actualizar inmediatamente todos los Deployments que usen esa imagen a nginx:1.23.

Asignación:

  1. Crea un Deployment llamado seguro-web con 2 réplicas usando la imagen nginx:1.21.
  2. Usa el comando kubectl patch para actualizar la imagen del Deployment a nginx:1.23 sin usar set image.
  3. Verifica que el cambio se haya aplicado correctamente y que los nuevos Pods usen la imagen actualizada.

Pasos realizados

  1. Crear el Deployment

    kubectl create deployment seguro-web --image=nginx:1.21 --replicas=2
    
  2. Actualizar la imagen mediante patch

    kubectl patch deployment seguro-web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"nginx:1.23"}]'
    

    Explicación: Este comando reemplaza directamente el valor de la imagen en la ruta especificada del Deployment. Es una forma muy directa de modificar cualquier campo del manifiesto sin necesidad de usar comandos específicos.

  3. Verificar la actualización

    kubectl rollout status deployment seguro-web
    

    Luego, comprobar que todos los Pods usan la nueva imagen:

    kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'
    

    También podemos describir el Deployment:

    kubectl describe deployment seguro-web | grep Image
    

    La salida debe mostrar nginx:1.23 para todos los Pods.

Categories: DevOps 

See also