Avui tinc previst parlar de com escriure aplicacions i quins són els requisits perquè la vostra aplicació funcioni bé a Kubernetes. Perquè no hi hagi maldecaps amb l'aplicació, perquè no hagis d'inventar i construir cap "cratch" al seu voltant, i tot funciona com pretenia Kubernetes.
Aquesta conferència forma part de "" Podeu veure les conferències teòriques obertes de l'Escola del Vespre . Per a aquells que prefereixen el text més que el vídeo, hem preparat aquest article.
Em dic Pavel Selivanov, actualment sóc l'enginyer líder de DevOps a Mail.ru Cloud Solutions, fem núvols, fem gestió de kubernetes, etc. Les meves tasques ara inclouen l'assistència en el desenvolupament, el desplegament d'aquests núvols, el desplegament de les aplicacions que escrivim i el desenvolupament directe de les eines que oferim als nostres usuaris.
He estat fent DevOps, crec que durant els últims, probablement, tres anys. Però, en principi, fa uns cinc anys que faig el que fa DevOps. Abans d'això, estava principalment involucrat en coses d'administrador. Vaig començar a treballar amb Kubernetes fa molt de temps; probablement han passat uns quatre anys des que vaig començar a treballar-hi.
En general, vaig començar quan Kubernetes era la versió 1.3, probablement, i potser 1.2, quan encara estava en la seva infància. Ara ja no està en els seus inicis, i és obvi que hi ha una gran demanda al mercat d'enginyers que els agradaria poder fer Kubernetes. I les empreses tenen una demanda molt alta d'aquestes persones. Per tant, de fet, va aparèixer aquesta conferència.
Si parlem del pla del que parlaré, es veu així, entre parèntesis hi ha escrit (TL;DR) - “massa llarg; no llegiu". La meva presentació d'avui constarà d'interminables llistes.
De fet, a mi mateix no m'agraden aquestes presentacions quan es fan, però aquest és un tema tal que quan estava preparant aquesta presentació, simplement no vaig saber com organitzar aquesta informació de manera diferent.
Perquè, en general, aquesta informació és “ctrl+c, ctrl+v”, de, entre altres coses, el nostre Wiki a la secció DevOps, on hem escrit els requisits per als desenvolupadors: “ nois, perquè llancem la vostra aplicació en Kubernetes, hauria de ser així".
És per això que la presentació va resultar ser una llista tan gran. Ho sento. Intentaré explicar el màxim possible perquè no sigui avorrit si és possible.
Què mirarem ara:
- aquests són, en primer lloc, els registres (registres d'aplicacions?), què fer amb ells a Kubernetes, què fer-hi, què haurien de ser;
- què fer amb les configuracions a Kubernetes, quines són les millors i les pitjors maneres de configurar una aplicació per a Kubernetes;
- Parlem de què són les comprovacions d'accessibilitat en general, com haurien de ser;
- parlem del que és un tancament gràcil;
- tornem a parlar de recursos;
- Tornem a tocar el tema de l'emmagatzematge de dades;
- i al final us explicaré quin és el terme d'aquesta misteriosa aplicació nativa del núvol. Cloudnativeness, com a adjectiu d'aquest terme.
Registres
Suggereixo començar pels registres, per on cal introduir aquests registres a Kubernetes. Ara heu llançat una aplicació a Kubernetes. Segons els clàssics, les aplicacions anteriors sempre escrivien registres en algun lloc d'un fitxer. Les aplicacions dolentes van escriure registres en un fitxer al directori inicial del desenvolupador que va iniciar l'aplicació. Les bones aplicacions van escriure registres en un fitxer en algun lloc /var/log.
En conseqüència, a més, els bons administradors tenien algunes coses configurades a les seves infraestructures que aquests registres podien girar: el mateix rsyslog, que mira aquests registres i quan els passa alguna cosa, n'hi ha molts, crea còpies de seguretat, hi posa registres. , elimina fitxers antics, més d'una setmana, sis mesos i alguns més. En teoria, hauríem de tenir disposicions perquè només perquè l'aplicació escrigui registres, l'espai als servidors de producció (servidors de combat?) no s'esgoti. I, en conseqüència, tota la producció no es va aturar a causa dels troncs.
Quan ens movem al món de Kubernetes i hi executem el mateix, el primer que pots parar atenció és el fet que la gent, mentre escrivia registres en un fitxer, segueix escrivint-los.
Resulta que si parlem de Kubernetes, el lloc adequat per escriure registres en algun lloc des d'un contenidor docker és simplement escriure'ls des de l'aplicació a l'anomenat Stdout/Stderr, és a dir, els fluxos de sortida estàndard del sistema operatiu, la sortida d'error estàndard. Aquesta és la manera més correcta, senzilla i lògica de posar els registres en principi a Docker i concretament a Kubernetis. Perquè si la vostra aplicació escriu registres a Stdout/Stderr, depèn de Docker i del complement de Kubernetes decidir què fer amb aquests registres. Docker crearà per defecte els seus fitxers especials en format JSON.
Aquí sorgeix la pregunta, què faràs després amb aquests registres? La manera més fàcil és clara, tenim la capacitat de fer-ho kubectl logs i mireu aquests registres d'aquestes "beines". Però, probablement, aquesta no és una opció molt bona: cal fer una altra cosa amb els registres.
De moment, parlem al mateix temps, ja que vam tocar el tema dels registres, d'una cosa com els registres haurien de semblar. És a dir, això no s'aplica directament a Kubernetes, però quan comencem a pensar què fer amb els registres, estaria bé pensar-hi també.
Necessitem algun tipus d'eina, de manera amistosa, que agafi aquests registres que el nostre docker posa als seus fitxers i els enviï a algun lloc. En general, normalment llancem algun tipus d'agent dins de Kubernetes en forma de DaemonSet: un col·lector de registres, al qual simplement se li indica on es troben els registres que recull Docker. I aquest agent de recollida simplement els pren, potser fins i tot d'alguna manera els analitza al llarg del camí, potser els enriqueix amb alguna metainformació addicional i, en última instància, els envia per emmagatzemar-los en algun lloc. Les variacions ja són possibles allà. El més comú és probablement Elasticsearch, on podeu emmagatzemar registres i podeu recuperar-los còmodament des d'allà. Després, utilitzant una sol·licitud, utilitzant Kibana, per exemple, creeu gràfics basats en ells, creeu alertes basades en ells, etc.
La idea més important, vull repetir-ho de nou, és que dins de Docker, en particular dins de Kubernetes, emmagatzemar els vostres registres en un fitxer és una molt mala idea.
Perquè en primer lloc, és difícil aconseguir els registres dins del contenidor en un fitxer. Primer heu d'anar al contenidor, executar-hi i després mirar els registres. El següent punt és que si teniu registres en un fitxer, els contenidors solen tenir un entorn minimalista i no hi ha utilitats que normalment es necessiten per al treball normal amb els registres. Enterreu-los, mireu-los, obriu-los en un editor de text. El següent moment és quan tenim registres en un fitxer dins d'un contenidor, si s'elimina aquest contenidor, enteneu, els registres moriran juntament amb ell. En conseqüència, qualsevol reinici del contenidor significa que no hi ha més registres. De nou, mala opció.
I l'últim punt és que dins dels contenidors normalment teniu la vostra aplicació i ja està: normalment és l'únic procés que s'executa. No es parla en absolut de cap procés que rotaria els fitxers amb els vostres registres. Tan bon punt es comencin a escriure els registres en un fitxer, això vol dir que, perdoneu, començarem a perdre el servidor de producció. Perquè, en primer lloc, són difícils de trobar, ningú els fa un seguiment, a més ningú els controla; en conseqüència, el fitxer creix sense parar fins que simplement s'esgota l'espai al servidor. Per tant, torno a dir que iniciar sessió a Docker, en particular a Kubernetes, en un fitxer és una mala idea.
El següent punt, aquí vull tornar a parlar d'això: ja que estem tocant el tema dels registres, seria bo parlar de com haurien de ser els registres per tal que sigui convenient treballar-hi. Com he dit, el tema no està directament relacionat amb Kubernetes, però es relaciona molt bé amb el tema de DevOps. Sobre el tema de la cultura del desenvolupament i l'amistat entre aquests dos departaments diferents: Dev i Ops, perquè tothom estigui còmode.
Això vol dir que, idealment, avui en dia, els registres haurien d'escriure's en format JSON. Si teniu alguna aplicació pròpia incomprensible, que escriu registres en formats incomprensibles perquè inseriu algun tipus d'impressió o alguna cosa així, aleshores és el moment de buscar a Google algun tipus de framework, algun tipus d'embolcall que us permeti implementar el registre normal; habiliteu els paràmetres de registre a JSON allà, perquè JSON és un format senzill, analitzar-lo és senzill.
Si el vostre JSON no funciona segons alguns criteris, ningú sap què, almenys escriu registres en un format que es pugui analitzar. Aquí, més aviat, val la pena pensar en el fet que, per exemple, si esteu executant un munt de contenidors o només processos amb nginx, i cadascun té la seva pròpia configuració de registre, probablement sembla que us serà molt inconvenient analitzar-los. Perquè per a cada nova instància de nginx heu d'escriure el vostre propi analitzador, perquè escriuen els registres de manera diferent. De nou, probablement valia la pena pensar en assegurar-se que totes aquestes instàncies nginx tinguessin la mateixa configuració de registre i escrivissin tots els seus registres de manera absolutament uniforme. El mateix s'aplica a absolutament totes les aplicacions.
Al final, també vull afegir combustible al foc que, idealment, s'haurien d'evitar els registres de format multilínia. Aquí està la cosa: si alguna vegada heu treballat amb col·leccionistes de registres, és molt probable que hàgiu vist el que us prometen, que poden treballar amb registres de diverses línies, saber com recollir-los, etc. De fet, al meu entendre, avui dia ni un sol col·leccionista pot recollir registres de diverses línies amb normalitat, completament i sense errors. D'una manera humana, perquè sigui convenient i sense errors.
Però el rastre de la pila sempre és registres de diverses línies i com evitar-los. La pregunta aquí és que un registre és un registre d'un esdeveniment, i stactrace no és realment un registre. Si recollim registres i els col·loquem en algun lloc d'Elasticsearch i després en dibuixem gràfics, creem alguns informes de l'activitat dels usuaris al vostre lloc, aleshores, quan obtingueu un rastre de la pila, vol dir que està passant alguna cosa inesperada, una situació no gestionada a la vostra aplicació. I té sentit carregar automàticament una traça de pila en algun lloc d'un sistema que pugui fer-ne un seguiment.
Aquest és un programari (el mateix Sentry) que està fet específicament per treballar amb traça de pila. Pot crear tasques automatitzades immediatament, assignar-les a algú, alertar quan es produeixen traces d'estat, agrupar-les per un tipus, etc. En principi, no té gaire sentit parlar d'estactraces quan parlem de registres, perquè al cap i a la fi són coses diferents amb finalitats diferents.
Configuració
A continuació parlem de la configuració a Kubernetes: què fer amb ella i com s'han de configurar les aplicacions dins de Kubernetes. En general, acostumo a dir que Docker no tracta de contenidors. Tothom sap que Docker tracta de contenidors, fins i tot aquells que no han treballat gaire amb Docker. Repeteixo, Docker no es tracta de contenidors.
Docker, al meu entendre, tracta d'estàndards. I hi ha estàndards per a pràcticament tot: estàndards per construir la vostra aplicació, estàndards per instal·lar la vostra aplicació.
I aquesta cosa, la vam fer servir abans, es va fer especialment popular amb l'arribada dels contenidors; aquesta cosa s'anomena variables d'entorn (ENV), és a dir, variables d'entorn que es troben al vostre sistema operatiu. En general, aquesta és una manera ideal de configurar la vostra aplicació, perquè si teniu aplicacions en JAVA, Python, Go, Perl, Déu n'hi do, i tots poden llegir l'amfitrió de la base de dades, l'usuari de la base de dades, les variables de la contrasenya de la base de dades, és ideal. Tens aplicacions en quatre idiomes diferents configurades al pla de la base de dades de la mateixa manera. Ja no hi ha configuracions diferents.
Tot es pot configurar mitjançant variables ENV. Quan parlem de Kubernetes, hi ha una manera fantàstica de declarar variables ENV dins de Deployment. En conseqüència, si parlem de dades secretes, podem enviar immediatament dades secretes de variables ENV (contrasenyes a bases de dades, etc.) a un secret, crear un clúster secret i indicar a la descripció d'ENV a Deployment que no estem declarant directament. el valor d'aquesta variable i el valor d'aquesta variable de contrasenya de base de dades es llegiran del secret. Aquest és el comportament estàndard de Kubernetes. I aquesta és l'opció més ideal per configurar les teves aplicacions. Només a nivell de codi, de nou això s'aplica als desenvolupadors. Si sou DevOps, podeu preguntar: "Nois, ensenyeu a la vostra aplicació a llegir variables d'entorn. I tots serem feliços".
Si tothom a l'empresa llegeix les mateixes variables d'entorn amb nom, això és genial. Perquè no succeeixi que alguns estan esperant la base de dades postgres, altres estan esperant el nom de la base de dades, altres estan esperant una altra cosa, altres estan esperant un dbn d'algun tipus, de manera que, en conseqüència, hi hagi uniformitat.
El problema ve quan teniu tantes variables d'entorn que acabeu d'obrir el desplegament, i hi ha cinc-centes línies de variables d'entorn. En aquest cas, simplement heu superat les variables d'entorn i ja no necessiteu torturar-vos. En aquest cas, tindria sentit començar a utilitzar les configuracions. És a dir, entrenar la vostra aplicació per utilitzar les configuracions.
L'única pregunta és que les configuracions no són el que penses. Config.pi no és una configuració convenient d'utilitzar. O alguna configuració en el vostre propi format, alternativament dotada; aquesta tampoc no és la configuració que vull dir.
Del que parlo és de configuració en formats acceptables, és a dir, l'estàndard més popular, amb diferència, és l'estàndard .yaml. És clar com llegir-lo, és llegible per l'home, és clar com llegir-lo des de l'aplicació.
En conseqüència, a més de YAML, també podeu, per exemple, utilitzar JSON, l'anàlisi és tan convenient com YAML pel que fa a la lectura de la configuració de l'aplicació des d'allà. És notablement més incòmode per a la gent llegir. Podeu provar el format, a la ini. És bastant còmode de llegir, des d'un punt de vista humà, però pot ser inconvenient processar-lo automàticament, en el sentit que si mai voleu generar les vostres pròpies configuracions, el format ini ja pot ser incòmode de generar.
Però en qualsevol cas, sigui quin sigui el format que trieu, la qüestió és que des del punt de vista de Kubernetes és molt convenient. Podeu posar tota la vostra configuració dins de Kubernetes, al ConfigMap. A continuació, agafeu aquest mapa de configuració i demaneu-lo que es munti dins del vostre pod en algun directori específic, on la vostra aplicació llegirà la configuració d'aquest mapa de configuració com si només fos un fitxer. Això, de fet, és el que és bo fer quan teniu moltes opcions de configuració a la vostra aplicació. O és només una mena d'estructura complexa, hi ha nidificació.
Si teniu un mapa de configuració, podeu ensenyar molt bé la vostra aplicació, per exemple, a fer un seguiment automàtic dels canvis al fitxer on està muntat el mapa de configuració i també tornar a carregar automàticament l'aplicació quan canvien les configuracions. En general, aquesta seria una opció ideal.
Un cop més, ja vaig parlar d'això: la informació secreta no està al mapa de configuració, la informació secreta no està en variables, la informació secreta no està en secrets. A partir d'aquí, connecteu aquesta informació secreta amb la diplomàcia. Normalment emmagatzemem totes les descripcions d'objectes Kubernetes, desplegaments, mapes de configuració i serveis a git. En conseqüència, posar la contrasenya a la base de dades a git, encara que sigui el vostre git, que teniu internament a l'empresa, és una mala idea. Perquè, com a mínim, git ho recorda tot i simplement eliminar les contrasenyes d'allà no és tan fàcil.
Revisió de salut
El següent punt és això que es diu comprovació de salut. En general, una comprovació de salut és simplement comprovar que la vostra aplicació funciona. Al mateix temps, més sovint estem parlant de determinades aplicacions web, per a les quals, en conseqüència, des del punt de vista de la comprovació de salut (més millor no traduir aquí i més enllà) aquesta serà una URL especial, que processen com a un estàndard, solen fer-ho /health.
En accedir a aquesta URL, per tant, la nostra aplicació diu "sí, d'acord, tot està bé per a mi, 200" o "no, tot no està bé per a mi, uns 500". En conseqüència, si la nostra aplicació no és http, no és una aplicació web, ara estem parlant d'algun tipus de dimoni, podem esbrinar com fer controls de salut. És a dir, no és necessari, si l'aplicació no és http, tot funciona sense un control de salut i això no es pot fer de cap manera. Podeu actualitzar periòdicament alguna informació del fitxer, podeu crear alguna ordre especial per al vostre dimoni, com ara, daemon status, que dirà "sí, tot està bé, el dimoni funciona, està viu".
Per a què serveix? La primera i la més òbvia és probablement la raó per la qual cal una revisió de salut: per entendre que l'aplicació funciona. Vull dir, és estúpid, quan està a punt ara, sembla que està funcionant, així que pots estar segur que està funcionant. I resulta que l'aplicació s'està executant, el contenidor s'està executant, la instància funciona, tot està bé, i aleshores els usuaris ja han tallat tots els números de telèfon del suport tècnic i diuen "què ets..., tu m'he adormit, res no funciona".
Un control de salut és només una manera de veure des del punt de vista de l'usuari que funciona. Un dels mètodes. Posem-ho així. Des del punt de vista de Kubernetes, aquesta també és una manera d'entendre quan s'inicia l'aplicació, perquè entenem que hi ha una diferència entre quan es va llançar, es va crear i es va iniciar el contenidor i quan l'aplicació es va llançar directament en aquest contenidor. Perquè si agafem una aplicació Java mitjana i intentem llançar-la al moll, durant quaranta segons, o fins i tot un minut, o fins i tot deu, pot començar bé. En aquest cas, almenys podeu trucar als seus ports, no hi respondrà, és a dir, encara no està preparat per rebre trànsit.
De nou, amb l'ajuda d'un control de salut i amb l'ajuda del fet que estem recorrent aquí, podem entendre a Kubernetes que no només el contenidor ha pujat a l'aplicació, sinó que l'aplicació en si s'ha iniciat, ja respon al control de salut, el que significa que podem enviar trànsit allà.
Del que parlo ara s'anomena Proves de preparació/vivència dins de Kubernetes; en conseqüència, les nostres proves de preparació són responsables de la disponibilitat de l'aplicació en l'equilibri. És a dir, si es realitzen proves de preparació a l'aplicació, tot està bé, el trànsit del client va a l'aplicació. Si no es realitzen proves de preparació, l'aplicació simplement no participa, aquesta instància en particular no participa en l'equilibri, s'elimina de l'equilibri i el trànsit del client no flueix. En conseqüència, calen proves de Liveness dins de Kubernetes perquè si l'aplicació s'encalla, es pugui reiniciar. Si la prova de vivacitat no funciona per a una aplicació que es declara a Kubernetes, l'aplicació no només s'elimina de l'equilibri, sinó que es reinicia.
I aquí hi ha un punt important que m'agradaria esmentar: des d'un punt de vista pràctic, la prova de preparació s'acostuma a utilitzar més sovint i és més necessària que la prova de vivacitat. És a dir, simplement declarar sense pensar tant les proves de preparació com de vivacitat, perquè Kubernetes pot fer-ho, i fem servir tot el que pot fer, no és una bona idea. Explicaré per què. Perquè el punt número dos de les proves és que seria una bona idea comprovar el servei subjacent als vostres controls de salut. Això vol dir que si es disposa d'una aplicació web que ofereix alguna informació, que al seu torn aquesta, naturalment, ha d'agafar d'algun lloc. En una base de dades, per exemple. Bé, desa la informació que entra a aquesta API REST a la mateixa base de dades. Aleshores, en conseqüència, si el vostre control de salut respon simplement com un slashhealth contactat, l'aplicació diu "200, d'acord, tot està bé" i, alhora, la base de dades de la vostra aplicació és inaccessible i l'aplicació de control de salut diu "200, d'acord, tot està bé". ” - Això és un mal control de salut. No és així com hauria de funcionar.
És a dir, la teva sol·licitud, quan hi arriba una sol·licitud /health, no només respon "200, d'acord", primer va, per exemple, a la base de dades, intenta connectar-s'hi, fa alguna cosa molt bàsica allà, com seleccionar-ne una, només comprova que hi hagi una connexió a la base de dades. base de dades i podeu consultar la base de dades. Si tot això va tenir èxit, la resposta és "200, d'acord". Si no té èxit, diu que hi ha un error, la base de dades no està disponible.
Per tant, en aquest sentit, torno de nou a les proves de preparació/vivència: per què probablement necessiteu una prova de preparació, però una prova de vivacitat està en qüestió. Perquè si descriu els controls de salut exactament com acabo de dir, resultarà que no està disponible a la part de la instànciaв или со всех instanceen una base de dades, per exemple. Quan vau declarar una prova de preparació, els nostres controls de salut van començar a fallar i, en conseqüència, totes les aplicacions des de les quals no es pot accedir a la base de dades, simplement es desactiven de l'equilibri i, de fet, es "pengen" només en un estat descuidado i esperen que les seves bases de dades treball.
Si hem declarat una prova de vivacitat, imagineu-vos que la nostra base de dades s'ha trencat i al vostre Kubernetes la meitat de tot comença a reiniciar-se perquè la prova de vivacitat falla. Això vol dir que cal reiniciar. Això no és gens el que vols, fins i tot vaig tenir experiència personal a la pràctica. Teníem una aplicació de xat escrita en JS i introduïda a una base de dades Mongo. I el problema va ser que va ser al principi del meu treball amb Kubernetes, vam descriure la disponibilitat, la vivacitat de les proves sobre el principi que Kubernetes pot fer-ho, així que ho farem servir. En conseqüència, en algun moment Mongo es va tornar una mica "avorrit" i la mostra va començar a fallar. En conseqüència, segons la prova de pluja, les beines van començar a "matar".
Com enteneu, quan són "assassinats", això és un xat, és a dir, hi ha moltes connexions de clients pendents. També són "assassinats" - no, no clients, només connexions - no tots alhora, i pel fet que no els maten al mateix temps, alguns abans, altres més tard, no comencen al mateix temps. temps. A més de l'atzar estàndard, no podem predir amb precisió de mil·lisegons l'hora d'inici de l'aplicació cada vegada, de manera que ho fan una instància a la vegada. S'aixeca un infospot, s'afegeix a l'equilibri, hi arriben tots els clients, no aguanta tanta càrrega, perquè està sol, i, a grans trets, n'hi ha una dotzena treballant allà, i cau. El següent s'aixeca, tota la càrrega és sobre ell, també cau. Bé, aquestes caigudes continuen caient en cascada. Al final, com es va resoldre això: només havíem d'aturar estrictament el trànsit d'usuaris a aquesta aplicació, deixar que totes les instàncies s'aixequessin i després iniciar tot el trànsit d'usuaris alhora, de manera que ja es distribuís entre les deu instàncies.
Si no s'hagués anunciat aquesta prova de vivacitat, que obligaria a reiniciar-ho tot, l'aplicació s'hauria gestionat bé. Però tot, des de l'equilibri, està desactivat per a nosaltres, perquè les bases de dades són inaccessibles i tots els usuaris han "caigut". Aleshores, quan aquesta base de dades està disponible, tot s'inclou en l'equilibri, però les aplicacions no necessiten començar de nou i no cal perdre temps i recursos en això. Tots ja són aquí, estan preparats per al trànsit, de manera que el trànsit només s'obre, tot està bé: l'aplicació està al seu lloc, tot continua funcionant.
Per tant, les proves de preparació i de vivacitat són diferents, encara que a més, teòricament podeu fer diferents controls de salut, un tipus de radi, un tipus de liv, per exemple, i comprovar coses diferents. Durant les proves de preparació, comproveu els vostres backends. I en una prova de vivacitat, per exemple, no comproveu des del punt de vista que la prova de vivacitat és generalment només una aplicació que respon, si és capaç de respondre.
Perquè la prova de vivacitat, en general, és quan estem "encallats". S'ha iniciat un bucle sense fi o alguna cosa més, i no es processen més sol·licituds. Per tant, té sentit fins i tot separar-los i implementar-hi una lògica diferent.
Pel que fa al que has de respondre quan et fas una prova, quan fas controls de salut. És realment un dolor. Els que estiguin familiaritzats amb això probablement riuran, però seriosament, he vist serveis a la meva vida que responen "200" en el XNUMX% dels casos. És a dir, qui té èxit. Però al mateix temps al cos de la resposta escriuen "tal error".
És a dir, l'estat de resposta us arriba: tot té èxit. Però al mateix temps, heu d'analitzar el cos, perquè el cos diu "ho sento, la sol·licitud va acabar amb un error" i això és només la realitat. Ho vaig veure a la vida real.
I perquè a algunes persones no els resulti graciós, i a altres els resulti molt dolorós, val la pena seguir una regla senzilla. En els controls de salut, i en principi quan es treballa amb aplicacions web.
Si tot ha anat bé, respon amb la resposta dos-centes. En principi, qualsevol resposta de dos-centes us convindrà. Si llegeixes molt bé i saps que alguns estats de resposta són diferents dels altres, respon amb els adequats: 204, 5, 10, 15, el que sigui. Si no és molt bo, llavors només "dos zero zero". Si tot va malament i la comprovació de salut no respon, respon amb una cinc centèsima qualsevol. De nou, si enteneu com respondre, com difereixen els diferents estats de resposta entre si. Si no ho enteneu, aleshores 502 és la vostra opció per respondre als controls de salut si alguna cosa va malament.
Aquest és un altre punt, vull tornar una mica sobre la comprovació dels serveis subjacents. Si comenceu, per exemple, a comprovar tots els serveis subjacents que hi ha darrere de la vostra aplicació, tot en general. El que obtenim des del punt de vista de l'arquitectura de microserveis, tenim un concepte com "acoblament baix", és a dir, quan els vostres serveis depenen mínimament els uns dels altres. Si un d'ells falla, tots els altres sense aquesta funcionalitat simplement continuaran funcionant. Algunes de les funcionalitats simplement no funcionen. En conseqüència, si lligueu tots els controls de salut entre ells, acabareu amb una cosa que cau a la infraestructura i, com que va caure, també comencen a fallar tots els controls de salut de tots els serveis, i hi ha més infraestructura en general per a la arquitectura de microservei sencera núm. Allà tot va quedar fosc.
Per tant, vull repetir-ho de nou que cal comprovar els serveis subjacents, aquells sense els quals la vostra aplicació en el cent per cent dels casos no pot fer la seva feina. És a dir, és lògic que si teniu una API REST a través de la qual l'usuari desa a la base de dades o recupera de la base de dades, a falta d'una base de dades, no podeu garantir el treball amb els vostres usuaris.
Però si els vostres usuaris, quan els traieu de la base de dades, s'enriqueixen addicionalment amb algunes altres metadades, d'un altre backend, que introduïu abans d'enviar una resposta al frontend, i aquest backend no està disponible, això vol dir que doneu el vostre resposta sense cap part de les metadades.
A continuació, també tenim un dels problemes dolorosos a l'hora de llançar aplicacions.
De fet, això no només s'aplica a Kubernetes en general; va passar que la cultura d'algun tipus de desenvolupament massiu i DevOps en particular es va començar a estendre al mateix temps que Kubernetes. Per tant, en general, resulta que cal tancar la vostra aplicació amb gràcia sense Kubernetes. Fins i tot abans de Kubernetes, la gent feia això, però amb l'arribada de Kubernetes, vam començar a parlar-ne massivament.
Apagada graciosa
En general, què és Graceful Shutdown i per què es necessita? Això és quan la vostra aplicació es bloqueja per algun motiu, heu de fer-ho app stop - o bé rebeu, per exemple, un senyal del sistema operatiu, la vostra aplicació l'ha d'entendre i fer-hi alguna cosa. El pitjor dels casos, per descomptat, és quan la vostra aplicació rep un SIGTERM i és com "SIGTERM, esperem, treballem, no fem res". Aquesta és una opció francament dolenta.
Una opció gairebé igual de dolenta és quan la vostra aplicació rep un SIGTERM i és com "van dir segterm, això vol dir que estem acabant, no he vist, no conec cap petició d'usuari, no sé quin tipus de sol·licituds en què estic treballant ara mateix, van dir SIGTERM, això vol dir que estem acabant " Aquesta també és una mala opció.
Quina opció és bona? El primer punt és tenir en compte la finalització de les operacions. Una bona opció és que el vostre servidor encara tingui en compte què fa si rep un SIGTERM.
SIGTERM és un apagat suau, està especialment dissenyat, es pot interceptar a nivell de codi, es pot processar, digues que ara, espera, primer acabarem el treball que tenim, després sortirem.
Des de la perspectiva de Kubernetes, aquest és el que sembla. Quan diem a un pod que s'està executant al clúster de Kubernetes, "si us plau, atureu-vos, aneu-ne", o ens reiniciem, o es produeix una actualització quan Kubernetes recrea els pods, Kubernetes envia el mateix missatge SIGTERM al pod, espera algun temps, i , aquest és el temps que espera, també està configurat, hi ha un paràmetre tan especial en els diplomes i es diu Graceful ShutdownTimeout. Com enteneu, no es diu així per res, i no és per res que en parlem ara.
Allà podem dir específicament quant de temps hem d'esperar entre el moment en què enviem SIGTERM a l'aplicació i quan entenem que l'aplicació sembla que s'ha tornat boja per alguna cosa o està "encallada" i no s'acabarà, i hem de envieu-lo SIGKILL, és a dir, completeu la seva feina. És a dir, en conseqüència, tenim algun tipus de dimoni en execució, que processa operacions. Entenem que, de mitjana, les nostres operacions en què treballa el dimoni no duren més de 30 segons alhora. En conseqüència, quan arriba SIGTERM, entenem que el nostre dimoni pot, com a màxim, acabar 30 segons després de SIGTERM. Ho escrivim, per exemple, 45 segons per si de cas i diem que SIGTERM. Després d'això esperem 45 segons. En teoria, durant aquest temps el dimoni hauria d'haver acabat el seu treball i acabat ell mateix. Però si de sobte no ha pogut, vol dir que el més probable és que s'hagi bloquejat: ja no processa les nostres sol·licituds amb normalitat. I en 45 segons pots, de fet, clavar-lo amb seguretat.
I aquí, de fet, fins i tot es poden tenir en compte 2 aspectes. En primer lloc, entengueu que si vau rebre una sol·licitud, vau començar a treballar-hi d'alguna manera i no vau donar resposta a l'usuari, però vau rebre SIGTERM, per exemple. Té sentit perfeccionar-lo i donar una resposta a l'usuari. Aquest és el punt número u en aquest sentit. El segon punt aquí és que si escriviu la vostra pròpia aplicació, generalment construïu l'arquitectura de manera que rebeu una sol·licitud per a la vostra aplicació, llavors comenceu a treballar, comenceu a descarregar fitxers des d'algun lloc, a baixar una base de dades, etc. Això. En general, el vostre usuari, la vostra sol·licitud es penja durant mitja hora i espera que li respongueu; llavors, molt probablement, haureu de treballar en l'arquitectura. És a dir, només tingueu en compte fins i tot el sentit comú que si les vostres operacions són curtes, llavors té sentit ignorar SIGTERM i modificar-lo. Si les vostres operacions són llargues, no té sentit ignorar SIGTERM en aquest cas. Té sentit redissenyar l'arquitectura per evitar operacions tan llargues. Perquè els usuaris no es quedin i esperen. No ho sé, feu-hi algun tipus de websocket, feu ganxos inversos que el vostre servidor ja enviarà al client, qualsevol altra cosa, però no obligueu l'usuari a penjar durant mitja hora i només espereu una sessió fins que contesta-li. Perquè és imprevisible on es podria trencar.
Quan la vostra aplicació finalitzi, hauríeu de proporcionar algun codi de sortida adequat. És a dir, si se li va demanar a la vostra aplicació que tanqués, s'aturi i s'hagués pogut aturar normalment, no cal que torneu cap tipus de codi de sortida 1,5,255 i així successivament. Qualsevol cosa que no sigui codi zero, almenys en sistemes Linux, n'estic segur, es considera que no té èxit. És a dir, es considera que la seva sol·licitud en aquest cas va acabar amb un error. En conseqüència, de manera amistosa, si la vostra sol·licitud s'ha completat sense error, dieu 0 a la sortida. Si la vostra aplicació falla per algun motiu, digueu que no és 0 a la sortida. I podeu treballar amb aquesta informació.
I l'última opció. És dolent quan el vostre usuari envia una sol·licitud i es penja durant mitja hora mentre la processeu. Però, en general, també m'agradaria dir sobre què en general val la pena per part del client. No importa si teniu una aplicació mòbil, un front-end, etc. Cal tenir en compte que en general es pot donar per finalitzada la sessió de l'usuari, pot passar qualsevol cosa. Es pot enviar una sol·licitud, per exemple, sense processar-se i no retornar cap resposta. La vostra interfície o la vostra aplicació mòbil (qualsevol interfície en general, diguem-ho així) ho hauria de tenir en compte. Si treballeu amb websockets, aquest és generalment el pitjor dolor que he tingut mai.
Quan els desenvolupadors d'alguns xats habituals no ho saben, resulta que el websocket es pot trencar. Per a ells, quan passa alguna cosa al proxy, només canviem la configuració i es torna a carregar. Naturalment, totes les sessions de llarga durada es trenquen en aquest cas. Els desenvolupadors ens venen corrents i ens diuen: "Nois, què feu, el xat s'ha trencat per a tots els nostres clients!" Els diem: “Què fas? Els vostres clients no poden tornar a connectar-se? Diuen: "No, necessitem que les sessions no es trenquin". En resum, això és realment una tonteria. Cal tenir en compte el costat del client. Sobretot, com dic, amb sessions de llarga durada com ara els websockets, es pot trencar i, sense que l'usuari s'adoni, cal poder reinstal·lar aquestes sessions. I després tot és perfecte.
Recursos
De fet, aquí només us explicaré una història clara. De nou de la vida real. La cosa més dolenta que he sentit mai sobre els recursos.
Recursos en aquest cas, vull dir, algun tipus de sol·licituds, límits que podeu posar als pods dels vostres clústers de Kubernetes. El més divertit que vaig sentir d'un desenvolupador... Un dels meus companys desenvolupadors en un lloc de treball anterior va dir una vegada: "La meva aplicació no començarà al clúster". Vaig mirar per veure que no començava, però o no encaixava en els recursos, o s'havien posat límits molt petits. En resum, l'aplicació no pot començar a causa dels recursos. Jo dic: "No començarà per recursos, tu decideixes quant necessites i estableixes un valor adequat". Ell diu: "Quin tipus de recursos?" Vaig començar a explicar-li que cal posar Kubernetes, límits a les peticions i bla, bla, bla. L'home va escoltar durant cinc minuts, va assentir i va dir: "He vingut aquí per treballar com a desenvolupador, no vull saber res de cap recurs. Vaig venir aquí per escriure codi i ja està". És trist. Aquest és un concepte molt trist des del punt de vista d'un desenvolupador. Sobretot al món modern, per dir-ho així, dels devops progressistes.
Per què es necessiten recursos? Hi ha 2 tipus de recursos a Kubernetes. Alguns s'anomenen peticions, d'altres s'anomenen límits. Per recursos entendrem que bàsicament sempre només hi ha dues restriccions bàsiques. És a dir, límits de temps de CPU i límits de RAM per a un contenidor que s'executa a Kubernetes.
Un límit posa un límit superior sobre com es pot utilitzar un recurs a la vostra aplicació. És a dir, en conseqüència, si dieu 1 GB de RAM en els límits, la vostra aplicació no podrà utilitzar més d'1 GB de RAM. I si de sobte vol i intenta fer-ho, aleshores un procés anomenat oom killer, sense memòria, és a dir, vindrà i matarà la vostra aplicació, és a dir, simplement es reiniciarà. Les aplicacions no es reiniciaran en funció de la CPU. Pel que fa a la CPU, si una aplicació intenta utilitzar molt, més del que s'especifica als límits, simplement es seleccionarà estrictament la CPU. Això no comporta reinicis. Aquest és el límit, aquest és el límit superior.
I hi ha una petició. Una sol·licitud és com Kubernetes entén com els nodes del vostre clúster de Kubernetes s'omplen amb aplicacions. És a dir, una sol·licitud és una mena de commit de la vostra sol·licitud. Diu el que vull utilitzar: "M'agradaria que reserveu tanta CPU i tanta memòria per a mi". Una analogia tan senzilla. Què passa si tenim un node que té, no ho sé, 8 CPU en total. I hi arriba un pod, les peticions del qual diuen 1 CPU, el que significa que el node té 7 CPU. És a dir, en conseqüència, tan bon punt arriben a aquest node 8 pods, cadascun dels quals té 1 CPU en les seves peticions, el node, com si des del punt de vista de Kubernetes, s'ha quedat sense CPU i no es poden fer més pods amb peticions. llançat en aquest node. Si tots els nodes es queden sense CPU, llavors Kubernetes començarà a dir que no hi ha nodes adequats al clúster per executar els vostres pods perquè la CPU s'ha esgotat.
Per què es necessiten sol·licituds i per què, sense sol·licituds, crec que no cal llançar res a Kubernetes? Imaginem una situació hipotètica. Inicieu la vostra aplicació sense sol·licituds, Kubernetes no sap quant del que teniu, a quins nodes la podeu impulsar. Bé, empeny, empènyer, empènyer als nodes. En algun moment, començareu a rebre trànsit a la vostra aplicació. I una de les aplicacions de sobte comença a utilitzar recursos fins als límits que té segons els límits. Resulta que hi ha una altra aplicació a prop i també necessita recursos. El node comença a quedar-se físicament sense recursos, per exemple, OP. El node comença a quedar-se físicament sense recursos, per exemple, memòria d'accés aleatori (RAM). Quan un node es queda sense energia, primer el docker deixarà de respondre, després el cubelet i després el sistema operatiu. Simplement quedaran inconscients i definitivament TOT deixarà de funcionar per a tu. És a dir, això farà que el vostre node s'enganxi i haureu de reiniciar-lo. En resum, la situació no és gaire bona.
I quan tens sol·licituds, els límits no són gaire diferents, almenys no moltes vegades més que els límits o les sol·licituds, llavors pots tenir un emplenat tan normal i racional d'aplicacions als nodes dels clústers de Kubernetes. Al mateix temps, Kubernetes és aproximadament conscient de quant del que posa on, quant del que s'utilitza on. És a dir, només és un moment així. És important entendre-ho. I és important controlar que això estigui indicat.
Emmagatzematge de dades
El nostre següent punt és sobre l'emmagatzematge de dades. Què fer amb ells i, en general, què fer amb la persistència a Kubernetes?
Crec, de nou, dins del nostre , hi havia un tema sobre la base de dades a Kubernetes. I em sembla que fins i tot sé aproximadament el que us van dir els vostres companys quan li van preguntar: "És possible executar una base de dades a Kubernetes?" Per alguna raó, em sembla que els vostres companys haurien d'haver-vos dit que si us pregunteu si és possible executar una base de dades a Kubernetes, és impossible.
La lògica aquí és senzilla. Per si de cas, us explicaré una vegada més, si sou un noi genial que pot crear un sistema d'emmagatzematge de xarxa distribuït bastant tolerant a errors, enteneu com s'ajusta una base de dades en aquest cas, com hauria de funcionar el núvol natiu als contenidors. en una base de dades en general. El més probable és que no tingueu cap dubte sobre com executar-lo. Si teniu una pregunta així i voleu assegurar-vos que tot es desenvolupi i es mantingui fins a la mort en producció i no cau mai, això no passa. Amb aquest enfocament, teniu la garantia de disparar-vos al peu. Així que és millor no fer-ho.
Què hem de fer amb les dades que voldria emmagatzemar la nostra aplicació, algunes imatges que pengen els usuaris, algunes coses que la nostra aplicació genera durant el seu funcionament, a l'inici, per exemple? Què fer amb ells a Kubernetes?
En general, l'ideal és que sí, és clar, Kubernetes està molt ben dissenyat i, en general, es va concebre inicialment per a aplicacions sense estat. És a dir, per a aquelles aplicacions que no emmagatzemen informació en absolut. Això és ideal.
Però, per descomptat, l'opció ideal no sempre existeix. I què? El primer i més senzill punt és prendre algun tipus de S3, no només un fet a casa, que tampoc no està clar com funciona, sinó d'algun proveïdor. Un bon proveïdor normal i ensenya la teva aplicació a utilitzar S3. És a dir, quan el vostre usuari vulgui carregar un fitxer, digueu "aquí, si us plau, carregueu-lo a S3". Quan el vulgui rebre, digueu: "Aquí teniu un enllaç a l'S3 i agafa-lo des d'aquí". Això és ideal.
Si de sobte per alguna raó aquesta opció ideal no és adequada, tens una aplicació que no has escrit, no desenvolupes o és una mena de llegat terrible, no pot utilitzar el protocol S3, sinó que ha de funcionar amb directoris locals en carpetes locals. Preneu alguna cosa més o menys senzilla, implementeu Kubernetes. És a dir, em sembla una mala idea esgrimir immediatament Ceph per a algunes tasques mínimes. Perquè Ceph, és clar, és bo i està de moda. Però si no enteneu realment el que esteu fent, aleshores, un cop hàgiu posat alguna cosa a Ceph, podreu tornar-lo a treure d'allà de manera molt fàcil i senzillament mai més. Perquè, com sabeu, Ceph emmagatzema dades al seu clúster en forma binària, i no en forma de fitxers simples. Per tant, si de sobte el clúster Ceph es trenca, hi ha una probabilitat completa i alta que mai més no obtindreu les vostres dades d'allà.
Farem un curs de Ceph, pots .
Per tant, és millor fer alguna cosa senzill com un servidor NFS. Kubernetes pot treballar amb ells, podeu muntar un directori sota un servidor NFS: la vostra aplicació és com un directori local. Al mateix temps, naturalment, heu d'entendre que, de nou, heu de fer alguna cosa amb el vostre NFS, heu d'entendre que de vegades pot arribar a ser inaccessible i plantejar-vos què faràs en aquest cas. Potser s'hauria de fer una còpia de seguretat en algun lloc d'una màquina independent.
El següent punt del qual vaig parlar és què fer si la vostra aplicació genera alguns fitxers durant el funcionament. Per exemple, quan s'inicia, genera algun fitxer estàtic, que es basa en una informació que l'aplicació rep només en el moment de l'inici. Quin moment. Si no hi ha moltes dades d'aquest tipus, no us haureu de molestar en absolut, només cal que instal·leu aquesta aplicació i treballeu. L'única pregunta aquí és què, mira. Molt sovint, tot tipus de sistemes heretats, com WordPress i així successivament, especialment amb algun tipus de complements intel·ligents modificats, desenvolupadors de PHP intel·ligents, sovint saben com fer-ho perquè generin algun tipus de fitxer per ells mateixos. En conseqüència, un genera un fitxer, el segon genera un segon fitxer. Són diferents. L'equilibri es produeix al clúster Kubernetes dels clients simplement per casualitat. En conseqüència, resulta que no saben com treballar junts per exemple. Un dóna una informació, l'altre dóna una altra informació a l'usuari. Això és una cosa que hauríeu d'evitar. És a dir, a Kubernetes, tot el que inicieu està garantit per funcionar en múltiples instàncies. Perquè Kubernetes és una cosa en moviment. En conseqüència, pot moure qualsevol cosa, quan vulgui, sense demanar a ningú. Per tant, cal comptar amb això. Tot el que es llança en una instància fallarà tard o d'hora. Com més reserves tinguis, millor. Però de nou, dic, si teniu uns quants fitxers d'aquest tipus, podeu posar-los a sota, pesen una petita quantitat. Si n'hi ha una mica més, probablement no hauríeu d'empènyer-los dins del contenidor.
Jo aconsellaria que hi ha una cosa tan meravellosa a Kubernetes, podeu utilitzar el volum. En particular, hi ha un volum del tipus dir buit. És a dir, només que Kubernetes crearà automàticament un directori als seus directoris de serveis al servidor on vau començar. I te'l donarà perquè el puguis utilitzar. Només hi ha un punt important. És a dir, les vostres dades no s'emmagatzemaran dins del contenidor, sinó a l'amfitrió en què esteu executant. A més, Kubernetes pot controlar aquests directoris buits amb una configuració normal i és capaç de controlar la seva mida màxima i no permetre que es superi. L'únic punt és que el que heu escrit al directori buit no es perd durant el reinici del pod. És a dir, si la teva beina cau per error i torna a pujar, la informació del directori buit no anirà enlloc. El pot tornar a utilitzar amb un nou començament, i això és bo. Si la teva beina surt d'algun lloc, llavors, naturalment, marxarà sense dades. És a dir, tan bon punt desapareix el pod del node on es va llançar amb el directori buit, s'elimina el directori buit.
Què més té de bo el directori buit? Per exemple, es pot utilitzar com a memòria cau. Imaginem que la nostra aplicació genera alguna cosa sobre la marxa, la dóna als usuaris i ho fa durant molt de temps. Per tant, l'aplicació, per exemple, la genera i la dóna als usuaris, i alhora l'emmagatzema en algun lloc, de manera que la propera vegada que vingui l'usuari pel mateix, serà més ràpid donar-la immediatament generada. Es pot demanar a Kubernetes el directori buit que creï a la memòria. I, per tant, les vostres memòria cau generalment poden funcionar a la velocitat del llamp, en termes de velocitat d'accés al disc. És a dir, tens un directori buit a la memòria, al sistema operatiu s'emmagatzema a la memòria, però per a tu, per a l'usuari dins del pod, sembla només un directori local. No necessiteu l'aplicació per ensenyar màgia específicament. Només agafeu i poseu el fitxer directament en un directori, però, de fet, a la memòria del sistema operatiu. Aquesta també és una característica molt convenient pel que fa a Kubernetes.
Quins problemes té Minio? El principal problema amb Minio és que perquè això funcioni, s'ha d'executar en algun lloc i hi ha d'haver algun tipus de sistema de fitxers, és a dir, emmagatzematge. I aquí ens trobem amb els mateixos problemes que té Ceph. És a dir, Minio ha d'emmagatzemar els seus fitxers en algun lloc. És simplement una interfície HTTP per als vostres fitxers. A més, la funcionalitat és clarament més pobre que la de l'S3 d'Amazon. Anteriorment, no podia autoritzar correctament l'usuari. Ara, pel que jo sé, ja pot crear cubs amb diferents autoritzacions, però de nou, em sembla que el principal problema és, per dir-ho d'alguna manera, el sistema d'emmagatzematge subjacent com a mínim.
Com afecta el directori buit a la memòria els límits? No afecta els límits de cap manera. Es troba a la memòria de l'amfitrió, i no a la memòria del vostre contenidor. És a dir, el vostre contenidor no veu el directori buit a la memòria com a part de la memòria ocupada. L'amfitrió ho veu. En conseqüència, sí, des del punt de vista de kubernetes, quan comenceu a utilitzar-lo, estaria bé entendre que esteu dedicant part de la vostra memòria al directori buit. I en conseqüència, entengueu que la memòria es pot esgotar no només a causa de les aplicacions, sinó també perquè algú escriu a aquests directoris buits.
Núvols
I el subtema final és què és Cloudnative. Per què és necessari? Cloudnativeness i així successivament.
És a dir, aquelles aplicacions que són capaços i escrites per treballar en una moderna infraestructura de núvol. Però, de fet, Cloudnative té un altre aspecte. Que no només es tracta d'una aplicació que té en compte tots els requisits d'una moderna infraestructura de núvol, sinó que sàpiga treballar amb aquesta moderna infraestructura de núvol, aprofiti els avantatges i inconvenients del fet que funcioni en aquests núvols. No t'excedeixis i treballis als núvols, sinó que aprofita els avantatges de treballar al núvol.
Prenguem Kubernetes com a exemple. La vostra aplicació s'està executant a Kubernetes. La vostra aplicació sempre pot, o més aviat els administradors de la vostra aplicació, sempre poden crear un compte de servei. És a dir, un compte d'autorització al mateix Kubernetes al seu servidor. Afegiu-hi alguns drets que necessitem. I podeu accedir a Kubernetes des de la vostra aplicació. Què pots fer d'aquesta manera? Per exemple, des de l'aplicació, rebeu dades sobre on es troben les vostres altres aplicacions, altres instàncies similars i, d'alguna manera, agrupeu-vos a la part superior de Kubernetes, si és necessari.
De nou, literalment hem tingut un cas recentment. Tenim un controlador que supervisa la cua. I quan apareixen algunes tasques noves en aquesta cua, es dirigeix a Kubernetes, i dins de Kubernetes crea un pod nou. Dóna a aquest pod una tasca nova i, dins del marc d'aquest pod, el pod realitza la tasca, envia una resposta al controlador mateix i el controlador fa alguna cosa amb aquesta informació. Per exemple, afegeix una base de dades. És a dir, de nou, aquest és un avantatge del fet que la nostra aplicació s'executa a Kubernetes. Podem utilitzar la pròpia funcionalitat integrada de Kubernetes per tal d'ampliar d'alguna manera i fer que la funcionalitat de la nostra aplicació sigui més còmoda. És a dir, no amagar algun tipus de màgia sobre com llançar una aplicació, com llançar un treballador. A Kubernetes, només envieu una sol·licitud a l'aplicació si l'aplicació està escrita en Python.
El mateix passa si anem més enllà de Kubernetes. Tenim el nostre Kubernetes funcionant en algun lloc; és bo si és en algun tipus de núvol. De nou, podem utilitzar, i fins i tot hauríem, crec, d'utilitzar les capacitats del mateix núvol on estem executant. De les coses elementals que ens proporciona el núvol. Balancing, és a dir, podem crear equilibradors de núvol i utilitzar-los. Aquest és un avantatge directe del que podem utilitzar. Perquè l'equilibri del núvol, en primer lloc, ens elimina estúpidament la responsabilitat de com funciona, de com es configura. A més, és molt convenient, perquè Kubernetes normal es pot integrar amb els núvols.
El mateix passa amb l'escala. Kubernetes habituals es pot integrar amb proveïdors de núvol. Sap entendre que si el clúster es queda sense nodes, és a dir, l'espai dels nodes s'ha esgotat, cal afegir-hi: el mateix Kubernetes afegirà nous nodes al vostre clúster i començarà a llançar-hi pods. És a dir, quan arriba la teva càrrega, el nombre de llars comença a augmentar. Quan els nodes del clúster s'esgoten per a aquests pods, Kubernetes llança nous nodes i, en conseqüència, el nombre de pods encara pot augmentar. I és molt convenient. Aquesta és una oportunitat directa per escalar el cúmul sobre la marxa. No molt ràpid, en el sentit que no és un segon, és més com un minut per afegir nous nodes.
Però des de la meva experiència, de nou, és la cosa més maca que he vist mai. Quan el clúster Cloudnative s'ha escalat en funció de l'hora del dia. Era un servei de backend que utilitzaven la gent del back office. És a dir, arriben a treballar a les 9 del matí, comencen a iniciar sessió al sistema i, en conseqüència, el clúster Cloudnative, on està tot funcionant, comença a inflar-se, llançant nous pods perquè tothom que vingui a treballar pugui treballar amb l'aplicació. Quan surten de la feina a les 8 o a les 6 hores, els clústers de Kubernetes s'adonen que ningú ja no utilitza l'aplicació i comencen a reduir-se. Es garanteix un estalvi de fins a un 30 per cent. Funcionava a Amazon en aquell moment; en aquell moment no hi havia ningú a Rússia que ho pogués fer tan bé.
Us diré directament que l'estalvi és del 30 per cent simplement perquè utilitzem Kubernetes i aprofitem les capacitats del núvol. Ara això es pot fer a Rússia. No faré publicitat a ningú, és clar, però diguem que hi ha proveïdors que poden fer-ho, proporcionar-ho immediatament amb un botó.
Hi ha un darrer punt que també m'agradaria cridar la vostra atenció. Perquè la vostra aplicació, la vostra infraestructura sigui Cloudnative, té sentit començar a adaptar finalment l'enfocament anomenat Infraestructura com a codi, és a dir, això vol dir que la vostra aplicació, o més aviat la vostra infraestructura, es necessita exactament de la mateixa manera que la codi Descriu la teva aplicació, la teva lògica empresarial en forma de codi. I treballar-hi com a codi, és a dir, provar-lo, desplegar-lo, emmagatzemar-lo a git, aplicar-hi CICD.
I això és exactament el que et permet, en primer lloc, tenir sempre el control de la teva infraestructura, entendre sempre en quin estat es troba. En segon lloc, eviteu les operacions manuals que causen errors. En tercer lloc, eviteu simplement el que s'anomena rotació, quan necessiteu realitzar constantment les mateixes tasques manuals. En quart lloc, permet recuperar-se molt més ràpidament en cas d'error. A Rússia, cada cop que parlo d'això, sempre hi ha un gran nombre de persones que diuen: "Sí, està clar, però tens plantejaments, en definitiva, no cal arreglar res". Però és cert. Si alguna cosa està trencada a la vostra infraestructura, aleshores des del punt de vista de l'enfocament Cloudnative i des del punt de vista de la infraestructura com a codi, en lloc de solucionar-ho, anar al servidor, esbrinar què està trencat i arreglar-lo, és més fàcil. per eliminar el servidor i crear-lo de nou. I tot això ho faré restaurar.
Tots aquests temes es tracten amb més detall a . Seguint l'enllaç podeu familiaritzar-vos amb el programa i les condicions. El més convenient és que podeu dominar Kubernetes estudiant des de casa o treballant entre 1 i 2 hores al dia.
Font: www.habr.com