¿Es Kubernetes un vaso medio vacío o medio lleno? Depende de cómo se mire. La mecánica de sus capacidades de orquestación es bastante compleja (en mi opinión), y no es raro, incluso para los profesionales más experimentados, darnos cabezazos contra la pared por ello. Al mismo tiempo, a menudo lo he recomendado para usuarios principiantes e incluso para casos empresariales en los que la capacidad de endeudamiento técnico es más limitada, con el fin de trabajar de forma más inteligente, no más dura. Tengo un segundo trabajo a tiempo parcial como autónomo, manteniendo un sistema para una pequeña organización sin ánimo de lucro. Así que cuando no tengo 8 horas al día para hacer de niñera, cuanto más trabajo pesado puedo descargar a K8s, mejor es la vida para todos nosotros. Aún mejor, si trabajo para una gran empresa donde me pagan 8 horas al día por hacer de canguro, preferiría aprovechar la potencia de K8s para que haga la mayor parte de ese trabajo por mí. Esta es la perspectiva del vaso medio lleno: considerar a K8s un aliado que está ahí para hacerte la vida más fácil. Declara lo que quieres y deja que haga lo que mejor sabe hacer.
Como este enfoque puede parecer demasiado simplista, también señalaré nuestra tendencia a hacer las cosas demasiado complejas. Por ejemplo, cuando diseñamos en exceso una solución a prueba de futuro que ni siquiera se vislumbra en el horizonte, o cuando reinventamos la rueda en lugar de utilizar herramientas de eficacia probada que ya han sido creadas específicamente para la tarea. La inmersión en la ingeniería de plataformas no es una excepción, pero hablaremos de ello en otro artículo.
K8s es un organismo potente y complejo, pero recuerda que muchos de nuestros compañeros del sector han dedicado horas a convertirlo en algo que "simplemente funcione", y como aprender a conducir un coche, la mejor forma de aprender es de forma práctica.
Conocí Kubernetes en 2019, en primera línea del equipo de atención al cliente de Linode, cuando lanzamos Linode Kubernetes Engine (LKE). Fue un momento de hundirse o nadar que no pudimos evitar porque la demanda de los usuarios era simplemente demasiado enorme. Teníamos que dar soporte a este producto, lo que significaba que teníamos que aprenderlo, y mejor aún... ¡resolver problemas! Aunque frustrantes a veces, fueron algunas de las experiencias más valiosas de mi carrera.
En este artículo, exploraremos algunas estrategias para aprender y gestionar Kubernetes, basadas en experiencias reales como la mía.
Aprender haciendo
La mejor manera de entender realmente la plataforma es construyendo y rompiendo cosas. Combinar documentación y tutoriales es una buena forma de poner las manos en un clúster que funcione. Pon tus manifiestos en un repositorio Git y tendrás una plantilla a la que siempre podrás recurrir. A continuación, encuentra una forma interesante de romperlo. Esto podría ser dejar que un amigo o compañero de trabajo tome una puñalada en él por lo que no tienen idea de la fuente del problema hasta que comience el diagnóstico. Otro método que he utilizado para esto es hacer algo más complejo que lo que se muestra en la guía. Por ejemplo, digamos que estás tomando el curso CKAD proporcionado por la Fundación Linux. Puede que te enseñen a construir un cluster simplificado con un único plano de control y un nodo trabajador. En su lugar, intente arrancar con éxito un clúster con tres nodos de plano de control para alta disponibilidad y tres nodos trabajadores. Si eso no fuera suficiente desafío, intente implementar una VPC y personalizar el direccionamiento de red del clúster para evitar colisiones en el espacio IP. Incluso si te frustras y tiras la toalla después de algún tiempo, habrás aprendido mucho más de lo que habrías aprendido de otra manera. Estos son sólo dos ejemplos de mi propia experiencia. El cielo es el límite.
Además, herramientas como Minikube o Kind pueden ser muy útiles para la experimentación localizada antes de tocar nada en la nube. Independientemente de cómo vayas a romper, solucionar problemas y arreglar tu clúster, asegúrate de dejar algún rastro de documentación. El acto de escribirlo sirve bien a tu memoria, ya que te obliga a articular los pasos y las soluciones. Si tienes tiempo de hacerlo público, no sólo podrás presumir de una metodología de resolución de problemas estelar, sino que también ayudarás a tus compañeros.
La resolución de problemas como vía de aprendizaje
En cuanto a la metodología de resolución de problemas, no existe una "práctica óptima" en sí, sino "tu práctica", lo que significa que debes encontrar el método que mejor te funcione, sea cual sea. Lo importante es que te esfuerces en desarrollar este músculo y que te resulte más fácil con el tiempo. Los mejores solucionadores de problemas que he conocido se convirtieron en los mejores a través de años de hacer exactamente esto y, como resultado, puedo lanzar cualquier cosa delante de ellos. En consecuencia, también son los que aprenden con más espontaneidad.
Estas son algunas de las técnicas que mejor me funcionan:
- Divide y vencerás: divide el problema por la mitad y elimina sistemáticamente las posibles causas. Aunque para algunos es más fácil escalar sistemáticamente por la pila, a mí me suele salir bien saltar directamente a lo que puedo descartar primero. ¿Desafía esto los buenos consejos de los demás? Es posible. Pero a mí me importa más lo que me funciona a mí.
- LaMonitoring y la observabilidad son tus amigos, y también lo son los errores: Las métricas, los registros y las trazas pueden ofrecer una visión holística del sistema y, mejor aún, ¡una visión holística del problema! Prometheus y Grafana son las herramientas de facto para la monitorización y se adaptan bien a tu elección de herramientas de agregación de registros y trazas. En el mundo real, sin embargo, no siempre se tiene la suerte de contar con una pila de observabilidad completa; a veces, lo mejor que se puede conseguir es Prometheus y Grafana con algunos objetivos remotos para raspar. Afortunadamente, esto sigue siendo muy útil la mayor parte del tiempo, y con o sin mensajes de error, ¡trátalos como si fueran tus amigos! Claro, algunos son más útiles que otros, pero no obstante, esta es la retroalimentación del sistema con la información de que algo salió mal.
- Recrear el problema: En la medida de lo posible, recree el problema en un entorno distinto. De este modo, se puede obtener mucha información sobre la causa, lo que abre las puertas a la búsqueda de la solución. También significa que dispone de un entorno de prueba con el que puede experimentar de forma segura. Una de las muchas razones por las que es una buena práctica aprovechar el poder de la infraestructura como código (IaC), es la capacidad de recrear o destruir rápidamente este entorno según sea necesario. Incluso si esto significa escribirlo uno mismo, en situaciones en las que el entorno no se codificó previamente, dedicar un poco más de tiempo a esto por adelantado puede ahorrar mucho más tiempo después.
- Mantenga un registro de resolución de problemas: Puede que conozcas el concepto de registro de decisiones de arquitectura. ¿Qué le impide aplicar un concepto similar a la resolución de problemas? Nada. Y no necesita ningún formato o convención especial. Basta con llevar un registro de los pasos que se van dando en la resolución de problemas. Esto puede ser útil si necesitas dar marcha atrás o reafirmar las cosas que ya has descartado. Y lo que es mejor, puedes revisarlo más tarde para documentar la solución y explicar cómo has llegado a ella. Ser capaz de articular los pasos y la lógica que los sustenta puede dejar huellas más permanentes en tu memoria. También resultará útil a cualquiera que lea tu documentación. Un buen candidato para esta documentación es una plataforma interna de base de conocimientos, o incluso un blog público para enseñar a otros.
Cuando se enfrentan a problemas particularmente difíciles, la resolución de problemas como una oportunidad de aprendizaje puede conducir a mejoras a largo plazo en las habilidades de resolución de problemas y ayudar a mejorar la forma en que gestiona su infraestructura. Los equipos que perfeccionen e iteren sus procesos de depuración estarán mejor equipados para disfrutar de la potencia de Kubernetes.
Tecnología sencilla y fiable
El ecosistema nativo de la nube (y el panorama de la nube en general) ofrece una plétora de herramientas y marcos de trabajo. Las posibilidades de creación son casi infinitas. Sin embargo, esta noción puede conducir a menudo a algunos escollos importantes: demasiadas herramientas, demasiada complejidad y demasiada deuda técnica. Afortunadamente, es una trampa fácil de evitar con un poco de disciplina y una mentalidad: menos es más. La mejor tecnología es la más fácil de mantener y la más estable, y descubrirás que tus usuarios tienden a estar de acuerdo. Si tuvieras que subir una escalera para llegar al tejado de una casa, no querrías que estuviera tan sobredimensionada hasta el punto de tener dudas sobre si la estás utilizando correctamente. Sería aterrador.
No hay orgullo en mantener una base de código tan complicada que nadie pueda leerla. No hay medalla de oro ni trofeo por construir un sistema tan complejo que casi nadie pueda utilizarlo. Lo que queremos son cosas que funcionen, que sean estables y que podamos utilizar correctamente de forma fiable sin acumular más trabajo. Aquí la simplicidad es tu amiga. Además, recuerda que un patrón de diseño nativo de la nube es aquel que acepta cambios rápidos. La arquitectura de tu aplicación ganará complejidad de forma natural con el tiempo a medida que evolucione, así que no hay necesidad de forzar esa mano. Con un enfoque minimalista además de un diseño modular nativo de la nube, los equipos pueden tener sistemas más esbeltos y seguros, y agilizar las implementaciones, el mantenimiento y la resolución de problemas.
Además, mantener la sencillez ayuda a reducir el riesgo de configuraciones erróneas que atasquen el rendimiento y/o aumenten la superficie de ataque de los fallos de seguridad.
Kubernetes en sí es una abstracción. No podríamos llamarlo "nativo de la nube" si no lo fuera, pero mantener a raya la cantidad de abstracciones innecesarias significa que los ingenieros dedican menos tiempo a gestionar la complejidad subyacente y más a centrarse en aportar valor. Me atengo a mi propia opinión aquí, a contracorriente del enfoque de "todo lo que puedas comer", porque la innovación más avanzada que he visto a lo largo de mi carrera proviene de empresas que encarnan el enfoque de "dieta estricta"; aquellas que se centraron en dominar los conceptos básicos, para poder construir de forma segura y fiable algunos productos de vanguardia que resuelven algunos problemas muy complejos.
Seguir dominando Kubernetes
Una combinación de experiencia práctica, una sólida metodología de resolución de problemas y un enfoque reflexivo de las herramientas puede hacer que Kubernetes sea mucho más fácil de dominar. Aprender haciendo (en lugar de solo leyendo) ayuda a arraigar las habilidades de resolución de problemas que son fundamentales en las operaciones del mundo real. La resolución de problemas no consiste únicamente en arreglar lo que no funciona; es una oportunidad para perfeccionar sus conocimientos, mejorar la documentación y desarrollar un enfoque sistemático que facilite la resolución de futuros problemas. Además, simplificar la pila de Kubernetes minimizando las abstracciones innecesarias reduce la sobrecarga cognitiva y facilita la gestión a lo largo del tiempo.
Como muchos profesionales experimentados han aprendido, un clúster sencillo y bien estructurado es más fácil de mantener y escalar que uno sobrecargado de herramientas que añaden complejidad sin aportar beneficios claros. En última instancia, el éxito con Kubernetes no consiste en utilizar todas las herramientas nuevas del mercado, sino en saber cuáles aportan un valor real a largo plazo.
Si quieres saber más sobre Kubernetes, hablo de ello con más detalle en el podcast KubeFM, que puedes ver en YouTube o más abajo.
Comentarios