{"id":94977,"date":"2020-09-24T07:43:00","date_gmt":"2020-09-24T05:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes"},"modified":"2020-09-24T07:43:00","modified_gmt":"2020-09-24T05:43:00","slug":"nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","title":{"rendered":"Nossas conclus\u00f5es ap\u00f3s um ano de migra\u00e7\u00e3o do GitLab.com para Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Nota do tradutor.<\/b>: a adapta\u00e7\u00e3o do Kubernetes no GitLab \u00e9 considerada um dos dois principais fatores que impulsionam o crescimento da empresa. No entanto, at\u00e9 recentemente, a infraestrutura do servi\u00e7o online GitLab.com estava baseada em m\u00e1quinas virtuais, e a migra\u00e7\u00e3o para K8s come\u00e7ou apenas h\u00e1 cerca de um ano, estando ainda em andamento. Temos o prazer de apresentar a tradu\u00e7\u00e3o de um artigo recente de um engenheiro SRE do GitLab sobre como isso est\u00e1 acontecendo e quais conclus\u00f5es est\u00e3o sendo feitas pelos engenheiros envolvidos no projeto.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Nossas conclus\u00f5es ap\u00f3s um ano de migra\u00e7\u00e3o do GitLab.com para Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/58429abf60cd19a49c5ce593051c2fca.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nH\u00e1 cerca de um ano, o nosso departamento de infraestrutura tem trabalhado na migra\u00e7\u00e3o de todos os servi\u00e7os operando no GitLab.com para Kubernetes. Durante esse per\u00edodo, enfrentamos problemas relacionados n\u00e3o apenas \u00e0 transfer\u00eancia dos servi\u00e7os para Kubernetes, mas tamb\u00e9m \u00e0 gest\u00e3o do deployment h\u00edbrido durante a transi\u00e7\u00e3o. Este artigo abordar\u00e1 as valiosas li\u00e7\u00f5es que aprendemos.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Desde o in\u00edcio, o GitLab.com operava em nuvem em m\u00e1quinas virtuais. Essas m\u00e1quinas virtuais s\u00e3o gerenciadas pelo Chef, e sua instala\u00e7\u00e3o \u00e9 feita atrav\u00e9s do nosso <noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/install\/#ubuntu\">pacote oficial do Linux<\/a><\/noindex>. <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-org\/release\/docs\/-\/blob\/master\/general\/deploy\/gitlab-com-deployer.md\">Estrat\u00e9gia de Deployment<\/a><\/noindex> para o caso de ser necess\u00e1rio atualizar o aplicativo, consiste na simples atualiza\u00e7\u00e3o do parque de servidores de forma coordenada e sequencial atrav\u00e9s de um pipeline CI. Este m\u00e9todo \u2014 embora lento e um pouco <noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/handbook\/values\/#boring-solutions\">tedioso<\/a><\/noindex> \u2014 garante que o GitLab.com utiliza os mesmos m\u00e9todos de instala\u00e7\u00e3o e configura\u00e7\u00e3o que os usu\u00e1rios das inst\u00e2ncias <i>(self-managed)<\/i> do GitLab, que utilizam nossos pacotes do Linux para isso.<\/p>\n<p>Utilizamos este m\u00e9todo porque \u00e9 extremamente importante sentir todas as dificuldades e alegrias que os membros da comunidade experimentam ao instalar e configurar suas pr\u00f3prias c\u00f3pias do GitLab. Esta abordagem funcionou bem por um tempo, no entanto, quando o n\u00famero de projetos no GitLab ultrapassou 10 milh\u00f5es, percebemos que ela j\u00e1 n\u00e3o atendia \u00e0s nossas necessidades de escalabilidade e deployment.<\/p>\n<h2>Os primeiros passos rumo ao Kubernetes e ao GitLab cloud-native<\/h2>\n<p>\nEm 2017, foi criado o projeto <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-org\/charts\">GitLab Charts<\/a><\/noindex> para preparar o GitLab para a implanta\u00e7\u00e3o na nuvem e para permitir que os usu\u00e1rios instalem o GitLab em clusters Kubernetes. Naquela \u00e9poca, sab\u00edamos que a migra\u00e7\u00e3o do GitLab para o Kubernetes aumentaria as capacidades de escalabilidade da plataforma SaaS, simplificaria as implanta\u00e7\u00f5es e melhoraria a efici\u00eancia do uso dos recursos computacionais. Ao mesmo tempo, muitas funcionalidades de nosso aplicativo dependiam de se\u00e7\u00f5es NFS montadas, o que retardava a transi\u00e7\u00e3o de m\u00e1quinas virtuais.<\/p>\n<p>A busca por cloud native e Kubernetes permitiu que nossos engenheiros planejassem uma transi\u00e7\u00e3o gradual, durante a qual abandonamos algumas depend\u00eancias do aplicativo em rela\u00e7\u00e3o a armazenamentos de rede, enquanto continu\u00e1vamos a desenvolver novas funcionalidades. Desde que come\u00e7amos a planejar a migra\u00e7\u00e3o no ver\u00e3o de 2019, muitas dessas restri\u00e7\u00f5es foram eliminadas, e o processo de migra\u00e7\u00e3o do GitLab.com para Kubernetes agora est\u00e1 em plena execu\u00e7\u00e3o!<\/p>\n<h2>Recursos do GitLab.com em Kubernetes<\/h2>\n<p>\nPara o GitLab.com, utilizamos um \u00fanico cluster regional GKE, que processa todo o tr\u00e1fego do aplicativo. Para minimizar a complexidade j\u00e1 elevada da migra\u00e7\u00e3o, concentramos nossos esfor\u00e7os em servi\u00e7os que n\u00e3o dependem de armazenamento local ou NFS. O GitLab.com utiliza predominantemente uma base de c\u00f3digo monol\u00edtica em Rails, e n\u00f3s direcionamos o tr\u00e1fego com base nas caracter\u00edsticas da carga de trabalho para diferentes endpoints, isolados em seus pr\u00f3prios grupos de n\u00f3s.<\/p>\n<p>No caso do frontend, esses tipos s\u00e3o divididos em solicita\u00e7\u00f5es para web, API, Git SSH\/HTTPS e Registry. No caso do backend, dividimos os jobs na fila com base em v\u00e1rias caracter\u00edsticas dependendo de <noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/blog\/2020\/06\/24\/scaling-our-use-of-sidekiq\/\">limites de recursos predefinidos<\/a><\/noindex>, que nos permitem estabelecer metas de n\u00edvel de servi\u00e7o (Service-Level Objectives, SLOs) para diferentes cargas.<\/p>\n<p>Todos esses servi\u00e7os do GitLab.com est\u00e3o configurados usando um gr\u00e1fico Helm n\u00e3o modificado do GitLab. A configura\u00e7\u00e3o \u00e9 feita em subgr\u00e1ficos, que podem ser inclu\u00eddos seletivamente \u00e0 medida que migramos gradualmente os servi\u00e7os para o cluster. Mesmo considerando que foi decidido n\u00e3o incluir na migra\u00e7\u00e3o alguns dos nossos servi\u00e7os stateful, como Redis, Postgres, GitLab Pages e Gitaly, o uso do Kubernetes permite reduzir drasticamente o n\u00famero de VMs que atualmente s\u00e3o gerenciadas pelo Chef.<\/p>\n<h2>Transpar\u00eancia e gerenciamento de configura\u00e7\u00e3o do Kubernetes<\/h2>\n<p>\nTodas as configura\u00e7\u00f5es s\u00e3o geridas pelo pr\u00f3prio GitLab. Para isso, utilizamos tr\u00eas projetos de configura\u00e7\u00e3o baseados em Terraform e Helm. Fazemos o poss\u00edvel para utilizar o pr\u00f3prio GitLab para rodar o GitLab, mas para tarefas operacionais, temos uma instala\u00e7\u00e3o separada do GitLab. Isso \u00e9 necess\u00e1rio para que n\u00e3o dependamos da disponibilidade do GitLab.com ao realizar deployments e atualiza\u00e7\u00f5es do GitLab.com.<\/p>\n<p>Embora nossos pipelines para o cluster Kubernetes funcionem em uma instala\u00e7\u00e3o separada do GitLab, os reposit\u00f3rios de c\u00f3digo t\u00eam espelhos, dispon\u00edveis publicamente nos seguintes endere\u00e7os:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/k8s-workloads\/gitlab-com\">k8s-workloads\/gitlab-com<\/a><\/noindex> \u2014 wrapper de configura\u00e7\u00e3o do GitLab.com para o Helm chart do GitLab;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/k8s-workloads\/gitlab-helmfiles\/\">k8s-workloads\/gitlab-helmfiles<\/a><\/noindex> \u2014 cont\u00e9m configura\u00e7\u00f5es para servi\u00e7os que n\u00e3o est\u00e3o diretamente relacionados ao aplicativo GitLab. Isso inclui configura\u00e7\u00f5es para gerenciamento de logs e monitoramento do cluster, bem como para ferramentas integradas como PlantUML;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gitlab-com-infrastructure\">Gitlab-com-infrastructure<\/a><\/noindex> \u2014 configura\u00e7\u00e3o Terraform para Kubernetes e antiga infraestrutura de VM (legacy). Aqui, todos os recursos necess\u00e1rios para iniciar o cluster s\u00e3o configurados, incluindo o pr\u00f3prio cluster, pools de n\u00f3s, contas de servi\u00e7os e reserva de endere\u00e7os IP.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Nossas conclus\u00f5es ap\u00f3s um ano de migra\u00e7\u00e3o do GitLab.com para Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/612125403171d73106a081bf4244a52b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Ao fazer altera\u00e7\u00f5es, \u00e9 exibido um <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/k8s-workloads\/gitlab-com\/-\/merge_requests\/315#note_390180361\"><i>resumo p\u00fablico<\/i><\/a><\/noindex><i> com um link para um diff detalhado que a SRE analisa antes de fazer altera\u00e7\u00f5es no cluster.<\/i><\/p>\n<p>Para SRE, o link leva a um diff detalhado na instala\u00e7\u00e3o do GitLab, que \u00e9 usada para opera\u00e7\u00f5es e cuja acesso \u00e9 restrito. Isso permite que funcion\u00e1rios e a comunidade, que n\u00e3o t\u00eam acesso ao projeto operacional (que \u00e9 aberto apenas para SRE), visualizem as altera\u00e7\u00f5es propostas na configura\u00e7\u00e3o. Combinando uma inst\u00e2ncia p\u00fablica do GitLab para o c\u00f3digo com uma inst\u00e2ncia privada para os pipelines de CI, mantemos um fluxo de trabalho unificado, ao mesmo tempo em que garantimos independ\u00eancia do GitLab.com durante as atualiza\u00e7\u00f5es de configura\u00e7\u00e3o.<\/p>\n<h2>O que aprendemos durante a migra\u00e7\u00e3o<\/h2>\n<p>\nDurante a transi\u00e7\u00e3o, adquirimos experi\u00eancias que aplicamos a novas migra\u00e7\u00f5es e implanta\u00e7\u00f5es no Kubernetes.<\/p>\n<h3>1. Aumento de custos devido ao tr\u00e1fego entre zonas de disponibilidade<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Nossas conclus\u00f5es ap\u00f3s um ano de migra\u00e7\u00e3o do GitLab.com para Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/3dce44b3f803ffcea13e0101e7343d91.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Estat\u00edsticas de egress di\u00e1ria (bytes por dia) do conjunto de reposit\u00f3rios Git no GitLab.com<\/i><\/p>\n<p>O Google divide sua rede em regi\u00f5es. Essas, por sua vez, s\u00e3o subdivididas em zonas de disponibilidade (AZ). O Git hosting est\u00e1 ligado a grandes volumes de dados, por isso \u00e9 importante controlar o egress da rede. No caso de tr\u00e1fego interno, o egress \u00e9 gratuito somente se permanecer dentro de uma \u00fanica zona de disponibilidade. No momento da reda\u00e7\u00e3o deste artigo, estamos transferindo cerca de 100 TB de dados em um dia normal de trabalho (e isso apenas para reposit\u00f3rios Git). Os servi\u00e7os que em nossa antiga topologia, baseada em VM, estavam nas mesmas m\u00e1quinas virtuais agora operam em diferentes pods Kubernetes. Isso significa que parte do tr\u00e1fego que antes era local para a VM pode potencialmente sair das zonas de disponibilidade.<\/p>\n<p>Os clusters regionais GKE permitem abranger v\u00e1rias zonas de disponibilidade para redund\u00e2ncia. Estamos considerando a possibilidade <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/delivery\/-\/issues\/1175\">de dividir o cluster regional GKE em clusters de uma \u00fanica zona<\/a><\/noindex> para servi\u00e7os que geram grandes volumes de tr\u00e1fego. Isso permitir\u00e1 reduzir os custos de egress enquanto mant\u00e9m a redund\u00e2ncia a n\u00edvel de cluster.<\/p>\n<h3>2. Limites, requisi\u00e7\u00f5es de recursos e escalabilidade<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Nossas conclus\u00f5es ap\u00f3s um ano de migra\u00e7\u00e3o do GitLab.com para Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/6e2e1ca4d37666b49358d94cd8660c56.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>N\u00famero de r\u00e9plicas processando o tr\u00e1fego de produ\u00e7\u00e3o em registry.gitlab.com. O tr\u00e1fego atinge seu pico por volta das 15:00 UTC.<\/i><\/p>\n<p>Nossa hist\u00f3ria de migra\u00e7\u00e3o come\u00e7ou em agosto de 2019, quando transferimos o primeiro servi\u00e7o \u2014 o registro de cont\u00eaineres GitLab (GitLab Container Registry) \u2014 para Kubernetes. Esse servi\u00e7o cr\u00edtico de alto tr\u00e1fego foi perfeito para a primeira migra\u00e7\u00e3o, pois \u00e9 um aplicativo sem estado com poucas depend\u00eancias externas. O primeiro problema que encontramos foi o alto n\u00famero de pods expulsos devido \u00e0 falta de mem\u00f3ria nos n\u00f3s. Por isso, tivemos que ajustar as requisi\u00e7\u00f5es e limites.<\/p>\n<p>Descobriu-se que, no caso de um aplicativo cujo consumo de mem\u00f3ria cresce ao longo do tempo, valores baixos para as requisi\u00e7\u00f5es (reservando mem\u00f3ria para cada pod) junto com um limite \"generoso\" de uso resultavam em satura\u00e7\u00e3o. <i>(satura\u00e7\u00e3o)<\/i> dos n\u00f3s e em altos n\u00edveis de expuls\u00f5es. Para lidar com esse problema, foi <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/delivery\/-\/issues\/998#note_388983696\">Decidiu-se aumentar as requisi\u00e7\u00f5es e reduzir os limites.<\/a><\/noindex>Isso aliviou a press\u00e3o nos n\u00f3s e garantiu um ciclo de vida dos pods que n\u00e3o exercia uma press\u00e3o excessiva sobre o n\u00f3. Agora, come\u00e7amos as migra\u00e7\u00f5es com valores generosos (e quase iguais) de requisi\u00e7\u00f5es e limites, ajustando-os conforme necess\u00e1rio.<\/p>\n<h3>3. M\u00e9tricas e Logs<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Nossas conclus\u00f5es ap\u00f3s um ano de migra\u00e7\u00e3o do GitLab.com para Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/66d1fd47b57d5826f13defa6e6a7fe3c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>A unidade de infraestrutura foca nas lat\u00eancias, na porcentagem de erros e na satura\u00e7\u00e3o com metas estabelecidas <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Service-level_objective\"><i>de n\u00edvel de servi\u00e7o<\/i><\/a><\/noindex><i> (SLO), ligadas a <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/dashboards-gitlab-com\/-\/metrics\/sla-dashboard.yml?environment=1790496&amp;duration_seconds=86400\"><i>disponibilidade geral do nosso sistema<\/i><\/a><\/noindex><i>.<\/i><\/p>\n<p>No \u00faltimo ano, um dos eventos-chave da unidade de infraestrutura foram as melhorias na monitora\u00e7\u00e3o e no trabalho com SLO. Os SLO nos permitiram estabelecer metas para servi\u00e7os individuais, que monitoramos de perto durante a migra\u00e7\u00e3o. Mas mesmo com essa visibilidade aprimorada, nem sempre conseguimos detectar problemas rapidamente, utilizando m\u00e9tricas e alertas. Por exemplo, ao focar nas lat\u00eancias e na porcentagem de erros, n\u00e3o abrangemos completamente todos os cen\u00e1rios de uso do servi\u00e7o em migra\u00e7\u00e3o.<\/p>\n<p>Esse problema foi identificado quase imediatamente ap\u00f3s a transfer\u00eancia de parte das cargas de trabalho para o cluster. Ele se destacou especialmente ao verificar fun\u00e7\u00f5es cujo n\u00famero de requisi\u00e7\u00f5es \u00e9 pequeno, mas que possuem depend\u00eancias de configura\u00e7\u00e3o muito espec\u00edficas. Uma das li\u00e7\u00f5es-chave ap\u00f3s a migra\u00e7\u00e3o foi a necessidade de considerar na monitora\u00e7\u00e3o n\u00e3o apenas m\u00e9tricas, mas tamb\u00e9m logs e o 'long tail' <i>(refere-se \u00e0 <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Long_tail\"><i>distribui\u00e7\u00e3o delas<\/i><\/a><\/noindex><i> em um gr\u00e1fico \u2014 nota do tradutor)<\/i> de erros. Agora, para cada migra\u00e7\u00e3o, inclu\u00edmos uma lista detalhada de requisi\u00e7\u00f5es aos logs <i>(log queries)<\/i> e planejamos procedimentos claros de rollback, que podem ser transmitidos de uma equipe para outra em caso de problemas.<\/p>\n<p>O atendimento paralelo das mesmas requisi\u00e7\u00f5es na antiga infraestrutura de VM e na nova, baseada em Kubernetes, representou um desafio \u00fanico. Ao contr\u00e1rio da migra\u00e7\u00e3o do tipo lift-and-shift <i>(transfer\u00eancia r\u00e1pida de aplica\u00e7\u00f5es 'como est\u00e3o' para a nova infraestrutura; mais detalhes podem ser lidos, por exemplo, <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/www.ibm.com\/cloud\/learn\/lift-and-shift\"><i>aqui<\/i><\/a><\/noindex><i> \u2014 nota do tradutor.)<\/i>, o trabalho paralelo em \"m\u00e1quinas virtuais antigas\" e Kubernetes requer que as ferramentas de monitoramento sejam compat\u00edveis com ambos os ambientes e consigam consolidar m\u00e9tricas em uma \u00fanica vis\u00e3o. \u00c9 importante que usemos os mesmos dashboards e consultas de logs para alcan\u00e7ar uma observabilidade consistente durante o per\u00edodo de transi\u00e7\u00e3o.<\/p>\n<h3>4. Mudando o tr\u00e1fego para o novo cluster<\/h3>\n<p>\nPara o GitLab.com, parte dos servidores \u00e9 destinada \u00e0 <noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/handbook\/engineering\/#canary-testing\">fase can\u00e1rio (canary)<\/a><\/noindex>. O parque can\u00e1rio atende nossos projetos internos e tamb\u00e9m pode <noindex><a rel=\"nofollow\" href=\"https:\/\/next.gitlab.com\/\">ser acionado por usu\u00e1rios<\/a><\/noindex>. Mas, principalmente, \u00e9 destinado \u00e0 verifica\u00e7\u00e3o de mudan\u00e7as feitas na infraestrutura e no aplicativo. O primeiro servi\u00e7o migrado come\u00e7ou recebendo um volume limitado de tr\u00e1fego interno, e continuamos usando esse m\u00e9todo para garantir que os SLO estejam sendo cumpridos antes de direcionar todo o tr\u00e1fego para o cluster.<\/p>\n<p>No caso da migra\u00e7\u00e3o, isso significa que inicialmente as solicita\u00e7\u00f5es para projetos internos s\u00e3o direcionadas ao Kubernetes, e ent\u00e3o, gradualmente, redirecionamos o restante do tr\u00e1fego para o cluster alterando o peso do backend atrav\u00e9s do HAProxy. Durante a transi\u00e7\u00e3o de VM para Kubernetes, ficou claro que era muito vantajoso ter um m\u00e9todo simples de redirecionamento de tr\u00e1fego entre a infraestrutura antiga e a nova e, consequentemente, manter a infraestrutura antiga pronta para um rollback nos primeiros dias ap\u00f3s a migra\u00e7\u00e3o.<\/p>\n<h3>5. Capacidade reserva dos pods e seu uso<\/h3>\n<p>\nQuase imediatamente, o seguinte problema foi identificado: os pods para o servi\u00e7o Registry iniciaram rapidamente, no entanto, o in\u00edcio dos pods para o Sidekiq demorava at\u00e9 <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-org\/charts\/gitlab\/-\/issues\/1775\">dois minutos<\/a><\/noindex>. O longo tempo de inicializa\u00e7\u00e3o dos pods para o Sidekiq tornou-se um problema quando come\u00e7amos a migrar para Kubernetes as cargas de trabalho para workers, que precisam processar jobs rapidamente e escalar rapidamente.<\/p>\n<p>Neste caso, a li\u00e7\u00e3o foi que, embora o Horizontal Pod Autoscaler (HPA) no Kubernetes lide bem com o aumento do tr\u00e1fego, \u00e9 importante considerar as caracter\u00edsticas das cargas de trabalho e reservar recursos adicionais para os pods (especialmente em condi\u00e7\u00f5es de demanda desigual). No nosso caso, houve um aumento repentino de jobs, resultando em uma escalabilidade r\u00e1pida, que estava saturando os recursos da CPU antes que consegu\u00edssemos escalar o pool de n\u00f3s.<\/p>\n<p>Sempre h\u00e1 uma tenta\u00e7\u00e3o de extrair o m\u00e1ximo do cluster, no entanto, inicialmente enfrentamos problemas de desempenho e agora come\u00e7amos com um or\u00e7amento de pods generoso e o reduzimos posteriormente, monitorando atentamente o SLO. O lan\u00e7amento de pods para o servi\u00e7o Sidekiq acelerou significativamente e agora leva, em m\u00e9dia, cerca de 40 segundos. <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-org\/charts\/gitlab\/-\/issues\/1775\">Para reduzir o tempo de inicializa\u00e7\u00e3o dos pods<\/a><\/noindex> tanto o GitLab.com quanto nossos usu\u00e1rios de instala\u00e7\u00f5es self-managed que trabalham com o chart Helm oficial do GitLab se beneficiaram.<\/p>\n<h2>Conclus\u00e3o<\/h2>\n<p>\nAp\u00f3s a migra\u00e7\u00e3o de cada servi\u00e7o, celebramos as vantagens de usar Kubernetes em produ\u00e7\u00e3o: deploys mais r\u00e1pidos e seguros, escalabilidade e uma distribui\u00e7\u00e3o de recursos mais eficaz. Al\u00e9m disso, os benef\u00edcios da migra\u00e7\u00e3o v\u00e3o al\u00e9m do servi\u00e7o GitLab.com. Cada melhoria no chart Helm oficial traz vantagens tamb\u00e9m para seus usu\u00e1rios.<\/p>\n<p>Espero que voc\u00ea tenha gostado da hist\u00f3ria sobre nossas aventuras na migra\u00e7\u00e3o para Kubernetes. Continuamos a migrar novos servi\u00e7os para o cluster. Mais informa\u00e7\u00f5es podem ser encontradas nas seguintes publica\u00e7\u00f5es:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/handbook\/engineering\/infrastructure\/production\/kubernetes\/gitlab-com\/\">Por que estamos migrando para Kubernetes?<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/handbook\/engineering\/infrastructure\/production\/architecture\/#gitlab-com-on-kubernetes\">GitLab.com no Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/groups\/gitlab-com\/gl-infra\/-\/epics\/112\">\u00c9pico da migra\u00e7\u00e3o do GitLab.com para Kubernetes<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>P.S. do tradutor<\/h2>\n<p>\nConfira tamb\u00e9m em nosso blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/519962\/\">3 anos com Kubernetes em produ\u00e7\u00e3o: o que aprendemos<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/504396\/\">10 erros t\u00edpicos ao usar Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/335814\/\">Hist\u00f3rias de sucesso do Kubernetes em produ\u00e7\u00e3o. Parte 3: GitHub<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440278\/\">A transi\u00e7\u00e3o do Tinder para Kubernetes<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/520150\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0430\u0434\u0430\u043f\u0442\u0430\u0446\u0438\u044e Kubernetes \u0432 GitLab \u0441\u0447\u0438\u0442\u0430\u044e\u0442 \u043e\u0434\u043d\u0438\u043c \u0438\u0437 \u0434\u0432\u0443\u0445 \u0433\u043b\u0430\u0432\u043d\u044b\u0445 \u0444\u0430\u043a\u0442\u043e\u0440\u043e\u0432, \u0441\u043f\u043e\u0441\u043e\u0431\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u0440\u043e\u0441\u0442\u0443 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438. \u0422\u0435\u043c \u043d\u0435 \u043c\u0435\u043d\u0435\u0435, \u0434\u043e \u043d\u0435\u0434\u0430\u0432\u043d\u0435\u0433\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0438 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0430 \u043e\u043d\u043b\u0430\u0439\u043d-\u0441\u0435\u0440\u0432\u0438\u0441\u0430 GitLab.com \u0431\u044b\u043b\u0430 \u043f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u0430 \u043d\u0430 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0445 \u043c\u0430\u0448\u0438\u043d\u0430\u0445, \u0438 \u0442\u043e\u043b\u044c\u043a\u043e \u043e\u043a\u043e\u043b\u043e \u0433\u043e\u0434\u0430 \u043d\u0430\u0437\u0430\u0434 \u043d\u0430\u0447\u0430\u043b\u0430\u0441\u044c \u0435\u0451 \u043c\u0438\u0433\u0440\u0430\u0446\u0438\u044f \u0432 K8s, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0434\u043e \u0441\u0438\u0445 \u043f\u043e\u0440 \u043d\u0435 \u0437\u0430\u0432\u0435\u0440\u0448\u0435\u043d\u0430. \u0420\u0430\u0434\u044b \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043d\u0435\u0434\u0430\u0432\u043d\u0435\u0439 \u0441\u0442\u0430\u0442\u044c\u0438 SRE-\u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0430 GitLab \u043e \u0442\u043e\u043c, \u043a\u0430\u043a [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":94978,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-94977","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.5 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0430\u0434\u0430\u043f\u0442\u0430\u0446\u0438\u044e Kubernetes \u0432 GitLab \u0441\u0447\u0438\u0442\u0430\u044e\u0442 \u043e\u0434\u043d\u0438\u043c \u0438\u0437 \u0434\u0432\u0443\u0445 \u0433\u043b\u0430\u0432\u043d\u044b\u0445 \u0444\u0430\u043a\u0442\u043e\u0440\u043e\u0432, \u0441\u043f\u043e\u0441\u043e\u0431\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u0440\u043e\u0441\u0442\u0443 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.5\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041d\u0430\u0448\u0438 \u0432\u044b\u0432\u043e\u0434\u044b \u0437\u0430 \u0433\u043e\u0434 \u043c\u0438\u0433\u0440\u0430\u0446\u0438\u0438 GitLab.com \u043d\u0430 Kubernetes | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0430\u0434\u0430\u043f\u0442\u0430\u0446\u0438\u044e Kubernetes \u0432 GitLab \u0441\u0447\u0438\u0442\u0430\u044e\u0442 \u043e\u0434\u043d\u0438\u043c \u0438\u0437 \u0434\u0432\u0443\u0445 \u0433\u043b\u0430\u0432\u043d\u044b\u0445 \u0444\u0430\u043a\u0442\u043e\u0440\u043e\u0432, \u0441\u043f\u043e\u0441\u043e\u0431\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u0440\u043e\u0441\u0442\u0443 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-09-24T05:43:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-09-24T05:43:00+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47 Nossas conclus\u00f5es ap\u00f3s um ano de migra\u00e7\u00e3o do GitLab.com para Kubernetes | ProHoster","description":"Nota do tradutor: a adapta\u00e7\u00e3o do Kubernetes no GitLab \u00e9 considerada um dos dois principais fatores que contribuem para o crescimento da empresa.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041d\u0430\u0448\u0438 \u0432\u044b\u0432\u043e\u0434\u044b \u0437\u0430 \u0433\u043e\u0434 \u043c\u0438\u0433\u0440\u0430\u0446\u0438\u0438 GitLab.com \u043d\u0430 Kubernetes | ProHoster","og:description":"\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0430\u0434\u0430\u043f\u0442\u0430\u0446\u0438\u044e Kubernetes \u0432 GitLab \u0441\u0447\u0438\u0442\u0430\u044e\u0442 \u043e\u0434\u043d\u0438\u043c \u0438\u0437 \u0434\u0432\u0443\u0445 \u0433\u043b\u0430\u0432\u043d\u044b\u0445 \u0444\u0430\u043a\u0442\u043e\u0440\u043e\u0432, \u0441\u043f\u043e\u0441\u043e\u0431\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u0440\u043e\u0441\u0442\u0443 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-09-24T05:43:00+00:00","article:modified_time":"2020-09-24T05:43:00+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"94977","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:14:45","updated":"2022-10-03 07:39:43","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/94977","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=94977"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/94977\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/94978"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=94977"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=94977"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=94977"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}