Categoría: Ubuntu

Kubernetes – montándonos un entorno de pruebas y producción – homeLAB – Parte2

Kubernetes – montándonos un entorno de pruebas y producción – homeLAB – Parte2

Hace unos meses escribí como iniciaba un entorno k8s en casa para hacer pruebas y entender las ventajas de esta nueva plataforma que está revolucionando la forma en que manejamos contenedores.

En mi primer intento me auxilie de varios Raspberry Pi los cuales son excelentes para pequeños procesos y pruebas, lamentablemente en mi caso no me gustó mucho el resultado. En un segundo intento, use la distribución de Rancher junto a su plataforma de administración que permite provisionar un cluster ya sea en premisa o en la nube, en todos mis intentos lo hice en premisa ya que no cuento con un presupuesto para pagar horas en Amazon o Google.

En esta “segunda parte” he llegado mucho más lejos y con mejores resultados, digamos que ahora me he tomado más tiempo para entender cómo se conectan las partes y he decidido administrar k8s sin ningún front-end. Esta vez no he usado RPi, todo se ha instalado en Ubuntu 16.04 con la distribución de Rancher llamada RKE (Rancher Kubernetes Engine). https://github.com/rancher/rke

Rancher Kubernetes Engine, an extremely simple, lightning fast Kubernetes installer that works everywhere.

Esta es la descripción del Proyecto en Github, se puede decir que es una de las maneras más rápidas de tener un cluster de k8s, al menos que yo he probado hasta el momento.

BOM:

  • 3 Ubuntu Servers 16.04 – en mi caso, estos son tres máquinas virtuales.
  • 1 Management server – Otra VM con Ubuntu, no necesariamente debe ser la misma versión que los nodos del cluster.
  • Un rango de direcciones IP para MetalLB.

Instalando RKE:

Primero debemos revisar cumplimos con el Node Requriments. Rancher tiene una tabla con las recomendaciones de OS, hardware y Networking.

https://rancher.com/docs/rancher/v2.x/en/installation/requirements/

Luego procederemos a preparar el equipo que usaremos para levantar el cluster de RKE.

https://rancher.com/docs/rke/v0.1.x/en/installation/

En mi caso fue descargar el binario para Linux y colocarlo en mi PATH, crear un cluster configuration file, este archivo puede tener cualquier nombre, para simplificar los pasos le pondremos cluster.yml igual que la documentación de Rancher.

En este archivo [cluster.yml] colocaremos la información de los nodos que usaremos para formar el cluster, antes de poder lanzar este proceso debemos cumplir con algunos pasos.

  1. En la maquina usada para administración necesitamos contar con SSH keys, desplegar este key en los nodos del cluster, RKE no envía password para hacer login a estos nodos, por esta razón debemos tener ssh-passwordless.
  2. Docker ya instalado y el usuario que cuenta con los keys de SSH en el grupo de Docker.

La forma más rápida de cumplir con este paso es usando un script ya preparado para realizar esta tarea, este script es oficialmente soportado por Rancher.

https://rancher.com/docs/rke/v0.1.x/en/os/

curl https://releases.rancher.com/install-docker/17.03.sh | sh
  1. Tener las herramientas necesarias en la máquina de administración, una de ellas es kubelet. En el caso de Ubuntu se instala como cualquier otro paquete usando APT.

En la siguiente imagen se puede apreciar el mensaje final del script para instalar Docker versión 17.03.

Ya podemos continuar con la preparación del cluster.yaml. Yo he usado uno bastante sencillo:

Ejecutando RKE para inicializar el cluster.

rke up –config rancher-cluster.yml

Al finalizar este proceso, tendremos un mensaje como:

Para probar que nuestros nodos responden y que tenemos un cluster de k8s, copiamos el archivo resultante de la operación anterior [kube_config_rancher-cluster.yml] a la ubicación por defecto usada por kubectl.

cp kube_config_rancher-cluster.yml ~./kube/config

Una alternativa cargarlo en la variable KUBECONFIG:

export KUBECONFIG=$(pwd)/kube_config_rancher-cluster.yml

Hacemos un kubectl get nodes:

… Houston, we have a cluster.

Alguien preguntara: ¿Ya témenos un cluster, ahora que hacemos con él?

En el estado actual, se pueden desplegar aplicaciones que no hagan uso de almacenamiento persistente (no me gusta el hostPath) y que hagan uso del host IP ya que no tenemos un LoadBalacer instalado. Para el próximo articulo estaré desplegando dos soluciones para que nuestro cluster se parezca más a un GKE o un EKS.

Kubernetes – montándonos un entorno de pruebas – homeLAB!

Hace ya unas semanas estuve en vBrownBagLATAM mostrando lo fácil que es montarnos un LAB de Kubernetes, si buscamos en Internet podremos ver muchos posts de clusters usando Raspberry Pi. En mi caso intente usar LXD como base para las maquinas (contenedores) que tendrán Kubernetes, tanto el master como los nodos. Resulta que el host con Ubuntu/LXD usado para este proyecto no tiene bastante capacidad de CPU para correr varios contenedores y dentro de estos tener Kubernetes.

Así que termine con un cluster de tres Raspberry Pi y otro sin terminar basado en LXD.

En esta entrada se detalla como iniciar con tres Raspberry Pi + Hypriot + Kubernetes.

Ingredientes!

Hypriot tiene una guía en su propio portal donde describen la inicialización y configuración de un cluster de Kubernetes, es recomendable leer esa guía.

https://blog.hypriot.com/post/setup-kubernetes-raspberry-pi-cluster/

 

 

  1. Luego de introducir la imagen de Hypriot en el SD Card que usaremos en cada RPi, podremos hacer un:
  • Por defecto el RPi solicitara IP median DHCP, es recomendable cambiarlo a estático. Ha diferencia de una imagen Raspbian, la dirección IP puede ser configurada en /etc/network.

 

sudo apt update
sudo apt upgrade -y

 

  1. Lo interesante de Hypriot es que viene con Docker preinstalado, esto nos ahorra algunos minutos ya que no tenemos que hacer cambios como deshabilitar SWAP y editar la opción de cgroups. El siguiente paso es instalar Kubernetes:

 

sudo su -

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -

echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list

apt update

apt install -y kubeadm kubelet

 

  1. Ahora toca inicializar el master node:

 

kubeadm init --pod-network-cidr 10.244.0.0/16 --service-cidr 10.96.0.0/12 --service-dns-domain "k8s.do" --apiserver-advertise-address 44.164.67.227 --ignore-preflight-errors=all
  • Recibiremos un mensaje de confirmación relacionado a la creación del cluster, un dato importante es el $TOKEN que más adelante usaremos para asociar los nodos.
  • No es recomendable iniciar el cluster con –ignore-preflight-errors=all, esta opción se usaría como última alternativa si tenemos errores que no podemos evitar, tal como Swap en LXD.

 

  1. Usando el Usuario pirate prepararemos el ambiente para usar kubectl sin especificar config o credenciales ya que estas serán cargadas desde el ambiente de usuario.

 

mkdir -p $HOME/.kube

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

sudo chown $(id -u):$(id -g) $HOME/.kube/config

echo "export KUBECONFIG=${HOME}/.kube/config" >> ~/.bashrcsource ~/.bashrc

 

  1. Veo que muchos usan flannel como su CNI, en este cluster instalare wave, en el basado en LXD probare nuevamente con flannel. De esta manera tendría ambos CNI para comparar funcionalidades, luego se podría preparar una lista con las diferencias.

 

$ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

 

  1. Para este momento ya contamos con un master, tenemos listo el CNI, podemos proceder a agregar nodos a nuestro cluster.
  • Validamos que el CNI fue desplegado haciendo un kubectl get nodes, si nuestro nodo master tiene el estado de Ready esto quiere decir que estamos listos para el próximo paso.

 

sudo kubeadm join --token=$TOKEN

 

  • $TOKEN es el valor que recibimos cuando iniciamos nuestro master.
  • Recibiremos un mensaje indicándonos que todo aconteció correctamente y que revisemos nuestro cluster.

 

  1. Verificamos que nuestro cluster cuenta con los nodos en los cuales ejecutamos kubeadm join.
kubectl get nodes
kubectl get pods –all-namespaces

 

 

  1. Validaremos que nuestro cluster puede ejecutar “Pods”.
  • En este ejemplo, utilizare la imagen oficial de nginx y será configurada para escuchar en el puerto 80 de todos los nodos.

 

$ kubectl run nginx --image=nginx --replicas=3 --port=80

deployment "nginx" created

 

  • exponemos los Pods de nginx.

 

$ kubectl expose deployment nginx --port 80service "nginx" exposed

 

  • validamos que el puerto 80 está escuchando en los IP de nuestros nodos.

 

$ kubectl get endpoints

NAME         ENDPOINTS                                   AGE

kubernetes   192.168.7.220:6443                          37

mnginx        10.244.4.2:80,10.244.4.3:80,10.244.3.2:80   23s

 

  1. Rápidamente usando la herramienta curl, podemos validar que nginx está respondiendo en el puerto especificado.
$ curl 10.244.4.2 | head -n 5

 

  • deberíamos recibir una respuesta como la siguiente:
<DOCTYPE html>

<html>

<head>

<title>Welcome to nginx!</title>

<style>

 

  • esto confirma que nuestro Pod está siendo ejecutado correctamente en el cluster de Kubernetes, aun faltarían muchos puntos por cubrir. Acceso desde fuera del cluster es importante ya que esta es la forma que nuestros usuarios/clientes consumirán servicios como nginx.

 

Hasta el momento solo hemos realizado configuraciones básicas en un entorno de Kubernetes y posiblemente algunos lleguen a la conclusión de que es mucho trabajo para simplemente tener un nginx o alguna otra aplicación la cual se puede levantar con Docker on LXC. Lo interesante de Kubernetes es la poca diferencia en administrar un cluster con 3 nodos a uno con 40 nodos.

En las próximas entradas escribiere como instalar y utilizar Helm, así también como instalar Istio para controlar el consumo de los servicios instalados en Kubernetes.

Ubuntu LXD, Alternativa ligera?

Ubuntu LXD, Alternativa ligera?

Containers!

LXD

Si se hace una búsqueda en Internet relacionada a Docker, contenedores y demás, podremos notar que se ha convertido en algo muy aceptado. Desde hace un tiempo estoy sacando provecho de Docker en mi NAS. unRAID es actualmente mi sistema de preferencia para servicios de filesharing y un beneficio adicional es la facilidad con la que se pueden lanzar contenedores con Docker y tener servicios funcionales y fáciles de mantener.

Pero en este post me gustaría hablar de LXD, esto es un desarrollo realizado por Canonical, los creadores de Ubuntu. Durante un tiempo, no era atraído por esta distribución de Linux, pero eso está cambiando gracias a las utilidades que han creado y liberado para la comunidad. Todo comenzó con LXC, lo usé para solucionar un impase en una implementación relacionada al manejo de datos .xml que necesitaban ser recibidos de manera segura, el proveedor solicitaba SFTP en un entorno aislado, en ese momento probé LXC y se crearon varios contenedores para cada proveedor. Todo funciono de maravilla y decidí seguir investigando.

De manera casi inmediata encontré un caso de uso para tenerlo en mi casa y este fue, tener pequeños Ubuntus corriendo servicios claves (DNS, MySQL, PHP, AD Blocking…), todo fue de maravilla. Hace unos días pude terminar de completar una “nueva máquina” con un board Mini-ITX + 6GB de RAM y varios SSD de tamaños entre 120GB y 60GB. Teniendo un consumo de apenas 20Watts, esta pequeña maquina es ideal para estar encendida 24/7.

Investigando la mejor manera de tener LXC, veo que Ubuntu ahora hace referencia a LXD como el siguiente paso de LXC, tomar en cuenta que LXD no es un reemplazo y es más que un complemento.

Info: https://linuxcontainers.org/lxd/introduction/#relationship-with-lxc

“ LXD isn't a rewrite of LXC, in fact it's building on top of LXC to provide a new, better user experience. Under the hood, LXD uses LXC through liblxc and its Go binding to create and manage the containers.

It's basically an alternative to LXC's tools and distribution template system with the added features that come from being controllable over the network. “

 

Instalando LXD.

Los siguientes pasos son basados en el documento oficial de LinuxContainers en la sección de LXD:

Nota: LXD puede ser instalado en las siguientes distribuciones:

  • ArchLinux
  • Fedora
  • Gentoo
  • Ubuntu
  • Debian

 

En este caso he seleccionado Ubuntu por que debería ser la distribución mejor soportada, ¿cierto?

apt install lxd lxd-client
sudo lxd init

 

Una serie de preguntas deben ser contestadas luego de ejecutar el lxd init. Siendo las más importantes la relacionada a redes, aquí se podría seleccionar crear un Bridge o utilizar uno ya existente, en mi caso opte por utilizar uno que ya había creado. La segunda opción con relevancia es el Storage, inicialmente seleccione dir como Storage backend, luego adicione un segundo disco usando ZFS.

 

Validando la instalación de LXD.

Luego de realizar la instalación podemos verificar que nuestro manejador de contenedores está operando de manera correcta con los siguientes comandos:

lxc info
lxc image list - en un entorno recién instalado este comando no presenta información.
lxc storage list
lxc network list
lxc list – en un entorno recién instalado este comando no presenta información.

 

Iniciando un contenedor.

Un nuevo contenedor puede ser creado desde una imagen, un contenedor existente o un snapshot. Por defecto LXD viene con tres repositorios de imágenes que podemos usar para crear contenedores.

  • ubuntu
  • ubuntu-daily
  • images

podemos investigar cuales imágenes están disponibles de la siguiente manera:

lxc image list ubuntu:

en pantalla nos mostrara la lista de imágenes disponibles para ser usadas, en este repositorio tenemos las versiones de Ubuntu.

Si cambiamos “ubuntu:” por “ubuntu-daily: podemos ver los snapshots generados diariamente. Si en lugar de Ubuntu usamos “images:”, tendremos una lista de todas las distribuciones que han generado imágenes y enviado al repositorio de Linux Containers, incluyendo a Ubuntu.

El resultado de este comando puede ser abrumador ya que contiene bastante información, en cambio si queremos ver la lista de una versión de Ubuntu o una distribución específica, podemos hacer:

lxc image list ubuntu:xenial

De esta manera solo tendremos las imágenes de Xenial.

Por otro lado, si queremos buscar imágenes de Debian:

lxc image list images:debian

lxc image list images:debian/9/

–  tendremos solo las versiones de Stretch.

La lista de imágenes está disponible vía web en: https://uk.images.linuxcontainers.org/

 

Ya sabemos el nombre de la imagen que queremos usar como base de nuestro contenedor. Usando los siguientes comandos podemos crear contenedores.

lxc init ubuntu:xenial cont1

– un nuevo contenedor será creado usando Xenial como base.

lxc launch ubuntu:xenial cont2

– a diferencia del anterior, de este modo podemos crear e inmediatamente iniciar el nuevo contenedor.

 

Interactuando con los contenedores.

Bien, ya tenemos nuestros contenedores. Necesitamos actualizarlo, instalar aplicaciones, usarlo tal cual usaríamos un servidor en físico o una máquina virtual que ya conocemos y queremos.

lxc exec cont1 – bash

– inmediatamente ejecutado este comando estaremos en el contenedor llamado cont1, el acceso es otorgado directamente con permisos de root. En lo adelante todo es exactamente igual que cualquier instalación de Ubuntu. Para salir del contenedor escribimos exit.

 

Aquí termina esta pequeña introducción a LXD, la capacidad de esta herramienta es bastante amplia, tengo varios planes y pruebas para realizar. Entre ella están tales como correr Kubernetes en LXD o crear un Docker Swarm usando contenedores en LXD y Raspberry Pi3.

Más información puede ser encontrada en: