¡Hola a todos! Mi nombre es Pavel Agaletsky. Trabajo como líder de equipo en un equipo que desarrolla el sistema de entrega Lamoda. En 2018, hablé en la conferencia HighLoad++ y hoy me gustaría presentar una transcripción de mi informe.

Mi tema está dedicado a la experiencia de nuestra empresa en la implementación de sistemas y servicios en diferentes entornos. A partir de nuestros tiempos prehistóricos, cuando implementábamos todos los sistemas en servidores virtuales ordinarios, terminando con la transición gradual de Nomad a la implementación en Kubernetes. Te diré por qué lo hicimos y qué problemas tuvimos en el proceso.

Implementación de aplicaciones en VM

Comencemos con el hecho de que hace 3 años todos los sistemas y servicios de la empresa se implementaron en servidores virtuales normales. Técnicamente, estaba organizado de tal manera que todo el código de nuestros sistemas se almacenaba y ensamblaba mediante herramientas de ensamblaje automático, utilizando jenkins. Usando Ansible, se implementó desde nuestro sistema de control de versiones a servidores virtuales. Además, cada sistema que tenía nuestra empresa se implementó en al menos 2 servidores: uno de ellos en la cabecera y el segundo en la cola. Estos dos sistemas eran absolutamente idénticos entre sí en todos sus ajustes, potencia, configuración, etc. La única diferencia entre ellos era que head recibía tráfico de usuarios, mientras que tail nunca recibía tráfico de usuarios.

¿Para qué se hizo?

Cuando implementamos nuevas versiones de nuestra aplicación, queríamos garantizar una implementación perfecta, es decir, sin consecuencias perceptibles para los usuarios. Esto se logró debido al hecho de que la siguiente versión compilada usando Ansible se implementó al final. Allí, las personas que estuvieron involucradas en el despliegue pudieron comprobar y asegurarse de que todo estaba bien: todas las métricas, secciones y aplicaciones estaban funcionando; Se lanzan los scripts necesarios. Sólo cuando se convencieron de que todo estaba bien se cambió el tráfico. Empezó a ir al servidor que antes era tail. Y el que antes era el jefe permaneció sin tráfico de usuarios, aunque aún conservaba la versión anterior de nuestra aplicación.

Así que fue perfecto para los usuarios. Porque la conmutación es instantánea, ya que simplemente se cambia el equilibrador. Puede volver muy fácilmente a la versión anterior simplemente cambiando el balanceador. También pudimos verificar que la aplicación era capaz de producirse incluso antes de recibir tráfico de usuarios, lo cual fue bastante conveniente.

¿Qué ventajas vimos en todo esto?

1. Primero que nada, es suficiente. simplemente funciona. Todo el mundo entiende cómo funciona este esquema de implementación, porque la mayoría de las personas alguna vez lo han implementado en servidores virtuales normales.
2. Esto es suficiente confiablemente, ya que la tecnología de implementación es sencilla, probada por miles de empresas. Millones de servidores se implementan de esta manera. Es difícil romper algo.
3. Y finalmente pudimos conseguir despliegues atómicos. Implementaciones que ocurren simultáneamente para los usuarios, sin una etapa notable de cambio entre la versión anterior y la nueva.

Pero también vimos varias deficiencias en todo esto:

1. Además del entorno de producción, el entorno de desarrollo, existen otros entornos. Por ejemplo, control de calidad y preproducción. En aquel momento teníamos muchos servidores y unos 60 servicios. Por esta razón era necesario Para cada servicio, mantenga la última versión. máquina virtual. Además, si desea actualizar bibliotecas o instalar nuevas dependencias, debe hacerlo en todos los entornos. También necesitaba sincronizar la hora en la que va a implementar la próxima nueva versión de su aplicación con la hora en que Devops realiza la configuración del entorno necesaria. En este caso, es fácil llegar a una situación en la que nuestro entorno será algo diferente en todos los entornos a la vez. Por ejemplo, en un entorno de control de calidad habrá algunas versiones de bibliotecas, y en un entorno de producción habrá otras diferentes, lo que generará problemas.
2. Dificultad para actualizar dependencias su aplicación. No depende de ti, sino del otro equipo. Es decir, del equipo devops que mantiene los servidores. Debes darles una tarea adecuada y una descripción de lo que quieres hacer.
3. En ese momento, también queríamos dividir los grandes monolitos que teníamos en pequeños servicios separados, ya que entendíamos que cada vez habría más. En ese momento ya teníamos más de 100. Para cada nuevo servicio, era necesario crear una nueva máquina virtual separada, que también necesitaba ser mantenida e implementada. Además, no necesitas un coche, sino al menos dos. A todo esto se suma el entorno de control de calidad. Esto causa problemas y dificulta la creación y ejecución de nuevos sistemas. proceso complejo, caro y largo.

Por lo tanto, decidimos que sería más conveniente pasar de implementar máquinas virtuales normales a implementar nuestras aplicaciones en un contenedor acoplable. Si tiene Docker, necesita un sistema que pueda ejecutar la aplicación en un clúster, ya que no puede simplemente crear un contenedor. Por lo general, desea realizar un seguimiento de cuántos contenedores se levantan para que se levanten automáticamente. Por este motivo, necesitábamos seleccionar un sistema de control.

Pensamos durante mucho tiempo cuál podríamos elegir. El caso es que en aquel momento esta pila de implementación en servidores virtuales normales estaba algo desactualizada, ya que no contaban con las últimas versiones de los sistemas operativos. En algún momento, incluso apareció FreeBSD, cuyo soporte no era muy conveniente. Entendimos que necesitábamos migrar a Docker lo más rápido posible. Nuestros desarrolladores analizaron su experiencia existente con diferentes soluciones y eligieron un sistema como Nomad.

Cambiar a nómada

Nomad es un producto de HashiCorp. También son conocidos por sus otras soluciones:

"Cónsul" es una herramienta para el descubrimiento de servicios.

"Terraformar" - un sistema de gestión de servidores que permite configurarlos mediante configuración, la llamada infraestructura como código.

"Vagabundo" le permite implementar máquinas virtuales localmente o en la nube a través de archivos de configuración específicos.

Nomad en ese momento parecía una solución bastante simple a la que se podía cambiar rápidamente sin cambiar toda la infraestructura. Además, es bastante fácil de aprender. Por eso lo elegimos como sistema de filtración para nuestro contenedor.

¿Qué necesita para implementar su sistema en Nomad?

1. Primero que nada necesitas imagen de Docker su aplicación. Debe compilarlo y colocarlo en el repositorio de imágenes de la ventana acoplable. En nuestro caso, se trata de un artefacto, un sistema que le permite insertar varios artefactos de diferentes tipos en él. Puede almacenar archivos, imágenes de Docker, paquetes PHP de compositor, paquetes NPM, etc.
2. También se necesita archivo de configuración, que le indicará a Nomad qué, dónde y en qué cantidad desea implementar.

Cuando hablamos de Nomad, utiliza el lenguaje HCL como formato de archivo de información, que significa Lenguaje de configuración de HashiCorp. Este es un superconjunto de Yaml que le permite describir su servicio en términos de Nomad.

Le permite decir cuántos contenedores desea implementar y desde qué imágenes pasarles varios parámetros durante la implementación. Por lo tanto, usted alimenta este archivo a Nomad y éste lanza los contenedores a producción de acuerdo con él.

En nuestro caso, nos dimos cuenta de que simplemente escribir archivos HCL absolutamente idénticos para cada servicio no sería muy conveniente, porque hay muchos servicios y, a veces, es necesario actualizarlos. Sucede que un servicio no se implementa en una instancia, sino en varias instancias diferentes. Por ejemplo, uno de los sistemas que tenemos en producción tiene más de 100 instancias en producción. Se ejecutan a partir de las mismas imágenes, pero difieren en los ajustes de configuración y los archivos de configuración.

Por lo tanto, decidimos que sería conveniente para nosotros almacenar todos nuestros archivos de configuración para su implementación en un repositorio común. De esta manera eran visibles: eran fáciles de mantener y podíamos ver qué sistemas teníamos. Si es necesario, también es fácil actualizar o cambiar algo. Agregar un nuevo sistema tampoco es difícil: solo necesita crear un archivo de configuración dentro del nuevo directorio. En su interior se encuentran los siguientes archivos: service.hcl, que contiene una descripción de nuestro servicio, y algunos archivos env que permiten configurar este mismo servicio, que se implementa en producción.

Sin embargo, algunos de nuestros sistemas se implementan en producción no en una copia, sino en varias a la vez. Por lo tanto, decidimos que sería conveniente para nosotros almacenar no las configuraciones en su forma pura, sino en forma de plantilla. Y elegimos jinja 2. En este formato, almacenamos tanto las configuraciones del servicio como los archivos env necesarios para ello.

Además, hemos colocado en el repositorio un script de implementación común a todos los proyectos, que le permite iniciar e implementar su servicio en producción, en el entorno deseado, en el objetivo deseado. En el caso en que convertimos nuestra configuración HCL en una plantilla, el archivo HCL, que antes era una configuración Nomad normal, en este caso comenzó a verse un poco diferente.

Es decir, reemplazamos algunas variables de ubicación de configuración con variables insertadas que se toman de archivos env u otras fuentes. Además, tenemos la oportunidad de recopilar archivos HCL de forma dinámica, es decir, podemos utilizar no solo inserciones de variables ordinarias. Dado que jinja admite bucles y condiciones, también puede crear archivos de configuración allí, que cambian dependiendo de dónde implemente exactamente sus aplicaciones.

Por ejemplo, desea implementar su servicio en preproducción y producción. Digamos que en preproducción no desea ejecutar scripts cron, sino que solo desea ver el servicio en un dominio separado para asegurarse de que esté funcionando. Para cualquiera que implemente el servicio, el proceso parece muy simple y transparente. Todo lo que necesita hacer es ejecutar el archivo implementar.sh, especificar qué servicio desea implementar y en qué destino. Por ejemplo, desea implementar un determinado sistema en Rusia, Bielorrusia o Kazajstán. Para hacer esto, simplemente cambie uno de los parámetros y tendrá el archivo de configuración correcto.

Cuando el servicio Nomad ya está implementado en su clúster, se ve así.

Primero, necesita algún tipo de equilibrador externo que reciba todo el tráfico de usuarios. Trabajará junto con Consul y descubrirá dónde, en qué nodo y en qué dirección IP se encuentra un servicio específico que corresponde a un nombre de dominio en particular. Los servicios en Consul provienen del propio Nomad. Al ser productos de la misma empresa, están bastante relacionados entre sí. Podemos decir que Nomad listo para usar puede registrar todos los servicios iniciados dentro de Consul.

Una vez que su balanceador de carga front-end sabe a qué servicio enviar tráfico, lo reenvía al contenedor apropiado o a varios contenedores que coincidan con su aplicación. Naturalmente, también hay que pensar en la seguridad. Aunque todos los servicios se ejecutan en las mismas máquinas virtuales en contenedores, esto generalmente requiere impedir el libre acceso de un servicio a otro. Lo logramos a través de la segmentación. Cada servicio se lanzó en su propia red virtual, en la que se prescribieron reglas de enrutamiento y reglas para permitir/denegar el acceso a otros sistemas y servicios. Podrían ubicarse tanto dentro de este grupo como fuera de él. Por ejemplo, si desea evitar que un servicio se conecte a una base de datos específica, puede hacerlo mediante la segmentación a nivel de red. Es decir, incluso por error, no puede conectarse accidentalmente desde el entorno de prueba a su base de datos de producción.

¿Cuánto nos costó la transición en términos de recursos humanos?

La transición de toda la empresa a Nomad tardó aproximadamente entre 5 y 6 meses. Avanzamos servicio por servicio, pero a un ritmo bastante rápido. Cada equipo tuvo que crear sus propios contenedores para los servicios.

Hemos adoptado un enfoque tal que cada equipo es responsable de las imágenes acoplables de sus sistemas de forma independiente. DevOps proporciona la infraestructura general necesaria para la implementación, es decir, soporte para el clúster en sí, soporte para el sistema CI, etc. Y en ese momento, teníamos más de 60 sistemas trasladados a Nomad, lo que equivalía a unos 2 mil contenedores.

Devops es responsable de la infraestructura general de todo lo relacionado con implementación y servidores. Y cada equipo de desarrollo, a su vez, es responsable de implementar contenedores para su sistema específico, ya que es el equipo el que sabe lo que generalmente necesita en un contenedor en particular.

Razones para abandonar Nomad

¿Qué ventajas obtuvimos al cambiar al despliegue usando Nomad y Docker, entre otros?

1. nosotros proporcionó igualdad de condiciones para todos los ambientes. En desarrollo, entorno de control de calidad, preproducción, producción, se utilizan las mismas imágenes de contenedor, con las mismas dependencias. En consecuencia, prácticamente no tiene ninguna posibilidad de que lo que termine en producción no sea lo que probó previamente localmente o en su entorno de prueba.
2. También encontramos que es suficiente fácil de agregar un nuevo servicio. Desde el punto de vista de la implementación, cualquier sistema nuevo se lanza de manera muy sencilla. Simplemente vaya al repositorio que almacena las configuraciones, agregue allí otra configuración para su sistema y estará listo. Puede implementar su sistema en producción sin ningún esfuerzo adicional por parte de los desarrolladores.
3. todos Archivos de configuración en un repositorio común resultó estar bajo revisión. En el momento en que implementamos nuestros sistemas usando servidores virtuales, usábamos Ansible, en el que las configuraciones estaban en el mismo repositorio. Sin embargo, para la mayoría de los desarrolladores fue un poco más difícil trabajar con esto. Aquí el volumen de configuraciones y código que necesita agregar para implementar el servicio se ha vuelto mucho menor. Además, es muy fácil para los desarrolladores arreglarlo o cambiarlo. En caso de transiciones, por ejemplo, a una nueva versión de Nomad, pueden tomar y actualizar de forma masiva todos los archivos operativos ubicados en el mismo lugar.

Pero también nos encontramos con varias desventajas:

Resultó que nosotros no se pudieron lograr implementaciones fluidas en el caso de Nómada. Al desplegar contenedores en diferentes condiciones, podía resultar que estuviera en funcionamiento y Nomad lo percibió como un contenedor listo para recibir tráfico. Esto sucedió antes de que la aplicación que contenía tuviera siquiera la oportunidad de iniciarse. Por esta razón, el sistema comenzó a producir 500 errores por un corto período de tiempo, porque el tráfico comenzó a dirigirse a un contenedor que aún no estaba listo para aceptarlo.

Nos encontramos con algunos insectos. El error más importante es que Nomad no maneja muy bien un clúster grande si tiene muchos sistemas y contenedores. Cuando desee sacar uno de los servidores incluidos en el clúster Nomad para realizar tareas de mantenimiento, existe una probabilidad bastante alta de que el clúster no se sienta muy bien y se desmorone. Algunos contenedores pueden, por ejemplo, caerse y no levantarse; esto le costará mucho más adelante si todos sus sistemas de producción están ubicados en un clúster administrado por Nomad.

Así que decidimos pensar hacia dónde deberíamos ir a continuación. En ese momento tomamos mucha más conciencia de lo que queríamos lograr. Es decir: queremos confiabilidad, un poco más de funciones de las que ofrece Nomad y un sistema más maduro y estable.

En este sentido, nuestra elección recayó en Kubernetes como la plataforma más popular para lanzar clústeres. Sobre todo porque el tamaño y el número de nuestros contenedores eran bastante grandes. Para tales propósitos, Kubernetes parecía ser el sistema más adecuado que podíamos considerar.

Transición a Kubernetes

Te contaré un poco sobre los conceptos básicos de Kubernetes y en qué se diferencian de Nomad.

En primer lugar, el concepto más básico de Kubernetes es el concepto de pod. Vaina es un grupo de uno o más contenedores que siempre funcionan juntos. Y siempre funcionan como si estuvieran estrictamente en una máquina virtual. Son accesibles entre sí a través de IP 127.0.0.1 en diferentes puertos.

Supongamos que tiene una aplicación PHP que consta de nginx y php-fpm, el esquema clásico. Lo más probable es que desees mantener juntos los contenedores nginx y php-fpm en todo momento. Kubernetes le permite lograr esto describiéndolos como un pod común. Esto es exactamente lo que no pudimos conseguir con Nomad.

El segundo concepto es despliegue. El hecho es que la cápsula en sí es algo efímero: comienza y desaparece. ¿Quiere eliminar primero todos sus contenedores anteriores y luego lanzar nuevas versiones a la vez, o desea implementarlos gradualmente? Este es el proceso del que es responsable el concepto de implementación. Describe cómo implementas tus pods, en qué cantidad y cómo actualizarlos.

El tercer concepto es de coches. Su servicio es en realidad su sistema, que recibe algo de tráfico y luego lo reenvía a uno o más pods correspondientes a su servicio. Es decir, le permite decir que todo el tráfico entrante a tal o cual servicio con tal o cual nombre debe enviarse a estos pods específicos. Y al mismo tiempo te proporciona equilibrio de tráfico. Es decir, puede iniciar dos pods de su aplicación y todo el tráfico entrante se equilibrará equitativamente entre los pods relacionados con este servicio.

Y el cuarto concepto básico es Ingreso. Este es un servicio que se ejecuta en un clúster de Kubernetes. Actúa como un equilibrador de carga externo que se hace cargo de todas las solicitudes. Utilizando la API de Kubernetes, Ingress puede determinar dónde deben enviarse estas solicitudes. Además, lo hace con mucha flexibilidad. Puede decir que todas las solicitudes a este host y tal o cual URL se envían a este servicio. Y estas solicitudes que llegan a este host y a otra URL se envían a otro servicio.

Lo mejor desde el punto de vista de alguien que desarrolla una aplicación es que puedes gestionarla toda tú mismo. Al configurar la configuración de Ingress, puede enviar todo el tráfico que llega a tal o cual API a contenedores separados escritos, por ejemplo, en Go. Pero este tráfico, que llega al mismo dominio, pero a una URL diferente, debe enviarse a contenedores escritos en PHP, donde hay mucha lógica, pero no son muy rápidos.

Si comparamos todos estos conceptos con Nomad, podemos decir que los tres primeros conceptos son todos juntos Servicio. Y el último concepto está ausente en el propio Nomad. Usamos un balanceador externo: podría ser haproxy, nginx, nginx+, etc. En el caso de un cubo, no es necesario introducir este concepto adicional por separado. Sin embargo, si observa Ingress internamente, es nginx, haproxy o traefik, pero está integrado en Kubernetes.

Todos los conceptos que describí son, de hecho, recursos que existen dentro de un clúster de Kubernetes. Para describirlos en el cubo se utiliza el formato yaml, que es más legible y familiar que los archivos HCL en el caso de Nomad. Pero estructuralmente describen lo mismo en el caso de, por ejemplo, pod. Dicen: quiero desplegar allí tal o cual cápsula, con tal o cual imagen, en tal o cual cantidad.

Además, nos dimos cuenta de que no queríamos crear cada recurso individual a mano: implementación, servicios, Ingress, etc. En cambio, queríamos describir cada uno de nuestros sistemas en términos de Kubernetes durante la implementación, para no tener que recrear manualmente todas las dependencias de recursos necesarias en el orden correcto. Se eligió Helm como el sistema que nos permitió hacer esto.

Conceptos básicos en Helm

El timón es gerente de empaquetación para Kubernetes. Es muy similar a cómo funcionan los gestores de paquetes en los lenguajes de programación. Le permiten almacenar un servicio que consta, por ejemplo, de implementación nginx, implementación php-fpm, configuración para Ingress, configmaps (esta es una entidad que le permite configurar env y otros parámetros para su sistema) en la forma de así: llamados gráficos. Al mismo tiempo, timón se ejecuta sobre Kubernetes. Es decir, no se trata de una especie de sistema al margen, sino de un servicio más lanzado dentro del cubo. Interactúas con él a través de su API mediante un comando de consola. Su conveniencia y belleza es que incluso si helm se rompe o lo elimina del clúster, sus servicios no desaparecerán, ya que helm esencialmente solo sirve para iniciar el sistema. El propio Kubernetes es entonces responsable del rendimiento y el estado de los servicios.

También nos dimos cuenta de que plantilla, que anteriormente nos vimos obligados a hacer nosotros mismos al introducir jinja en nuestras configuraciones, es una de las características principales de helm. Todas las configuraciones que crea para sus sistemas se almacenan en helm en forma de plantillas, un poco similares a jinja, pero, de hecho, utilizan las plantillas del lenguaje Go, en el que está escrito helm, como Kubernetes.

Helm nos agrega algunos conceptos más.

Tabla - esta es una descripción de su servicio. En otros gestores de paquetes se llamaría paquete, paquete o algo similar. Aquí se llama gráfico.

Valores son las variables que desea utilizar para crear sus configuraciones a partir de plantillas.

tortugitas. Cada vez que un servicio que se implementa mediante helm recibe una versión incremental de la versión. Helm recuerda cuál era la configuración del servicio en la versión anterior, la versión anterior, etc. Por lo tanto, si necesita revertir, simplemente ejecute el comando de devolución de llamada helm, apuntándolo a la versión anterior. Incluso si la configuración correspondiente en su repositorio no está disponible en el momento de la reversión, helm aún recordará cuál era y revertirá su sistema al estado en el que se encontraba en la versión anterior.

En el caso de que usemos helm, las configuraciones habituales de Kubernetes también se convierten en plantillas en las que es posible utilizar variables, funciones y aplicar declaraciones condicionales. De esta manera puede recopilar la configuración de su servicio según el entorno.

En la práctica, decidimos hacer las cosas un poco diferente a como lo hicimos con Nomad. Si en Nomad tanto las configuraciones de implementación como las n variables necesarias para implementar nuestro servicio se almacenaban en un repositorio, aquí decidimos dividirlas en dos repositorios separados. El repositorio de "implementación" almacena solo las n variables necesarias para la implementación, y el repositorio de "timón" almacena configuraciones o gráficos.

¿Qué nos dio esto?

A pesar de que no almacenamos ningún dato realmente sensible en los propios archivos de configuración. Por ejemplo, contraseñas de bases de datos. Se almacenan como secretos en Kubernetes, pero, sin embargo, todavía hay ciertas cosas a las que no queremos que todos tengan acceso. Por lo tanto, el acceso al repositorio de “implementación” es más limitado y el repositorio de “helm” simplemente contiene una descripción del servicio. Por este motivo, un mayor número de personas pueden acceder a él de forma segura.

Dado que no solo tenemos entornos de producción, sino también otros, gracias a esta separación podemos reutilizar nuestros gráficos de timón para implementar servicios no solo en producción, sino también, por ejemplo, en un entorno de control de calidad. Incluso para implementarlos localmente usando Minikube - esto es para ejecutar Kubernetes localmente.

Dentro de cada repositorio, dejamos una división en directorios separados para cada servicio. Es decir, dentro de cada directorio hay plantillas relacionadas con el gráfico correspondiente y que describen los recursos que se deben implementar para iniciar nuestro sistema. Solo dejamos envs en el repositorio de "implementación". En este caso, no utilizamos plantillas usando jinja, porque el propio helm proporciona plantillas listas para usar; esta es una de sus funciones principales.

Dejamos un script de implementación: implementar.sh, que simplifica y estandariza el inicio de la implementación usando helm. Entonces, para cualquiera que quiera implementar, la interfaz de implementación se ve exactamente igual que cuando se implementó a través de Nomad. Lo mismo implementar.sh, el nombre de su servicio y dónde desea implementarlo. Esto hace que el timón se inicie internamente. Este, a su vez, recopila configuraciones de plantillas, inserta los archivos de valores necesarios en ellas, luego las implementa y las ejecuta en Kubernetes.

Hallazgos

El servicio Kubernetes parece ser más complejo que Nomad.

Aquí el tráfico saliente llega a Ingress. Este es solo el controlador frontal, que se hace cargo de todas las solicitudes y posteriormente las envía a los servicios correspondientes a los datos de la solicitud. Los determina en función de las configuraciones que forman parte de la descripción de su aplicación en helm y que los desarrolladores configuran por su cuenta. El servicio envía solicitudes a sus pods, es decir, contenedores específicos, equilibrando el tráfico entrante entre todos los contenedores que pertenecen a este servicio. Y, por supuesto, no debemos olvidar que no debemos alejarnos de la seguridad a nivel de red. Por tanto, la segmentación funciona en un clúster de Kubernetes, que se basa en el etiquetado. Todos los servicios tienen ciertas etiquetas a las que están asociados los derechos de acceso de los servicios a ciertos recursos externos/internos dentro o fuera del clúster.

A medida que hicimos la transición, vimos que Kubernetes tenía todas las capacidades de Nomad, que habíamos usado anteriormente, y también agregamos muchas cosas nuevas. Se puede ampliar mediante complementos y, de hecho, mediante tipos de recursos personalizados. Es decir, tiene la oportunidad no solo de usar algo que viene con Kubernetes listo para usar, sino de crear su propio recurso y servicio que leerá su recurso. Esto le brinda opciones adicionales para expandir su sistema sin tener que reinstalar Kubernetes y sin requerir modificaciones.

Un ejemplo de tal uso es Prometheus, que se ejecuta dentro de nuestro clúster de Kubernetes. Para que comience a recopilar métricas de un servicio en particular, debemos agregar un tipo adicional de recurso, el llamado monitor de servicio, a la descripción del servicio. Prometheus, debido al hecho de que puede leer un tipo de recurso personalizado cuando se inicia en Kubernetes, comienza automáticamente a recopilar métricas del nuevo sistema. Es bastante conveniente.

La primera implementación que hicimos en Kubernetes fue en marzo de 2018. Y durante este tiempo nunca tuvimos ningún problema con él. Funciona de manera bastante estable y sin errores importantes. Además, podemos ampliarlo aún más. Hoy tenemos suficientes capacidades que tiene y nos gusta mucho el ritmo de desarrollo de Kubernetes. Actualmente, hay más de 3000 contenedores en Kubernetes. El cluster ocupa varios Nodos. Al mismo tiempo, es útil, estable y muy controlable.

Fuente: habr.com