{"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 previsione di DevOpsConf<\/a><\/noindex> Vitaliy Khabarov<\/b> ha intervistato\u00a0Dmitrij Stolyarov<\/b> (distol<\/a><\/noindex>), direttore tecnico e co-fondatore dell'azienda \u00abFlant\u00bb. Vitaliy ha chiesto a Dmitrij cosa fa \u00abFlant\u00bb, di Kubernetes, dello sviluppo dell'ecosistema e del supporto. Hanno discusso del perch\u00e9 Kubernetes sia utile e se serva davvero. Inoltre, hanno parlato di microservizi, Amazon AWS, dell'approccio \u00abMi sentir\u00f2 fortunato\u00bb nel DevOps, del futuro di Kubernetes, perch\u00e9, quando e come conquister\u00e0 il mondo, delle prospettive del DevOps e di cosa si devono preparare gli ingegneri nel prossimo e luminoso futuro con semplificazioni e reti neurali.<\/p>\n

L'intervista originale<\/a><\/noindex> in formato podcast pu\u00f2 essere ascoltata su DevOps DeFlop \u2014 il podcast in lingua russa su DevOps, e qui sotto trovate la versione testuale. <\/p>\n

\"Kubernetes
\n
\nQui e di seguito le domande sono poste da Vitaliy Khabarov<\/a><\/noindex> un ingegnere di Express42.
\n<\/a><\/noindex><\/p>\n

Su \u00abFlant\u00bb<\/h2>\n

\n\u2014 Dima, ciao. Tu sei il direttore tecnico di \u00abFlant<\/a><\/noindex>\u00bb e anche il suo fondatore. Raccontaci, per favore, cosa fa l'azienda e tu in essa?<\/b><\/p>\n

\"KubernetesDmitrij<\/b>: Dall'esterno sembra che siamo quei ragazzi che vanno in giro a installare Kubernetes e a fare qualcosa con esso. Ma non \u00e8 cos\u00ec. Siamo partiti come azienda che si occupava di Linux, ma da molto tempo la nostra attivit\u00e0 principale consiste nell'assistenza a progetti di produzione e highload chiavi in mano. Di solito costruiamo tutta l'infrastruttura da zero e poi per molto tempo ce ne assumiamo la responsabilit\u00e0. Pertanto, il lavoro principale che fa \u00abFlant\u00bb, per cui viene pagato, \u00e8 prendersi la responsabilit\u00e0 e realizzare la produzione chiavi in mano<\/b>.
\n

\n

\nIo, come direttore tecnico e uno dei fondatori dell'azienda, lavoro giorno e notte per inventare come aumentare la disponibilit\u00e0 della produzione, semplificare la sua gestione, rendere la vita degli amministratori pi\u00f9 facile e quella dei programmatori pi\u00f9 piacevole.<\/p>\n

Su Kubernetes<\/h2>\n

\n\u2014 Ultimamente da \u00abFlant\u00bb vedo molte relazioni e\u00a0articoli<\/a><\/noindex> sul Kubernetes. Come ci siete arrivati?<\/b><\/p>\n

Dmitrij<\/b>: Ne ho gi\u00e0 parlato molte volte, ma non mi dispiace ripeterlo. Penso che sia giusto ripetere quest'argomento, perch\u00e9 c'\u00e8 confusione tra causa ed effetto.<\/p>\n

Avevamo davvero bisogno di uno strumento. Ci siamo imbattuti in una miriade di problemi, abbiamo lottato, superato le difficolt\u00e0 con vari espedienti e sentivamo la necessit\u00e0 di uno strumento. Abbiamo esplorato molte opzioni diverse, costruito le nostre soluzioni, accumulato esperienza. Gradualmente siamo arrivati al punto di iniziare a utilizzare Docker quasi subito dopo la sua apparizione, intorno al 2013. Al momento del suo arrivo, avevamo gi\u00e0 una significativa esperienza con i container, avevamo gi\u00e0 scritto un nostro equivalente di \"Docker\" \u2014 alcuni espedienti in Python. Con l'arrivo di Docker, \u00e8 diventata possibile eliminare gli espedienti ed utilizzare una soluzione affidabile e supportata dalla comunit\u00e0.<\/p>\n

La storia con Kubernetes \u00e8 simile. Quando ha iniziato a guadagnare terreno \u2014 per noi \u00e8 la versione 1.2 \u2014 avevamo gi\u00e0 una moltitudine di espedienti sia in Shell che in Chef, con i quali tentavamo di orchestrare Docker. Abbiamo preso in considerazione seriamente Rancher e diverse altre soluzioni, ma poi \u00e8 arrivato Kubernetes, che \u00e8 realizzato esattamente come lo avremmo fatto noi, o addirittura meglio. Non c'era nulla di cui lamentarsi.<\/p>\n

S\u00ec, qui ci sono alcune imperfezioni, ce ne sono molte, e la 1.2 \u00e8 davvero spaventosa, ma... Kubernetes \u00e8 come un edificio in costruzione: osservi il progetto e capisci che sar\u00e0 fantastico. Se l'edificio ha gi\u00e0 una base e due piani, capisci che \u00e8 meglio non trasferirsi ancora, mentre con il software non ci sono problemi del genere: puoi gi\u00e0 utilizzarlo.<\/p>\n

Non abbiamo mai avuto un momento in cui ci siamo chiesti se utilizzare Kubernetes o meno. Lo aspettavamo da molto prima che apparisse e tentavamo di costruire analoghi.<\/p><\/blockquote>\n

<\/p>\n

Circa Kubernetes<\/h2>\n

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

Dmitrij<\/b>: In modo indiretto. Partecipiamo piuttosto allo sviluppo dell'ecosistema. Inviamo un certo numero di pull requests: in Prometheus, in vari operatori, in Helm \u2014 nell'ecosistema. Sfortunatamente, non sono in grado di tenere traccia di tutto ci\u00f2 che facciamo e potrei commettere errori, ma non abbiamo alcuna pull request in 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 esiste gi\u00e0. Se le pull request non vengono accettate, semplicemente le fork e viviamo finch\u00e9 non vengono accettate con i nostri build. Poi, quando questo arriva all'upstream, torniamo indietro alla versione upstream.<\/p>\n

Ad esempio, abbiamo un operatore Prometheus con cui abbiamo fatto su e gi\u00f9 rispetto all'upstream della nostra build gi\u00e0 5 volte, probabilmente. Abbiamo bisogno di una funzionalit\u00e0, abbiamo inviato una pull request, dobbiamo rilasciarla domani, e non vogliamo aspettare che venga rilasciata nell'upstream. Pertanto, ci creiamo la nostra build con la funzionalit\u00e0 di cui abbiamo bisogno e la distribuiamo a tutti i nostri cluster. Poi, ad esempio, nell'upstream ci dicono: \"Ragazzi, facciamo in modo che funzioni per un caso pi\u00f9 generale\", e noi, o qualcun altro, lo completiamo, e col tempo viene di nuovo unito.<\/p>\n

Cercando di sviluppare tutto ci\u00f2 che esiste<\/b>. Molti elementi che non esistono ancora, che non sono stati ancora inventati o che sono stati inventati ma non sono stati realizzati, li stiamo facendo. 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. Spesso ci chiedono perch\u00e9 abbiamo creato quella o quell'altra cosa? La risposta \u00e8 semplice: perch\u00e9 avevamo bisogno di andare avanti, di risolvere qualche problema pratico, e abbiamo risolto quel problema con questo strumento.<\/p>\n

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

<\/p>\n

Strumenti di Flant<\/h2>\n

\n\u2014 So che attualmente Flant ha operatori add-on, operatori shell e strumenti dapp\/werf. Da quanto capisco, si tratta dello stesso strumento in incarnazioni diverse. Inoltre, capisco che all'interno di Flant ci sono molti altri strumenti diversi. \u00c8 cos\u00ec?<\/b><\/p>\n

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

Molti strumenti! E ce ne saranno ancora di pi\u00f9, poich\u00e9 un certo numero di soluzioni interne sar\u00e0 rilasciato quest'anno. Tra i grandi, ci sono molti addon per Kubernetes, come ad esempio come installare correttamente il sert manager \u2013 uno strumento per la gestione dei certificati, o come installare Prometheus con un sacco di accessori \u2013 si tratta di circa venti binari diversi che esportano dati e raccolgono informazioni. A questo si aggiungono grafica e avvisi straordinari di Prometheus. Tutti questi sono semplicemente moltissimi addon per Kubernetes, che vengono installati nel cluster, trasformandolo da semplice a avanzato, automatizzato, in cui molte questioni sono gi\u00e0 risolte. S\u00ec, facciamo davvero molto.<\/p>\n

Sviluppo dell'ecosistema<\/h2>\n

\n\u2014 Mi sembra che questo sia un contributo molto significativo allo sviluppo di questo strumento e alle sue modalit\u00e0 di utilizzo. Puoi provare a stimare chi potrebbe contribuire in modo simile allo sviluppo dell'ecosistema?<\/b><\/p>\n

Dmitrij<\/b>: In Russia, tra le aziende che operano nel nostro mercato, non c'\u00e8 nessuno anche lontanamente<\/b>. Certo, \u00e8 un'affermazione audace, perch\u00e9 ci sono grandi attori come Mail e Yandex che stanno facendo qualcosa con Kubernetes, ma anche loro non si avvicinano al contributo delle aziende a livello mondiale, che stanno facendo molto di pi\u00f9 di noi. \u00c8 difficile confrontare \"Flant\" con uno staff di 80 persone e Red Hat, che ha solo per Kubernetes 300 ingegneri, se non sbaglio. \u00c8 difficile fare un confronto. Nel nostro dipartimento RnD ci sono 6 persone, me compreso, che sviluppano tutti i nostri strumenti. 6 persone contro 300 ingegneri di Red Hat \u2013 non \u00e8 semplice fare un paragone.<\/p>\n

\u2014 Tuttavia, quando anche solo questi 6 possono creare qualcosa di realmente utile e trasferibile, quando affrontano un problema pratico e forniscono una soluzione alla comunit\u00e0 \u2013 \u00e8 un caso interessante. Capisco che nelle grandi aziende tecnologiche, dove ci sono sviluppatori e team di supporto per Kubernetes, potrebbero in linea di principio essere sviluppati strumenti simili. Questo \u00e8 un esempio per loro di ci\u00f2 che \u00e8 possibile sviluppare e condividere con la comunit\u00e0, dando impulso a tutta la comunit\u00e0 che utilizza Kubernetes.<\/b><\/p>\n

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

Capisco tutto riguardo al titolo di DevOps engineer, tutti lo capiscono e si sono abituati a chiamare DevOps engineer DevOps engineer, non discuteremo di questo. Questi 40 straordinari ingegneri DevOps affrontano problemi ogni giorno e li risolvono, noi analizziamo semplicemente questa esperienza e cerchiamo di generalizzare. Comprendiamo che se questa conoscenza rimane al nostro interno, dopo un anno o due lo strumento diventa inutile, perch\u00e9 da qualche parte nella community apparir\u00e0 uno strumento pronto. Non ha senso accumulare questa esperienza all'interno\u2014\u00e8 solo uno spreco di energia e tempo in dev\/null. Cos\u00ec, non ci dispiace affatto. Pubblicizziamo tutto con grande piacere e capiamo che \u00e8 necessario pubblicare, sviluppare, promuovere, far girare affinch\u00e9 la gente lo utilizzi e aggiunga le proprie esperienze\u2014cos\u00ec tutto cresce e vive. Allora, dopo due anni, lo strumento non finisce nella spazzatura. Non ci dispiace continuare a investire energie, perch\u00e9 \u00e8 evidente che qualcuno utilizza 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 realizzarlo, sembra circa 3 anni fa. Inizialmente era completamente in shell. Era un super proof of concept, abbiamo risolto alcune delle nostre specifiche problematiche\u2014e ci siamo riusciti! Ma con lo shell ci sono dei problemi, non \u00e8 possibile svilupparlo ulteriormente, programmare in shell \u00e8 un'occupazione piuttosto complicata. Avevamo l'abitudine di scrivere in Ruby e quindi abbiamo rifatto alcune cose in Ruby, sviluppato, sviluppato, sviluppato, e ci siamo scontrati con il fatto che la community, il gruppo che non dice Lo strumento DevOps deve essere un binario statico<\/b>. Su Go o non su Go non \u00e8 cos\u00ec importante, ma \u00e8 meglio un binario statico scritto in Go.<\/p>\n

Abbiamo investito risorse, riscritto il dapp in Go e lo abbiamo chiamato werf. Il dapp non \u00e8 pi\u00f9 supportato, non \u00e8 in sviluppo, funziona con una sorta di ultima versione, ma c'\u00e8 un assoluto percorso di upgrade, e si pu\u00f2 seguirlo.<\/p>\n

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

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

Dmitrij<\/b>: La prima ragione riguarda il processo di build. Inizialmente avevamo seri problemi con la build, quando Docker non supportava il multi-stage, e abbiamo realizzato il multi-stage da soli. Poi avevamo anche molte domande sulla pulizia delle immagini. Tutti coloro che fanno CI\/CD, prima o poi, si imbattono nel problema di avere un sacco di immagini create, \u00e8 necessario trovare un modo per pulire ci\u00f2 che non serve e mantenere ci\u00f2 che serve.<\/p>\n

La seconda ragione riguarda il deploy. S\u00ec, esiste Helm, ma risolve solo parte dei problemi. \u00c8 strano, ma c'\u00e8 scritto che \"Helm \u00e8 il Package Manager per Kubernetes\". Esattamente, \"il\". Ci sono anche le parole \"Package Manager\" \u2014 quali aspettative abbiamo di solito da un Package Manager? Diciamo: \"Package Manager, installa il pacchetto!\" e ci aspettiamo che ci dica: \"Pacchetto installato\". <\/p>\n

\u00c8 interessante che diciamo: \"Helm, installa il pacchetto\", e quando risponde che l'ha installato, scopriamo che ha solo avviato l'installazione \u2014 ha indicato a Kubernetes: \"Avvia questa cosa!\", ma se \u00e8 stata avviata o meno, se funziona o meno, Helm non risolve affatto questa questione.<\/p>\n

Dunque, Helm \u00e8 semplicemente un preprocessore testuale che carica dati in Kubernetes.<\/p><\/blockquote>\n

\nMa noi, nel contesto di qualsiasi deploy, vogliamo sapere \u2014 l'applicazione \u00e8 stata distribuita in produzione o no? Essere distribuita in produzione significa che l'applicazione \u00e8 stata lanciata, \u00e8 stata distribuita una nuova versione e che almeno non sta crollando e risponde correttamente. Helm non risolve affatto questo problema. Per affrontarlo, bisogna spendere molte energie, poich\u00e9 \u00e8 necessario dare a Kubernetes il comando di distribuire e monitorare cosa succede \u2014 se \u00e8 stata distribuita o meno. E ci sono anche molti altri compiti legati al deploy, alla pulizia, alla costruzione.<\/p>\n

Piani<\/h2>\n

\nAnche quest'anno ci dedicheremo allo sviluppo locale. Vogliamo arrivare a uno stato simile a quello di Vagrant: digitando \"vagrant up\", le nostre macchine virtuali si avviano. Vogliamo che, con un progetto su Git, sia sufficiente scrivere \"werf up\" per avviare una copia locale di questo progetto, distribuita in un mini-Kub locale, con tutte le directory collegate, pronte per lo sviluppo. A seconda del linguaggio di sviluppo, ci\u00f2 pu\u00f2 essere realizzato in modi diversi, ma \u00e8 importante poter condurre lo sviluppo locale in modo conveniente sotto file montati.<\/p>\n

Il prossimo passo per noi \u00e8 investire molto nel comfort per gli sviluppatori<\/b>. Per poter lanciare rapidamente un progetto localmente con uno strumento, svilupparlo, effettuare il push su Git e farlo uscire esattamente allo stesso modo in stage o per il testing, a seconda dei pipeline, e poi utilizzare lo stesso strumento per andare in produzione. Questa unit\u00e0, unificazione e riproducibilit\u00e0 dell'infrastruttura, dal ambiente locale fino alla produzione, per noi \u00e8 un aspetto molto importante. Ma finora non \u00e8 disponibile in werf; stiamo solo pianificando di farlo.<\/p>\n

Ma il percorso verso dapp\/werf \u00e8 sempre stato simile a quello di Kubernetes all'inizio. Abbiamo affrontato problemi e li abbiamo risolti con soluzioni alternative, inventando qualcosa per noi stessi su shell o su qualsiasi cosa. Poi, abbiamo cercato di rettificare, generalizzare e consolidare questi metodi in binari, che 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, albero di Natale \u2014 non c'\u00e8 proprio nulla. Solo il telaio e il motore. E c'\u00e8 Helm: \u00e8 il volante. \u00c8 fantastico avere il volante, ma servono anche il perno dello sterzo, la cremagliera, il cambio e le ruote, altrimenti non si va da nessuna parte.<\/p><\/blockquote>\n

\nNel caso di werf, \u00e8 un altro componente di Kubernetes. Solo che adesso, nella nostra versione alpha di werf, Helm si compila direttamente all'interno di werf, perch\u00e9 ci siamo stancati di farlo da soli. Ci sono molte ragioni per fare cos\u00ec; spiegher\u00f2 dettagliatamente perch\u00e9 abbiamo incorporato completamente helm insieme a tiller dentro werf nella mia presentazione a RIT++<\/a><\/noindex>.<\/p>\n

Attualmente werf \u00e8 un componente pi\u00f9 integrato. Otteniamo un volante finito, un perno di controllo - non sono molto esperto di automobili, ma si tratta di un grande blocco che risolve gi\u00e0 un ampio spettro di compiti. Non dobbiamo perdere tempo a cercare nel catalogo, abbinando un pezzo all'altro e pensando a come montarli insieme. Riceviamo un combinato pronto all'uso che risolve immediatamente un gran numero di compiti. Ma all'interno \u00e8 costruito con gli stessi componenti open source, utilizza Docker per le compilazioni, Helm per alcune funzionalit\u00e0 e ci sono anche altre librerie. \u00c8 uno strumento integrato per ottenere rapidamente e facilmente un ottimo CI\/CD direttamente dalla scatola.<\/p>\n

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

\n\u2014 Parli della tua esperienza con Kubernetes, dicendo che \u00e8 il vostro telaio, motore, e che si pu\u00f2 aggiungere tanto di diverso: carrozzeria, volante, collegare i pedali, i sedili. Nasce la domanda: quanto \u00e8 difficile per voi mantenere Kubernetes? Avete una ricca esperienza, quanto tempo e risorse dedicate specificamente alla manutenzione di Kubernetes a parte tutto il resto?<\/b><\/p>\n

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

\u2014 Da quello che so e come vedo, molte squadre vogliono provare Kubernetes. Tutti si cimentano, lo installano da soli. Ho la sensazione che le persone non comprendano sempre la complessit\u00e0 di questo sistema.<\/b><\/p>\n

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

\u2014 Quanto \u00e8 difficile prendere Kubernetes e installarlo da zero affinch\u00e9 sia pronto per la produzione?<\/b><\/p>\n

Dmitrij<\/b>: Cosa ne pensi, quanto \u00e8 difficile trapiantare un cuore? Capisco, \u00e8 una domanda compromettente. Usare un bisturi e non sbagliare non \u00e8 cos\u00ec difficile. Se qualcuno ti dice dove tagliare e dove suturare, la procedura in s\u00e9 non \u00e8 complessa. \u00c8 difficile garantire di volta in volta che tutto funzioni perfettamente.<\/p>\n

Installare Kubernetes e farlo funzionare \u00e8 semplice: puff! - \u00e8 installato, ci sono molti modi per farlo. Ma cosa succede quando sorgono problemi?<\/p><\/blockquote>\n

\nSorgono sempre domande: cosa non abbiamo considerato? Cosa non abbiamo fatto? Quali parametri del kernel di Linux abbiamo specificato in modo errato? Dio mio, li abbiamo specificati?! Quali componenti di Kubernetes abbiamo installato e quali no? Nascono migliaia di domande, e per rispondere a queste \u00e8 necessario avere 15-20 anni di esperienza in questo settore.<\/p>\n

Ho un esempio fresco su questo tema che pu\u00f2 chiarire il significato del problema \"\u00c8 difficile mantenere Kubernetes?\". Qualche tempo fa abbiamo seriamente considerato se valesse la pena implementare Cilium come rete in Kubernetes.<\/p>\n

Spiegher\u00f2 cos'\u00e8 Cilium. In Kubernetes ci sono molte diverse implementazioni del sistema di rete, e una di esse \u00e8 davvero fantastica: \u00e8 Cilium. Qual \u00e8 il suo scopo? Nel kernel, qualche tempo fa, \u00e8 stata introdotta la possibilit\u00e0 di scrivere hook per il kernel che, in un modo o nell'altro, si inseriscono nel sistema di rete e in altri vari sistemi, consentendo di aggirare grandi parti nel kernel.<\/p>\n

Nel kernel di Linux ci sono storicamente ip rout, netfilter, bridge e molti altri componenti datati, alcuni dei quali hanno 15, 20 o 30 anni. In generale, funzionano, \u00e8 tutto fantastico, ma ora abbiamo una moltitudine di contenitori, e appare come una torre di 15 mattoni uno sopra l'altro, mentre tu ci stai sopra su una gamba - una sensazione strana. Questo sistema si \u00e8 sviluppato storicamente con molte sfumature, come un'appendice nell'organismo. 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: i ragazzi hanno scritto i loro hook per il kernel. Il pacchetto arriva nel kernel Linux, lo estraggono direttamente all'ingresso, lo elaborano come necessario senza bridge, senza TCP, senza stack IP - insomma, saltando tutto ci\u00f2 che \u00e8 stato scritto nel kernel di Linux, e lo sputano immediatamente nel contenitore.<\/p>\n

Qual \u00e8 il risultato? Un performance davvero impressionante, funzionalit\u00e0 fantastiche - semplicemente incredibile! Ma guardiamo a questo e vediamo che su ogni macchina c'\u00e8 un programma che si connette all'API Kubernetes e, in base ai dati che ottiene da quest'API, genera codice C e compila i binari che carica nel kernel, affinch\u00e9 questi hook funzionino nello spazio del kernel.<\/p>\n

Cosa succede se qualcosa va storto? Non lo sappiamo. Per capirlo, dobbiamo leggere tutto questo codice, comprendere tutta la logica, ed \u00e8 incredibilmente complicato. D'altra parte, ci sono questi bridge, netfilter, ip rout - non ho letto i loro sorgenti, e nemmeno i 40 ingegneri che lavorano nella nostra azienda. Forse alcuni pezzi sono compresi solo da pochi.<\/p>\n

E qual \u00e8 la differenza? Risulta che ci sia ip rout, il nucleo di Linux, e ci sia un nuovo strumento: qual \u00e8 la differenza? Non comprendiamo n\u00e9 l'uno n\u00e9 l'altro. Ma abbiamo paura di usare il nuovo: perch\u00e9? Perch\u00e9 se uno strumento ha 30 anni, in 30 anni sono stati trovati tutti i bug, e non \u00e8 necessario conoscere tutto: funziona come una scatola nera e funziona sempre. Tutti sanno dove infilare il cacciavite diagnostico, quale tcpdump avviare in un determinato momento. Tutti conoscono bene gli strumenti diagnostici e comprendono come funziona questo insieme di componenti nel nucleo di Linux: non come \u00e8 costruito, ma come si usa.<\/p>\n

E l'incredibile Cilium non ha 30 anni, non \u00e8 ancora stato collaudato. Con Kubernetes \u00e8 lo stesso, \u00e8 una copia. Sia che Cilium venga installato magnificamente, sia che Kubernetes venga installato magnificamente, ma quando qualcosa va storto in produzione, sarete in grado di capire rapidamente, in una situazione critica, cosa \u00e8 andato storto? <\/p>\n

Quando parliamo di quanto sia difficile mantenere Kubernetes, no, \u00e8 molto semplice, e s\u00ec, \u00e8 incredibilmente complicato. Kubernetes funziona bene da solo, ma con un miliardo di sfumature.<\/p><\/blockquote>\n

<\/p>\n

Sull'approccio 'Spero di avere fortuna'<\/h2>\n

\n\u2014 Esistono aziende dove \u00e8 quasi garantito che appariranno queste sfumature? Supponiamo che Yandex decida improvvisamente di migrare tutti i servizi su Kubernetes, ci sar\u00e0 un carico enorme.<\/b><\/p>\n

Dmitrij<\/b>: No, questa non \u00e8 una discussione sul carico, ma su cose basilari. Ad esempio, abbiamo Kubernetes, abbiamo distribuito l\u00ec un'applicazione. Come possiamo capire se funziona? Non esiste uno strumento pronto per capire che l'applicazione non si arresta. Non esiste 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 pu\u00f2 dire che sia una versione vecchia, ma noi ci siamo ancora sopra perch\u00e9 \u00e8 LTS. Ci sono systemd, il cui inconveniente \u00e8 che non ripulisce i C-groups. Kubernetes avvia i pod, crea C-groups, poi elimina i pod, e in qualche modo si verifica - non ricordo i dettagli, scusate - che rimangono degli slice di systemd. Questo porta a un punto in cui, col passare del tempo, qualsiasi macchina inizia a rallentare notevolmente. Non \u00e8 nemmeno una questione di highload. Se si avviano pod permanenti, ad esempio, se c'\u00e8 un Cron Job che genera costantemente pod, allora la macchina con Ubuntu 16.04 dopo una settimana inizier\u00e0 a rallentare. Ci sar\u00e0 un load average costantemente alto a causa della creazione di un sacco di C-groups. Questo \u00e8 un problema di cui chiunque installi semplicemente Ubuntu 16 e poi Kubernetes si trova a fronteggiare.<\/p>\n

Supponiamo che in qualche modo aggiorni systemd o qualcos'altro, ma nel kernel Linux fino alla versione 4.16 \u00e8 persino pi\u00f9 divertente: quando si eliminano i C-groups, essi perdono nel kernel e in realt\u00e0 non vengono rimossi. Pertanto, dopo un mese di lavoro su questa macchina sar\u00e0 impossibile visualizzare le statistiche della memoria relative ai pod. Prendiamo un file, lo giriamo nel programma, e un file ci sta 15 secondi, perch\u00e9 il kernel calcola a lungo internamente su un milione di C-groups che sembrano essere stati rimossi, ma in realt\u00e0 non lo sono - perdono.<\/p>\n

Ci sono ancora tantissimi di questi piccoli dettagli sia qui che l\u00e0. Non \u00e8 una questione che le grandi aziende possono affrontare occasionalmente durante carichi molto elevati - no, \u00e8 una questione di cose quotidiane. Le persone possono vivere cos\u00ec per mesi - hanno installato Kubernetes, hanno deploato un'applicazione - sembra funzionare. Per molti va bene. Non scopriranno mai che quell'applicazione croller\u00e0 per qualche motivo, l'allerta non arriver\u00e0, ma per loro \u00e8 la norma. Prima vivevano su macchine virtuali senza monitoraggio, ora si sono trasferiti in Kubernetes anche senza monitoraggio - qual \u00e8 la differenza?<\/p>\n

Il punto \u00e8 che quando camminiamo sul ghiaccio, non sappiamo mai quanto \u00e8 spesso, a meno che non lo misuriamo in anticipo. Molti camminano e non si preoccupano, perch\u00e9 ci sono gi\u00e0 stati.<\/p>\n

Dal mio punto di vista, la complessit\u00e0 e la difficolt\u00e0 nell'esploitazione di qualsiasi sistema stanno nel garantire che lo spessore del ghiaccio sia sufficientemente solido per risolvere le nostre esigenze. \u00c8 di questo che si tratta.<\/p><\/blockquote>\n

\nNell'IT, mi sembra che ci siano troppi approcci del tipo 'Mi andr\u00e0 bene'. Molti installano software e usano librerie in attesa che le cose vadano bene. In generale, molte volte va bene. Probabilmente \u00e8 anche per questo che funziona.<\/p>\n

\u2014 Dal mio punto di vista pessimista, sembra cos\u00ec: quando i rischi sono elevati e l'applicazione deve funzionare, \u00e8 necessaria assistenza da parte di 'Flant', possibilmente da Red Hat, oppure \u00e8 richiesta una propria squadra interna dedicata a Kubernetes, che \u00e8 pronta a gestirlo.<\/b><\/p>\n

Dmitrij<\/b>: Oggettivamente \u00e8 cos\u00ec. Entrare da soli nella questione di Kubernetes con un piccolo team comporta alcuni rischi.<\/p>\n

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

\n\u2014 Puoi raccontarmi quanto Kubernetes sia diffuso in Russia?<\/b><\/p>\n

Dmitrij<\/b>: Non ho questi dati e non sono sicuro che qualcun altro li abbia. Noi diciamo: 'Kubernetes, Kubernetes', ma ci sono altri punti di vista su questa questione. Quanto siano diffusi i container, non lo so nemmeno, ma so che secondo i rapporti online il 70% dei container \u00e8 orchestrato da Kubernetes. \u00c8 stata una fonte attendibile su un campione piuttosto grande a livello mondiale.<\/p>\n

Passiamo a un'altra domanda: abbiamo davvero bisogno di container?<\/b> Ho la sensazione personale e in generale la posizione dell'azienda 'Flant' \u00e8 che Kubernetes \u00e8 lo standard de facto.<\/p>\n

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

\n\u00c8 un vero game-changer nel campo della gestione delle infrastrutture. Davvero assoluto: basta Ansible, Chef, macchine virtuali, Terraform. Non parlo nemmeno dei vecchi metodi improvvisati. Kubernetes \u00e8 un cambiamento assoluto<\/b>, e ora sar\u00e0 solo cos\u00ec.<\/p>\n

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

\u2014 Quindi le aziende che non sono ancora passate a Kubernetes, devono sicuramente farlo, o rimarranno nel dimenticatoio. Ho capito correttamente?<\/b><\/p>\n

Dmitrij<\/b>: Anche questo non \u00e8 del tutto corretto. Ad esempio, se abbiamo il compito di lanciare un server DNS, pu\u00f2 funzionare su FreeBSD 4.10 e pu\u00f2 funzionare perfettamente per 20 anni. Semplicemente funziona e basta. \u00c8 possibile che in 20 anni sia necessario aggiornare qualcosa una sola volta. Se parliamo di software che abbiamo lanciato e che funziona realmente per anni senza aggiornamenti, senza modifiche, ovviamente, non ci sar\u00e0 Kubernetes. Non \u00e8 necessario.<\/p>\n

Tutto ci\u00f2 che riguarda CI\/CD - ovunque ci sia bisogno di Continuous Delivery, dove \u00e8 necessario aggiornare le versioni, apportare modifiche attive, ovunque sia necessario costruire tolleranza ai guasti - solo Kubernetes.<\/p><\/blockquote>\n

<\/p>\n

Sui microservizi<\/h2>\n

\n\u2014 Qui ho un piccolo dissonanza. Per lavorare con Kubernetes, \u00e8 necessaria un supporto esterno o interno - questo \u00e8 il primo punto. Secondo - quando iniziamo appena a sviluppare, siamo una piccola startup, non abbiamo ancora nulla, lo sviluppo sotto Kubernetes o sotto l'architettura a microservizi pu\u00f2 essere complicato e non sempre giustificato economicamente. Sono interessato alla tua opinione: \u00e8 necessario che le startup inizino subito a scrivere sotto Kubernetes o si pu\u00f2 comunque scrivere un monolite e poi passare a Kubernetes?<\/b><\/p>\n

Dmitrij<\/b>: Ottima domanda. Ho una presentazione sui microservizi \u00abMicroservizi: la dimensione conta\u00bb.<\/a><\/noindex> Mi \u00e8 capitato molte volte di vedere persone che cercano di piantare chiodi con un microscopio. Di per s\u00e9, l'approccio \u00e8 corretto, stiamo progettando il nostro software interno proprio in questo modo. Ma quando lo fai, devi avere una chiara comprensione di quello che stai facendo. Ci\u00f2 che odio di pi\u00f9 nei microservizi \u00e8 la parola \u00abmicro\u00bb. Storicamente, questa parola \u00e8 emersa 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 capiscono che ci sono problemi e che deve essere suddiviso in micro-pezzi - circa 10, ognuno dei quali \u00e8 scritto da un minimo di 30 persone. Questo \u00e8 importante, necessario e fantastico. Ma quando ci arriva una startup, dove 3 ragazzi molto bravi e talentuosi hanno scritto 60 microservizi a mano, ogni volta cerco il Corvalol.<\/p>\n

Mi sembra che se ne sia gi\u00e0 parlato mille volte: abbiamo ottenuto un monolite distribuito in una forma o nell'altra. Questo non \u00e8 economicamente giustificato, \u00e8 molto difficile 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, utilizzare Kubernetes \u00e8 spaventoso, perch\u00e9 non \u00e8 chiaro cosa possa rompersi o non funzionare, dall'altro lato, \u00e8 evidente che tutto sta andando in quella direzione e niente, tranne Kubernetes, ci sar\u00e0. La risposta \u00e8 valutare il volume dei benefici che si ottiene, il volume delle attivit\u00e0 che puoi risolvere<\/b>. Questo \u00e8 da un lato della bilancia. Dall'altro lato ci sono i rischi legati ai tempi di inattivit\u00e0 o alla diminuzione del tempo di risposta, del livello di disponibilit\u00e0, alla diminuzione delle metriche di performance.<\/p>\n

La situazione \u00e8 questa: o ci muoviamo rapidamente, e Kubernetes consente di fare molte cose molto pi\u00f9 velocemente e meglio, oppure utilizziamo soluzioni affidabili e collaudate, ma ci muoviamo molto pi\u00f9 lentamente. Questa scelta deve essere fatta da ogni azienda. Si pu\u00f2 considerare come un sentiero nella giungla: quando ci si va la prima volta, si pu\u00f2 incontrare un serpente, una tigre o un tasso arrabbiato, ma dopo esserci andati 10 volte, si crea un sentiero, si rimuovono i rami e si cammina pi\u00f9 facilmente. Ogni volta il sentiero diventa pi\u00f9 ampio. Poi diventa una strada asfaltata, e successivamente un bel viale.<\/p>\n

Kubernetes non resta fermo. Ancora una volta la domanda: Kubernetes, da un lato, sono 4-5 binari, dall'altro lato, \u00e8 tutto un ecosistema. \u00c8 un sistema operativo che abbiamo sulle macchine. Cos'\u00e8? Ubuntu o Curios? \u00c8 il kernel Linux, una miriade di componenti aggiuntivi. Tutte queste cose qui hanno scartato un serpente velenoso dalla strada, l\u00e0 hanno messo una recinzione. Kubernetes si sta sviluppando molto rapidamente e dinamicamente, e il volume dei rischi, il volume dell'ignoto, diminuisce ogni mese e, di conseguenza, questi pesi si riequilibrano.<\/p>\n

Rispondendo alla domanda su cosa fare per una startup, direi: venite da \"Flant\", pagate 150.000 rubli e ottenete un servizio DevOps easy service chiavi in mano. Se siete una piccola startup con pochi sviluppatori, questo funziona. Invece di assumere il vostro DevOps, che dovr\u00e0 imparare a risolvere i vostri problemi e a cui dovrete pagare uno stipendio nel frattempo, riceverete una soluzione a tutte le questioni chiavi in mano. S\u00ec, ci sono alcuni svantaggi. Noi, come outsourcer, non possiamo essere cos\u00ec coinvolti e non possiamo reagire rapidamente ai cambiamenti. Ma abbiamo molta esperienza e pratiche pronte. Garantiamo che in qualsiasi situazione ci organizzeremo rapidamente e recupereremo qualsiasi Kubernetes dall'aldil\u00e0. <\/p>\n

Raccomando categoricamente l'outsourcing per le startup e le aziende consolidate fino a quando non potete dedicare un team di 10 persone alla gestione, perch\u00e9 altrimenti non ha senso. Ha assolutamente senso esternalizzare.<\/p><\/blockquote>\n

<\/p>\n

Su Amazon e Google<\/h2>\n

\n\u00c8 possibile considerare le soluzioni di hosting da Amazon o Google come outsourcing?<\/b><\/p>\n

Dmitrij<\/b>: S\u00ec, certamente, questo risolve alcune questioni. Ma ci sono comunque delle sfumature. Bisogna comunque capire come utilizzarle. Ad esempio, ci sono mille piccoli dettagli nel lavoro con Amazon AWS: bisogna riscaldare il Load Balancer o inviare una richiesta in anticipo dicendo \"ragazzi, ci arriver\u00e0 traffico, per favore riscaldateci il Load Balancer!\" Queste sfumature bisogna conoscerle.<\/p>\n

Quando ti rivolgi a persone che si specializzano in questo, ottieni quasi tutte le cose standard messe a posto. Adesso abbiamo 40 ingegneri e entro la fine dell'anno probabilmente saranno 60 \u2014 siamo sicuri di aver gi\u00e0 affrontato tutte queste cose. Anche se su un progetto troviamo di nuovo questo problema, chiediamo gi\u00e0 rapidamente tra di noi e sappiamo come risolverlo.<\/p>\n

Probabilmente la risposta \u00e8: certo, la storia dell'hosting facilita una parte di questo. La domanda \u00e8: siete pronti a fidarvi di questi fornitori di hosting, e risolveranno i vostri problemi? Amazon e Google si sono dimostrati efficaci. Per tutti i nostri casi, sicuramente. Altrimenti non abbiamo avuto esperienze positive. Tutti gli altri cloud con cui abbiamo provato a lavorare hanno creato molti problemi \u2014 sia Ager che tutto ci\u00f2 che esiste in Russia, e vari OpenStack in diverse implementazioni: Headster, Overage \u2014 tutto ci\u00f2 che vuoi. Creano tutti problemi che non si ha voglia di affrontare.<\/p>\n

Pertanto, la risposta \u00e8 s\u00ec, ma in effetti non ci sono molte soluzioni hosted mature.<\/p>\n

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

\n\u2014 E comunque, a chi serve Kubernetes? Chi dovrebbe gi\u00e0 passare a Kubernetes, chi \u00e8 il cliente tipico di \"Flanta\" che viene proprio per Kubernetes?<\/b><\/p>\n

Dmitrij<\/b>: \u00c8 una domanda interessante, perch\u00e9 adesso molti ci contattano proprio in un momento in cui Kubernetes \u00e8 di tendenza: \"Ragazzi, sappiamo che fate Kubernetes, fatelo per noi!\". Noi rispondiamo: \"Signori, non facciamo Kubernetes, facciamo produzione e tutto ci\u00f2 che con esso \u00e8 collegato\". Perch\u00e9 fare produzione senza dedicarsi a tutto il CI\/CD e a tutta questa storia \u00e8 semplicemente impossibile al giorno d'oggi. Tutti si sono allontanati dalla divisione tra sviluppo e operazioni.<\/p>\n

I nostri clienti si aspettano cose diverse, ma tutti sperano in qualche miracolo, che possano avere problemi e adesso \u2014 hop! \u2014 Kubernetes li risolver\u00e0. La gente crede nei miracoli. Sa razionalmente che non ci sar\u00e0 un miracolo, ma spera con il cuore \u2014 e se questo Kubernetes ora ci risolvesse tutto, ne parlano tanto! E se fosse ora \u2014 ecco! \u2014 la pallottola d'argento, ecco! \u2014 e avremmo un uptime del 100%, tutti gli sviluppatori potrebbero rilasciare quello che vogliono in produzione 50 volte e non cadrebbe. In generale, un miracolo!<\/p>\n

Quando queste persone ci contattano, diciamo: \"Ci scusiamo, ma i miracoli non esistono\". Per essere in salute, bisogna mangiare bene e fare sport. Per avere una produzione affidabile, bisogna costruirla in modo affidabile. Per avere un CI\/CD conveniente, bisogna crearlo in quel modo. C'\u00e8 molto lavoro da fare.<\/p>\n

Rispondendo alla domanda a chi serve Kubernetes \u2014 Kubernetes non serve a nessuno.<\/p><\/blockquote>\n

\nAlcune persone hanno la falsa impressione di avere bisogno di Kubernetes. La gente ha bisogno di smettere di pensare, occuparsi e interessarsi a tutti i problemi infrastrutturali e ai problemi di avvio delle loro applicazioni. Vogliono che le applicazioni funzionino semplicemente e si distribuiscano senza problemi. Per loro Kubernetes \u00e8 la speranza di smettere di sentire storie come \"eravamo in difficolt\u00e0\" o \"non possiamo rilasciare\", o altro.<\/p>\n

Di solito, ci contatta un direttore tecnico. Da lui ci si aspetta due cose: da un lato, vogliamo le funzionalit\u00e0, dall'altro \u2014 stabilit\u00e0. Noi proponiamo di prenderci questa responsabilit\u00e0 e fare. La pallottola d'argento, o meglio, la pallottola argentata, consiste nel fatto che smetterai di pensare a questi problemi e di perdere tempo. Avrai persone speciali che si occuperanno di questa questione.<\/p>\n

La formulazione che noi o qualcuno abbiamo bisogno di Kubernetes \u00e8 errata.<\/p><\/blockquote>\n

\nKubernetes \u00e8 molto utile per gli amministratori, perch\u00e9 \u00e8 un giocattolo veramente interessante con cui giocare e sperimentare. Siamo onesti: a tutti piacciono i giocattoli. Siamo tutti bambini in qualche modo e quando vediamo qualcosa di nuovo, vogliamo giocarci. Alcuni di noi lo hanno superato, per esempio nel mondo dell'amministrazione, perch\u00e9 ci siamo gi\u00e0 divertiti e ci siamo stancati tanto che non abbiamo pi\u00f9 voglia. Ma non \u00e8 che questo interesse sia completamente spento per chiunque. Ad esempio, se mi sono gi\u00e0 annoiato dei giochi nel campo dell'amministrazione di sistemi e del DevOps, continuo comunque ad amare i giocattoli e ne acquisto di nuovi.<\/p>\n

Non bisogna giocare con la produzione. Quello che io categoricamente non consiglio di fare e che vedo ora accadere molto spesso \u00e8: \"Oh, un nuovo giocattolo!\" e correte a comprarlo, comprato e poi: \"Prendiamolo subito a scuola, mostriamo a tutti i nostri amici\". Non fatelo. Mi scuso, ho solo dei bambini che crescono, vedo continuamente cose nei bambini, me ne accorgo in me stesso e poi generalizzo sugli altri.<\/p>\n

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

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