k8s, Minikube y la cuarentena eterna

Este domingo se volvió demasiado productivo así que le puse un stop a nifi + Docker (Pronto la segunda parte, pueden leer la primera acá) y me adentre en el mundo de Kubernetes.

Pero, ¿Que es Kubernetes?

Kubernetes es una plataforma portable y extensible de código abierto para administrar cargas de trabajo y servicios en contenedores (Actualmente existen varios container runtime, pero el que tiene mas popularidad es Docker Mas información).

Tiene un ecosistema grande y en rápido crecimiento. El soporte, las herramientas y los servicios para Kubernetes están ampliamente disponibles.

Para entender la idea, imaginemos que tenemos 2 vm, en ese escenario es simple controlar los contenedores, ¿Pero que pasaría si escalamos horizontalmente y ahora tenemos 1000 vm? ¿Como hacemos para tener todo bajo control, verificar que los contenedores estén en el estado que tienen que estar, que el numero de replicas sea el indicado, etc? En este caso el escenario es complejo.

Kubernetes es la herramientas que nos ayuda a vigilar, organizar y controlar estos escenarios (EJ: Si un contenedor se cae, Kubernetes (de ahora en mas k8s) puede levantar un nuevo contenedor)

Esto es k8s a muy grandes rasgos, un orquestador de contenedores.

Arquitectura de k8s

Pueden ver la imagen original en este enlace, yo la modifique bastante para el ejemplo

Vamos parte por parte:

Muy por arriba k8s se separa en dos partes, una llamada master que es la encargada del procesamiento, organización y dar las ordenes y por el otro lado tenemos los nodos.

Para que todo funcione estas dos partes se comunican.

En el caso de querer tener una alta disponibilidad puede haber varios masters pero para mantener la explicación lo mas simple posible, vamos a centrarnos en uno solo.

Master:

Kube-api-server

Dentro del Master tenemos el kube-api-server que sirve para que yo (como usuario) pueda comunicarme con k8s.

¿Como nos vamos a comunicar?

Hay dos formas, una a través de kubectl que es una interfaz de línea de comandos para ejecutar comandos sobre despliegues clusterizados de Kubernetes y por otro lado la api también acepta request en formato json por lo que podríamos enviarle un request con un json en el body.

En cuanto a kubectl funciona como un interprete ya que toma la orden que le enviamos y la transforma en json para que la api pueda usarla. Así que usemos la que usemos, a fin de cuentas a la api llega un json.

Kube-scheduler

El scheduler es el encargado de poner las cosas donde tienen que ir.

Cuando hacemos una petición a la api, esta se conecta con el scheduler, le pasa las especificaciones y es el scheduler el encargado de buscar entre los nodos y decidir donde crear lo que estamos solicitando. Una vez analizados los nodos, elige los mas potenciales. Ej: Dentro del requerimiento se piden 500mb de ram, entonces el scheduler analiza los recursos, revisa y selecciona cual es el que cumple los requisitos, cual tiene menos contenedores y se lo asigna

¿Que pasa si ningún nodo cumple con los requerimientos?

En ese caso la petición queda en el schedule con el estado pendiente hasta que un nodo pueda cumplir los requisitos.

Kube-controller manager

El controlador tiene:

- Node controller: En el encargado de levantar los nodos cuando alguno se cae

- Replication controller: Es el encargado de mantener las replicas que nosotros solicitamos

- Endpoint controller: Es el encargado de los niveles de servicios y redes

- Service Account & Tokens controller: Es el encargado de los temas de la autentificación en los llamados a la Api.

Etcd

Es una base de datos (clave — valor) y es la encargada de mantener los estados, configuraciones, estados, movimientos dentro del cluster.

Supongamos que estamos usando la versión 1 de alguna imagen, luego upgradeamos a la versión 2 y en ese momento tenemos algún error y queremos volver a la versión 1, esto podemos hacerlo sin problemas porque toda la información esta guardada en la base de datos (estado, configuraciones, etc).

Cloud-controller manager:

Sirve para integración cloud.

Nodos

Kubelet

Es un servicio que esta corriendo en cada uno de los nodos. A grandes rasgos, es el responsable de 2 tareas.

- Recibir información del master: Se encarga de procesar la data que llega del master, realiza las tareas dentro del nodo y se conecta con el container runtime (en este caso docker) para que este pueda crear lo solicitado.

- Enviar informes al master Ej: Estos nodos están ok, este nodo se esta quedando sin memoria, etc.

Kube-proxy

Simplificado: Se encarga del tema de networking. Permite la comunicación entre los containers dentro de un nodo.

Container Runtime

Es el runtime que vamos a utilizar para manejar los contenedores. Si vamos a utilizar Docker, cada nodo debe tener instalado Docker.

Minikube

Es una herramientas que nos va a permitir simular un cluster de manera local y asi vamos a poder aprender las bases de k8s. (Usando esta herramienta solo vamos a tener un master y un nodo)

En caso de querer usar una herramientas multinodo, existe Microk8s, pueden ver un poco mas en el siguiente video

Instalaciones

Para estos posteos voy a usar Docker así que si no lo tenes instalado verifica este enlace

Instalar kubectl en linux (ubuntu):

curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl
chmod +x ./kubectl
sudo mv ./kubectl /usr/local/bin/kubectl

Mas info acá

Instalar Minikube:

Se puede usar de dos formas:

• Usando una Vm
• Usando Docker (Yo voy a usar esta opción)

curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \
  && chmod +x minikube
sudo cp minikube /usr/local/bin && rm minikube

Iniciar Minikube

minikube start

(Un error comun puede ser este Sorry, Kubernetes v1.18.0 requires conntrack to be installed in root’s path, para solucionarlo solo instalar sudo apt install conntrack y volver a correr el comando minikube start)

La primera vez que ejecutan ese comando puede tardar un poco porque tiene que descargar todas las imagenes necesarias para funcionar.

Ahora si hacen un docker ps van a ver que hay muchas imagenes funcionando

Sudo kubectl:

En la imagen de minikube start podemos ver esta info:

To use kubectl or minikube commands as your own user, you may need to relocate them. For example, to overwrite your own settings, run:

- sudo mv /home/juan/.kube /home/juan/.minikube $HOME

- sudo chown -R $USER $HOME/.kube $HOME/.minikube

Si seguimos esos pasos cuando hagamos un stop o un delete a minikube y lo volvamos a levantar vamos a tener un problema de certificados, asi que por el momento crear alias para no tener estos inconvenientes.

nano ~/.bashrc

Y agregar estas dos lineas al final:

alias kubectl=”sudo kubectl”
alias minikube=”sudo minikube”

Y luego correr este comando para que se tomen los cambios

source ~/.bashrc

Ahora ya podemos correr kubetcl y minikube sin usar sudo (En proximos postemos vamos a ver como autentificarnos de manera correcta)

En caso de querer liberar recursos solo correr el comando

minikube stop

Si ahora hacen un docker ps van a ver que ya no hay imagenes corriendo

Ya con todos los servicios instalados vamos a poder empezar a trabajar.

Ejecutemos este comando

kubectl get pods

Como todavía no creamos nada vamos a obtener este mensaje

No resources found in default namespace.

Ahora, ¿Que es un pod? ¿Que son los ReplicaSets? ¿Deployments? , eso queda para el proximo posteo.

Suerte.