Nota. traducir: La adopción de Kubernetes en GitLab se considera uno de los dos factores principales que contribuyen al crecimiento de la empresa. Sin embargo, hasta hace poco, la infraestructura del servicio en línea GitLab.com se basaba en máquinas virtuales, y hace apenas un año comenzó su migración a K8, que aún no se ha completado. Nos complace presentar una traducción de un artículo reciente de un ingeniero de GitLab SRE sobre cómo sucede esto y qué conclusiones llegan a los ingenieros que participan en el proyecto.
Desde hace aproximadamente un año, nuestra división de infraestructura ha estado migrando todos los servicios que se ejecutan en GitLab.com a Kubernetes. Durante este tiempo, encontramos desafíos relacionados no solo con el traslado de servicios a Kubernetes, sino también con la gestión de la implementación híbrida durante la transición. Las valiosas lecciones que aprendimos se analizarán en este artículo.
Desde el comienzo de GitLab.com, sus servidores se ejecutaron en la nube en máquinas virtuales. Estas máquinas virtuales son administradas por Chef e instaladas usando nuestro . en caso de que sea necesario actualizar la aplicación, consiste simplemente en actualizar la flota de servidores de manera coordinada y secuencial mediante un canal de CI. Este método, aunque lento y un poco - garantiza que GitLab.com utilice las mismas prácticas de instalación y configuración que los usuarios sin conexión (autogestionado) Instalaciones de GitLab usando nuestros paquetes de Linux para esto.
Usamos este método porque es extremadamente importante experimentar todas las tristezas y alegrías que experimentan los miembros comunes de la comunidad al instalar y configurar sus copias de GitLab. Este enfoque funcionó bien durante algún tiempo, pero cuando la cantidad de proyectos en GitLab superó los 10 millones, nos dimos cuenta de que ya no satisfacía nuestras necesidades de escalamiento e implementación.
Primeros pasos hacia Kubernetes y GitLab nativo de la nube
El proyecto fue creado en 2017. preparar GitLab para la implementación en la nube y permitir a los usuarios instalar GitLab en clústeres de Kubernetes. Entonces sabíamos que trasladar GitLab a Kubernetes aumentaría la escalabilidad de la plataforma SaaS, simplificaría las implementaciones y mejoraría la eficiencia de los recursos informáticos. Al mismo tiempo, muchas de las funciones de nuestra aplicación dependían de particiones NFS montadas, lo que ralentizó la transición desde las máquinas virtuales.
El impulso hacia la nube nativa y Kubernetes permitió a nuestros ingenieros planificar una transición gradual, durante la cual abandonamos algunas de las dependencias de la aplicación en el almacenamiento de red mientras continuamos desarrollando nuevas funciones. Desde que comenzamos a planificar la migración en el verano de 2019, muchas de estas limitaciones se resolvieron y el proceso de migración de GitLab.com a Kubernetes ya está en marcha.
Características de GitLab.com en Kubernetes
Para GitLab.com, utilizamos un único clúster regional de GKE que maneja todo el tráfico de aplicaciones. Para minimizar la complejidad de la (ya complicada) migración, nos centramos en servicios que no dependen del almacenamiento local o NFS. GitLab.com utiliza una base de código Rails predominantemente monolítica y enrutamos el tráfico según las características de la carga de trabajo a diferentes puntos finales que están aislados en sus propios grupos de nodos.
En el caso del frontend, estos tipos se dividen en solicitudes a web, API, Git SSH/HTTPS y Registro. En el caso del backend, dividimos los trabajos en la cola según varias características dependiendo de , que nos permiten establecer objetivos de nivel de servicio (SLO) para diversas cargas de trabajo.
Todos estos servicios de GitLab.com se configuran utilizando un gráfico GitLab Helm sin modificar. La configuración se realiza en subgráficos, que se pueden habilitar de forma selectiva a medida que vayamos migrando servicios al cluster. Aunque decidimos no incluir algunos de nuestros servicios con estado en la migración, como Redis, Postgres, GitLab Pages y Gitaly, el uso de Kubernetes nos permite reducir radicalmente la cantidad de VM que Chef administra actualmente.
Visibilidad y gestión de la configuración de Kubernetes
Todas las configuraciones son administradas por el propio GitLab. Para ello se utilizan tres proyectos de configuración basados en Terraform y Helm. Intentamos utilizar GitLab siempre que sea posible para ejecutar GitLab, pero para tareas operativas tenemos una instalación de GitLab separada. Esto es necesario para garantizar que no dependa de la disponibilidad de GitLab.com al realizar implementaciones y actualizaciones de GitLab.com.
Aunque nuestras canalizaciones para el clúster de Kubernetes se ejecutan en una instalación de GitLab independiente, existen réplicas de los repositorios de código que están disponibles públicamente en las siguientes direcciones:
- — Marco de configuración de GitLab.com para el gráfico GitLab Helm;
- - Contiene configuraciones para servicios que no están asociados directamente con la aplicación GitLab. Estas incluyen configuraciones para registro y monitoreo de clústeres, así como herramientas integradas como PlantUML;
- — Configuración de Terraform para Kubernetes e infraestructura de VM heredada. Aquí configura todos los recursos necesarios para ejecutar el clúster, incluido el clúster en sí, los grupos de nodos, las cuentas de servicio y las reservas de direcciones IP.
La vista pública se muestra cuando se realizan cambios. con un enlace a la diferencia detallada que SRE analiza antes de realizar cambios en el clúster.
Para SRE, el enlace conduce a una diferencia detallada en la instalación de GitLab, que se utiliza para la producción y cuyo acceso es limitado. Esto permite a los empleados y a la comunidad, sin acceso al proyecto operativo (que solo está abierto para SRE), ver los cambios de configuración propuestos. Al combinar una instancia pública de GitLab para código con una instancia privada para canalizaciones de CI, mantenemos un flujo de trabajo único y al mismo tiempo garantizamos la independencia de GitLab.com para las actualizaciones de configuración.
Lo que descubrimos durante la migración
Durante la mudanza se adquirió experiencia que aplicamos a nuevas migraciones y despliegues en Kubernetes.
1. Aumento de costos debido al tráfico entre zonas de disponibilidad
Estadísticas de salida diaria (bytes por día) para la flota de repositorios Git en GitLab.com
Google divide su red en regiones. Éstas, a su vez, se dividen en zonas de accesibilidad (AZ). El alojamiento Git está asociado con grandes cantidades de datos, por lo que es importante para nosotros controlar la salida de la red. Para el tráfico interno, la salida solo es gratuita si permanece dentro de la misma zona de disponibilidad. Al momento de escribir este artículo, estamos entregando aproximadamente 100 TB de datos en un día laboral típico (y eso es solo para los repositorios de Git). Los servicios que residían en las mismas máquinas virtuales en nuestra antigua topología basada en VM ahora se ejecutan en diferentes pods de Kubernetes. Esto significa que parte del tráfico que anteriormente era local para la máquina virtual podría potencialmente viajar fuera de las zonas de disponibilidad.
Los clústeres regionales de GKE te permiten abarcar varias zonas de disponibilidad para lograr redundancia. Estamos considerando la posibilidad para servicios que generan grandes volúmenes de tráfico. Esto reducirá los costos de salida y al mismo tiempo mantendrá la redundancia a nivel de clúster.
2. Límites, solicitudes de recursos y escalamiento
La cantidad de réplicas que procesan el tráfico de producción en registro.gitlab.com. El tráfico alcanza su punto máximo a las 15:00 UTC.
Nuestra historia de migración comenzó en agosto de 2019, cuando migramos nuestro primer servicio, GitLab Container Registry, a Kubernetes. Este servicio de misión crítica y alto tráfico fue una buena opción para la primera migración porque es una aplicación sin estado con pocas dependencias externas. El primer problema que encontramos fue una gran cantidad de pods desalojados debido a la falta de memoria en los nodos. Debido a esto, tuvimos que cambiar las solicitudes y los límites.
Se descubrió que en el caso de una aplicación donde el consumo de memoria aumenta con el tiempo, los valores bajos para las solicitudes (reservar memoria para cada pod) junto con un límite estricto "generoso" de uso conducían a la saturación. (saturación) nodos y un alto nivel de desalojos. Para hacer frente a este problema, fue . Esto quitó presión a los nodos y aseguró que las cápsulas tuvieran un ciclo de vida que no ejerciera demasiada presión sobre el nodo. Ahora comenzamos las migraciones con valores límite y de solicitud generosos (y casi idénticos), ajustándolos según sea necesario.
3. Métricas y registros
La división de infraestructura se centra en la latencia, las tasas de error y la saturación de instalaciones instaladas. (SLO) vinculado a .
Durante el año pasado, uno de los eventos clave en la división de infraestructura fueron las mejoras en el monitoreo y el trabajo con los SLO. Los SLO nos permitieron establecer objetivos para servicios individuales que monitoreamos de cerca durante la migración. Pero incluso con esta observabilidad mejorada, no siempre es posible ver los problemas de inmediato mediante métricas y alertas. Por ejemplo, al centrarnos en la latencia y las tasas de error, no cubrimos completamente todos los casos de uso de un servicio en proceso de migración.
Este problema se descubrió casi inmediatamente después de migrar algunas cargas de trabajo al clúster. Se volvió especialmente grave cuando tuvimos que verificar funciones para las cuales el número de solicitudes era pequeño, pero que tenían dependencias de configuración muy específicas. Una de las lecciones clave de la migración fue la necesidad de tener en cuenta no sólo las métricas al monitorear, sino también los registros y la "cola larga". (esto es sobre en el gráfico - aprox. trad.) errores. Ahora, para cada migración incluimos una lista detallada de consultas de registro. (consultas de registro) y planificar procedimientos de reversión claros que puedan transferirse de un turno al siguiente si surgen problemas.
Atender las mismas solicitudes en paralelo en la antigua infraestructura de VM y en la nueva infraestructura basada en Kubernetes presentó un desafío único. A diferencia de la migración de elevación y cambio (transferencia rápida de aplicaciones "tal cual" a una nueva infraestructura; se pueden leer más detalles, por ejemplo, - aprox. trad.), el trabajo paralelo en máquinas virtuales "antiguas" y Kubernetes requiere que las herramientas de monitoreo sean compatibles con ambos entornos y puedan combinar métricas en una sola vista. Es importante que utilicemos los mismos paneles y consultas de registros para lograr una observabilidad consistente durante el período de transición.
4. Cambiar el tráfico a un nuevo clúster
Para GitLab.com, parte de los servidores está dedicado a . Canary Park sirve a nuestros proyectos internos y también puede . Pero está diseñado principalmente para probar los cambios realizados en la infraestructura y la aplicación. El primer servicio migrado comenzó aceptando una cantidad limitada de tráfico interno y continuamos usando este método para garantizar que se cumplan los SLO antes de enviar todo el tráfico al clúster.
En el caso de la migración, esto significa que las solicitudes a proyectos internos se envían primero a Kubernetes y luego cambiamos gradualmente el resto del tráfico al clúster cambiando el peso del backend a través de HAProxy. Durante la migración de VM a Kubernetes, quedó claro que era muy beneficioso tener una manera fácil de redirigir el tráfico entre la infraestructura antigua y la nueva y, en consecuencia, mantener la infraestructura antigua lista para la reversión en los primeros días después de la migración.
5. Capacidades de reserva de vainas y su uso.
Casi de inmediato se identificó el siguiente problema: los pods para el servicio de Registro se iniciaron rápidamente, pero el lanzamiento de los pods para Sidekiq tomó hasta . El largo tiempo de inicio de los pods Sidekiq se convirtió en un problema cuando comenzamos a migrar cargas de trabajo a Kubernetes para los trabajadores que necesitaban procesar trabajos y escalar rápidamente.
En este caso, la lección fue que si bien el escalador automático de pods horizontal (HPA) de Kubernetes maneja bien el crecimiento del tráfico, es importante considerar las características de las cargas de trabajo y asignar capacidad adicional a los pods (especialmente cuando la demanda está distribuida de manera desigual). En nuestro caso, hubo un aumento repentino en los trabajos, lo que llevó a un rápido escalamiento, lo que llevó a la saturación de los recursos de la CPU antes de que tuviéramos tiempo de escalar el grupo de nodos.
Siempre existe la tentación de exprimir todo lo posible de un clúster; sin embargo, después de haber encontrado problemas de rendimiento inicialmente, ahora estamos comenzando con un presupuesto de módulo generoso y reduciéndolo más adelante, manteniendo una estrecha vigilancia sobre los SLO. El lanzamiento de módulos para el servicio Sidekiq se ha acelerado significativamente y ahora tarda unos 40 segundos en promedio. Ganaron tanto GitLab.com como nuestros usuarios de instalaciones autoadministradas que trabajan con el gráfico oficial de GitLab Helm.
Conclusión
Después de migrar cada servicio, nos regocijamos con los beneficios de usar Kubernetes en producción: implementación de aplicaciones, escalamiento y asignación de recursos más eficientes y más rápidos. Además, las ventajas de la migración van más allá del servicio GitLab.com. Cada mejora en el gráfico oficial de Helm beneficia a sus usuarios.
Espero que hayas disfrutado la historia de nuestras aventuras de migración a Kubernetes. Continuamos migrando todos los servicios nuevos al clúster. Puede encontrar información adicional en las siguientes publicaciones:
- «";
- «";
- .
PD del traductor
Lea también en nuestro blog:
- «";
- «";
- «";
- «".
Fuente: habr.com