Introducción a Kubernetes

En este post vamos a estar revisando los fundamentos principales de Kuberntes. Esta es una plataforma que hoy es un State-Of-The-Art respecto a la orquestación de Contenedores… ¿Por qué? Averiguemoslo en el post!

¿Que es Kubernetes?

Según la documentación oficial, Kubernetes es un motor de orquestación de contenedores de código abierto diseñado para automatizar el despliegue, el escalado y la gestión de aplicaciones en contenedores. Este proyecto de código abierto está alojado por la Cloud Native Computing Foundation (CNCF).

Se ha convertido en un estándar de facto para la gestión de aplicaciones modernas gracias a sus características clave, como:

Portabilidad y flexibilidad: permite a las aplicaciones ejecutarse de manera consistente en entornos locales, en la nube pública o en configuraciones híbridas.
Autoreparación: reinicia automáticamente contenedores que fallan, reemplaza nodos que no responden y asegura la salud general del clúster.
Escalado automático: ajusta los recursos de manera dinámica en función de la carga de trabajo.
Despliegues continuos: facilita estrategias avanzadas como canarying, blue-green, y rolling updates sin interrumpir el servicio.

Gracias a estas capacidades, Kubernetes permite a los equipos de desarrollo y operaciones entregar software más rápido, reducir costos y mejorar la resiliencia de las aplicaciones.

¿De donde surge Kubernetes?

Los origenes de Kubernetes nos llevan a Google, uno de los grandes actores de la tecnología desde los comienzos de internet, que desarrolló una plataforma para manejar las cargas de Contenedores para su infraestructura Global con un alcance a nivel mundial para millones de usuarios.

Google desarrolló Borg para la orquestación de sus contenedores que permitian que los usuarios de esta compañía utilizaran servicios como Search, Gmail y Maps entre otros. Hoy es la plataforma que continúa utilizando para acercar estos servicios a usuarios de todo el mundo.

¿Qué es Borg y cómo se “convierte” en Kubernetes?

Borg es el sistema de gestión de clústeres de Google que ejecuta cientos de miles de Jobs, provenientes de miles de aplicaciones, en clústeres que pueden tener decenas de miles de máquinas.

Esta plataforma logra una alta utilización de los recursos combinando control de admisión, empaquetado eficiente de tareas, sobrecompromiso y compartición de máquinas, mientras garantiza el aislamiento de rendimiento a nivel de procesos. Además, soporta aplicaciones de alta disponibilidad con funciones que minimizan el tiempo de recuperación ante fallos y políticas de programación que reducen fallos correlacionados.

Borg simplifica la experiencia del usuario mediante un lenguaje declarativo para especificar trabajos, integración con servicios de nombres, monitoreo en tiempo real y herramientas para analizar y simular el comportamiento del sistema.

Google aprovechó su experiencia operativa con Borg para diseñar Kubernetes, un sistema inspirado en sus principios, pero optimizado para ser abierto, modular y portable.

Borg es el predecesor de Kubernetes.

El primer Commit de Kubernetes fue realizado el 6 de Junio de 2014 en GitHub marcando un Hito en la historia de la tecnología para siempre

Kubernetes fue “oficialmente regalado” a la comunidad a través de la Cloud Native Computing Foundation (CNCF) el 10 de Marzo de 2016, promoviendo estándares abiertos para la orquestación de contenedores. Así, Kubernetes democratizó el acceso a tecnologías avanzadas de orquestación, permitiendo que empresas de cualquier tamaño implementen prácticas de nivel empresarial similares a las de Google.

Timeline de Kubernetes

La historia de Kubernetes comienza con un commit histórico el 6 de junio de 2014, seguido por el anuncio del proyecto durante la keynote de Eric Brewer, ingeniero de Google, el 10 de junio en DockerCon 2014, acompañado de una publicación en el blog de Google.

Durante el siguiente año, una pequeña comunidad de colaboradores, principalmente de Google y Red Hat, trabajó arduamente en el proyecto, culminando con el lanzamiento de la versión 1.0 el 21 de julio de 2015. Ese mismo día, Google anunció que Kubernetes sería donado a una nueva rama de la Linux Foundation llamada Cloud Native Computing Foundation (CNCF).

Hitos y actualizaciones notables desde la versión 1.0:

Diciembre 2016: Kubernetes 1.5 introduce la pluggabilidad del runtime con soporte inicial para CRI y soporte alfa para nodos Windows. También aparecen los StatefulSets y PodDisruptionBudgets en versión beta.
Abril 2017: Se introduce el Role-Based Access Control (RBAC).
Junio 2017: En Kubernetes 1.7, los ThirdPartyResources (TPRs) son reemplazados por los CustomResourceDefinitions (CRDs).
Diciembre 2017: Kubernetes 1.9 lleva la API de Workloads a disponibilidad general (GA), estabilizando objetos como Deployment y ReplicaSet tras más de un año de uso en producción.
Diciembre 2018: En la versión 1.13, el Container Storage Interface (CSI) y la herramienta kubeadm llegan a GA, y CoreDNS se convierte en el servidor DNS predeterminado.
Septiembre 2019: Los CRDs alcanzan GA en Kubernetes 1.16.
Agosto 2020: Kubernetes 1.19 extiende la ventana de soporte para lanzamientos a 1 año.
Diciembre 2020: Dockershim es deprecado en la versión 1.20.
Abril 2021: El ciclo de lanzamientos cambia de 4 a 3 versiones por año.
Julio 2021: APIs beta ampliamente utilizadas son eliminadas en la versión 1.22.
Mayo 2022: En Kubernetes 1.24, las APIs beta están deshabilitadas por defecto, y Dockershim es eliminado.
Diciembre 2022: En la versión 1.26, se realiza una importante revisión de la API de batch y jobs, mejorando el soporte para cargas de trabajo de AI/ML y batch.

¿Cual es “el problema” que soluciona?

Manejar contenedores de manera manual implica tareas repetitivas y propensas a errores, como iniciar, detener, escalar y monitorear cada contenedor individualmente, además de configurar redes y asegurar la persistencia de datos. Este tipo de tareas podemos encontrarlas al manejar ambientes basados en Docker hosts, donde nosotros, los DevOps Engineers o SREs debemos encargarnos de gestionar cada uno de los aspectos de la infraestructura.

Más allá de que manejar las cargas de trabajo en muchos Contenedores nos trae muchas ventajas de gestion de recursos y estandarización en comparación a utilizar muchas maquinas virtuales, tambien nos trae nuevos (y muchos) desafios para mantenerlos.

Este enfoque puede volverse inmanejable a medida que el número de contenedores crece, generando problemas de sobrecarga operativa, falta de consistencia y tiempos de respuesta prolongados ante fallos.

Kubernetes es una plataforma Automatica, bajo los estandares de SRE de Google. Resuelve estos desafíos automatizando el despliegue, escalado y gestión de contenedores.

Ofrece características como:

Autoescalado,
Autoreparación,
Balanceo de carga,
gestión centralizada del ciclo de vida de aplicaciones
y un sistema de redes propio, que simplifica la comunicación entre servicios.

Esto no solo mejora la eficiencia de las operaciones de infraestructura, sino que también asegura alta disponibilidad, escalabilidad dinámica y una experiencia más consistente en cualquier entorno.

¿Cuales son los beneficios de usar Kubernetes?

Automatización del despliegue y la gestión
- Kubernetes automatiza tareas repetitivas como el despliegue, escalado y reinicio de contenedores, reduciendo el esfuerzo manual y los errores humanos.
- Todo esto basado en archivos YAML declarativos.
Escalabilidad dinámica
- Ajusta automáticamente los recursos según la demanda, optimizando el uso de infraestructura y reduciendo costos.
Alta disponibilidad y tolerancia a fallos
- Con AutoHealing reemplaza contenedores fallidos, con Balanceo de Carga integrado redistribuye cargas asegurando la continuidad del servicio con mínima interrupción.
Portabilidad y consistencia
- Gracias a un aprovechamiento maximo de la tecnología de Contenedores, permite ejecutar aplicaciones de manera consistente en entornos locales, nubes públicas o híbridas, eliminando problemas de compatibilidad.
- Kubernetes facilita la gestión de arquitecturas basadas en microservicios.
Balanceo de carga
- Distribuye automáticamente el tráfico entre los pods, asegurando que las aplicaciones mantengan un rendimiento óptimo. Todo esto se realiza de manera algoritmica en funcionalidades Built In de la plataforma.
Estrategias de Despliegue integradas
- Implementa estrategias como actualizaciones progresivas (rolling updates), Canarying o blue-green deployments, minimizando el impacto en los usuarios finales.
Escalabilidad horizontal
- Escala fácilmente aplicaciones añadiendo o eliminando réplicas de pods según las necesidades.
Comunidad activa y soporte de ecosistema.
- Al ser un proyecto de código abierto, cuenta con una gran comunidad que desarrolla herramientas y extensiones para ampliar sus capacidades.
Reducción de costos operativos
- La automatización y optimización de recursos permiten aprovechar al máximo la infraestructura disponible, reduciendo costos.
- Aunque tambien nos trae nuevos desafíos al mantener la plataforma.
Integración con herramientas de DevOps
- Se integra fácilmente con CI/CD, sistemas de monitoreo, y herramientas como Helm, Prometheus y Grafana, fortaleciendo los flujos de trabajo DevOps.

Arquitectura

En alto nivel, la arquitectura de Kubernetes está compuesta por dos componentes principales: el Control Plane y los Nodos (Nodes), los cuales trabajan en conjunto para administrar y orquestar aplicaciones en contenedores.

1. Control Plane

El Control Plane es el cerebro de Kubernetes, tiene la visibilidad del estado del cluster a través de ETCD y responsable de tomar decisiones sobre el estado del clúster y manejar la orquestación general de los contenedores. Sus componentes principales son:

API Server (api):
Exposición de la API de Kubernetes que actúa como punto de entrada para todas las operaciones administrativas. Recibe peticiones (por ejemplo, kubectl) y las procesa.
Controller Manager (c-m, c-cm):
Gestiona los controladores que garantizan que el estado deseado del clúster se mantenga. Ejemplos incluyen replicar pods o manejar fallos en los nodos.
etcd:
Base de datos key-value que almacena toda la información de configuración y estado del clúster de forma consistente.
Scheduler (sched):
Decide en qué nodo se ejecutará cada pod basándose en requisitos de recursos y políticas definidas.

2. Nodos

Los nodos son las máquinas (físicas o virtuales) donde se ejecutan los contenedores de las aplicaciones. Cada nodo contiene los siguientes componentes:

Kubelet:
Es un agente que corre en cada nodo y se encarga de comunicarse con el Control Plane para asegurar que los contenedores se ejecuten según las instrucciones recibidas y estén en el estado deseado.
Kube-proxy (k-proxy) o CNI:
Componente que maneja las reglas de red para exponer los servicios de los pods dentro y fuera del clúster.

10 Objetos básicos de Kubernetes

Los objetos de Kubernetes son las entidades que representan el estado deseado del clúster, como las aplicaciones en ejecución, las configuraciones de red, y los volúmenes persistentes. A continuación, describiremos los objetos básicos más importantes:

1. Namespaces

Permiten dividir el clúster en entornos lógicos completamente aislados dentro de cluster.
Normalmente son utilizados para separar recursos entre equipos, ambientes o proyectos (por ejemplo, desarrollo, staging y producción).

2. Pods

Unidad mínima básica de despliegue en Kubernetes.
Representa uno o más contenedores que comparten un entorno basico de comunicación de Red (Network Namespace).
Se dice que los Pods son efímeros en Kubernetes ya que pueden ser creados y eliminados segun sea necesario.

3. Services

Son el endpoint de acceso estatico para la comunicación inbound hacia una o mas replicas de un Pod.
Debido a que los pods en Kubernetes son efímeros, los Servicios proporcionan un punto de acceso estable a un conjunto dinámico de Pods.
Tipos de Services:
- ClusterIP: Acceso interno dentro del clúster.
- NodePort: Exposición a través de un puerto específico del nodo.
- LoadBalancer: Exposición pública mediante un balanceador de carga externo.

4. Deployments

Administra un conjunto de Pods para ejecutar una carga de trabajo de aplicación.
Generalmente para aplicaciones Stateless.
Un Deployment ofrece actualizaciones declarativas para Pods y ReplicaSets.
Facilitan actualizaciones progresivas (rolling updates) y revertir cambios en caso de errores.

5. StatefullSet

Un StatefulSet es un objeto de Kubernetes diseñado para gestionar el despliegue y la escalabilidad de aplicaciones con estado.
A diferencia de los Deployments, que se utilizan para aplicaciones sin estado, los StatefulSets garantizan que cada Pod tenga una identidad única y persistente a lo largo de su ciclo de vida.
Ideal para bases de datos (por ejemplo, MySQL, Cassandra), sistemas de almacenamiento distribuido o cualquier aplicación que necesite mantener su estado en un clúster.

6. Volumes Persistentes

Proporcionan almacenamiento persistente a los Pods.
Los datos en un Volume persisten más allá del ciclo de vida del contenedor.
Ejemplos: emptyDir, hostPath, PersistentVolume (PV) y PersistentVolumeClaim (PVC).

7. ConfigMaps

Almacenan configuraciones en forma de key-value pairs.
Permiten separar las configuraciones del código de la aplicación.

8. Secrets

Similar a los ConfigMaps, pero se utilizan para almacenar información sensible como credenciales, claves API o certificados.
Los datos almacenados están codificados en Base64.
Pueden ser decodificados facilmente: ¿Son seguros los Secrets en Kubernetes?

9. ReplicaSets

Garantizan que un número específico de réplicas de un Pod estén siempre ejecutándose.
Su función principal es mantener la disponibilidad de las aplicaciones.

10. Ingress

Gestiona el acceso externo a los servicios dentro del clúster, generalmente HTTP y HTTPS.
Permite configurar reglas de enrutamiento y balanceo de carga a nivel de aplicaciones.

Propiedad clave: extensibilidad

Kubernetes es altamente extensible gracias a su diseño modular y flexible, lo que permite personalizar su comportamiento sin necesidad de modificar el código fuente de la plataforma. Esto facilita la adaptación de Kubernetes a una amplia variedad de entornos y casos de uso.

La configuración de Kubernetes se puede realizar modificando parámetros en los archivos de configuración o argumentos de línea de comandos, así como ajustando recursos de la API.

Aunque esta personalización es útil, tiene limitaciones, ya que a menudo requiere reiniciar componentes clave y puede ser afectada por actualizaciones en versiones futuras.

Las extensiones, por otro lado, permiten incorporar nuevas funcionalidades al clúster sin alterar su núcleo. Por ejemplo, los controladores personalizados automatizan tareas específicas al interactuar con la API de Kubernetes, mientras que los webhooks validan, autorizan o modifican solicitudes entrantes en tiempo real.

Además, Kubernetes admite plugins binarios como los de almacenamiento (CSI) y redes (CNI), que permiten ampliar las capacidades del clúster para soportar hardware o configuraciones de red específicas. Esto se utiliza mucho para los Plugin de Redes y las integraciones en los Cloud Providers para el uso de servicios Nativos (como EBS, Load Balancers, Persistent Disks, entre otros).

Otro aspecto clave de la extensibilidad de Kubernetes es la posibilidad de crear recursos personalizados con CRDs (Custom Resources Definitions). Esto permite a los usuarios definir nuevos tipos de objetos que funcionan de manera similar a las APIs nativas, lo que facilita la gestión de configuraciones avanzadas o específicas.

Los Operadores de Kubernetes son extensiones que automatizan la gestión de aplicaciones complejas dentro del clúster. Combina Custom Resources y controladores personalizados para gestionar tareas como configuración, escalado, copias de seguridad y recuperación de fallos de forma declarativa. Aprovechan la extensibilidad de Kubernetes para mantener el estado deseado de una aplicación, simplificando su administración y reduciendo la intervención manual. Esto los hace ideales para aplicaciones con estado, como bases de datos o sistemas distribuidos.