Bueno, ya vimos
Ansible, ya vimos
Docker y ahora vamos con
Kubernetes.
No, hoy no te voy a hacer
el chiste del hacker, aunque si, me sigue causando gracia.
Hoy vamos al grano, porque es un post largo que creo que les va a resultar útil.
Kubernetes (
K8s) es un proyecto
open source que nació en
Google y sirve para
orquestar contenedores (
Docker), aunque no nos permite crear imágenes, ni subirlas al
registry, solo sirve para
gestionarlos. Es un buen complemento, sino el ideal, de
Docker (
motor de contenedores) para los
entornos de producción grandes en donde
Docker solo, no puede escalar.
Distribuye de la mejor forma posible la carga de todos los
NODOS.
POD: La unidad mas chica en
Kubernetes es un
POD, que agrupa dentro suyo diferentes
contenedores (en general uno solo) que tienen un componente (
kubelet) "que le avisa" al
NODO MASTER si la aplicación se encuentra o no corriendo. Y si no esta corriendo entonces
Kubernetes levanta una nueva para mantener la cantidad de replicas que configuramos para que se encuentren corriendo. Estas
instancias se levantan en base a una
imagen, como los
containers de
Docker.
Los
PODs por definición son
stateless, y
Kubernetes los crea o destruye de manera constante en función de las necesidades. Si los
PODs deben tener
datos persistentes, deben utilizarse
volúmenes.
Los
containers levantados en el mismo
POD comparten el
stack de red y pueden hablar entre si, así como también pueden compartir un volumen y acceder a la misma información. Cada
POD tiene su propia direccion IP.
La desventaja de que los containers dentro del
POD compartan el stack de red es que no podes tener 2 containers adentro del mismo POD
escuchando en el mismo puerto, porque al tener la misma red hay colisión de puertos, pero esto se resuelve poniendo esos 2 containers en
PODs diferentes.
NODO: Un
NODO conjunto de
PODs.
NODO MASTER: Se encargan de coordinar el
clúster. Tiene que haber mínimo uno por cluster.
Generalmente no ejecutan contenedores, sino que deciden en qué
nodo se ejecuta cada
contenedor. Usualmente son 3 nodos para alta disponibilidad. Esto es debido a
etcd, que guarda el estado global del clúster y su información es crítica. Si hay 3 nodos de etcd y se pierde uno, el sistema puede seguir funcionando, ya que los dos nodos restantes pueden seguir verificándose el uno al otro. Pero ya no se puede perder ningún otro. Por eso, los nodos de etcd se escalan siempre de dos en dos, si hay 3 se puede perder 1, si hay 5 se pueden perder 2 y así sucesivamente.
El
NODO MASTER ejecuta los siguientes procesos:
-
kube-apiserver que es la forma en la que interactuamos con los otros
NODOS del cluster.
-
Kubernetes Controller (
kube-controller) que compara el estado actual del cluster con el estado que debería tener (chequea por ejemplo si la cantidad de
PODs que hay en un
NODO es la que debería haber, y sino los levanta).
-
Kubernetes Scheduler (
kube-scheduler) que es el que se encarga de escuchar al controller y cuando el controller le avisa que le faltan
PODs, el
scheduler se fija en que
NODO pueden estar mejor ubicados y los levanta ahí.
-
etcd que es una base de datos que se utiliza para
mantener la configuración global del clúster. La información contenida en
etcd es crítica y debe tenerse siempre un plan de copias de seguridad.
NODO MINION (WORKERS): Se encargan de la ejecución de los
contenedores desplegados en el clúster. Tienen instalado el agente de
Kubernetes llamado
kubelet (que se encarga de
monitorizar que un contenedor se inicie, funcione correctamente y en caso de error, reiniciarlo inmediatamente) y un
kube-proxy, que gestiona la red virtual y las IPs virtuales que de cada contenedor.
CLUSTER: Es un conjunto de
NODOS.
Entre sus principales funciones se encuentran:
. Permite Escalar
. Permite balanceo de carga
. Reparación automática del contenedor (si falla o muere, el cluster automáticamente levanta uno nuevo)
. Distribución inteligente de la carga de trabajo
. Permite almacenamiento persistente en la nube
. Optimiza nuestros recursos
Para entornos de Workstation se puede usar Minikube .
SERVICES: Los PODs no son visibles más allá de su propio contenedor. Para solucionar esto, existen los
services, que son objetos que permiten reenviar tráfico de red a un conjunto de
PODs, lo cual nos permite acceder a nuestras aplicaciones. Los
services utilizan servidores
DNS instalados en la red para registrarse en esta y permitir el acceso por nombres de servicio a sus
PODs, facilitando el descubrimiento de los mismos.
VOLUMENES PERSISTENTES: Es una pieza de almacenamiento en el cluster que sirve para guardar los datos de nuestros
PODs. Su ciclo de vida es independiente de los PODs individuales.
LABELS/SELECTORS: Los
selectors son filtros de las
etiquetas. Las
labels son muy útiles cuando por ejemplo manejamos 500 contenedores que hacen de
webserver y cuya etiqueta es
webserver, entonces, si queremos eliminarlos a todos ponemos que borre todo lo que tenga esa etiqueta en lugar de borrar uno por uno.
En
Kubernetes, podemos
exponer nuestras aplicaciones de varias maneras:
-
ClusterIP, es el
servicio que se genera de forma
predeterminada y nos permite acceder a los servicios dentro del clúster. Este servicio no es accesible desde
Internet, para que lo sea necesitaríamos habilitar el acceso a través del
proxy de
Kubernetes.
- Usando un
servicio de tipo
Kubernetes NodePort, que expone la aplicación en un puerto a través de cada uno de sus nodos. Sólo un servicio por puerto. No es para ambientes en Producción.
- Usando un servicio de tipo
Kubernetes LoadBalancer, que crea un balanceador de carga externo que apunta a un servicio Kubernetes en su clúster.
- Usando un
Kubernetes Ingress Controller, que permite un enrutamiento HTTP basado en host o URL.
Ingress no es un tipo de
servicio como el resto, se trata más de un enrutador que permite la entrada al clúster y gestionar el acceso a múltiples servicios. Hay que tener en cuenta que un Ingress Controller generalmente no elimina la necesidad de un LoadBalancer externo: el Ingress Controller solo agrega una capa adicional de enrutamiento y control detrás del balanceador de carga.
Estos son los patrones básicos para enrutar el tráfico externo a su clúster
Kubernetes.
MINIKUBE: Es un proyecto que nos permite probar
Kubernetes en una maquina local y utiliza maquinas virtuales de
Virtual Box (por defecto).
Kubernetes necesita al menos 3 nodos para funcionar, lo cual no siempre es posible en una maquina local. Para eso se creó
Minikube, que es una versión reducida de Kubernetes, que corre en una única máquina virtual que hace de maestro y esclavo a la vez.
Ademas de
Minikube también necesitara instalar
kubectl para poder comunicarse con el servidor Kubernetes.
Kubernetes tiene también una parte
Web, con un
dashboard que permite monitorizar y gestionar el clúster.
Minikube viene instalado con uno por defecto.
DEPLOYMENT: Para mantener los PODs prestando servicio sin interrupción utilizamos los
deployments, acá definimos cuantas
replicas queremos, como queremos
desplegarlos, como queremos
escalar y
Kubernetes se encarga de mantener el
clúster funcionando. Los
deployments crean replication controllers que por defecto mantienen el número de réplicas que especificamos en el despliegue, pero nos permitirán cambiar este numero a futuro si así lo deseamos.
Bueno, hasta acá toda la teoría, pero estas aburrido, ¿no?
Queres tocar, queres poner manos a la obra, queres revolcarte en este chiquero (?).
Empecemos:
