Arquitectura de Kubernetes: Master Node

Siguiendo con las entradas de Kubernetes, en esta entrada vamos a ver un poco más sobre la Arquitectura de Kubernetes y en concreto como funciona el Master Node o nodo maestro.

Elementos de una Arquitectura de Kubernetes

De una manera resumida, podríamos decir que kubernetes cuenta con los siguientes componentes:

• Uno o varios master nodes.
• Uno o varios worker nodes.
• Almacen distribuido clave-valor, como puede ser etcd.

Master Node

Los Master node, proporcionan un entorno de ejecución para el control plane, el cual se encargará de gestionar el estado del cluster de kubernetes. Y será el cerebro de todas las operaciones dentro del cluster. Los componentes del Control Plane, son agentes con distintos roles dentro de la gestión del cluster. La comunicación con el clúster, se podrá hacer através del Línea de comandos, una interfaz de usuario, o un API.

Es importante mantener el Control Plane funcionando a toda costa. La pérdida del Control Plane puede introducir tiempos de inactividad, causando interrupciones del servicio a los clientes, con una posible pérdida de negocios. Para garantizar la tolerancia a fallos del Control Plane, se agregan réplicas de nodo maestro al clúster, configuradas en modo de alta disponibilidad (HA). Si bien solo una de las réplicas del nodo maestro administra activamente el clúster, los componentes del Control Plane permanecen sincronizados a través de las réplicas del nodo maestro. Este tipo de configuración agrega resistencia al Control Plane del clúster, en caso de que falle la réplica del nodo maestro activo.

En todo momento hay que conocer el estado del cluster de Kubernetes, toda esta información es guardad en etcd.

Etcd es un almacen clave-valor, el cual solo mantiene información relativa al estado. Además se configura en el Master Node, y se comunica através del API Server. También permite ser configurado de manera externalizada, pero en este caso no estaría garantizada la resiliencia, ya que solo estaría garantizada cuando los Master Nodes se encuentran en HA.

Componentes Master Node

Api Server

Todas la gestión de tareas se coordina por el Kube-apiserver, el cual es un componente del Control Plane, que se ejecuta en el Nodo Master. El Server API, intercepta las llamadas REST de los usuarios, operadores y agentes externos, las valida y procesa. Durante este procesamiento, el servidor API lee el estado del clúster de Kubernetes información que se encuentra en etcd, y después esta información esta información se vuelve a guardar en etcd. Este componente será el único que puede comunicarse con etcd.

Scheduler

Básicamente el Kube Scheduler se encarga de asignar nuevos objetos, como pods a los nodos. Este podrá recibir del API Server los requisitos del nuevo objeto que forman parte de sus datos de configuración, en otros datos también se pueden incluir restricciones en el uso o quotas, la ubicación de los datos, sistemas de tolerancia a fallos etc..

Managers Controller

Los Controller Manager, son componentes del Control Plane y tienen como misión regular el estado del clúster de kubernetes. Este en un proceso que se ejecuta en bucle y compara el estado que existe con el estado deseado. En el caso en el que los estados no coincidan se toman medidas correctivas.

kube-controller-manager, ejecuta controladores reponsables de actuar cuando los nodos llegan a estar no disponibles, para asegurar que el número de pods es el esperado, para crear endpoints, cuentas de servicio y tokens de acceso a APIs.

Cloud-controller-manager, ejecuta controladores responsables de interactuar con infraestructuras de un provedor de una nube cuando los nodos no están disponbiles, para gestionar los almacenes proporcionados por un servicio de cloud, y gestionar el balanceo de carga y el enrutamiento.

Etcd

Etcd es un almacén de datos clave valor distribuido el cual es utilizado por el clúster de kubernetes para persistir el estado en el que se encuentra. Los datos nuevos (el estado) únicamente se guardan almacenando un nuevo registro, nunca se reemplazan o actualizan. Periodicamente se compactan los valores para minimizar el tamaño en disco. Etcd únicamente es accesible a través del API Server.

A través de línea de comandos (CLI) de etcd, tenemos capacidades de copia de seguridad y restauración, que nos serán útiles para entornos de aprendizaje y nuestros entornos de desarrollo ya que lo normal será cuando tengamos un único clúster de k8s. Pero para entornos de producción, será de vital importancia tener réplicas en modo HA.

Algunas herramientas de arranque de clúster de Kubernetes, de forma predeterminada, proporcionan nodos maestros etcd , donde el almacén de datos se ejecuta junto y comparte recursos con los otros componentes del Control Plane en el mismo Master Node. Para aislarlo de los componentes del Control Plane, etcd también podrá ser configurado de manera externa, en tal caso deberá hacer en HA.

Como curiosidad etcd se ha basado en el algoritmo consenso de Raft, lo que resumiendo mucho viene a decir que una colección de máquinas trabajaran como un grupo coherente que podrá sobrevivir a los fallos de alguno de sus miembros. Cualquier nodo podrá ser tratado como master y el resto seguidores, en cualquier momento. Etcd esta escrito en go, y aunque el principal objetivo en k8s es guardar el estado, también, que se verá más adelante puede guardar configuraciones, ConfigMaps, Secrets, etc.

Conclusión

En esta entrada hemos visto como funciona el Master Node en una arquitectura de Kubernetes así como sus diversos componentes. En la siguiente entrada entraremos en más detalle a ver los diversos componentes del Worker Node.