LabEx
EntrarÚnete

Cómo ejecutar comandos en Pods de Kubernetes al iniciar

KubernetesBeginner
Practicar Ahora

Introducción

Este tutorial lo guía a través de la ejecución de comandos en pods de Kubernetes al iniciar. Aprenderá cómo configurar comandos de inicio utilizando los campos command y args, ejecutar múltiples comandos y manejar fallos de inicio. Utilizaremos Minikube para crear un entorno local de Kubernetes donde puede practicar estos conceptos de primera mano.

Al final de este laboratorio (lab), entenderá cómo personalizar el comportamiento de sus pods de Kubernetes durante el inicio y garantizar una implementación fluida de la aplicación. Este conocimiento es esencial para configurar adecuadamente aplicaciones contenerizadas en un entorno de Kubernetes.

Configuración de su entorno de Kubernetes

En este paso, prepararemos nuestro entorno iniciando Minikube y comprendiendo los conceptos básicos de Kubernetes necesarios para este laboratorio (lab).

¿Qué es Kubernetes?

Kubernetes es una plataforma de código abierto diseñada para automatizar la implementación, escalado y operación de contenedores de aplicaciones. En el núcleo de Kubernetes se encuentran los Pods (cápsulas) - las unidades desplegables más pequeñas que se pueden crear y gestionar.

Inicio de Minikube

Minikube es una herramienta que le permite ejecutar Kubernetes de forma local. Vamos a iniciarlo:

minikube start --driver=docker

Este comando creará un clúster local de Kubernetes utilizando Docker como controlador. El proceso de inicio puede tardar unos minutos mientras se descargan los componentes necesarios.

Debería ver una salida similar a la siguiente:

😄  minikube v1.30.1 on Ubuntu 22.04
✨  Using the docker driver based on user configuration
📌  Using Docker driver with root privileges
👍  Starting control plane node minikube in cluster minikube
🚜  Pulling base image ...
🔥  Creating docker container (CPUs=2, Memory=2200MB) ...
🐳  Preparing Kubernetes v1.27.4 on Docker 24.0.4 ...
    ▪ Generating certificates and keys ...
    ▪ Booting up control plane ...
    ▪ Configuring RBAC rules ...
🔎  Verifying Kubernetes components...
🌟  Enabled addons: default-storageclass, storage-provisioner
💡  kubectl not found. If you need it, try: 'minikube kubectl -- get pods -A'
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

Verificación de la instalación

Vamos a verificar que todo está funcionando correctamente comprobando el estado de nuestro clúster de Minikube:

minikube status

Debería ver una salida que indique que Minikube está en ejecución:

minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

Ahora, vamos a comprobar que kubectl (la herramienta de línea de comandos de Kubernetes) está configurada correctamente:

kubectl get nodes

Debería ver un nodo (su instancia de Minikube) listado como Listo (Ready):

NAME       STATUS   ROLES           AGE     VERSION
minikube   Ready    control-plane   2m15s   v1.27.4

Comprensión de los Pods de Kubernetes

Un Pod es la unidad básica de ejecución de una aplicación de Kubernetes. Cada Pod representa un proceso en ejecución en su clúster y encapsula uno o más contenedores. Los Pods son efímeros por diseño, lo que significa que se pueden crear, destruir y recrear según sea necesario.

En Kubernetes, normalmente se definen los Pods en archivos YAML. Para este laboratorio (lab), ya hemos preparado algunos archivos YAML de ejemplo en su entorno.

Vamos al directorio donde se encuentran estos archivos:

cd ~/project/kubernetes-examples
ls -la

Debería ver los siguientes archivos:

total 20
drwxr-xr-x 2 labex labex 4096 Sep 21 10:00 .
drwxr-xr-x 3 labex labex 4096 Sep 21 10:00 ..
-rw-r--r-- 1 labex labex  193 Sep 21 10:00 basic-pod.yaml
-rw-r--r-- 1 labex labex  254 Sep 21 10:00 liveness-probe-pod.yaml
-rw-r--r-- 1 labex labex  312 Sep 21 10:00 multi-command-pod.yaml
-rw-r--r-- 1 labex labex  263 Sep 21 10:00 startup-command-pod.yaml

Ahora que nuestro entorno está configurado, estamos listos para comenzar a trabajar con los Pods de Kubernetes y aprender cómo ejecutar comandos al iniciar.

Creación de su primer Pod con comandos básicos de inicio

En este paso, crearemos nuestro primer Pod de Kubernetes y entenderemos cómo ejecuta comandos al iniciar. Examinaremos el campo command que define lo que el contenedor debe ejecutar cuando se inicia.

Exploración de la configuración básica de un Pod

Primero, examinemos la configuración de un Pod básico. Abra el archivo basic-pod.yaml con el editor nano:

nano basic-pod.yaml

Verá un archivo YAML con el siguiente contenido:

apiVersion: v1
kind: Pod
metadata:
  name: basic-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash", "-c", "echo 'Pod is running' && sleep 3600"]

Esta configuración define:

  • Un Pod llamado basic-pod
  • Un solo contenedor llamado ubuntu que utiliza la imagen ubuntu:20.04
  • Un comando de inicio que muestra un mensaje y luego se queda en espera durante 3600 segundos (1 hora)

El campo command especifica el ejecutable que se ejecutará cuando el contenedor se inicie. En este caso, estamos ejecutando la shell /bin/bash con la bandera -c, que nos permite pasar una cadena de comandos para ejecutar.

Presione Ctrl+X para salir del editor nano.

Creación del Pod

Vamos a crear este Pod en nuestro clúster de Kubernetes:

kubectl apply -f basic-pod.yaml

Debería ver una salida como la siguiente:

pod/basic-pod created

Comprobación del estado del Pod

Ahora, comprobemos si nuestro Pod se está ejecutando correctamente:

kubectl get pods

Debería ver una salida similar a la siguiente:

NAME        READY   STATUS    RESTARTS   AGE
basic-pod   1/1     Running   0          30s

Esto indica que nuestro Pod se está ejecutando correctamente. El 1/1 en la columna READY significa que un contenedor está en ejecución de un contenedor esperado.

Visualización de los registros del Pod

Para ver la salida de nuestro comando de inicio, podemos comprobar los registros del Pod:

kubectl logs basic-pod

Debería ver lo siguiente:

Pod is running

Esto confirma que nuestro comando de inicio se ejecutó correctamente.

Exploración del contenedor en ejecución

Examinemos lo que está sucediendo dentro de nuestro contenedor ejecutando una shell interactiva:

kubectl exec -it basic-pod -- /bin/bash

Ahora está dentro de la shell del contenedor. Verifiquemos que nuestro proceso se está ejecutando:

ps aux

Debería ver que el comando sleep se está ejecutando, que es parte de nuestro comando de inicio:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   4112  3372 ?        Ss   10:05   0:00 /bin/bash -c echo 'Pod is running' && sleep 3600
root         7  0.0  0.0   4112  3536 pts/0    Ss   10:06   0:00 /bin/bash
root        14  0.0  0.0   5900  2928 pts/0    R+   10:06   0:00 ps aux
root        15  0.0  0.0   2512   580 ?        S    10:06   0:00 sleep 3600

El proceso con PID 1 es nuestro comando de inicio, y el comando sleep 3600 se está ejecutando como un proceso separado.

Salga de la shell del contenedor escribiendo:

exit

Comprensión del ciclo de vida del Pod

Cuando crea un Pod, este pasa por varias fases:

  1. Pending (Pendiente): El Pod ha sido aceptado por Kubernetes pero aún no se está ejecutando.
  2. Running (En ejecución): El Pod se está ejecutando con todos sus contenedores.
  3. Succeeded (Completado): Todos los contenedores en el Pod se han terminado correctamente.
  4. Failed (Fallido): Todos los contenedores se han terminado, y al menos un contenedor ha fallado.
  5. Unknown (Desconocido): No se puede determinar el estado del Pod.

Nuestro Pod está en el estado Running porque nuestro proceso principal (sleep 3600) todavía se está ejecutando. Cuando este proceso se complete o se detenga, el Pod pasará al estado Succeeded o Failed, dependiendo del código de salida.

Ahora comprende cómo crear un Pod básico y ejecutar comandos al iniciar utilizando el campo command.

Uso de Command y Args para la configuración de inicio

En este paso, aprenderemos cómo utilizar los campos command y args juntos para configurar comportamientos de inicio más complejos en los Pods de Kubernetes.

Comprensión de Command y Args

Kubernetes ofrece dos formas principales de especificar el comando que se ejecuta cuando un contenedor se inicia:

  1. command: Especifica el ejecutable a ejecutar (similar al ENTRYPOINT de Docker).
  2. args: Especifica los argumentos a pasar al comando (similar al CMD de Docker).

Utilizar estos campos de forma separada o juntos te brinda flexibilidad en cómo se inician tus contenedores.

Exploración del Pod con comando de inicio

Examinemos el archivo startup-command-pod.yaml:

nano startup-command-pod.yaml

Verás la siguiente configuración:

apiVersion: v1
kind: Pod
metadata:
  name: startup-command-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash"]
      args:
        ["-c", "echo 'Custom startup message' > /tmp/startup.txt && sleep 3600"]

En esta configuración:

  • El campo command especifica que queremos ejecutar /bin/bash.
  • El campo args proporciona los argumentos a pasar a bash: -c y la cadena que contiene nuestros comandos.

Esta separación de comando y argumentos hace que la configuración sea más legible y mantenible.

Presiona Ctrl+X para salir del editor nano.

Creación del Pod con comando de inicio

Vamos a crear este Pod:

kubectl apply -f startup-command-pod.yaml

Deberías ver:

pod/startup-command-pod created

Comprobación del estado del Pod

Verifica que el Pod esté en ejecución:

kubectl get pods startup-command-pod

Deberías ver:

NAME                  READY   STATUS    RESTARTS   AGE
startup-command-pod   1/1     Running   0          30s

Verificación del comando de inicio

Ahora, verifiquemos que nuestro comando de inicio se haya ejecutado correctamente comprobando si creó el archivo esperado:

kubectl exec startup-command-pod -- cat /tmp/startup.txt

Deberías ver:

Custom startup message

Esto confirma que nuestro comando se ejecutó correctamente y creó el archivo con el contenido especificado.

Comprensión de la diferencia entre Command y Args

Es importante entender la relación entre command y args:

  1. Si solo especificas command, se anula el ENTRYPOINT predeterminado de la imagen del contenedor.
  2. Si solo especificas args, se anula el CMD predeterminado de la imagen del contenedor.
  3. Si especificas tanto command como args, se anulan tanto el ENTRYPOINT como el CMD.

Veamos qué sucede si modificamos la configuración de nuestro Pod. Crea un nuevo archivo llamado modified-command-pod.yaml:

nano modified-command-pod.yaml

Agrega el siguiente contenido:

apiVersion: v1
kind: Pod
metadata:
  name: modified-command-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/echo"]
      args: ["This message is printed by echo"]

Guarda y sal con Ctrl+X, seguido de Y y Enter.

Ahora, vamos a crear este Pod:

kubectl apply -f modified-command-pod.yaml

Deberías ver:

pod/modified-command-pod created

Comprueba los registros para ver qué sucedió:

kubectl logs modified-command-pod

Deberías ver:

This message is printed by echo

Observa cómo el Pod ejecutó el comando /bin/echo con el argumento especificado y luego se terminó, ya que echo sale después de imprimir su salida.

Comprueba el estado del Pod:

kubectl get pods modified-command-pod

Deberías ver algo como:

NAME                   READY   STATUS      RESTARTS   AGE
modified-command-pod   0/1     Completed   0          45s

El estado Completed indica que el Pod se ejecutó hasta el final y salió correctamente.

Ahora entiendes cómo utilizar command y args juntos para configurar el comportamiento de inicio en los Pods de Kubernetes.

Ejecución de múltiples comandos y manejo de fallos de inicio

En este paso, aprenderemos cómo ejecutar múltiples comandos al iniciar un Pod y cómo manejar los fallos de inicio utilizando comprobaciones de salud.

Ejecución de múltiples comandos

A menudo, es necesario ejecutar múltiples comandos cuando un contenedor se inicia. Hay varias formas de hacer esto en Kubernetes:

  1. Encadenar comandos utilizando operadores de shell (&&, ;, etc.).
  2. Utilizar un archivo de script.
  3. Utilizar un contenedor de inicialización (init container).

Exploremos el primer método examinando el archivo multi-command-pod.yaml:

nano multi-command-pod.yaml

Verás:

apiVersion: v1
kind: Pod
metadata:
  name: multi-command-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args:
        [
          "echo 'First command' > /tmp/first.txt && echo 'Second command' > /tmp/second.txt && sleep 3600"
        ]

Esta configuración encadena múltiples comandos utilizando el operador &&, que ejecuta cada comando solo si el anterior tiene éxito.

Presiona Ctrl+X para salir del editor.

Vamos a crear este Pod:

kubectl apply -f multi-command-pod.yaml

Deberías ver:

pod/multi-command-pod created

Ahora, verifiquemos que ambos comandos se hayan ejecutado comprobando los archivos creados:

kubectl exec multi-command-pod -- cat /tmp/first.txt

Deberías ver:

First command

Y para el segundo archivo:

kubectl exec multi-command-pod -- cat /tmp/second.txt

Deberías ver:

Second command

Manejo de fallos de inicio con comprobaciones de salud

Kubernetes proporciona mecanismos para detectar y manejar fallos de inicio:

  1. Liveness Probes (Comprobaciones de vida): Comprueban si el contenedor está en ejecución; si no lo está, Kubernetes lo reiniciará.
  2. Readiness Probes (Comprobaciones de preparación): Comprueban si el contenedor está listo para recibir tráfico.
  3. Startup Probes (Comprobaciones de inicio): Comprueban si la aplicación se ha iniciado; son útiles para contenedores que tardan en iniciar.

Examinemos un Pod que utiliza una comprobación de vida (liveness probe):

nano liveness-probe-pod.yaml

Verás:

apiVersion: v1
kind: Pod
metadata:
  name: liveness-probe-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args: ["touch /tmp/healthy && sleep 3600"]
      livenessProbe:
        exec:
          command: ["cat", "/tmp/healthy"]
        initialDelaySeconds: 5
        periodSeconds: 5

En esta configuración:

  • El contenedor crea un archivo /tmp/healthy al iniciar.
  • La comprobación de vida comprueba este archivo cada 5 segundos.
  • Si el archivo falta, Kubernetes considera que el contenedor no está saludable y lo reinicia.

Presiona Ctrl+X para salir del editor.

Vamos a crear este Pod:

kubectl apply -f liveness-probe-pod.yaml

Deberías ver:

pod/liveness-probe-pod created

Comprueba que el Pod esté en ejecución:

kubectl get pods liveness-probe-pod

Deberías ver:

NAME                 READY   STATUS    RESTARTS   AGE
liveness-probe-pod   1/1     Running   0          30s

Ahora, veamos qué sucede si eliminamos el archivo de comprobación de salud:

kubectl exec liveness-probe-pod -- rm /tmp/healthy

Espera unos 10 segundos y luego comprueba el estado del Pod de nuevo:

kubectl get pods liveness-probe-pod

Deberías ver que el contenedor se ha reiniciado:

NAME                 READY   STATUS    RESTARTS   AGE
liveness-probe-pod   1/1     Running   1          60s

El contador de reinicios (RESTARTS) ha aumentado a 1, lo que indica que Kubernetes detectó el estado no saludable y reinició el contenedor.

Verifiquemos que el archivo de comprobación de salud exista de nuevo (debería haber sido recreado por el comando de inicio cuando el contenedor se reinició):

kubectl exec liveness-probe-pod -- ls -la /tmp/healthy

Deberías ver que el archivo existe de nuevo:

-rw-r--r-- 1 root root 0 Sep 21 10:30 /tmp/healthy

Esto demuestra cómo Kubernetes puede recuperarse automáticamente de fallos de inicio y mantener el estado deseado de tus aplicaciones.

Creación de un script de inicio personalizado

Para una inicialización más compleja, es posible que desees utilizar un script de inicio personalizado. Vamos a crear un Pod que utilice un script de shell para el inicio:

nano script-pod.yaml

Agrega el siguiente contenido:

apiVersion: v1
kind: Pod
metadata:
  name: script-pod
spec:
  containers:
    - name: ubuntu
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args:
        - |
          cat > /tmp/startup.sh << 'EOF'
          #!/bin/bash
          echo "Script started at $(date)" > /tmp/script-log.txt
          echo "Creating configuration files..." >> /tmp/script-log.txt
          mkdir -p /tmp/config
          echo "app_name=MyApp" > /tmp/config/app.conf
          echo "version=1.0" >> /tmp/config/app.conf
          echo "Script completed successfully" >> /tmp/script-log.txt
          EOF
          chmod +x /tmp/startup.sh
          /tmp/startup.sh
          sleep 3600

Esta configuración:

  1. Crea un script de inicio en el contenedor.
  2. Lo hace ejecutable.
  3. Ejecuta el script.
  4. Mantiene el contenedor en ejecución con un comando de espera (sleep).

Guarda y sal con Ctrl+X, seguido de Y y Enter.

Vamos a crear este Pod:

kubectl apply -f script-pod.yaml

Deberías ver:

pod/script-pod created

Espera un momento para que el Pod se inicie y luego comprueba su estado:

kubectl get pods script-pod

Deberías ver:

NAME         READY   STATUS    RESTARTS   AGE
script-pod   1/1     Running   0          30s

Ahora, comprobemos la salida de nuestro script:

kubectl exec script-pod -- cat /tmp/script-log.txt

Deberías ver algo como:

Script started at Tue Sep 21 10:35:42 UTC 2023
Creating configuration files...
Script completed successfully

Y verifiquemos que el archivo de configuración se haya creado:

kubectl exec script-pod -- cat /tmp/config/app.conf

Deberías ver:

app_name=MyApp
version=1.0

Esto demuestra cómo utilizar scripts de inicio complejos para inicializar tus contenedores en Kubernetes.

Mejores prácticas y aplicaciones en el mundo real

En este último paso, exploraremos las mejores prácticas para ejecutar comandos en los Pods de Kubernetes al iniciar y crearemos un ejemplo de aplicación en el mundo real que implemente estas prácticas.

Mejores prácticas para comandos de inicio

Al configurar comandos de inicio para los Pods de Kubernetes, considera las siguientes mejores prácticas:

  1. Mantén los comandos de inicio idempotentes: Los comandos deben ser seguros para ejecutarse múltiples veces sin causar problemas.
  2. Utiliza comprobaciones de salud: Implementa comprobaciones de vida (liveness) y preparación (readiness) para verificar un inicio exitoso.
  3. Maneja los fallos de manera elegante: Incluye manejo de errores en tus scripts de inicio.
  4. Separa las responsabilidades: Utiliza contenedores de inicialización (init containers) para tareas de inicialización separadas de tu aplicación principal.
  5. Limita el tiempo de inicio: Mantén la inicialización rápida para reducir el tiempo de despliegue.
  6. Utiliza variables de entorno: Haz que tus comandos de inicio sean configurables a través de variables de entorno.
  7. Registra el progreso del inicio: Genera registros claros para la resolución de problemas.

Uso de contenedores de inicialización para tareas de inicio

Los contenedores de inicialización se ejecutan antes de que los contenedores de la aplicación se inicien y son ideales para tareas de configuración. Vamos a crear un Pod con un contenedor de inicialización:

nano init-container-pod.yaml

Agrega el siguiente contenido:

apiVersion: v1
kind: Pod
metadata:
  name: init-container-pod
spec:
  initContainers:
    - name: init-config
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args:
        - |
          echo "Initializing configuration..."
          mkdir -p /work-dir/config
          echo "database_url=mysql://user:password@db:3306/mydb" > /work-dir/config/db.conf
          echo "api_key=1234567890" > /work-dir/config/api.conf
          echo "Initialization complete"
      volumeMounts:
        - name: shared-volume
          mountPath: /work-dir
  containers:
    - name: app
      image: ubuntu:20.04
      command: ["/bin/bash", "-c"]
      args:
        - |
          echo "Application starting..."
          echo "Reading configuration:"
          cat /work-dir/config/db.conf
          cat /work-dir/config/api.conf
          echo "Application running..."
          sleep 3600
      volumeMounts:
        - name: shared-volume
          mountPath: /work-dir
  volumes:
    - name: shared-volume
      emptyDir: {}

En esta configuración:

  1. El contenedor de inicialización init-config se ejecuta primero y crea archivos de configuración.
  2. Ambos contenedores comparten un volumen llamado shared-volume.
  3. El contenedor principal de la aplicación lee la configuración creada por el contenedor de inicialización.

Guarda y sal con Ctrl+X, seguido de Y y Enter.

Vamos a crear este Pod:

kubectl apply -f init-container-pod.yaml

Deberías ver:

pod/init-container-pod created

Comprueba el estado del Pod:

kubectl get pods init-container-pod

Deberías ver que el Pod está en ejecución:

NAME                 READY   STATUS    RESTARTS   AGE
init-container-pod   1/1     Running   0          30s

Ahora, comprobemos los registros del contenedor principal:

kubectl logs init-container-pod -c app

Deberías ver algo como:

Application starting...
Reading configuration:
database_url=mysql://user:password@db:3306/mydb
api_key=1234567890
Application running...

Esto confirma que el contenedor de inicialización creó con éxito los archivos de configuración y que el contenedor principal pudo leerlos.

Ejemplo en el mundo real: Aplicación web con comprobación de base de datos

Vamos a crear un ejemplo más realista: una aplicación web que comprueba la disponibilidad de la base de datos antes de iniciar:

nano webapp-pod.yaml

Agrega el siguiente contenido:

apiVersion: v1
kind: Pod
metadata:
  name: webapp-pod
spec:
  initContainers:
    - name: wait-for-db
      image: busybox:1.28
      command: ["/bin/sh", "-c"]
      args:
        - |
          echo "Checking for database availability..."
          ## In a real scenario, this would check an actual database
          ## For this example, we'll simulate success after a short delay
          sleep 5
          echo "Database is available"
          touch /tmp/db-ready
      volumeMounts:
        - name: shared-volume
          mountPath: /tmp
  containers:
    - name: webapp
      image: nginx:1.19
      ports:
        - containerPort: 80
      command: ["/bin/sh", "-c"]
      args:
        - |
          if [ -f /tmp/db-ready ]; then
            echo "Database connection verified, starting web application..."
            ## Customize nginx configuration
            echo "<h1>Web Application Started Successfully</h1>" > /usr/share/nginx/html/index.html
            echo "<p>Connected to database</p>" >> /usr/share/nginx/html/index.html
            ## Start nginx
            nginx -g 'daemon off;'
          else
            echo "Error: Database not available"
            exit 1
          fi
      volumeMounts:
        - name: shared-volume
          mountPath: /tmp
      readinessProbe:
        httpGet:
          path: /
          port: 80
        initialDelaySeconds: 5
        periodSeconds: 5
  volumes:
    - name: shared-volume
      emptyDir: {}

Esta configuración:

  1. Utiliza un contenedor de inicialización para comprobar la disponibilidad de la base de datos (simulado).
  2. El contenedor principal comprueba la existencia de un archivo creado por el contenedor de inicialización antes de iniciar.
  3. Incluye una comprobación de preparación para verificar que la aplicación está sirviendo tráfico.
  4. Utiliza un volumen compartido para la comunicación entre contenedores.

Guarda y sal con Ctrl+X, seguido de Y y Enter.

Vamos a crear este Pod:

kubectl apply -f webapp-pod.yaml

Deberías ver:

pod/webapp-pod created

Espera un momento para que el Pod se inicie completamente y luego comprueba su estado:

kubectl get pods webapp-pod

Deberías ver:

NAME         READY   STATUS    RESTARTS   AGE
webapp-pod   1/1     Running   0          30s

El 1/1 en la columna READY indica que la comprobación de preparación ha tenido éxito.

Vamos a hacer un reenvío de puertos para acceder a la aplicación web:

kubectl port-forward webapp-pod 8080:80 &

Este comando se ejecuta en segundo plano (debido al &). Ahora podemos acceder a la aplicación web utilizando curl:

curl http://localhost:8080

Deberías ver:

<h1>Web Application Started Successfully</h1>
<p>Connected to database</p>

Esto confirma que nuestra aplicación se inicializó correctamente, verificó la disponibilidad de la base de datos y ahora está sirviendo tráfico.

Detén el proceso de reenvío de puertos:

pkill -f "kubectl port-forward"

Limpieza

Antes de concluir el laboratorio, vamos a limpiar los recursos que creamos:

kubectl delete pod basic-pod startup-command-pod modified-command-pod multi-command-pod liveness-probe-pod script-pod init-container-pod webapp-pod

Deberías ver:

pod "basic-pod" deleted
pod "startup-command-pod" deleted
pod "modified-command-pod" deleted
pod "multi-command-pod" deleted
pod "liveness-probe-pod" deleted
pod "script-pod" deleted
pod "init-container-pod" deleted
pod "webapp-pod" deleted

Ahora has aprendido cómo ejecutar comandos en los Pods de Kubernetes al iniciar, ejecutar múltiples comandos, manejar fallos y aplicar mejores prácticas en escenarios del mundo real.

Resumen

En este laboratorio, has aprendido cómo ejecutar comandos en los Pods de Kubernetes al iniciar. Has adquirido experiencia práctica en:

  • Configurar un entorno de Kubernetes utilizando Minikube.
  • Crear y gestionar Pods con comandos de inicio específicos.
  • Utilizar los campos command y args para configurar el comportamiento de los contenedores.
  • Ejecutar múltiples comandos utilizando operadores de shell y scripts.
  • Manejar fallos de inicio con comprobaciones de salud.
  • Implementar mejores prácticas con contenedores de inicialización (init containers).
  • Construir aplicaciones del mundo real que requieran una inicialización adecuada.

Estas habilidades son esenciales para desplegar aplicaciones contenerizadas en entornos de Kubernetes. Al configurar correctamente los comandos de inicio, puedes asegurarte de que tus aplicaciones se inicialicen correctamente, verifiquen las dependencias y manejen los errores de manera elegante.

A medida que continúes tu viaje en Kubernetes, recuerda que una inicialización adecuada de las aplicaciones es una parte crítica de la construcción de sistemas confiables, escalables y mantenibles.

Relacionado Kubernetes Cursos
Kubernetes para Principiantes

Kubernetes para Principiantes

kubernetesdevops
Kubernetes para Principiantes

Kubernetes para Principiantes

kubernetesdevops