Kubernetes: Una breve introducción

Kubernetes es un proyecto que surgió de Google como una plataforma de orquestación de contenedores de código abierto, podéis ver su código en github y aportar. Fue diseñado a partir de las lecciones aprendidas en el desarrollo y ejecución de Borg y Omega, los sistemas internos de Google para la gestión de contenedores.

Está diseñado como una colección de componentes que trabajan de manera independiente pero cohesionada para implementar, mantener y escalar cargas de trabajo. Kubernetes abstrae el hardware subyacente de los nodos y proporciona una interfaz uniforme para implementar y consumir recursos compartidos. Actúa como un motor para mantener el estado deseado del sistema al compararlo con el estado actual.

Kubernetes ofrece capacidades como el escalado automático de cargas de trabajo, servicios persistentes, trabajos programados (cron jobs) y, en cierta medida, cargas de trabajo por lotes. También gestiona aplicaciones sin estado y con estado, y proporciona métodos nativos de descubrimiento de servicios y auto recuperación.

Una breve historia de los contenedores

Guia-Tutorial práctica de Kubernetes

Índice:

• Visión general de la arquitectura
  • El plano de control (Control Plane)
  • Nodos (Nodes)
  • Cargas de trabajo (Workloads)
  • Almacenamiento (Storage)
  • Redes (Networking)
  • Trabajo con volúmenes (Volumes)
• Conceptos y recursos
  • La API y el modelo de objetos
  • API Groups
  • Versionado de la API
  • Modelo de objetos
• Objetos fundamentales
  • Namespaces
  • Pods
  • Etiquetas (Labels)
  • Selectores
  • Servicios
• Conclusión

Visión general de la arquitectura

El plano de control (Control Plane)

El plano de control de Kubernetes, a menudo conocido como el «master», administra la configuración del clúster a través de un almacén de datos distribuido. Responde a cambios de estado, proporciona una API accesible mediante CLI e interfaces RESTful, y se encarga de la programación, entre otras tareas.

Componentes del plano de control

• kube-apiserver
• etcd
• kube-controller-manager
• kube-scheduler

kube-apiserver

Actúa como la interfaz principal hacia el plano de control de Kubernetes y la base de datos. Todos los clientes y aplicaciones interactúan con Kubernetes exclusivamente a través del servidor de API. Además, actúa como el guardián del clúster, manejando autenticación, autorización y control de admisión, además de ser el frente para el almacenamiento de datos.

etcd

etcd funciona como la base de datos del clúster. Su propósito en relación con Kubernetes es proporcionar un almacén de claves y valores sólido, consistente y altamente disponible para persistir el estado del clúster.

kube-controller-manager

Es el daemon principal que gestiona todos los bucles de control de los componentes centrales. Monitoriza el estado del clúster a través del servidor de API y dirige el clúster hacia el estado deseado.

kube-scheduler

Es un motor con políticas ricas que evalúa los requisitos de las cargas de trabajo y trata de asignarlas a recursos compatibles. El programador predeterminado utiliza la técnica de «bin packing» para tomar decisiones basadas en requisitos de hardware, afinidad, etiquetas y otros requisitos personalizados.

Nodos (Nodes)

• Pods: Los pods son la unidad más pequeña y desplegable en Kubernetes. Pueden contener uno o más contenedores en un solo espacio de nombres (namespace). Los pods no se reinician automáticamente cuando fallan, por lo que se debe gestionar su estado externamente.
• Kubelet: Es un daemon en cada nodo que gestiona el ciclo de vida de los pods. Se comunica con la interfaz de tiempo de ejecución de contenedores (CRI), normalmente Docker, y escucha archivos de especificación de pods a través de HTTP(S) desde el servidor de API.
• Kube-proxy: Administra la red de los pods y garantiza la comunicación entre ellos. También se encarga de asignar IPs únicas y persistentes a los servicios.
• Motor de tiempo de ejecución de contenedores: Gestiona los contenedores en los pods, por ejemplo, Docker.

Cargas de Trabajo en Kubernetes

Kubernetes ofrece un conjunto de controladores de recursos conocidos como «cargas de trabajo» para administrar y supervisar la creación y el funcionamiento de los pods de manera eficiente. Estos controladores aseguran que los pods se implementen, escalen y administren de acuerdo con las necesidades de la aplicación y las políticas definidas.

• ReplicaSet
• Deployment
• DaemonSet
• StatefulSet
• Job
• CronJob

ReplicaSet

ReplicaSet es un controlador que garantiza que un número específico de réplicas de un pod esté en ejecución en todo momento. Si un pod falla o se elimina, ReplicaSet lo reemplazará automáticamente para mantener el número deseado de réplicas.

Uso típico: ReplicaSet es útil cuando se necesita garantizar la alta disponibilidad de una aplicación al mantener un número constante de copias idénticas en funcionamiento.

Deployment

Deployment es un controlador que abstrae ReplicaSets y proporciona un mecanismo más avanzado para administrar la implementación de aplicaciones. Permite realizar actualizaciones sin tiempo de inactividad al cambiar las versiones de las aplicaciones y garantiza que las actualizaciones se apliquen de manera controlada.

Uso típico: Los Deployments son ideales para administrar aplicaciones en constante evolución, como aplicaciones web, permitiendo actualizaciones y cambios sin interrupciones en el servicio.

DaemonSet

DaemonSet es un controlador que asegura que todos los nodos del clúster tengan una copia de un pod en ejecución. Cada nodo del clúster ejecuta una instancia del pod gestionado por DaemonSet.

Uso típico: DaemonSet es útil para implementar componentes que deben estar presentes en cada nodo, como agentes de monitoreo, recolección de registros o servicios de red.

StatefulSet

StatefulSet es un controlador diseñado para aplicaciones que requieren almacenamiento persistente y una identidad única y estable. Los pods administrados por StatefulSet tienen nombres y persisten su estado, lo que facilita la gestión de aplicaciones que requieren un estado específico, como bases de datos.

Uso típico: StatefulSet es esencial para aplicaciones de bases de datos, sistemas de mensajería y otras aplicaciones que necesitan nombres únicos y almacenamiento persistente.

Job

Job es un controlador que garantiza que uno o más pods se ejecuten y finalicen con éxito. Los pods administrados por Job realizan una tarea y no se eliminan hasta que se completa la tarea con éxito o se alcanza un límite de reintentos.

Uso típico: Los Jobs son adecuados para tareas de procesamiento por lotes, trabajos de cómputo intensivo y cualquier trabajo que deba completarse antes de ser eliminado.

CronJob

CronJob es una extensión del controlador de trabajos (Job) que permite ejecutar trabajos de manera programada, similar a la funcionalidad de cron en sistemas operativos. Los CronJobs ejecutan trabajos en un horario específico o periódicamente.

Uso típico: CronJobs son útiles para automatizar tareas recurrentes, como copias de seguridad, generación de informes o limpieza de registros, siguiendo un horario predefinido.

Almacenamiento (Storage)

Los pods en Kubernetes pueden necesitar compartir datos o almacenar información. Para ello, se utilizan los siguientes recursos:

Volúmenes (Volumes)

Los volúmenes son objetos que se adjuntan a un pod y se utilizan para compartir datos entre los contenedores en ese pod. Kubernetes admite varios tipos de volúmenes.

PersistentVolumes (PV)

Los PersistentVolumes son recursos que representan almacenamiento. Son independientes de los pods y se administran de manera centralizada. No pueden conectarse directamente a un pod y requieren PersistentVolumeClaims (PVC) para hacerlo.

PersistentVolumeClaims (PVC)

Las PersistentVolumeClaims son solicitudes de almacenamiento que los pods hacen para obtener acceso a un PersistentVolume. Definen los requisitos del almacenamiento, como el tamaño y la clase.

StorageClasses

Las StorageClasses definen la forma en que se provisiona el almacenamiento, incluido el tipo de almacenamiento y las políticas de reclamación. Permiten a los usuarios solicitar almacenamiento de manera dinámica.

Trabajo con volúmenes (Volumes)

Kubernetes ofrece patrones integrados para separar la configuración de las aplicaciones o contenedores. Esto se logra mediante los componentes ConfigMaps y Secrets.

ConfigMap

ConfigMap almacena pares clave-valor de configuración que se pueden montar en los pods como volúmenes o configurar como variables de entorno en contenedores.

Secret

Los Secrets se utilizan para almacenar información sensible, como contraseñas o certificados. Kubernetes admite varios tipos de Secrets, incluidos los de registro de Docker, genéricos y basados en certificados.

Redes (Networking)

Kubernetes proporciona una red flexible y escalable para las aplicaciones en ejecución. Sigue algunas reglas fundamentales de red.

Reglas fundamentales de la red

• Todos los contenedores dentro de un pod pueden comunicarse entre sí sin obstáculos.
• Todos los pods pueden comunicarse con todos los demás pods sin necesidad de NAT.
• Todos los nodos pueden comunicarse con todos los pods (y viceversa) sin NAT.
• La IP que ve un pod es la misma IP que ven otros.

Red de pod (Pod Network)

La red de pod es una red en todo el clúster utilizada para la comunicación entre pods y es administrada por un plugin de la Interfaz de Red de Contenedor (CNI).

Red de servicios (Service Network)

La red de servicios es un rango en todo el clúster de IPs virtuales administrado por kube-proxy para la búsqueda de servicios.

Aplicación de los fundamentos

• De pod a servicio (Pod-to-Service): Se gestiona mediante kube-proxy y se asigna una IP única y persistente en el clúster a los servicios. Los servicios persisten más allá del ciclo de vida de un pod.
• Externo a servicio (External-to-Service): Se maneja mediante kube-proxy y trabaja en cooperación con un proveedor de la nube u otra entidad externa (balanceador de carga).

Interfaz de red de contenedor (CNI)

La red de los pods en Kubernetes se establece a través de la Interfaz de Red de Contenedor (CNI), que funciona como una interfaz entre el tiempo de ejecución de contenedores y un plugin de implementación de red.

Conceptos y recursos

La API y el modelo de objetos

Kubernetes proporciona una API RESTful para todas las interacciones con el clúster. La herramienta de línea de comandos kubectl envuelve esta API. En Kubernetes, todo es un objeto de API.

Grupos de API (API Groups)

Un grupo de API es una ruta compatible con REST que actúa como descriptor de tipo para un objeto de Kubernetes. Se hace referencia a él dentro de un objeto como apiVersion y kind.

Versionado de la API

La API de Kubernetes tiene tres niveles de madurez: Alpha (posiblemente con errores), Beta (probada y considerada estable) y Estable (lanzada y sin cambios en el esquema de API).

Modelo de objetos

Los objetos son registros de intención o entidades persistentes que representan el estado deseado del objeto en el clúster. Todos los objetos deben tener apiVersion, kind y los campos anidados metadata.name, metadata.namespace y metadata.uid.

Modelo de objetos – Cargas de trabajo (Workload)

Los objetos relacionados con las cargas de trabajo en Kubernetes tienen dos campos adicionales anidados: spec (que describe el estado deseado) y status (que es gestionado por Kubernetes y describe el estado real).

Objetos fundamentales

Kubernetes tiene varios bloques de construcción fundamentales que forman la base de sus componentes de nivel superior, incluyendo:

• Namespaces: Son entornos lógicos que permiten la partición y el acceso a recursos dentro del clúster.
• Pods: Son los componentes básicos de las cargas de trabajo en Kubernetes.
• Servicios: Proporcionan una forma unificada de acceder a los pods expuestos.
• Etiquetas (Labels): Son pares clave-valor que se utilizan para identificar y agrupar objetos relacionados.
• Selectores: Utilizan etiquetas para filtrar u seleccionar objetos.

Namespaces

Los namespaces son entornos lógicos que ayudan a separar y gestionar los recursos dentro de un clúster. Permiten una partición lógica y un control de acceso adecuado.

Pod

Los pods son los bloques de construcción fundamentales para las cargas de trabajo en Kubernetes. Pueden contener uno o más contenedores que comparten almacenamiento y espacio de red. Cada pod tiene atributos clave, como nombre, imagen, puertos, variables de entorno y más.

Etiquetas (Labels)

Las etiquetas son pares clave-valor que se utilizan para identificar, describir y agrupar objetos relacionados en Kubernetes. Pueden aplicarse a nodos, pods, servicios, etc.

Selectores

Los selectores utilizan etiquetas para filtrar u seleccionar objetos en Kubernetes. Pueden ser de tipo basado en igualdad o basado en conjuntos.

Servicios (Services)

Los servicios proporcionan una forma unificada de acceder a las cargas de trabajo expuestas. Tienen tipos diferentes, como ClusterIP, NodePort, LoadBalancer y ExternalName, para satisfacer diferentes necesidades.

Tipos de Servicios en Kubernetes

Kubernetes ofrece varios tipos de servicios que permiten exponer y acceder a aplicaciones y cargas de trabajo en el clúster. Cada tipo de servicio se adapta a necesidades específicas de exposición y acceso, lo que brinda flexibilidad para satisfacer diversos escenarios de implementación.

• ClusterIP
• NodePort
• LoadBalancer
• ExternalName

ClusterIP (Tipo predeterminado)

El servicio ClusterIP es el tipo predeterminado en Kubernetes. Proporciona una dirección IP interna y estática que solo es accesible dentro del clúster. Este tipo de servicio es ideal para exponer aplicaciones y servicios que deben ser consumidos internamente por otras partes del clúster.

Uso típico: Se utiliza para exponer bases de datos internas, servicios internos o cualquier aplicación que no deba estar directamente expuesta fuera del clúster.

NodePort

NodePort es un tipo de servicio que expone la aplicación en un puerto específico en todos los nodos del clúster. Permite que las aplicaciones sean accesibles desde fuera del clúster a través de una dirección IP de nodo y el puerto especificado.

Uso típico: NodePort se utiliza cuando es necesario acceder a una aplicación desde fuera del clúster, como aplicaciones web públicas o servicios que deben ser accesibles desde fuera del clúster.

LoadBalancer

El servicio LoadBalancer se integra con el equilibrador de carga proporcionado por la nube en la que se ejecuta el clúster Kubernetes. El proveedor de la nube asigna una dirección IP externa y gestiona la distribución del tráfico a través de los nodos del clúster.

Uso típico: LoadBalancer es ideal cuando se necesita escalabilidad automática y equilibrio de carga para una aplicación expuesta al público en Internet, como sitios web de alta disponibilidad.

ExternalName

ExternalName no crea una exposición directa al clúster ni una dirección IP interna. En cambio, mapea el servicio a un registro DNS externo. Esto es útil cuando se necesita redirigir el tráfico a servicios externos administrados por proveedores de servicios externos, como bases de datos o APIs en la nube.

Uso típico: Se utiliza para redirigir el tráfico a servicios externos, como bases de datos gestionadas por proveedores de servicios en la nube o API de terceros.

Conclusión

Es importante destacar que aún hay mucho más por explorar en el mundo de Kubernetes. Hemos visto una introducción sólida a sus componentes clave, pero hay aspectos más avanzados y que se podrían detallar mucho más.

Algunos de estos temas excluídos en el artículo son la gestión avanzada de recursos, la escalabilidad, la seguridad, la alta disponibilidad, las prácticas recomendadas para la implementación de aplicaciones, etc. La curiosidad es quien marca el camino.