Laboratorio. Ejercicios prácticos enfocado a ConfigMaps (Parte 1)

 Ejercicio: Crear y usar un ConfigMap para una aplicación

En este ejercicio, aprenderás a:

  1. Crear un ConfigMap desde un archivo y desde un comando.
  2. Montar el ConfigMap como variables de entorno en un Pod.
  3. Montar el ConfigMap como un archivo en un contenedor. 

Escenario

Tienes una aplicación que necesita configurar dos parámetros:

  • APP_MODE: El modo en que la aplicación se ejecutará (production o debug).
  • APP_PORT: El puerto en el que se ejecutará (por ejemplo, 8080).

Usarás un ConfigMap para almacenar estos parámetros y consumirlos desde un Pod.

Pasos

1. Crear un ConfigMap desde un archivo (Propiedades (propertie), no unYaml)

Primero, crea un archivo llamado app-config.properties con los valores de configuración:

APP_MODE=production
APP_PORT=8080

Luego, crea el ConfigMap desde este archivo:

kubectl create configmap app-config --from-file=app-config.properties

Verifica que el ConfigMap se haya creado correctamente:
kubectl get configmap app-config -o yaml
2. Crear un Pod que use el ConfigMap como variables de entorno
Crea un archivo YAML llamado pod-env-configmap.yaml para definir un Pod 
que usa el ConfigMap:
apiVersion: v1
kind: Pod
metadata:
  name: app-pod-env
spec:
  containers:
  - name: app-container
    image: busybox
    command: [ "sh", "-c", "env && sleep 3600" ] # Muestra las variables de entorno y espera
    envFrom:
    - configMapRef:
        name: app-config # Asocia el ConfigMap
Aplica el Pod:
kubectl apply -f pod-env-configmap.yaml
Verifica que el Pod esté corriendo:
kubectl get pod app-pod-env

Revisa las variables de entorno en el contenedor:
kubectl exec -it app-pod-env -- env
Deberías ver las variables APP_MODE=production y APP_PORT=8080.
3. Crear un Pod que monte el ConfigMap como un archivo:

Crea otro archivo YAML llamado pod-volume-configmap.yaml para montar el ConfigMap 
como un volumen:
apiVersion: v1
kind: Pod
metadata:
  name: app-pod-volume
spec:
  containers:
  - name: app-container
    image: busybox
    command: [ "sh", "-c", "cat /config/app-config.properties && sleep 3600" ] 
# Muestra el contenido del archivo
    volumeMounts:
    - name: config-volume
      mountPath: /config # Monta el ConfigMap en /config
  volumes:
  - name: config-volume
    configMap:
      name: app-config # Asocia el ConfigMap
Aplica este Pod:
kubectl apply -f pod-volume-configmap.yaml

 Verifica el contenido del archivo montado:
kubectl exec -it app-pod-volume -- cat /config/app-config.properties

Deberías ver:

APP_MODE=production
APP_PORT=8080
4. Limpieza
Cuando termines el ejercicio, elimina los recursos:
kubectl delete pod app-pod-env app-pod-volume
kubectl delete configmap app-config


Objetivos del ejercicio
  • Crear ConfigMaps desde un archivo.
  • Usar ConfigMaps como variables de entorno en un contenedor.
  • Montar ConfigMaps como archivos en un contenedor.

Siguientes pasos sugeridos
  • Intenta montar el mismo ConfigMap como un archivo en un Pod para explorar otro caso de uso:
    • Usar la configuración de la aplicación como un archivo que la aplicación puede leer.
  • Prueba hacer cambios dinámicos en el ConfigMap y observa cómo afectan a los Pods.
Teoría para entenderlo bien:

Uso de fichero de properties Vs Yaml:

En este caso se usa un archivo de propiedades (app-config.properties) porque es
un enfoque común en aplicaciones que ya tienen configuraciones existentes
en formato plano. 
Sin embargo, si prefieres un flujo más nativo de Kubernetes, puedes definir 
y gestionar el ConfigMap directamente en YAML.

Vamos a desglosar el primer YAML del ejercicio:

apiVersion: v1
kind: Pod
metadata:
  name: app-pod-env
spec:
  containers:
  - name: app-container
    image: busybox
    command: [ "sh", "-c", "env && sleep 3600" ] # Muestra las variables de entorno y espera
    envFrom:
    - configMapRef:
        name: app-config # Asocia el ConfigMap

1. apiVersion
apiVersion: v1

  • Significa: Define la versión de la API de Kubernetes que se usará para gestionar
 este recurso.
  • Siempre es v1 para Pods: Los pods pertenecen a los recursos básicos en Kubernetes
 y están en la API estable v1. 
Para otros recursos como Deployments o Services, la versión puede cambiar 
(por ejemplo, apps/v1).
2. kind
kind: Pod

  • Significa: Especifica el tipo de recurso que estás definiendo. 
Aquí Pod indica que estás creando un pod.
  • Otros posibles valores: Deployment, Service, ConfigMap, etc., 
dependiendo del recurso que quieras crear.
3. metadata
metadata:
   name: app-pod-env

  • Significa: Información sobre el recurso, como el nombre y las etiquetas.
  • name:
    • Define el nombre del pod (app-pod-env).
    • Este nombre debe ser único en el namespace donde se despliega.
    • Puedes usar este nombre para interactuar con el pod 
(kubectl get pod app-pod-env).
4. spec
La sección spec define la configuración del pod, incluyendo los contenedores 
y cómo se comportarán. Veamos cada campo dentro de spec:
4.1 containers
  containers:
  - name: app-container
    image: busybox

  • containers: Lista de contenedores que estarán dentro del pod.
  • name: app-container:
    • Es el nombre del contenedor dentro del pod.
    • No tiene que ser único a nivel del clúster, pero sí dentro del pod.
  • image: busybox:
    • Especifica la imagen de contenedor que se usará.
    • Busybox:
      • Es una imagen muy ligera basada en Linux, ideal para tareas rápidas
o utilidades de depuración.
      • Contiene herramientas básicas como sh, cat, env, etc.
4.2 command
    command: [ "sh", "-c", "env && sleep 3600" ]

  • Define el comando que se ejecutará cuando el contenedor arranque.
    • sh: Invoca el intérprete de comandos de Busybox.
    • -c: Permite ejecutar un comando como cadena.
    • env: Lista todas las variables de entorno disponibles en el contenedor.
    • &&: Ejecuta otro comando después si el anterior tuvo éxito.
    • sleep 3600: Hace que el contenedor espere 3600 segundos (1 hora) antes
 de terminar.
  • ¿Por qué usar esto?:
    • env muestra las variables de entorno.
    • sleep 3600 evita que el contenedor termine inmediatamente, 
permitiendo inspeccionar el pod con comandos como kubectl exec.
4.3 envFrom
    envFrom:
    - configMapRef:
        name: app-config

  • Significa: envFrom toma las claves y valores de un ConfigMap
(en este caso, app-config) y las convierte en variables de entorno
 dentro del contenedor.
  • Cómo funciona:
    1. ConfigMap: Debe existir previamente y contener claves y valores. Ejemplo:
      apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_MODE: production
  APP_PORT: 8080

    2. configMapRef:
      • Hace referencia al ConfigMap app-config.
    3. Efecto en el contenedor:
      • Todas las claves del ConfigMap (APP_MODE, APP_PORT) 
se convierten en variables de entorno en el contenedor.
      • Puedes verificarlas con el comando env.
Comportamiento del pod al ejecutarlo
  1. Cuando el pod se crea:
    • Kubernetes programa el pod en un nodo.
    • El nodo descarga la imagen busybox y la ejecuta.
  2. Dentro del contenedor:
    • Se ejecuta el comando: env && sleep 3600.
    • El contenedor imprime todas las variables de entorno, incluyendo 
las que provienen del ConfigMap:
      APP_MODE=production
APP_PORT=8080

    • Luego, espera 3600 segundos antes de finalizar.
Resumen
  • apiVersion: Define la versión de la API de Kubernetes.
  • kind: Especifica el tipo de recurso, aquí un Pod.
  • metadata: Proporciona el nombre del pod para identificarlo.
  • containers: Define los contenedores dentro del pod.
    • image: busybox: Una imagen ligera basada en Linux.
    • command: Ejecuta un comando para listar variables de entorno (env) y mantener el contenedor vivo (sleep 3600).
  • envFrom: Carga las claves y valores de un ConfigMap (app-config) como variables de entorno dentro del contenedor.

Comentarios

Publicar un comentario