El cambio de mentalidad técnico necesario para entender K8s.
Mi rol como Tech Manager involucra trabajar con varias empresas y clientes ayudándolas a hacer la transición a Kubernetes. He descubierto que hay un gran esfuerzo al principio para explicar el cambio de mentalidad necesario cuando se trabaja con Kubernetes, tanto para personas no-técnicas como para equipos técnicos que nunca han trabajado con Kubernetes.
Y es que en efecto, entender los conceptos y funcionalidades básicas puede ser complejo y poder visualizar todo el conjunto de elementos alrededor de Kubernetes no es una tarea fácil.
Si bien Kubernetes es un proyecto profundamente técnico, descubrí que uno de los mayores obstáculos iniciales es mapear los procedimientos establecidos en los nuevos conceptos de Kubernetes. Esto puede dar como resultado un “muro de complejidad”.
Para superar este abismo, he descubierto que es necesario establecer un contexto adecuado, por lo que creo que es importante iniciar explicando los siguientes conceptos y cambiar el “mindset”:
- Todo con lo que interactúas es un objeto.
- Todo gira en torno a los pods.
- Kubernetes funciona a través de una serie de bucles de control.
- Los diferentes componentes de Kubernetes no se comunican entre sí directamente.
- Kubernetes ofrece una colección de patrones.
Cuando entiendes estos conceptos, es más fácil empezar a entenderlo, en vez de compararlo con tu infraestructura actual, lo cual es un gran error, no compares.
Expliquemos rápidamente algunos de estos conceptos, pero tenga en cuenta que generalmente es más fácil enseñarlos de manera visual, por lo que le invito a subscribirse a mi canal de Youtube donde subiré video-cursos relacionados a k8s. https://www.youtube.com/c/MrWhitevsElPodcast
Todo es un objeto
Todo lo que puede llegar a ver el usuario en un clúster de Kubernetes se representa como un objeto. Ya sea que se trate de un volumen persistente en su infraestructura de nube, un punto final de red o una máquina en su clúster, se representa como un Objeto con su propia estructura y esquema. Así de simple, no hay que ir mas allá.
Todo gira en torno a los PODS
Un Pod es una unidad básica de carga de trabajo de Kubernetes. Si bien decimos que Kubernetes es una plataforma de orquestador de contenedores, no tratamos con contenedores directamente, sino con un contenedor conceptual a su alrededor llamado Pod.
Un Pod es cómo ejecuta sus contenedores y, por extensión, su software. Por sí solos, los Pods no hacen mucho más que ejecutar contenedores, sino que todos los demás objetos de una forma u otra tratan con la administración de Pods.
La clave para entender es que, si bien Pods puede ejecutar varios contenedores, si desea que se ejecuten varias instancias de una aplicación, no ejecutaría un Pod con múltiples contenedores idénticos, sino que ejecutaría varios Pods con un solo contenedor.
Bucles de control Kubernetes
Ten este concepto en mente:
Interactúas con Kubernetes declarando tu intención (un estado deseado).
Usted especifica de manera declarativa (usando un archivo de manifiesto) los componentes de su sistema y cómo deben comportarse al responder a los cambios. Luego envía este manifiesto a Kubernetes y deja que Kubernetes haga el trabajo duro de implementar y mantener su aplicación.
Para entender como esto se maneja por debajo, es importante entender que es y como funciona etcd, al cuál le dedique un articulo completo fácil de entender:
El núcleo de cómo funciona esto es una serie de bucles de control con un principio básico: asegurarse de que el estado actual observado de la aplicación coincida con el estado deseado.
Un ejemplo simple podría ser solicitar 5 réplicas de un Pod en particular. Defina esto en el archivo de manifiesto y envíelo a Kubernetes (usando un bucle de control de Kubernetes muy común llamado Deployment).
Kubernetes programa los Pods e implementa un bucle de control para garantizar que siempre se ejecuten 5 réplicas del Pod solicitado. Si uno o más caen, casi de inmediato se crearán nuevos.
Los diferentes componentes de Kubernetes no se comunican entre sí directamente
El siguiente punto que trato de transmitir es que Kubernetes es un conjunto de componentes especializados poco acoplados que toman sus propias decisiones independientes en función de los cambios en el estado del clúster.
Y hago énfasis con este punto porque he observado que a menudo es difícil pasar de una mentalidad de “si-esto-entonces-eso” a un modelo más orgánico implementado por Kubernetes.
Por lo general, varios bucles de control están involucrados en un cambio, cada uno centrado en su trabajo sin notificar directamente a los demás acerca de su acción, aparte de manipular el estado central. Al trabajar en su propia área de responsabilidad, en paralelo con otros, logran una tarea de orden superior.
Supongamos que estamos enrutando el tráfico a 5 Pods que ejecutan un servicio web mientras están en proceso de actualización (reemplazo). En este escenario, tenemos dos controladores que realizan dos trabajos especializados: el controlador de implementación está actualizando los 5 pods y el controlador de servicio para redirigir el tráfico de red. Sin embargo, los dos controladores no se comunican directamente entre sí, sino que manipulan un estado centralizado. Por ejemplo, el controlador de Servicio supervisa los cambios en el estado del clúster, observa que se eliminan los Pods antiguos y se agregan nuevos Pods, y toma sus propias decisiones sobre a qué Pods enrutar el tráfico.
Kubernetes ofrece una colección de patrones.
Con estos dos principios clave internalizados, es mucho más fácil explicar y comprender los diferentes objetos ofrecidos por Kubernetes, y que en esencia, Kubernetes es un conjunto de patrones muy útiles para resolver problemas del mundo real.
Si necesita un cierto número de aplicaciones sin estado para estar siempre ejecutándose y fácilmente actualizable, use un objeto de Deployment. Si parte de una aplicación necesita un estado y una identidad persistente, use un objeto StatefulSet, etc.
Cada objeto tiene su propio controlador y un caso de uso específico y puede modificarse, pero al final, son un conjunto de patrones configurables que le permiten describir cómo se debe implementar, acceder a su aplicación y cómo debe responder a los cambios.
Comprender estos conceptos clave permite a los equipos experimentados acelerar y maximizar su uso de Kubernetes y el valor que extraen. Dejan de hablar sobre máquinas individuales o tomas de red específicas y comienzan a describir el comportamiento de sus aplicaciones: cómo deben implementarse, acceder y responder a los cambios.
¿Qué ventajas tiene entender este “mindset” ?
Una vez que hayamos entendido esto, descubriremos que la mayoría de las viejas objeciones han desaparecido y podemos relacionarnos de manera más productiva hacia usar Kubernetes. En lugar de sentirse intimidados por nuevas jergas y conceptos, tenemos que ver cómo Kubernetes simplifica las cosas y ayuda con las aplicaciones del mundo real.
