4 cosas de nivel experto que desearía saber sobre Kubernetes

Los clientes de InfluxDB Cloud ejecutan una variedad de aplicaciones en nuestra plataforma de desarrollo, desde aplicaciones de IoT y aplicaciones financieras hasta monitoreo de infraestructura y 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 caro y llevar mucho tiempo. Ambos pueden convertirse en factores dolorosos al mover datos para estas aplicaciones. Por este motivo, es importante que nuestros clientes dispongan de InfluxDB Cloud disponible en su región y el proveedor de servicios en la nube de su elección.

Hemos optado por implementar InfluxDB Cloud como Gobernadores con el fin de permitirnos satisfacer las necesidades multinube y multirregión 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. Hemos tenido un éxito increíble, pero nos ha costado un poco de esfuerzo. Aquí hay cuatro cosas que desearía haber sabido sobre Kubernetes cuando comenzamos.

1. Las aplicaciones nativas de la nube y los binarios son mundos aparte.

Las diferencias técnicas entre escribir un solo servidor binario o una pila de servidores binarios únicos interdependientes y una aplicación de Kubernetes son obvias a primera vista. La transición de la mentalidad de un equipo de ingenieros entre estos universos es un trabajo que debe tenerse en cuenta en tales esfuerzos.

Por ejemplo, es común consolidar tantos procesos como sea posible en su único servidor binario. Este es el enfoque opuesto al del universo de Kubernetes, donde se coloca en contenedores cada proceso en su propio contenedor y se ejecutan ejércitos de pods que pueden escalar dinámicamente para servir 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 de Kubernetes. Es poco probable que sus procesos de Kubernetes puedan intercambiar memoria o soltar archivos para que todos los lean.

Al mantener un solo servidor binario, los desarrolladores escriben código para que el servidor funcione a cualquier costo; por ejemplo, código para recuperarse de errores inesperados, restablecer el estado y continuar sirviendo. En Kubernetes, hacemos lo contrario. Si encontramos algún error inesperado, 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 limpio, lo que significa que completa cualquier trabajo posible de antemano para ser limpiado.

En general, descubrimos que la diferencia entre el código OSS y el código en la nube era tan grande que ya no tenía sentido mantener una base de código común. Usamos herramientas de CI para asegurarnos de que las API entre nuestras versiones de OSS y Cloud no diverjan, pero desde que dejamos de intentar mantener una base de código común, la velocidad de ambos proyectos ha mejorado notablemente.

2. Hay más métricas de las que puede manejar.

Con Kubernetes, el problema con la observabilidad no es la falta de métricas: el dilema es encontrar una manera de localizar una señal en todo el ruido.

Nos tomó muchas iteraciones de recopilación de datos, procesamiento de datos y tableros para aterrizar en un conjunto de RED, USE, SLO y otros tableros y métricas que nos ayudaron a comprender el estado del mundo de los servicios de producción que ofrecíamos. Recomendaría encarecidamente permitir suficiente tiempo para iterar sobre la recopilación de métricas, alertas, paneles y SLI / SLO. Este no es un proyecto paralelo, sino una parte central de la administración de múltiples clústeres de Kubernetes.

3. Configure la vigilancia sintética.

A pesar de la gran cantidad de datos operativos que provienen de nuestros clústeres de producción de Kubernetes, o tal vez debido a ellos, puede resultar difícil inferir la calidad de la experiencia del usuario proporcionada por su aplicación, especialmente al principio de la producción. Nuestra solución para esto fue aumentar nuestros esfuerzos de vigilancia mediante la implementación de una «vigilancia sintética». Como plataforma de desarrollo, la calidad de la experiencia del usuario depende del rendimiento y la confiabilidad de la API. El monitoreo sintético implica ejecutar una aplicación externamente que ejercita la API de una manera similar a cómo los usuarios interactúan con la aplicación.

Originalmente, nuestro monitoreo sintético nos proporcionó una mejor retroalimentación crítica 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 fue más allá de nuestro monitoreo sintético al alertarnos sobre posibles problemas de producción y, por supuesto, permitiéndonos diagnosticar y resolver problemas, lo que el monitoreo sintético no puede hacer.

Nuestro monitoreo sintético continúa complementando nuestro monitoreo basado en métricas al brindar una visión objetiva de la calidad del servicio que brindamos a los clientes. Esto es particularmente útil durante incidentes.

4. La entrega continua en múltiples nubes es difícil.

Como desarrolladores, nuestros usuarios son muy exigentes en cuanto a disponibilidad. Uno de los principales problemas que encontramos inicialmente fue que durante las implementaciones, Kubernetes cerró inesperadamente algunos servicios y devolvió un error 500 o 503. Estos errores terminarían en llamadas API fallidas para nuestros usuarios. Tener una base de datos en el corazón de nuestra oferta significa que no podemos simplemente volver a intentar los errores del servidor, ya que no tenemos forma de saber si hay algún efecto secundario potencial con respecto a la consulta que está realizando el cliente.

Cuando realiza una implementación continua, significa que los clientes experimentan continuamente esta interrupción. Fue un esfuerzo significativo escribir código en 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, capacidades y servicios uniformes. Por lo tanto, necesita encontrar una manera de administrar estas diferencias en sus implementaciones de una manera sostenible.

Hemos elegido una combinación de Jsonnet y Argo para solucionar este problema. Jsonnet impone un nivel adicional de complejidad, pero ha demostrado ser una herramienta esencial para administrar implementaciones de múltiples nubes.

Ponlo todo junto

Kubernetes nos ha ayudado a hacer evolucionar 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 pagada. Pueden ejecutar la base de datos y calcular los recursos lo más cerca posible de donde generan sus datos, lo que les ayuda a administrar la gravedad de sus datos.

Kubernetes nos permite transformar servicios hasta cinco veces más rápido que con nuestra solución OSS. Hemos demostrado que puede usar Kubernetes como una capa de abstracción de la nube a gran escala, pero requirió un poco de esfuerzo y hubo algunos problemas en el camino. Espero que pueda utilizar nuestros aprendizajes mientras se embarca en su propio viaje por Kubernetes.

Para obtener más información sobre los temas nativos de la nube, únase al Base de computación nativa en la nube y la comunidad nativa en la nube de KubeCon + CloudNativeCon North America 2021 – 11-15 de octubre de 2021

Relacionado