{"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\/fr\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","title":{"rendered":"Nos conclusions sur un an de migration de GitLab.com vers Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Note de traduction.<\/b>: l'adaptation de Kubernetes dans GitLab est consid\u00e9r\u00e9e comme l'un des deux principaux facteurs contribuant \u00e0 la croissance de l'entreprise. Cependant, jusqu'\u00e0 r\u00e9cemment, l'infrastructure du service en ligne GitLab.com \u00e9tait construite sur des machines virtuelles, et seulement il y a environ un an a commenc\u00e9 sa migration vers K8s, qui n'est toujours pas termin\u00e9e. Nous sommes heureux de pr\u00e9senter la traduction d'un r\u00e9cent article d'un ing\u00e9nieur SRE de GitLab sur la mani\u00e8re dont cela se d\u00e9roule et les conclusions tir\u00e9es par les ing\u00e9nieurs participant au projet.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Nos conclusions sur un an de migration de GitLab.com vers Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/58429abf60cd19a49c5ce593051c2fca.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDepuis pr\u00e8s d'un an, notre d\u00e9partement d'infrastructure s'occupe de la migration de tous les services fonctionnant sur GitLab.com vers Kubernetes. Pendant cette p\u00e9riode, nous avons rencontr\u00e9 des probl\u00e8mes li\u00e9s non seulement au d\u00e9placement des services vers Kubernetes, mais aussi \u00e0 la gestion du d\u00e9ploiement hybride durant la transition. Cette article traitera des le\u00e7ons pr\u00e9cieuses que nous avons apprises.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Depuis le d\u00e9but, GitLab.com a fonctionn\u00e9 sur le cloud avec des machines virtuelles. Ces machines virtuelles sont g\u00e9r\u00e9es par Chef, et leur installation se fait via notre <noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/install\/#ubuntu\">paquet Linux officiel<\/a><\/noindex>. <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-org\/release\/docs\/-\/blob\/master\/general\/deploy\/gitlab-com-deployer.md\">Strat\u00e9gie de d\u00e9ploiement<\/a><\/noindex> au cas o\u00f9 il serait n\u00e9cessaire de mettre \u00e0 jour l'application, consiste \u00e0 mettre \u00e0 jour le parc de serveurs de mani\u00e8re coordonn\u00e9e et s\u00e9quentielle \u00e0 l'aide d'un pipeline CI. Cette m\u00e9thode - bien qu'elle soit lente et un peu <noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/handbook\/values\/#boring-solutions\">ennuyeuse<\/a><\/noindex> - garantit que GitLab.com applique les m\u00eames m\u00e9thodes d'installation et de configuration que les utilisateurs des installations <i>(autonomes)<\/i> de GitLab, qui utilisent nos paquets Linux.<\/p>\n<p>Nous utilisons cette m\u00e9thode car il est d'une importance cruciale de ressentir toutes les joies et les peines que rencontrent les membres de la communaut\u00e9 lorsqu'ils installent et configurent leurs propres copies de GitLab. Cette approche a bien fonctionn\u00e9 pendant un certain temps, mais lorsque le nombre de projets sur GitLab a d\u00e9pass\u00e9 les 10 millions, nous avons r\u00e9alis\u00e9 qu'elle ne r\u00e9pondait plus \u00e0 nos besoins en mati\u00e8re de mise \u00e0 l'\u00e9chelle et de d\u00e9ploiement.<\/p>\n<h2>Premiers pas vers Kubernetes et GitLab cloud-native<\/h2>\n<p>\nEn 2017, le projet a \u00e9t\u00e9 cr\u00e9\u00e9 <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-org\/charts\">GitLab Charts<\/a><\/noindex> pour pr\u00e9parer GitLab \u00e0 \u00eatre d\u00e9ploy\u00e9 dans le cloud, ainsi que pour donner aux utilisateurs la possibilit\u00e9 d'installer GitLab dans des clusters Kubernetes. \u00c0 l'\u00e9poque, nous savions que le transfert de GitLab vers Kubernetes augmenterait la capacit\u00e9 de mise \u00e0 l'\u00e9chelle de la plateforme SaaS, simplifierait les d\u00e9ploiements et am\u00e9liorerait l'efficacit\u00e9 de l'utilisation des ressources informatiques. En m\u00eame temps, de nombreuses fonctions de notre application d\u00e9pendaient de sections NFS mont\u00e9es, ce qui ralentissait la transition depuis des machines virtuelles.<\/p>\n<p>L'aspiration \u00e0 une approche cloud native et \u00e0 Kubernetes a permis \u00e0 nos ing\u00e9nieurs de planifier une transition progressive, au cours de laquelle nous avons abandonn\u00e9 certaines d\u00e9pendances de l'application vis-\u00e0-vis des stockages en r\u00e9seau, tout en continuant \u00e0 d\u00e9velopper de nouvelles fonctionnalit\u00e9s. Depuis que nous avons commenc\u00e9 \u00e0 planifier la migration \u00e0 l'\u00e9t\u00e9 2019, de nombreuses restrictions ont \u00e9t\u00e9 lev\u00e9es, et le processus de transfert de GitLab.com vers Kubernetes est maintenant en cours !<\/p>\n<h2>Caract\u00e9ristiques de GitLab.com dans Kubernetes<\/h2>\n<p>\nPour GitLab.com, nous utilisons un seul cluster r\u00e9gional GKE traitant tout le trafic de l'application. Afin de minimiser la complexit\u00e9 d\u00e9j\u00e0 importante de la migration, nous nous concentrons sur les services qui ne d\u00e9pendent pas du stockage local ou de NFS. GitLab.com utilise principalement une base de code monolithique sur Rails, et nous dirigeons le trafic selon les caract\u00e9ristiques de la charge de travail vers diff\u00e9rents points de terminaison, isol\u00e9s dans leurs propres pools de n\u0153uds.<\/p>\n<p>Pour le front-end, ces types se divisent en requ\u00eates web, API, Git SSH\/HTTPS et Registry. Pour le back-end, nous divisons les t\u00e2ches dans la queue selon diff\u00e9rentes caract\u00e9ristiques. <noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/blog\/2020\/06\/24\/scaling-our-use-of-sidekiq\/\">limites de ressources pr\u00e9d\u00e9finies<\/a><\/noindex>, ce qui nous permet d'\u00e9tablir des objectifs de niveau de service (Service-Level Objectives, SLOs) pour diff\u00e9rentes charges.<\/p>\n<p>Tous ces services GitLab.com sont configur\u00e9s \u00e0 l'aide du Helm chart GitLab non modifi\u00e9. La configuration se fait dans des sous-charts qui peuvent \u00eatre activ\u00e9s s\u00e9lectivement au fur et \u00e0 mesure que nous transf\u00e9rons progressivement des services dans le cluster. M\u00eame si nous avons d\u00e9cid\u00e9 de ne pas inclure dans la migration certains de nos services \u00e9tat, tels que Redis, Postgres, GitLab Pages et Gitaly, l'utilisation de Kubernetes permet de r\u00e9duire radicalement le nombre de VM actuellement g\u00e9r\u00e9es par Chef.<\/p>\n<h2>Transparence et gestion des configurations Kubernetes<\/h2>\n<p>\nTous les param\u00e8tres sont g\u00e9r\u00e9s par GitLab lui-m\u00eame. Pour cela, nous utilisons trois projets de configuration bas\u00e9s sur Terraform et Helm. Nous essayons de nous appuyer autant que possible sur GitLab pour faire fonctionner GitLab, mais pour les t\u00e2ches op\u00e9rationnelles, nous avons une installation distincte de GitLab. Cela est n\u00e9cessaire pour \u00e9viter de d\u00e9pendre de la disponibilit\u00e9 de GitLab.com lors des d\u00e9ploiements et des mises \u00e0 jour de GitLab.com.<\/p>\n<p>Bien que nos pipelines pour le cluster Kubernetes fonctionnent sur une installation s\u00e9par\u00e9e de GitLab, les d\u00e9p\u00f4ts de code ont des miroirs, accessibles publiquement aux adresses suivantes :<\/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 enveloppe de configuration GitLab.com pour le Helm chart de 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 contient des configurations pour des services qui ne sont pas li\u00e9s directement \u00e0 l'application GitLab. Cela inclut des configurations pour la gestion des logs et la surveillance du cluster, ainsi que pour des outils int\u00e9gr\u00e9s comme PlantUML ;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gitlab-com-infrastructure\">Gitlab-com-infrastructure<\/a><\/noindex> \u2014 configuration Terraform pour Kubernetes et l'ancienne infrastructure VM (legacy). Ici, toutes les ressources n\u00e9cessaires au d\u00e9ploiement du cluster sont configur\u00e9es, y compris le cluster lui-m\u00eame, les pools de n\u0153uds, les comptes de service, et la r\u00e9servation d'adresses IP.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Nos conclusions sur un an de migration de GitLab.com vers Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/612125403171d73106a081bf4244a52b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Lors de modifications, un r\u00e9sum\u00e9 public est affich\u00e9 <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/k8s-workloads\/gitlab-com\/-\/merge_requests\/315#note_390180361\"><i>avec un lien vers un diff d\u00e9taill\u00e9, que l'\u00e9quipe SRE analyse avant d'apporter des modifications au cluster.<\/i><\/a><\/noindex><i> Pour les SRE, le lien m\u00e8ne \u00e0 un diff d\u00e9taill\u00e9 dans l'installation de GitLab, qui est utilis\u00e9e pour les op\u00e9rations et \u00e0 laquelle l'acc\u00e8s est restreint. Cela permet aux employ\u00e9s et \u00e0 la communaut\u00e9 sans acc\u00e8s au projet op\u00e9rationnel (qui n'est ouvert qu'aux SRE) de consulter les modifications propos\u00e9es dans la configuration. En combinant une instance publique de GitLab pour le code avec une instance ferm\u00e9e pour les pipelines CI, nous pr\u00e9servons un flux de travail unique tout en garantissant une ind\u00e9pendance par rapport \u00e0 GitLab.com lors des mises \u00e0 jour de configuration.<\/i><\/p>\n<p>Pour les SRE, le lien renvoie \u00e0 un diff d\u00e9taill\u00e9 dans l'installation de GitLab, qui est utilis\u00e9e pour les op\u00e9rations et \u00e0 laquelle l'acc\u00e8s est restreint. Cela permet aux employ\u00e9s et \u00e0 la communaut\u00e9 sans acc\u00e8s au projet op\u00e9rationnel (qui est ouvert uniquement aux SRE) de visualiser les modifications propos\u00e9es dans la configuration. En combinant une instance publique de GitLab pour le code avec une instance priv\u00e9e pour les pipelines CI, nous maintenons un flux de travail unifi\u00e9 tout en garantissant l'ind\u00e9pendance par rapport \u00e0 GitLab.com lors des mises \u00e0 jour de configuration.<\/p>\n<h2>Au cours de la migration, de l'exp\u00e9rience a \u00e9t\u00e9 acquise, que nous appliquons aux nouvelles migrations et d\u00e9ploiements dans Kubernetes.<\/h2>\n<p>\n1. Augmentation des co\u00fbts en raison du trafic entre les zones de disponibilit\u00e9<\/p>\n<h3>Statistiques quotidiennes de l'egress (octets par jour) pour la flotte de d\u00e9p\u00f4ts Git sur GitLab.com<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Nos conclusions sur un an de migration de GitLab.com vers Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/3dce44b3f803ffcea13e0101e7343d91.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Statistiques quotidiennes d'egress (octets par jour) pour le parc de d\u00e9p\u00f4ts Git sur GitLab.com<\/i><\/p>\n<p>Google divise son r\u00e9seau en r\u00e9gions. Celles-ci se subdivisent en zones de disponibilit\u00e9 (AZ). L'h\u00e9bergement Git est li\u00e9 \u00e0 de grands volumes de donn\u00e9es, il est donc important de contr\u00f4ler le egress r\u00e9seau. En cas de trafic interne, le egress est gratuit uniquement s'il reste \u00e0 l'int\u00e9rieur d'une seule zone de disponibilit\u00e9. Au moment de la r\u00e9daction de cet article, nous transf\u00e9rons environ 100 To de donn\u00e9es en une journ\u00e9e de travail normale (et cela ne concerne que les d\u00e9p\u00f4ts Git). Les services, qui dans notre ancienne topologie bas\u00e9e sur des VM, se trouvaient sur les m\u00eames machines virtuelles, fonctionnent d\u00e9sormais dans diff\u00e9rents pods Kubernetes. Cela signifie qu'une partie du trafic qui \u00e9tait auparavant locale aux VM pourrait potentiellement d\u00e9passer les zones de disponibilit\u00e9.<\/p>\n<p>Les clusters r\u00e9gionaux GKE permettent de couvrir plusieurs zones de disponibilit\u00e9 pour la redondance. Nous envisageons la possibilit\u00e9 <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/delivery\/-\/issues\/1175\">de diviser le cluster r\u00e9gional GKE en clusters zon\u00e9s uniques<\/a><\/noindex> pour les services g\u00e9n\u00e9rant de gros volumes de trafic. Cela permettra de r\u00e9duire les co\u00fbts d'egress tout en maintenant la redondance au niveau du cluster.<\/p>\n<h3>2. Limites, demandes de ressources et mise \u00e0 l'\u00e9chelle<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Nos conclusions sur un an de migration de GitLab.com vers Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/6e2e1ca4d37666b49358d94cd8660c56.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Nombre de r\u00e9pliques traitant le trafic de production sur registry.gitlab.com. Le trafic atteint son pic vers ~15h00 UTC.<\/i><\/p>\n<p>Notre histoire de migration a commenc\u00e9 en ao\u00fbt 2019, lorsque nous avons transf\u00e9r\u00e9 notre premier service \u2014 GitLab Container Registry \u2014 vers Kubernetes. Ce service critique et \u00e0 fort trafic \u00e9tait bien adapt\u00e9 pour cette premi\u00e8re migration, car il s'agit d'une application stateless avec peu de d\u00e9pendances externes. Le premier probl\u00e8me rencontr\u00e9 a \u00e9t\u00e9 le grand nombre de pods \u00e9vinc\u00e9s en raison du manque de m\u00e9moire sur les n\u0153uds. Cela nous a contraints \u00e0 modifier les demandes et les limites.<\/p>\n<p>Il a \u00e9t\u00e9 constat\u00e9 que dans le cas d'une application dont la consommation de m\u00e9moire augmente avec le temps, de faibles valeurs pour les demandes (r\u00e9servant de la m\u00e9moire pour chaque pod) combin\u00e9es \u00e0 une limite 'g\u00e9n\u00e9reuse' d'utilisation entra\u00eenaient une saturation. <i>(saturation)<\/i> des n\u0153uds et un taux \u00e9lev\u00e9 d'expulsions. Pour rem\u00e9dier \u00e0 ce probl\u00e8me, il a \u00e9t\u00e9 <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/delivery\/-\/issues\/998#note_388983696\">Il a \u00e9t\u00e9 d\u00e9cid\u00e9 d'augmenter les demandes et de r\u00e9duire les limites.<\/a><\/noindex>Cela a soulag\u00e9 la pression sur les n\u0153uds et a assur\u00e9 un cycle de vie des pods qui ne mettait pas une pression excessive sur les n\u0153uds. Nous commen\u00e7ons d\u00e9sormais les migrations avec des valeurs (g\u00e9n\u00e9reuses et presque \u00e9gales) pour les demandes et les limites, en les ajustant si n\u00e9cessaire.<\/p>\n<h3>3. M\u00e9triques et journaux<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Nos conclusions sur un an de migration de GitLab.com vers Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/66d1fd47b57d5826f13defa6e6a7fe3c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Le d\u00e9partement des infrastructures se concentre sur les latences, le taux d'erreurs et la saturation par rapport aux <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Service-level_objective\"><i>objectifs de niveau de service<\/i><\/a><\/noindex><i> (SLO), li\u00e9s \u00e0 <\/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>la disponibilit\u00e9 g\u00e9n\u00e9rale de notre syst\u00e8me.<\/i><\/a><\/noindex><i>.<\/i><\/p>\n<p>Au cours de l'ann\u00e9e \u00e9coul\u00e9e, l'un des \u00e9v\u00e9nements cl\u00e9s dans le d\u00e9partement des infrastructures a \u00e9t\u00e9 des am\u00e9liorations dans le suivi et la gestion des SLO. Les SLO nous ont permis de d\u00e9finir des objectifs pour des services sp\u00e9cifiques, que nous avons surveill\u00e9s de pr\u00e8s pendant la migration. Mais m\u00eame avec une visibilit\u00e9 am\u00e9lior\u00e9e, il n'est pas toujours possible de voir imm\u00e9diatement les probl\u00e8mes en utilisant les m\u00e9triques et les alertes. Par exemple, en nous concentrant sur les latences et le taux d'erreurs, nous ne couvrons pas compl\u00e8tement tous les sc\u00e9narios d'utilisation du service en migration.<\/p>\n<p>Ce probl\u00e8me a \u00e9t\u00e9 d\u00e9tect\u00e9 presque imm\u00e9diatement apr\u00e8s le transfert d'une partie des charges de travail vers le cluster. Il s'est particuli\u00e8rement manifest\u00e9 lors de la v\u00e9rification de fonctionnalit\u00e9s dont le nombre de requ\u00eates est faible, mais qui ont des d\u00e9pendances de configuration tr\u00e8s sp\u00e9cifiques. L'une des le\u00e7ons cl\u00e9s tir\u00e9es de la migration a \u00e9t\u00e9 la n\u00e9cessit\u00e9 de prendre en compte non seulement les m\u00e9triques lors de la surveillance, mais \u00e9galement les journaux et le \u00ab long tail \u00bb <i>(il s'agit de <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Long_tail\"><i>ce type de r\u00e9partition<\/i><\/a><\/noindex><i> sur le graphique - note du trad.)<\/i> d'erreurs. Maintenant, pour chaque migration, nous incluons une liste d\u00e9taill\u00e9e des requ\u00eates aux journaux <i>(log queries)<\/i> et pr\u00e9voyons des proc\u00e9dures de rollback claires, pouvant \u00eatre transmises d'une \u00e9quipe \u00e0 l'autre en cas de probl\u00e8mes.<\/p>\n<p>Le service parall\u00e8le des m\u00eames requ\u00eates sur l'ancienne infrastructure VM et la nouvelle, bas\u00e9e sur Kubernetes, repr\u00e9sentait un d\u00e9fi unique. Contrairement \u00e0 la migration de type lift-and-shift <i>(transfert rapide d'applications \u00ab telles quelles \u00bb vers la nouvelle infrastructure ; pour en savoir plus, par exemple, <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/www.ibm.com\/cloud\/learn\/lift-and-shift\"><i>ici<\/i><\/a><\/noindex><i> \u2014 n.d.t.)<\/i>, le travail parall\u00e8le sur les \u00ab anciennes \u00bb VM et Kubernetes n\u00e9cessite que les outils de surveillance soient compatibles avec les deux environnements et puissent agr\u00e9ger les m\u00e9triques en une seule vue. Il est important que nous utilisions les m\u00eames tableaux de bord et les m\u00eames requ\u00eates de journaux afin d'obtenir une observabilit\u00e9 coh\u00e9rente pendant la p\u00e9riode de transition.<\/p>\n<h3>4. Changement de trafic vers le nouveau cluster<\/h3>\n<p>\nPour GitLab.com, une partie des serveurs est d\u00e9di\u00e9e \u00e0 <noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/handbook\/engineering\/#canary-testing\">l'\u00e9tape canari<\/a><\/noindex>. Le parc canari sert nos projets internes, mais peut \u00e9galement <noindex><a rel=\"nofollow\" href=\"https:\/\/next.gitlab.com\/\">\u00eatre activ\u00e9 par les utilisateurs<\/a><\/noindex>. Mais il est avant tout destin\u00e9 \u00e0 tester les modifications apport\u00e9es \u00e0 l'infrastructure et \u00e0 l'application. Le premier service migr\u00e9 a commenc\u00e9 par recevoir un volume limit\u00e9 de trafic interne, et nous continuons d'utiliser cette m\u00e9thode pour assurer le respect des SLO avant de diriger tout le trafic vers le cluster.<\/p>\n<p>Dans le cas de la migration, cela signifie que les requ\u00eates pour les projets internes sont d'abord dirig\u00e9es vers Kubernetes, puis nous transf\u00e9rons progressivement le reste du trafic vers le cluster en ajustant le poids pour le backend via HAProxy. Au cours de la transition des VM vers Kubernetes, il est devenu \u00e9vident qu'il est tr\u00e8s avantageux d'avoir une m\u00e9thode simple pour rediriger le trafic entre l'ancienne et la nouvelle infrastructure et, par cons\u00e9quent, de garder l'ancienne infrastructure pr\u00eate \u00e0 \u00eatre r\u00e9activ\u00e9e dans les premiers jours apr\u00e8s la migration.<\/p>\n<h3>5. Capacit\u00e9s de secours des pods et leur utilisation<\/h3>\n<p>\nPresque imm\u00e9diatement, le probl\u00e8me suivant a \u00e9t\u00e9 identifi\u00e9 : les pods pour le service Registry d\u00e9marraient rapidement, mais le lancement des pods pour Sidekiq prenait jusqu'\u00e0 <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-org\/charts\/gitlab\/-\/issues\/1775\">deux minutes<\/a><\/noindex>. Le d\u00e9marrage prolong\u00e9 des pods pour Sidekiq est devenu un probl\u00e8me lorsque nous avons commenc\u00e9 la migration des charges de travail Kubernetes pour les workers, qui doivent traiter rapidement les jobs et se mettre \u00e0 l'\u00e9chelle rapidement.<\/p>\n<p>Dans ce cas, la le\u00e7on \u00e9tait que, bien que le Horizontal Pod Autoscaler (HPA) de Kubernetes g\u00e8re bien l'augmentation du trafic, il est important de prendre en compte les caract\u00e9ristiques des charges de travail et de pr\u00e9voir des ressources de secours pour les pods (surtout dans des conditions de demande in\u00e9gale). Dans notre cas, nous avons observ\u00e9 une mont\u00e9e soudaine des jobs, entra\u00eenant un escalade rapide, ce qui a satur\u00e9 les ressources CPU avant que nous puissions \u00e9largir le pool de n\u0153uds.<\/p>\n<p>Il y a toujours la tentation d'\u00ab extraire \u00bb autant que possible du cluster, cependant, nous, confront\u00e9s \u00e0 des probl\u00e8mes de performance \u00e0 l'origine, commen\u00e7ons maintenant avec un budget de pods g\u00e9n\u00e9reux et le r\u00e9duisons par la suite, surveillant de pr\u00e8s les SLO. Le d\u00e9marrage des pods pour le service Sidekiq s'est consid\u00e9rablement acc\u00e9l\u00e9r\u00e9 et prend maintenant en moyenne environ 40 secondes. <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-org\/charts\/gitlab\/-\/issues\/1775\">\u00c0 propos de la r\u00e9duction du temps de d\u00e9marrage des pods<\/a><\/noindex> en ont b\u00e9n\u00e9fici\u00e9 tant GitLab.com que nos utilisateurs des installations self-managed utilisant le chart Helm officiel de GitLab.<\/p>\n<h2>Conclusion<\/h2>\n<p>\nApr\u00e8s avoir migr\u00e9 chaque service, nous avons appr\u00e9ci\u00e9 les avantages de l'utilisation de Kubernetes en production : un d\u00e9ploiement d'application plus rapide et plus s\u00fbr, une scalabilit\u00e9 accrue et une r\u00e9partition des ressources plus efficace. Les avantages de la migration vont m\u00eame au-del\u00e0 du service GitLab.com. Chaque am\u00e9lioration du chart Helm officiel en b\u00e9n\u00e9ficie \u00e9galement \u00e0 ses utilisateurs.<\/p>\n<p>J'esp\u00e8re que vous avez aim\u00e9 l'histoire de nos aventures dans la migration vers Kubernetes. Nous continuons \u00e0 transf\u00e9rer de nouveaux services dans le cluster. Vous pouvez trouver plus d'informations dans les publications suivantes :<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/handbook\/engineering\/infrastructure\/production\/kubernetes\/gitlab-com\/\">Pourquoi migrons-nous vers 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 sous Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/groups\/gitlab-com\/gl-infra\/-\/epics\/112\">\u00c9pop\u00e9e de la migration de GitLab.com vers Kubernetes<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>P.S. de l'auteur<\/h2>\n<p>\nLisez aussi dans notre blog :<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/519962\/\">3 ans avec Kubernetes en production : voici ce que nous avons compris<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/504396\/\">10 erreurs typiques lors de l'utilisation de Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/335814\/\">Histoires de succ\u00e8s de Kubernetes en production. Partie 3 : GitHub<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440278\/\">La transition de Tinder vers Kubernetes<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Source : <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.2 - 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\/fr\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\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\/fr\/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\udd47Nos conclusions apr\u00e8s un an de migration de GitLab.com vers Kubernetes | ProHoster","description":"Note du traducteur : l'adoption de Kubernetes par GitLab est consid\u00e9r\u00e9e comme l'un des deux principaux facteurs contribuant \u00e0 la croissance de l'entreprise.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","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\/fr\/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\/fr\/wp-json\/wp\/v2\/posts\/94977","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=94977"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/94977\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/94978"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=94977"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=94977"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=94977"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}