Ola a todos! Chámome Pavel Agaletsky. Traballo como xefe de equipo nun equipo que desenvolve o sistema de entrega Lamoda. En 2018, falei na conferencia HighLoad++ e hoxe gustaríame presentar unha transcrición do meu informe.

O meu tema está dedicado á experiencia da nosa empresa na implantación de sistemas e servizos en diferentes contornas. A partir dos nosos tempos prehistóricos, cando despregamos todos os sistemas en servidores virtuais comúns, rematando coa transición gradual de Nomad á implantación en Kubernetes. Vouvos contar por que o fixemos e que problemas tivemos no proceso.

Implementación de aplicacións en VM

Comecemos co feito de que hai 3 anos todos os sistemas e servizos da empresa foron implantados en servidores virtuais habituais. Tecnicamente, organizouse de forma que todo o código dos nosos sistemas fose almacenado e ensamblado mediante ferramentas de montaxe automáticas, utilizando jenkins. Usando Ansible, lanzouse desde o noso sistema de control de versións a servidores virtuais. Ademais, cada sistema que tiña a nosa empresa despregábase en polo menos 2 servidores: un deles na cabeza, o segundo na cola. Estes dous sistemas eran absolutamente idénticos entre si en todas as súas configuracións, potencia, configuración, etc. A única diferenza entre eles era que a cabeza recibía tráfico de usuarios, mentres que tail nunca recibiu tráfico de usuarios.

Por que se fixo isto?

Cando despregamos novas versións da nosa aplicación, queriamos garantir un lanzamento fluido, é dicir, sen consecuencias perceptibles para os usuarios. Isto conseguiuse debido ao feito de que a próxima versión compilada usando Ansible foi lanzada ata o final. Alí, as persoas que participaron no despregamento podían comprobar e asegurarse de que todo estaba ben: todas as métricas, seccións e aplicacións funcionaban; lánzanse os scripts necesarios. Só despois de que estiveron convencidos de que todo estaba ben, cambiouse o tráfico. Comezou a ir ao servidor que antes era tail. E a que antes era a cabeza quedou sen tráfico de usuarios, aínda que tiña a versión anterior da nosa aplicación.

Polo tanto, foi perfecto para os usuarios. Porque a conmutación é instantánea, xa que simplemente é cambiar o equilibrador. Podes volver á versión anterior moi facilmente cambiando o equilibrador. Tamén puidemos verificar que a aplicación era capaz de producirse mesmo antes de recibir tráfico de usuarios, o que era bastante cómodo.

Que vantaxes vimos en todo isto?

1. En primeiro lugar, é suficiente só funciona. Todo o mundo entende como funciona ese esquema de implantación, porque a maioría da xente xa se implantou en servidores virtuais habituais.
2. Isto é suficiente de forma fiable, xa que a tecnoloxía de implantación é sinxela, probada por miles de empresas. Deste xeito despréganse millóns de servidores. É difícil romper algo.
3. E por fin puidemos conseguir despregamentos atómicos. Implantacións que se producen simultáneamente para os usuarios, sen unha etapa notable de cambio entre a versión antiga e a nova.

Pero tamén vimos varias deficiencias en todo isto:

1. Ademais do ambiente de produción, o ambiente de desenvolvemento, hai outros ambientes. Por exemplo, qa e preprodución. Daquela tiñamos moitos servidores e uns 60 servizos. Por iso foi necesario para cada servizo, manteña a versión máis recente para el máquina virtual. Ademais, se queres actualizar bibliotecas ou instalar novas dependencias, cómpre facelo en todos os ambientes. Tamén necesitaba sincronizar a hora na que vai implementar a próxima nova versión da súa aplicación coa hora en que devops realiza a configuración do contorno necesaria. Neste caso, é fácil entrar nunha situación na que o noso entorno será algo diferente en todos os ambientes á vez. Por exemplo, nun ambiente de control de calidade haberá algunhas versións de bibliotecas, e nun ambiente de produción haberá outras diferentes, o que dará lugar a problemas.
2. Dificultade para actualizar dependencias a súa aplicación. Non depende de ti, senón do outro equipo. É dicir, do equipo devops que mantén os servidores. Debes darlles unha tarefa adecuada e unha descrición do que queres facer.
3. Daquela tamén queriamos dividir os grandes monolitos que tiñamos en pequenos servizos separados, xa que entendiamos que cada vez serían máis. Nese momento, xa tiñamos máis de 100. Para cada novo servizo, era necesario crear unha nova máquina virtual separada, que tamén tiña que ser mantida e implantada. Ademais, non necesitas un coche, senón polo menos dous. A todo isto súmase o ambiente de control de calidade. Isto causa problemas e dificulta a creación e a execución de novos sistemas. proceso complexo, caro e longo.

Polo tanto, decidimos que sería máis conveniente pasar de implementar máquinas virtuais habituais a implementar as nosas aplicacións nun contedor docker. Se tes docker, necesitas un sistema que poida executar a aplicación nun clúster, xa que non podes crear un contedor. Normalmente quere facer un seguimento de cantos contedores se levantan para que se levanten automaticamente. Por este motivo, necesitabamos seleccionar un sistema de control.

Durante moito tempo pensamos cal podíamos tomar. O caso é que naquel momento esta pila de despregamento nos servidores virtuais comúns estaba algo desfasada, xa que non tiñan as últimas versións dos sistemas operativos. Nalgún momento, incluso houbo FreeBSD, que non era moi cómodo de soportar. Entendemos que necesitabamos migrar a Docker o máis rápido posible. Os nosos devops analizaron a súa experiencia existente con diferentes solucións e escolleron un sistema como Nomad.

Cambia a Nomad

Nomad é un produto de HashiCorp. Tamén son coñecidos polas súas outras solucións:

"cónsul" é unha ferramenta para o descubrimento de servizos.

"Terraforma" - un sistema de xestión de servidores que permite configuralos mediante a configuración, a chamada infraestrutura-as-a-code.

"Vagante" permítelle implantar máquinas virtuais localmente ou na nube mediante ficheiros de configuración específicos.

Nomad naquel momento parecía unha solución bastante sinxela á que se podía cambiar rapidamente sen cambiar toda a infraestrutura. Ademais, é bastante fácil de aprender. É por iso que o eliximos como sistema de filtración do noso recipiente.

Que necesitas para implementar o teu sistema en Nomad?

1. En primeiro lugar, necesitas imaxe docker a súa aplicación. Debes crealo e colocalo no repositorio de imaxes docker. No noso caso, este é un artefacto, un sistema que che permite introducir nela varios artefactos de diferentes tipos. Pode almacenar arquivos, imaxes docker, paquetes PHP de compositor, paquetes NPM, etc.
2. Tamén é necesario ficheiro de configuración, que lle dirá a Nomad que, onde e en que cantidade quere implantar.

Cando falamos de Nomad, usa a linguaxe HCL como o seu formato de ficheiro de información, o que significa Linguaxe de configuración de HashiCorp. Este é un superconxunto de Yaml que che permite describir o teu servizo en termos Nomad.

Permíteche dicir cantos contedores queres despregar, desde que imaxes pasarlles varios parámetros durante a implantación. Así, alimentas este ficheiro a Nomad, e este lanza contedores en produción segundo el.

No noso caso, decatámonos de que simplemente escribir ficheiros HCL absolutamente idénticos para cada servizo non sería moi cómodo, porque hai moitos servizos e ás veces queres actualizalos. Acontece que un servizo non se implanta nunha instancia, senón nunha variedade de diferentes. Por exemplo, un dos sistemas que temos en produción ten máis de 100 instancias en produción. Funcionan a partir das mesmas imaxes, pero difiren en axustes de configuración e ficheiros de configuración.

Polo tanto, decidimos que sería conveniente para nós almacenar todos os nosos ficheiros de configuración para a súa implantación nun repositorio común. Deste xeito eran visibles: eran fáciles de manter e podíamos ver que sistemas tiñamos. Se é necesario, tamén é fácil actualizar ou cambiar algo. Engadir un novo sistema tampouco é difícil: só tes que crear un ficheiro de configuración dentro do novo directorio. No seu interior atópanse os seguintes ficheiros: service.hcl, que contén unha descrición do noso servizo, e algúns ficheiros env que permiten configurar este mesmo servizo, sendo despregado en produción.

Non obstante, algúns dos nosos sistemas están implantados en produción non nunha copia, senón en varias á vez. Polo tanto, decidimos que sería conveniente para nós almacenar non as configuracións na súa forma pura, senón a súa forma modelo. E escollemos xenia 2. Neste formato, almacenamos tanto as configuracións do propio servizo como os ficheiros env necesarios para iso.

Ademais, colocamos no repositorio un script de despregamento común a todos os proxectos, que che permite lanzar e implantar o teu servizo en produción, no entorno desexado, no destino desexado. No caso en que convertemos a nosa configuración HCL nun modelo, entón o ficheiro HCL, que antes era unha configuración normal de Nomad, neste caso comezou a parecer un pouco diferente.

É dicir, substituímos algunhas variables de localización de configuración por variables inseridas que se toman de ficheiros env ou doutras fontes. Ademais, tivemos a oportunidade de recoller ficheiros HCL de forma dinámica, é dicir, podemos usar non só insercións de variables comúns. Dado que jinja admite bucles e condicións, tamén pode crear ficheiros de configuración alí, que cambian dependendo de onde se implemente exactamente as súas aplicacións.

Por exemplo, quere implantar o seu servizo en preprodución e produción. Digamos que na preprodución non queres executar scripts cron, senón que só queres ver o servizo nun dominio separado para asegurarte de que funciona. Para quen despregue o servizo, o proceso parece moi sinxelo e transparente. Todo o que cómpre facer é executar o ficheiro deploy.sh, especificar que servizo quere implantar e para que destino. Por exemplo, quere implantar un determinado sistema en Rusia, Bielorrusia ou Casaquistán. Para iso, basta con cambiar un dos parámetros e terás o ficheiro de configuración correcto.

Cando o servizo Nomad xa está implantado no teu clúster, ten este aspecto.

En primeiro lugar, necesitas algún tipo de equilibrador externo, que recibirá todo o tráfico de usuarios. Traballará en conxunto con Consul e descubrirá desde el onde, en que nodo, en que enderezo IP se atopa un servizo específico que corresponde a un determinado nome de dominio. Os servizos en Cónsul veñen do propio Nomad. Dado que se trata de produtos da mesma empresa, están bastante relacionados entre si. Podemos dicir que Nomad fóra da caixa pode rexistrar todos os servizos postos en marcha nel dentro de Consul.

Unha vez que o teu equilibrador de carga front-end sabe a que servizo enviar o tráfico, envíao ao contedor adecuado ou a varios contedores que coincidan coa túa aplicación. Por suposto, tamén hai que pensar na seguridade. Aínda que todos os servizos se executan nas mesmas máquinas virtuais en contedores, isto normalmente require impedir o acceso gratuíto de calquera servizo a calquera outro. Conseguimos isto mediante a segmentación. Cada servizo lanzouse na súa propia rede virtual, na que se prescribían regras de enrutamento e regras para permitir/negar o acceso a outros sistemas e servizos. Poderían situarse tanto dentro deste clúster como fóra del. Por exemplo, se quere evitar que un servizo se conecte a unha base de datos específica, pódese facer mediante a segmentación a nivel de rede. É dicir, mesmo por erro, non pode conectarse accidentalmente desde o ambiente de proba á súa base de datos de produción.

Canto nos custou a transición en recursos humanos?

A transición de toda a empresa a Nomad levou aproximadamente 5-6 meses. Movémonos servizo por servizo, pero a un ritmo bastante rápido. Cada equipo tivo que crear os seus propios contedores para os servizos.

Adoptamos tal enfoque que cada equipo é responsable das imaxes docker dos seus sistemas de forma independente. DevOps proporciona a infraestrutura xeral necesaria para a implantación, é dicir, soporte para o propio clúster, soporte para o sistema CI, etc. E naquel momento, tivemos máis de 60 sistemas trasladados a Nomad, o que ascendía a uns 2 mil colectores.

Devops é responsable da infraestrutura xeral de todo o relacionado coa implantación e os servidores. E cada equipo de desenvolvemento, pola súa banda, encárgase de implantar contedores para o seu sistema específico, xa que é o equipo quen sabe o que necesita xeralmente nun determinado contedor.

Motivos para abandonar Nomad

Que vantaxes obtivemos ao cambiar ao despregamento mediante Nomad e Docker, entre outros?

1. Nós proporcionando condicións iguais para todos os ambientes. No desenvolvemento, ambiente QA, preprodución, produción utilízanse as mesmas imaxes de contedores, coas mesmas dependencias. En consecuencia, practicamente non tes ningunha posibilidade de que o que acabe na produción non sexa o que probaches anteriormente localmente ou no teu ambiente de proba.
2. Tamén descubrimos que é suficiente fácil de engadir un novo servizo. Desde o punto de vista do despregue, calquera novo sistema lánzase de forma moi sinxela. Só tes que ir ao repositorio que almacena as configuracións, engade alí outra configuración para o teu sistema e xa está todo listo. Podes implementar o teu sistema en produción sen ningún esforzo adicional dos devops.
3. Todos ficheiros de configuración nun repositorio común resultou estar en revisión. No momento en que implantamos os nosos sistemas mediante servidores virtuais, utilizamos Ansible, no que as configuracións estaban no mesmo repositorio. Non obstante, para a maioría dos desenvolvedores isto foi un pouco máis difícil de traballar. Aquí o volume de configuracións e código que cómpre engadir para implementar o servizo fíxose moito menor. Ademais, para os devops é moi sinxelo arranxalo ou cambialo. En caso de transicións, por exemplo, a unha nova versión de Nomad, poden levar e actualizar masivamente todos os ficheiros operativos situados no mesmo lugar.

Pero tamén atopamos varias desvantaxes:

Resultou que nós non se puido lograr despregamentos sen fisuras no caso de Nomad. Ao lanzar contedores en diferentes condicións, podería resultar en funcionamento e Nomad percibíao como un contedor preparado para recibir tráfico. Isto ocorreu antes de que a aplicación que tiña dentro tivese a oportunidade de lanzarse. Por este motivo, o sistema comezou a producir 500 erros durante un breve período de tempo, porque o tráfico comezou a dirixirse a un contedor que aínda non estaba preparado para aceptalo.

Encontrámonos con algúns erros. O erro máis significativo é que Nomad non manexa moi ben un clúster grande se tes moitos sistemas e contedores. Cando queres sacar un dos servidores incluídos no clúster Nomad para o mantemento, hai unha probabilidade bastante alta de que o clúster non se sinta moi ben e se desmorone. Algúns contedores poden, por exemplo, caer e non subir; isto custaráche moito máis tarde se todos os teus sistemas de produción están situados nun clúster xestionado por Nomad.

Así que decidimos pensar a onde deberíamos ir a continuación. Nese momento, fomos moito máis conscientes do que queriamos conseguir. A saber: queremos fiabilidade, un pouco máis de funcións das que proporciona Nomad e un sistema máis maduro e estable.

Neste sentido, a nosa elección recaeu en Kubernetes como a plataforma máis popular para lanzar clusters. Sobre todo tendo en conta que o tamaño e número dos nosos contedores era o suficientemente grande. Para tales fins, Kubernetes parecía ser o sistema máis axeitado que podíamos ver.

Transición a Kubernetes

Vouche falar un pouco sobre os conceptos básicos de Kubernetes e como se diferencian de Nomad.

En primeiro lugar, o concepto máis básico en Kubernetes é o concepto de pod. Vagem é un grupo dun ou máis contedores que sempre funcionan xuntos. E sempre funcionan coma se fosen estrictamente nunha máquina virtual. Son accesibles entre si a través de IP 127.0.0.1 en diferentes portos.

Supoñamos que tes unha aplicación PHP que consta de nginx e php-fpm, o esquema clásico. O máis probable é que queira manter os contedores nginx e php-fpm xuntos en todo momento. Kubernetes permíteche conseguir isto describindoos como un pod común. Isto é exactamente o que non puidemos conseguir con Nomad.

O segundo concepto é desenvolvemento. O caso é que a vaina en si é algo efémero, comeza e desaparece. Queres matar primeiro todos os teus contedores anteriores e, a continuación, lanzar novas versións á vez, ou queres lanzalos gradualmente? Este é o proceso do que se encarga o concepto de despregamento. Describe como implementas os teus pods, en que cantidade e como actualizalos.

O terceiro concepto é servizo. O teu servizo é en realidade o teu sistema, que recibe algo de tráfico e despois o reenvía a un ou máis pods correspondentes ao teu servizo. É dicir, permite dicir que todo o tráfico entrante a tal ou cal servizo con tal nome debe enviarse a estes pods específicos. E ao mesmo tempo proporciónache o equilibrio do tráfico. É dicir, podes lanzar dous pods da túa aplicación e todo o tráfico entrante equilibrarase uniformemente entre os pods relacionados con este servizo.

E o cuarto concepto básico é Ingreso. Este é un servizo que se executa nun clúster de Kubernetes. Actúa como un equilibrador de carga externo que se fai cargo de todas as solicitudes. Usando a API de Kubernetes, Ingress pode determinar onde se deben enviar estas solicitudes. Ademais, faino de forma moi flexible. Podes dicir que todas as solicitudes a este host e tal ou cal URL son enviadas a este servizo. E estas solicitudes que chegan a este host e a outro URL envíanse a outro servizo.

O máis chulo desde o punto de vista de quen desenvolve unha aplicación é que podes xestionalo todo ti mesmo. Ao configurar a configuración de Ingress, pode enviar todo o tráfico que chegue a tal ou tal API a contedores separados escritos, por exemplo, en Go. Pero este tráfico, que chega ao mesmo dominio, pero a un URL diferente, debería enviarse a contedores escritos en PHP, onde hai moita lóxica, pero non son moi rápidos.

Se comparamos todos estes conceptos con Nomad, podemos dicir que os tres primeiros conceptos son todos xuntos Servizo. E o último concepto está ausente no propio Nomad. Usamos un equilibrador externo: podería ser haproxy, nginx, nginx+, etc. No caso dun cubo, non é necesario introducir este concepto adicional por separado. Non obstante, se observas Ingress internamente, é nginx, haproxy ou traefik, pero está integrado en Kubernetes.

Todos os conceptos que describín son, de feito, recursos que existen dentro dun clúster de Kubernetes. Para describilos no cubo utilízase un formato yaml, máis lexible e familiar que os ficheiros HCL no caso de Nomad. Pero estruturalmente describen o mesmo no caso de, por exemplo, pod. Din - quero despregar tal ou cal vainas alí, con tal ou cal imaxes, en tal ou cal cantidade.

Ademais, decatámonos de que non queriamos crear a man cada recurso individual: despregamento, servizos, Ingress, etc. Pola contra, queriamos describir cada un dos nosos sistemas en termos de Kubernetes durante a implantación, de modo que non teriamos que recrear manualmente todas as dependencias de recursos necesarias na orde correcta. Helm foi elixido como o sistema que nos permitiu facelo.

Conceptos básicos en Helm

Helm é xestor de paquetes para Kubernetes. É moi semellante a como funcionan os xestores de paquetes nas linguaxes de programación. Permítenche almacenar un servizo que consiste, por exemplo, en implementación nginx, implementación php-fpm, config para Ingress, configmaps (esta é unha entidade que che permite configurar env e outros parámetros para o teu sistema) en forma de so- chamados gráficos. Ao mesmo tempo Helm corre enriba de Kubernetes. É dicir, non se trata dun sistema de lado, senón dun servizo máis lanzado dentro do cubo. Interactúa con el a través da súa API mediante un comando de consola. A súa comodidade e beleza é que aínda que se rompa o timón ou o elimines do clúster, os teus servizos non desaparecerán, xa que o timón só serve esencialmente para iniciar o sistema. O propio Kubernetes é entón responsable do rendemento e do estado dos servizos.

Tamén nos demos conta diso modelización, que antes estabamos obrigados a facer nós mesmos introducindo jinja nas nosas configuracións, é unha das principais características de Helm. Todas as configuracións que creas para os teus sistemas gárdanse en helm en forma de modelos, un pouco parecidos a jinja, pero, de feito, usando a plantilla da linguaxe Go, na que helm está escrito, como Kubernetes.

Helm engade algúns conceptos máis para nós.

Gráfico - Esta é unha descrición do teu servizo. Noutros xestores de paquetes chamaríase paquete, paquete ou algo semellante. Aquí chámase gráfico.

Valores son as variables que queres usar para crear as túas configuracións a partir de modelos.

Solte. Cada vez que un servizo que se desprega mediante Helm recibe unha versión incremental da versión. Helm lembra cal era a configuración do servizo na versión anterior, a versión anterior, etc. Polo tanto, se precisas desfacer, só tes que executar o comando de devolución de chamada helm, apuntando á versión anterior. Aínda que a configuración correspondente no teu repositorio non estea dispoñible no momento da recuperación, Helm seguirá lembrando cal era e volverá a restaurar o teu sistema ao estado no que estaba na versión anterior.

No caso de usar helm, as configuracións habituais de Kubernetes tamén se converten en modelos nos que é posible usar variables, funcións e aplicar instrucións condicionais. Deste xeito, podes recoller a configuración do teu servizo dependendo da contorna.

Na práctica, decidimos facer as cousas un pouco diferente do que fixemos con Nomad. Se en Nomad tanto as configuracións de implementación como as n-variables necesarias para implementar o noso servizo estaban almacenadas nun repositorio, aquí decidimos dividilas en dous depósitos separados. O repositorio "desplegar" almacena só n-variables necesarias para a implantación, e o repositorio "helm" almacena configuracións ou gráficos.

Que nos deu isto?

A pesar de que non almacenamos datos realmente sensibles nos propios ficheiros de configuración. Por exemplo, contrasinais para bases de datos. Gárdanse como segredos en Kubernetes, pero, con todo, aínda hai certas cousas ás que non queremos que todos accedan. Polo tanto, o acceso ao repositorio "desplegar" é máis limitado e o repositorio "helm" simplemente contén unha descrición do servizo. Por este motivo, un abano máis amplo de persoas pode acceder a el con seguridade.

Dado que non só temos produción, senón tamén outros ambientes, grazas a esta separación podemos reutilizar os nosos gráficos de timón para implementar servizos non só na produción, senón tamén, por exemplo, nun ambiente de control de calidade. Incluso para implementalos localmente usando Minikube - Esta é unha cousa para executar Kubernetes localmente.

Dentro de cada repositorio, deixamos unha división en directorios separados para cada servizo. É dicir, dentro de cada directorio hai modelos relacionados co cadro correspondente e nos que se describen os recursos que hai que despregar para poñer en marcha o noso sistema. Deixamos só envs no repositorio "desplegar". Neste caso, non usamos modelos usando jinja, porque o propio helm ofrece modelos listos para usar, esta é unha das súas principais funcións.

Deixamos un script de implementación: deploy.sh, que simplifica e estandariza o lanzamento para a implementación mediante Helm. Polo tanto, para quen queira implementar, a interface de implementación ten exactamente o mesmo aspecto que cando se implementou a través de Nomad. O mesmo deploy.sh, o nome do teu servizo e onde queres implantalo. Isto fai que o timón se inicie internamente. Á súa vez, recompila configuracións dos modelos, insire neles os ficheiros de valores necesarios e, a continuación, implantaos, lanzándoos en Kubernetes.

Descubrimentos

O servizo de Kubernetes parece ser máis complexo que Nomad.

Aquí o tráfico saínte chega a Ingress. Este é só o controlador frontal, que se fai cargo de todas as solicitudes e, posteriormente, as envía aos servizos correspondentes aos datos da solicitude. Determínaos en función das configuracións que forman parte da descrición da túa aplicación en Helm e que os desenvolvedores establecen por si mesmos. O servizo envía solicitudes aos seus pods, é dicir, contedores específicos, equilibrando o tráfico entrante entre todos os contedores que pertencen a este servizo. E, por suposto, non debemos esquecer que non debemos ir a ningún lado da seguridade a nivel de rede. Polo tanto, a segmentación funciona nun clúster de Kubernetes, que se basea no etiquetado. Todos os servizos teñen determinadas etiquetas ás que están asociados os dereitos de acceso dos servizos a determinados recursos externos/internos dentro ou fóra do clúster.

Mentres fixemos a transición, vimos que Kubernetes tiña todas as capacidades de Nomad, que utilizabamos anteriormente, e tamén engadía moitas cousas novas. Pódese ampliar mediante complementos e, de feito, mediante tipos de recursos personalizados. É dicir, tes a oportunidade non só de usar algo que vén con Kubernetes fóra da caixa, senón de crear o teu propio recurso e servizo que lerá o teu recurso. Isto ofrécelle opcións adicionais para expandir o teu sistema sen ter que reinstalar Kubernetes e sen necesidade de modificacións.

Un exemplo deste uso é Prometheus, que se executa dentro do noso clúster de Kubernetes. Para que comece a recoller métricas dun servizo en particular, necesitamos engadir un tipo adicional de recurso, o chamado monitor de servizo, á descrición do servizo. Prometheus, debido ao feito de que pode ler un tipo de recurso personalizado cando se inicia en Kubernetes, comeza automaticamente a recoller métricas do novo sistema. É bastante cómodo.

A primeira implementación que fixemos en Kubernetes foi en marzo de 2018. E durante este tempo nunca tivemos ningún problema con el. Funciona de forma bastante estable sen erros significativos. Ademais, podemos amplialo aínda máis. Hoxe temos bastantes das capacidades que ten, e gústanos moito o ritmo de desenvolvemento de Kubernetes. Actualmente, hai máis de 3000 contedores en Kubernetes. O clúster ocupa varios Nodos. Ao mesmo tempo, é útil, estable e moi controlable.

Fonte: www.habr.com