Kubernetes se está convirtiendo rápidamente en el sistema operativo para Cloud, y aporta una ubicuidad que potencialmente puede proporcionar beneficios masivos para organizaciones de tecnología y desarrolladores(as). Kubernetes ha visto un aumento dramático en visibilidad y adopción a lo largo del 2017, con los principales proveedores de Cloud ofreciendo sus propios servicios nativos de Kubernetes, y varias plataformas de orquestación de contenedores reconstruyéndose con Kubernetes como base. En este artículo, vamos a visitar algunas de las cosas que hemos encontrado interesantes, desafiantes, o entusiasmantes sobre el uso de Kubernetes durante el último año - esperamos que lo encuentres útil.
Para la mayoría de las personas que comienzan con Kubernetes, crear un Cluster es lo primero que se hace. Al inicio de 2017, si querías Clusters de Kubernetes tus opciones eran: usar el servicio de Kubernetes gestionado por Google, o construir uno propio. Por suerte, desde entonces han surgido varias nuevas herramientas y scripts que hacen la vida más fácil. Para el equipo, la introducción de Kops cambió las reglas del juego. Kops ha hecho que ejecutar Cluster de Kubernetes en AWS sea muy fácil.
Con unos pocos comandos, Kops fue capaz de crear un Cluster auto-escalable completo, en el cual hemos estado trabajando cómodamente durante el último año. Kops incluso generó un conjunto de modelos de Terraform para nuestro Cluster, que pudimos incluir en la base de código de automatización de infraestructura que ya teníamos y administrarlo de la misma forma que cualquier otra parte de nuestra infraestructura.
Durante el tiempo que hemos tenido un Cluster de Kubernetes lo hemos actualizado desde la versión 1.4 a la versión actual. Kops administró todos los cambios con su funcionalidad de actualización progresiva que migró nuestro Cluster servidor por servidor, introduciendo gradualmente la nueva versión hasta que todo volvió a reportarse saludablemente. Gracias a Kops hemos sido capaces de mantenernos al tanto de los lanzamientos de Kubernetes, lo cual nos ha permitido usar las últimas funcionalidades a medida que se disponibilizan. Hemos visto el ascenso y caída de PetSets, la introducción de Cronjobs, afinidad de Nodo, contenedores de inicialización, y muchas otras funcionalidades interesantes sin derramar ni una gota de sudor debido a la actualización.
A pesar de la ayuda de Kops, configurar nuestro Cluster no fue un camino de rosas. Encontramos un número de complicaciones, muchas auto-infringidas a medida que aprendíamos, pero también algunas propias de Kops y Kubernetes. Por ejemplo, la funcionalidad de actualización progresiva es fantástica, pero aún está en sus albores. Tuvimos varios problemas con actualizaciones de Cluster que terminaron prematuramente, lo que resultó en distintas versiones de Nodos ejecutándose al mismo tiempo. En varias ocasiones los Pods fueron redistribuidos a otros Nodos mientras se ejecutaba una actualización, y no fueron balanceados de nuevo correctamente cuando la actualización fue hecha, lo que dejó Nodos con mucha utilización y otros casi sin usar. Casos como estos pudieron haber sido mitigados por mejoras recientes en Kops y una cuidadosa planificación de la capacidad.
Con Azure, Google Cloud, y AWS, todos ofreciendo o habiendo anunciado un servicio gestionado de Kubernetes, crear un Cluster en el futuro cercano debería ser tan trivial como crear cualquier otro servicio gestionado de Cloud, y tener una barrera de entrada mucho más baja de lo que ha tenido históricamente. Kops seguirá siendo una herramienta atractiva para organizaciones que necesitan un Cluster autogestionado, pero cada vez más se convertirá en un nicho de mercado.
El equipo y la comunidad de Kubernetes han hecho un gran trabajo para que la experiencia de trabajar con Kubernetes sea fluida e indolora para los(as) desarrolladores(as). El proyecto tiene el carácter distintivo de una comunidad comprometida y documentación rigurosa, lo que significa que como principiante no sólo tienes una gran cantidad de información, guías y talleres para consumir, sino que también eres bienvenido(a) por una comunidad amistosa y servicial. Es difícil no entender y adaptarse rápidamente a Kubernetes, con todo lo que eso conlleva. Ambos sentimos que la documentación y enfoque de Kubernetes para manejar cambios es una de sus mayores fortalezas.
Las personas que quieran probar Kubernetes pueden usar Minikube para crear un pequeño Cluster auto-contenido en la máquina local y desplegar en él como en cualquier otro cluster de Kubernetes. Kubernetes y Minikube pueden impactar significativamente en la forma de trabajo de los(as) desarrolladores(as). Estamos viendo la adopción casi universal de Docker en todas partes, y con Minikube siendo una combinación de un Kubernetes local sobre Docker, tu flujo de desarrollo puede reflejar tu flujo de producción de forma más fiel que antes. Las imágenes de Docker diseñadas para ejecutarse en un ambiente de Kubernetes pueden ejecutarse localmente en un Minikube sin realizar cambios. Existe todo un ecosistema desarrollado alrededor de flujos de trabajo locales, con herramientas como Draft de Azure abordando algunos desafíos interesantes. Incluso el propio Docker ha añadido Kubernetes a su stack tecnológico.
Una vez que tienes claro lo que significa hacer un despliegue a un Cluster, lo que son los Pods, Despliegues, Servicios y demás, te estarás preguntando cómo puedes aplicar prácticas de Entrega Continua a tu flujo de trabajo de Kubernetes. ¿Cómo entregas frecuentemente, con releases idempotentes, sin tiempos de inactividad y con la mayor reutilización y semejanza posible entre los entornos?
Así como Kops, Helm fue otra herramienta que cambió las reglas del juego. Helm es un administrador de paquetes, una herramienta de despliegue, y un repositorio de aplicaciones pre-configuradas. Con Helm puedes escribir manifiestos de Kubernetes como plantillas de código, que pueden ser reutilizadas en todos los entornos mediante ajustes en las configuraciones en tiempo de despliegue usando variables.
Esto es semejante a la infraestructura como código para Kubernetes, y nos brinda la capacidad de repetición y reutilización esperadas de un proyecto de infraestructura bien administrado
Estamos usando Helm ampliamente para automatizar nuestros despliegues a Kubernetes, que son tanto sistemas reales en uso como entornos de prueba transitorios, todo en el mismo código. También confiamos y contribuimos a varios de los cuadros de código abierto de Helm para aplicaciones comunes, tales como Concourse, Grafana, InfluxDB, y muchos otros.
Kubernetes puede sonar como una isla, dejada a su suerte. Estás construyendo software y poniéndolo en ejecución en un Cluster Kubernetes, pero ¿no te estás aislando de tu proveedor de Cloud?
Kubernetes ocupa un espacio muy interesante en el ecosistema de infraestructura Cloud, donde se está convirtiendo en una capa agnóstica entre la plataforma Cloud y las aplicaciones que ejecutamos. Esto puede sonar a aislamiento, pero Kubernetes puede estar a la vez fuertemente integrado con proveedores de Cloud, al tiempo que te permite ser mucho más independiente del proveedor de Cloud de lo que lo serías sin él. Esta idea resulta un poco contradictoria, por lo que vamos a explicarla un poco mejor...
Tienes una aplicación que necesita un Balanceador de Carga, como muchas otras. Tradicionalmente, construirías y empaquetarías tu aplicación, y luego usarías plantillas de CloudFormation o Terraform para describir el entorno en el que desplegar la aplicación, que contendrían una petición específica para crear, por ejemplo, un Elastic Load Balancer de AWS. Con Kubernetes, especificas un Balanceador de Carga en su manifiesto pero sin solicitar explícitamente uno de AWS. Cuando despliegas la aplicación en tu Cluster, Kubernetes interpreta tu petición para un Balanceador de Carga de manera diferente, dependiendo de cuál es el proveedor de Cloud en el que el Cluster está desplegado. Cuando tu Cluster está sobre AWS, un Elastic Load Balancer de AWS se provisiona y se conecta automáticamente a tu contenedor, pero cuando estás en Google Cloud se crea un Balanceador de Carga de GCP en su lugar, todo de manera transparente y sin necesidad de realizar cambios a tu configuración de despliegue.
Los Balanceadores de Carga son solo un ejemplo. El mismo patrón puede aplicarse a registros externos de DNS, volúmenes de almacenamiento de larga duración, pasando por la configuración de red del Cluster. Resulta interesante que este agnosticismo abre la puerta a la posibilidad de ejecutar Clusters federados a través de múltiples proveedores de Cloud para (super) alta disponibilidad, e incluso ejecutar Kubernetes en servidores físicos.
Con la cantidad de actividad que ocurre en un Cluster de Kubernetes -creación y destrucción de Pods, trabajos de cron planificados, despliegues frecuentes - una monitorización adecuada es la clave para comprender el actual estado de salud de tu Cluster. Además, cuando estás recolectando un conjunto adecuado de métricas, puedes alertar a tus equipos cuando el sistema no está ejecutándose correctamente o precisa de atención. De manera similar, debido a la naturaleza dinámica de Kubernetes, un sistema de log centralizado es esencial para permitir el diagnóstico de incidencias cuando se producen.
Cuando estábamos empezando, encontramos que el uso de Kubernetes Dashboard y la colección de métricas de Heapster eran un buen lugar para sumergirse en la observación del comportamiento de nuestro Cluster. La mayoría de los Clusters de Kubernetes tienen el Dashboard de Kubernetes instalado por defecto, o puede instalarse más tarde con un mínimo esfuerzo. El Dashboard te proporciona una vista de alto nivel de la salud de tu Cluster mediante una serie de métricas relativas a cuánta CPU y cuánta memoria están consumiendo los Pods, y como se están forzando los límites de cada Nodo. El dashboard también tiene un conjunto limitado de capacidades de administración, tales como el escalado manual de Pods, visualización de logs, ejecución de comandos en un contenedor, que pueden llevarte sorprendentemente lejos a la hora de observar tu Cluster. El Kubernetes Dashboard es otro excelente ejemplo de cómo el proyecto y la comunidad (el dashboard está dirigido por la comunidad después de todo) acogen a los principiantes, al hacer que información potencialmente complicada esté accesible de manera inmediata con un esfuerzo mínimo.
Una vez que el Dashboard se te queda pequeño es cuando las cosas realmente empiezan a ponerse interesantes. Pasar del Dashboard a un gran sistema de monitorización realmente nos ayudó a comprender cómo se comportaban nuestros sistemas, y qué cosas podríamos intentar para mejorar la salud del Cluster. Nuestro Cluster evolucionó de Heapster y el Dashboard a una combinación de un conjunto de dashboards de Grafana y Prometheus (ambos servicialmente instalados usando Helm).
Toda la planificación en Kubernetes se maneja vía una API central, que resulta ser una característica bastante atractiva. Diversos subsistemas pueden escuchar actividad en el Cluster y realizar acciones sobre eventos, como por ejemplo cuando arranca un nuevo Pod. Usamos esta capacidad para que nuestro sistema de monitorización Prometheus detecte automáticamente cuando se despliegan nuevas aplicaciones en nuestro Cluster. Esto nos permite comenzar a recoger métricas y visualizar su comportamiento inmediatamente.
Esto lo combinamos con algunas configuraciones simples de alertas para recibir notificaciones cuando algún sistema comienza a comportarse de manera incorrecta, todo sin necesidad de intervención humana. Por ejemplo, utilizamos esta configuración para diagnosticar cuándo los Pods sometidos a mucha carga de trabajo estaban dejando a otros Pods sin recursos, y pudimos establecer límites de consumo de recursos más adecuados y configurar reglas de afinidad de Nodo para planificar cargas elevadas de trabajo en Nodos dedicados con más recursos. De manera similar a como hicimos con las métricas, también configuramos Fluentd para que automáticamente accediera a los logs de cada Pod para reenviarlos a nuestro Cluster de ElasticSearch.
Dicho esto, la monitorización y el tratamiento de logs automáticos también tienen algunos costos. Hay un coste económico real: probablemente estás reenviando una cantidad de logs y métricas mucho más grande de la que enviabas hasta ahora, y la tendencia es a aumentar. También está el coste cognitivo de recoger todos estos datos, y un peligro real de alertar en exceso y provocar fatiga o complacencia en tus equipos a la hora de responder a las alertas (HumanOps es una consideración importante en este punto). Recomendamos tener mucho cuidado con las alertas que elegimos para enviar notificaciones; es mejor equivocarse por enviar alertas de menos al principio. Nuestra práctica consiste en enviar todas las alertas a un canal de Slack que se comprueba periódicamente pero que se mantiene mudo para la mayoría de la gente. Una vez que hemos ajustado las alertas que van a ese canal, se promocionan al canal de alertas “reales” y a otras herramientas de notificaciones.
El que estas herramientas sean capaces de auto-enlazarse proporciona un concepto increíblemente potente. Tiene el potencial de revolucionar la manera en que estructuramos y desplegamos aplicaciones. Kubernetes emplea el término Sidecar para referirse a un conjunto de contenedores de soporte que pueden ubicarse junto a las aplicaciones. En vez de que cada aplicación tenga que incluir o solicitar explícitamente su propio conjunto de librerías de monitorización, los Sidecars pueden añadirse automáticamente a tu aplicación y comenzar a proporcionar valor sin añadir complejidad adicional al flujo de desarrollo. Algunos ejemplos de Sidecars que hemos usado ya han sido mencionados — monitorización con Prometheus y recogida de logs con Fluentd. Pero también usamos contenedores que funcionan como proxies inversos, otros para generación automática de certificados TLS, y otros para realización de tareas periódicas como puede ser la ejecución de migraciones de bases de datos. Los Sidecars son un concepto super interesante y pueden tener un impacto significativo en la manera en que diseñes tu sistema.
¿A dónde vamos desde aquí? Hay un entusiasmo creciente en la industria entorno a las arquitecturas “serverless” y basadas en Lambdas, y algunos podrían argumentar que Kubernetes se mueve en dirección contraria.
Puede parecer que Kubernetes está en desacuerdo con las aproximaciones serverless de diseño de sistemas; un gran Cluster de servidores frente a “sin servidores”. Sin embargo, los servicios Lambdas se planifican para ser ejecutados en algún sitio, y es en un Cluster de servidores, solo que no es un Cluster de servidores que tu controles. No todas las organizaciones se sienten a gusto renunciando a ese control, y no todas las cargas de trabajo son compatibles con las limitaciones de servicios Lambdas.
Kubernetes tiene la oportunidad de convertirse en los servidores de un mundo sin servidores. Ya podemos contemplar herramientas como Kubeless y Fission que proporcionan equivalentes de las funciones-como-servicio, pero ejecutándose dentro de Kubernetes. Estas herramientas todavía no son un reemplazo directo para Lambdas, ya que carecen de muchas de las integraciones nativas que hacen a los Lambdas tan poderosos. Pero constituyen un ejemplo interesante de cómo no es una situación mutuamente excluyente, y cómo puedes evitar potencialmente parte del monopolio de los vendedores que actualmente acompaña a las Cloud Functions de Google y las Lambdas de AWS.
El avance más atractivo en este campo, en nuestra opinión, lo constituye AWS Fargate. Aún son escasos los detalles sobre cómo va a funcionar exactamente, pero lo que sabemos hasta ahora es que Fargate es a los contenedores lo que Lambda era a las funciones. En vez de tener que retorcer o descomponer tus bases de código para trabajar dentro las restricciones de Lambda (lo que no siempre es malo, aunque puede serlo ¡si el único motivo por el que lo haces es para satisfacer el propio Lambda!), puedes desplegar un contenedor en Fargate y tenerlo gestionado externamente con un modelo de coste similar al de Lambda. ¿Por qué es esto tan interesante? A principios de 2018 presenciaremos como Fargate se ejecuta sobre Kubernetes en AWS EKS. La flexibilidad y escaso sobrecoste de las aplicaciones sin servidores, ejecutándose opcionalmente en un Cluster gestionado o auto-gestionado de Kubernetes, presumiblemente con todos los beneficios adicionales.
Traducción al español realizada por: Rocío Sepúlveda y Jesús Cardenal Escribano
Comenzando con Clusters
He oído hablar sobre una cosa llamada Kubernetes, pero ¿cómo y dónde comienzo?Para la mayoría de las personas que comienzan con Kubernetes, crear un Cluster es lo primero que se hace. Al inicio de 2017, si querías Clusters de Kubernetes tus opciones eran: usar el servicio de Kubernetes gestionado por Google, o construir uno propio. Por suerte, desde entonces han surgido varias nuevas herramientas y scripts que hacen la vida más fácil. Para el equipo, la introducción de Kops cambió las reglas del juego. Kops ha hecho que ejecutar Cluster de Kubernetes en AWS sea muy fácil.
Con unos pocos comandos, Kops fue capaz de crear un Cluster auto-escalable completo, en el cual hemos estado trabajando cómodamente durante el último año. Kops incluso generó un conjunto de modelos de Terraform para nuestro Cluster, que pudimos incluir en la base de código de automatización de infraestructura que ya teníamos y administrarlo de la misma forma que cualquier otra parte de nuestra infraestructura.
Durante el tiempo que hemos tenido un Cluster de Kubernetes lo hemos actualizado desde la versión 1.4 a la versión actual. Kops administró todos los cambios con su funcionalidad de actualización progresiva que migró nuestro Cluster servidor por servidor, introduciendo gradualmente la nueva versión hasta que todo volvió a reportarse saludablemente. Gracias a Kops hemos sido capaces de mantenernos al tanto de los lanzamientos de Kubernetes, lo cual nos ha permitido usar las últimas funcionalidades a medida que se disponibilizan. Hemos visto el ascenso y caída de PetSets, la introducción de Cronjobs, afinidad de Nodo, contenedores de inicialización, y muchas otras funcionalidades interesantes sin derramar ni una gota de sudor debido a la actualización.
A pesar de la ayuda de Kops, configurar nuestro Cluster no fue un camino de rosas. Encontramos un número de complicaciones, muchas auto-infringidas a medida que aprendíamos, pero también algunas propias de Kops y Kubernetes. Por ejemplo, la funcionalidad de actualización progresiva es fantástica, pero aún está en sus albores. Tuvimos varios problemas con actualizaciones de Cluster que terminaron prematuramente, lo que resultó en distintas versiones de Nodos ejecutándose al mismo tiempo. En varias ocasiones los Pods fueron redistribuidos a otros Nodos mientras se ejecutaba una actualización, y no fueron balanceados de nuevo correctamente cuando la actualización fue hecha, lo que dejó Nodos con mucha utilización y otros casi sin usar. Casos como estos pudieron haber sido mitigados por mejoras recientes en Kops y una cuidadosa planificación de la capacidad.
Con Azure, Google Cloud, y AWS, todos ofreciendo o habiendo anunciado un servicio gestionado de Kubernetes, crear un Cluster en el futuro cercano debería ser tan trivial como crear cualquier otro servicio gestionado de Cloud, y tener una barrera de entrada mucho más baja de lo que ha tenido históricamente. Kops seguirá siendo una herramienta atractiva para organizaciones que necesitan un Cluster autogestionado, pero cada vez más se convertirá en un nicho de mercado.
Developing for and on Kubernetes
Ya tengo un Cluster ¿cómo puede mi equipo comenzar a usarlo y desplegar en él sus aplicaciones?El equipo y la comunidad de Kubernetes han hecho un gran trabajo para que la experiencia de trabajar con Kubernetes sea fluida e indolora para los(as) desarrolladores(as). El proyecto tiene el carácter distintivo de una comunidad comprometida y documentación rigurosa, lo que significa que como principiante no sólo tienes una gran cantidad de información, guías y talleres para consumir, sino que también eres bienvenido(a) por una comunidad amistosa y servicial. Es difícil no entender y adaptarse rápidamente a Kubernetes, con todo lo que eso conlleva. Ambos sentimos que la documentación y enfoque de Kubernetes para manejar cambios es una de sus mayores fortalezas.
Las personas que quieran probar Kubernetes pueden usar Minikube para crear un pequeño Cluster auto-contenido en la máquina local y desplegar en él como en cualquier otro cluster de Kubernetes. Kubernetes y Minikube pueden impactar significativamente en la forma de trabajo de los(as) desarrolladores(as). Estamos viendo la adopción casi universal de Docker en todas partes, y con Minikube siendo una combinación de un Kubernetes local sobre Docker, tu flujo de desarrollo puede reflejar tu flujo de producción de forma más fiel que antes. Las imágenes de Docker diseñadas para ejecutarse en un ambiente de Kubernetes pueden ejecutarse localmente en un Minikube sin realizar cambios. Existe todo un ecosistema desarrollado alrededor de flujos de trabajo locales, con herramientas como Draft de Azure abordando algunos desafíos interesantes. Incluso el propio Docker ha añadido Kubernetes a su stack tecnológico.
Una vez que tienes claro lo que significa hacer un despliegue a un Cluster, lo que son los Pods, Despliegues, Servicios y demás, te estarás preguntando cómo puedes aplicar prácticas de Entrega Continua a tu flujo de trabajo de Kubernetes. ¿Cómo entregas frecuentemente, con releases idempotentes, sin tiempos de inactividad y con la mayor reutilización y semejanza posible entre los entornos?
Así como Kops, Helm fue otra herramienta que cambió las reglas del juego. Helm es un administrador de paquetes, una herramienta de despliegue, y un repositorio de aplicaciones pre-configuradas. Con Helm puedes escribir manifiestos de Kubernetes como plantillas de código, que pueden ser reutilizadas en todos los entornos mediante ajustes en las configuraciones en tiempo de despliegue usando variables.
Esto es semejante a la infraestructura como código para Kubernetes, y nos brinda la capacidad de repetición y reutilización esperadas de un proyecto de infraestructura bien administrado
Estamos usando Helm ampliamente para automatizar nuestros despliegues a Kubernetes, que son tanto sistemas reales en uso como entornos de prueba transitorios, todo en el mismo código. También confiamos y contribuimos a varios de los cuadros de código abierto de Helm para aplicaciones comunes, tales como Concourse, Grafana, InfluxDB, y muchos otros.
Integración Cloud y agnosticismo
He creado mi Cluster y tengo mi aplicación ejecutándose allí, pero me preocupa que ahora no pueda aprovechar al máximo el potencial de mi Cloud. Mis aplicaciones Kubernetes ¿pueden seguir usando servicios nativos de AWS/GCP?Kubernetes puede sonar como una isla, dejada a su suerte. Estás construyendo software y poniéndolo en ejecución en un Cluster Kubernetes, pero ¿no te estás aislando de tu proveedor de Cloud?
Kubernetes ocupa un espacio muy interesante en el ecosistema de infraestructura Cloud, donde se está convirtiendo en una capa agnóstica entre la plataforma Cloud y las aplicaciones que ejecutamos. Esto puede sonar a aislamiento, pero Kubernetes puede estar a la vez fuertemente integrado con proveedores de Cloud, al tiempo que te permite ser mucho más independiente del proveedor de Cloud de lo que lo serías sin él. Esta idea resulta un poco contradictoria, por lo que vamos a explicarla un poco mejor...
Tienes una aplicación que necesita un Balanceador de Carga, como muchas otras. Tradicionalmente, construirías y empaquetarías tu aplicación, y luego usarías plantillas de CloudFormation o Terraform para describir el entorno en el que desplegar la aplicación, que contendrían una petición específica para crear, por ejemplo, un Elastic Load Balancer de AWS. Con Kubernetes, especificas un Balanceador de Carga en su manifiesto pero sin solicitar explícitamente uno de AWS. Cuando despliegas la aplicación en tu Cluster, Kubernetes interpreta tu petición para un Balanceador de Carga de manera diferente, dependiendo de cuál es el proveedor de Cloud en el que el Cluster está desplegado. Cuando tu Cluster está sobre AWS, un Elastic Load Balancer de AWS se provisiona y se conecta automáticamente a tu contenedor, pero cuando estás en Google Cloud se crea un Balanceador de Carga de GCP en su lugar, todo de manera transparente y sin necesidad de realizar cambios a tu configuración de despliegue.
Los Balanceadores de Carga son solo un ejemplo. El mismo patrón puede aplicarse a registros externos de DNS, volúmenes de almacenamiento de larga duración, pasando por la configuración de red del Cluster. Resulta interesante que este agnosticismo abre la puerta a la posibilidad de ejecutar Clusters federados a través de múltiples proveedores de Cloud para (super) alta disponibilidad, e incluso ejecutar Kubernetes en servidores físicos.
Ejecutando sistemas en Kubernetes
Ahora que tengo aplicaciones ejecutándose en mi Cluster, ¿Cómo me aseguro de que se están ejecutando correctamente?Con la cantidad de actividad que ocurre en un Cluster de Kubernetes -creación y destrucción de Pods, trabajos de cron planificados, despliegues frecuentes - una monitorización adecuada es la clave para comprender el actual estado de salud de tu Cluster. Además, cuando estás recolectando un conjunto adecuado de métricas, puedes alertar a tus equipos cuando el sistema no está ejecutándose correctamente o precisa de atención. De manera similar, debido a la naturaleza dinámica de Kubernetes, un sistema de log centralizado es esencial para permitir el diagnóstico de incidencias cuando se producen.
Cuando estábamos empezando, encontramos que el uso de Kubernetes Dashboard y la colección de métricas de Heapster eran un buen lugar para sumergirse en la observación del comportamiento de nuestro Cluster. La mayoría de los Clusters de Kubernetes tienen el Dashboard de Kubernetes instalado por defecto, o puede instalarse más tarde con un mínimo esfuerzo. El Dashboard te proporciona una vista de alto nivel de la salud de tu Cluster mediante una serie de métricas relativas a cuánta CPU y cuánta memoria están consumiendo los Pods, y como se están forzando los límites de cada Nodo. El dashboard también tiene un conjunto limitado de capacidades de administración, tales como el escalado manual de Pods, visualización de logs, ejecución de comandos en un contenedor, que pueden llevarte sorprendentemente lejos a la hora de observar tu Cluster. El Kubernetes Dashboard es otro excelente ejemplo de cómo el proyecto y la comunidad (el dashboard está dirigido por la comunidad después de todo) acogen a los principiantes, al hacer que información potencialmente complicada esté accesible de manera inmediata con un esfuerzo mínimo.
Pasar tiempo explorando el dashboard realmente nos ayudó a comprender cómo las piezas se relacionan entre sí y que estaba ocurriendo en nuestro Cluster.
Una vez que el Dashboard se te queda pequeño es cuando las cosas realmente empiezan a ponerse interesantes. Pasar del Dashboard a un gran sistema de monitorización realmente nos ayudó a comprender cómo se comportaban nuestros sistemas, y qué cosas podríamos intentar para mejorar la salud del Cluster. Nuestro Cluster evolucionó de Heapster y el Dashboard a una combinación de un conjunto de dashboards de Grafana y Prometheus (ambos servicialmente instalados usando Helm).
Toda la planificación en Kubernetes se maneja vía una API central, que resulta ser una característica bastante atractiva. Diversos subsistemas pueden escuchar actividad en el Cluster y realizar acciones sobre eventos, como por ejemplo cuando arranca un nuevo Pod. Usamos esta capacidad para que nuestro sistema de monitorización Prometheus detecte automáticamente cuando se despliegan nuevas aplicaciones en nuestro Cluster. Esto nos permite comenzar a recoger métricas y visualizar su comportamiento inmediatamente.
Esto lo combinamos con algunas configuraciones simples de alertas para recibir notificaciones cuando algún sistema comienza a comportarse de manera incorrecta, todo sin necesidad de intervención humana. Por ejemplo, utilizamos esta configuración para diagnosticar cuándo los Pods sometidos a mucha carga de trabajo estaban dejando a otros Pods sin recursos, y pudimos establecer límites de consumo de recursos más adecuados y configurar reglas de afinidad de Nodo para planificar cargas elevadas de trabajo en Nodos dedicados con más recursos. De manera similar a como hicimos con las métricas, también configuramos Fluentd para que automáticamente accediera a los logs de cada Pod para reenviarlos a nuestro Cluster de ElasticSearch.
Dicho esto, la monitorización y el tratamiento de logs automáticos también tienen algunos costos. Hay un coste económico real: probablemente estás reenviando una cantidad de logs y métricas mucho más grande de la que enviabas hasta ahora, y la tendencia es a aumentar. También está el coste cognitivo de recoger todos estos datos, y un peligro real de alertar en exceso y provocar fatiga o complacencia en tus equipos a la hora de responder a las alertas (HumanOps es una consideración importante en este punto). Recomendamos tener mucho cuidado con las alertas que elegimos para enviar notificaciones; es mejor equivocarse por enviar alertas de menos al principio. Nuestra práctica consiste en enviar todas las alertas a un canal de Slack que se comprueba periódicamente pero que se mantiene mudo para la mayoría de la gente. Una vez que hemos ajustado las alertas que van a ese canal, se promocionan al canal de alertas “reales” y a otras herramientas de notificaciones.
El que estas herramientas sean capaces de auto-enlazarse proporciona un concepto increíblemente potente. Tiene el potencial de revolucionar la manera en que estructuramos y desplegamos aplicaciones. Kubernetes emplea el término Sidecar para referirse a un conjunto de contenedores de soporte que pueden ubicarse junto a las aplicaciones. En vez de que cada aplicación tenga que incluir o solicitar explícitamente su propio conjunto de librerías de monitorización, los Sidecars pueden añadirse automáticamente a tu aplicación y comenzar a proporcionar valor sin añadir complejidad adicional al flujo de desarrollo. Algunos ejemplos de Sidecars que hemos usado ya han sido mencionados — monitorización con Prometheus y recogida de logs con Fluentd. Pero también usamos contenedores que funcionan como proxies inversos, otros para generación automática de certificados TLS, y otros para realización de tareas periódicas como puede ser la ejecución de migraciones de bases de datos. Los Sidecars son un concepto super interesante y pueden tener un impacto significativo en la manera en que diseñes tu sistema.
El futuro: ¿Es serverless?
Bueno, todo esto es muy interesante, pero ¿no es solo una pérdida de tiempo, considerando que Lambda y serverless son el futuro?¿A dónde vamos desde aquí? Hay un entusiasmo creciente en la industria entorno a las arquitecturas “serverless” y basadas en Lambdas, y algunos podrían argumentar que Kubernetes se mueve en dirección contraria.
Puede parecer que Kubernetes está en desacuerdo con las aproximaciones serverless de diseño de sistemas; un gran Cluster de servidores frente a “sin servidores”. Sin embargo, los servicios Lambdas se planifican para ser ejecutados en algún sitio, y es en un Cluster de servidores, solo que no es un Cluster de servidores que tu controles. No todas las organizaciones se sienten a gusto renunciando a ese control, y no todas las cargas de trabajo son compatibles con las limitaciones de servicios Lambdas.
Kubernetes tiene la oportunidad de convertirse en los servidores de un mundo sin servidores. Ya podemos contemplar herramientas como Kubeless y Fission que proporcionan equivalentes de las funciones-como-servicio, pero ejecutándose dentro de Kubernetes. Estas herramientas todavía no son un reemplazo directo para Lambdas, ya que carecen de muchas de las integraciones nativas que hacen a los Lambdas tan poderosos. Pero constituyen un ejemplo interesante de cómo no es una situación mutuamente excluyente, y cómo puedes evitar potencialmente parte del monopolio de los vendedores que actualmente acompaña a las Cloud Functions de Google y las Lambdas de AWS.
El avance más atractivo en este campo, en nuestra opinión, lo constituye AWS Fargate. Aún son escasos los detalles sobre cómo va a funcionar exactamente, pero lo que sabemos hasta ahora es que Fargate es a los contenedores lo que Lambda era a las funciones. En vez de tener que retorcer o descomponer tus bases de código para trabajar dentro las restricciones de Lambda (lo que no siempre es malo, aunque puede serlo ¡si el único motivo por el que lo haces es para satisfacer el propio Lambda!), puedes desplegar un contenedor en Fargate y tenerlo gestionado externamente con un modelo de coste similar al de Lambda. ¿Por qué es esto tan interesante? A principios de 2018 presenciaremos como Fargate se ejecuta sobre Kubernetes en AWS EKS. La flexibilidad y escaso sobrecoste de las aplicaciones sin servidores, ejecutándose opcionalmente en un Cluster gestionado o auto-gestionado de Kubernetes, presumiblemente con todos los beneficios adicionales.
Concluyendo
Por si no lo has notado, estamos muy entusiasmados con Kubernetes. En el plazo de aproximadamente un año que llevamos ejecutando nuestro Cluster, hemos podido presenciar cómo se iba haciendo cada vez más fuerte, con nuevas versiones siendo liberadas frecuentemente que contienen mejoras significativas y nuevas y atractivas características, al tiempo que cada vez más y más vendedores lo están adoptando. Creemos que durante el próximo año, Kubernetes va a estar por todas partes, y comenzaremos a ver tecnología incluso más atractiva construida sobre él gracias a que todo el mundo va a tener capacidad extra al no tener que reinventar lo básico. Redes Mesh, Clusters multi-región, Clusters multi-Cloud, serverless reimaginado, es todo muy emocionante. Sigue atentamente este campo.Traducción al español realizada por: Rocío Sepúlveda y Jesús Cardenal Escribano
Aviso legal: Las declaraciones y opiniones expresadas en este artículo son las del autor/a o autores y no reflejan necesariamente las posiciones de Thoughtworks.