Hoxe penso falar sobre como escribir aplicacións e cales son os requisitos para que a súa aplicación funcione ben en Kubernetes. Para que non haxa dores de cabeza coa aplicación, para que non teñas que inventar e construír ningún "cratch" ao seu redor, e todo funciona como o propio Kubernetes pretendía.
Esta charla forma parte de "" Podes ver as charlas teóricas abertas da Escola Noite . Para aqueles que prefiren o texto ao vídeo, preparamos este artigo.
Chámome Pavel Selivanov, actualmente son o enxeñeiro líder de DevOps en Mail.ru Cloud Solutions, facemos nubes, facemos xestión de kubernetes, etc. As miñas tarefas agora inclúen a asistencia no desenvolvemento, a implantación destas nubes, a posta en marcha das aplicacións que escribimos e o desenvolvemento directo das ferramentas que ofrecemos aos nosos usuarios.
Estiven facendo DevOps, creo que nos últimos, probablemente, tres anos. Pero, en principio, levo facendo o que fai DevOps probablemente hai uns cinco anos. Antes diso, estaba involucrado principalmente en cousas de administración. Comecei a traballar con Kubernetes hai moito tempo; probablemente pasaron uns catro anos desde que comecei a traballar con el.
En xeral, comecei cando Kubernetes era a versión 1.3, probablemente, e quizais a 1.2, cando aínda estaba na súa infancia. Agora xa non está na súa infancia, e é obvio que hai unha gran demanda no mercado de enxeñeiros que lles gustaría poder facer Kubernetes. E as empresas teñen unha demanda moi alta por este tipo de persoas. Por iso, de feito, apareceu esta conferencia.
Se falamos do plano do que vou falar, parece así, entre parénteses está escrito (TL;DR) - “demasiado longo; non leas". A miña presentación de hoxe constará de listas infinitas.
De feito, a min mesmo non me gustan este tipo de presentacións cando se fan, pero este é un tema tal que cando estaba a preparar esta presentación, simplemente non descubrín como organizar esta información de forma diferente.
Porque, en xeral, esta información é “ctrl+c, ctrl+v”, procedente, entre outras cousas, da nosa Wiki na sección DevOps, onde temos escritos requisitos para os desenvolvedores: “chicos, para que lancemos a túa aplicación en Kubernetes, debería ser así".
Por iso a presentación resultou ser unha lista tan grande. Sentímolo. Intentarei contar o máximo posible para que non sexa aburrido se é posible.
O que imos ver agora:
- estes son, en primeiro lugar, rexistros (rexistros de aplicacións?), que facer con eles en Kubernetes, que facer con eles, cales deberían ser;
- que facer coas configuracións en Kubernetes, cales son as mellores e as peores formas de configurar unha aplicación para Kubernetes;
- Falemos de que son os controis de accesibilidade en xeral, como deben ser;
- imos falar do que é un apagado gracioso;
- volvamos falar de recursos;
- Toquemos unha vez máis o tema do almacenamento de datos;
- e ao final contarei cal é o termo esta misteriosa aplicación nativa da nube. Cloudnativeness, como adxectivo deste termo.
Rexistros
Suxiro comezar cos rexistros, por onde hai que colocar estes rexistros en Kubernetes. Agora lanzaches unha aplicación en Kubernetes. Segundo os clásicos, anteriormente as aplicacións sempre escribían rexistros nalgún lugar dun ficheiro. As aplicacións incorrectas escribiron rexistros nun ficheiro no directorio de inicio do programador que iniciou a aplicación. As boas aplicacións escribiron rexistros nun ficheiro nalgún lugar /var/log.
En consecuencia, ademais, os bos administradores tiñan algunhas cousas configuradas nas súas infraestruturas que estes rexistros poderían rotar: o mesmo rsyslog, que mira estes rexistros e cando lles pasa algo, hai moitos, crea copias de seguridade, pon os rexistros alí. , elimina ficheiros antigos, máis dunha semana, seis meses e algúns máis. En teoría, deberíamos ter disposicións para que simplemente porque a aplicación escriba rexistros, o espazo nos servidores de produción (servidores de combate?) non se esgote. E, en consecuencia, toda a produción non parou por mor dos troncos.
Cando pasamos ao mundo de Kubernetes e executamos o mesmo alí, o primeiro ao que podes prestar atención é o feito de que a xente, mentres escribiu rexistros nun ficheiro, segue escribindoos.
Resulta que se falamos de Kubernetes, o lugar axeitado para escribir rexistros nalgún lugar dun contedor docker é simplemente escribilos desde a aplicación no chamado Stdout/Stderr, é dicir, os fluxos de saída estándar do sistema operativo, erro estándar. saída . Esta é a forma máis correcta, sinxela e lóxica de poñer os rexistros en principio en Docker e concretamente en Kubernetis. Porque se a túa aplicación escribe rexistros en Stdout/Stderr, correspóndelle a Docker e ao complemento de Kubernetes decidir que facer con estes rexistros. Docker creará por defecto os seus ficheiros especiais en formato JSON.
Aquí xorde a pregunta, que vai facer a continuación con estes rexistros? O xeito máis doado está claro, temos a capacidade de facelo kubectl logs e mira estes rexistros destas "vainas". Pero, probablemente, esta non é unha opción moi boa: hai que facer outra cousa cos rexistros.
De momento, imos falar ao mesmo tempo, xa que tocamos o tema dos rexistros, sobre o que deberían parecer os rexistros. É dicir, isto non se aplica directamente a Kubernetes, pero cando empecemos a pensar que facer cos rexistros, estaría ben pensalo tamén.
Necesitamos algún tipo de ferramenta, de xeito amigable, que leve estes rexistros que o noso docker pon nos seus ficheiros e os envíe a algún lugar. En xeral, adoitamos lanzar algún tipo de axente dentro de Kubernetes en forma de DaemonSet: un colector de rexistros, ao que simplemente se indica onde están os rexistros que recolle Docker. E este axente de recollida simplemente lévaos, quizais incluso analízaos dalgún xeito ao longo do camiño, quizais os enriqueza con algunha metainformación adicional e, finalmente, envíaos para almacenalos nalgún lugar. As variacións xa son posibles alí. O máis común é probablemente Elasticsearch, onde podes almacenar rexistros e podes recuperalos comodamente desde alí. Despois, usando unha solicitude, usando Kibana, por exemplo, constrúe gráficos baseados neles, crea alertas baseadas neles, etc.
A idea máis importante, quero repetilo de novo, é que dentro de Docker, en particular dentro de Kubernetes, almacenar os teus rexistros nun ficheiro é moi mala idea.
Porque, en primeiro lugar, é difícil conseguir os rexistros dentro do contedor nun ficheiro. Primeiro debes entrar no contedor, executar alí e despois mirar os rexistros. O seguinte punto é que se tes rexistros nun ficheiro, os contedores adoitan ter un ambiente minimalista e non hai utilidades que adoitan ser necesarias para o traballo normal cos rexistros. Entérraos, míraos, ábreos nun editor de texto. O seguinte momento é cando temos rexistros nun ficheiro dentro dun contenedor, se este contenedor se elimina, entendes, os rexistros morrerán xunto con el. En consecuencia, calquera reinicio do contedor significa que non hai máis rexistros. De novo, mala opción.
E o último punto é que dentro dos contedores normalmente tes a túa aplicación e xa está: adoita ser o único proceso en execución. Non se fala en absoluto de ningún proceso que faría xirar os ficheiros cos teus rexistros. En canto os rexistros comecen a escribirse nun ficheiro, isto significa que, perdón, comezaremos a perder o servidor de produción. Porque, en primeiro lugar, son difíciles de atopar, ninguén os rastrexa e ninguén os controla; en consecuencia, o ficheiro crece sen parar ata que o espazo no servidor simplemente se esgota. Polo tanto, volvo dicir que iniciar sesión en Docker, en particular en Kubernetes, nun ficheiro é unha mala idea.
O seguinte punto, aquí quero falar sobre isto de novo: xa que estamos a tocar o tema dos rexistros, sería bo falar de como deberían verse os rexistros para que sexa cómodo traballar con eles. Como dixen, o tema non está directamente relacionado con Kubernetes, pero está moi ben relacionado co tema de DevOps. Sobre o tema da cultura de desenvolvemento e a amizade entre estes dous departamentos diferentes: Dev e Ops, para que todos estean cómodos.
Isto significa que idealmente, hoxe en día, os rexistros deberían escribirse en formato JSON. Se tes algunha aplicación propia incomprensible, que escribe rexistros en formatos incomprensibles porque inseris algún tipo de impresión ou algo así, entón é hora de buscar en Google algún tipo de framework, algún tipo de wrapper que che permita implementar o rexistro normal; habilite alí os parámetros de rexistro en JSON, porque JSON é un formato sinxelo, analizalo é sinxelo.
Se o teu JSON non funciona segundo algúns criterios, ninguén sabe que, polo menos escribe rexistros nun formato que se poida analizar. Aquí, máis ben, paga a pena pensar no feito de que, por exemplo, se estás executando un montón de contedores ou só procesos con nginx, e cada un ten a súa propia configuración de rexistro, probablemente parece que che resultará moi inconveniente. analizalos. Porque para cada nova instancia de nginx necesitas escribir o teu propio analizador, porque escriben os rexistros de forma diferente. De novo, probablemente pagase a pena pensar en asegurarse de que todas estas instancias de nginx tiñan a mesma configuración de rexistro e escribiron todos os seus rexistros de forma absolutamente uniforme. O mesmo aplícase a absolutamente todas as aplicacións.
Ao final, tamén quero engadir combustible ao lume que, idealmente, deberían evitarse os rexistros de formato multiliña. Aquí está a cousa, se algunha vez traballaches con recopiladores de rexistros, o máis probable é que teñas visto o que che prometen, que poden traballar con rexistros de varias liñas, saber como recollelos, etc. De feito, na miña opinión, nin un só colector pode recoller rexistros de varias liñas de forma normal, completa e sen erros. Dun xeito humano, para que sexa cómodo e libre de erros.
Pero o rastrexo da pila é sempre rexistros de varias liñas e como evitalos. A pregunta aquí é que un rexistro é un rexistro dun evento e stactrace non é realmente un rexistro. Se recollemos rexistros e os colocamos nalgún lugar de Elasticsearch e despois elaboramos gráficos a partir deles, creamos algúns informes da actividade dos usuarios no teu sitio, entón cando obteñas un rastrexo da pila, significa que está a suceder algo inesperado, unha situación non xestionada na túa aplicación. E ten sentido cargar automaticamente un rastro de pila nalgún lugar nun sistema que poida rastrexalos.
Este é un software (o mesmo Sentry) que está feito especificamente para traballar con rastrexo de pila. Pode crear inmediatamente tarefas automatizadas, asignalas a alguén, alertar cando se producen trazos de estado, agrupar estes trazos por un tipo, etc. En principio, non ten moito sentido falar de stactraces cando falamos de rexistros, porque, ao cabo, son cousas diferentes con propósitos diferentes.
Configuración
A continuación falamos da configuración en Kubernetes: que facer con ela e como se deben configurar as aplicacións dentro de Kubernetes. En xeral, adoito dicir que Docker non se trata de contedores. Todo o mundo sabe que Docker trata de contedores, incluso aqueles que non traballaron moito con Docker. Repito, Docker non se trata de contedores.
Docker, na miña opinión, trata de estándares. E hai estándares para practicamente todo: estándares para construír a túa aplicación, estándares para instalar a túa aplicación.
E esta cousa - usámola antes, fíxose especialmente popular coa chegada dos contedores - esta cousa chámase variables ENV (ambiente), é dicir, variables de ambiente que están no teu sistema operativo. En xeral, esta é unha forma ideal de configurar a túa aplicación, porque se tes aplicacións en JAVA, Python, Go, Perl, Deus non o libre, e todos poden ler o servidor da base de datos, o usuario da base de datos, as variables do contrasinal da base de datos, entón é ideal. Tes aplicacións en catro idiomas diferentes configuradas no plan de base de datos do mesmo xeito. Non hai máis configuracións diferentes.
Todo se pode configurar usando variables ENV. Cando falamos de Kubernetes, hai unha boa forma de declarar variables ENV directamente dentro de Deployment. En consecuencia, se estamos a falar de datos secretos, podemos enviar inmediatamente os datos secretos das variables ENV (contrasinais para bases de datos, etc.) nun segredo, crear un clúster secreto e indicar na descrición de ENV en Implementación que non estamos declarando directamente. o valor desta variable e o valor desta variable de contrasinal da base de datos lerase desde o segredo. Este é o comportamento estándar de Kubernetes. E esta é a opción máis ideal para configurar as túas aplicacións. Só a nivel de código, de novo isto aplícase aos desenvolvedores. Se es DevOps, podes preguntar: "Rapaces, ensine á súa aplicación a ler as variables de ambiente. E todos seremos felices".
Se todos os membros da empresa len as mesmas variables de ambiente nomeadas, é xenial. Para que non ocorra que uns agarden a base de datos de postgres, outros agardan o nome da base de datos, outros agardan outra cousa, outros agardan algún tipo de dbn, para que, en consecuencia, haxa uniformidade.
O problema vén cando tes tantas variables de ambiente que acabas de abrir Implementación, e hai cincocentas liñas de variables de ambiente. Neste caso, simplemente superou as variables de ambiente e xa non necesitas torturarte. Neste caso, tería sentido comezar a usar as configuracións. É dicir, adestra a túa aplicación para usar as configuracións.
A única pregunta é que as configuracións non son o que pensas. Config.pi non é unha configuración que sexa cómodo de usar. Ou algunha configuración no seu propio formato, alternativamente dotada; esta tampouco é a configuración que me refiro.
Do que estou a falar é de configuración en formatos aceptables, é dicir, o estándar máis popular é o estándar .yaml. Está claro como lelo, é lexible por humanos, está claro como lelo desde a aplicación.
En consecuencia, ademais de YAML, tamén pode, por exemplo, usar JSON, a análise é tan conveniente como YAML en canto a ler a configuración da aplicación desde alí. É notablemente máis incómodo para a xente a ler. Podes probar o formato, a la ini. É bastante cómodo de ler, desde o punto de vista humano, pero pode resultar incómodo procesala automaticamente, no sentido de que, se algunha vez queres xerar as túas propias configuracións, o formato ini xa pode resultar incómodo de xerar.
Pero en calquera caso, sexa cal sexa o formato que elixas, a cuestión é que desde o punto de vista de Kubernetes é moi conveniente. Podes poñer toda a túa configuración dentro de Kubernetes, no ConfigMap. E despois colle este mapa de configuración e pídelle que se monte dentro do teu pod nalgún directorio específico, onde a túa aplicación lerá a configuración deste mapa de configuración coma se fose só un ficheiro. Isto, de feito, é o que é bo facer cando tes moitas opcións de configuración na túa aplicación. Ou é só algún tipo de estrutura complexa, hai aniñación.
Se tes un mapa de configuración, podes ensinarlle moi ben á túa aplicación, por exemplo, a facer un seguimento automático dos cambios no ficheiro onde está montado o mapa de configuración e tamén volver cargar automaticamente a túa aplicación cando cambian as configuracións. En xeral, esta sería unha opción ideal.
De novo, xa falei disto: a información secreta non está no mapa de configuración, a información secreta non está en variables, a información secreta non está en segredo. A partir de aí, conecta esta información secreta coa diplomacia. Normalmente almacenamos todas as descricións de obxectos de Kubernetes, despregamentos, mapas de configuración e servizos en git. En consecuencia, poñer o contrasinal da base de datos en git, aínda que sexa o teu git, que tes internamente na empresa, é unha mala idea. Porque, como mínimo, git lembra todo e simplemente eliminar os contrasinais de alí non é tan sinxelo.
Control sanitario
O seguinte punto é isto chamado Revisión de saúde. En xeral, unha comprobación de saúde é simplemente comprobar que a túa aplicación funciona. Ao mesmo tempo, a maioría das veces estamos a falar de determinadas aplicacións web, para as que, en consecuencia, desde o punto de vista da comprobación de saúde (é mellor non traducir aquí e máis adiante) esta será unha URL especial, que procesan como un estándar, adoitan facelo /health.
En consecuencia, ao acceder a este URL, a nosa aplicación di "si, está ben, todo está ben para min, 200" ou "non, non todo está ben para min, uns 500". En consecuencia, se a nosa aplicación non é http, non é unha aplicación web, agora estamos a falar dalgún tipo de daemon, podemos descubrir como facer comprobacións de saúde. É dicir, non é necesario, se a aplicación non é http, todo funciona sen un control de saúde e isto non se pode facer de ningún xeito. Podes actualizar periodicamente algunha información no ficheiro, podes crear algún comando especial para o teu daemon, como, daemon status, que dirá "si, todo está ben, o daemon está funcionando, está vivo".
Para que serve? O primeiro e máis obvio é probablemente o motivo polo que se necesita unha comprobación de saúde - para entender que a aplicación está funcionando. Quero dicir, é unha estupidez, cando está agora, parece que está funcionando, así que podes estar seguro de que está funcionando. E resulta que a aplicación está a executarse, o contedor está a funcionar, a instancia funciona, todo está ben, e entón os usuarios xa cortaron todos os números de teléfono do soporte técnico e din "que es ti..., ti durmiuse, nada funciona".
Un control de saúde é só unha forma de ver desde o punto de vista do usuario que funciona. Un dos métodos. Poñémolo así. Desde o punto de vista de Kubernetes, esta tamén é unha forma de entender cando se inicia a aplicación, porque entendemos que hai unha diferenza entre cando se lanzou, creou e iniciou o contedor e cando a aplicación se lanzou directamente neste contedor. Porque se tomamos algunha aplicación Java media e intentamos lanzala no dock, entón durante corenta segundos, ou mesmo un minuto, ou ata dez, pode comezar ben. Neste caso, polo menos podes chamar aos seus portos, non responderá alí, é dicir, aínda non está preparado para recibir tráfico.
De novo, coa axuda dunha comprobación de saúde e coa axuda do feito de que estamos a virar aquí, podemos entender en Kubernetes que non só o contedor subiu na aplicación, senón que a propia aplicación comezou, xa responde ao revisión de saúde, o que significa que podemos enviar tráfico alí.
O que estou a falar agora chámase probas de preparación/vivencia dentro de Kubernetes; polo tanto, as nosas probas de preparación son as responsables da dispoñibilidade da aplicación no equilibrio. É dicir, se se realizan probas de preparación na aplicación, todo está ben, o tráfico do cliente vai á aplicación. Se non se realizan as probas de preparación, a aplicación simplemente non participa, esta instancia en particular non participa no equilibrio, elimínase do equilibrio e o tráfico do cliente non flúe. En consecuencia, son necesarias probas de Liveness dentro de Kubernetes para que se a aplicación se atasca, poida reiniciarse. Se a proba de actividade non funciona para unha aplicación declarada en Kubernetes, a aplicación non só se elimina do equilibrio, senón que se reinicia.
E aquí hai un punto importante que me gustaría mencionar: desde un punto de vista práctico, a proba de preparación adoita utilizarse con máis frecuencia e é máis necesaria que a proba de vida. É dicir, simplemente declarar sen pensar tanto as probas de preparación como de vivacidade, porque Kubernetes pode facelo, e usemos todo o que pode facer, non é moi boa idea. Vou explicar por que. Porque o punto número dous das probas é que sería unha boa idea comprobar o servizo subxacente nos teus controis de saúde. Isto quere dicir que se tes unha aplicación web que ofrece algunha información, que á súa vez, por suposto, debe levar de algún lugar. Nunha base de datos, por exemplo. Ben, garda a información que entra nesta API REST na mesma base de datos. Entón, en consecuencia, se a túa comprobación de saúde responde simplemente como slashhealth contactada, a aplicación di "200, está ben, todo está ben" e, ao mesmo tempo, a base de datos da túa aplicación é inaccesible e a aplicación de comprobación de saúde di "200, está ben, todo está ben". ” - Este é un mal control de saúde. Non é así como debería funcionar.
É dicir, a súa solicitude, cando lle chega unha solicitude /health, non só responde "200, ok", primeiro vai, por exemplo, á base de datos, tenta conectarse a ela, fai algo moi básico alí, como seleccionar un, só comproba que hai unha conexión no base de datos e pode consultar a base de datos. Se todo isto tivo éxito, entón a resposta é "200, ok". Se non ten éxito, di que hai un erro, a base de datos non está dispoñible.
Polo tanto, a este respecto, volvo de novo ás probas de preparación/vivencia: por que probablemente necesites unha proba de preparación, pero unha proba de vitalidade está en cuestión. Porque se describe os controis de saúde exactamente como acabo de dicir, entón resultará que non está dispoñible na parte de instanciaв или со всех instancenunha base de datos, por exemplo. Cando declarou unha proba de preparación, as nosas comprobacións de saúde comezaron a fallar e, en consecuencia, todas as aplicacións das que non se pode acceder á base de datos simplemente desactívanse do equilibrio e, de feito, "colgan" só nun estado descoidado e agardan a que as súas bases de datos se traballo.
Se declaramos unha proba de vitalidade, imaxina que a nosa base de datos rompeuse e no teu Kubernetes a metade de todo comeza a reiniciarse porque a proba de vitalidade falla. Isto significa que cómpre reiniciar. Isto non é para nada o que queres, ata tiven experiencia persoal na práctica. Tiñamos unha aplicación de chat que estaba escrita en JS e introducida nunha base de datos Mongo. E o problema foi que foi ao comezo do meu traballo con Kubernetes, describimos a preparación, a vitalidade das probas sobre o principio de que Kubernetes pode facelo, polo que imos usalo. En consecuencia, nalgún momento Mongo volveuse un pouco "aburrido" e a mostra comezou a fallar. En consecuencia, segundo a proba de choiva, as vainas comezaron a "matar".
Como entendes, cando son "matados", isto é un chat, é dicir, hai moitas conexións de clientes pendentes del. Tamén son "matados" - non, non clientes, só conexións - non todos ao mesmo tempo, e debido ao feito de que non son asasinados ao mesmo tempo, algúns antes, outros máis tarde, non comezan ao mesmo tempo. tempo. Ademais do aleatorio estándar, non podemos predecir con precisión de milisegundos a hora de inicio da aplicación cada vez, polo que o fan unha instancia á vez. Sobe un infospot, súmase ao balance, todos os clientes chegan alí, non pode soportar tal carga, porque está só e, grosso modo, hai unha ducia traballando alí, e baixa. O seguinte levántase, toda a carga está sobre el, tamén cae. Ben, estas caídas só seguen caendo en cascada. Ao final, como se solucionou isto: só tivemos que deter estrictamente o tráfico de usuarios a esta aplicación, deixar que todas as instancias suban e despois iniciar todo o tráfico de usuarios á vez para que xa se distribuíse entre as dez instancias.
Se non fose porque se anunciara esta proba de vivacidade, que obrigaría a reiniciar todo, a aplicación teríalo ben xestionado. Pero todo, desde o equilibrio está desactivado para nós, porque as bases de datos son inaccesibles e todos os usuarios "caeron". Despois, cando esta base de datos está dispoñible, todo está incluído no balance, pero as aplicacións non precisan comezar de novo e non hai que perder tempo e recursos con isto. Xa están todos aquí, están listos para o tráfico, polo que o tráfico só se abre, todo está ben: a aplicación está no seu lugar, todo segue funcionando.
Polo tanto, as probas de preparación e vivacidade son diferentes e, ademais, teoricamente podes facer diferentes controis de saúde, un tipo de radio, un tipo de liv, por exemplo, e comprobar cousas diferentes. Durante as probas de preparación, comproba os teus backends. E nunha proba de vivacidade, por exemplo, non comproba desde o punto de vista de que a proba de vivacidade é xeralmente só unha aplicación que responde, se é capaz de responder.
Porque a proba de vitalidade, en xeral, é cando estamos "atascados". Comezou un ciclo interminable ou outra cousa, e non se procesan máis solicitudes. Polo tanto, ten sentido incluso separalos e implementar neles unha lóxica diferente.
Respecto ao que hai que responder cando tes unha proba, cando fas controis de saúde. É realmente unha dor. Os que estean familiarizados con isto probablemente se rirán, pero en serio, vin servizos na miña vida que responden "200" no XNUMX% dos casos. É dicir, quen ten éxito. Pero ao mesmo tempo no corpo da resposta escriben "erro tal e tal".
É dicir, o estado de resposta chega a ti: todo é exitoso. Pero ao mesmo tempo, debes analizar o corpo, porque o corpo di "perdón, a solicitude rematou cun erro" e isto é só a realidade. Eu vin isto na vida real.
E para que a algunhas persoas non lle resulte gracioso e a outras lle resulte moi doloroso, aínda paga a pena seguir unha simple regra. Nas comprobacións de saúde, e en principio cando se traballa con aplicacións web.
Se todo saíu ben, responde coa resposta doscentésima. En principio, calquera resposta de dúas centésimas axeitaráche. Se le moi ben a ragsy e sabe que algúns estados de resposta son diferentes doutros, responde cos apropiados: 204, 5, 10, 15, o que sexa. Se non é moi bo, entón só "dous cero cero". Se todo vai mal e o control de saúde non responde, responde con calquera quinientos. De novo, se entendes como responder, en que diferentes estados de resposta difiren entre si. Se non entendes, entón o 502 é a túa opción para responder aos controis de saúde se algo sae mal.
Este é outro punto, quero volver un pouco sobre a comprobación dos servizos subxacentes. Se comezas, por exemplo, a comprobar todos os servizos subxacentes que hai detrás da túa aplicación, todo en xeral. O que obtemos desde o punto de vista da arquitectura de microservizos, temos un concepto como "acoplamento baixo", é dicir, cando os teus servizos dependen mínimamente uns dos outros. Se un deles falla, todos os outros sen esta funcionalidade seguirán funcionando. Algunhas das funcións simplemente non funcionan. En consecuencia, se vinculan todos os controis de saúde entre si, entón acabará caendo unha cousa na infraestrutura e, como caeu, tamén comezan a fallar todos os controles de saúde de todos os servizos, e hai máis infraestrutura en xeral para o arquitectura completa de microservizos núm. Alí todo quedou escuro.
Polo tanto, quero repetir de novo que cómpre comprobar os servizos subxacentes, aqueles sen os cales a súa aplicación non pode facer o seu traballo nun cen por cento dos casos. É dicir, é lóxico que se tes unha API REST a través da cal o usuario garda na base de datos ou recupera da base de datos, a falta dunha base de datos, non podes garantir o traballo cos teus usuarios.
Pero se os seus usuarios, cando os saca da base de datos, se enriquecen adicionalmente con outros metadatos, doutro backend, que introduce antes de enviar unha resposta ao frontend, e este backend non está dispoñible, isto significa que dá o seu responder sen ningunha parte dos metadatos.
A continuación, tamén temos un dos problemas dolorosos ao lanzar aplicacións.
De feito, isto non só se aplica a Kubernetes en xeral; ocorreu que a cultura dalgún tipo de desenvolvemento masivo e DevOps en particular comezou a estenderse ao mesmo tempo que Kubernetes. Polo tanto, en xeral, resulta que cómpre pechar a aplicación sen Kubernetes. Mesmo antes de Kubernetes, a xente facía isto, pero coa chegada de Kubernetes comezamos a falar diso en masa.
Apagado gracioso
En xeral, que é Graceful Shutdown e por que é necesario? Trátase de cando a túa aplicación falla por algún motivo, debes facelo app stop - ou recibe, por exemplo, un sinal do sistema operativo, a súa aplicación debe entendelo e facer algo ao respecto. O peor dos casos, por suposto, é cando a túa aplicación recibe un SIGTERM e é como "SIGTERM, imos esperar, traballar, non facer nada". Esta é unha opción francamente mala.
Unha opción case igual de mala é cando a túa aplicación recibe un SIGTERM e é como “dixeron segterm, iso significa que estamos rematando, non vin, non coñezo ningunha solicitude de usuario, non sei que tipo de solicitudes nas que teño traballando agora mesmo, dixeron SIGTERM, iso significa que estamos rematando " Esta tamén é unha mala opción.
Que opción é boa? O primeiro punto é ter en conta a finalización das operacións. Unha boa opción é que o teu servidor aínda teña en conta o que fai se recibe un SIGTERM.
SIGTERM é un apagado suave, está especialmente deseñado, pódese interceptar a nivel de código, pódese procesar, digamos que agora, espera, primeiro remataremos o traballo que temos, despois sairemos.
Desde a perspectiva de Kubernetes, isto é o que parece. Cando dicimos a un pod que se está a executar nun clúster de Kubernetes, "detén, vaia", ou se produce un reinicio ou se produce unha actualización cando Kubernetes recrea os pods, Kubernetes envía só a mesma mensaxe SIGTERM ao pod, agarda algún tempo, e , este é o tempo que espera, tamén está configurado, hai un parámetro tan especial nos diplomas e chámase Graceful ShutdownTimeout. Como entendes, non se chama así por nada, e non por nada falamos diso agora.
Alí podemos dicir especificamente canto tempo hai que esperar entre o momento en que enviamos SIGTERM á aplicación e cando entendemos que a aplicación parece que se volveu tola por algo ou está "atascada" e non vai rematar, e necesitamos envíalle SIGKILL, é dicir, completa o seu traballo. É dicir, en consecuencia, temos algún tipo de daemon en execución, que procesa operacións. Entendemos que, de media, as nosas operacións nas que traballa o daemon non duran máis de 30 segundos á vez. En consecuencia, cando chega SIGTERM, entendemos que o noso daemon pode, como máximo, rematar 30 segundos despois de SIGTERM. Escribimos, por exemplo, 45 segundos por se acaso e dicimos que SIGTERM. Despois diso, agardamos 45 segundos. En teoría, durante este tempo o demo debería ter completado o seu traballo e rematar por si mesmo. Pero se de súpeto non puido, significa que o máis probable é que estea atascado; xa non está a procesar as nosas solicitudes con normalidade. E en 45 segundos podes, de feito, cravalo con seguridade.
E aquí, de feito, mesmo se poden ter en conta 2 aspectos. En primeiro lugar, entende que se recibiu unha solicitude, comezaches a traballar con ela dalgún xeito e non deu resposta ao usuario, pero recibiu SIGTERM, por exemplo. Ten sentido refinalo e darlle unha resposta ao usuario. Este é o punto número un neste sentido. O punto número dous aquí é que se escribe a súa propia aplicación, xeralmente constrúe a arquitectura de tal xeito que reciba unha solicitude para a súa aplicación, entón comeza a traballar, comeza a descargar ficheiros desde algún lugar, a descargar unha base de datos e outras cousas. Iso. En xeral, o seu usuario, a súa solicitude pende durante media hora e espera a que lle responda; entón, moi probablemente, necesite traballar na arquitectura. É dicir, só ten en conta o sentido común de que, se as súas operacións son curtas, ten sentido ignorar SIGTERM e modificalo. Se as túas operacións son longas, non ten sentido ignorar SIGTERM neste caso. Ten sentido redeseñar a arquitectura para evitar operacións tan longas. Para que os usuarios non se limiten a esperar. Non sei, fai alí algún tipo de websocket, fai ganchos inversos que o teu servidor xa enviará ao cliente, calquera outra cousa, pero non obrigues ao usuario a colgar durante media hora e só espera unha sesión ata que contestalle. Porque é imprevisible onde pode romper.
Cando a súa aplicación remate, debe proporcionar algún código de saída adecuado. É dicir, se se lle pediu a súa aplicación que pechase, se detivese e puido deterse por si mesma normalmente, non necesitará devolver algún tipo de código de saída 1,5,255 e así por diante. Todo o que non sexa código cero, polo menos nos sistemas Linux, estou seguro diso, considérase que non ten éxito. É dicir, considérase que a súa solicitude neste caso rematou cun erro. En consecuencia, de forma amigable, se a súa solicitude completouse sen erro, di 0 na saída. Se a túa aplicación falla por algún motivo, dis non-0 na saída. E podes traballar con esta información.
E a última opción. É malo cando o teu usuario envía unha solicitude e se colga durante media hora mentres a procesas. Pero, en xeral, tamén me gustaría dicir sobre o que en xeral paga a pena por parte do cliente. Non importa se tes unha aplicación móbil, front-end, etc. Hai que ter en conta que a sesión do usuario pode ser finalizada, calquera cousa pode pasar. É posible que unha solicitude se envíe, por exemplo, non se procese correctamente e non se devolva ningunha resposta. O teu frontend ou a túa aplicación móbil -calquera frontend en xeral, poñémolo así- debería telo en conta. Se traballas con websockets, esta é xeralmente a peor dor que tiven.
Cando os desenvolvedores dalgúns chats habituais non o saben, resulta que o websocket pode romper. Para eles, cando ocorre algo no proxy, simplemente cambiamos a configuración e recarga. Por suposto, todas as sesións de longa duración son rasgadas neste caso. Os desenvolvedores veñen correndo cara a nós e din: "Rapaces, que estás facendo, o chat rompeuse para todos os nosos clientes!" Dicímoslles: “Que fas? Os teus clientes non poden volver conectarse? Din: "Non, necesitamos que as sesións non se rompan". En resumo, isto é realmente unha tontería. Hai que ter en conta o lado do cliente. Sobre todo, como digo, con sesións de longa duración como os websockets, pode romperse e, sen que o usuario se dea conta, cómpre poder reinstalar este tipo de sesións. E entón todo é perfecto.
Recursos
En realidade, aquí só vos contarei unha historia directa. De novo da vida real. A cousa máis doente que xamais escoitei sobre recursos.
Recursos neste caso, quero dicir, algún tipo de solicitudes, límites que podes poñer nos pods dos teus clústeres de Kubernetes. O máis divertido que escoitei dun programador... Un dos meus compañeiros desenvolvedores nun lugar de traballo anterior dixo unha vez: "A miña aplicación non se iniciará no clúster". Mirei para ver que non empezaba, pero ou non encaixaba nos recursos, ou puxeran límites moi pequenos. En resumo, a aplicación non pode iniciarse debido aos recursos. Eu digo: "Non comezará por recursos, ti decides canto necesitas e estableces un valor adecuado". El di: "Que tipo de recursos?" Comecei a explicarlle que hai que establecer Kubernetes, límites de solicitudes e bla, bla, bla. O home escoitou durante cinco minutos, asentiu e dixo: "Vinei aquí para traballar como programador, non quero saber nada de ningún recurso. Vin aquí para escribir código e xa está". É triste. Este é un concepto moi triste desde o punto de vista dun programador. Especialmente no mundo moderno, por así dicir, dos devops progresistas.
Por que son necesarios recursos? Hai 2 tipos de recursos en Kubernetes. Algunhas chámanse solicitudes, outras chámanse límites. Por recursos entenderemos que basicamente sempre hai só dúas restricións básicas. É dicir, límites de tempo de CPU e límites de RAM para un contedor que se executa en Kubernetes.
Un límite establece un límite superior sobre como se pode usar un recurso na súa aplicación. É dicir, en consecuencia, se dis 1 GB de RAM nos límites, entón a túa aplicación non poderá usar máis de 1 GB de RAM. E se de súpeto quere e tenta facelo, entón un proceso chamado oom killer, sen memoria, é dicir, chegará e matará a súa aplicación, é dicir, simplemente reiniciarase. As aplicacións non se reiniciarán en función da CPU. En termos de CPU, se unha aplicación intenta usar moito, máis do especificado nos límites, a CPU simplemente seleccionarase estrictamente. Isto non leva a reinicios. Este é o límite - este é o límite superior.
E hai unha petición. Unha solicitude é como Kubernetes entende como se enchen de aplicacións os nodos do teu clúster de Kubernetes. É dicir, unha solicitude é unha especie de compromiso da túa solicitude. Di o que quero usar: "Gustaríame que reservaras tanta CPU e tanta memoria para min". Unha analoxía tan sinxela. E se temos un nodo que teña, non sei, 8 CPUs en total. E chega alí un pod, cuxas solicitudes din 1 CPU, o que significa que ao nodo lle quedan 7 CPU. É dicir, en consecuencia, en canto chegan 8 pods a este nodo, cada un dos cales ten 1 CPU nas súas solicitudes, o nodo, como se desde o punto de vista de Kubernetes, quedou sen CPU e non se poden ter máis pods con solicitudes. lanzado neste nodo. Se todos os nodos quedan sen CPU, entón Kubernetes comezará a dicir que non hai nodos axeitados no clúster para executar os seus pods porque a CPU esgotouse.
Por que son necesarias as solicitudes e por que, sen solicitudes, creo que non hai que lanzar nada en Kubernetes? Imaxinemos unha situación hipotética. Lanzas a túa aplicación sen solicitudes, Kubernetes non sabe canto do que tes, a que nodos podes impulsala. Ben, el empurra, empurra, empurra nos nós. Nalgún momento, comezará a recibir tráfico para a súa aplicación. E unha das aplicacións comeza de súpeto a utilizar recursos ata os límites que ten segundo os límites. Resulta que hai outra aplicación preto e tamén necesita recursos. O nodo realmente comeza a quedarse sen recursos, por exemplo, OP. O nodo realmente comeza a esgotar fisicamente os recursos, por exemplo, a memoria de acceso aleatorio (RAM). Cando un nodo queda sen enerxía, primeiro o docker deixará de responder, despois o cubelet e despois o SO. Simplemente quedarán inconscientes e TODO definitivamente deixará de funcionar para ti. É dicir, isto fará que o teu nodo se atasque e terás que reinicialo. En resumo, a situación non é moi boa.
E cando tes solicitudes, os límites non son moi diferentes, polo menos non moitas veces máis que os límites ou solicitudes, entón podes ter un recheo tan normal e racional de aplicacións nos nodos dos clústeres de Kubernetes. Ao mesmo tempo, Kubernetes sabe aproximadamente canto do que pon onde, canto do que se usa onde. É dicir, é só un momento así. É importante entendelo. E é importante controlar que isto estea indicado.
Almacenamento de datos
O noso seguinte punto é sobre o almacenamento de datos. Que facer con eles e, en xeral, que facer coa persistencia en Kubernetes?
Penso, de novo, dentro do noso , había un tema sobre a base de datos en Kubernetes. E paréceme que sei ata o que che dixeron os teus compañeiros cando lle preguntaron: "É posible executar unha base de datos en Kubernetes?" Por algún motivo, paréceme que os teus colegas deberían dicirche que se estás facendo a pregunta de se é posible executar unha base de datos en Kubernetes, entón é imposible.
A lóxica aquí é sinxela. Por se acaso, explicarei unha vez máis, se es un tipo moi xenial que pode construír un sistema de almacenamento de rede distribuído bastante tolerante a fallos, entende como encaixar unha base de datos neste caso, como debería funcionar o nativo da nube nos contedores. nunha base de datos en xeral. O máis probable é que non teña dúbidas sobre como executalo. Se tes tal pregunta e queres asegurarte de que todo se desenvolva e morre na produción e nunca caia, isto non ocorre. Está garantido que te dispararás no pé con este enfoque. Entón, é mellor non facelo.
Que debemos facer cos datos que a nosa aplicación quere almacenar, algunhas imaxes que cargan os usuarios, algunhas cousas que a nosa aplicación xera durante o seu funcionamento, ao iniciarse, por exemplo? Que facer con eles en Kubernetes?
En xeral, o ideal, si, claro, Kubernetes está moi ben deseñado e en xeral foi concibido inicialmente para aplicacións sen estado. É dicir, para aquelas aplicacións que non almacenan información en absoluto. Isto é ideal.
Pero, por suposto, a opción ideal non sempre existe. Entón, que? O primeiro e máis sinxelo punto é tomar algún tipo de S3, pero non un feito na casa, o que tampouco está claro como funciona, senón dalgún provedor. Un bo provedor normal e ensine a súa aplicación a usar S3. É dicir, cando o teu usuario queira cargar un ficheiro, di "aquí, por favor, cárgueo a S3". Cando queira recibilo, di: "Aquí está unha ligazón ao S3 de volta e cólleo de aquí". Isto é ideal.
Se de súpeto por algún motivo esta opción ideal non é axeitada, tes unha aplicación que non escribiches, non desenvolves ou é algún tipo de legado terrible, non pode usar o protocolo S3, senón que debe traballar con directorios locais en cartafoles locais. Fai algo máis ou menos sinxelo e implementa Kubernetes. É dicir, esgrimir inmediatamente a Ceph para algunhas tarefas mínimas, paréceme, é unha mala idea. Porque Ceph, por suposto, é bo e de moda. Pero se realmente non entendes o que estás a facer, entón unha vez que poñas algo en Ceph, podes sacarlo de aí de xeito moi sinxelo e nunca máis. Porque, como sabes, Ceph almacena os datos no seu clúster en forma binaria, e non en forma de ficheiros simples. Polo tanto, se de súpeto o clúster Ceph rompe, hai unha probabilidade total e alta de que nunca máis volvas obter os teus datos desde alí.
Teremos un curso de Ceph, podes .
Polo tanto, é mellor facer algo sinxelo como un servidor NFS. Kubernetes pode traballar con eles, pode montar un directorio nun servidor NFS - a súa aplicación é como un directorio local. Ao mesmo tempo, naturalmente, cómpre comprender que, de novo, cómpre facer algo co seu NFS, cómpre comprender que ás veces pode chegar a ser inaccesible e considerar a cuestión do que fará neste caso. Quizais debería facerse unha copia de seguranza nalgún lugar nunha máquina separada.
O seguinte punto do que falei é que facer se a súa aplicación xera algúns ficheiros durante a operación. Por exemplo, cando se inicia, xera algún ficheiro estático, que se basea nalgunha información que a aplicación recibe só no momento do lanzamento. Que momento. Se non hai moitos datos deste tipo, entón non tes que preocuparte en absoluto, simplemente instala esta aplicación por ti mesmo e traballa. A única pregunta aquí é que, mira. Moitas veces, todo tipo de sistemas legados, como WordPress e así por diante, especialmente con algún tipo de complementos intelixentes modificados, desenvolvedores de PHP intelixentes, moitas veces saben como facelo para xerar algún tipo de ficheiro por si mesmos. En consecuencia, un xera un ficheiro, o segundo xera un segundo ficheiro. Son diferentes. O equilibrio ocorre no clúster de Kubernetes dos clientes simplemente por casualidade. En consecuencia, resulta que non saben como traballar xuntos por exemplo. Un dá unha información, o outro dálle outra información ao usuario. Isto é o que debes evitar. É dicir, en Kubernetes, todo o que lances está garantido para poder funcionar en varias instancias. Porque Kubernetes é algo en movemento. En consecuencia, pode mover calquera cousa, cando queira, sen preguntarlle a ninguén. Polo tanto, cómpre contar con isto. Todo o que se lance nunha instancia fallará tarde ou cedo. Cantas máis reservas teñas, mellor. Pero de novo, digo, se tes algúns ficheiros deste tipo, podes poñelos debaixo de ti, pesan unha pequena cantidade. Se hai un pouco máis deles, probablemente non deberías empurralos dentro do recipiente.
Aconsello que hai unha cousa tan marabillosa en Kubernetes, podes usar o volume. En particular, hai un volume de tipo dir baleiro. É dicir, é só que Kubernetes creará automaticamente un directorio nos seus directorios de servizos no servidor onde comezaches. E darachelo para que o uses. Só hai un punto importante. É dicir, os teus datos non se almacenarán dentro do contedor, senón no host no que estás a executar. Ademais, Kubernetes pode controlar estes directorios baleiros baixo a configuración normal e é capaz de controlar o seu tamaño máximo e non permitir que se supere. O único punto é que o que escribiu no directorio baleiro non se perde durante o reinicio do pod. É dicir, se o teu pod cae por erro e volve subir, a información do directorio baleiro non irá a ningún lado. Pode usalo de novo nun novo comezo, e iso é bo. Se a túa vaina sae dalgún lugar, naturalmente marchará sen datos. É dicir, en canto desaparece o pod do nodo onde foi lanzado co directorio baleiro, elimínase o directorio baleiro.
Que máis ten de bo o directorio baleiro? Por exemplo, pódese usar como caché. Imaxinemos que a nosa aplicación xera algo sobre a marcha, dállo aos usuarios e faino durante moito tempo. Por iso, a aplicación, por exemplo, xéraa e entrégaa aos usuarios e, ao mesmo tempo, gárdaa nalgún lugar, de xeito que a próxima vez que o usuario veña polo mesmo, será máis rápido darlla inmediatamente xerada. Pódese solicitar a Kubernetes o directorio baleiro para que o cree na memoria. E, polo tanto, as túas cachés poden funcionar xeralmente á velocidade do lóstrego, en termos de velocidade de acceso ao disco. É dicir, tes un directorio baleiro na memoria, no SO gárdase na memoria, pero para ti, para o usuario dentro do pod, parece só un directorio local. Non necesitas a aplicación para ensinar específicamente ningunha maxia. Simplemente colles e colocas directamente o teu ficheiro nun directorio, pero, de feito, na memoria do SO. Esta é tamén unha característica moi conveniente en termos de Kubernetes.
Que problemas ten Minio? O principal problema de Minio é que para que isto funcione, ten que estar funcionando nalgún lugar e debe haber algún tipo de sistema de ficheiros, é dicir, almacenamento. E aquí atopamos os mesmos problemas que ten Ceph. É dicir, Minio debe almacenar os seus ficheiros nalgún lugar. É simplemente unha interface HTTP para os teus ficheiros. Ademais, a funcionalidade é claramente máis pobre que a do S3 de Amazon. Anteriormente, non era capaz de autorizar correctamente o usuario. Agora, polo que sei, xa pode crear baldes con diferentes autorizacións, pero de novo, paréceme que o principal problema é, por así dicir, o sistema de almacenamento subxacente como mínimo.
Como afecta o directorio baleiro na memoria aos límites? Non afecta os límites de ningún xeito. Atópase na memoria do host, e non na memoria do teu recipiente. É dicir, o teu contedor non ve o directorio baleiro na memoria como parte da súa memoria ocupada. O anfitrión ve isto. En consecuencia, si, desde o punto de vista de kubernetes, cando comeces a usar isto, sería bo entender que estás dedicando parte da túa memoria ao directorio baleiro. E, en consecuencia, entende que a memoria pode esgotarse non só polas aplicacións, senón tamén porque alguén escribe nestes directorios baleiros.
Nubosidade
E o subtema final é o que é Cloudnative. Por que é necesario? Cloudnativeness e así por diante.
É dicir, aquelas aplicacións que son capaces e escritas para funcionar nunha infraestrutura moderna de nube. Pero, de feito, Cloudnative ten outro aspecto deste tipo. Que esta non só é unha aplicación que ten en conta todos os requisitos dunha moderna infraestrutura de nube, senón que tamén sabe como traballar con esta moderna infraestrutura de nube, aproveite as vantaxes e inconvenientes de que funcione nestas nubes. Non te limites a traballar nas nubes, senón que aproveita os beneficios de traballar na nube.
Tomemos só Kubernetes como exemplo. A túa aplicación estase executando en Kubernetes. A súa aplicación sempre pode, ou mellor dito os administradores da súa aplicación, sempre poden crear unha conta de servizo. É dicir, unha conta para a autorización no propio Kubernetes no seu servidor. Engade alí algúns dereitos que necesitamos. E podes acceder a Kubernetes desde a túa aplicación. Que podes facer deste xeito? Por exemplo, desde a aplicación, recibe datos sobre onde se atopan as outras aplicacións, outras instancias similares e, se hai esa necesidade, agrupanse enriba de Kubernetes.
De novo, tivemos literalmente un caso recentemente. Temos un controlador que supervisa a cola. E cando aparecen algunhas tarefas novas nesta cola, vai a Kubernetes e, dentro de Kubernetes, crea un novo pod. Dálle a este pod algunha tarefa nova e, no marco deste pod, realiza a tarefa, envía unha resposta ao propio controlador e, a continuación, o controlador fai algo con esta información. Por exemplo, engade unha base de datos. É dicir, de novo, esta é unha vantaxe do feito de que a nosa aplicación se executa en Kubernetes. Podemos usar a propia funcionalidade integrada de Kubernetes para ampliar dalgún xeito e facer que a funcionalidade da nosa aplicación sexa máis cómoda. É dicir, non ocultar algún tipo de maxia sobre como lanzar unha aplicación, como lanzar un traballador. En Kubernetes, simplemente envía unha solicitude na aplicación se a aplicación está escrita en Python.
O mesmo se aplica se imos máis aló de Kubernetes. Temos o noso Kubernetes funcionando nalgún lugar; é bo se está nalgún tipo de nube. De novo, podemos usar, e mesmo deberíamos, creo, usar as capacidades da propia nube onde estamos a executar. Dende as cousas elementais que nos proporciona a nube. Balancing, é dicir, podemos crear equilibradores de nube e utilizalos. Esta é unha vantaxe directa do que podemos usar. Porque o equilibrio na nube, en primeiro lugar, simplemente quítanos a responsabilidade de como funciona, como está configurado. Ademais, é moi cómodo, porque os Kubernetes normais poden integrarse coas nubes.
O mesmo ocorre coa escala. Os Kubernetes habituais poden integrarse cos provedores de nube. Sabe entender que se o clúster queda sen nodos, é dicir, se esgotou o espazo dos nodos, entón cómpre engadir: o propio Kubernetes engadirá novos nodos ao seu clúster e comezará a lanzar pods neles. É dicir, cando chega a túa carga, o número de fogares comeza a aumentar. Cando os nodos do clúster se esgotan para estes pods, Kubernetes lanza novos nodos e, en consecuencia, o número de pods aínda pode aumentar. E é moi cómodo. Esta é unha oportunidade directa para escalar o clúster sobre a marcha. Non moi rápido, no sentido de que non é un segundo, é máis ben un minuto para engadir novos nodos.
Pero pola miña experiencia, de novo, é o máis chulo que vin. Cando o clúster Cloudnative escalou en función da hora do día. Era un servizo de backend que era usado por persoas do back office. É dicir, chegan ao traballo ás 9 da mañá, comezan a iniciar sesión no sistema e, en consecuencia, o clúster Cloudnative, onde está todo en execución, comeza a incharse, lanzando novos pods para que todos os que veñan traballar poidan traballar coa aplicación. Cando saen do traballo ás 8 ou ás 6 horas, os clústeres de Kubernetes notan que xa ninguén está a usar a aplicación e comezan a diminuír. Garántese un aforro de ata un 30 por cento. Funcionaba en Amazon naquel momento; naquel momento non había ninguén en Rusia que puidese facelo tan ben.
Dígoche directamente, o aforro é do 30 por cento simplemente porque usamos Kubernetes e aproveitamos as capacidades da nube. Agora isto pódese facer en Rusia. Non farei publicidade a ninguén, por suposto, pero digamos que hai provedores que poden facelo, proporcionalo desde a caixa cun botón.
Hai un último punto sobre o que tamén me gustaría chamar a súa atención. Para que a súa aplicación, a súa infraestrutura sexa Cloudnative, ten sentido comezar finalmente a adaptar o enfoque denominado Infraestrutura como Código. É dicir, isto significa que a súa aplicación, ou máis ben a súa infraestrutura, é necesaria exactamente do mesmo xeito que a código Describe a túa aplicación, a túa lóxica empresarial en forma de código. E traballar con el como código, é dicir, probalo, desenrolalo, gárdao en git, aplícalle CICD.
E isto é exactamente o que che permite, en primeiro lugar, ter sempre control sobre a túa infraestrutura, comprender sempre en que estado se atopa. En segundo lugar, evite operacións manuais que causen erros. En terceiro lugar, evita simplemente o que se chama rotación, cando necesitas realizar constantemente as mesmas tarefas manuais. En cuarto lugar, permítelle recuperar moito máis rápido en caso de falla. En Rusia, cada vez que falo disto, sempre hai un gran número de persoas que din: "Si, está claro, pero tes enfoques, en resumo, non hai que arranxar nada". Pero é certo. Se algo está roto na túa infraestrutura, entón desde o punto de vista do enfoque Cloudnative e desde o punto de vista da infraestrutura como código, en lugar de solucionalo, ir ao servidor, descubrir o que está roto e solucionalo, é máis fácil. para eliminar o servidor e crealo de novo. E terei todo isto restaurado.
Todas estas cuestións son tratadas con máis detalle en . Seguindo a ligazón podes familiarizarte co programa e as condicións. O cómodo é que podes dominar Kubernetes estudando desde casa ou traballando durante 1-2 horas ao día.
Fonte: www.habr.com