Kubernetes 101: Una introducción holística

Kubernetes se está convirtiendo rápidamente en el nuevo estándar para implementar y administrar software en la nube. Con todo el poder que Kubernetes proporciona, sin embargo, viene una curva de aprendizaje compleja. Cuando recién empiezas, tratar de analizar la documentación oficial puede ser abrumador.

Hay muchas piezas diferentes que componen el sistema, y puede ser difícil saber cuáles son relevantes para su caso de uso. Esta publicación te proporcionará una vista simplificada de Kubernetes, pero intentará dar una visión general de alto nivel de los componentes más importantes y cómo encajan entre sí.
Primero, veamos cómo se representa el hardware.

Nodes

Un nodo es la unidad más pequeña de hardware en Kubernetes. Es una representación de una sola máquina en su clúster. En la mayoría de los sistemas de producción, un nodo probablemente sea una máquina física en un centro de datos o una máquina virtual alojada en un proveedor de la nube como Google Cloud Platform, mi favorita plataforma, pero se pueden desplegar cluster de K8s (el acrónimo para Kubernetes) en multiples proveedores de nube como AWS, IBM Cloud y Azure, entre otros. Sin embargo, no permita que las convenciones lo limiten; en teoría, puedes hacer un nodo de casi cualquier cosa.

Cluster

Aunque trabajar con nodos individuales puede ser útil, no es la forma de Kubernetes. En general, se debe pensar en el clúster como un todo, en lugar de preocuparse por el estado de los nodos individuales.

En Kubernetes, los nodos agrupan sus recursos para formar una máquina más poderosa. Cuando implementas programas en el clúster, maneja de manera inteligente el trabajo de distribución a los nodos individuales por usted. Si se agregan o eliminan nodos, el clúster cambiará de trabajo según sea necesario. No debería de importarle al programa, ni al programador, que máquinas individuales realmente ejecutan el código.

Si este tipo de sistema parecido a una colmena te recuerda a los Borg de Star Trek, no estás solo; “Borg” es el nombre del proyecto interno de Google en el que se basó Kubernetes.

Les gustaría entender cómo funciona “por debajo” el algoritmo del cluster que administra los nodos? Les dejo este sitio que explica muy muy bien el algoritmo de Raft:

http://thesecretlivesofdata.com/

Persistent Volumens

Debido a que no se garantiza que los programas que se ejecutan en su clúster se ejecuten en un nodo específico, los datos no se pueden guardar en ningún lugar arbitrario del sistema de archivos. Si un programa intenta guardar datos en un archivo para más tarde, pero luego se reubica en un nuevo nodo, el archivo ya no estará donde el programa espera que esté. Por esta razón, el almacenamiento local tradicional asociado a cada nodo se trata como un caché temporal para contener programas, pero no se puede esperar que los datos guardados localmente persistan. Esto se llaman Servicios Volátiles

Para almacenar datos permanentemente, Kubernetes usa volúmenes persistentes. Si bien los recursos de CPU y RAM de todos los nodos se agrupan y administran de manera efectiva por el clúster, el almacenamiento persistente de archivos no lo es. En cambio, las unidades locales o en la nube se pueden conectar al clúster como un volumen persistente. Esto puede considerarse como conectar un disco duro externo al clúster. Los volúmenes persistentes proporcionan un sistema de archivos que se puede montar en el clúster, sin estar asociado con ningún nodo en particular

Ahora que entendemos los elementos de hardware básicos, hablemos de los componentes de software

Containers

Los programas que se ejecutan en Kubernetes se empaquetan como contenedores de Linux. Los contenedores son un estándar ampliamente aceptado, por lo que ya hay muchas imágenes preconstruidas que se pueden implementar en Kubernetes.

La “contenedorización” (suena raro el termino en español jeje) le permite crear entornos de ejecución Linux autónomos. Cualquier programa y todas sus dependencias pueden agruparse en un solo archivo y luego compartirse en Internet. Cualquiera puede descargar el contenedor e implementarlo en su infraestructura con muy poca configuración requerida. La creación de un contenedor se puede realizar mediante programación, lo que permite la formación de potentes canalizaciones de CI y CD.

Se pueden agregar varios programas en un solo contenedor, pero debe limitarse a un proceso por contenedor si es posible. Es mejor tener muchos recipientes pequeños que uno grande. Si cada contenedor tiene un enfoque estricto, las actualizaciones son más fáciles de implementar y los problemas son más fáciles de diagnosticar, así como la escalabilidad es más fácil de planear y predecir.

Pods

A diferencia de otros sistemas que puede haber utilizado en el pasado, Kubernetes no ejecuta contenedores directamente; en su lugar, envuelve uno o más contenedores en una estructura de nivel superior llamada pod.

Cualquier contenedor en el mismo pod compartirá los mismos recursos y la red local. Los contenedores pueden comunicarse fácilmente con otros contenedores en la misma cápsula como si estuvieran en la misma máquina mientras mantienen un grado de aislamiento de los demás.

Los pods se usan como la unidad de replicación en Kubernetes. Si su aplicación se vuelve demasiado “intensa” y una sola instancia de pod no puede transportar la carga, Kubernetes se puede configurar para implementar nuevas réplicas de su pod en el clúster según sea necesario. Incluso cuando no está bajo una carga pesada, es estándar tener múltiples copias de un pod funcionando en cualquier momento en un sistema de producción para permitir el equilibrio de carga y la resistencia a fallas.
Las cápsulas pueden contener múltiples contenedores, pero debe limitarse cuando sea posible. Debido a que los pods se escalan hacia arriba y hacia abajo como una unidad, todos los contenedores en un pod deben escalarse juntos, independientemente de sus necesidades individuales. Esto conduce a la pérdida de recursos y una factura costosa. Para resolver esto, las cápsulas deben permanecer lo más pequeñas posible, por lo general, sosteniendo solo un proceso principal y sus contenedores auxiliares estrechamente acoplados (estos contenedores auxiliares generalmente se denominan “side-cars”). Mi recomendación es, use solamente una sola imagen de contenedor por Pod.

Deployment

Aunque los pods son la unidad básica de cómputo en Kubernetes, generalmente no se despliegan directamente en un clúster. En cambio, los pods generalmente son administrados por una capa más de abstracción: el deployment.
El objetivo principal de una implementación es declarar cuántas réplicas de un pod deberían ejecutarse a la vez. Cuando se agrega una implementación al clúster, automáticamente aumentará el número de pods solicitados y luego los monitoreará. Si un módulo muere, el deployment lo volverá a crear automáticamente.
Con un deployment, no tiene que lidiar con los pods manualmente. Simplemente puede declarar el estado deseado del sistema, y se gestionará automáticamente.

Ingress

Utilizando los conceptos descritos anteriormente, puede crear un grupo de nodos e iniciar deployments de pods en el grupo. Sin embargo, hay un último problema que resolver: permitir el tráfico externo a su aplicación.

Por defecto, Kubernetes proporciona aislamiento entre los pods y el mundo exterior. Si desea comunicarse con un servicio que se ejecuta en un pod, debe abrir un canal para la comunicación. Esto se conoce como Ingress.
Hay varias formas de agregar ingreso a su clúster. Las formas más comunes son agregando un controlador Ingress o un LoadBalancer. Las diferencias exactas entre estas dos opciones están fuera del alcance de esta publicación, pero debe tener en cuenta que el Ingress es algo que debe manejar antes de poder experimentar con Kubernetes.

Que sigue
Lo que les describí en este articulo es una versión simplificada de Kubernetes, pero debería darte los conceptos básicos que necesitas para comenzar a experimentar.

Si quieres aprender más sobre Kubernetes, te invito a seguir nuestra comunidad de Kubernetes Costa Rica y mi canal personal de Youtube donde coloco tutoriales y podcast respecto a Kubernetes, Cloud Native y Google Cloud Platform en general.

Te invito a conectar en LinkedIn también donde publico recursos muy útiles sobre K8s: https://www.linkedin.com/in/kevinblanco/