{"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\/es\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","title":{"rendered":"Nuestras conclusiones tras un a\u00f1o de migraci\u00f3n de GitLab.com a Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Nota de traducci\u00f3n.<\/b>: adaptar Kubernetes en GitLab se considera uno de los dos principales factores que contribuyen al crecimiento de la empresa. Sin embargo, hasta hace poco, la infraestructura del servicio en l\u00ednea GitLab.com se basaba en m\u00e1quinas virtuales, y solo hace aproximadamente un a\u00f1o comenz\u00f3 su migraci\u00f3n a K8s, la cual a\u00fan no se ha completado. Nos complace presentar la traducci\u00f3n de un reciente art\u00edculo de un ingeniero SRE de GitLab sobre c\u00f3mo est\u00e1 sucediendo esto y qu\u00e9 conclusiones est\u00e1n sacando los ingenieros involucrados en el proyecto.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Nuestras conclusiones tras un a\u00f1o de migraci\u00f3n de GitLab.com a Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/58429abf60cd19a49c5ce593051c2fca.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDurante aproximadamente un a\u00f1o, nuestro departamento de infraestructura ha estado migrando todos los servicios en funcionamiento en GitLab.com a Kubernetes. A lo largo de este tiempo, hemos enfrentado problemas relacionados no solo con el traslado de servicios a Kubernetes, sino tambi\u00e9n con la gesti\u00f3n de un despliegue h\u00edbrido durante la transici\u00f3n. En este art\u00edculo hablaremos sobre las lecciones valiosas que hemos aprendido.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Desde el principio, GitLab.com ha tenido sus servidores en la nube en m\u00e1quinas virtuales. Estas m\u00e1quinas virtuales son gestionadas por Chef, y su instalaci\u00f3n se lleva a cabo mediante nuestro <noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/install\/#ubuntu\">paquete oficial de Linux<\/a><\/noindex>. <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-org\/release\/docs\/-\/blob\/master\/general\/deploy\/gitlab-com-deployer.md\">La estrategia de despliegue<\/a><\/noindex> en caso de que sea necesario actualizar la aplicaci\u00f3n consiste en actualizar de manera coordinada y secuencial el parque de servidores utilizando un pipeline de CI. Este m\u00e9todo, aunque lento y un poco <noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/handbook\/values\/#boring-solutions\">aburrido<\/a><\/noindex> garantiza que GitLab.com utilice los mismos m\u00e9todos de instalaci\u00f3n y configuraci\u00f3n que los usuarios de instalaciones <i>(autogestionadas)<\/i> de GitLab, que aplican nuestros paquetes de Linux para ello.<\/p>\n<p>Utilizamos este m\u00e9todo porque es crucial experimentar todas las penas y alegr\u00edas que enfrentan los miembros de la comunidad al instalar y configurar sus propias copias de GitLab. Este enfoque funcion\u00f3 bien durante un tiempo, pero cuando el n\u00famero de proyectos en GitLab super\u00f3 los 10 millones, nos dimos cuenta de que ya no satisfac\u00eda nuestras necesidades de escalamiento y despliegue.<\/p>\n<h2>Los primeros pasos hacia Kubernetes y GitLab nativo en la nube<\/h2>\n<p>\nEn 2017 se cre\u00f3 el proyecto <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-org\/charts\">GitLab Charts<\/a><\/noindex> para preparar GitLab para su implementaci\u00f3n en la nube, as\u00ed como para permitir que los usuarios instalen GitLab en cl\u00fasteres de Kubernetes. En ese momento, sab\u00edamos que trasladar GitLab a Kubernetes ampliar\u00eda las capacidades de escalabilidad de la plataforma SaaS, facilitar\u00eda las implementaciones y optimizar\u00eda el uso de recursos inform\u00e1ticos. Al mismo tiempo, muchas funciones de nuestra aplicaci\u00f3n depend\u00edan de los vol\u00famenes NFS montados, lo que ralentizaba la transici\u00f3n desde m\u00e1quinas virtuales.<\/p>\n<p>La b\u00fasqueda de soluciones nativas de la nube y Kubernetes permiti\u00f3 a nuestros ingenieros planificar una transici\u00f3n gradual en la que renunciamos a algunas dependencias de la aplicaci\u00f3n de los almacenamientos de red, mientras continu\u00e1bamos desarrollando nuevas funciones. Desde que comenzamos a planear la migraci\u00f3n en verano de 2019, muchas de estas limitaciones han sido superadas, \u00a1y el proceso de transferencia de GitLab.com a Kubernetes est\u00e1 ahora en pleno desarrollo!<\/p>\n<h2>Caracter\u00edsticas de GitLab.com en Kubernetes<\/h2>\n<p>\nPara GitLab.com utilizamos un \u00fanico cl\u00faster regional de GKE que maneja todo el tr\u00e1fico de la aplicaci\u00f3n. Para minimizar la complejidad (ya de por s\u00ed complicada) de la migraci\u00f3n, nos enfocamos en los servicios que no dependen del almacenamiento local o de NFS. GitLab.com utiliza principalmente una base de c\u00f3digo monol\u00edtica en Rails, y dirigimos el tr\u00e1fico seg\u00fan las caracter\u00edsticas de la carga de trabajo a diferentes endpoints, aislados en sus propios grupos de nodos.<\/p>\n<p>En el caso del frontend, estos tipos se dividen en solicitudes a web, API, Git SSH\/HTTPS y Registry. En el caso del backend, calificamos los trabajos en la cola seg\u00fan varias caracter\u00edsticas dependiendo de <noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/blog\/2020\/06\/24\/scaling-our-use-of-sidekiq\/\">los l\u00edmites de recursos predefinidos<\/a><\/noindex>, que nos permiten establecer objetivos de niveles de servicio (Service-Level Objectives, SLOs) para diferentes cargas.<\/p>\n<p>Todos estos servicios de GitLab.com est\u00e1n configurados utilizando el chart de Helm de GitLab sin modificaciones. La configuraci\u00f3n se realiza en subcharts, que pueden ser habilitados selectivamente a medida que trasladamos gradualmente los servicios al cl\u00faster. A pesar de que se decidi\u00f3 no incluir en la migraci\u00f3n algunos de nuestros servicios con estado, como Redis, Postgres, GitLab Pages y Gitaly, el uso de Kubernetes permite reducir radicalmente el n\u00famero de VM que actualmente gestiona Chef.<\/p>\n<h2>Transparencia y gesti\u00f3n de la configuraci\u00f3n de Kubernetes<\/h2>\n<p>\nTodas las configuraciones son administradas por GitLab. Para ello, utilizamos tres proyectos de configuraci\u00f3n basados en Terraform y Helm. Intentamos utilizar GitLab en la medida de lo posible para ejecutar GitLab, pero para las tareas operativas tenemos una instalaci\u00f3n separada de GitLab. Esto es necesario para no depender de la disponibilidad de GitLab.com durante los despliegues y actualizaciones de GitLab.com.<\/p>\n<p>Aunque nuestros pipelines para el cl\u00faster de Kubernetes funcionan en una instalaci\u00f3n separada de GitLab, los repositorios de c\u00f3digo tienen espejos, accesibles p\u00fablicamente en las siguientes direcciones:<\/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 la envoltura de configuraci\u00f3n de GitLab.com para el chart de Helm 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 contiene configuraciones para servicios que no est\u00e1n directamente relacionados con la aplicaci\u00f3n GitLab. Entre ellos se incluyen configuraciones para la captura de logs y la monitorizaci\u00f3n del cl\u00faster, as\u00ed como para herramientas 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 configuraci\u00f3n de Terraform para Kubernetes y la infraestructura de VM antigua (legacy). Aqu\u00ed se configuran todos los recursos necesarios para iniciar el cl\u00faster, incluyendo el propio cl\u00faster, grupos de nodos, cuentas de servicio y reservas de direcciones IP.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Nuestras conclusiones tras un a\u00f1o de migraci\u00f3n de GitLab.com a Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/612125403171d73106a081bf4244a52b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Al realizar cambios, se muestra un <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/k8s-workloads\/gitlab-com\/-\/merge_requests\/315#note_390180361\"><i>resumen p\u00fablico<\/i><\/a><\/noindex><i> con un enlace a un diff detallado, que el SRE analiza antes de aplicar cambios en el cl\u00faster.<\/i><\/p>\n<p>Para SRE, el enlace lleva a un diff detallado en la instalaci\u00f3n de GitLab que se utiliza para operaciones y a la que se tiene acceso restringido. Esto permite que los empleados y la comunidad sin acceso al proyecto de operaciones (que est\u00e1 abierto solo para SRE) puedan revisar los cambios propuestos en la configuraci\u00f3n. Combinando una instancia p\u00fablica de GitLab para el c\u00f3digo con una instancia privada para los pipelines de CI, mantenemos un \u00fanico flujo de trabajo, al tiempo que aseguramos la independencia de GitLab.com en las actualizaciones de configuraci\u00f3n.<\/p>\n<h2>Lo que hemos aprendido durante la migraci\u00f3n<\/h2>\n<p>\nDurante el proceso de traslado se ha acumulado experiencia que aplicamos a nuevas migraciones y despliegues en Kubernetes.<\/p>\n<h3>1. Aumento de costos debido al tr\u00e1fico entre zonas de disponibilidad<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Nuestras conclusiones tras un a\u00f1o de migraci\u00f3n de GitLab.com a Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/3dce44b3f803ffcea13e0101e7343d91.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Estad\u00edsticas diarias de egress (bytes por d\u00eda) para el conjunto de repositorios Git en GitLab.com<\/i><\/p>\n<p>Google divide su red en regiones. Estas, a su vez, se dividen en zonas de disponibilidad (AZ). El alojamiento de Git est\u00e1 asociado con grandes vol\u00famenes de datos, por lo que es importante controlar la salida de red. En el caso del tr\u00e1fico interno, la salida es gratuita solo si se mantiene dentro de los l\u00edmites de una sola zona de disponibilidad. En el momento de escribir este art\u00edculo, estamos entregando aproximadamente 100 TB de datos en un d\u00eda laboral normal (y eso solo para los repositorios de Git). Los servicios que estaban en nuestra antigua topolog\u00eda basada en VM, que se encontraban en las mismas m\u00e1quinas virtuales, ahora funcionan en diferentes pods de Kubernetes. Esto significa que parte del tr\u00e1fico que antes era local para la VM puede potencialmente salir de las zonas de disponibilidad.<\/p>\n<p>Los cl\u00fasteres regionales de GKE permiten abarcar varias zonas de disponibilidad para la redundancia. Estamos considerando la posibilidad de <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/delivery\/-\/issues\/1175\">dividir el cl\u00faster regional de GKE en cl\u00fasteres de una sola zona<\/a><\/noindex> para los servicios que generan grandes vol\u00famenes de tr\u00e1fico. Esto permitir\u00e1 reducir los costos de egreso mientras se mantiene la redundancia a nivel de cl\u00faster.<\/p>\n<h3>2. L\u00edmites, solicitudes de recursos y escalado<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Nuestras conclusiones tras un a\u00f1o de migraci\u00f3n de GitLab.com a Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/6e2e1ca4d37666b49358d94cd8660c56.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>El n\u00famero de r\u00e9plicas que manejan el tr\u00e1fico de producci\u00f3n en registry.gitlab.com. El tr\u00e1fico alcanza su punto m\u00e1ximo alrededor de las 15:00 UTC.<\/i><\/p>\n<p>Nuestra historia con la migraci\u00f3n comenz\u00f3 en agosto de 2019, cuando trasladamos el primer servicio: el registro de contenedores GitLab (GitLab Container Registry) a Kubernetes. Este servicio cr\u00edtico de alto tr\u00e1fico fue adecuado para nuestra primera migraci\u00f3n, ya que es una aplicaci\u00f3n sin estado con pocas dependencias externas. El primer problema que encontramos fue el gran n\u00famero de pods desechados debido a la falta de memoria en los nodos. Debido a esto, tuvimos que ajustar las solicitudes y los l\u00edmites.<\/p>\n<p>Se descubri\u00f3 que, en el caso de una aplicaci\u00f3n cuya utilizaci\u00f3n de memoria aumenta con el tiempo, los valores bajos para las solicitudes (reservando memoria para cada pod) junto con un l\u00edmite 'generoso' en el uso conduc\u00edan a la saturaci\u00f3n. <i>(saturaci\u00f3n)<\/i> en los nodos y un alto nivel de desalojos. Para enfrentar este problema, se <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-com\/gl-infra\/delivery\/-\/issues\/998#note_388983696\">se decidi\u00f3 aumentar las solicitudes y reducir los l\u00edmites.<\/a><\/noindex>. Esto alivi\u00f3 la presi\u00f3n sobre los nodos y proporcion\u00f3 un ciclo de vida de los pods que no ejerc\u00eda demasiada presi\u00f3n sobre el nodo. Ahora comenzamos las migraciones con valores \u2018generosos\u2019 (y casi id\u00e9nticos) para las solicitudes y los l\u00edmites, ajust\u00e1ndolos seg\u00fan sea necesario.<\/p>\n<h3>3. M\u00e9tricas y registros<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Nuestras conclusiones tras un a\u00f1o de migraci\u00f3n de GitLab.com a Kubernetes\" src=\"\/wp-content\/uploads\/2020\/09\/66d1fd47b57d5826f13defa6e6a7fe3c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>El departamento de infraestructura se centra en las latencias, la tasa de errores y la saturaci\u00f3n con los objetivos establecidos <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Service-level_objective\"><i>de nivel de servicio<\/i><\/a><\/noindex><i> (SLO), ligados 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>la disponibilidad general de nuestro sistema.<\/i><\/a><\/noindex><i>.<\/i><\/p>\n<p>Durante el \u00faltimo a\u00f1o, uno de los eventos clave en el departamento de infraestructura ha sido la mejora en el monitoreo y la gesti\u00f3n de SLO. Los SLO nos permitieron establecer objetivos para servicios individuales, los cuales seguimos de cerca durante la migraci\u00f3n. Pero incluso con esta mejor visibilidad, no siempre se pueden identificar inmediatamente problemas utilizando m\u00e9tricas y alertas. Por ejemplo, al centrarnos en las latencias y la tasa de errores, no abarcamos completamente todos los escenarios de uso del servicio que est\u00e1 en migraci\u00f3n.<\/p>\n<p>Este problema se detect\u00f3 casi de inmediato despu\u00e9s de trasladar parte de las cargas de trabajo al cl\u00faster. Se hizo especialmente evidente al verificar funciones que tienen un n\u00famero bajo de solicitudes, pero que tienen dependencias de configuraci\u00f3n muy espec\u00edficas. Una de las lecciones clave aprendidas tras la migraci\u00f3n fue la necesidad de considerar en el monitoreo no solo las m\u00e9tricas, sino tambi\u00e9n los registros y el 'cola larga' <i>(refiri\u00e9ndose a <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Long_tail\"><i>tal distribuci\u00f3n<\/i><\/a><\/noindex><i> en el gr\u00e1fico \u2014 nota del traductor)<\/i> de errores. Ahora, para cada migraci\u00f3n, incluimos una lista detallada de consultas a los registros <i>(log queries)<\/i> y planeamos procedimientos claros de reversi\u00f3n, que en caso de problemas se pueden transferir de un turno a otro.<\/p>\n<p>La atenci\u00f3n paralela a las mismas solicitudes en la antigua infraestructura de VM y en la nueva, basada en Kubernetes, present\u00f3 un desaf\u00edo \u00fanico. A diferencia de la migraci\u00f3n de tipo lift-and-shift <i>(traslado r\u00e1pido de aplicaciones 'tal como est\u00e1n' a la nueva infraestructura; se puede leer m\u00e1s al respecto, por ejemplo, <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/www.ibm.com\/cloud\/learn\/lift-and-shift\"><i>aqu\u00ed<\/i><\/a><\/noindex><i> \u2014 nota del traductor)<\/i>, el funcionamiento paralelo de las \"antiguas\" VM y Kubernetes requiere que las herramientas de monitoreo sean compatibles con ambos entornos y sean capaces de combinar m\u00e9tricas en una \u00fanica vista. Es importante que utilicemos los mismos dashboards y consultas a los registros para lograr una observabilidad coherente durante el per\u00edodo de transici\u00f3n.<\/p>\n<h3>4. Redirigir el tr\u00e1fico al nuevo cl\u00faster<\/h3>\n<p>\nPara GitLab.com, parte de los servidores se asigna a <noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/handbook\/engineering\/#canary-testing\">la etapa canaria (canary)<\/a><\/noindex>. El parque canario atiende nuestros proyectos internos, y tambi\u00e9n puede <noindex><a rel=\"nofollow\" href=\"https:\/\/next.gitlab.com\/\">ser activado por los usuarios<\/a><\/noindex>. Pero, en primer lugar, est\u00e1 destinado a verificar los cambios realizados en la infraestructura y la aplicaci\u00f3n. El primer servicio migrado comenz\u00f3 recibiendo un volumen limitado de tr\u00e1fico interno, y seguimos utilizando este m\u00e9todo para asegurarnos de que se cumplan los SLO antes de dirigir todo el tr\u00e1fico al cl\u00faster.<\/p>\n<p>En el caso de la migraci\u00f3n, esto significa que, primero, se dirigen las solicitudes a proyectos internos en Kubernetes, y luego, gradualmente, redirigimos el resto del tr\u00e1fico al cl\u00faster cambiando el peso para el backend a trav\u00e9s de HAProxy. Durante el proceso de transici\u00f3n de VM a Kubernetes, qued\u00f3 claro que es muy beneficioso tener una forma simple de redirigir el tr\u00e1fico entre la antigua y nueva infraestructura y, por lo tanto, mantener la antigua infraestructura lista para un retroceso en los primeros d\u00edas despu\u00e9s de la migraci\u00f3n.<\/p>\n<h3>5. Capacidades de respaldo de los pods y su uso<\/h3>\n<p>\nCasi de inmediato se identific\u00f3 el siguiente problema: los pods para el servicio de Registro se iniciaban r\u00e1pidamente, sin embargo, el inicio de los pods para Sidekiq tardaba hasta <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-org\/charts\/gitlab\/-\/issues\/1775\">dos minutos<\/a><\/noindex>. El prolongado inicio de los pods para Sidekiq se convirti\u00f3 en un problema cuando comenzamos a migrar las cargas de trabajo de Kubernetes para los trabajadores que necesitan procesar trabajos r\u00e1pidamente y escalar r\u00e1pidamente.<\/p>\n<p>En este caso, la lecci\u00f3n fue que, aunque el Horizontal Pod Autoscaler (HPA) de Kubernetes maneja bien el aumento del tr\u00e1fico, es importante tener en cuenta las caracter\u00edsticas de las cargas de trabajo y asignar recursos de reserva para los pods (especialmente en condiciones de demanda desigual). En nuestro caso, experimentamos un repentino aumento de trabajos, lo que condujo a una r\u00e1pida escalabilidad, saturando los recursos de CPU antes de que pudi\u00e9ramos escalar el grupo de nodos.<\/p>\n<p>Siempre existe la tentaci\u00f3n de extraer lo m\u00e1ximo posible del cl\u00faster; sin embargo, tras enfrentar problemas de rendimiento inicialmente, ahora comenzamos con un presupuesto generoso para los pods y lo reducimos posteriormente, vigilando de cerca el SLO. El lanzamiento de pods para el servicio Sidekiq se ha acelerado significativamente y ahora tarda aproximadamente 40 segundos en promedio. <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/gitlab-org\/charts\/gitlab\/-\/issues\/1775\">Reduciendo el tiempo de lanzamiento de los pods<\/a><\/noindex> se han beneficiado tanto GitLab.com como nuestros usuarios de instalaciones autogestionadas que utilizan el chart oficial de Helm de GitLab.<\/p>\n<h2>Conclusi\u00f3n<\/h2>\n<p>\nDespu\u00e9s de migrar cada servicio, disfrutamos de las ventajas de usar Kubernetes en producci\u00f3n: despliegues de aplicaciones m\u00e1s r\u00e1pidos y seguros, escalabilidad y una distribuci\u00f3n de recursos m\u00e1s eficiente. Adem\u00e1s, las ventajas de la migraci\u00f3n van m\u00e1s all\u00e1 del servicio GitLab.com. Cada mejora del chart oficial de Helm tambi\u00e9n beneficia a sus usuarios.<\/p>\n<p>Espero que hayas disfrutado la historia sobre nuestras aventuras con la migraci\u00f3n a Kubernetes. Seguimos trasladando nuevos servicios al cl\u00faster. Puedes obtener m\u00e1s informaci\u00f3n de las siguientes publicaciones:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/about.gitlab.com\/handbook\/engineering\/infrastructure\/production\/kubernetes\/gitlab-com\/\">\u00bfPor qu\u00e9 estamos migrando a 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 en Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/gitlab.com\/groups\/gitlab-com\/gl-infra\/-\/epics\/112\">\u00c9pico de migraci\u00f3n de GitLab.com a Kubernetes<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>P.D. del traductor<\/h2>\n<p>\nTambi\u00e9n puedes leer en nuestro blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/519962\/\">3 a\u00f1os con Kubernetes en producci\u00f3n: esto es lo que hemos aprendido<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/504396\/\">10 errores comunes al usar Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/335814\/\">Historias de \u00e9xito de Kubernetes en producci\u00f3n. Parte 3: GitHub<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440278\/\">La transici\u00f3n de Tinder a Kubernetes<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Fuente: <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\/es\/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=\"es_ES\" \/>\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\/es\/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\udd47Nuestras conclusiones tras un a\u00f1o de migraci\u00f3n de GitLab.com a Kubernetes | ProHoster","description":"Nota del traductor: se considera que la adaptaci\u00f3n de Kubernetes en GitLab es uno de los dos principales factores que contribuyen al crecimiento de la empresa.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/94977","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=94977"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/94977\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/94978"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=94977"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=94977"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=94977"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}