Como lanzar un paquete (Chart) de Helm sin instalar Tiller

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)..

$ sudo k3s kubectl get pods -A
NAMESPACE        NAME                              READY   STATUS      RESTARTS   AGE
...
kube-system      helm-install-traefik-ksqsj        0/1     Completed   0          10m
kube-system      traefik-9cfbf55b6-5cds5           1/1     Running     0          9m28s
$ sudo k3s kubectl get jobs -A
NAMESPACE      NAME                        COMPLETIONS   DURATION   AGE
kube-system    helm-install-traefik        1/1           50s        12m

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:

$ sudo k3s kubectl get clusterrolebinding helm-kube-system-traefik -o yaml
...
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: helm-traefik
  namespace: kube-system

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:

$ sudo k3s kubectl create namespace helm-weave-scope
namespace/helm-weave-scope created

Creamos una nueva cuenta de sistema y le asignamos los permisos de administrado:

$ sudo k3s kubectl create serviceaccount helm-installer-weave-scope -n helm-weave-scope
serviceaccount/helm-installer-weave-scope created
$ sudo k3s kubectl create clusterrolebinding helm-installer-weave-scope --clusterrole=cluster-admin --serviceaccount=helm-weave-scope:helm-installer-weave-scope
clusterrolebinding.rbac.authorization.k8s.io/helm-installer-weave-scope
… Read the rest “Como lanzar un paquete (Chart) de Helm sin instalar Tiller”
Abrir publicación
K3s: Kubernetes más simple 2

K3s: Kubernetes más simple

¿Que es K3s?

K3s ( https://k3s.io/ ) es una solución Kubernetes creada por Rancher Labs ( https://rancher.com/ ) que nos promete fácil instalación, pocos requisitos y un uso de memoría mínimo.

Para el planteamiento de un entorno Demo/Desarrollo esto se convierte en una gran mejora sobre lo que hemos hablado anteriormente en Kubernetes: Crear un entorno mínimo para demos , donde la creación del entorno es compleja y requiere de muchos recursos aunque sea Ansible quien realice el trabajo difícil.

Pasamos a comprobar si es cierto lo que se nos presenta y si podemos incluir las herramientas metallb (https://metallb.universe.tf/) que nos permitirá emular la potencia de los balanceadores de los entornos Cloud y K8dash (https://github.com/herbrandson/k8dash) que nos permitirá un seguimiento de estado de la infraestructura .

Descargar K3s

La configuración de las máquinas virtuales la realizamos de la misma manera que para Kubernetes, con la instalación de dependencias:

#Debian
sudo apt-get install -y ebtables ethtool socat libseccomp2 conntrack ipvsadm
#Centos
sudo yum install -y ebtables ethtool socat libseccomp conntrack-tools ipvsadm

Descargamos la última versión de k3s desde https://github.com/rancher/k3s/releases/latest/download/k3s y la ponemos en /usr/bin con permisos de ejecución en todos los nodos.

Servicios “extras” de K3s

K3s incluye tres servicios “extras” que nos van a cambiar el planteamiento inicial que usamos para Kubernetes, el primero es Flannel ( https://github.com/coreos/flannel) que está integrado en K3s y nos va a realizar toda la capa de gestión de red interna a Kubernetes, aunque no es tan completo en características como Weave (por ejemplo soporte multicast) cumple con ser compatible con Metallb. Una comparación muy completa de proveedores de red de Kubernetes se puede ver en https://rancher.com/blog/2019/2019-03-21-comparing-kubernetes-cni-providers-flannel-calico-canal-and-weave/ .

El segundo servicio es Traefik ( https://traefik.io/ ) que realiza funciones de entrada desde fuera del entorno Kubernetes, es un potente proxy inverso/balanceador con múltiples características que realizará las funciones de red de capa 7 por detrás de Metallb que realizará las funciones de balanceador de capa de red 3.… Read the rest “K3s: Kubernetes más simple”

Abrir publicación
Kubernetes: Crear un entorno mínimo para demos 4

Kubernetes: Crear un entorno mínimo para demos

Cada día más los entornos plantean una migración/utilización Cloud o entornos Kubernetes/Openshift y se necesita cumplir dichos requisitos de los clientes para la realización de demostraciones para clientes.

Kubernetes no es un entorno amigable para llevarlo en un portatil de media capacidad (8GB a 16 GB de RAM) y menos con una demo que requiera ciertos recursos.

Desplegar Kubernetes basandonos en kubeadm, containerd, metallb y weave

Este caso se basa en el despliegue basado en Kubeadm (https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) para el despliegue de Kubernetes, usando containerd (https://containerd.io/) como gestor del ciclo de vida de los contenedores y para poder disponer de una gestión de red mínima usaremos metallb (https://metallb.universe.tf/) que nos permitirá emular la potencia de los balanceadores de los entornos Cloud y Weave (https://www.weave.works/blog/weave-net-kubernetes-integration/) que nos permite la gestión de red de los contenedores y se integra sin problemas con metallb.

Por último y aprovechando la infraestructura desplegamos el gestor en tiempo real de los recursos K8dash (https://github.com/herbrandson/k8dash) que nos permitirá un seguimiento de estado de la infraestructura y de las aplicaciones que desplegamos en la misma.

Aunque los roles de Ansible que hemos utilizado con anterioridad (ver https://github.com/aescanero/disasterproject) nos permiten desplegar el entorno con facilidad y limpieza vamos a examinar el mismo para entender como los cambios que usaremos en siguientes capítulos (usar k3s y microk8s) repercuten de manera importante en la disponibilidad y rendimiento del entorno de demo/desarrollo.

Primer paso: Instalar Containerd

El primer paso en la instalación son las dependencias que tiene Kubernetes y una muy buena referencia sobre las mismas es la documentación que Kelsey Hightower pone a disposición de aquellos que necesitan conocer a fondo Kubernetes (https://github.com/kelseyhightower/kubernetes-the-hard-way), especialmente de todos aquellos que están interesados en certificaciones Kubernetes como CKA (https://www.cncf.io/certification/cka/).

Kubernetes: Crear un entorno mínimo para demos 5

Empezamos por una serie de paquetes de red

#Debian
sudo apt-get install -y ebtables ethtool socat libseccomp2 conntrack ipvsadm
#Centos
sudo yum install -y ebtables ethtool socat libseccomp conntrack-tools ipvsadm

Instalamos el gestor de vida de los contenedores (Containerd que incluye CRI y CNI) y aprovechamos el paquetes que viene con los interfaces de red de Kubernetes (CNI o Container Network Interface)

sudo sh -c "curl -LSs https://storage.googleapis.com/cri-containerd-release/cri-containerd-cni-1.2.7.linux-amd64.tar.gz
… Read the rest “Kubernetes: Crear un entorno mínimo para demos”

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).

Elegir entre Docker o Podman para entornos de pruebas y desarrollo 7

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:

# sudo apt update && sudo apt install -y software-properties-common dirmngr
# sudo apt-key adv --keyserver ha.pool.sks-keyservers.net --recv-keys 0x018BA5AD9DF57A4448F0E6CF8BECF1637AD8C79D
# sudo sh -c "echo 'deb http://ppa.launchpad.net/projectatomic/ppa/ubuntu bionic main' /etc/apt/sources.list.d/container.list"
# sudo apt update && sudo apt install -y podman skopeo buildah uidmap debootstrap

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:

$ sudo sh -c 'echo "deb http://ppa.launchpad.net/ansible/ansible/ubuntu
… Read the rest “Elegir entre Docker o Podman para entornos de pruebas y desarrollo”

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

Máquina virtual linux con KVM desde linea de comandos 8

Primero debemos tener instalado libvirt y Qemu-KVM que en Ubuntu/Debian se instala con:

$ sudo apt-get install -y libvirt-daemon-system python-libvirt python-lxml

Y en CentOS/Redhat con:

$ sudo yum install -y libvirt-daemon-kvm python-lxml

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):

<network<nameNOMBRE_DE_RED</name<forward mode='nat'<nat<port start='1' end='65535'/</nat</forward<bridge name='NOMBRE_DEL_BRIDGE' stp='on' delay='0'/<ip address='IP_HOST' netmask='MASCARA_RED'<dhcp<range start='INICIO_RANGO_DHCP' end='FIN_RANGO_DHCP'/</dhcp</ip</network

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.
… Read the rest “Máquina virtual linux con KVM desde linea de comandos”
Abrir publicación
KVM, Ansible y como hacer un entorno de pruebas 9

KVM, Ansible y como hacer un entorno de pruebas

En los entornos de desarrollo locales siempre hace falta la simulación de entornos más potentes como pasa habitualmente en la realización de demos.

Para ello vamos a seguir siempre la filosofía “KISS” (keep it simple stupid!) y usaremos aquellos servicios para que nuestro linux requiera el menor uso de recursos posibles. Vamos a utilizar dos herramientas para simplificar el trabajo que son Ansible para el despliegue y KVM como hipervisor.

Imágenes para el entorno de pruebas

El primer paso es hacernos con un sistema que nos suministre imágenes de la manera más simple posible y nos vamos a encontrar con que Vagrant es una fuente maravillosa de imágenes. Tenemos dos maneras de hacerlo:

  1. Descargar de https://www.vagrantup.com/downloads.html e instalar con sudo dpkg -i vagrant_VERSION_x86_64.deb en entornos Debian/Ubuntu o con sudo rpm -i vagrant_VERSION_x86_64.rpm en entornos RHEL/Centos), para obtener una imagen lo más pequeña posible vamos a hacer uso de una debian 9.9.0 con el siguiente comando:
    $ vagrant box add --provider libvirt debian/stretch64
    ==> box: Loading metadata for box 'debian/stretch64'
    box: URL: https://vagrantcloud.com/debian/stretch64
    ==> box: Adding box 'debian/stretch64' (v9.9.0) for provider: libvirt
    box: Downloading: https://vagrantcloud.com/debian/boxes/stretch64/versions/9.9.0/providers/libvirt.box
    box: Download redirected to host: vagrantcloud-files-production.s3.amazonaws.com
    ==> box: Successfully added box 'debian/stretch64' (v9.9.0) for 'libvirt'!
    La imagen descargada la tendremos en ~/.vagrant.d/boxes/debian-VAGRANTSLASH-stretch64/9.9.0/libvirt, en la forma de tres archivos, siendo el que nos interesa box.img que es una imagen con formato QCOW.

  2. Descargar directamente las imágenes que vamos a utilizar, por ejemplo una imagen Centos: http://cloud.centos.org/centos/7/vagrant/x86_64/images/CentOS-7.Libvirt.box y una imagen Debian: https://app.vagrantup.com/debian/boxes/stretch64/versions/9.9.0/providers/libvirt.box
    Para hacer más fácil el despliegue, se ha configurado Ansible para que haga la descarga automáticamente, guarde la imagen en /root/.images y al utilice directamente sin que necesitemos tener que hacer nada más.

Lo siguiente que necesitamos es descargar las tareas de Ansible que nos van a permitir lanzar nuestro entorno de pruebas, el “paquete” está formado por un archivo que será realmente importante llamado “inventory.yml”… Read the rest “KVM, Ansible y como hacer un entorno de pruebas”

Navegación de entradas

1 2 3 4
Volver arriba