Los clientes de InfluxDB Cloud ejecutan una variedad de aplicaciones en nuestra plataforma de desarrollo, desde aplicaciones de IoT hasta aplicaciones financieras, infraestructura y monitoreo de servidores. Este tipo de aplicaciones generan cantidades importantes de datos. Sin embargo, los datos tienen «gravedad», lo que significa que mover terabytes a través de Internet o incluso entre regiones dentro del mismo proveedor de nube puede resultar prohibitivo en términos de costo y tiempo. Ambos pueden convertirse en factores dolorosos al mover datos a estas aplicaciones. Por esta razón, es importante que nuestros clientes tengan InfluxDB Cloud disponible en la región y el proveedor de servicios en la nube de su elección.
Elegimos implementar InfluxDB Cloud como un gobernadores aplicación para que podamos satisfacer las necesidades de múltiples nubes y regiones de nuestros clientes. Kubernetes nos proporciona una capa de abstracción en la nube que nos permite (más o menos) escribir una sola aplicación para que se ejecute en cualquier lugar.
Aunque potente, Kubernetes es una tecnología relativamente nueva. Encontramos un éxito increíble, pero requirió mucho esfuerzo. Aquí hay cuatro cosas que quería saber sobre Kubernetes cuando comenzamos.
1. Las aplicaciones nativas de la nube y los binarios son universos aparte.
Las diferencias técnicas entre escribir un solo servidor binario o una pila de servidores binarios únicos interrelacionados y una aplicación de Kubernetes son obvias en la superficie. La transición de la mentalidad de un equipo de ingenieros entre estos universos es un trabajo que debe considerarse en estos esfuerzos.
Por ejemplo, es común agrupar tantos procesos como sea posible en su único servidor binario. Este es el enfoque opuesto al universo de Kubernetes, donde coloca cada proceso en contenedores en su propio contenedor y ejecuta ejércitos de pods que pueden escalar dinámicamente para cumplir con las cargas de trabajo.
Asimismo, en un entorno de software de código abierto (OSS) (InfluxDB también tiene una versión de código abierto), los procesos pueden compartir memoria o espacio en disco. Sin embargo, una vez que cambie a una aplicación nativa de la nube, es posible que sus procesos ni siquiera residan en el mismo nodo que Kubernetes. Es poco probable que sus procesos de Kubernetes puedan intercambiar memoria o soltar archivos para leerse entre sí.
Al mantener un solo servidor binario, los desarrolladores escriben código para mantener el servidor funcionando a toda costa; por ejemplo, código para recuperarse de errores inesperados, restablecer el estado y continuar sirviendo. En Kubernetes, hacemos lo contrario. Si encontramos errores inesperados, nuestro código informa que el pod no está en buen estado y permite que Kubernetes reinicie el pod en un estado limpio, con suerte después de un apagado normal, lo que significa que completa cualquier trabajo que pueda antes de que se limpie.
En general, descubrimos que la diferencia entre el código OSS y el código en la nube era tan significativa que ya no tenía sentido mantener una base de código común. Usamos algunas herramientas de CI para asegurarnos de que las API entre nuestras versiones de OSS y Cloud no diverjan, pero cuando dejamos de intentar mantener una base de código común, la velocidad de ambos proyectos mejoró visiblemente.
2. Hay más métricas de las que jamás podrá manejar.
Con Kubernetes, el problema de la observabilidad no es la falta de métricas; el dilema es encontrar una manera de ubicar una señal en todo el ruido.
Tomamos muchas iteraciones de recopilación de datos, procesamiento de datos y paneles para crear un conjunto de RED, USE, SLO y otros paneles y métricas que nos ayudaron a comprender el estado de los servicios de producción que ofrecíamos. Recomendaría encarecidamente dedicar mucho tiempo a iterar a través de la recopilación de métricas, alertas, paneles y SLI / SLO. Este no es un proyecto paralelo, sino un elemento central para administrar múltiples clústeres de Kubernetes.
3. Configure la monitorización sintética.
A pesar de, o quizás debido a, la gran cantidad de datos operativos que fluyen desde nuestros clústeres de producción de Kubernetes, puede ser difícil inferir la calidad de la experiencia del usuario que brinda su aplicación, especialmente en las primeras etapas de producción. Nuestra solución a esto fue aumentar nuestros esfuerzos de monitoreo mediante la implementación de «monitoreo sintético». Como plataforma de desarrollo, la calidad de la experiencia del usuario tiene que ver con el rendimiento y la confiabilidad de la API. El monitoreo sintético implica ejecutar una aplicación externamente que ejercita la API de manera similar a cómo los usuarios interactúan con la aplicación.
Originalmente, nuestro monitoreo sintético hizo un mejor trabajo al proporcionar comentarios críticos que nuestro monitoreo basado en métricas, lo que significaba que teníamos trabajo que hacer para mejorar nuestro monitoreo y alertas. Después de un tiempo, nuestro monitoreo basado en métricas superó nuestro monitoreo sintético en términos de alertarnos sobre posibles problemas en la producción y, por supuesto, permitiéndonos diagnosticar y solucionar problemas, lo que el monitoreo sintético no puede hacer.
Nuestro monitoreo sintético vive como un complemento a nuestro monitoreo basado en métricas, proporcionando una visión objetiva de la calidad del servicio que brindamos a los clientes. Esto es especialmente útil durante incidentes.
4. La entrega continua a través de múltiples nubes es difícil.
Como desarrolladores, nuestros usuarios son muy exigentes con la disponibilidad. Uno de los principales problemas que tuvimos inicialmente fue que, durante las implementaciones, Kubernetes cerraba inesperadamente algunos servicios y devolvía un error 500 o 503. Estos errores terminarían como llamadas API fallidas para nuestros usuarios. Tener una base de datos en el centro de nuestra oferta significa que no podemos simplemente intentarlo de nuevo en caso de errores del servidor, ya que no tenemos una forma de saber si hay posibles efectos secundarios en la consulta que el cliente está ejecutando.
Cuando realiza una implementación continua, significa que los clientes experimentan continuamente esta interrupción. Fue un esfuerzo significativo escribir código para toda la plataforma para crear implementaciones súper fluidas que minimizan las interrupciones durante las implementaciones.
Además, los proveedores de servicios en la nube no ofrecen entornos, características y servicios uniformes. Por lo tanto, debe encontrar una forma de administrar estas diferencias en sus implementaciones de manera sostenible.
Elegimos una combinación de jsonnet y Argo para solucionar este problema. Jsonnet impone un nivel adicional de complejidad, pero ha resultado ser una herramienta crítica para administrar implementaciones de múltiples nubes.
poniendo todo junto
Kubernetes nos ayudó a escalar nuestra plataforma de una manera que ninguna otra tecnología disponible en la actualidad puede hacerlo. Nuestros clientes pueden utilizar la plataforma de forma totalmente elástica y de pago por uso. Pueden ejecutar la base de datos y calcular los recursos lo más cerca posible de donde están generando sus datos y esto les ayuda a administrar la gravedad de sus datos.
Kubernetes nos permite transformar servicios hasta cinco veces más rápido de lo que podríamos con nuestra solución OSS. Hemos demostrado que puede usar Kubernetes como una capa de abstracción de nube escalada, pero requiere esfuerzo y hubo algunos puntos débiles en el camino. Con suerte, puede utilizar nuestro aprendizaje mientras se embarca en su propio viaje en Kubernetes.
Para saber más sobre temas nativos de la nube, únase al Base de computación nativa en la nube y la comunidad nativa de la nube en KubeCon + CloudNativeCon North America 2021 – 11-15 de octubre de 2021
Relacionado
