Arquitectura de kubernetes

Arquitectura en su modo más simple:

Cuando vemos la arquitectura de kubernetes podemos ver fácilmente los siguientes componentes:

Maestro(Máster) o Control Plane: Un clúster de kubernetes del mundo real suele tener varios “Control Plane”. Esto por cuestiones de disponibilidad.

Nodos: Hacen el trabajo de gestionar los contenedores

Arquitectura con un poco más de detalle

Pero si la vemos con un poco más de detalle se ve algo así:

El Control Plane contiene:

• Api server: Uno de los núcleos que tiene kubernetes. Expone todo que podemos hacer en Kubernetes a través de un api server, que suele ser de tipo REST.

  Cuando un cliente quiere distribuir una aplicación en contenedores, envía a través de una petición POST una configuración en formato YAML.

  YAML contiene una serie de características que especifican el estado deseado.

• Controller Manager: Está compuesto de múltiples componentes, estos gestionan algunas de las características básicas del clúster. Estos controladores están en modo “loop” e intervienen cuando tiene que hacerlo.

  Existen hasta el momento 4 controller managers

  • Node Controller

    Gestiona los nodos: si están vivos, muertos, que tiene que hacer en caso de que mueran(que se caigan). Etc.

  • Replication Controller

    Se encarga de conseguir que las replicas o las copias de los distintos contenedores que exige o que determina una aplicación estén correctas y estén activas.

    Cuando desplegamos un entorno especificamos, cuantas réplicas queremos y son estas réplicas las que se encarga de asegurarse el Replication Controller que se mantengan.

  • Endpoint Controller

    Se encarga de ligar Servicios con PODS, nos ofrece un endpoint (punto de entrada) a un determinado servicio

  • Service Account & Token Controller

    Se encarga de los temas de acceso y autenticación al entorno

• Scheduler: Determina donde asignar los pods, contenedores o los diferentes objetos de kubernetes dependiendo de los recursos disponibles en los nodos.

• ETC Es un almacén de datos de tipo:valor que guarda toda la configuración que vallamos haciendo en kubernetes. Todo lo que hacemos se persiste en esta base de datos para que perviva entre arranques. Es otro de esos componentes que tendríamos que tener replicado para garantizar la seguridad de nuestro clúster de kubernetes

• Kubernetes DNS: Es un DNS interno el cual todos los nodos conocen, aquí es donde está todo lo referente a la red para esos servicios que ofrecemos en kubernetes

Cuando estamos trabajando en modo CLOUD tenemos otro componente que es:

• Cloud Controller Manager: Por ejemplo si nosotros desplegamos nuestro kubernetes en una plataforma de tipo cloud, este componente se encarga de relacionarse con cada cloud. Es decir es el intérprete entre la parte de kubernetes pura y la parte del proveedor de servicios cloud

Parte del esclavo (nodos)

• Container Runtime: Es quien ejecuta los contenedores que kubernetes lanza, hay varios container runtimes que kubernetes soporta:
  • Docker
  • Containerd
  • Cri
  • Cualquier container runtime que se adiera a Kubernetes CRI(Container Runtime Interface)
• POD: Es la unidad más básica de kubernetes. Un pod puede tener de 1 a más contenedores, esos contenedores forman una unidad de trabajo. Cuando queremos desplegar containers dentro de kubernetes es desplegar POD
• Kubelet: Es un agente que se despliega a cada uno de los nodos del clúster y está trabajando de manera cooperativa con el maestro. Se puede decir que es el corazón de kubernetes dentro del nodo. Suele llamarse también como dataplane.
• Kube-Proxy: Permite la conectividad de todos los componentes dentro del nodo con el resto del clúster. Por ejemplo: hacer que los PODS accedan unos con otros o que se pueda acceder a ellos desde el exterior