Saltar al contenido principal

Orquestación de Kubernetes con Ansible

Este proyecto demuestra la capacidad de gestionar configuraciones complejas de forma idempotente y escalable. Hemos diseñado un rol de Ansible (kubernetes_bootstrap) que automatiza el ciclo de vida de la instalación de binarios v1.35 en un entorno multi-nodo.

1. Diseño de la Configuración (ansible.cfg)​

Hemos optimizado la comunicación SSH y la salida visual para mejorar la experiencia de depuración del ingeniero.

ansible.cfg
export default "[defaults]\n# 1. Definimos el inventario y usuario\ninventory = ./inventory.ini\nremote_user = candidate\nhost_key_checking = False\n\n# 2. ELIMINACIÓN DEL ERROR DEL CALLBACK\n# En lugar de usar 'yaml', usamos el plugin 'default' de ansible-core\nstdout_callback = ansible.builtin.default\n# Activamos los callbacks para comandos ad-hoc (como el ping)\nbin_ansible_callbacks = True\n\n# 3. SILENCIAR WARNINGS DE PYTHON\n# Esto elimina los mensajes amarillos sobre el descubrimiento del intérprete\ninterpreter_python = auto_silent\n\nroles_path = ./roles\nforks = 5\n\n# 4. CONFIGURACIÓN ESPECÍFICA DEL FORMATO YAML\n[callback_default]\n# Aquí es donde activamos el formato YAML que antes hacía el plugin externo\nresult_format = yaml\n\n[ssh_connection]\nssh_args = -C -o ControlMaster=auto -o ControlPersist=60s\npipelining = True\n";

2. Inventario Semántico​

El inventario separa las responsabilidades de red de la lógica de negocio, agrupando nodos por función (Masters vs Workers).

inventory.ini.example
[masters]
cluster1-master1 ansible_host=10.2.3.4

[workers]
cluster1-worker1 ansible_host=10.2.3.45
cluster1-worker2 ansible_host=10.2.3.46
cluster1-worker3 ansible_host=10.2.3.47

[k8s_cluster:children]
masters
workers

[k8s_cluster:vars]
ansible_user=candidate

3. Implementación del Rol: kubernetes_bootstrap​

La arquitectura del rol sigue el principio de Responsabilidad Única, dividiendo las tareas en unidades lógicas.

Este es el orquestador del rol que detecta el sistema operativo y llama a las subtareas.

export default "---\n- name: Actualizar cache de APT y Upgrade de sistema\n  ansible.builtin.apt:\n    upgrade: dist\n    update_cache: yes\n  when: ansible_os_family == \"Debian\"\n\n- ansible.builtin.include_tasks: setup_repo.yml\n- ansible.builtin.include_tasks: install.yml\n";

4. Análisis de Ingeniería (Interview Ready)​

Durante el desarrollo de este proyecto, se implementaron las siguientes mejores prácticas de DevOps:

  1. Idempotencia: Los playbooks pueden ejecutarse múltiples veces sin alterar el estado final si el clúster ya está configurado correctamente.
  2. Mantenibilidad: El uso de variables (k8s_version) permite actualizar la versión de todo el clúster cambiando un solo valor en defaults/main.yml.
  3. Handlers: Solo reiniciamos el kubelet si ha habido un cambio real en los archivos de configuración o binarios, minimizando el downtime de los nodos.
  4. Seguridad: El uso de remote_user: candidate con privilegios de sudo controlados garantiza el principio de mínimo privilegio.

:::tip Puntos Clave para la Entrevista Si te preguntan por qué Ansible y no solo Bash: "Ansible nos permite garantizar el Estado Deseado y facilita la escalabilidad. Si mañana necesitamos 100 workers, solo hay que añadirlos al inventory.ini y ejecutar el playbook; con Bash, el manejo de errores sería inmanejable". :::

Documentación Relacionada: