Cursos Empresas Blog Live Conf Precios

¿Cómo funciona la arquitectura de red de Kubernetes?

Clase 4 de 33 • Curso de Kubernetes (2019)

Contenido del curso

Introducción a Kubernetes

Primer contacto con un cluster de kubernetes

Balanceo de carga y service discovery

Escalando nuestra aplicación

Optimizando el uso de nuestro cluster

Autorización y Namespaces

Fin del curso

32
Recomendaciones para implementar Kubernetes en tu organización o proyectos
10:16 min

Bonus

33
Clase en vivo: workflows de Kubernetes usando git
09:38 min

kube-scheduler Si el cluster requiere de nuevos clústeres el kube-scheduler se encarga de programar en Kubernetes la generación de los mismos.

Para ello se debe tener en cuenta los recursos que se necesita en un pod, como CPU o memoria, junto con el estado del clúster. Luego se programa el pod en un nodo informático adecuado.

kube-controller-manager Los controladores son los que realmente ejecutan el clúster. El kube-controller-manager contiene varias funciones de este tipo en una. El controlador realiza una consulta al programador y se asegura de que se esté ejecutando la cantidad correcta de pods. Si uno de ellos se cae, otro controlador lo percibe y responde al problema. Un controlador conecta los servicios a los pods, de manera que las solicitudes van a los extremos correctos. Además, hay algunos que permiten crear cuentas y tokens de acceso a las API.

etcd Los datos de configuración y la información sobre el estado del clúster se alojan en la etcd, una base de datos de almacenamiento de valor clave. Esta base de datos distribuida y con tolerancia a los fallos está diseñada para ser la principal fuente de información del clúster.

Nodos Un clúster de Kubernetes necesita al menos un nodo, pero suele tener varios. Los pods se programan y organizan para ejecutarse en ellos.

Pods El pod es la unidad más pequeña y sencilla del modelo de objetos de Kubernetes. Representa una instancia única de una aplicación. Cada pod contiene un contenedor o una serie de contenedores con conexión directa, y las opciones que controlan su funcionamiento. Los pods pueden conectarse a un almacenamiento permanente para ejecutar aplicaciones con estado.

Motor de tiempo de ejecución de contenedores (Container runtime engine) Cada nodo posee un motor de tiempo de ejecución de contenedores que posibilita su funcionamiento. Docker es un ejemplo, aunque Kubernetes también admite otros tiempos de ejecución que cumplen con la Open Container Initiative, como rkt y CRI-O.

kubelet Todos los nodos contienen un kubelet, es decir, una aplicación muy pequeña que se comunica con el plano de control. El kubelet garantiza que sus contenedores se ejecuten en un pod. Cuando el plano de control necesita que algo suceda en un nodo, la kubelet ejecuta la acción.

kube-proxy Los nodos también contienen un kube-proxy, es decir, un proxy de red que facilita los servicios de red de Kubernetes. El kube-proxy administra las comunicaciones de red dentro y fuera del clúster. Para ello, confía en la capa de filtrado de paquetes de su sistema operativo o reenvía el tráfico por cuenta propia.

Almacenamiento permanente (Persistant storage) Kubernetes además de gestionar los contenedores que ejecutan una aplicación, también puede administrar los datos que esta genera y que están adjuntos a un clúster. Esta tecnología permite que los usuarios soliciten recursos de almacenamiento sin necesidad de conocer los detalles de la infraestructura subyacente. Los volúmenes permanentes son específicos de un clúster y no de un pod, así que duran más que este último.

Registro de contenedores (Container registry) Las imágenes de contenedores en las que se basa Kubernetes se almacenan en un registro de contenedores, el cual puede configurarlo usted o pertenecerle a un tercero.

Infraestructura subyacente (Underlying infrastructure) Al tener toda una infraestructura se puede ejecutar Kubernetes en servidores sin sistema operativo, máquinas virtuales, proveedores de nube pública, nubes privadas o entornos de nube híbrida. Una de las principales ventajas de Kubernetes es que funciona en muchos tipos de infraestructura.

¿Cómo funciona la arquitectura de red de Kubernetes?

La Arquitectura de Kubernetes está formada por dos (2) grandes partes: Nodos master: Que son el cerebro de Kubernetes. Nodos minions: Que son los nodos de trabajo.

Para poder comunicarse con Kubernetes se puede realizar de dos (2) formas y ambas son utilizando la API que expone Kubernetes: UI interfaz de usuario. CLI línea de comandos.

Ambas se comunican a través de la Api, en donde se ejecutan las diferentes órdenes. Kubernetes es una plataforma de orquestación que busca un modelo declarativo a donde no se le indica qué hacer sino que se le expresa este es el estado deseado del cluster, esto me gustaría lograr y Kubernetes entra en un ciclo de reconciliación constante hasta llegar a ese estado final.

Registro de Imágenes: Nos permite justamente al momento de ejecutar un contenedor que se basa en una imagen y que no se pueda acceder al contenedor, lo que hacen dichos nodos (registro de imagen) es conectarse a un registro de imágenes porque no se tiene la imagen y descargar la misma.

¿Qué pasa cuando un Nodo Master muere? Hay dos (2) componentes importantes de Kubernetes que nos permiten sobrellevar la situación: Raft Consensus (Consenso de arbitraje): Kubernetes está fundamentado en este algoritmo que permite tener varios master en mi cluster y cuando un máster no responde, muere, etc. Nos permite que otro nodo máster tome el leadership (liderazgo) y que nuestras aplicaciones puedan seguir funcionando, este proceso se realiza de forma automática.
Levantar el nodo master: Para levantarlo se deben tener backups del clúster, se debe tener un claro conocimiento de cómo agregar el nodo al clúster para avanzar.

El que no exista un Nodo Master no significa que nuestros servicios dejan de funcionar sino que no se puede enviarle comandos al cluster, ejecutar un pod, hacer un nuevo deploy, entre otros. Pero todo el resto de la arquitectura seguirá funcionando.

Está una vista más a detalle de la arquitecta Kubernetes a donde se puede observar el nodo master más desagregado y que cuenta con cuatro (4) elementos: API Server: Es a lo que todo se conecta, los agentes, los nodos, cuando se utiliza un comando (CLI), un dashboard, etc; todo se conecta al API Server porque al ser el cerebro del cluster es el que entiende que está sucediendo y es cuando un nodo máster se cae justamente se pierde, es lo único que se conecta al ETCD que es una base de datos altamente disponible con la finalidad que si el nodo se cae el cluster no quede fuera de servicio. Scheduler: Cuando se debe crear un tipo de trabajo como un Pod, etc. Se encarga de asignar el Pod al nodo que corresponde además de administrar los flujos de trabajo, revisando las restricciones y recursos disponibles. Controller Manager: Es un proceso que está en un ciclo de reconciliación constante, buscando llegar a un estado deseado (utilizando un sistema declarativo y no imperativo) con el que se busca darle instrucciones a Kubernetes, tipos de controller manager: Replica Manager. Deployment Manager. Service Manager. Etcd: Key value store, es lo que permite que sea altamente disponible.

Otros componentes: Container Runtime: Generalmente suele ser Docker, en versiones 1.14 de Kubernetes tienen por default Container D, que es producto del core de Docker.

Componentes importantes que viven en los nodos: Kubelet: Agente de Kubernetes, se conecta con el control play y le dice soy este nodo y pregunta qué recurso (pods, contenedores ) debo ejecutar, el Scheduler asigna el pod y contendores al nodo, el agente (Kubelet) realiza esta comunicación constantemente con el control vía API server consultando qué recurso ejecutar, recibe el recurso y está constantemente realizando este ciclo. Actualiza constantemente el Control Play con el estado de los contenedores, monitorea los pods constantemente para saber si están vivos, los recursos disponibles, etc; le comunica constantemente al scheduler vía API Server el estado de los mismos.

Kube-proxy: Se encarga de balancear el tráfico que corre en nuestros contenedores/servicios. UNa vez que llega el request se encarga de decidir a que Pod y contenedor debe ir.

Nodos = Minions Todos los nodos y masters están conectados a una red física para tener comunicación entre sí.