Oghje aghju pensatu à parlà di cumu scrive l'applicazioni è quali sò i requisiti per a vostra applicazione per travaglià bè in Kubernetes. Cusì ùn ci hè micca mal di testa cù l'applicazione, per ùn avè micca inventà è custruisce "cratches" intornu à questu - è tuttu funziona cum'è Kubernetes stessu hà intesu.
Sta cunferenza face parte di "" Pudete vede e lezioni teoriche aperte di a Scola di a Sera . Per quelli chì preferiscenu u testu piuttostu chè u video, avemu preparatu stu articulu.
Mi chjamu Pavel Selivanov, attualmente sò u principale ingegnere DevOps in Mail.ru Cloud Solutions, facemu nuvole, facemu kubernetes di gestione è cusì. I mo compiti avà includenu l'assistenza in u sviluppu, u rollu di sti nuvuli, u rollu di l'applicazioni chì scrivimu è u sviluppu direttu di l'arnesi chì furnimu per i nostri utilizatori.
Aghju fattu DevOps, pensu per l'ultimi, probabilmente, trè anni. Ma, in principiu, aghju fattu ciò chì DevOps faci per probabilmente circa cinque anni. Prima di quessa, era principalmente implicatu in cose di amministratore. Aghju cuminciatu à travaglià cù Kubernetes assai tempu fà - probabilmente circa quattru anni sò passati da quandu aghju cuminciatu à travaglià cun ellu.
In generale, aghju cuminciatu quandu Kubernetes era a versione 1.3, probabilmente, è forse 1.2 - quandu era ancu in a so zitiddina. Avà ùn hè più in a so infanzia - è hè ovvi chì ci hè una grande dumanda in u mercatu per ingegneri chì vulianu esse capace di fà Kubernetes. E cumpagnie anu una dumanda assai alta per tali persone. Dunque, in fattu, sta cunferenza hè apparsu.
Se parlemu secondu u pianu di ciò chì parleraghju, pare cusì, in parentesi hè scrittu (TL; DR) - "troppu longu; ùn leghje ". A mo presentazione oghje serà custituita da liste infinite.
In fatti, ùn mi piace micca tali presentazioni quandu sò fatte, ma questu hè un tema cusì chì quandu preparava sta presentazione, ùn aghju micca veramente capitu cumu organizà sta informazione in modu diversu.
Perchè, in generale, sta informazione hè "ctrl+c, ctrl+v", da, frà altre cose, u nostru Wiki in a sezione DevOps, induve avemu scrittu esigenze per i sviluppatori: "ragazzi, cusì chì lanciamu a vostra applicazione in Kubernetes, duverebbe esse cusì ".
Hè per quessa chì a presentazione hè stata una lista cusì grande. Scusa. Pruvaraghju di dì quant'è pussibule in modu chì ùn sia micca noioso s'ellu hè pussibule.
Ciò chì andemu à vede avà:
- Quessi sò, prima, logs (registru di l'applicazioni?), chì fà cun elli in Kubernetes, chì fà cun elli, ciò chì deve esse;
- chì fà cù e cunfigurazioni in Kubernetes, chì sò i modi più boni è peghju per cunfigurà una applicazione per Kubernetes;
- Parlemu di ciò chì i cuntrolli di l'accessibilità sò in generale, cumu si deve esse;
- parlemu di ciò chì hè un fermu graziosu;
- parlemu di novu di risorse ;
- Toccheremu u tema di l'almacenamiento di dati una volta;
- è à a fine vi dicu ciò chì u terminu hè sta misteriosa applicazione nativa di nuvola. Cloudnativeness, cum'è un aggettivu di stu terminu.
Logs
Suggeriu di principià cù i logs - cù induve questi logs deve esse shoved in Kubernetes. Avà avete lanciatu una applicazione in Kubernetes. Sicondu i classici, l'applicazioni prima anu sempre scrittu logs in un locu in un schedariu. L'applicazioni cattivi anu scrittu logs in un schedariu in u cartulare di casa di u sviluppatore chì hà lanciatu l'applicazione. L'applicazioni boni anu scrittu logs in un schedariu in qualchì locu /var/log.
In cunsiquenza, in più, i boni amministratori avianu parechje cose cunfigurate in e so infrastrutture chì sti logs puderanu rotà - u stessu rsyslog, chì guarda à questi logs è quandu qualcosa li succede, ci sò assai, crea copie di salvezza, mette logs quì. , elimina i schedari vechji, più di una settimana, sei mesi è un pocu di più. In teoria, duvemu avè disposti per chì solu perchè l'applicazione scrive logs, u spaziu nantu à i servitori di pruduzzione (servitori di cummattimentu?) ùn esce micca. È, dunque, tutta a pruduzzione ùn si ferma micca per via di i logs.
Quandu andemu in u mondu di Kubernetes è eseguimu a listessa cosa, a prima cosa chì pudete attentu hè u fattu chì e persone, cum'è scrivevanu logs in un schedariu, cuntinueghjanu à scrive.
Risulta chì, se parlemu di Kubernetes, u locu ghjustu per scrive logs in un locu da un containeru docker hè solu di scriveli da l'applicazione à u chjamatu Stdout / Stderr, vale à dì, i flussi di output standard di u sistema operatore, l'output di errore standard. Questu hè u modu più currettu, più simplice è più logicu per mette logs in principiu in Docker è specificamente in Kubernetis. Perchè se a vostra applicazione scrive logs à Stdout/Stderr, allora tocca à Docker è à l'add-on Kubernetes decide ciò chì fà cù questi logs. Docker hà da custruisce per difettu i so fugliali speciali in formatu JSON.
Eccu a quistione, chì fate dopu cù questi logs? A manera più faciule hè chjara, avemu a capacità di fà kubectl logs è fighjate à sti logs di sti "pods". Ma, prubabilmente, questu ùn hè micca una bona opzione - qualcosa deve esse fattu cù i logs.
Per avà, parlemu à u stessu tempu, postu chì avemu toccu nantu à u tema di i logs, nantu à una cosa cum'è i logs deve esse simile. Questu hè, questu ùn hè micca appiicatu direttamente à Kubernetes, ma quandu avemu principiatu à pensà à ciò chì fà cù i logs, saria bè di pensà ancu à questu.
Avemu bisognu di qualchì strumentu, in modu amichevule, chì pigliarà questi logs chì u nostru docker mette in i so fugliali è li manda in qualchì locu. In generale, di solitu lanciamu un tipu d'agente in Kubernetes in forma di DaemonSet - un cullettore di log, chì hè simplicemente dettu induve si trovanu i logs chì Docker raccoglie. È questu agente di cullizzioni li piglia solu, forse ancu in qualche modu li analizza in a strada, forse li arricchisce cù qualchì meta-informazione supplementu è, infine, li manda per u almacenamentu in qualchì locu. Variazioni sò digià pussibuli quì. U più cumuni hè probabilmente Elasticsearch, induve pudete almacenà i logs è pudete ricuperà facilmente da quì. Allora, usendu una dumanda, usendu Kibana, per esempiu, custruisce gràfiche basatu annantu à elli, custruisce alerti basati nantu à elli, è cusì.
L'idea più impurtante, vogliu ripetiri dinò, hè chì in Docker, in particulare in Kubernetes, almacenà i vostri logs in un schedariu hè una idea assai mala.
Perchè prima, hè difficiule di ottene i logs in u cuntinuu in un schedariu. Duvete prima andà in u containeru, execu quì, è dopu fighjate i logs. U puntu dopu hè chì si avete logs in un schedariu, i cuntenituri sò generalmente un ambiente minimalista è ùn ci sò micca utilità chì sò generalmente necessarii per u travagliu normale cù logs. Sepulteli, fighjate, apre in un editore di testu. U mumentu dopu hè quandu avemu logs in un schedariu in un containeru, se stu containeru hè sguassatu, capite, i logs mureranu cun ellu. Per quessa, ogni riavviu di u containeru significa chì ùn ci sò più logs. Di novu, mala opzione.
È l'ultimu puntu hè chì in i cuntenituri di solitu avete a vostra applicazione è basta - hè di solitu l'unicu prucessu in esecuzione. Ùn ci hè nunda di parlà di qualsiasi prucessu chì avissi a rotazione di i schedari cù i vostri logs. Appena i logs cumincianu à esse scritti in un schedariu, questu significa chì, scusa, avemu da cumincià à perde u servitore di produzzione. Perchè, prima, sò difficiuli di truvà, nimu li traccia, più nimu ùn li cuntrolla - per quessa, u schedariu cresce senza fine finu à chì u spaziu nantu à u servitore hè ghjustu. Dunque, dicu novu chì u logu in Docker, in particulare in Kubernetes, à un schedariu hè una mala idea.
U puntu dopu, quì vogliu parlà di questu novu - postu chì avemu toccu nantu à u tema di i logs, saria bè di parlà di cumu si deve vede i logs per fà cunvene per travaglià cun elli. Cumu l'aghju dettu, u tema ùn hè micca direttamente ligatu à Kubernetes, ma si tratta assai bè cù u tema di DevOps. Nantu à u tema di a cultura di sviluppu è l'amicizia trà sti dui dipartimenti diffirenti - Dev è Ops, cusì chì tutti sò cunfortu.
Questu significa chì idealmente, oghje, i logs deve esse scritti in formatu JSON. Sè vo avete qualchì applicazione incomprensibile di u vostru propiu, chì scrive logs in furmati incomprensibile perchè inserite qualchì tipu di stampa o quarchi cosa cusì, allora hè u tempu di google un tipu di quadru, un tipu di wrapper chì vi permette di implementà u logu normale; attivà i paràmetri di logging in JSON quì, perchè JSON hè un furmatu simplice, l'analisi hè simplice.
Se u vostru JSON ùn funziona micca secondu certi criterii, nimu ùn sà chì, allora almenu scrive logs in un formatu chì pò esse analizatu. Quì, piuttostu, vale a pena di pensà à u fattu chì, per esempiu, sè vo site una mansa di cuntenituri o solu prucessi cù nginx, è ognunu hà i so paràmetri di logging, allora probabilmente pare chì serà assai inconveniente per voi. analizà li. Perchè per ogni nova istanza di nginx avete bisognu di scrive u vostru parser, perchè scrivenu logs in modu diversu. In novu, era prubabilmente vale a pena di pensà à assicurà chì tutti questi casi nginx avianu a listessa cunfigurazione di logging è hà scrittu tutti i so logs in modu assolutamente uniforme. U listessu vale per assolutamente tutte l'applicazioni.
In fine, vogliu ancu aghjunghje carburante à u focu chì, idealmente, i logs di forma multi-linea deve esse evitata. Eccu a cosa, s'è vo avete mai travagliatu cù cullizzioni di log, allura più prubabilmente avete vistu ciò chì vi prumettenu, chì ponu travaglià cù logs multi-linea, sapè cumu per cullà, è cusì. In fattu, in u mo parè, micca un solu cullettore oghje pò cullà logs multi-linea nurmale, cumpletamente è senza errori. In modu umanu, cusì chì hè cunvene è senza errore.
Ma a traccia di stack hè sempre logs multi-linea è cumu per evità. A quistione quì hè chì un logu hè un registru di un avvenimentu, è stactrace ùn hè micca veramente un log. Se cullemu i logs è i mette in un locu in Elasticsearch è poi traccianu grafici da elli, custruite qualchi rapporti di l'attività di l'utilizatori nantu à u vostru situ, allora quandu avete una traccia di stack, significa chì qualcosa inesperu hè accadutu, una situazione senza gestione in a vostra applicazione. È hè sensu per carica automaticamente una traccia di stack in un locu in un sistema chì pò seguità.
Questu hè un software (u stessu Sentry) chì hè fattu apposta per travaglià cù stack trace. Puderà immediatamente creà travaglii automatizati, assignalli à qualchissia, avvisate quandu stacttraces accadenu, raggruppate sti stacttraces per un tipu, è cusì. In principiu, ùn hè micca assai sensu di parlà di stactraces quandu avemu parlatu di logs, perchè questi sò, dopu tuttu, cose diverse cù scopi diffirenti.
Cunfigurazione
Dopu parlemu di a cunfigurazione in Kubernetes: chì fà cun ellu è cumu l'applicazioni in Kubernetes deve esse cunfigurate. In generale, di solitu dicu chì Docker ùn hè micca di cuntenituri. Tuttu u mondu sapi chì Docker hè di cuntenituri, ancu quelli chì ùn anu micca travagliatu cù Docker assai. Ripetu, Docker ùn hè micca di cuntenituri.
Docker, in my opinion, hè di standard. E ci sò standard per quasi tuttu: standard per a custruzzione di a vostra applicazione, standard per a stallazione di a vostra applicazione.
E sta cosa - l'avemu utilizata prima, hè diventata soprattuttu populari cù l'avventu di cuntenituri - questa cosa hè chjamata ENV (ambienti) variabili, vale à dì, variabili ambientali chì sò in u vostru sistema operatore. Questu hè generalmente un modu ideale per cunfigurà a vostra applicazione, perchè s'è vo avete applicazioni in JAVA, Python, Go, Perl, Diu ùn ci vole, è tutti ponu leghje l'ospiti di a basa di dati, l'utilizatori di a basa di dati, e variabili di password di a basa di dati, allora hè ideale. Avete applicazioni in quattru lingue diverse cunfigurate in u pianu di a basa di dati in u listessu modu. Ùn ci sò più cunfigurazioni diverse.
Tuttu pò esse cunfiguratu cù variabili ENV. Quandu parlemu di Kubernetes, ci hè una bella manera di dichjarà variabili ENV ghjustu in Deployment. In cunsiquenza, se parlemu di dati secreti, pudemu immediatamente spinghje i dati secreti da variabili ENV (passwords à basa di dati, etc.) in un sicretu, creà un cluster secretu è indicà in a descrizzione ENV in Deployment chì ùn avemu micca direttamente dichjarà. u valore di sta variabile, è u valore di sta variabile di password di a basa di dati serà lettu da u sicretu. Questu hè u cumpurtamentu standard di Kubernetes. È questu hè l'opzione più ideale per cunfigurà e vostre applicazioni. Solu à u nivellu di codice, dinò questu hè appiicatu à i sviluppatori. Sè vo site DevOps, pudete dumandà: "Ragazzi, per piacè insegnate à a vostra applicazione à leghje variabili di l'ambiente. È seremu tutti felici ".
Se tutti in a cumpagnia leghjenu i stessi variabili di l'ambienti chjamati, allora hè grande. Per ùn succede micca chì certi stanu aspittendu a basa di dati di postgres, altri aspettanu u nome di a basa di dati, altri aspettanu qualcosa d'altru, altri aspettanu un dbn di qualchì tipu, per quessa, per quessa, ci hè uniformità.
U prublema vene quandu avete tante variabili di l'ambiente chì avete appena apertu Deployment - è ci sò cinque centu linee di variabili ambientali. In questu casu, avete semplicemente superatu variabili di l'ambiente - è ùn avete più bisognu di tortu. In questu casu, avaristi sensu per cumincià à aduprà cunfigurazione. Questu hè, furmà a vostra applicazione per utilizà cunfigurazioni.
L'unica quistione hè chì e cunfigurazioni ùn sò micca ciò chì pensate. Config.pi ùn hè micca una cunfigurazione chì hè cunvene à utilizà. O qualchì cunfigurazione in u vostru propiu furmatu, alternativamente dotatu - questu hè ancu micca a cunfigurazione chì vogliu dì.
Ciò chì parlu hè a cunfigurazione in formati accettabili, vale à dì, u standard più populari hè u standard .yaml. Hè chjaru cumu leghje, hè leggibile umanu, hè chjaru cumu leghje da l'applicazione.
In cunsiquenza, in più di YAML, pudete ancu, per esempiu, aduprà JSON, l'analizazione hè quasi cunvene cum'è YAML in quantu à leghje a cunfigurazione di l'applicazione da quì. Hè notevolmente più inconveniente per a ghjente di leghje. Pudete pruvà u furmatu, à la ini. Hè abbastanza còmuda di leghje, da un puntu di vista umanu, ma pò esse sconveniente per processà automaticamente, in u sensu chì, sè vo vulete sempre generà e vostre cunfigurazioni, u formatu ini pò esse digià inconveniente per generà.
Ma in ogni casu, qualunque sia u formatu chì sceglite, u puntu hè chì da u puntu di vista di Kubernetes hè assai còmuda. Pudete mette tutta a vostra cunfigurazione in Kubernetes, in u ConfigMap. E poi pigliate stu configmap è dumandate ch'ellu sia muntatu in u vostru pod in un repertoriu specificu, induve a vostra applicazione leghjerà a cunfigurazione da questa configmap cum'è s'ellu era solu un schedariu. Questu, in fattu, hè ciò chì hè bonu per fà quandu avete assai opzioni di cunfigurazione in a vostra applicazione. O hè solu un tipu di struttura cumplessa, ci hè nidificazione.
Sè vo avete un configmap, allura vi pò assai bè insignà a vostra applicazione, per esempiu, à seguità automaticamente i cambiamenti in u schedariu induve u configmap hè muntatu, è dinò automaticamente ricaricà a vostra applicazione quandu a cunfigurazione cambia. In generale, questu seria una opzione ideale.
In novu, aghju digià parlatu di questu - l'infurmazione secreta ùn hè micca in u configmap, l'infurmazione secreta ùn hè micca in variàbili, l'infurmazione secreta ùn hè micca in secreti. Da quì, cunnette sta infurmazione secreta à a diplomazia. Di solitu almacenamu tutte e descrizioni di l'uggetti Kubernetes, implementazioni, configmaps, servizii in git. Dunque, mette a password à a basa di dati in git, ancu s'ellu hè u vostru git, chì avete internamente in a cumpagnia, hè una mala idea. Perchè, à u minimu, git si ricorda di tuttu è solu sguassà e password da quì ùn hè micca cusì faciule.
Verificazione di salute
U prossimu puntu hè questa cosa chjamata Salute. In generale, un cuntrollu di Salute hè solu cuntrollà chì a vostra applicazione funziona. À u listessu tempu, parlemu più spessu di certe applicazioni web, per quale, per quessa, da u puntu di vista di u cuntrollu di salute (hè megliu ùn traduce micca quì è più) questu serà qualchì URL speciale, chì processanu cum'è un standard, di solitu facenu /health.
Quandu accede à questu URL, per quessa, a nostra applicazione dice o "iè, va bè, tuttu va bè per mè, 200" o "no, tuttu ùn hè micca bè per mè, circa 500". In cunsiquenza, se a nostra applicazione ùn hè micca http, micca una applicazione web, ora parlemu di qualchì tipu di demone, pudemu capisce cumu fà cuntrolli di salute. Questu hè, ùn hè micca necessariu, se l'applicazione ùn hè micca http, allora tuttu funziona senza un cuntrollu di salute è questu ùn pò micca esse fattu in ogni modu. Pudete aghjurnà periodicamente alcune informazioni in u schedariu, pudete vene cun un cumandamentu speciale per u vostru daemon, cum'è, daemon status, chì dicerà "iè, tuttu hè bè, u demoniu hè travagliatu, hè vivu".
Chì ghjè per ? A prima è a più ovvia hè probabilmente perchè un cuntrollu di salute hè necessariu - per capisce chì l'applicazione funziona. Vogliu dì, hè solu stupidu, quandu hè avà, pare chì travaglia, cusì pudete esse sicuru chì funziona. È risulta chì l'applicazione hè in esecuzione, u cuntinuu hè in esecuzione, l'istanza funziona, tuttu hè bè - è allora l'utilizatori anu digià tagliatu tutti i numeri di telefunu da u supportu tecnicu è dicenu "chì site ... si dorme, nunda ùn funziona.
Un cuntrollu di salute hè solu un modu per vede da u puntu di vista di l'utilizatori chì funziona. Unu di i metudi. Mettimu cusì. Da u puntu di vista di Kubernetes, questu hè ancu un modu per capiscenu quandu l'applicazione principia, perchè avemu capitu chì ci hè una diffarenza trà quandu u cuntinuu hè stata lanciata, creata è cuminciata, è quandu l'applicazione hè stata lanciata direttamente in questu cuntinuu. Perchè s'ellu pigliamu qualchì applicazione media Java è pruvate à lancià in u dock, dopu per quaranta seconde, o ancu un minutu, o ancu deci, pò principià bè. In questu casu, pudete almenu chjappà nantu à i so porti, ùn risponde micca quì, vale à dì ùn hè ancu pronta per riceve u trafficu.
In novu, cù l'aiutu di un cuntrollu di salute è cù l'aiutu di u fattu chì vultemu quì, pudemu capisce in Kubernetes chì micca solu u cuntinuu hà risuscitatu in l'applicazione, ma l'applicazione stessa hà iniziatu, risponde digià à u cuntrollu di salute, chì significa chì pudemu mandà u trafficu quì.
Ciò chì parlu avà hè chjamatu Test di Prontezza / Vita in Kubernetes; per quessa, i nostri testi di prontezza sò rispunsevuli di a dispunibilità di l'applicazione in equilibriu. Vale à dì, se e teste di prontezza sò eseguite in l'applicazione, allora tuttu hè bè, u trafficu di u cliente và à l'applicazione. Se i testi di prontezza ùn sò micca realizati, allora l'applicazione simpricimenti ùn participa micca, questu casu particulari ùn participa micca à l'equilibriu, hè sguassatu da l'equilibriu, u trafficu di u cliente ùn scorri micca. Di conseguenza, i testi di Liveness in Kubernetes sò necessarii per chì se l'applicazione si blocca, pò esse riavviata. Se a prova di vita ùn funziona micca per una applicazione chì hè dichjarata in Kubernetes, allora l'applicazione ùn hè micca solu sguassata da l'equilibriu, hè riavviata.
È quì hè un puntu impurtante chì vogliu dì: da un puntu di vista praticu, a prova di prontezza hè generalmente usata più spessu è hè più spessu necessariu chè a prova di vita. Vale à dì, simpricimenti dichjarà senza penseru e teste di prontezza è di vita, perchè Kubernetes pò fà quessa, è usemu tuttu ciò chì pò fà, ùn hè micca una idea assai bona. Spiegheraghju perchè. Perchè u puntu numeru dui in a prova hè chì saria una bona idea di verificà u serviziu sottostante in i vostri cuntrolli di salute. Questu significa chì si avete una applicazione web chì dà qualchì infurmazione, chì à u turnu, naturalmente, deve piglià da qualchì locu. In una basa di dati, per esempiu. Ebbè, salva l'infurmazioni chì vene in questa API REST in a stessa basa di dati. Allora, per quessa, se u vostru cuntrollu di salute risponde solu cum'è slashhealth cuntattatu, l'applicazione dice "200, va bè, tuttu va bè", è à u stessu tempu a basa di dati di a vostra applicazione hè inaccessibile, è l'applicazione di cuntrollu di salute dice "200, va bè, tuttu va bè. " - Questu hè un cattivu cuntrollu di salute. Questu ùn hè micca cumu si deve travaglià.
Questu hè, a vostra applicazione, quandu una dumanda vene à questu /health, ùn risponde micca solu, "200, ok", prima vai, per esempiu, à a basa di dati, prova di cunnette vi, face qualcosa di assai basicu quì, cum'è selezziunate unu, verificate solu chì ci hè una cunnessione in u basa di dati è pudete dumandà a basa di dati. Se tuttu questu hè successu, allora a risposta hè "200, ok". Se ùn hè micca successu, dice chì ci hè un errore, a basa di dati ùn hè micca dispunibule.
Per quessa, in questu sensu, torna torna à i testi di Prontezza / Liveness - perchè probabilmente avete bisognu di una prova di prontezza, ma una prova di vita hè in quistione. Perchè se discrivite i cuntrolli di salute esattamente cum'è aghju dettu, allora sarà chì ùn hè micca dispunibule in a parte di l'istanza.в или со всех instancein una basa di dati, per esempiu. Quandu avete dichjaratu una prova di prontezza, i nostri cuntrolli di salute anu cuminciatu à fallu, è per quessa, tutte l'applicazioni da quale a basa di dati ùn hè micca accessibile, sò simpliciamente disattivate da l'equilibriu è in fattu "pendu" solu in un statu trascuratu è aspettate chì e so basa di dati si travagliu.
Se avemu dichjaratu una prova di vivacità, allora imaginate, a nostra basa di dati hè rotta, è in u vostru Kubernetes a mità di tuttu principia à riavvia perchè a prova di vivacità falla. Questu significa chì avete bisognu di riavvia. Questu ùn hè micca in tuttu ciò chì vulete, aghju avutu ancu una sperienza persunale in a pratica. Avemu avutu una applicazione di chat chì era scritta in JS è alimentata in una basa di dati Mongo. È u prublema era chì era à u principiu di u mo travagliu cù Kubernetes, avemu discrittu a prontezza, a vivacità di e teste nantu à u principiu chì Kubernetes pò fà, cusì avemu aduprà. In cunsiquenza, à un certu puntu Mongo hè diventatu un pocu "dull" è a mostra hà cuminciatu à fallu. In cunsiquenza, secondu a prova di pioggia, i baccelli cuminciaru à "ammazzà".
Comu capisci, quandu sò "ammazzati", questu hè un chat, vale à dì, ci sò assai cunnessione da i clienti appiccicati nantu à questu. Sò ancu "ammazzati" - no, micca clienti, solu cunnessione - micca tutti à u stessu tempu, è per u fattu chì ùn sò micca ammazzati à u stessu tempu, alcuni prima, alcuni dopu, ùn cumincianu micca à u listessu tempu. tempu. In più standard casuale, ùn pudemu micca predichendu cù precisione milliseconda l'ora di iniziu di l'applicazione ogni volta, cusì facenu una istanza à volta. Un infospot cresce, hè aghjuntu à l'equilibriu, tutti i clienti venenu quì, ùn pò micca sustene una tale carica, perchè hè solu, è, à pocu pressu, ci sò una decina di elli chì travaglianu quì, è casca. U prossimu si alza, tutta a carica hè nantu à ellu, cascà ancu. Ebbè, queste cascate cuntinueghjanu solu à cascata. À a fine, cumu hè statu risoltu - avemu avutu solu piantà strettamente u trafficu di l'utilizatori à questa applicazione, lasciate chì tutte e istanze aumentanu è poi cumincianu tuttu u trafficu di l'utilizatori in una volta in modu chì era digià distribuitu trà tutti i dece casi.
S'ellu ùn era micca stata annunziata sta prova di vivacità, chì forzaria tuttu à riavvia, l'applicazione l'avaria trattatu bè. Ma tuttu da u equilibriu hè disattivatu per noi, perchè e basa di dati sò inaccessibili è tutti l'utilizatori anu "cadutu". Allora, quandu sta basa di dati diventa dispunibile, tuttu hè inclusu in equilibriu, ma l'applicazioni ùn anu micca bisognu di ricuminciari, è ùn ci hè bisognu di perdi tempu è risorse nantu à questu. Sò tutti digià quì, sò pronti per u trafficu, cusì u trafficu si apre, tuttu hè bè - l'applicazione hè in u locu, tuttu cuntinueghja à travaglià.
Dunque, e teste di prontezza è di vivacità sò diffirenti, ancu di più, pudete teoricamente fà diverse cuntrolli di salute, un tipu di radiu, un tipu liv, per esempiu, è verificate diverse cose. Durante e teste di prontezza, verificate i vostri backends. È nantu à una prova di vita, per esempiu, ùn cuntrolla micca da u puntu di vista chì a prova di vita hè in generale solu una applicazione chì risponde, s'ellu hè capaci di risponde à tutti.
Perchè a prova di vita, in generale, hè quandu simu "bloccati". Un ciclu infinitu hà iniziatu o qualcosa d'altru - è ùn ci sò più richieste. Dunque, hè sensu ancu separà - è implementà una logica diversa in elli.
In quantu à ciò chì avete bisognu di risponde quandu avete una prova, quandu fate cuntrolli di salute. Hè solu veramente un dolore. Quelli chì sò familiarizati cù questu prubabilmente rideranu - ma seriu, aghju vistu servizii in a mo vita chì rispondenu "200" in u XNUMX% di i casi. Questu hè, quale hè successu. Ma à u listessu tempu in u corpu di a risposta scrivenu "tali è tali errore".
Questu hè, u statu di risposta vene à voi - tuttu hè successu. Ma à u stessu tempu, deve analizà u corpu, perchè u corpu dice "scusate, a dumanda finita cù un errore" è questu hè solu a realità. Aghju vistu questu in a vita reale.
È cusì chì certi pirsuni ùn si trovanu micca divertenti, è altri si trovanu assai doloroso, vale a pena aderisce à una regula simplice. In i cuntrolli di salute, è in principiu quandu u travagliu cù l'applicazioni web.
Sè tuttu andava bè, poi rispondi cù a risposta di dui centu. In principiu, ogni risposta di dui centu vi cunvene. Se leghjite ragsy assai bè è sapete chì certi stati di risposta sò diffirenti di l'altri, rispondi cù l'appropritati: 204, 5, 10, 15, qualunque sia. Se ùn hè micca assai bonu, allora solu "dui zero zero". Se tuttu va male è u cuntrollu di a salute ùn risponde micca, allora risponde cù ogni cinque centu. In novu, se capite cumu risponde, cumu e diverse stati di risposta sò diffirenti l'una di l'altru. Se ùn avete micca capitu, allora 502 hè a vostra opzione per risponde à i cuntrolli di salute se qualcosa va male.
Questu hè un altru puntu, vogliu vultà un pocu per verificà i servizii sottumessi. Sè avete principiatu, per esempiu, cuntrollà tutti i servizii sottostanti chì stanu daretu à a vostra applicazione - tuttu in generale. Ciò chì avemu da u puntu di vista di l'architettura di u microserviziu, avemu un cuncettu cum'è "coppiu bassu" - vale à dì, quandu i vostri servizii sò minimamente dipindenti l'una di l'altru. Se unu d'elli falli, tutti l'altri senza sta funziunalità anu da cuntinuà à travaglià. Alcune di e funziunalità solu ùn funziona micca. Dunque, se liate tutti i cuntrolli di salute l'un à l'altru, allora vi finiscinu cù una cosa chì cascà in l'infrastruttura, è perchè hè cascata, tutti i cuntrolli di salute di tutti i servizii cumincianu ancu à fallu - è ci hè più infrastruttura in generale per u tutta l'architettura di microserviziu No. Tuttu hè andatu scuru quì.
Dunque, vogliu ripetiri questu novu chì avete bisognu di verificà i servizii sottumessi, quelli senza chì a vostra applicazione in un centu per centu di casi ùn pò micca fà u so travagliu. Questu hè, hè logicu chì si avete una REST API per mezu di quale l'utilizatore salva à a basa di dati o recupera da a basa di dati, allora in l'absenza di una basa di dati, ùn pudete micca guarantisci u travagliu cù i vostri utilizatori.
Ma se i vostri utilizatori, quandu li pigliate fora di a basa di dati, sò in più arricchiti cù qualchì altra metadata, da un altru backend, chì entre prima di mandà una risposta à u frontend - è questu backend ùn hè micca dispunibule, questu significa chì dà u vostru risponde senza alcuna parte di i metadati.
Dopu, avemu ancu unu di i prublemi dolorosi quandu lanciate applicazioni.
In fatti, questu ùn hè micca solu appiicatu à Kubernetes in generale; hè accadutu chì a cultura di qualchì tipu di sviluppu di massa è DevOps in particulare hà cuminciatu à sparghje in u stessu tempu cum'è Kubernetes. Dunque, in generale, risulta chì avete bisognu di chjude grazia a vostra applicazione senza Kubernetes. Ancu prima di Kubernetes, a ghjente hà fattu questu, ma cù l'avventu di Kubernetes, avemu cuminciatu à parlà in massa.
Spegnimentu graziosu
In generale, chì hè Graceful Shutdown è perchè hè necessariu? Questu hè quandu a vostra applicazione crash per una certa ragione, avete bisognu di fà app stop - o ricevi, per esempiu, un signalu da u sistema upirativu, a vostra applicazione deve capisce è fà qualcosa. U peghju scenariu, di sicuru, hè quandu a vostra applicazione riceve un SIGTERM è hè cum'è "SIGTERM, aspettemu, travaglià, ùn fate nunda". Questa hè una opzione veramente cattiva.
Una opzione guasi ugualmente cattiva hè quandu a vostra applicazione riceve un SIGTERM è hè cum'è "hanu dettu segterm, questu significa chì avemu finitu, ùn aghju micca vistu, ùn cunnoscu micca richieste di l'utilizatori, ùn sò micca chì tipu di dumande chì aghju travagliatu avà, anu dettu SIGTERM, questu significa chì finemu " Questu hè ancu una mala opzione.
Quale opzione hè bona? U primu puntu hè di piglià in contu a fine di l'operazioni. Una bona opzione hè per u vostru servitore per sempre piglià in contu ciò chì faci s'ellu riceve un SIGTERM.
SIGTERM hè un chjusu suave, hè apposta cuncepitu, pò esse interceptatu à u nivellu di codice, pò esse processatu, dì chì avà, aspittà, avemu prima finitu u travagliu chì avemu, dopu esce.
Da una perspettiva di Kubernetes, questu hè ciò chì pare. Quandu dicemu à un pod chì hè in esecuzione in u cluster Kubernetes, "per piacè fermate, vai via", o simu riavviati, o una aghjurnazione accade quandu Kubernetes ricrea i pods, Kubernetes manda solu u stessu missaghju SIGTERM à u pod, aspetta per qualchì tempu, è , questu hè u tempu chì aspetta, hè ancu cunfiguratu, ci hè un paràmetru cusì speciale in diplomi è hè chjamatu Graceful ShutdownTimeout. Comu capisci, ùn hè micca chjamatu cusì per nunda, è ùn hè micca per nunda chì avemu parlatu avà.
Ci pudemu specificamente dì quantu duvemu aspittà trà u tempu chì mandemu SIGTERM à l'applicazione è quandu avemu capitu chì l'applicazione pare ch'ella sia andata pazza per qualcosa o hè "bloccata" è ùn hè micca finita - è avemu bisognu. mandate SIGKILL, vale à dì, compie duramente u so travagliu. Hè per quessa, avemu qualchì tipu di demone in esecuzione, processa operazioni. Avemu capitu chì in media e nostre operazioni chì u daemon travaglia ùn duranu più di 30 seconde à volta. Dunque, quandu SIGTERM ghjunghje, capiscenu chì u nostru demoniu pò, à u più, finisce 30 seconde dopu à SIGTERM. Scrivemu, per esempiu, 45 seconde in casu è dicemu chì SIGTERM. Dopu quì, aspittemu 45 seconde. In teoria, durante stu tempu, u dimòniu duveria avè finitu u so travagliu è finitu stessu. Ma s'ellu di colpu ùn pudia micca, significa chì u più prubabilmente hè appiccicatu - ùn hè più processatu e nostre dumande nurmale. È in 45 seconde pudete in modu sicuru, in fattu, chjappà.
È quì, in fattu, ancu 2 aspetti pò esse cunsideratu. Prima, capisce chì, se avete ricevutu una dumanda, avete cuminciatu à travaglià cun ella in qualchì modu è ùn hà micca datu una risposta à l'utilizatore, ma avete ricevutu SIGTERM, per esempiu. Hè sensu per raffinà è dà una risposta à l'utilizatori. Questu hè u puntu numeru unu in questu sensu. U puntu numeru dui quì hè chì se scrive a vostra propria applicazione, generalmente custruite l'architettura in tale manera chì riceve una dumanda per a vostra applicazione, allora cuminciate un travagliu, cuminciate à scaricà fugliali da un locu, scaricate una basa di dati, è quant'è. Chì. In generale, u vostru utilizatore, a vostra dumanda pende per una meza ora è aspetta per risponde à ellu - allora, assai prubabile, avete bisognu di travaglià nantu à l'architettura. Vale à dì, basta à piglià in contu ancu u sensu cumunu chì se e vostre operazioni sò brevi, allora hè sensu per ignurà SIGTERM è mudificà. Se e vostre operazioni sò longu, allora ùn hè micca sensu per ignurà SIGTERM in questu casu. Hè sensu di riprogettà l'architettura per evità operazioni cusì longu. Per quessa, l'utilizatori ùn si fermanu micca solu è aspittà. Ùn sò micca sapè, fate un tipu di websocket quì, fate un ganciu inversu chì u vostru servitore hà digià mandatu à u cliente, qualsiasi altra cosa, ma ùn forzà micca l'utilizatore à appiccà per una meza ora è aspittà solu per una sessione finu à voi. rispondimi. Perchè hè imprevisible induve puderia rompe.
Quandu a vostra applicazione finisce, duvete furnisce un codice di uscita adattatu. Questu hè, se a vostra applicazione hè stata dumandata à chjude, ferma, è hà sappiutu piantà di solitu, allora ùn avete micca bisognu di rinvià qualchì tipu di codice di uscita 1,5,255 è cusì. Tuttu ciò chì ùn hè micca u codice zero, almenu in i sistemi Linux, sò sicuru di questu, hè cunsideratu senza successu. Questu hè, hè cunsideratu chì a vostra applicazione in questu casu hà finitu cù un errore. Dunque, in modu amichevule, se a vostra applicazione hè cumpletata senza errore, dite 0 nantu à l'output. Se a vostra applicazione falla per una certa ragione, dite non-0 in u output. È pudete travaglià cù sta infurmazione.
È l'ultima opzione. Hè male quandu u vostru utilizatore manda una dumanda è pende per una meza ora mentre u processate. Ma in generale, vogliu ancu dì di ciò chì generalmente vale a pena da a parte di u cliente. Ùn importa micca s'ellu avete una applicazione mobile, front-end, etc. Hè necessariu di piglià in contu chì in generale a sessione di l'utilizatore pò esse terminata, tuttu pò succede. Una dumanda pò esse mandata, per esempiu, sottuprocessata è nisuna risposta tornata. U vostru frontend o a vostra applicazione mobile - qualsiasi frontend in generale, diciamu cusì - deve piglià questu in contu. Se travagliate cù websockets, questu hè in generale u peghju dulore chì aghju mai avutu.
Quandu i sviluppatori di certi chats regulari ùn sanu micca chì, risulta chì u websocket pò rompe. Per elli, quandu qualcosa succede à u proxy, cambiamu solu a cunfigurazione, è face una ricarica. Naturalmente, tutte e sessioni longu sò strappate in questu casu. I sviluppatori venenu correndu da noi è dicenu: "Ragazzi, chì fate, a chat hè rotta per tutti i nostri clienti!" Li dicemu : « Chì faci ? I vostri clienti ùn ponu micca cunnettà? Dicenu: "No, avemu bisognu di e sessioni per ùn esse strappate". In cortu, questu hè veramente un assurdità. U latu di u cliente deve esse cunsideratu. In particulare, cum'è dicu, cù e sessioni longu cum'è websockets, pò rompe è, senza nutà da l'utilizatori, avete bisognu di pudè reinstallà tali sessioni. E allora tuttu hè perfettu.
Risorse
In verità, quì vi dicu solu una storia diretta. Di novu da a vita vera. A cosa più malata chì aghju mai intesu parlà di risorse.
Risorse in questu casu, vogliu dì, qualchì tipu di richieste, limiti chì pudete mette nantu à pods in i vostri clusters Kubernetes. A cosa più divertente chì aghju intesu da un sviluppatore ... Unu di i mo cumpagni di sviluppatori in un postu di travagliu precedente hà dettu una volta: "A mo applicazione ùn principia micca in u cluster". Aghju guardatu per vede chì ùn era micca principiatu, ma o ùn hè micca adattatu in i risorse, o avianu stabilitu limiti assai chjuchi. In corta, l'applicazione ùn pò micca inizià per via di risorse. Dicu: "Ùn cumincerà micca per via di risorse, decide quantu avete bisognu è stabilisce un valore adattatu". Ellu dice: "Chì tipu di risorse?" Aghju cuminciatu à spiegà à ellu chì Kubernetes, i limiti di e dumande è bla, bla, bla deve esse stabilitu. L'omu ascoltò cinque minuti, annunziò è disse: "Sò venutu quì per travaglià cum'è sviluppatore, ùn vogliu micca sapè nunda di qualsiasi risorse. Sò ghjuntu quì per scrive codice è basta. Hè tristu. Questu hè un cuncettu assai tristu da u puntu di vista di u sviluppatore. In particulare in u mondu mudernu, per dì cusì, di devops progressivi.
Perchè sò necessarie risorse in tuttu? Ci sò 2 tippi di risorse in Kubernetes. Certi sò chjamati dumande, altri sò chjamati limiti. Per risorse capisceremu chì ci sò sempre solu duie restrizioni basi. Vale à dì, i limiti di u tempu di CPU è i limiti di RAM per un containeru in esecuzione in Kubernetes.
Un limitu pone un limitu superiore nantu à cumu una risorsa pò esse usata in a vostra applicazione. Questu hè, per quessa, se dite 1GB di RAM in i limiti, allora a vostra applicazione ùn puderà micca aduprà più di 1GB di RAM. È s'ellu di colpu vole è prova di fà questu, allora un prucessu chjamatu oom killer, fora di memoria, vale à dì, venerà è tumbà a vostra applicazione - vale à dì, solu riavviarà. L'applicazioni ùn riavviaranu micca basatu nantu à CPU. In quantu à u CPU, se una applicazione prova di utilizà assai, più di ciò chì hè specificatu in i limiti, u CPU serà simplicemente sceltu strettamente. Questu ùn porta micca à riavvia. Questu hè u limitu - questu hè u limitu superiore.
È ci hè una dumanda. Una dumanda hè cumu Kubernetes capisce cumu i nodi in u vostru cluster Kubernetes sò populati cù applicazioni. Vale à dì, una dumanda hè un tipu di impegnu di a vostra applicazione. Dice ciò chì vogliu aduprà: "Vogliu chì riservà stu CPU è sta memoria per mè". Una analogia cusì simplice. E se avemu un node chì hà, ùn sò micca, 8 CPU in totale. È un pod arriva quì, chì e dumande dicenu 1 CPU, chì significa chì u node hà 7 CPU manca. Questu hè, per quessa, appena 8 pods ghjunghjenu à stu node, ognunu di i quali hà 1 CPU in e so dumande, u node, cum'è da u puntu di vista di Kubernetes, hà scappatu di CPU è più pods cù richieste ùn ponu micca esse. lanciatu nant'à stu node. Se tutti i nodi escenu di CPU, allora Kubernetes hà da cumincià à dì chì ùn ci sò micca nodi adattati in u cluster per eseguisce i vostri pods perchè u CPU hè scappatu.
Perchè e dumande sò necessarie è perchè senza richieste, pensu chì ùn ci hè bisognu di lancià qualcosa in Kubernetes? Imaginemu una situazione ipotetica. Lanciate a vostra applicazione senza richieste, Kubernetes ùn sapi micca quantu di ciò chì avete, à quali nodi pudete spinghje. Ebbè, spinge, spinge, spinge nantu à i nodi. À un certu puntu, avete da cumincià à ottene u trafficu à a vostra applicazione. È una di l'applicazioni di colpu principia à aduprà risorse finu à i limiti chì hà secondu i limiti. Risulta chì ci hè una altra applicazione vicinu è hà ancu bisognu di risorse. U node in realtà principia à esce fisicamente senza risorse, per esempiu, OP. U node in realtà principia à esce fisicamente senza risorse, per esempiu, memoria d'accessu aleatoriu (RAM). Quandu un node sguassate u putere, prima di tuttu u docker smette di risponde, dopu u cubelet, dopu u SO. Semplicemente andaranu inconsciente è TUTTI definitivamente cessanu di travaglià per voi. Vale à dì, questu portarà à u vostru node chì si blocca è avete bisognu di riavvia. In corta, a situazione ùn hè micca assai bona.
È quandu avete richieste, i limiti ùn sò micca assai diffirenti, almenu micca parechje volte più di i limiti o richieste, allora pudete avè un cumpletu cusì normale è raziunale di applicazioni in i nodi di clusters Kubernetes. À u listessu tempu, Kubernetes hè apprussimatamente cuscente di quantu di ciò chì mette induve, quantu di ciò chì hè utilizatu induve. Questu hè, hè solu un mumentu cusì. Hè impurtante di capiscenu. È hè impurtante di cuntrollà chì questu hè indicatu.
Storage di dati
U nostru prossimu puntu hè di u almacenamiento di dati. Chì fà cun elli è in generale, chì fà cù a persistenza in Kubernetes?
Pensu, di novu, in u nostru , ci era un tema nantu à a basa di dati in Kubernetes. È mi pare chì sò ancu apprussimatamente ciò chì i vostri culleghi vi anu dettu quandu avete dumandatu: "Hè pussibule di gestisce una basa di dati in Kubernetes?" Per una certa raghjone, mi pari chì i vostri culleghi duveranu avè dettu chì, sè vo fate a quistione s'ellu hè pussibule eseguisce una basa di dati in Kubernetes, allora hè impussibile.
A logica quì hè simplice. In casu, vi spiegheraghju una volta di più, sè vo site un omu veramente cool chì pò custruisce un sistema abbastanza tolerante à i difetti di almacenamentu in rete distribuitu, capisce cumu si mette una basa di dati in questu casu, cumu a nuvola nativa in cuntenituri deve travaglià. in una basa di dati in generale. Hè assai prubabile, ùn avete micca dubbitu nantu à cumu eseguisce. Sè vo avete una tale quistione, è vo vulete assicurà chì tuttu si sviluppa è ferma ghjustu à a morte in a pruduzzione è ùn cascà mai, allora questu ùn succede micca. Avete assicuratu di sparà in u pede cù questu approcciu. Allora hè megliu micca.
Chì duvemu fà cù e dati chì a nostra applicazione piacerebbe almacenà, alcune foto chì l'utilizatori caricanu, alcune cose chì a nostra applicazione genera durante u so funziunamentu, à l'iniziu, per esempiu? Cosa fà cun elli in Kubernetes?
In generale, idealmente, sì, sicuru, Kubernetes hè assai bè cuncepitu è hè statu generalmente cuncipitu inizialmente per applicazioni senza statu. Vale à dì, per quelli applicazioni chì ùn guardanu micca l'infurmazioni in tuttu. Questu hè ideale.
Ma, sicuru, l'opzione ideale ùn esiste micca sempre. Allora? U primu puntu è più simplice hè di piglià un tipu di S3, solu micca un fattu in casa, chì ùn hè ancu chjaru cumu si travaglia, ma da qualchì fornitore. Un bon fornitore normale - è insegna à a vostra applicazione à utilizà S3. Questu hè, quandu u vostru utilizatore vole cullà un schedariu, dite "quì, per piacè, caricate in S3". Quandu ellu vole riceve, dì: "Eccu un ligame à S3 torna è pigliate da quì". Questu hè ideale.
Se di colpu per una certa ragione sta opzione ideale ùn hè micca adattata, avete una applicazione chì ùn avete micca scrittu, ùn avete micca sviluppatu, o hè un tipu di eredità terribile, ùn pò micca aduprà u protokollu S3, ma deve travaglià cù cartulari lucali in cartulare lucali. Pigliate qualcosa più o menu simplice, implementate Kubernetes. Vale à dì, scherma immediatamente Ceph per alcuni travaglii minimi, mi pari, hè una mala idea. Perchè Ceph, sicuru, hè bonu è di moda. Ma s'ellu ùn capisce micca veramente ciò chì fate, allora una volta chì mette qualcosa nantu à Ceph, pudete fà assai facilmente è simpricimenti ùn mai più esce da quì. Perchè, cum'è sapete, Ceph guarda dati in u so cluster in forma binaria, è micca in forma di schedarii simplici. Per quessa, s'ellu di colpu u cluster Ceph si rompe, tandu ci hè una prubabilità cumpleta è alta chì ùn avete mai più i vostri dati da quì.
Averemu un cursu nantu à Ceph, pudete .
Dunque, hè megliu fà qualcosa simplice cum'è un servitore NFS. Kubernetes pò travaglià cun elli, pudete muntà un repertoriu sottu un servitore NFS - a vostra applicazione hè cum'è un repertoriu lucale. À u listessu tempu, naturalmente, avete bisognu di capiscenu chì, di novu, avete bisognu di fà qualcosa cù u vostru NFS, avete bisognu di capiscenu chì qualchì volta pò esse inaccessibile è cunsiderà a quistione di ciò chì fate in questu casu. Forse deve esse salvata in un locu in una macchina separata.
U prossimu puntu ch'e aghju parlatu hè ciò chì deve fà se a vostra applicazione genera qualchi schedari durante l'operazione. Per esempiu, quandu principia, genera un schedariu staticu, chì hè basatu annantu à qualchì infurmazione chì l'applicazione riceve solu à u mumentu di u lanciu. Chì mumentu. Sè ùn ci hè micca assai tali dati, allura tu nun hannu a fastidiu à tutti, basta à stallà sta dumanda per sè stessu è travaglià. L'unica quistione quì hè chì, guarda. Assai spessu, tutti i tipi di sistemi legati, cum'è WordPress è cusì, soprattuttu cù mudificate qualchì tipu di plugins intelligenti, sviluppatori PHP intelligenti, spessu sà cumu fà cusì chì generanu qualchì tipu di schedariu per elli stessi. Per quessa, unu genera un schedariu, u sicondu genera un second file. Sò diffirenti. L'equilibriu accade in u cluster Kubernetes di i clienti solu per casu. Per quessa, si trova chì ùn sanu micca cumu travaglià inseme in esempiu. Unu dà una infurmazione, l'altru dà à l'utilizatori un'altra infurmazione. Questu hè qualcosa chì duvete evità. Vale à dì, in Kubernetes, tuttu ciò chì lanciate hè garantitu per pudè travaglià in parechje casi. Perchè Kubernetes hè una cosa in muvimentu. In cunsiquenza, pò muvimenti qualcosa, quandu ellu vole, senza dumandà à nimu. Dunque, avete bisognu di cuntà nantu à questu. Tuttu ciò chì hè lanciatu in una istanza prima o poi fallirà. Più riserve avete, u megliu. Ma dinò, dicu, s'è vo avete uni pochi di tali schedari, allura vi ponu mette ghjustu sottu à voi, pisanu una piccula quantità. S'ellu ci hè un pocu più di elli, probabilmente ùn deve micca imbuttà in u cuntinuu.
Avissi cunsigliu chì ci hè una cosa maravigliosa in Kubernetes, pudete aduprà u voluminu. In particulare, ci hè un voluminu di tipu dir viotu. Hè, hè solu chì Kubernetes hà da creà automaticamente un annuariu in i so repertorii di serviziu in u servitore induve avete principiatu. È ellu vi darà per chì pudete aduprà. Ci hè solu un puntu impurtante. Vale à dì, i vostri dati ùn saranu micca guardati in u cuntinuu, ma piuttostu nantu à l'ospite nantu à quale site in esecuzione. Inoltre, Kubernetes pò cuntrullà tali dirs vioti in cunfigurazione normale è hè capaci di cuntrullà a so dimensione massima è ùn permettenu micca esse superatu. L'unicu puntu hè chì ciò chì avete scrittu in u dir viotu ùn hè micca persu durante u pod restarts. Vale à dì, se u vostru pod cascà per sbagliu è si risuscita di novu, l'infurmazioni in u dir viotu ùn andaranu in ogni locu. Pò usà di novu à un novu principiu - è hè bonu. Se u vostru pod parte in un locu, allora naturalmente lascià senza dati. Vale à dì, appena u pod da u node induve hè stata lanciata cù u dir viotu sparisce, u dir viotu hè sguassatu.
Chì altru hè bonu di dir viotu? Per esempiu, pò esse usatu cum'è cache. Imaginemu chì a nostra applicazione genera qualcosa nantu à a mosca, dà à l'utilizatori, è fà per un bellu pezzu. Dunque, l'applicazione, per esempiu, genera è dà à l'utilizatori, è à u stessu tempu l'almacene in un locu, perchè a prossima volta chì l'utilizatore vene per a listessa cosa, serà più veloce per dà immediatamente generatu. U dir viotu pò esse dumandatu à Kubernetes per creà in memoria. È cusì, i vostri cache ponu generalmente travaglià à a velocità di u lampu - in quantu à a velocità di accessu à u discu. Questu hè, avete un dir viotu in memoria, in u SO hè guardatu in memoria, ma per voi, per l'utilizatore in u pod, pare solu un repertoriu lucale. Ùn avete micca bisognu di l'app per insegnà specificamente alcuna magia. Pigliate direttamente è mette u vostru schedariu in un cartulare, ma, in fattu, in memoria in u SO. Questa hè ancu una funzione assai còmuda in quantu à Kubernetes.
Chì prublemi hà Minio ? U prublema principali cù Minio hè chì, per chì sta cosa funziona, deve esse in esecuzione in un locu, è deve esse un tipu di sistema di fugliale, vale à dì, almacenamiento. È quì avemu scontru i stessi prublemi chì Ceph hà. Vale à dì, Minio deve almacenà i so fugliali in qualchì locu. Hè solu una interfaccia HTTP à i vostri schedari. Inoltre, a funziunalità hè chjaramente più povera di quella di l'S3 di Amazon. Nanzu, ùn era micca capaci di auturizà bè l'utilizatori. Avà, quantu a so, pò digià creà buckets cù diverse autorizazioni, ma di novu, mi pari chì u prublema principali hè, per dì cusì, u sistema di almacenamentu sottumessu à u minimu.
Cumu l'Empty dir in memoria influenza i limiti? Ùn affetta micca i limiti in ogni modu. Si trova in a memoria di l'ospite, è micca in a memoria di u vostru cuntinuu. Questu hè, u vostru cuntinuu ùn vede micca u dir viotu in memoria cum'è parte di a so memoria occupata. L'ospite vede questu. In cunsiquenza, sì, da u puntu di vista di kubernetes, quandu avete principiatu à aduprà questu, saria bonu per capiscenu chì site dedicatu una parte di a vostra memoria à dir viotu. È per quessa, capisce chì a memoria pò esce micca solu per via di l'applicazioni, ma ancu perchè qualcunu scrive à questi dirs vacanti.
Nuvolatezza
È u subtopic finali hè ciò chì Cloudnative hè. Perchè hè necessariu? Cloudnativeness è cusì.
Vale à dì, quelli applicazioni chì sò capaci è scritte per travaglià in una infrastruttura nuvola moderna. Ma, in fattu, Cloudnative hà un altru tali aspettu. Chì questu ùn hè micca solu una applicazione chì piglia in contu tutte e esigenze di una infrastruttura di nuvola muderna, ma sà ancu cumu travaglià cù questa infrastruttura di nuvola moderna, prufittà di i vantaghji è i disadvantages di u fattu chì travaglia in questi nuvuli. Ùn andate micca solu è travaglià in i nuvuli, ma apprufittate di i benefici di travaglià in u nuvulu.
Pigliamu solu Kubernetes cum'è un esempiu. A vostra applicazione hè in esecuzione in Kubernetes. A vostra applicazione pò sempre, o megliu l'amministratori per a vostra applicazione, ponu sempre creà un contu di serviziu. Questu hè, un contu per l'autorizazione in Kubernetes stessu in u so servitore. Aghjunghjite alcuni diritti chì avemu bisognu. È pudete accede à Kubernetes da a vostra applicazione. Chì pudete fà cusì? Per esempiu, da l'applicazione, riceve dati nantu à induve e vostre altre applicazioni, altre istanze simili si trovanu, è inseme in qualchì modu cluster in cima à Kubernetes, se ci hè una tale necessità.
In novu, avemu literalmente avutu un casu recentemente. Avemu un controller chì monitoreghja a fila. È quandu alcuni novi compiti appariscenu in questa fila, si va à Kubernetes - è in Kubernetes crea un novu pod. Dà stu pod un novu compitu è in u quadru di stu pod, u pod esegue u compitu, manda una risposta à u controller stessu, è u controller poi face qualcosa cù questa informazione. Per esempiu, aghjunghje una basa di dati. Hè, di novu, questu hè un plus di u fattu chì a nostra applicazione funziona in Kubernetes. Pudemu aduprà a funziunalità integrata di Kubernetes stessu per espansione in qualchì modu è rende a funziunalità di a nostra applicazione più còmuda. Vale à dì, ùn nasconde micca una sorta di magia nantu à cumu lancià una applicazione, cumu lancià un travagliadore. In Kubernetes, basta à mandà una dumanda in l'app se l'applicazione hè scritta in Python.
U listessu vale s'ellu andemu oltre Kubernetes. Avemu u nostru Kubernetes in esecuzione in qualchì locu - hè bonu s'ellu hè in qualchì tipu di nuvola. In novu, pudemu usà, è ancu duverebbe, crede, aduprà e capacità di u nuvulu stessu induve avemu in esecuzione. Da e cose elementari chì u nuvulu ci furnisce. Balancing, vale à dì, pudemu creà balancers di nuvola è aduprà. Questu hè un vantaghju direttu di ciò chì pudemu usà. Perchè u bilanciu di nuvola, in prima parte, elimina stupidamente a rispunsabilità da noi per cumu funziona, cumu hè cunfiguratu. In più hè assai còmuda, perchè Kubernetes regulare pò integrà cù i nuvuli.
U stessu passa per a scala. Kubernetes regulare pò integrà cù i fornitori di nuvola. Sapi cum'è capisce chì se u cluster esce da i nodi, vale à dì, u spaziu di u nodu hè finitu, allora avete bisognu di aghjunghje - Kubernetes stessu aghjunghjenu novi nodi à u vostru cluster è cumincià à lancià pods nantu à elli. Questu hè, quandu a vostra carica vene, u nùmeru di fogghi cumencia à aumentà. Quandu i nodi in u cluster esce per questi podi, Kubernetes lancia novi nodi è, per quessa, u numeru di pods pò ancu aumentà. È hè assai còmuda. Questa hè una opportunità diretta per scala u cluster in u volu. Micca assai veloce, in u sensu chì ùn hè micca un secondu, hè più cum'è un minutu per aghjunghje novi nodi.
Ma da a mo sperienza, di novu, hè a cosa più bella chì aghju mai vistu. Quandu u cluster Cloudnative scaled basatu annantu à l'ora di u ghjornu. Era un serviziu backend chì era utilizatu da e persone in u back office. Vale à dì, venenu à travaglià à 9 am, cumincianu à login in u sistema, è in cunseguenza, u cluster Cloudnative, induve tuttu hè in esecuzione, cumencia à gonfià, lanciando novi pods per chì tutti quelli chì venenu à travaglià ponu travaglià cù l'applicazione. Quandu partenu da u travagliu à 8 ore o 6 ore di sera, i clusters Kubernetes avvisanu chì nimu ùn usa più l'applicazione è cumincianu à diminuisce. Risparmi finu à u 30 per centu hè garantitu. Funzionava in Amazon à quellu tempu; à quellu tempu ùn ci era nimu in Russia chì puderia fà cusì bè.
Vi dicu drittu, u risparmiu hè 30 per centu solu perchè usemu Kubernetes è prufittà di e capacità di u nuvulu. Avà questu pò esse fattu in Russia. Ùn aghju micca annunzià à nimu, sicuru, ma diciamu solu chì ci sò fornituri chì ponu fà questu, furnisce u dirittu fora di a scatula cù un buttone.
Ci hè un ultimu puntu chì vogliu ancu attirà a vostra attenzione. Per chì a vostra applicazione, a vostra infrastruttura per esse Cloudnative, hè sensu di principià infine à adattà l'approcciu chjamatu Infrastruttura cum'è Codice, vale à dì, questu significa chì a vostra applicazione, o megliu a vostra infrastruttura, hè necessariu esattamente in u listessu modu cum'è u codice. codice Descrive a vostra applicazione, a vostra logica cummerciale in forma di codice. È travaglià cun ellu cum'è codice, vale à dì, pruvate, stende, guardà in git, applica CICD.
È questu hè esattamente ciò chì vi permette, prima, di avè sempre u cuntrollu di a vostra infrastruttura, per capisce sempre in quale statu hè. Siconda, evite l'operazioni manuali chì causanu errori. Terzu, evite solu ciò chì hè chjamatu turnover, quandu avete sempre bisognu di fà i stessi travaglii manuali. Quartu, vi permette di ricuperà assai più veloce in casu di fallimentu. In Russia, ogni volta chì parlu di questu, ci sò sempre un gran numaru di persone chì dicenu: "Iè, hè chjaru, ma avete avvicinamenti, in breve, ùn ci hè bisognu di riparà nunda". Ma hè vera. Se qualcosa hè rottu in a vostra infrastruttura, allora da u puntu di vista di l'approcciu Cloudnative è da u puntu di vista di l'Infrastruttura cum'è Codice, invece di riparà, andendu à u servitore, capisce ciò chì hè rottu è riparà, hè più faciule. per sguassà u servitore è creanu di novu. È aghju tuttu questu restauratu.
Tutti questi prublemi sò discututi in più detail à . Seguindu u ligame, pudete familiarizàvi cù u prugramma è e cundizioni. A cosa cunvene hè chì pudete masterizà Kubernetes studiendu da casa o travagliu per 1-2 ore à ghjornu.
Source: www.habr.com