Photo by Mabel Amber
En la entrada anterior hemos visto cómo crear y clonar discos. Si el disco clonado contiene el sistema operativo de una máquina virtual, el clon continene identificadores que deberían ser únicos (como el machine ID, direcciones MAC, claves SSH de host, etc).
Podemos usar virt-sysprep para eliminar todos estos identificadores únicos.
Una vez creados los storage pools llega el momento de empezar a llenarlos con discos.
En la entrada anterior hemos visto cómo añadir una imagen ISO al pool que hemos creado para los medios de instalación.
Ahora vamos a crear discos para las máquinas virtuales.
En KVM existe el concepto de storage pool, que como indica su nombre, es un recurso de almacenamiento.
En mi caso, todo el almacenamiento es local, por lo que voy a examinar el pool existente y a continuación crearé un nuevo storage pool para guardar las ISOs de instalación de los diversos sistemas operativos que utilice.
Al disponer únicamente del disco local como espacio de almacenamiento la creación de storage pools adicionales sirve para separar los discos de las VMs (que dejaré en el pool default) de las ISOs y de paso, aprender cómo funcionan los storage pool en KVM ;)
La virtualización anidada permite ejecutar una máquina virtual dentro de otra máquina virtual aprovechando las posibilidades de aceleración por hardware que proporciona el sistema anfitrión.
KVM es un módulo de virtualización que permite al kernel de Linux funcionar como hipervisor. Al formar parte del kernel de Linux, no requiere un entorno de escritorio. Esto permite reducir el peso extra del sistema, pero también supone un reto a la hora de gestionar las máquinas virtuales.
Como dice el chiste, las nubes están compuestas básicamente de servidores Linux. Una de estas nubes, Amazon Web Services (AWS), ofrece su propia distribución de Linux: Amazon Linux 2.
Con Ansible podemos automatizar la gestión de la configuración de las máquinas virtuales (o no) que creamos. Pero para poder explotar la potencia de Ansible necesitamos que la máquina gestionada cumpla unos requisitos previos: disponer de Python 2.6 o superior y que Ansible pueda conectar con la máquina.
Todas estas tareas se pueden automatizar, así que vamos a ver cómo conseguirlo.
cloud-init se define como el estándar para personalizar instancias cloud. Las imágenes para las instancias cloud empiezan siendo idénticas entre sí, al ser clones. Es la información proporcionada por el usuario lo que le da a la instancia su personalidad y cloud-init es la herramienta que aplica esta configuración a las instancias de forma automática.
cloud-init fue desarrollado inicialmente por Canonical para las imágenes cloud de Ubuntu usadas por AWS. Desde entonces, la aplicación ha evolucionado y puede ser usada en otras muchas distribuciones y en otros entornos cloud (y no cloud).
En la entrada Pods en estado creatingContainer en K8s describía el problema surgido al crear un clúster de Kubernetes usando Vagrant. Al partir de la misma imagen, todas las máquinas del clúster tienen el mismo machine-id.
El machine-id debe ser único, como se describe en los requerimientos de Kubernetes; si no lo es, se producen problemas como el descrito.
En esta entrada analizo con más detalle cómo se crea el machine-id y cómo generar uno nuevo.
Una de las maneras más sencillas de crear un entorno de desarrollo para Kubernetes es usando Vagrant y Ansible.
En el Vagrantfile definimos un conjunto de tres máquinas, llamadas node1, node2 y node3.
Una vez las máquinas están levantadas, desde el servidor de Ansible uso ssh-copy-id para habilitar el login sin password de Ansible en los nodos del clúster.
A partir de aquí, tanto la instalación de los prerequisitos como la inicialización del clúster funcionan sin problemas; sin embargo, al intentar desplegar una aplicación, los pods se quedan en el estado CreatingContainer.
