Uno de los detalles más interesantes que me he encontrado al usar K3s (https://k3s.io/) es la manera de desplegar Traefik, en el cual utiliza un esquema (chart) de Helm (nota: en Kubernetes el comando a ejecutar es sudo kubectl, pero en k3s kubectl está integrado para que use menos recursos).. Nos encontramos que helm no está instalado, pero si vemos un job que ejecuta el cliente de helm para que podamos disponer de su potencia sin la necesidad de tener corriendo tiller (el servidor de helm) que por supuesto utiliza recursos y de esta manera nos los ahorramos, pero ¿Como funciona? Klipper Helm Lo primero que vemos es el uso de un job (tarea que habitualmente se ejecuta una única vez en forma de contenedor) basado en la imagen “rancher/klipper-helm” (https://github.com/rancher/klipper-helm) que ejecuta un entorno helm con solamente descargarlo y ejecutar un único script: https://raw.githubusercontent.com/rancher/klipper-helm/master/entry Como requisito si va a requerir una cuenta de sistema con permisos de administrador en el espacio de kube-system, para traefik es: Lo que debemos tener en cuenta es la necesidad de crear la cuenta de servicio y al terminar la tarea de instalación con helm eliminarla ya que no será necesaria hasta otra operación de eliminación o actualización.Como ejemplo vamos a crear una tarea para instalar un servicio weave-scope utilizando el chart helm (https://github.com/helm/charts/tree/master/stable/weave-scope) Creación del servicio Creamos un espacio de trabajo para aislar el nuevo servicio (namespace en kubernetes, proyecto en Openshift) que llamaremos helm-weave-scope: Creamos una nueva cuenta de sistema y le asignamos los permisos de administrado: Nuestro siguiente paso es crear la tarea, para ello la creamos en el fichero tarea.yml: La ejecución Y lo lanzamos con: Lo que va a lanzar todos los procesos que el chart tenga: El resultado Podemos observar la correcta instalación de la aplicación sin la necesidad de instalar Helm ni tiller corriendo en el sistema: Actualización Con la llegada de Helm v3 no se hace necesario Tiller y su uso es mucho más sencillo. Para explicar su funcionamiento, se explica como se hizo un Chart para PowerDNS en Helm v3 para desplegar PowerDNS sobre Kubernetes, esto también evita el uso de Klipper evitando jobs no requeridos.
K3s: Kubernetes más simple
K3s para demos, muchas ventajas sobre Kubernetes por despliegue y tamaño.
Kubernetes: Crear un entorno mínimo para demos
Crear un entorno mínimo para demos de Kubernetes
Elegir entre Docker o Podman para entornos de pruebas y desarrollo
¿Cuando elegimos Docker o Podman? Muchas veces nos encontramos que tenemos muy pocos recursos y necesitamos un entorno para realizar una completa demostración de producto a un cliente. En esos casos vamos a necesitar simular un entorno de la manera más sencilla y con menos recursos posibles y para ello usaremos contenedores, pero ¿cual es la mejor solución para esos pequeños entornos? Docker Docker es el entorno de contedores estandar en el mercado, es el más extendido y conforma un conjunto de herramientas extraordinariamente potentes como son un cliente desde linea de comandos, un API server, un gestor del ciclo de vida de los contenedores (containerd), un lanzador de contenedores (runc). Instalar docker es realmente fácil, ya que docker suministra un script que realiza el proceso de preparar y configurar los requisitos y los repositorios necesario y por último instala y configura docker dejando el servicio listo para usar. Podman Podman es un entorno de contenedores que no utiliza un servicio y por lo tanto no dispone de un API server, las peticiones se hacen únicamente desde la linea de comandos, lo que tiene ventajas y desventajas que explicaremos al final. Instalar podman es fácil en un entorno Centos (yum install -y podman para Centos 7 y yum install -y container-tools para Centos 8) pero necesita cierto trabajo en un entorno Debian: Despliegue con Ansible En nuestro caso hemos utilizado los roles Ansible desarrollados en https://github.com/aescanero/disasterproject, para desplegar dos máquinas virtuales, una con podman y la otra con docker. En el caso de usar una distribución basada en Debian instalamos Ansible: Procedemos a descargar el entorno y configurar Ansible: Editamos el archivo inventory.yml y le ponemos el siguiente formato: Existen algunas variables globales que cuelgan de “vars:”, que son: network_name: Nombre descriptivo de la red de libvirt que crearemos y que además será el nombre del interface que se configurará en el anfitrión KVM y que servirá de puerta de enlace de las máquinas virtuales network: los tres primeros campos de la dirección IPv4 para confirmar una red con máscara 255.255.255.0, las máquinas virtuales deberán tener una IP de dicho rango (menos 0,1 y 255) El formato de cada equipo se define por los siguientes atributos: nombre: Nombre descriptivo de la máquina virtual a desplegar, será además el hostname del equipo memory: Memoria de la máquina virtual en MB vcpus: Número de CPUs virtuales en la máquina virtual vm_ip: IP […]
Máquina virtual linux con KVM desde linea de comandos
Si queremos levantar máquinas virtuales en un entorno Linux KVM que no disponga de entorno gráfico podemos levantar máquinas virtuales desde linea de comando usando una plantilla XML. Este artículo explica como funciona internamente el despliegue que se realiza con Ansible-libvirt en https://www.disasterproject.com/index.php/2019/06/entorno-minimo-kvm-y-ansible/ Instalar Qemu-KVM y Libvirt Primero debemos tener instalado libvirt y Qemu-KVM que en Ubuntu/Debian se instala con: Y en CentOS/Redhat con: Para iniciar el servicio haremos $ sudo systemctl enable libvirtd && sudo systemctl start libvirtd Configurar una plantilla de red Libvirt nos provee de una poderosa herramienta para gestión de las máquinas virtuales llamada ‘virsh’, la cual debemos de utilizar para poder gestionar las máquinas virtuales KVM desde la linea de comandos. Para una máquina virtual necesitamos principalmente tres elementos, el primero es una configuración de red que entre otras cosas provea a las máquinas virtuales de IP vía DHCP. Para ello libvirt necesita de una plantilla XML como la siguiente (que llamaremos net.xml): Cuyos elementos principales son: NOMBRE_DE RED: Nombre descriptivo que vamos a dar a la red, por ejemplo red_pruebas o red_producción. NOMBRE_DEL_BRIDGE: Cada red crea una interfaz en el servidor anfitrión que servirá para dar salida y entrada a los paquetes de dicha red hacia el exterior. Aquí le asignamos un nombre descriptivo que nos permita identificar el interfaz. IP_HOST: La IP que dicho interfaz tendrá en el servidor anfitrión y que será la puerta de enlace de las máquinas virtuales MASCARA_RED: Depende de la red, habitualmente para pruebas y demos siempre una clase C (255.255.255.0) INICIO_RANGO_DHCP: Para asignar IPs a las máquinas virtuales libvirt usa un servidor DHCP interno (basado en dnsmasq), aquí definimos la primera IP que podemos servir a las máquinas virtuales. FIN_RANGO_DHCP: Y aquí le decimos la última IP que podemos servir a las máquinas virtuales para su uso. Preparando la imagen del sistema operativo El segundo elemento es la imagen de la máquina virtual, la imagen se puede crear o descargar, siendo recomendable lo segundo para reducir el tiempo de despliegue. Una fuente de imágenes para máquinas virtuales con KVM/libvirt es Vagrant ( https://app.vagrantup.com/boxes/search?provider=libvirt ), para obtener una imagen de la máquina virtual que nos interese de las que existen en dicha página nos las descargaremos de https://app.vagrantup.com/NOMBRE_APP/boxes/ETIQUETA_APP/versions/VERSION_APP/providers/libvirt.box siendo NOMBRE_APP el nombre de la aplicación que queremos utilizar (p.e. debian), ETIQUETA_APP es la distribución de dicha aplicación (p.e. stretch64) y por último VERSION_APP es la versión de la […]
KVM, Ansible y como hacer un entorno de pruebas
Vamos a seguir siempre la filosofía “KISS” (keep it simple stupid!)” para la creación de entornos de desarrollo locales con máquina virtuales, nos centraremos en el rendimiento que nos da KVM y las capacidades de Ansible.