{"id":34450,"date":"2019-10-31T21:58:24","date_gmt":"2019-10-31T18:58:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kubernetes-zahvatit-mir-kogda-i-kak\/"},"modified":"2019-10-31T21:58:24","modified_gmt":"2019-10-31T18:58:24","slug":"kubernetes-zahvatit-mir-kogda-i-kak","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kubernetes-zahvatit-mir-kogda-i-kak","title":{"rendered":"Kubernetes conquister\u00e0 il mondo. Quando e come?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

In vista di DevOpsConf<\/a><\/noindex> Vitalij Chabarov<\/b> ha intervistato\u00a0Dmitrij Stolyarov<\/b> (distol<\/a><\/noindex>), direttore tecnico e cofondatore dell'azienda \"Flant\". Vitalij ha chiesto a Dmitrij cosa fa la \"Flant\", di Kubernetes, dello sviluppo dell'ecosistema e del supporto. Hanno discusso del perch\u00e9 Kubernetes sia importante e se sia davvero necessario. E anche dei microservizi, di Amazon AWS, dell'approccio \"Mi va bene\" in DevOps, del futuro di Kubernetes e del perch\u00e9, quando e come conquister\u00e0 il mondo, delle prospettive per DevOps e di cosa devono prepararsi gli ingegneri in un futuro prossimo con semplificazioni e reti neurali.<\/p>\n

L'intervista originale<\/a><\/noindex> puoi ascoltarla nel formato podcast su DevOps Deflope \u2014 il podcast in lingua russa su DevOps, e qui sotto trovi la versione testuale. <\/p>\n

\"Kubernetes
\n
\nQui e oltre le domande sono poste da Vitalij Chabarov<\/a><\/noindex> un ingegnere di Express42.
\n<\/a><\/noindex><\/p>\n

Su \"Flant\"<\/h2>\n

\n\u2014 Dima, ciao. Sei il direttore tecnico di \"Flant<\/a><\/noindex>\" e anche il suo fondatore. Raccontami, per favore, di cosa si occupa l'azienda e quale ruolo hai tu?<\/b><\/p>\n

\"KubernetesDmitrij<\/b>: All'esterno sembriamo degli esperti che si occupano di Kubernetes e ne sfruttano le potenzialit\u00e0. Ma non \u00e8 cos\u00ec. Siamo nati come azienda specializzata in Linux, ma da molto tempo ci concentriamo principalmente sulla gestione di progetti high-load e di produzione chiavi in mano. Di solito costruiamo l'intera infrastruttura da zero e poi ci occupiamo di essa a lungo termine. Pertanto, il lavoro principale che svolge \u00ab\u0424\u043b\u0430\u043d\u0442\u00bb e per cui viene remunerata \u00e8 prenderci la responsabilit\u00e0 e realizzare produzioni chiavi in mano<\/b>.
\n

\n

\nIo, come CTO e uno dei fondatori dell'azienda, passo le mie giornate a pensare a come aumentare l'affidabilit\u00e0 della produzione, semplificarne la gestione e rendere la vita degli amministratori pi\u00f9 facile, mentre quella degli sviluppatori pi\u00f9 piacevole.<\/p>\n

Riguardo a Kubernetes<\/h2>\n

\n\u2014 Ultimamente da \u00ab\u0424\u043b\u0430\u043d\u0442\u00bb vedo molti interventi e\u00a0articoli<\/a><\/noindex> sul Kubernetes. Come ci siete arrivati?<\/b><\/p>\n

Dmitrij<\/b>: Ne ho parlato molte volte, ma non mi dispiace ripeterlo. Credo sia giusto ripetere questo argomento, poich\u00e9 si crea confusione tra causa ed effetto.<\/p>\n

Avevamo davvero bisogno di uno strumento. Ci siamo trovati ad affrontare molte problematiche, lottando e superando ostacoli con varie soluzioni di fortuna, e sentivamo il bisogno di un vero strumento. Abbiamo esplorato molte opzioni diverse, ci siamo adattati e accumulato esperienza. Siamo giunti al punto in cui abbiamo iniziato a utilizzare Docker quasi subito dopo la sua uscita \u2014 intorno al 2013. Al momento della sua introduzione, avevamo gi\u00e0 molta esperienza con i container e avevamo persino scritto una sorta di 'Docker' \u2014 una nostra soluzione provvisoria in Python. Con l'arrivo di Docker, abbiamo potuto abbandonare queste soluzioni temporanee a favore di una soluzione solida e supportata dalla comunit\u00e0.<\/p>\n

La storia con Kubernetes \u00e8 simile. Quando ha iniziato a guadagnare attenzione \u2014 per noi la versione 1.2 \u2014 avevamo gi\u00e0 un sacco di soluzioni comuni, sia in Shell che in Chef, che stavamo cercando di orchestrare con Docker. Abbiamo preso seriamente in considerazione Rancher e altre soluzioni, ma a quel punto \u00e8 arrivato Kubernetes, realizzato esattamente come lo avremmo fatto noi, se non addirittura meglio. Non c'\u00e8 nulla di cui lamentarsi.<\/p>\n

S\u00ec, ci sono alcune incompletezze qui, molte cose non sono finite, e la 1.2 \u00e8 davvero terribile, ma... Kubernetes \u00e8 come un edificio in costruzione: guardi il progetto e capisci che diventer\u00e0 fantastico. Se l'edificio ha gi\u00e0 le fondamenta e due piani, capisci che \u00e8 meglio non trasferirsi per ora, mentre con il software non ci sono questi problemi: \u00e8 gi\u00e0 utilizzabile.<\/p>\n

Non c'\u00e8 mai stato un momento in cui ci siamo chiesti se utilizzare Kubernetes o meno. Lo aspettavamo da molto tempo prima che apparisse e cercavamo di costruire analoghi da soli.<\/p><\/blockquote>\n

<\/p>\n

Circa Kubernetes<\/h2>\n

\n\u2014 Partecipate direttamente allo sviluppo di Kubernetes stesso?<\/b><\/p>\n

Dmitrij<\/b>: Indirettamente. Piuttosto partecipiamo allo sviluppo dell'ecosistema. Inviamo un certo numero di pull request: in Prometheus, in vari operatori, in Helm \u2014 nell'ecosistema. Sfortunatamente, non sono in grado di seguire tutto ci\u00f2 che facciamo e potrei sbagliarmi, ma non abbiamo inviato alcun pull request al kernel.<\/p>\n

\u2014 Allo stesso tempo sviluppate anche molti dei vostri strumenti attorno a Kubernetes?<\/b><\/p>\n

Dmitrij<\/b>: La strategia \u00e8 questa: andiamo e facciamo pull request su tutto ci\u00f2 che gi\u00e0 esiste. Se non vengono accettati pull request, semplicemente li forkamo per noi stessi e continuiamo a vivere, finch\u00e9 non vengono accettati con le nostre build. Poi, quando questo arriva nell\u2019upstream, torniamo alla versione upstream.<\/p>\n

Ad esempio, abbiamo un operatore Prometheus, con il quale abbiamo switchato su e gi\u00f9 nella nostra build upstream gi\u00e0 circa 5 volte. Abbiamo bisogno di una certa funzione, abbiamo inviato un pull request, dobbiamo implementarla domani, e non vogliamo aspettare il suo rilascio nell\u2019upstream. Pertanto, ci costruiamo la nostra versione con la funzione di cui abbiamo bisogno, su tutti i nostri cluster. Poi, per esempio, questo viene riportato nell\u2019upstream con le parole: \u00abRagazzi, facciamolo per un caso pi\u00f9 generale\u00bb, noi, o qualcun altro, lo completiamo e col tempo viene nuovamente integrato.<\/p>\n

Tutto ci\u00f2 che esiste, cerchiamo di svilupparlo.<\/b>. Molti elementi che non esistono ancora non sono stati ancora inventati o sono stati inventati ma non sono stati implementati - noi lo facciamo. E non perch\u00e9 ci piaccia il processo stesso o la costruzione di biciclette come settore, ma semplicemente perch\u00e9 abbiamo bisogno di questo strumento. Ci viene spesso chiesto perch\u00e9 abbiamo realizzato questo o quel cosa. La risposta \u00e8 semplice: perch\u00e9 dovevamo andare avanti, risolvere un problema pratico, e l'abbiamo risolto con questo strumento.<\/p>\n

Il percorso \u00e8 sempre lo stesso: cerchiamo con molta attenzione e, se non troviamo alcuna soluzione su come fare un filobus con una pagnotta di pane, allora facciamo la nostra pagnotta e il nostro filobus.<\/p><\/blockquote>\n

<\/p>\n

Strumenti di 'Flanta'<\/h2>\n

\n\u2014 So che ora 'Flanta' ha operatori addon, operatori shell, strumenti dapp\/werf. Se ho capito bene, si tratta dello stesso strumento in diverse incarnazioni. Inoltre, capisco che all'interno di 'Flanta' ci sono molti altri strumenti diversi. \u00c8 cos\u00ec?<\/b><\/p>\n

Dmitrij<\/b>: Su GitHub abbiamo ancora molte altre cose. Tra quelle che ricordo, abbiamo statusmap \u2014 un pannello per Grafana che \u00e8 piaciuto a tutti. Viene menzionato quasi in ogni secondo articolo riguardante il monitoraggio di Kubernetes su Medium. \u00c8 impossibile spiegare brevemente cos'\u00e8 statusmap \u2014 serve un articolo a parte, ma \u00e8 uno strumento molto utile per il monitoraggio dello stato nel tempo, poich\u00e9 in Kubernetes \u00e8 spesso necessario mostrare lo stato nel tempo. Abbiamo anche LogHouse \u2014 \u00e8 una soluzione basata su ClickHouse e un po' di magia nera per la raccolta dei log in Kubernetes.<\/p>\n

Tante utility! E ce ne saranno ancora di pi\u00f9, poich\u00e9 alcune soluzioni interne saranno rilasciate quest'anno. Tra le pi\u00f9 importanti, ci sono molte addon per Kubernetes come, ad esempio, come installare correttamente il cert-manager \u2014 uno strumento per la gestione dei certificati, oppure come installare Prometheus con una serie di componenti aggiuntivi \u2014 ci sono circa venti diversi binari che esportano dati e raccolgono informazioni. Con Prometheus, ottieni grafica fantastica e allerta. Tutto questo \u00e8 un insieme di addon per Kubernetes, che vengono installati nel cluster, trasformandolo da semplice a avanzato, automatico, dove molte questioni sono gi\u00e0 risolte. S\u00ec, stiamo facendo molte cose.<\/p>\n

Sviluppo dell'ecosistema<\/h2>\n

\n\u2014 Mi sembra un contributo molto significativo allo sviluppo di questo strumento e dei suoi metodi di utilizzo. Puoi fare un'idea di chi altro potrebbe contribuire in modo simile allo sviluppo dell'ecosistema?<\/b><\/p>\n

Dmitrij<\/b>: In Russia, tra le aziende che operano nel nostro mercato \u2014 nessuno anche lontanamente.<\/b>. Certamente, \u00e8 un'affermazione audace, perch\u00e9 ci sono grandi attori come Mail e Yandex che stanno lavorando su Kubernetes, ma anche loro non si avvicinano al contributo delle aziende a livello globale, che \u00e8 molto maggiore del nostro. \u00c8 difficile confrontare Flant con un team di 80 persone e Red Hat, che conta circa 300 ingegneri solo per Kubernetes, se non sbaglio. \u00c8 complicato fare il paragone. Nel nostro dipartimento R&D ci sono 6 persone, me compreso, che sviluppano tutti i nostri strumenti. 6 persone contro 300 ingegneri di Red Hat \u00e8 un confronto piuttosto difficile.<\/p>\n

\u2014 Tuttavia, quando anche queste 6 persone riescono a creare qualcosa di veramente utile e trasferibile, quando affrontano una sfida concreta e offrono la soluzione alla comunit\u00e0, \u00e8 un caso interessante. Capisco che nelle grandi aziende tecnologiche, dove ci sono team di sviluppo e supporto per Kubernetes, si possano sviluppare strumenti simili. Questo per loro \u00e8 un esempio di cosa si pu\u00f2 sviluppare e offrire alla comunit\u00e0, dando uno slancio a tutto il gruppo che utilizza Kubernetes.<\/b><\/p>\n

Dmitrij<\/b>: Probabilmente \u00e8 una caratteristica dell'integratore, una sua peculiarit\u00e0. Noi gestiamo molti progetti e vediamo molte situazioni diverse. Per noi, il principale modo di creare valore aggiunto \u00e8 analizzare questi casi, trovare delle somiglianze e ridurre al minimo i costi per noi. Su questo ci impegniamo attivamente. \u00c8 difficile per me parlare della Russia e del mondo, ma abbiamo circa 40 ingegneri DevOps nell'azienda che si occupano di Kubernetes. Non credo che in Russia ci siano molte aziende con un numero comparabile di specialisti esperti in Kubernetes, se ci sono.<\/p>\n

Comprendo tutto riguardo il titolo di DevOps Engineer, tutti lo capiscono e sono abituati a chiamare gli ingegneri DevOps cos\u00ec, non discuteremo di questo. Questi 40 straordinari ingegneri DevOps affrontano problemi ogni giorno e li risolvono; noi semplicemente analizziamo questa esperienza e cerchiamo di generalizzarla. Capisco che se rimane con noi, tra un anno o due lo strumento diventa inutile, perch\u00e9 da qualche parte nella community ne apparir\u00e0 uno pronto. Non ha senso accumulare questa esperienza all'interno \u2014 \u00e8 solo uno spreco di energie e tempo nel dev\/null. In questo modo, non ci dispiace affatto. Pubblicizziamo tutto con grande piacere e capiamo che \u00e8 necessario pubblicare, sviluppare, fare PR, promuovere, affinch\u00e9 le persone possano usarlo e aggiungere la loro esperienza \u2014 cos\u00ec tutto cresce e vive. Tra due anni, lo strumento non finisce nella spazzatura. Non ci dispiace continuare a investire energie, perch\u00e9 \u00e8 chiaro che qualcuno sta usando il tuo strumento, e dopo due anni lo usano gi\u00e0 tutti.<\/p>\n

Questa \u00e8 parte della nostra grande strategia con dapp\/werf<\/b>. Non ricordo quando abbiamo iniziato a svilupparlo, sembra passato circa 3 anni. Inizialmente era totalmente in shell. Era un super proof of concept, abbiamo risolto alcune delle nostre questioni interne \u2014 e ha funzionato! Ma ci sono problemi con shell, non \u00e8 possibile espanderlo ulteriormente, programmare in shell \u00e8 un vero e proprio impegno. Avevamo l'abitudine di scrivere in Ruby, quindi abbiamo riscritto alcune cose, evolvendo, crescendo, crescendo, ma ci siamo scontrati con la realt\u00e0 che la community, la gente, non dice 'vogliamo o non vogliamo', fa una smorfia nei confronti di Ruby, per quanto sia strano. Abbiamo capito che dovevamo scrivere tutto questo in Go, semplicemente per rispettare il primo punto nella checklist: Il tool DevOps deve essere un binario statico<\/b>. Scrivere in Go o meno non \u00e8 cos\u00ec importante, ma \u00e8 meglio avere un binario statico scritto in Go.<\/p>\n

Abbiamo investito risorse, riscritto dapp in Go e l'abbiamo chiamato werf. Dapp non \u00e8 pi\u00f9 supportato, non viene pi\u00f9 sviluppato, funziona in qualche ultima versione, ma c'\u00e8 un percorso di upgrade assoluto da seguire.<\/p>\n

Perch\u00e9 \u00e8 stato creato dapp<\/h2>\n

\n\u2014 Puoi spiegare brevemente perch\u00e9 \u00e8 stato creato dapp, quali problemi risolve?<\/b><\/p>\n

Dmitrij<\/b>: La prima ragione \u00e8 legata alla costruzione. Inizialmente abbiamo avuto gravi problemi con la costruzione, quando Docker non supportava il multi-stage, e lo abbiamo realizzato da soli. Poi abbiamo avuto anche una serie di domande sulla pulizia delle immagini. Tutti coloro che lavorano con CI\/CD, prima o poi, si trovano ad affrontare il problema di avere un sacco di immagini costruite, e quindi \u00e8 necessario in qualche modo pulire ci\u00f2 che non serve e mantenere ci\u00f2 che \u00e8 utile.<\/p>\n

La seconda ragione riguarda il deploy. Certo, c'\u00e8 Helm, ma risolve solo alcune delle questioni. Anche se pu\u00f2 sembrare strano, \u00e8 scritto che \u00abHelm \u00e8 il Package Manager per Kubernetes\u00bb. Esattamente, con \u00abil\u00bb. Ci sono anche le parole \u00abPackage Manager\u00bb \u2014 quali sono le aspettative tipiche dal Package Manager? Diciamo: \u00abPackage Manager, installa il pacchetto!\u00bb e ci aspettiamo che ci risponda: \u00abPacchetto installato\u00bb. <\/p>\n

\u00c8 interessante che diciamo: \u00abHelm, installa il pacchetto\u00bb, ma quando risponde che l'ha installato, si scopre che in realt\u00e0 ha solo iniziato l'installazione \u2014 ha detto a Kubernetes: \u00abAvvia questo!\u00bb ma se \u00e8 realmente partito o meno, e se funziona o no, Helm non risolve affatto questa domanda.<\/p>\n

Quindi, si scopre che Helm \u00e8 semplicemente un pre-processore testuale che carica dati in Kubernetes.<\/p><\/blockquote>\n

\nMa all'interno di qualsiasi deploy vogliamo sapere se l'applicazione \u00e8 stata distribuita in produzione o meno. Essere in produzione significa che l'applicazione \u00e8 stata rilasciata, \u00e8 stata distribuita una nuova versione e questa deve stare in piedi e rispondere correttamente. Helm non risolve questa questione. Per affrontarla, \u00e8 necessario investire molte energie, poich\u00e9 \u00e8 fondamentale dare a Kubernetes il comando di distribuire e monitorare cosa sta succedendo: \u00e8 stata distribuita o meno. Inoltre, ci sono molte attivit\u00e0 collegate al deploy, alla pulizia e alla compilazione.<\/p>\n

Piani<\/h2>\n

\nQuest'anno ci muoveremo verso lo sviluppo locale. Vogliamo tornare a ci\u00f2 che prima era in Vagrant: un semplice 'vagrant up' per avviare le nostre macchine virtuali. Vogliamo arrivare a uno stato in cui esiste un progetto in Git, e scriviamo 'werf up', il quale avvia una copia locale di questo progetto, disponibile in un mini-Kubernetes locale, con tutte le directory necessarie collegate, rendendo la fase di sviluppo pi\u00f9 conveniente. A seconda del linguaggio di programmazione, questo pu\u00f2 essere eseguito in modi diversi, ma \u00e8 fondamentale poter condurre lo sviluppo locale con i file montati.<\/p>\n

Il prossimo passo per noi \u00e8 significativo investire nel comfort per gli sviluppatori<\/b>. Per schierare rapidamente un progetto localmente con un solo strumento, sviluppare, pushare su Git, e questo sar\u00e0 sicuramente distribuito su stage o in test, a seconda dei pipeline, e poi con lo stesso strumento andare in produzione. Questa unit\u00e0, unificazione, riproducibilit\u00e0 dell'infrastruttura dall'ambiente locale alla produzione \u00e8 un aspetto per noi molto importante. Ma questo non \u00e8 ancora presente in werf \u2014 lo stiamo solo pianificando.<\/p>\n

Ma il percorso verso dapp\/werf \u00e8 sempre stato lo stesso che abbiamo seguito all'inizio con Kubernetes. Ci siamo imbattuti in problemi, li abbiamo affrontati con soluzioni alternative \u2014 ideando delle soluzioni in shell, su qualsiasi cosa. Poi cercavamo di semplificare, generalizzare e consolidare queste soluzioni in binari, che poi condividiamo semplicemente.<\/p>\n

C'\u00e8 anche un altro punto di vista su tutta questa storia, con delle analogie. <\/p>\n

Kubernetes \u00e8 il telaio di un'auto con il motore. Non ci sono porte, vetri, radio, profumi d'albero \u2014 non c'\u00e8 nulla. Solo il telaio e il motore. E c'\u00e8 Helm \u2014 questo \u00e8 il volante. \u00c8 fantastico avere il volante, ma servono anche il perno del volante, la cremagliera, il cambio e le ruote, altrimenti non si pu\u00f2 fare.<\/p><\/blockquote>\n

\nNel caso di werf, si tratta di un ulteriore componente per Kubernetes. Adesso abbiamo in versione alpha werf, dove, per esempio, Helm \u00e8 compilato direttamente all'interno di werf, perch\u00e9 ci siamo stancati di farlo noi stessi. Ci sono molte ragioni per farlo, e ne parler\u00f2 dettagliatamente sul perch\u00e9 abbiamo integrato completamente Helm insieme a Tiller all'interno di werf. alla presentazione su RIT++<\/a><\/noindex>.<\/p>\n

Ora werf \u00e8 un componente molto pi\u00f9 integrato. Otteniamo un timone pronto, un perno di comando: non sono molto esperto di automobili, ma si tratta di un grande blocco che risolve un ampio spettro di problemi. Non dobbiamo pi\u00f9 cercare nel catalogo, abbinare un pezzo all'altro, pensando a come assemblare il tutto. Riceviamo un combinato pronto che affronta subito molteplici sfide. Ma all'interno \u00e8 costituito da tutti gli stessi componenti open source, utilizza ancora Docker per la compilazione, Helm per parte delle funzionalit\u00e0, e ci sono anche altre librerie. \u00c8 uno strumento integrato per ottenere rapidamente e facilmente un eccellente CI\/CD out-of-the-box.<\/p>\n

\u00c8 difficile mantenere Kubernetes?<\/h2>\n

\n\u2014 Parli della tua esperienza con Kubernetes, \u00e8 per voi un telaio, un motore, e su di esso si possono montare molte cose diverse: carrozzeria, volante, pedali, sedili. Sorgono domande: quanto \u00e8 difficile per voi mantenere Kubernetes? Avete una grande esperienza; quanto tempo e risorse dedicate specificamente al mantenimento di Kubernetes, separatamente da tutto il resto?<\/b><\/p>\n

Dmitrij<\/b>: \u00c8 una domanda molto complessa e, per rispondere, bisogna capire cosa si intende per manutenzione e cosa vogliamo da Kubernetes. Potresti chiarire?<\/p>\n

\u2014 Per quanto ne so e come vedo, molte squadre vogliono provare Kubernetes. Tutti si stanno cimentando, installandolo in modo rudimentale. Ho l'impressione che le persone non comprendano sempre la complessit\u00e0 di questo sistema.<\/b><\/p>\n

Dmitrij<\/b>: Esattamente.<\/p>\n

\u2014 Quanto \u00e8 difficile installare Kubernetes da zero affinch\u00e9 sia production ready?<\/b><\/p>\n

Dmitrij<\/b>: Cosa ne pensi, quanto \u00e8 difficile trapiantare un cuore? Capisco che la domanda \u00e8 compromettente. Usare un bisturi senza errori non \u00e8 cos\u00ec difficile. Se ti dicono dove tagliare e dove suturare, l'intera procedura non \u00e8 complessa. La difficolt\u00e0 sta nel garantire ogni volta che tutto funzioni.<\/p>\n

Installare Kubernetes e farlo funzionare \u00e8 semplice: clic! \u2014 \u00e8 installato, ci sono molteplici metodi di installazione. Ma cosa succede quando sorgono problemi?<\/p><\/blockquote>\n

\nSorgono sempre domande \u2014 cosa ci siamo dimenticati? Cosa non abbiamo fatto? Quali parametri del kernel Linux abbiamo impostato in modo errato? Oh cielo, li abbiamo impostati?! Quali componenti di Kubernetes abbiamo installato e quali no? Migliaia di domande si presentano, e per rispondere a queste occorrono 15-20 anni di esperienza nel settore.<\/p>\n

Ho un esempio recente su questo tema che pu\u00f2 rivelare il senso del problema: \"\u00c8 difficile mantenere Kubernetes?\". Tempo fa abbiamo seriamente considerato l'idea di implementare Cilium come rete in Kubernetes.<\/p>\n

Spiegher\u00f2 cosa sia Cilium. In Kubernetes ci sono molteplici implementazioni del sottosistema di rete, e una di esse \u00e8 davvero notevole: \u00e8 Cilium. Qual \u00e8 il suo scopo? Nel kernel, alcuni tempo fa \u00e8 stata introdotta la possibilit\u00e0 di scrivere hook per il kernel, che in vari modi si intrecciano con il sottosistema di rete e altri sottosistemi, consentendo di bypassare grandi porzioni del kernel.<\/p>\n

Nel kernel Linux ci sono storicamente ip rout, netfilter, bridge e molti altri componenti vecchi di 15, 20 o anche 30 anni. In generale funzionano, tutto \u00e8 a posto, ma ora ci sono cos\u00ec tanti contenitori che sembra una torre di 15 mattoni l'uno sopra l'altro, e tu ci stai in equilibrio su una gamba \u2014 \u00e8 una sensazione strana. Questo sistema si \u00e8 sviluppato storicamente con molte sfumature, come un appendice nel corpo. In alcune situazioni ci sono problemi di performance, ad esempio.<\/p>\n

C'\u00e8 un fantastico BPF e la possibilit\u00e0 di scrivere hook per il kernel \u2014 le persone hanno scritto i loro hook per il kernel. Un pacchetto arriva nel kernel Linux, loro lo estraggono direttamente all'ingresso, lo elaborano come necessario senza bridge, senza TCP, senza lo stack IP \u2014 insomma, bypassano tutto ci\u00f2 che \u00e8 scritto nel kernel Linux e lo rilasciano subito nel contenitore.<\/p>\n

Cosa ne \u00e8 venuto fuori? Una performance fantastica, funzioni eccezionali \u2014 semplicemente incredibile! Ma osserviamo questo e vediamo che su ogni macchina c'\u00e8 un programma che si connette all'API Kubernetes e, in base ai dati ricevuti da questa API, genera codice C e compila i binari che vengono caricati nel kernel, affinch\u00e9 questi hook funzionino nello spazio del kernel.<\/p>\n

Cosa succede se qualcosa va storto? Non lo sappiamo. Per capirlo, bisogna leggere tutto questo codice, capire tutta la logica, e non \u00e8 affatto facile. D'altra parte, ci sono questi bridge, net-filter, ip rout \u2014 io non ho letto il loro codice sorgente, e nemmeno i 40 ingegneri che lavorano nella nostra azienda. Forse solo alcune persone ne comprendono alcuni pezzi.<\/p>\n

E che differenza fa? Ci sono ip rout, il kernel Linux, e c'\u00e8 un nuovo strumento \u2014 che importa, non comprendiamo l'uno n\u00e9 l'altro. Ma abbiamo paura di usare il nuovo \u2014 perch\u00e9? Perch\u00e9 se uno strumento ha 30 anni, in 30 anni tutti i bug sono stati trovati, si sono incontrati tutti gli ostacoli e sapere tutto non \u00e8 necessario \u2014 funziona come una scatola nera, e funziona sempre. Tutti sanno quale cacciavite diagnostico infilare in quale posto, quale tcpdump avviare in quale momento. Tutti conoscono bene gli strumenti diagnostici e comprendono come questo insieme di componenti funzioni nel kernel Linux \u2014 non come \u00e8 fatto, ma come utilizzarlo.<\/p>\n

Cilium non ha 30 anni, non \u00e8 ancora maturo. Lo stesso problema esiste con Kubernetes: entrambi si installano bene, ma quando qualcosa va storto in produzione, sarete in grado di comprendere rapidamente cosa sia andato storto in una situazione critica? <\/p>\n

Quando si parla di quanto sia difficile mantenere Kubernetes, la risposta \u00e8 sia semplice che incredibilmente complessa. Kubernetes funziona perfettamente da solo, ma ci sono miliardi di dettagli da considerare.<\/p><\/blockquote>\n

<\/p>\n

Sull'approccio del 'Tanto vale tentare'<\/h2>\n

\n\u2014 Ci sono aziende dove questi dettagli appariranno quasi sicuramente? Immaginiamo che Yandex decida di migrare tutti i servizi su Kubernetes; l\u00ec ci sar\u00e0 un carico incredibile.<\/b><\/p>\n

Dmitrij<\/b>: No, non si tratta di carichi, ma di cose semplici. Ad esempio, supponiamo di avere Kubernetes, e abbiamo deploato un'applicazione. Come possiamo sapere se sta funzionando? Non esiste uno strumento pronto per capire se l'applicazione non va in crash. Non c'\u00e8 un sistema pronto che invii avvisi: bisogna configurare questi avvisi e ogni grafico. E noi stiamo aggiornando Kubernetes.<\/p>\n

C'\u00e8 Ubuntu 16.04. Si potrebbe dire che sia una versione obsoleta, ma noi siamo ancora su di essa, perch\u00e9 \u00e8 LTS. \u00c8 presente systemd, il cui dettaglio \u00e8 che non pulisce i C-group. Kubernetes avvia i pod, crea i C-group, poi elimina i pod, e in qualche modo \u2014 non ricordo i dettagli, scusate \u2014 rimangono degli slice di systemd. Questo porta al fatto che, nel tempo, qualsiasi macchina inizia a rallentare considerevolmente. Non si tratta nemmeno di highload. Se ci sono pod in esecuzione costante, ad esempio, se c'\u00e8 un Cron Job che genera continuamente pod, la macchina con Ubuntu 16.04 inizier\u00e0 a rallentare dopo una settimana. Ci sar\u00e0 sempre un alto load average a causa della creazione di un sacco di C-group. Questo \u00e8 un problema con cui si imbatte chiunque installi semplicemente Ubuntu 16 e poi Kubernetes sopra.<\/p>\n

Immagina che in qualche modo aggiorni systemd o qualcos'altro, ma nel kernel Linux fino alla versione 4.16 \u00e8 ancora pi\u00f9 divertente: quando si rimuovono i C-group, continuano a persistere nel kernel e, di fatto, non vengono eliminati. Quindi, dopo un mese di utilizzo di questa macchina, diventa impossibile controllare le statistiche sulla memoria delle pod. Prendiamo un file, lo eseguiamo nel programma, e un file ci impiega 15 secondi, perch\u00e9 il kernel impiega molto tempo a contare internamente un milione di C-group che sembrano essere stati rimossi, ma non lo sono: continuano a persistere.<\/p>\n

Ci sono ancora molte piccole cose qui e l\u00e0. Non si tratta di un problema che le aziende giganti possono talvolta affrontare sotto carichi enormi: no, \u00e8 una questione di cose quotidiane. Le persone possono vivere cos\u00ec per mesi: hanno installato Kubernetes, implementato un'applicazione: sembra funzionare. A molti va bene cos\u00ec. Su quando mai quell'applicazione possa cadere, non lo sapranno nemmeno, l'allerta non arriver\u00e0, ma per loro \u00e8 normale. Prima vivevano su macchine virtuali senza monitoraggio, ora sono passati a Kubernetes, sempre senza monitoraggio: quale differenza?<\/p>\n

La questione \u00e8 che quando camminiamo sul ghiaccio, non sappiamo mai la sua spessore se non lo abbiamo misurato in anticipo. Molti camminano senza preoccuparsene, perch\u00e9 in passato l'hanno fatto.<\/p>\n

Dal mio punto di vista, il dettaglio e la complessit\u00e0 nell'utilizzo di qualsiasi sistema risiedono nel garantire che lo spessore del ghiaccio sia sufficiente per risolvere i nostri compiti. Questo \u00e8 il punto.<\/p><\/blockquote>\n

\nNell'IT, mi sembra che ci siano troppi approcci basati su \u2018spero di avere fortuna\u2019. Molti installano software, utilizzano librerie software nella speranza di avere successo. In generale, a molti va bene. Probabilmente \u00e8 per questo che funziona.<\/p>\n

\u2014 Dalla mia valutazione pessimistica, sembra cos\u00ec: quando i rischi sono elevati e l'applicazione deve funzionare, \u00e8 necessaria assistenza da 'Flant', forse da Red Hat, oppure \u00e8 richiesta una propria squadra interna dedicata a Kubernetes, pronta a supportarlo.<\/b><\/p>\n

Dmitrij<\/b>: Oggettivamente \u00e8 cos\u00ec. Entrare autonomamente nel mondo di Kubernetes per un piccolo team comporta un certo numero di rischi.<\/p>\n

Abbiamo bisogno di contenitori?<\/h2>\n

\n\u2014 Puoi dirmi quanto \u00e8 diffuso Kubernetes in Russia?<\/b><\/p>\n

Dmitrij<\/b>: Non ho questi dati e non sono sicuro che esista qualcuno che li abbia. Diciamo: 'Kubernetes, Kubernetes', ma ci sono anche altre opinioni su questo tema. Non so nemmeno quanto siano diffusi i container, ma so che secondo i rapporti online, il 70% dei container \u00e8 orchestrato da Kubernetes. Questa era una fonte affidabile su un campione piuttosto ampio a livello mondiale.<\/p>\n

Poi c'\u00e8 un'altra domanda: abbiamo bisogno dei container?<\/b> Ho la sensazione personale e, in generale, la posizione della 'Flant' \u00e8 che Kubernetes sia lo standard di fatto.<\/p>\n

Non ci sar\u00e0 nulla oltre a Kubernetes.<\/p><\/blockquote>\n

\n\u00c8 un assoluto game-changer nel campo della gestione dell'infrastruttura. Assolutamente \u2014 niente pi\u00f9 Ansible, Chef, macchine virtuali, Terraform. E non parlo nemmeno dei vecchi metodi superati. Kubernetes \u00e8 un vero e proprio cambio di paradigma<\/b>, e d'ora in poi sar\u00e0 solo cos\u00ec.<\/p>\n

\u00c8 chiaro che ci vorranno un paio d'anni per alcuni, o addirittura decenni per altri, per rendersi conto di questo. Non ho dubbi che non ci sar\u00e0 niente oltre a Kubernetes e a questa nuova visione: non colpiremo pi\u00f9 il sistema operativo, ma useremo infrastructure as code<\/b>, solo che non con codice, ma con yml \u2014 un'infrastruttura descritta in modo dichiarativo. Ho la sensazione che sar\u00e0 sempre cos\u00ec.<\/p>\n

\u2014 Cio\u00e8, quelle aziende che non sono ancora migrate a Kubernetes, lo faranno sicuramente o scompariranno. Ho capito bene?<\/b><\/p>\n

Dmitrij<\/b>: Questo non \u00e8 del tutto corretto. Ad esempio, se abbiamo il compito di avviare un server DNS, possiamo farlo su FreeBSD 4.10 e funzioner\u00e0 bene per 20 anni. Solo per funzionare e basta. Forse, dopo 20 anni, sar\u00e0 necessario aggiornare qualcosa una sola volta. Se parliamo di software che abbiamo avviato e che funziona davvero per molti anni senza aggiornamenti, senza modifiche, certamente l\u00ec non ci sar\u00e0 Kubernetes. Non \u00e8 necessario.<\/p>\n

Tutto ci\u00f2 che riguarda CI\/CD \u2014 ovunque ci sia bisogno di Continuous Delivery, dove \u00e8 necessario aggiornare le versioni, apportare modifiche attive, ovunque sia necessario costruire un'architettura a prova di guasto \u2014 solo Kubernetes.<\/p><\/blockquote>\n

<\/p>\n

Su microservizi<\/h2>\n

\n\u2014 Qui ho un piccolo dissonanza. Per lavorare con Kubernetes \u00e8 necessaria un supporto esterno o interno \u2014 questo \u00e8 il primo punto. Il secondo \u00e8 che, quando iniziamo a sviluppare, siamo una piccola startup e non abbiamo nulla; lo sviluppo su Kubernetes o in generale su architetture microservizi pu\u00f2 essere difficile e non sempre giustificato economicamente. Sono curioso del tuo punto di vista \u2014 devono le startup partire subito scrivendo per Kubernetes, o possono prima realizzare un monolite e poi eventualmente passare a Kubernetes?<\/b><\/p>\n

Dmitrij<\/b>: Ottima domanda. Ho una presentazione sui microservizi. \u00abI microservizi: la dimensione conta\u00bb.<\/a><\/noindex> Mi \u00e8 capitato molte volte di vedere persone che cercano di piantare chiodi con il microscopio. Il metodo da solo \u00e8 corretto, stiamo progettando il nostro software interno proprio in questo modo. Ma quando lo si fa, \u00e8 importante avere chiaro cosa si sta facendo. Ci\u00f2 che odio di pi\u00f9 nei microservizi \u00e8 la parola \u00abmicro\u00bb. Storicamente, \u00e8 nato questo termine e per qualche motivo le persone pensano che micro significhi molto piccolo, meno di un millimetro, come un micrometro. Non \u00e8 cos\u00ec.<\/p>\n

Ad esempio, c'\u00e8 un monolite scritto da 300 persone, e tutti coloro che hanno partecipato allo sviluppo sanno che ci sono dei problemi, e che bisognerebbe suddividerlo in micro-pezzetti \u2014 circa 10, ognuno dei quali viene scritto da un minimo di 30 persone. Questo \u00e8 importante, necessario e fantastico. Ma quando ci arriva una startup con 3 ragazzi molto bravi e talentuosi che hanno scritto in fretta 60 microservizi, ogni volta cerco un rimedio.<\/p>\n

Mi sembra che di questo se ne sia gi\u00e0 parlato migliaia di volte \u2014 abbiamo ottenuto un monolite distribuito in una forma o nell'altra. Questo non \u00e8 economicamente sostenibile, \u00e8 molto complicato in generale. Semplicemente, l'ho visto cos\u00ec tante volte che mi fa male, quindi continuo a parlarne.<\/p>\n

Ritornando alla domanda iniziale, c'\u00e8 un conflitto tra il fatto che, da un lato, Kubernetes \u00e8 spaventosamente complicato da usare, perch\u00e9 non \u00e8 chiaro cosa si possa rompere o non funzionare, e dall'altro lato, \u00e8 chiaro che tutto sta andando in quella direzione e non ci sar\u00e0 altro che Kubernetes. La risposta \u00e8 valutare il volume di benefici che arrivano, e il volume di compiti che puoi risolvere.<\/b>. Questo \u00e8 da un lato della bilancia. Dall'altro lato ci sono i rischi associati a tempi di inattivit\u00e0 o a un aumento dei tempi di risposta e del livello di disponibilit\u00e0, che portano a una riduzione delle prestazioni.<\/p>\n

La questione \u00e8 questa: dobbiamo muoverci rapidamente, e Kubernetes consente di fare molte cose molto pi\u00f9 velocemente e meglio, oppure dobbiamo utilizzare soluzioni consolidate e affidabili, ma ci muoveremo molto pi\u00f9 lentamente. Ogni azienda deve prendere questa decisione. Si pu\u00f2 considerare come un sentiero nella giungla: la prima volta che ci si avventura, si pu\u00f2 incontrare un serpente, una tigre o un tasso arrabbiato, ma dopo averlo fatto dieci volte, si crea un percorso, si rimuovono i rami e si cammina pi\u00f9 facilmente. Ogni volta il sentiero diventa pi\u00f9 ampio. Poi diventa una strada asfaltata e infine un bel boulevard.<\/p>\n

Kubernetes non si ferma mai. Tornando alla domanda: da un lato, Kubernetes \u00e8 composto da 4-5 binari, dall'altro \u00e8 tutta un'ecosistema. \u00c8 un sistema operativo che installiamo sulle macchine. Che cosa \u00e8? Ubuntu o Curios? \u00c8 il kernel Linux, una serie di componenti aggiuntivi. Tutte queste cose hanno gettato una vipera velenosa dalla strada, hanno messo una recinzione l\u00ec. Kubernetes si sta evolvendo rapidamente e dinamicamente, e il volume dei rischi, l'ignoto, diminuisce ogni mese e, di conseguenza, questi equilibri si riequilibrano.<\/p>\n

Rispondendo alla domanda su cosa dovrebbe fare una startup, direi: venite a \u00abFlant\u00bb, pagate 150.000 rubli e riceverete un servizio DevOps chiavi in mano. Se siete una piccola startup con alcuni sviluppatori, questo funziona. Anzich\u00e9 assumere un vostro DevOps, che dovr\u00e0 imparare a risolvere i vostri problemi e nel frattempo essere pagato, otterrete una soluzione completa per tutte le vostre esigenze. Certo, ci sono alcuni svantaggi. Come outsourcer, non possiamo essere cos\u00ec coinvolti e reagire rapidamente ai cambiamenti. Tuttavia, abbiamo un'enorme esperienza e pratiche consolidate. Garantiamo che in qualsiasi situazione saremo in grado di comprendere rapidamente e sollevare qualsiasi Kubernetes da quella situazione. <\/p>\n

Raccomando categoricamente l'outsourcing per startup e aziende consolidate fino a quando non si pu\u00f2 assegnare un team di 10 persone per le operazioni, perch\u00e9 altrimenti non ha senso. Ha assolutamente senso farlo in outsourcing.<\/p><\/blockquote>\n

<\/p>\n

Su Amazon e Google<\/h2>\n

\n\u2014 \u00c8 possibile considerare come outsourcing l'hosting offerto da Amazon o Google?<\/b><\/p>\n

Dmitrij<\/b>: S\u00ec, certo, questo risolve alcune questioni. Ma ci sono sempre dei dettagli. \u00c8 comunque necessario comprendere come utilizzarlo. Ad esempio, ci sono mille piccole cose nel lavoro con Amazon AWS: \u00e8 necessario riscaldare il Load Balancer o inviare in anticipo una richiesta, dicendo 'ragazzi, ci arriver\u00e0 del traffico, riscaldateci il Load Balancer!' Questi dettagli devono essere conosciuti.<\/p>\n

Quando ti rivolgi a persone specializzate in questo campo, ottieni quasi tutte le questioni standard gi\u00e0 risolte. Abbiamo attualmente 40 ingegneri e probabilmente ne avremo 60 entro fine anno \u2013 ci siamo sicuramente gi\u00e0 confrontati con tutte queste problematiche. Anche se in un progetto ci troviamo nuovamente di fronte a questo problema, chiediamo velocemente all'uno o all'altro e sappiamo come risolverlo.<\/p>\n

Probabilmente, la risposta \u00e8 questa: certo, la storia dell'hosting facilita in qualche modo. La domanda \u00e8 se sei pronto a fidarti di questi host e se risolveranno i tuoi problemi. Amazon e Google hanno dimostrato di essere affidabili. Per tutti i nostri casi, certamente. Non abbiamo altre esperienze positive. Tutti gli altri servizi cloud con cui abbiamo provato a lavorare creano moltissimi problemi: Ager, e tutto ci\u00f2 che esiste in Russia, cos\u00ec come diversi OpenStack in varie implementazioni: Headster, Overage \u2014 tutto ci\u00f2 che vuoi. Creano tutti problemi che preferiremmo non affrontare.<\/p>\n

Quindi, la risposta \u00e8 s\u00ec, ma in realt\u00e0, le soluzioni hosted mature non sono molte.<\/p>\n

A chi serve Kubernetes?<\/h2>\n

\n\u2014 Eppure, a chi serve Kubernetes? Chi dovrebbe gi\u00e0 passare a Kubernetes, chi \u00e8 il tipico cliente di 'Flant' che si presenta esattamente per Kubernetes?<\/b><\/p>\n

Dmitrij<\/b>: La domanda \u00e8 interessante perch\u00e9 ora, con la crescente popolarit\u00e0 di Kubernetes, molte persone ci contattano dicendo: \u00abRagazzi, sappiamo che lavorate con Kubernetes, fatecelo!\u00bb. Noi rispondiamo: \u00abSignori, noi non realizziamo Kubernetes, noi costruiamo produzione e tutto ci\u00f2 che comporta\u00bb. Perch\u00e9 realizzare una produzione senza impostare tutto il CI\/CD e tutta questa storia \u00e8 semplicemente impossibile al giorno d'oggi. Tutti hanno abbandonato la divisione tra sviluppo e operativit\u00e0.<\/p>\n

I nostri clienti hanno aspettative diverse, ma tutti sperano in una sorta di meraviglia, che possano avere determinati problemi e poi, puff! \u2014 Kubernetes li risolver\u00e0. La gente crede nei miracoli. Razionalmente capiscono che non ci sar\u00e0 alcun miracolo, ma dentro di s\u00e9 sperano \u2014 e se questo Kubernetes risolvesse tutto, visto che se ne parla tanto! Magari adesso \u00e8 la chiave magica, puff! \u2014 e abbiamo il 100% di uptime, tutti gli sviluppatori possono rilasciare qualsiasi cosa in produzione 50 volte e non crolla. Insomma, un miracolo!<\/p>\n

Quando persone di questo tipo vengono da noi, diciamo: \u00abMi dispiace, ma non ci sono miracoli\u00bb. Per essere sani, \u00e8 necessario mangiare bene e fare sport. Per avere un server affidabile, deve essere realizzato con cura. Per avere un CI\/CD comodo, deve essere progettato in modo adeguato. Si tratta di un lavoro impegnativo che deve essere svolto.<\/p>\n

Rispondendo alla domanda su chi ha bisogno di Kubernetes \u2013 Kubernetes non \u00e8 necessario per nessuno.<\/p><\/blockquote>\n

\nAlcune persone hanno una percezione errata di aver bisogno di Kubernetes. Le persone desiderano, sentono un bisogno profondo di smettere di pensare, occuparsi e interessarsi a tutti i problemi infrastrutturali e al lancio delle loro applicazioni. Vogliono che le applicazioni funzionino semplicemente e vengano distribuite. Per loro, Kubernetes \u00e8 la speranza di non dover pi\u00f9 sentire la storia di \u00abci siamo arenati\u00bb o \u00abnon possiamo andare in produzione\u00bb, o altro.<\/p>\n

Di solito ci contatta il CTO. Da lui si chiedono due cose: da un lato, nuove funzionalit\u00e0, dall'altro, stabilit\u00e0. Noi proponiamo di prenderci carico di questo e realizzarlo. La soluzione ideale \u00e8 che tu smetta di pensare a questi problemi e di perdere tempo. Avrai persone dedicate che si occuperanno di questo.<\/p>\n

L'affermazione che a noi o a qualcun altro serva Kubernetes \u00e8 sbagliata.<\/p><\/blockquote>\n

\nKubernetes \u00e8 molto importante per gli amministratori, perch\u00e9 \u00e8 un giocattolo davvero interessante, con cui si pu\u00f2 sperimentare. Siamo onesti: a tutti piacciono i giochi. Siamo tutti un po' bambini, e quando vediamo una novit\u00e0 vogliamo provarla. Alcuni ne hanno perso il fascino, ad esempio nel lavoro di amministrazione, perch\u00e9 ci si \u00e8 gi\u00e0 divertiti e si \u00e8 stanchi. Ma nessuno l'ha completamente abbandonato. Anche se per me i giochi in ambito sistemistico e DevOps hanno perso il loro fascino da un po', continuo comunque ad amare i giocattoli ed acquisto sempre qualcosa di nuovo. Tutti, in un modo o nell'altro, vogliono sempre dei nuovi giochi.<\/p>\n

Non dovresti giocare con la produzione. Cosa non raccomando categoricamente di fare e cosa vedo ora in massa: \"Oh, un nuovo giocattolo!\" \u2014 si corre a comprarlo, si compra e: \"Portiamolo a scuola ora, mostriamolo a tutti gli amici\". Non fatelo. Mi scuso, ma ho solo bambini che crescono, vedo costantemente qualcosa in loro, lo noto in me stesso e poi generalizzo agli altri.<\/p>\n

Risposta definitiva: non hai bisogno di Kubernetes. Devi risolvere i tuoi problemi.<\/p><\/blockquote>\n

\nPuoi ottenere che:<\/p>\n