La sfârșitul lunii mai organizat un meet-up online pe tema . Am discutat despre containere, Kubernetes și orchestration în general, despre criteriile de alegere a infrastructurii și multe altele. Participanții au împărtășit studii de caz din propria experiență.
Participanți:
- Evgheni Potapov, CEO „ITSumma”. Mai mult de jumătate dintre clienții săi fie au trecut deja, fie doresc să treacă la Kubernetes.
- Dmitri Stolyarov, CTO „Flant”. Are peste 10 ani de experiență în lucrul cu sistemele de containere.
- Denis Remciukov (aka Eric Oldmann), COO argotech.io, fost la RAO EES. A promis să vorbească despre studii de caz din „sectorul greu” al enterprise-urilor.
- Andrei Fedorovski, CTO „News360.com”După achiziția companiei de către un alt jucător, este responsabil pentru o serie de proiecte ML și AI și pentru infrastructură.
- Ivan Kruglov, inginer sistem, fost la Booking.com.Același om care a realizat multe cu Kubernetes cu mâinile sale.
Teme:
- Întâlnirile participanților despre containere și orchestration (Docker, Kubernetes și altele); ce au încercat în practică sau au analizat.
- Studiu de caz: Compania își construiește un plan pe termen lung pentru dezvoltarea infrastructurii. Cum se ia decizia de a construi (sau de a migra infrastructura curentă) pe containere și Kubernetes sau nu?
- Probleme în lumea cloud-native, ce lipsește, să ne imaginăm ce va fi mâine.
A avut loc o discuție interesantă, opiniile participanților s-au dovedit atât de diferite și au stârnit atât de multe comentarii încât dorim să le împărtășim cu voi. Există , iar mai jos – o sinteză a discuției.
Kubernetes este deja un standard sau un marketing excelent?
„Am ajuns la el (Kubernetes. — Nota red.) atunci când nimeni nu știa despre el. Am ajuns la el atunci când acesta încă nu exista. L-am dorit mult înainte” — Dmitri Stolyarov
Fotografie de pe Reddit.com
Acum 5-10 ani existau o mulțime de instrumente și nu existau standarde unice. La fiecare șase luni apărea un nou produs, sau poate chiar mai mult de unul. La început Vagrant, apoi Salt, Chef, Puppet,… „și trebuie să îți reconstruiești infrastructura la fiecare șase luni. Ai cinci administratori care sunt constant ocupați cu scrierea configurațiilor” — își amintește Andrei Fedorovski. El crede că Docker și Kubernetes „au pus capăt celorlalte”. Docker a devenit standard în ultimii cinci ani, Kubernetes — în ultimii doi ani. Și acest lucru este bun pentru industrie..
Dmitrie Stolyarov și echipa sa iubesc Kubernetes. Ei își doreau un astfel de instrument cu mult înainte de a apărea, și l-au adoptat încă de când nimeni nu știa despre el. În prezent, din motive de confort, nu acceptă clienți dacă consideră că nu pot implementa Kubernetes pentru aceștia. Cu toate acestea, potrivit lui Dmitrie, compania are „multe istorii de succes uriașe în transformarea unor moșteniri teribile”.
Kubernetes nu este doar o orchestrare de containere; este un sistem complex de gestionare a configurației, cu o API dezvoltată, un component de rețea, echilibrare L3 și controllere Ingress, care permite gestionarea relativ ușoară a resurselor, scalarea și abstraharea de straturile inferioare ale infrastructurii.
Din păcate, în viața noastră trebuie să plătim pentru tot. Și acest impozit este mare, mai ales când vine vorba de tranziția unei companii cu o infrastructură dezvoltată la Kubernetes, consideră Ivan Kruglov. El ar putea lucra fără probleme atât într-o companie cu infrastructură tradițională, cât și cu Kubernetes. Principalul este să înțelegi caracteristicile companiei și ale pieței. Dar, de exemplu, pentru Evgheni Potapov, care ar generaliza Kubernetes ca pe orice instrument de orchestrare a containerelor, o astfel de problemă nu există.
Evgheni a tras o analogie cu situația din anii '90, când a apărut programarea orientată pe obiect, ca modalitate de a programa aplicații complexe. La acea vreme, dezbaterile nu se opreau, iar noi instrumente care suportau OOP apăreau constant. Apoi, au apărut microserviciile ca o modalitate de a scăpa de conceptele monolitice. Aceasta, la rândul său, a dus la apariția containerelor și a instrumentelor lor de gestionare. „Cred că în curând vom ajunge în acel moment când întrebarea dacă ar trebui să scriem o aplicație mică într-un mod microservicii nu va mai exista; aceasta va fi scrisă implicit ca un microserviciu”, consideră el. Similar, Docker și Kubernetes vor deveni, în timp, o soluție standard fără a mai necesita o alegere.
Problema bazelor de date este stateless.
Foto de
În zilele noastre, există multe rețete pentru a rula baze de date în Kubernetes. Chiar și pentru a separa partea care lucrează cu I/O de disc de, să zicem, partea de aplicație a bazei de date. Este posibil ca în viitor bazele de date să se schimbe atât de mult încât vor fi livrate într-o cutie, unde o parte va fi orchestrat prin Docker și Kubernetes, iar cealaltă parte a infrastructurii, printr-un software separat, va oferi partea de stocare? Se vor schimba bazele ca produs?
Această descriere seamănă cu managementul coadelor, dar cerințele de fiabilitate și sincronizare a informațiilor în bazele de date tradiționale sunt mult mai ridicate, consideră Andrei. Ratio-ul de hit-uri al cache-ului în bazele normale se menține la un nivel de 99%. Dacă un worker se prăbușește, se lansează unul nou, iar cache-ul se "reîncălzește" de la zero. Până când cache-ul nu este reîncălzit, worker-ul funcționează lent, deci nu poate suporta o sarcină de utilizator. Atâta timp cât nu există o sarcină de utilizator, cache-ul nu se reîncălzește. Este un cerc vicios.
Dmitri nu este de acord, - cvorumul și sharding-ul rezolvă problema. Dar Andrei insistă că soluția nu se potrivește tuturor. În unele situații, cvorumul este potrivit, dar adaugă o sarcină suplimentară asupra rețelei. O bază NoSQL nu este potrivită în toate cazurile.
Participanții la meet-up s-au împărțit în două tabere.
Denis și Andrei susțin că tot ce scrie pe disc - bazele și altele - nu este posibil de realizat în actuala ecosistemă Kubernetes. Nu este posibil să menții integritatea și consistența datelor productive în Kubernetes. Aceasta este o caracteristică fundamentală. Soluția: infrastructură hibridă.
Chiar și bazele cloud native moderne, cum ar fi MongoDB și Cassandra, sau coadele de mesaje, cum ar fi Kafka sau RabbitMQ, necesită stocări de date permanente în afara Kubernetes.
Evgheni replică: „Bazele în Kubernetes sunt o traumă legată de Rusia sau de întreprinderile mari, asociată cu faptul că în Rusia adoptarea cloud-ului nu există”. Companiile mici sau medii din Vest sunt bazate pe Cloud. Este mai ușor să folosești Amazon RDS decât să te ocupi singur de Kubernetes. În Rusia, se folosește Kubernetes "on-premise" și se mută bazele în el atunci când încearcă să scape de zoo-ul de tehnologii.
Dmitri nu este de acord cu afirmația că nu există baze care să poată fi păstrate în Kubernetes: „Există baze și baze. Și dacă vrei să introduci o bază de date relațională gigantică, atunci cu siguranță nu. Dacă vrei să introduci ceva mic și cloud native, care este pregătit moral pentru o viață semi-efemeră, totul va fi în regulă.” Dmitri a menționat, de asemenea, că instrumentele de gestionare a bazelor nu sunt pregătite nici pentru Docker, nici pentru Kubernetes, astfel încât apar mari complicații.
Ivan este, la rândul său, sigur că, chiar dacă ne abținem de la noțiunile de stateful și stateless, ecosistemul soluțiilor enterprise în Kubernetes nu este încă pregătit. Cu Kube este dificil să se respecte cerințele legale și de reglementare. De exemplu, este imposibil să realizăm o soluție de furnizare a identității, unde sunt necesare garanții stricte de identificare a serverului, inclusiv până la hardware-ul care este introdus în servere. Acest domeniu se dezvoltă, dar momentan nu există soluții.
Participanții nu au reușit să ajungă la un acord, așa că nu vor urma concluzii în această parte. Mai bine să dăm câteva exemple practice.
Caz 1. Cybersecuritate a «megaregulatorului» cu baze de date în afara Kubernetes
În cazul unui sistem dezvoltat de cybersecuritate, utilizarea containerelor și orchestrasii permite apărarea împotriva atacurilor și intruziunilor. De exemplu, într-un megaregulator, Denis și echipa sa au implementat o legătură între orchestrator și un serviciu SIEM antrenat, care analizează jurnalele în timp real și determină procesul atacului, spargerii sau defecțiunii. În caz de atac, încercări de a introduce ceva sau în caz de intruziune a unui virus ransomware, acesta, prin orchestrator, ridică containere cu aplicații mai repede decât acestea se infectează sau mai repede decât atacatorul le atacă.
Caz 2. Mutarea parțială a bazelor de date Booking.com în Kubernetes
La Booking.com, baza de date principală este MySQL cu replicare asincronă - există un master și o întreagă ierarhie de slave. La momentul plecării lui Ivan din companie, a fost demarat un proiect de mutare a slavelor, care pot fi «deconectate» cu un anumit prejudiciu.
Pe lângă baza principală, există o instalare Cassandra cu orchestrare personalizată, care a fost scrisă cu mult înainte ca Kubernetes să devină mainstream. Nu sunt probleme în acest sens, dar aceasta are persistent pe SSD-uri locale. Stocările externe, chiar și în cadrul unui singur centru de date, nu sunt folosite din cauza problemelor cu latența mare.
A treia clasă de baze de date este serviciul de căutare Booking.com, unde fiecare nod al serviciului este o bază de date. Încercările de a muta serviciul de căutare în Kubernetes nu au avut succes, deoarece fiecare nod are 60-80 GB de stocare locală, care este greu de «ridicat» și «încălzit».
În cele din urmă, motorul de căutare în Kubernetes nu a fost mutat și Ivan nu crede că vor exista noi încercări în viitorul apropiat. Baza de date MySQL a fost mutată parțial: doar slavelor, care nu este înfricoșător să «deconectezi». Cassandra s-a adaptat excelent.
Alegerea infrastructurii ca o problemă fără soluție generală
Foto de
Să presupunem că avem o companie nouă sau o companie unde o parte din infrastructură a fost construită pe vechi. Aceasta dezvoltă un plan de dezvoltare a infrastructurii pe ani. Cum se ia decizia de a construi infrastructura pe containere și Kubernetes sau nu?
Companiile care se luptă pentru nanosecunde sunt excluse din discuție. Un conservatorism sănătos se justifică din punct de vedere al fiabilității, dar totuși există companii care ar trebui să analizeze noi abordări.
Ivan: „Acum aș începe cu siguranță o companie în cloud, pur și simplu pentru că este mai rapid”, deși nu neapărat mai ieftin. Odată cu dezvoltarea capitalului de risc, startup-urile nu au mari probleme cu banii, iar sarcina principală este de a cuceri piața.
Ivan consideră că dezvoltarea actualei infrastructuri este un criteriu de selecție. Dacă în trecut au fost investiții semnificative, iar acestea funcționează, atunci nu are sens să se refacă. Dacă infrastructura nu este dezvoltată și există probleme cu instrumentele, securitatea și monitorizarea, atunci merită să ne uităm la infrastructura distribuită.
Impozitul va trebui plătit în orice caz, iar Ivan ar plăti acela care i-ar permite să plătească mai puțin în viitor. „Pentru că doar datorită faptului că călătoresc cu un tren condus de alții, voi călători mult mai departe decât dacă m-aș urca în alt tren, în care ar trebui să-mi furnizez eu combustibilul.” — spune Ivan. Când compania este nouă și cerințele de latență sunt de ordinul zecilor de milisecunde, Ivan s-ar uita spre „operatori”, care astăzi „învelește” bazele de date clasice. Aceștia ridică o rețea de replicare care se comută automat în caz de failover, etc…
Pentru o companie mică cu câteva servere în Kubernetes nu are sens, — afirmă Andrei. Dar dacă aceasta planifică să crească la sute de servere sau mai mult, atunci este nevoie de automatizare și de un sistem de gestionare a resurselor. 90% din cazuri justifică costurile. Indiferent de nivelul de încărcare și resurse. Toți, începând de la startup-uri, până la mari companii cu o audiență de milioane, ar trebui să își îndrepte treptat privirea spre produse pentru orchestrarea containerelor. „Da, acesta este cu adevărat viitorul”, este convins Andrei.
Denis a identificat două criterii principale — scalabilitatea și reziliența operațiunilor. El va alege acele instrumente care se potrivesc cel mai bine acestei sarcini. „Aceasta poate fi o soluție DIY necunoscută, pe care o rulăm cu Nutanix Community Edition. Poate fi o a doua linie sub forma unei aplicații pe Kuber, cu o bază de date în backend, care este replicată și are parametri stabiliți RTO și RPO” (obiectivele de timp de recuperare/punct). exemplu).
Eugene a semnalat o posibilă problemă cu personalul. În prezent, pe piață nu sunt atât de mulți specialiști de înaltă calitate care să înțeleagă „interiorul” tehnologiilor. Cu adevărat, dacă tehnologia aleasă este învechită, este greu să angajezi pe cineva, în afară de persoane în vârstă, plictisite și obosite de viață. Cu toate acestea, alți participanți consideră că aceasta este o problemă de pregătire profesională.
Dacă ne punem întrebarea de alegere: să lansăm o companie mică în Public Cloud cu baze de date în Amazon RDS sau „on premise” cu baze de date în Kubernetes, atunci, în ciuda unor dezavantaje, alegerea participanților a fost Amazon RDS.
Deoarece majoritatea ascultătorilor meetup-ului nu provin din „entertainment” corporativ, soluțiile distribuite sunt ceea ce trebuie să aspirăm. Sistemele de stocare a datelor trebuie să fie distribuite, fiabile, și să genereze latențe măsurate în milisecunde, maximum zeci., a conchis Andrei.
Evaluarea utilizării Kubernetes
Ascultătorul Anton Zhbankov a adresat o întrebare capcană apologistilor Kubernetes: cum a fost aleasă și desfășurată fundamentarea tehnico-economică? De ce Kubernetes, de ce nu mașini virtuale, de exemplu?
Foto de
Răspunsurile au venit de la Dmitry și Ivan. În ambele cazuri, prin metoda probelor și greșelilor, s-a realizat o secvență de soluții, în urma căreia ambii participanți au ajuns la Kubernetes. Acum, afacerea începe să dezvolte independent software care are sens să fie migrat în Kuber. Nu este vorba despre sisteme externe clasice, de tip 1C. Kubernetes ajută atunci când dezvoltatorii trebuie să facă rapid lansări, într-un proces continuu de îmbunătățire.
Echipa lui Andrei a încercat să creeze un cluster scalabil pe baza mașinilor virtuale. Nodurile cădeau ca niște domino, ceea ce uneori ducea la căderea cluster-ului. „Teoretic, putem să finalizăm și să menținem manual, dar este obositor. Și dacă pe piață există o soluție care permite operarea din cutie, atunci ne îndreptăm cu plăcere către ea. Și în cele din urmă am trecut la aceasta.”, spune Andrei.
Există standarde pentru astfel de analize și calcule, dar nimeni nu poate spune cât de exacte sunt acestea în utilizarea pe hardware real. Pentru calcule este, de asemenea, important să înțelegem fiecare instrument și ecosistem, dar acest lucru este imposibil.
Ce ne așteaptă
Foto de
Pe măsură ce tehnologiile progresează, apar din ce în ce mai multe fragmente disparate, iar apoi are loc o tranziție de fază, apare un vendor care a ucis suficient de mult «bani» pentru ca totul să se unească într-un singur instrument.
Nu vi se pare că va veni un moment în care va apărea un instrument așa cum a devenit Ubuntu pentru lumea Linux? Este posibil ca un instrument unic de containerizare și orchestrare să includă și Kubernetes. Cu acesta va fi mai simplu să construiești cloud-uri on-premise.
Ivan a răspuns: «Google construiește acum Anthos — aceasta este oferta lor de pachet care desfășoară cloud-ul și include Kubernetes, Service Mesh, monitorizare — întreaga legătură necesară microserviciilor în „on-premise”. Suntem aproape de viitor.»
Denis a menționat, de asemenea, Nutanix și VMWare cu produsul vRealize Suite, care pot face față unor sarcini similare fără containerizare.
Dmitry a împărtășit opinia că reducerea «durerii» și diminuarea impozitelor sunt două direcții în care ar trebui să ne așteptăm la îmbunătățiri.
În concluzia discuției, să subliniem următoarele probleme ale infrastructurii moderne
- Trei participanți au semnalat problema cu stateful.
- Diversificate probleme de suport pentru securitate, inclusiv probabilitatea ca mai multe versiuni de Python, servere de aplicații și componente să ajungă în Docker.
Suprautilizarea, despre care ar fi bine să organizăm un meetup separat.
Problema învățării, deoarece orchestrarea reprezintă un ecosistem complex.
O problemă generală a industriei — utilizarea instrumentelor în scopuri necorespunzătoare.Restul concluziilor trebuie să le tragi tu. Până acum, rămâne sentimentul că combinația Docker+Kubernetes nu va deveni cu ușurință o parte „centrală” a sistemului. De exemplu, sistemele de operare sunt instalate pe hardware la început, lucru care nu se poate spune despre containere și orchestrare. Poate, în viitor, sistemele de operare și containerele se vor integra cu software-ul de gestionare a cloud-ului.
Foto deCu ocazia aceasta vreau să transmit salutări mamei și să îi amintesc că avem un grup pe Facebook , canal cu publicații interesante din diverse bloguri tehnologice. Și canalul meu , unde vă povestesc despre gestionarea dezvoltării în companiile de produse.
Sursa: habr.com
