Nota. transl.: A adopción de Kubernetes en GitLab considérase un dos dous principais factores que contribúen ao crecemento da empresa. Non obstante, ata hai pouco, a infraestrutura do servizo en liña GitLab.com construíuse en máquinas virtuais, e hai só un ano comezou a súa migración a K8s, que aínda non está rematada. Temos o pracer de presentar a tradución dun artigo recente dun enxeñeiro SRE de GitLab sobre como ocorre isto e que conclusións sacan os enxeñeiros que participan no proxecto.
Desde hai aproximadamente un ano, a nosa división de infraestrutura estivo migrando todos os servizos que se executan en GitLab.com a Kubernetes. Durante este tempo, atopamos desafíos relacionados non só co traslado de servizos a Kubernetes, senón tamén coa xestión da implantación híbrida durante a transición. As valiosas leccións que aprendemos serán discutidas neste artigo.
Desde o inicio de GitLab.com, os seus servidores funcionaban na nube en máquinas virtuais. Estas máquinas virtuais son xestionadas por Chef e instaladas mediante o noso . no caso de que a aplicación necesite actualizarse, consiste simplemente en actualizar a flota de servidores de forma coordinada e secuencial mediante unha canalización de CI. Este método - aínda que lento e un pouco - garante que GitLab.com utilice as mesmas prácticas de instalación e configuración que os usuarios sen conexión (autoxestionado) Instalacións de GitLab usando os nosos paquetes de Linux para iso.
Usamos este método porque é moi importante experimentar todas as penas e alegrías que experimentan os membros comúns da comunidade ao instalar e configurar as súas copias de GitLab. Este enfoque funcionou ben durante algún tempo, pero cando o número de proxectos en GitLab superou os 10 millóns, decatámonos de que xa non cumpría as nosas necesidades de escalado e implantación.
Primeiros pasos para Kubernetes e GitLab nativo na nube
O proxecto foi creado en 2017 para preparar GitLab para a implantación na nube e para permitir aos usuarios instalar GitLab en clústeres de Kubernetes. Entón sabiamos que mover GitLab a Kubernetes aumentaría a escalabilidade da plataforma SaaS, simplificaría as implantacións e melloraría a eficiencia dos recursos informáticos. Ao mesmo tempo, moitas das funcións da nosa aplicación dependían de particións NFS montadas, o que retardaba a transición das máquinas virtuais.
O impulso cara á nube nativa e Kubernetes permitiu aos nosos enxeñeiros planificar unha transición gradual, durante a cal abandonamos algunhas das dependencias da aplicación do almacenamento en rede mentres continuamos desenvolvendo novas funcións. Desde que comezamos a planificar a migración no verán de 2019, moitas destas limitacións foron resoltas e o proceso de migración de GitLab.com a Kubernetes xa está en marcha.
Características de GitLab.com en Kubernetes
Para GitLab.com, usamos un único clúster rexional de GKE que xestiona todo o tráfico de aplicacións. Para minimizar a complexidade da migración (xa complicada), centrámonos nos servizos que non dependen do almacenamento local nin de NFS. GitLab.com usa unha base de código de Rails predominantemente monolítica e encamiñamos o tráfico en función das características da carga de traballo a diferentes puntos finais que están illados nos seus propios grupos de nodos.
No caso do frontend, estes tipos divídense en solicitudes a web, API, Git SSH/HTTPS e Rexistro. No caso do backend, dividimos os traballos na cola segundo varias características dependendo de , que nos permiten establecer obxectivos de nivel de servizo (SLO) para varias cargas de traballo.
Todos estes servizos de GitLab.com están configurados mediante un gráfico GitLab Helm sen modificar. A configuración realízase en subgráficos, que poden activarse de forma selectiva a medida que imos migrando os servizos ao clúster aos poucos. Aínda que decidimos non incluír algúns dos nosos servizos con estado na migración, como Redis, Postgres, GitLab Pages e Gitaly, o uso de Kubernetes permítenos reducir radicalmente o número de máquinas virtuales que Chef xestiona actualmente.
Visibilidade e xestión da configuración de Kubernetes
Todas as configuracións son xestionadas polo propio GitLab. Para iso utilízanse tres proxectos de configuración baseados en Terraform e Helm. Tentamos usar o propio GitLab sempre que sexa posible para executar GitLab, pero para tarefas operativas temos unha instalación separada de GitLab. Isto é necesario para garantir que non dependes da dispoñibilidade de GitLab.com cando realizas implementacións e actualizacións de GitLab.com.
Aínda que as nosas canalizacións para o clúster de Kubernetes execútanse nunha instalación GitLab separada, hai réplicas dos repositorios de código que están dispoñibles publicamente nos seguintes enderezos:
- — Marco de configuración de GitLab.com para o gráfico GitLab Helm;
- - Contén configuracións para servizos que non están directamente asociados coa aplicación GitLab. Estes inclúen configuracións para o rexistro e monitorización de clústeres, así como ferramentas integradas como PlantUML;
- — Configuración de Terraform para Kubernetes e infraestrutura de VM heredada. Aquí configura todos os recursos necesarios para executar o clúster, incluído o propio clúster, as agrupacións de nodos, as contas de servizo e as reservas de enderezos IP.
A vista pública móstrase cando se fan cambios. cunha ligazón á diferenza detallada que SRE analiza antes de facer cambios no clúster.
Para SRE, a ligazón leva a unha diferenza detallada na instalación de GitLab, que se usa para a produción e o acceso está restrinxido. Isto permite que os empregados e a comunidade, sen acceso ao proxecto operativo (que só está aberto a SRE), poidan ver os cambios de configuración propostos. Ao combinar unha instancia pública de GitLab para código cunha instancia privada para canalizacións de CI, mantemos un único fluxo de traballo ao tempo que garantimos a independencia de GitLab.com para as actualizacións de configuración.
O que descubrimos durante a migración
Durante o traslado, adquiriu experiencia que aplicamos a novas migracións e implantacións en Kubernetes.
1. Aumento dos custos debido ao tráfico entre zonas de dispoñibilidade
Estatísticas de saída diarias (bytes por día) para a flota de repositorios de Git en GitLab.com
Google divide a súa rede en rexións. Estes, á súa vez, divídense en zonas de accesibilidade (AZ). O aloxamento de Git está asociado a grandes cantidades de datos, polo que é importante para nós controlar a saída da rede. Para o tráfico interno, a saída só é gratuíta se permanece dentro da mesma zona de dispoñibilidade. Ata o momento de escribir este artigo, estamos a ofrecer aproximadamente 100 TB de datos nun día de traballo típico (e iso é só para os repositorios de Git). Os servizos que residían nas mesmas máquinas virtuais da nosa antiga topoloxía baseada en VM agora execútanse en diferentes pods de Kubernetes. Isto significa que parte do tráfico que antes era local da máquina virtual podería viaxar fóra das zonas de dispoñibilidade.
Os clústeres rexionais de GKE permítenche abarcar varias zonas de dispoñibilidade para a súa redundancia. Estamos considerando a posibilidade para servizos que xeran grandes volumes de tráfico. Isto reducirá os custos de saída mantendo a redundancia a nivel de clúster.
2. Límites, solicitudes de recursos e escalado
O número de réplicas que procesan o tráfico de produción en registry.gitlab.com. O tráfico alcanza o máximo ás ~15:00 UTC.
A nosa historia de migración comezou en agosto de 2019, cando migramos o noso primeiro servizo, o GitLab Container Registry, a Kubernetes. Este servizo de misión crítica e de alto tráfico foi unha boa opción para a primeira migración porque é unha aplicación sen estado con poucas dependencias externas. O primeiro problema que atopamos foi un gran número de vainas desaloxadas debido á falta de memoria nos nodos. Por iso, tivemos que cambiar as solicitudes e os límites.
Descubriuse que no caso dunha aplicación onde o consumo de memoria aumenta co paso do tempo, os valores baixos das solicitudes (reservando memoria para cada pod) unidos a un límite de uso "xeneroso" provocaban a saturación. (saturación) nodos e un alto nivel de desafiuzamentos. Para facer fronte a este problema, foi . Isto quitou a presión dos nodos e garantiu que as vainas tivesen un ciclo de vida que non tivese demasiada presión sobre o nodo. Agora comezamos as migracións con valores de solicitude e límite xenerosos (e case idénticos), axustándoos segundo sexa necesario.
3. Métricas e rexistros
A división de infraestrutura céntrase na latencia, as taxas de erro e a saturación con instalacións (SLO) vinculado a .
Durante o ano pasado, un dos eventos clave na división de infraestruturas foron as melloras no seguimento e no traballo con SLO. Os SLO permitíronnos establecer obxectivos para servizos individuais que supervisamos de preto durante a migración. Pero aínda con esta observabilidade mellorada, non sempre é posible ver inmediatamente problemas usando métricas e alertas. Por exemplo, ao centrarnos na latencia e nas taxas de erro, non cubrimos por completo todos os casos de uso dun servizo en proceso de migración.
Este problema descubriuse case inmediatamente despois de migrar algunhas cargas de traballo ao clúster. Fíxose especialmente agudo cando tiñamos que comprobar funcións para as que o número de solicitudes era pequeno, pero que tiñan dependencias de configuración moi específicas. Unha das leccións fundamentais da migración foi a necesidade de ter en conta non só as métricas ao monitorizar, senón tamén os rexistros e a "cola longa" (isto é sobre no gráfico - aprox. trad.) erros. Agora, para cada migración, incluímos unha lista detallada de consultas de rexistro (consultas de rexistro) e planificar procedementos de retroceso claros que se poidan transferir dunha quenda a outra se xorden problemas.
Atender as mesmas solicitudes en paralelo na antiga infraestrutura de VM e na nova infraestrutura baseada en Kubernetes presentaba un desafío único. A diferenza da migración lift-and-shift (transferencia rápida das aplicacións "tal cual" a unha nova infraestrutura; pódense ler máis detalles, por exemplo, - aprox. transl.), o traballo paralelo en máquinas virtuales "vellas" e Kubernetes require que as ferramentas de monitorización sexan compatibles con ambos os ambientes e poidan combinar métricas nunha soa vista. É importante que usemos os mesmos paneis e consultas de rexistro para lograr unha observabilidade consistente durante o período de transición.
4. Cambiando o tráfico a un novo clúster
Para GitLab.com, parte dos servidores está dedicado . Canary Park serve aos nosos proxectos internos e tamén pode . Pero está deseñado principalmente para probar os cambios realizados na infraestrutura e na aplicación. O primeiro servizo migrado comezou aceptando unha cantidade limitada de tráfico interno e seguimos usando este método para asegurarnos de que se cumpran os SLO antes de enviar todo o tráfico ao clúster.
No caso da migración, isto significa que as solicitudes de proxectos internos envíanse primeiro a Kubernetes e despois cambiamos gradualmente o resto do tráfico ao clúster cambiando o peso do backend a través de HAProxy. Durante a migración de VM a Kubernetes, quedou claro que era moi beneficioso ter un xeito sinxelo de redirixir o tráfico entre a antiga e a nova infraestrutura e, en consecuencia, manter a antiga infraestrutura preparada para a súa restauración nos primeiros días despois da migración.
5. Capacidades de reserva das vainas e o seu uso
Case inmediatamente identificouse o seguinte problema: os pods para o servizo de rexistro comezaron rapidamente, pero o lanzamento de pods para Sidekiq levou . O longo tempo de execución dos pods Sidekiq converteuse nun problema cando comezamos a migrar cargas de traballo a Kubernetes para os traballadores que necesitaban procesar traballos rapidamente e escalar rapidamente.
Neste caso, a lección foi que, aínda que o Horizontal Pod Autoscaler (HPA) de Kubernetes manexa ben o crecemento do tráfico, é importante ter en conta as características das cargas de traballo e asignar capacidade sobrante aos pods (especialmente cando a demanda está distribuída de forma desigual). No noso caso, houbo un repentino aumento dos traballos, que levou a un rápido escalado, o que provocou a saturación dos recursos da CPU antes de ter tempo para escalar o grupo de nodos.
Sempre existe a tentación de espremer o máximo posible dun clúster, pero tendo atopado inicialmente problemas de rendemento, agora comezamos cun orzamento de pod xeneroso e reducilo máis tarde, vixiando de preto os SLO. O lanzamento de pods para o servizo Sidekiq acelerouse significativamente e agora leva uns 40 segundos de media. gañou tanto GitLab.com como os nosos usuarios de instalacións autoxestionadas que traballan co gráfico oficial de GitLab Helm.
Conclusión
Despois de migrar cada servizo, alegrámonos dos beneficios de usar Kubernetes na produción: implementación de aplicacións máis rápida e segura, escalado e asignación de recursos máis eficiente. Ademais, as vantaxes da migración van máis aló do servizo GitLab.com. Cada mellora do gráfico oficial de Helm beneficia aos seus usuarios.
Espero que vos gustase a historia das nosas aventuras de migración de Kubernetes. Seguimos migrando todos os novos servizos ao clúster. Pódese atopar información adicional nas seguintes publicacións:
- «»;
- «»;
- .
PS do tradutor
Lea tamén no noso blog:
- «»;
- «»;
- «»;
- «».
Fonte: www.habr.com