aprenderDevOps

Para profesionales TI interesados en DevOps

  • Inicio
  • Acerca de
  • Categorías
    • Aseguramiento de la calidad
    • Cloud
    • Contenedores
    • Infraestructura como código
    • Integración y entrega continua
    • Otros
  • Recursos
    • GitHub
    • Docker Hub
  • Contacto

22 de diciembre de 2018 por Arturo

Arquitectura de Kubernetes

Arquitectura de Kubernetes

Tras la entrada Introducción a Kubernetes, en la que conocimos este orquestador de contenedores y vimos algunos conceptos clave, vamos a ver su arquitectura, identificando los distintos componentes en los que está organizado y su relación entre ellos.

Nodos

Los nodos en Kubernetes son las máquinas que componen el clúster Kubernetes. Estas máquinas pueden ser físicas o virtuales, y estar desplegadas on premise o en la nube. A su vez los nodos pueden ser nodos master o nodos worker.Arquitectura de Kubernetes

Nodos master

Los nodos master son los responsables de gestionar el clúster Kubernetes. Estos nodos toman decisiones globales sobre el clúster, como el reparto de trabajo entre los nodos worker, y detectan y dan respuesta a distintos eventos del clúster, como puede ser el inicio de nuevos pods cuando el número de replicas es inferior al configurado para un controlador de replicación.

En un clúster Kubernetes puede haber un único nodo master o varios si queremos tener redundancia para asegurar una mayor disponibilidad del clúster. Si hay varios nodos master, el número de nodos master tiene que ser siempre impar para que sea posible establecer quórum. Esto es así porque en cada nodo master se ejecuta un nodo de la base de datos distribuida etcd y todos los componentes master de Kubernetes restantes (API, administrador del controlador/controller y scheduler). Un clúster etcd necesita alcanzar una mayoría de nodos, un quórum, para acordar las actualizaciones del estado del clúster, y esto sólo se puede asegurar si el número de nodos es impar.

Nodos worker

Los nodos worker, también denominados simplemente nodos, son los responsables de ejecutar las aplicaciones en pods. Como ya vimos en la entrada Introducción a Kubernetes, un pod es una colección lógica de contenedores y recursos compartidos por esos contenedores que pertenecen a una aplicación.

Como curiosidad, indicar que en la documentación de las primeras versiones de Kubernetes los nodos worker se denominaban minions.

Cada nodo worker puede ejecutar múltiples pods. Es muy recomendable tener varios nodos worker si queremos asegurar la disponibilidad de las aplicaciones desplegadas en el clúster Kubernetes.

Componentes de un nodo master

Los distintos componentes de un nodo master se pueden ejecutar en cualquier máquina del clúster, sin embargo, por simplicidad, las secuencias de comandos de configuración inician normalmente todos los componentes del nodo master en la misma máquina. Además, en esa máquina no se ejecutan contenedores de usuario.Arquitectura de KubernetesEstos componentes de un nodo master se detallan a continuación.

API server

Es el componente que expone la API de Kubernetes. Es, por lo tanto, el punto de entrada para todos los comandos REST utilizados para controlar el clúster. Procesa las solicitudes REST, las valida y ejecuta.

Scheduler

Este componente observa los pods recién creados que no tienen un nodo asignado y selecciona un nodo para que se ejecuten. El scheduler tiene en cuenta los recursos disponibles en cada nodo del clúster, así como los recursos necesarios para que se ejecute un determinado servicio. Con esta información decide dónde desplegar cada pod dentro del clúster.

Controller-manager

Este componente ejecuta los controladores. Un controlador usa el API server para observar el estado compartido del clúster y realiza cambios correctivos en el estado actual para cambiarlo al estado deseado.

Un ejemplo de controlador es el controlador de replicación, que se ocupa de mantener la cantidad correcta de pods en el clúster. El usuario configura el factor de replicación, y es responsabilidad del controlador de replicación volver a crear un pod caído o eliminar uno que se haya programado de más.

Desde un punto de vista lógico, cada controlador es un proceso separado, pero para reducir la complejidad, todos los controladores se compilan en un único binario y se ejecutan en un solo proceso.

Estos son los controladores incluidos:

  • Controlador de nodo: responsable de monitorizar el estado de los nodos y responder cuando uno se cae desplegando los pods afectados en los nodos restantes disponibles.
  • Controlador de replicación: responsable de mantener el número correcto de pods.
  • Controlador de endpoints: responsable de asegurar la conexión entre servicios y pods.
  • Controladores service acount y token: crean cuentas predeterminadas y tokens de acceso a la API para nuevos espacios de nombres.

etcd

etcd es un almacén de datos clave valor simple, distribuido y consistente. Se utiliza para almacenar la configuración compartida del clúster y para el descubrimiento de servicios. Permite de una forma confiable notificar al resto de nodos del clúster los cambios de configuración en un nodo determinado.

Algunos ejemplos de datos almacenados por Kubernetes en etcd son los trabajos que se programan, crean y despliegan, estado y detalles de los pods, espacios de nombre o información de replicación.

Componentes de un nodo worker

Arquitectura de KubernetesCada nodo worker ejecuta los siguientes componentes que se detallan a continuación.

kubelet

kubelet es el servicio, dentro de cada nodo worker, responsable de comunicarse con el nodo master. Obtiene la configuración de los pods del API server y garantiza que los contenedores descritos en dicha configuración estén arriba y funcionando correctamente. También se comunica con etcd para obtener información de los servicios y registrar los detalles de los nuevos servicios creados.

kube-proxy

kube-proxy actúa como proxy de red y balanceador de carga enrutando el tráfico hacia el contenedor correcto en función de la dirección IP y el número de puerto indicados en cada petición.

Runtime de contenedores

El runtime de contenedores es el software responsable de ejecutar los contenedores de los pods. Para ello, se encarga de descargar las imágenes necesarias y de arrancar los contenedores.

Kubernetes admite varios runtimes de contenedores: Docker, rkt, runc y cualquier implementación de la especificación de runtime OCI (Open Container Initiative).

Pods

Como ya comentamos, las aplicaciones se ejecutan mediante pods. Un pod es una colección lógica de contenedores más los recursos compartidos por esos contenedores.

En próximas entradas veremos cómo instalar Kubernetes y algunos ejemplos de configuración de aplicaciones en este orquestador de contenedores.

Archivado en: Contenedores Etiquetado con: kubernetes

Comentarios

  1. RAS dice

    18 de diciembre de 2022 en 12:04

    Excelente, muy sencilla y resumida la explicación.

    Responder

Deja una respuesta Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Lista de correo

Únete y recibe gratis en tu correo contenido actualizado.

Sígueme en la red

  • Correo electrónico
  • Facebook
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • YouTube

Categorías

  • Aseguramiento de la calidad
  • Contenedores
  • Infraestructura como código
  • Integración y entrega continua
  • Otros
  • Correo electrónico
  • Facebook
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • YouTube
  • Inicio
  • Acerca de
  • Categorías
  • Recursos
  • Contacto

Copyright © 2023 aprenderDevOps