Todavía estoy en medio de esta travesía. He pasado varias noches estudiando, he conversado con profesionales que ya tienen su chaqueta, y he superado varios de esos exámenes. Si hay algo que he aprendido en este proceso es que cada certificación representa un desafío importante, pero la satisfacción de aprobar vale la pena.

Permíteme compartir cómo ha sido esta aventura desde mi perspectiva personal.

El punto de partida: Convertirse en Kubestronaut 🧑‍🚀

Todo comienza con un objetivo ambicioso pero alcanzable. Para obtener el título de Kubestronaut, debes demostrar un dominio integral de Kubernetes aprobando cinco certificaciones que abarcan los aspectos fundamentales de esta tecnología.

Las cinco certificaciones requeridas

Para alcanzar el estatus de Kubestronaut, necesitas aprobar estos cinco exámenes:

Exámenes teóricos (opción múltiple, sin acceso a documentación):

• KCNA (Kubernetes and Cloud Native Associate): Los cimientos teóricos de todo el ecosistema Cloud Native

• KCSA (Kubernetes and Cloud Native Security Associate): Una inmersión profunda en los principios de seguridad en la nube

Exámenes prácticos (con acceso a documentación oficial):

• CKA (Certified Kubernetes Administrator): Valida tu capacidad para mantener un clúster en funcionamiento sin importar los obstáculos

• CKAD (Certified Kubernetes Application Developer): Enfocado en el despliegue y la gestión eficiente de aplicaciones

• CKS (Certified Kubernetes Security Specialist): El más desafiante, donde la seguridad es protagonista

Mi recomendación personal: El orden importa

Después de mi experiencia y conversaciones con algunos Kubestronauts, te comparto el orden que considero más efectivo para abordar estas certificaciones:

1. KCNA - Comienza con los fundamentos teóricos del ecosistema

2. KCSA - Profundiza en los conceptos de seguridad

3. CKA - Tu primer examen práctico, estableciendo las bases administrativas

4. CKAD - Construye sobre lo aprendido, ahora desde la perspectiva del desarrollador

5. CKS - Especialización en seguridad de Kubernetes, requiere tener el CKA aprobado

¿Por qué este orden? Iniciar con la parte teórica te proporciona una comprensión sólida del ecosistema antes de enfrentarte a la terminal. Los exámenes KCNA y KCSA te darán el contexto y vocabulario necesarios para aprovechar mejor la documentación durante los exámenes prácticos. Además, el CKS requiere haber aprobado previamente el CKA, por lo que tiene sentido dejarlo para el final cuando ya dominas tanto la teoría como la práctica.

La recompensa

Cuando finalmente logras aprobar las cinco certificaciones y mantenerlas vigentes simultáneamente, llega el momento de la verdad. Las recompensas van más allá del reconocimiento: recibes la exclusiva chaqueta Kubestronaut (definitivamente un buen trofeo 🧥), tu insignia digital verificable, acceso a una comunidad privada en Slack donde intercambias conocimientos con otros expertos, y descuentos para continuar tu formación.

El siguiente nivel: Golden Kubestronaut 🌟

Alcanzar el nivel Kubestronaut es solo el comienzo. Para quienes quieren ir más allá, existe el Golden Kubestronaut —un nivel para aquellos que no solo dominan Kubernetes, sino que conocen a fondo gran parte del ecosistema Cloud Native reconocido por la CNCF.

Un viaje a través del ecosistema

La lista de certificaciones requeridas se expande considerablemente. Además de mantener las cinco certificaciones Kubestronaut, debes conquistar las siguientes:

LFCS (Linux Foundation Certified SysAdmin): El viaje comienza estableciendo una base sólida en Linux. Es un examen práctico puro, donde solo cuentas con la terminal y tu conocimiento.

A partir de ahí, te sumerges en un océano de herramientas especializadas. La mayoría son exámenes teóricos que ponen a prueba tu comprensión profunda:

• PCA: Prometheus para monitoreo y alertas. Te evalúa en métricas, consultas PromQL y mejores prácticas de observabilidad.

• CCA: Cilium para networking avanzado y seguridad. Cubre eBPF, políticas de red y observabilidad de tráfico.

• CAPA: Argo Project, enfocado en ArgoCD para GitOps, Argo Workflows para orquestación y las demás herramientas del ecosistema Argo.

• CGOA: GitOps como metodología. Principios, patrones y mejores prácticas para la entrega continua declarativa.

• CBA: Backstage para portales de desarrolladores. Construcción de catálogos de servicios y experiencias de desarrollo internas.

• OTCA: OpenTelemetry para observabilidad unificada. Trazas distribuidas, métricas y logs en un estándar abierto.

• KCA: Kyverno para políticas declarativas. Validación, mutación y generación de recursos de Kubernetes.

Mención especial merece el ICA (Istio Certified Associate), que combina preguntas teóricas con un laboratorio práctico. Te obliga a cambiar de enfoque a mitad del examen, algo bastante particular.

Los beneficios adicionales

Alcanzar el estatus Golden Kubestronaut trae consigo beneficios adicionales: una mochila dorada, un gorro de edición limitada, suscripciones a plataformas de bienestar, una entrada gratuita anual a cualquier Kubernetes Community Day, y descuentos para KubeCon y futuras certificaciones. Es un reconocimiento importante a tu dedicación y conocimiento.

Lecciones desde las trincheras 🔥

Aunque todavía me faltan por aprobar el CKS, ICA, CCA, CBA y LFCS para completar mi camino hacia el Golden Kubestronaut, quiero compartir lo que he aprendido hasta ahora y lo que me han contado otros compañeros de esta aventura.

Cada examen tiene su propia personalidad. El CKA y CKAD me enseñaron mucho sobre la administración y desarrollo en Kubernetes. Según quienes ya pasaron por el CKS, es donde la seguridad se vuelve protagonista con escenarios complejos. Y el LFCS, me cuentan, es un regreso a las bases de administración de sistemas Linux, donde solo tienes la terminal como herramienta. Cada certificación aprobada te da energía para continuar, aunque hay momentos donde el cansancio y las dudas aparecen.

Consejos que marcan la diferencia

Estas son algunas estrategias que me han funcionado y que otros Kubestronauts también recomiendan:

Compromiso con fecha límite: Cuando compres un voucher, agenda el examen de inmediato. Tener una fecha en el calendario te obliga a estudiar en serio. La presión de una fecha límite realmente funciona.

Domina la navegación de documentación: En los exámenes prácticos (CKA, CKAD, CKS), saber buscar rápido en la documentación oficial es tan importante como conocer los comandos. Practica hasta que encuentres cualquier cosa en segundos.

Preparación para exámenes teóricos: Sin atajos. Haz resúmenes y repasa hasta que los conceptos sean claros.

La práctica es clave: Monta tu propio clúster con minikube o kind, usa las sesiones de práctica de killer.sh (vienen con CKA/CKAD/CKS/LFCS), y practica hasta que kubectl sea natural para ti.

Únete a la comunidad: Los grupos de estudio locales de CNCF (https://community.cncf.io/chapters/) son un gran apoyo. Compartir experiencias y dudas con otros que están en el mismo camino hace toda la diferencia.

Invierte en buenos recursos: Plataformas como KodeKloud ofrecen laboratorios y cursos especializados. Aunque son de pago, la inversión vale la pena por la calidad del contenido y la práctica que obtienes.

Busca descuentos para certificaciones: Las certificaciones tienen un costo considerable, pero siempre hay formas de ahorrar. El repositorio https://github.com/techiescamp/linux-foundation-coupon mantiene cupones activos cada mes. El mejor momento para comprar suele ser Black Friday.

La misión continúa...

El camino hacia el Golden Kubestronaut es arduo y exigente, pero puedo asegurarte que cada hora invertida te transforma profundamente como profesional. Más allá de las insignias o la vestimenta exclusiva, es una demostración tangible de tu compromiso con la excelencia y una oportunidad invaluable para crecer y compartir conocimiento con la comunidad.

Mi viaje continúa, celebrando cada logro, por pequeño que sea. Si tú también has emprendido esta ruta, mi consejo es simple: persevera. Establece tu próximo objetivo, estudia con pasión y celebra cada avance.

¡Espero encontrarte pronto en el exclusivo club dorado! 🚀✨

Referencias útiles

• Programa oficial Kubestronaut: https://www.cncf.io/training/kubestronaut/

• Comunidades locales CNCF: https://community.cncf.io/chapters/

• Cupones de descuento actualizados: https://github.com/techiescamp/linux-foundation-coupon

Imagina esta situación: acabas de escribir un playbook de Ansible perfecto en tu máquina local. Funciona de maravilla. Lo pruebas una y otra vez, y todo sale bien. Llega el momento de ejecutarlo en producción y... ¡sorpresa! Falla porque el servidor tiene una versión diferente de Python, le faltan módulos o tiene dependencias incompatibles.

Si esto te suena familiar, no estás solo. Es uno de los dolores de cabeza más comunes en el mundo de la automatización con Ansible. Y es precisamente el problema que Ansible Execution Environment (EE) viene a resolver.

¿Qué es exactamente un Execution Environment?

Piensa en un Execution Environment como una "cápsula espacial" para tus playbooks de Ansible. Es un contenedor que lleva consigo todo lo necesario para ejecutar tus automatizaciones: la versión correcta de Python, todos los módulos necesarios, las colecciones de Ansible que usas, y cualquier herramienta adicional que requieras.

La gran diferencia es que, mientras antes tenías que asegurarte de que cada servidor tuviera el entorno correcto configurado (y mantenerlo actualizado), ahora simplemente ejecutas tu contenedor y listo.

¿Por qué esto cambia todo?

1. Consistencia total entre ambientes

Ya no más "funciona en mi máquina". Tu playbook se ejecutará exactamente igual en desarrollo, staging y producción. La misma versión de Python, las mismas librerías, los mismos resultados.

2. Colaboración sin dolores de cabeza

Cuando compartes un EE con tu equipo, todos trabajan con el mismo entorno. No más perder horas configurando dependencias o resolviendo conflictos de versiones.

3. Múltiples versiones sin conflictos

¿Un playbook legacy necesita Python 2.7 mientras que otro requiere Python 3.11? Sin problema. Cada EE es independiente y puede tener sus propias versiones de todo.

4. Preparado para el enterprise

Si tu empresa usa o planea usar Ansible Automation Platform, los EE son el estándar. Facilitan la gobernanza, el cumplimiento y la escalabilidad de tus automatizaciones.

Manos a la obra: Creando tu primer Execution Environment

Vamos a crear un EE usando la versión más reciente de ansible-builder. Esta guía está probada y funciona perfectamente con Red Hat UBI 9.

Paso 1: Instalar las herramientas necesarias

Primero necesitamos ansible-builder:

# Instalar la última versión de ansible-builder
pip install ansible-builder --upgrade

# Verificar que tienes la versión 3.x
ansible-builder --version

# También necesitarás Podman o Docker
# En Fedora/RHEL:
sudo dnf install podman

# En Ubuntu/Debian:
sudo apt install podman

Paso 2: Crear la estructura del proyecto

Vamos a crear todos los archivos necesarios de una vez. Crea un directorio para tu proyecto:

mkdir mi-ee-ubi9 && cd mi-ee-ubi9

Paso 3: Crear el archivo principal execution-environment.yml

Este es el corazón de tu EE. Crea el archivo con este contenido:

version: 3

build_arg_defaults:
  ANSIBLE_GALAXY_CLI_COLLECTION_OPTS: '--pre'

dependencies:
  ansible_core:
    package_pip: ansible-core==2.14.4
  ansible_runner:
    package_pip: ansible-runner
  galaxy: requirements.yml
  python: requirements.txt
  system: bindep.txt
  exclude:
    python:
      - docker
    system:
      - python3-Cython

images:
  base_image:
    name: docker.io/redhat/ubi9:latest

additional_build_files:
  - src: files/ansible.cfg
    dest: configs

additional_build_steps:
  prepend_base:
    - RUN echo "Starting build process..."
    - RUN dnf install -y python3-pip

  prepend_galaxy:
    - COPY _build/configs/ansible.cfg /etc/ansible/ansible.cfg

  prepend_final: |
    RUN whoami
    RUN cat /etc/os-release

  append_final:
    - RUN echo "Build completed!"
    - RUN dnf clean all
    - RUN rm -rf /var/cache/dnf

Paso 4: Crear las dependencias del sistema (bindep.txt)

Este archivo lista los paquetes del sistema operativo que necesitas:

# Compilación
gcc [compile platform:rpm]
make [compile platform:rpm]

# Control de versiones
git [platform:rpm]

# Herramientas de red
iputils [platform:rpm]
net-tools [platform:rpm]
openssh-clients [platform:rpm]

# Desarrollo Python
python3-devel [platform:rpm]
python3-cffi [platform:rpm]
python3-cryptography [platform:rpm]
python3-lxml [platform:rpm]
python3-pycparser [platform:rpm]

# SSH y conectividad
libssh-devel [platform:rpm]
sshpass [platform:rpm]

# Utilidades
rsync [platform:rpm]
unzip [platform:rpm]
tar [platform:rpm]

Paso 5: Crear las colecciones de Ansible (requirements.yml)

Define qué colecciones de Ansible necesitas:

---
collections:
  - name: ansible.posix
    version: ">=1.5.0"
  - name: community.general
    version: ">=7.0.0"
  - name: ansible.utils
    version: ">=2.9.0"
  - name: community.crypto
    version: ">=2.11.0"

Paso 6: Crear las dependencias de Python (requirements.txt)

Lista los paquetes de Python necesarios:

# Core
six>=1.16.0
psutil>=5.9.0

# Networking
paramiko>=2.12.0
netaddr>=0.8.0

# Utilidades
jinja2>=3.1.0
PyYAML>=6.0
requests>=2.28.0
urllib3>=1.26.0

Paso 7: Crear la configuración de Ansible

Primero crea el directorio:

mkdir -p files

Luego crea files/ansible.cfg:

[defaults]
host_key_checking = False
retry_files_enabled = False
stdout_callback = yaml
interpreter_python = auto_silent
gathering = smart
fact_caching = jsonfile
fact_caching_connection = /tmp/ansible-facts
fact_caching_timeout = 3600

[ssh_connection]
pipelining = True
control_path = /tmp/ansible-ssh-%%h-%%p-%%r

[inventory]
enable_plugins = auto, yaml, ini, toml

Paso 8: Construir tu Execution Environment

Ahora viene el momento de la verdad:

ansible-builder build -t mi-ee:latest

El proceso tomará algunos minutos la primera vez. Verás cómo:

1. Se descarga la imagen base de UBI 9

2. Se instalan los paquetes del sistema

3. Se configuran las dependencias de Python

4. Se descargan las colecciones de Ansible

5. Se aplican las configuraciones personalizadas

Paso 9: Verificar y usar tu EE

Verificar que se construyó correctamente:

# Ver la imagen creada
podman images | grep mi-ee

# Ver qué colecciones están instaladas
podman run --rm mi-ee:latest ansible-galaxy collection list

# Ver la versión de Ansible
podman run --rm mi-ee:latest ansible --version

# Ver qué módulos de Python están instalados
podman run --rm mi-ee:latest pip list

Usar tu EE para ejecutar playbooks:

# Instalar ansible-navigator si no lo tienes
pip install ansible-navigator

# Ejecutar un playbook
ansible-navigator run site.yml --execution-environment-image mi-ee:latest

Troubleshooting: Problemas comunes y sus soluciones

"El build falla con error de paquete no encontrado"

Este es el error más común al usar UBI. Red Hat Universal Base Image tiene repositorios limitados por diseño.

Solución rápida: Revisa qué paquete falla y:

1. Búscalo con un nombre alternativo

2. Elimínalo de bindep.txt si no es crítico

3. Instálalo desde fuente en additional_build_steps

Ejemplo real: Si openshift-clients no está disponible:

additional_build_steps:
  prepend_base:
    - RUN curl -L https://mirror.openshift.com/pub/openshift-v4/clients/ocp/latest/openshift-client-linux.tar.gz | tar xz -C /usr/local/bin

"Mi EE pesa más de 1GB"

Los EEs pueden inflarse rápidamente, especialmente con múltiples colecciones y dependencias.

Estrategia de optimización:

1. Revisa qué realmente necesitas - menos es más

2. Limpia después de instalar:

additional_build_steps:
  append_final:
    - RUN dnf clean all && rm -rf /var/cache/dnf
    - RUN find /usr/local -type d -name "__pycache__" -exec rm -rf {} + 2>/dev/null || true
    - RUN find /usr/local -type f -name "*.pyc" -delete
    - RUN rm -rf /root/.cache /tmp/*

"Permission denied al montar volúmenes"

El clásico problema de SELinux en sistemas Red Hat.

Solución: Siempre usa la opción :Z al montar:

# Correcto
podman run -v $(pwd):/runner:Z mi-ee:latest

Mejores prácticas

1. Versiona tus EEs: Usa tags semánticos como v1.0.0, no solo latest

2. Documenta dependencias: Comenta por qué incluyes cada paquete

3. Mantén EEs específicos: Crea diferentes EEs para diferentes propósitos

4. Automatiza builds: Integra la construcción en tu CI/CD

5. Prueba regularmente: Valida que tus playbooks funcionan con el EE

Conclusión

Los Ansible Execution Environments representan un cambio fundamental en cómo manejamos las dependencias y la portabilidad en Ansible. Con esta guía, tienes todo lo necesario para crear EEs robustos y reproducibles basados en Red Hat UBI 9.

La clave está en empezar simple: crea tu primer EE con las dependencias mínimas, pruébalo, y ve agregando lo que necesites. En poco tiempo, te preguntarás cómo sobrevivías sin ellos.

Recursos adicionales

• Documentación oficial de Ansible Builder

• Ansible Navigator Documentation

• Red Hat UBI Documentation

• Ejemplos de EE en GitHub

¿Ya creaste tu primer Execution Environment? ¿Qué problemas resolviste? ¿Qué personalizaciones agregaste?

Y si este artículo te fue útil, compártelo con ese colega que siempre está peleando con las versiones de Python. 😉