Los 6 errores más comunes al implementar Kubernetes

Kubernetes introduce cambios en la forma de construir y ejecutar aplicaciones, y exige el dominio de conceptos como el ingreso, los ReplicaSets o las comprobaciones de salud. Por eso, se han identificado una serie de problemas que suelen aparecer en la implementación y escalado de Kubernetes. En este artículo, examinaremos algunas de estas dificultades y presentaremos soluciones para manejar las nuevas complejidades sin perder la agilidad.

1. No dimensionar los clusters correctamente

Numerosas organizaciones estaban entusiasmadas por adoptar la orquestación de contenedores y se apresuraron a implementar Kubernetes. Sin embargo, con el aumento de la adopción, cada equipo de desarrollo solía crear sus propios clusters para sus aplicaciones. No obstante, resulta un gran esfuerzo que cada equipo de desarrolladores gestione los ciclos de vida y las responsabilidades de cada cluster. Y sin las medidas de protección adecuadas para evitar el aislamiento entre los diferentes equipos, administrar grandes clusters de varios inquilinos puede volverse un desafío importante.

Solución: Diseñe con el aislamiento en mente. Deje más control en manos de los ingenieros de plataforma para crear clusters más pequeños y de un solo inquilino. Pero, si decide seguir este camino, prepárese para nuevos efectos secundarios en la gestión de los clusters.

2. Monitoreo descentralizado nativo de la nube

Los equipos de ingeniería necesitan visibilidad sobre la salud de sus aplicaciones e infraestructura para identificar problemas temprano. Y el monitoreo es posible cuando se trata de un solo cluster. Sin embargo, cuando se trabaja con un gran número de clusters, la observabilidad se vuelve más compleja y difícil de administrar. Las herramientas de observabilidad nativas de la nube también generan una gran cantidad de datos, lo que dificulta concentrarse en qué alertas son realmente importantes.

Solución: No se puede esperar que los equipos inicien sesión y cierren sesión en cada cluster para recopilar registros y métricas importantes. Por lo tanto, lo más recomendable es utilizar una herramienta como Thanos para reunir todas las métricas relevantes en un lugar centralizado. O Amazon-Managed Prometheus (AMP) es otra forma de monitorear métricas y salud en miles de aplicaciones y clusters.

3. Demasiadas configuraciones de grupos de nodos

Tener demasiados tipos diferentes de configuraciones de grupo de nodos puede ser un obstáculo para tu plataforma de Kubernetes. Las cargas de trabajo informáticas a menudo funcionan mejor en infraestructuras y hardware ligeramente diferentes. Tal vez una carga de trabajo funcione mejor en un procesador de computadora basado en ARM o en un chip de GPU específico de NVIDIA. Pero aunque configurar entornos de trabajo muy específicos puede aumentar las optimizaciones de rendimiento, puedes tener problemas de capacidad al programar contenedores.

Solución: Para evitar esto, se sugiere un enfoque más generalizado para programar la ubicación de las cargas de trabajo. En lugar de una relación directa uno a uno, los grupos de nodos deben admitir múltiples tipos de cargas de trabajo.

4. Falta de gobernanza de herramientas K8s

Otro error común es la falta de gobernanza en torno a las herramientas y las integraciones que los desarrolladores introducen en Kubernetes. Estas herramientas pueden respaldar áreas comunes como el registro, la autenticación, el CI/CD, la gestión de bases de datos y más. Sin embargo, a medida que se agregan más capas, puede causar una sobrecarga significativa para los equipos de ingeniería de la plataforma, quienes se vuelven responsables de mantener la disponibilidad y seguridad de todas estas integraciones.

Solución: La solución aquí recomendada es reducir el control total que se le da a los desarrolladores y tratar la plataforma como más un producto. Invocar un modelo basado en solicitudes en el que el equipo de ingeniería de la plataforma acepta las entradas de los desarrolladores, pero tiene el poder de decidir qué integración respaldar como el nuevo «como servicio».

5. Falta de niveles de acceso granulares

Frecuentemente, los equipos de desarrollo tienen acceso completo al administrador de clústeres. Si alguien tiene acceso al clúster completo de Kubernetes, podría instalar integraciones que comprometan el clúster para todos los demás que trabajan en él. Cuando las cuentas de servicio entregan acceso de forma innecesaria, se rompe la regla del menor privilegio, lo que va en contra de una política de seguridad de confianza cero. Según la CNCF, este dilema no es nuevo, ya que la mayoría ya está de acuerdo en que los valores predeterminados de seguridad nativos en la nube son demasiado abiertos.

Solución: Identificar reglas y asignar responsabilidades según la necesidad de acceso. Para ello, herramientas como Open Policy Agent (OPA) o Kyverno pueden ayudar a implementar una gestión de políticas nativas en la nube con una granularidad fina.

6. Aquellos asignados a K8s carecen de las habilidades para operarlo.

Finalmente, otro patrón anti-común asociado con Kubernetes es asignar demasiada responsabilidad a aquellos que carecen de las habilidades para respaldar la tecnología. Muchos equipos todavía están más acostumbrados a las máquinas virtuales o carecen de experiencia en la orquestación de contenedores. Resolver este problema implica reasignar roles o agregar más capas de abstracción.

Solución: Equilibrar las habilidades de los usuarios de Kubernetes con las de sus consumidores.