La contenerización de los flujos de trabajo de desarrollo, pruebas y producción está revolucionando la gestión de TI en todos los niveles, tanto para aplicaciones y servicios orientados al cliente como internos. Las organizaciones logran mayor eficiencia en el desarrollo y reducen el tiempo de implementación mediante el uso de arquitecturas basadas en microservicios construidas sobre contenedores y el aprovechamiento de marcos de orquestación de contenedores como Kubernetes.
La transición de la TI clásica a los enfoques basados en contenedores suele originarse a partir de iniciativas de base de equipos o departamentos de DevOps que crean un entorno prototipo que otros equipos luego replican. Si bien estos equipos hacen esto para ganar eficiencia y flexibilidad, el resultado suele ser la fragmentación de los clústeres de DevOps y, por lo tanto, un rendimiento deficiente (recursos insuficientes) o una mala utilización (recursos subutilizados fuera de las horas pico). Por lo general, se dan ambas situaciones; mientras un equipo está "sobrecargado" con su demanda y suministro de recursos, otros equipos pueden tener muchos ciclos inactivos disponibles. Peor aún, los equipos a menudo sobredimensionan y luego los costos son enormes. Los estándares de la industria para la utilización de clústeres suelen estar en el rango del 20 %.
Consolidar clústeres (o cuentas en la nube, para el caso) de muchos a menos, idealmente en uno solo, y compartir los recursos entre equipos y casos de uso es la receta para aumentar el rendimiento y la producción al mismo tiempo que se reducen los costos. La consolidación y el uso compartido realmente le permiten hacer más con menos, si puede compartir de manera efectiva, automática y justa.
Los marcos de orquestación de contenedores actuales, como Kubernetes , Docker Swarm o Mesos, no permiten lograr esto de forma predeterminada. Kubernetes y Swarm proporcionan esquemas de distribución de carga de trabajo simples, como 'spread' (round-robin), 'pack' o 'random', y requieren que se segmenten los recursos del clúster manualmente mediante conceptos como espacios de nombres o etiquetas. En Mesos, los diferentes tipos de cargas de trabajo (por ejemplo, Spark, Hadoop o servicios bajo Marathon) traen su propio planificador que puede o no ofrecer políticas de uso compartido de recursos (con su propia lógica y configuración), pero las cargas de trabajo competirán entre sí por el acceso a los recursos y no existe un sistema de políticas general que comprenda cuáles son las cargas de trabajo más importantes para una empresa y cómo satisfacer sus necesidades sin sobrecargarlas con recursos.
Para casos de uso de uso compartido de recursos no triviales, cada uno de estos sistemas requerirá una gran cantidad de intervención manual y aún requerirá sobreaprovisionamiento o sufrirá impactos en el rendimiento causados por conflictos de recursos.
Lo que realmente se necesita para poder compartir un grupo de recursos entre organizaciones y tipos arbitrarios de cargas de trabajo (en contenedores pero también sin contenedores) es un sistema de políticas avanzado que comprenda las características de la carga de trabajo y las prioridades comerciales para que pueda automatizar la toma de decisiones sobre la asignación de recursos y reasignar recursos a pedido cuando cambien las condiciones límite o las demandas.
Navops Command es un ejemplo bastante singular de esta capacidad. Complementa Kubernetes y añade políticas sofisticadas, dinámicas y basadas en la demanda que automatizan la toma de decisiones sobre la priorización de cargas de trabajo y el consumo de recursos en cualquier momento. En comparación con otros marcos de orquestación de contenedores, Kubernetes ofrece el conjunto más completo de capacidades de producción para gestionar cargas de trabajo de forma fiable (como controladores automatizados para réplicas, trabajos, despliegues, admisión de cargas de trabajo, etc.). Con Navops Command sobre Kubernetes, puede ejecutar compilaciones de software, pruebas automatizadas y despliegues de producción de varias aplicaciones y entornos de servicio en el mismo clúster o pool de nube. Las tareas de DevOps y los servicios de producción pueden provenir de varios equipos y tener diferente importancia, que puede variar a lo largo del día. Navops Command garantiza que ninguna de las cargas de trabajo relacionadas interfiera con las demás, funcionando según lo requerido simultáneamente.
Imagen 1: Política de Navops Command 'Acciones proporcionales' que automatiza el intercambio de recursos entre grupos, proyectos e individuos
Con Navops Command es posible lograr tasas de utilización de clústeres del 80 % e incluso superiores. Ofrece sus beneficios incluso dentro de un solo equipo cuando ejecuta varias tareas como compilación, prueba y operaciones, y brinda aún más beneficios cuando comparte entre equipos.
Navops Command muestra lo necesario para ejecutar eficazmente aplicaciones basadas en microservicios, así como otras cargas de trabajo en contenedores, en un entorno compartido (local o en la nube). Actualmente está disponible para cualquier distribución de Kubernetes y se puede evaluar fácilmente como se describe aquí.
Acerca del autor.
Fritz Ferstl es actualmente CTO y Business Development EMEA en Univa Corporation.
Fritz Ferstl aporta 20 años de experiencia en grid y computación en la nube a Univa y, como director de tecnología, ayudará a establecer la visión técnica mientras encabeza alianzas estratégicas. Fritz, considerado durante mucho tiempo como el padre del software Grid Engine y sus precursores Codine y GRD, dirigió el negocio del software Grid Engine desde Sun Microsystems y Oracle durante los últimos 10 años, convirtiéndolo de una tecnología nueva en la solución de administración de carga de trabajo más implementada. en algunos de los entornos de centros de datos más desafiantes del planeta. Bajo el liderazgo de Fritz, el software Grid Engine era de código abierto y ha hecho crecer una comunidad vibrante.
Amazon