Arquitectura de Kubernetes
Veamos la arquitectura de Kubernetes, empezaremos por un vistazo general y luego profundizaremos en sus componentes principales.
Un clúster de Kubernetes consta de dos piezas fundamentales:
-
El "control plane", o nodo maestro, que es responsable de gestionar el clúster. No ejecuta pods ni ningún tipo de workloads o cargas de trabajo. Se limita a interactuar con los nodos de trabajo y gestionar los recursos del clúster.
-
Los nodos de trabajo o "workers" alojan los pods (contenedores) y las cargas de trabajo, es decir, Son los encargados de ejecutar las aplicaciones y servicios que se despliegan en el clúster.
Esta separación de funciones permite que los nodos maestros sean muy fiables y, por otra parte, permite mayor flexibilidad al escalar los nodos de trabajo. Todos los nodos ejecutan el software de Kubernetes y se comunican entre sí a través de la red, repartiéndose las tareas y garantizando la alta disponibilidad de las aplicaciones.
Una visión general de la arquitectura de Kubernetes se muestra en el siguiente diagrama:
Aunque vamos a profundizar en los componentes de cada tipo de nodo, es principalmente para que entiendas a grandes rasgos cómo funciona Kubernetes. No es necesario que recuerdes todos los detalles, ya que en la práctica no tendrás que interactuar con ellos directamente. Como usuarios, solo interactuaremos con el clúster a través de la API de Kubernetes. Salvo en la especialización del CKA o administrador de Kubernetes, donde sí tendrás que conocer estos detalles para tema de mantenimiento y troubleshooting.
Componentes básicos de cualquier nodo
- Container runtime: es el software que se encarga de ejecutar los contenedores. Docker es el más popular, pero en Kubernetes lo más habitual es usar containerd o CRI-O, versiones más ligeras y especializadas es este tipo de entornos.
- Kubelet: es el encargado de gestionar los contenedores en un nodo y de garantizar que estos se mantengan en el estado deseado. Se comunica con el API Server para recibir instrucciones y transmitirlas al runtime de contenedores.
- Kube-proxy: gestiona el tráfico de red en el nodo. Se encarga de enrutar las peticiones a los servicios y de balancear la carga entre los pods. También se encarga de la exposición de los servicios al exterior. Traduce las necesidades de red de los servicios a reglas de iptables de forma automática.
Componentes de un Nodo Maestro
Ya hemos visto, que los compomentes anteriores eran necesarios en todos los nodos. Como se aprecia en el diagrama, el nodo maestro o control plane, es el más complejo. Vamos a ver los componentes adicionales que lo componen:
- Kube-apiserver: es el punto de entrada al clúster. Es el componente que recibe las peticiones de los usuarios y de los nodos de trabajo. Es el único que se comunica directamente con la base de datos de Kubernetes, etcd. Almacena el estado del clúster, gestiona las peticiones y las transforma en acciones.
- Kube-scheduler: es el encargado de decidir en qué nodo se ejecutará un pod. Se basa en las necesidades de los pods y en las capacidades de los nodos para tomar la decisión.
- Etcd: es la base de datos de Kubernetes. Almacena el estado del clúster y es el único componente que almacena información de forma persistente. Es altamente consistente y tolerante a fallos.
- Kube-controller-manager: es el componente que se encarga de gestionar los controladores de Kubernetes. Los controladores son procesos que se ejecutan de forma continua y que se encargan de mantener el estado deseado del clúster. Por ejemplo, el controlador de replicación se encarga de mantener el número de réplicas de un pod en el estado deseado.
- Cloud-controller-manager: es como el kube-controller-manager pero para entornos en la nube. Se encarga de interactuar con los servicios del proveedor, como los volúmenes de almacenamiento, balanceadores de carga, etc.
Vale, muchos datos, pero...
Por simplificar, el api de kubernetes gestiona todas las peticiones de los usuarios o de los nodos, el scheduler decide donde se ejecutan los pods, el controlador mantiene el estado deseado del clúster y el etcd almacena el estado del clúster.
En conjunto, estos componentes garantizan que los kubelets de los nodos de trabajo ejecuten los pods y se aseguran de que estén en el estado deseado.
Si te fijas, son muchas capas de abstracción. En tu PC tu utilizarías docker directamente, pues aquí invocas un API que coordina con diferentes piezas la ejecución de esos contenedores. Además, kubernetes no solo son contenedores, aporta nuevos conceptos para ejecutar grupos de contenedores, como los deployments, servicios de red, almacenamiento persistente, etc, que iremos viendo en los siguientes capítulos.
Resumen
En este capítulo hemos visto una visión general de la arquitectura de Kubernetes. Hemos visto que un clúster de Kubernetes se compone de dos tipos de nodos: los nodos maestros y los nodos de trabajo. Hemos visto los componentes básicos de cada tipo de nodo y hemos profundizado en los componentes del nodo maestro. En el siguiente capítulo veremos cómo instalar un clúster de Kubernetes para meternos de lleno en la práctica.
- Lista de vídeos en Youtube: Curso Kubernetes