Când doriți să utilizați Linux pentru a furniza servicii unei companii, aceste servicii vor trebui să fie sigure, rezistente și scalabile. Cuvinte frumoase, dar ce vrem să spunem prin ele?
„Securizat” înseamnă că utilizatorii pot accesa datele pe care le solicită, fie accesul numai în citire sau accesul la scriere. În același timp, nu există date expuse niciunei părți care nu este autorizată să le vadă. Securitatea este înșelătoare: poți crede că ai totul protejat doar pentru a afla mai târziu că există găuri. Proiectarea în siguranță de la începutul unui proiect este mult mai ușoară decât încercarea de a-l moderniza ulterior.
„Rezilient” înseamnă că serviciile dvs. tolerează eșecurile din cadrul infrastructurii. Un eșec ar putea fi un controler de disc server care nu mai poate accesa niciun disc, făcând datele inaccesibile. Sau eșecul ar putea fi un comutator de rețea care nu mai permite două sau mai multe sisteme să comunice. În acest context, un „punct unic de eșec” sau SPOF este un eșec care afectează negativ disponibilitatea serviciului. O infrastructură rezistentă este una fără SPOF-uri.
„Scalabil” descrie abilitatea sistemelor de a gestiona cu grație vârfurile de cerere. De asemenea, dictează cât de ușor pot fi modificate sistemele. De exemplu, adăugarea unui nou utilizator, creșterea capacității de stocare sau mutarea unei infrastructuri de la Amazon Web Services la Google Cloud - sau chiar mutarea acesteia în interior.
De îndată ce infrastructura dvs. se extinde dincolo de un singur server, există o mulțime de opțiuni pentru creșterea securității, rezistenței și scalabilității. Ne vom uita la modul în care aceste probleme au fost rezolvate în mod tradițional și la ce tehnologie nouă este disponibilă, care schimbă fața calculelor aplicațiilor mari.
Obțineți mai mult Linux!
Îți place ce citești? Vrei mai mult Linux și open source? Putem livra, literalmente! Abonați-vă astăzi la Linux Format la un preț redus. Puteți obține ediții tipărite, ediții digitale sau de ce nu ambele? Livrăm la ușa dvs. în întreaga lume pentru o taxă anuală simplă. Deci, faceți-vă viața mai bună și mai ușoară, abonați-vă acum!
Pentru a înțelege ce este posibil astăzi, este util să ne uităm la modul în care proiectele tehnologice au fost implementate în mod tradițional. În vremurile de demult - adică acum mai bine de 10 ani - companiile cumpărau sau închiriau hardware pentru a rula toate componentele aplicațiilor lor. Chiar și aplicațiile relativ simple, cum ar fi un site web WordPress, au mai multe componente. În cazul WordPress, este necesară o bază de date MySQL împreună cu un server web, cum ar fi Apache, și o modalitate de a gestiona codul PHP. Deci, ar construi un server, vor configura Apache, PHP și MySQL, vor instala WordPress și vor pleca.
În general, asta a funcționat. A funcționat suficient de bine încât există încă un număr mare de servere configurate exact în acest mod astăzi. Dar nu a fost perfect și două dintre cele mai mari probleme au fost rezistența și scalabilitatea.
Lipsa rezistenței a însemnat că orice problemă semnificativă de pe server ar duce la pierderea serviciului. În mod evident, un eșec catastrofal ar însemna lipsa site-ului web, dar, de asemenea, nu a existat spațiu pentru efectuarea întreținerii programate fără a afecta site-ul. Chiar și instalarea și activarea unei actualizări de securitate de rutină pentru Apache ar necesita o întrerupere de câteva secunde pentru site-ul web.
Problema rezilienței a fost rezolvată în mare parte prin construirea de „clustere de înaltă disponibilitate”. Principiul a fost acela de a avea două servere care rulează site-ul web, configurate astfel încât eșecul unuia dintre ele să nu conducă la defectarea site-ului. Serviciul oferit a fost rezistent chiar dacă serverele individuale nu au fost.
Nori abstracteO parte din puterea Kubernetes este abstractizarea pe care o oferă. Din perspectiva dezvoltatorului, dezvoltă aplicația pentru a rula într-un container Docker. Docker nu-i pasă dacă rulează pe Windows, Linux sau pe alt sistem de operare. Același container Docker poate fi preluat de pe MacBook-ul dezvoltatorului și rulat sub Kubernetes fără nicio modificare.
Instalarea Kubernetes în sine poate fi o singură mașină. Desigur, multe dintre beneficiile Kubernetes nu vor fi disponibile: nu va exista o scalare automată; există un singur punct evident de eșec și așa mai departe. Totuși, ca dovadă a conceptului într-un mediu de testare, funcționează.
După ce sunteți pregătit pentru producție, puteți rula intern sau pe un furnizor de cloud, cum ar fi AWS sau Google Cloud. Furnizorii Cloud au câteva servicii încorporate care ajută la rularea Kubernetes, dar niciuna dintre acestea nu este o cerință dificilă. Dacă doriți să vă deplasați între Google, Amazon și propria infrastructură, configurați Kubernetes și vă deplasați. Niciuna dintre aplicațiile dvs. nu trebuie să se schimbe în vreun fel.
Și unde este Linux? Kubernetes rulează pe Linux, dar sistemul de operare este invizibil pentru aplicații. Acesta este un pas semnificativ în maturitatea și utilizabilitatea infrastructurilor IT.
Efectul Slashdot
Problema scalabilității este puțin mai complicată. Să presupunem că site-ul dvs. WordPress primește 1.000 de vizitatori pe lună. Într-o zi, afacerea dvs. este menționată la Radio 4 sau la micul dejun TV. Dintr-o dată, veți obține mai mult de o lună de vizitatori în 20 de minute. Cu toții am auzit povești despre site-uri web care „se prăbușesc” și de aceea de obicei: o lipsă de scalabilitate.
Cele două servere care au ajutat la reziliență ar putea gestiona o sarcină de lucru mai mare decât ar putea face un singur server, dar acest lucru este încă limitat. Ați plăti pentru două servere 100% din timp și de cele mai multe ori ambele funcționau perfect. Este posibil ca unul singur să vă poată rula site-ul. Apoi, John Humphrys menționează afacerea dvs. pe Today și ați avea nevoie de 10 servere pentru a gestiona încărcătura - dar numai pentru câteva ore.
Soluția mai bună atât pentru reziliență, cât și pentru problema scalabilității a fost cloud computing-ul. Configurați o instanță de server sau două - micile servere care vă rulează aplicațiile - pe Amazon Web Services (AWS) sau Google Cloud și, dacă una dintre instanțe nu a reușit din anumite motive, aceasta va fi repornită automat. Configurați scalarea automată corect și atunci când domnul Humphrys face ca volumul de lucru pe instanțele serverului dvs. web să crească rapid, instanțele de server suplimentare sunt pornite automat pentru a partaja volumul de lucru. Mai târziu, pe măsură ce dobânzile scad, acele instanțe suplimentare sunt oprite și plătiți doar pentru ceea ce utilizați. Perfect … sau este?
În timp ce soluția cloud este mult mai flexibilă decât serverul tradițional independent, există încă probleme. Actualizarea tuturor instanțelor cloud care rulează nu este simplă. Dezvoltarea pentru cloud are și provocări: laptopul pe care îl folosesc dezvoltatorii dvs. poate fi similar instanței cloud, dar nu este același lucru. Dacă vă angajați în AWS, migrarea către Google Cloud este o activitate complexă. Și să presupunem că, din orice motiv, pur și simplu nu doriți să vă predați calculele către Amazon, Google sau Microsoft?
Containerele au apărut ca un mijloc de a împacheta aplicațiile cu toate dependențele lor într-un singur pachet care poate fi rulat oriunde. Containerele, cum ar fi Docker, pot rula pe laptopurile dezvoltatorilor dvs. în același mod în care rulează pe instanțele dvs. cloud, dar gestionarea unei flote de containere devine din ce în ce mai dificilă pe măsură ce crește numărul de containere.
Răspunsul este orchestrarea containerelor. Aceasta este o schimbare semnificativă a focalizării. Înainte, ne asiguram că avem suficiente servere, fie ele fizice sau virtuale, pentru a ne asigura că putem deservi volumul de lucru. Folosirea scalării automate a furnizorilor de cloud a ajutat, dar încă ne ocupam de cazuri. A trebuit să configurăm echilibratoarele de sarcină, firewall-urile, stocarea datelor și multe altele manual. Cu orchestrarea containerelor, toate acestea (și multe altele) sunt îngrijite. Specificăm rezultatele pe care le solicităm, iar instrumentele noastre de orchestrare a containerelor ne îndeplinesc cerințele. Precizăm mai degrabă ce vrem să facem, decât cum vrem să se facă.
Deveniți Kubernete
Kubernetes (ku-ber-net-eez) este astăzi instrumentul principal de orchestrare a containerelor și a venit de la Google. Dacă cineva știe să ruleze infrastructuri IT la scară mare, Google știe. Originea Kubernetes este Borg, un proiect Google intern care este încă folosit pentru a rula majoritatea aplicațiilor Google, inclusiv motorul său de căutare, Gmail, Google Maps și multe altele. Borg a fost un secret până când Google a publicat o lucrare despre asta în 2015, dar ziarul a făcut foarte evident faptul că Borg era principala inspirație din spatele Kubernetes.
Borg este un sistem care gestionează resursele de calcul din centrele de date Google și păstrează aplicațiile Google, atât în producție, cât și în alte domenii, în ciuda defecțiunilor hardware, a epuizării resurselor sau a altor probleme care ar fi putut cauza altfel o întrerupere. Face acest lucru monitorizând cu atenție miile de noduri care alcătuiesc o „celulă” Borg și containerele care rulează pe ele și pornind sau oprind containerele după cum este necesar ca răspuns la probleme sau fluctuații de încărcare.
Kubernetes în sine s-a născut din inițiativa Google GIFEE („Infrastructura Google pentru toată lumea”) și a fost concepută pentru a fi o versiune mai prietenoasă a lui Borg, care ar putea fi utilă în afara Google. A fost donat Fundației Linux în 2015 prin formarea Fundației Cloud Native Computing (CNCF).
Kubernetes oferă un sistem prin care „declarați” aplicațiile și serviciile dvs. containerizate și asigură că aplicațiile dvs. rulează în conformitate cu aceste declarații. Dacă programele dvs. necesită resurse externe, cum ar fi stocarea sau echilibrarea încărcării, Kubernetes le poate aproviziona automat. Vă poate scala aplicațiile în sus sau în jos pentru a ține pasul cu schimbările de încărcare și poate chiar scala întregul cluster atunci când este necesar. Componentele programului dvs. nici măcar nu trebuie să știe unde rulează: Kubernetes oferă servicii de denumire interne aplicațiilor, astfel încât să se poată conecta la „wp_mysql” și să fie conectate automat la resursa corectă. '
Rezultatul final este o platformă care poate fi utilizată pentru a vă rula aplicațiile pe orice infrastructură, de la o singură mașină printr-un rack local de sisteme până la flote de mașini virtuale bazate pe cloud care rulează pe orice furnizor major de cloud, toate folosind aceleași containere și configurație. Kubernetes este furnizor-agnostic: rulați-l oriunde doriți.
Kubernetes este un instrument puternic și este neapărat complex. Înainte de a intra într-o imagine de ansamblu, trebuie să introducem câțiva termeni folosiți în Kubernetes. Containerele rulează aplicații unice, după cum sa discutat mai sus, și sunt grupate în pod-uri. Un pod este un grup de containere strâns legate care sunt desfășurate împreună pe aceeași gazdă și partajează unele resurse. Containerele dintr-un pod funcționează ca o echipă: vor îndeplini funcții conexe, cum ar fi un container pentru aplicație și un container pentru înregistrare cu setări specifice pentru aplicație.
Patru componente cheie Kubernetes sunt API Server, Scheduler, Controller Manager și o bază de date de configurație distribuită numită etcd. Serverul API se află în centrul Kubernetes și acționează ca punct final final pentru toate cererile de gestionare. Acestea pot fi generate de o varietate de surse, inclusiv de alte componente Kubernetes, cum ar fi programatorul, administratorii prin linie de comandă sau tablouri de bord web și aplicațiile containerizate în sine. Validează cererile și actualizează datele stocate în etcd.
Programatorul determină ce noduri vor rula diferitele pod-uri, ținând cont de constrângeri, cum ar fi cerințele de resurse, orice constrângeri hardware sau software, sarcina de lucru, termenele și multe altele.
Controler Manager monitorizează starea clusterului și va încerca să pornească sau să oprească pod-urile în mod necesar, prin intermediul serverului API, pentru a aduce clusterul în starea dorită. De asemenea, gestionează unele conexiuni interne și caracteristici de securitate.
Fiecare nod rulează un proces Kubelet, care comunică cu serverul API și gestionează containerele - în general folosind Docker - și Kube-Proxy, care gestionează proxy-ul de rețea și echilibrarea încărcării în cadrul clusterului.
Sistemul de baze de date distribuite etcd își derivă numele din / etc folder pe sistemele Linux, care este utilizat pentru a păstra informațiile de configurare a sistemului, plus sufixul „d”, adesea folosit pentru a denumi un proces demon. Obiectivele etcd sunt stocarea datelor cheie-valoare într-un mod distribuit, consecvent și tolerant la erori.
Serverul API își păstrează toate datele de stare în etcd și poate rula simultan multe instanțe. Managerul de planificare și controler poate avea o singură instanță activă, dar folosește un sistem de leasing pentru a determina care instanță rulează master. Toate acestea înseamnă că Kubernetes poate rula ca un sistem extrem de disponibil, fără puncte unice de eșec.
Punând totul împreună
Deci, cum folosim aceste componente în practică? Ceea ce urmează este un exemplu de configurare a unui site web WordPress utilizând Kubernetes. Dacă ați dori să faceți acest lucru pe bune, probabil că ați folosi probabil o rețetă predefinită numită grafic de cârmă. Acestea sunt disponibile pentru o serie de aplicații obișnuite, dar aici vom analiza câțiva pași necesari pentru ca un site WordPress să funcționeze pe Kubernetes.
Prima sarcină este de a defini o parolă pentru MySQL:
kubectl creează secret secret mysql-pass --from-literal = parola = YOUR_PASSWORD
kubectl va vorbi cu serverul API, care va valida comanda și apoi va stoca parola în etcd. Serviciile noastre sunt definite în fișiere YAML, iar acum avem nevoie de ceva stocare persistentă pentru baza de date MySQL.
apiVersion: v1 kind: PersistentVolumeClaim metadate: nume: mysql-pv-claim labels: app: wordpress spec: accessModes: - ReadWriteOnce resurse: solicitări: stocare: 20Gi
Specificațiile ar trebui să fie în mare parte auto-explicative. Numele și câmpurile de etichete sunt folosite pentru a face referire la această stocare din alte părți ale Kubernetes, în acest caz containerul nostru WordPress.
După ce am definit spațiul de stocare, putem defini o instanță MySQL, arătând-o către spațiul de stocare predefinit. Aceasta este urmată de definirea bazei de date în sine. Oferim acelei baze de date un nume și o etichetă pentru o referință ușoară în Kubernetes.
Acum avem nevoie de un alt container pentru a rula WordPress. O parte din specificația de implementare a containerului este:
gen: Metadate de implementare: nume: etichete wordpress: aplicație: specificații wordpress: strategie: tip: Recreați
Tipul de strategie „Recreate” înseamnă că, dacă se modifică oricare dintre codurile care conțin aplicația, instanțele care rulează vor fi șterse și recreate. Alte opțiuni includ posibilitatea de a cicla instanțe noi și de a elimina instanțele existente, una câte una, permițând serviciului să ruleze în continuare în timpul implementării unei actualizări. În cele din urmă, declarăm un serviciu pentru WordPress în sine, care cuprinde codul PHP și Apache. O parte din fișierul YAML care declară acest lucru este:
metadate: nume: etichete wordpress: app: specificații wordpress: porturi: - port: 80 selector: app: nivel wordpress: tip frontend: LoadBalancer
Rețineți ultima linie, definind tipul de serviciu ca LoadBalancer. Acest lucru îi instruiește pe Kubernetes să facă serviciul disponibil în afara Kubernetes. Fără această linie, acesta ar fi doar un serviciu intern „numai Kubernetes”. Si asta e. Kubernetes va folosi acum acele fișiere YAML ca o declarație a ceea ce este necesar și va configura pod-uri, conexiuni, stocare și așa mai departe, după cum este necesar, pentru a aduce clusterul în starea „dorită”.
Aceasta a fost în mod necesar doar o imagine de ansamblu la nivel înalt a Kubernetes și multe detalii și caracteristici ale sistemului au fost omise. Am analizat autoscalarea (atât pod-urile, cât și nodurile care alcătuiesc un cluster), joburile cron (pornirea containerelor conform unui program), Ingress (echilibrarea încărcării HTTP, rescrierea și descărcarea SSL), RBAC (controale de acces bazate pe roluri) , politici de rețea (firewall) și multe altele. Kubernetes este extrem de flexibil și extrem de puternic: pentru orice nouă infrastructură IT, trebuie să fie un concurent serios.
Resurse
Dacă nu sunteți familiarizat cu Docker, începeți aici: https://docs.docker.com/get-started.
Există un tutorial interactiv despre implementarea și scalarea unei aplicații aici: https://kubernetes.io/docs/tutorials/kubernetes-basics.
Și consultați https://kubernetes.io/docs/setup/scratch pentru cum să construiți un cluster.
Puteți juca cu un cluster Kubernetes gratuit la https://tryk8s.com.
În cele din urmă, puteți analiza o lucrare tehnică lungă, cu o imagine de ansamblu excelentă asupra utilizării de către Borg a Google și a modului în care aceasta a influențat designul Kubernetes aici: https://storage.googleapis.com/pub-tools-public-publication-data/ pdf / 43438.pdf.
Aflați mai multe despre Tiger Computing.
- Cel mai bun stocare cloud din 2022-2023 online: opțiuni gratuite, plătite și de afaceri
Îți place ce citești? Vrei mai mult Linux și open source? Putem livra, literalmente! Abonați-vă astăzi la Linux Format la un preț redus. Puteți obține ediții tipărite, ediții digitale sau de ce nu ambele? Livrăm la ușa dvs. în întreaga lume pentru o taxă anuală simplă. Deci, faceți-vă viața mai bună și mai ușoară, abonați-vă acum!