Rețea Kubernetes: un ghid complet pentru înțelegerea modelului de rețea

Managementul containerelor este un aspect vital al rețelei. Odată cu cerințele de trafic în schimbare de astăzi, importanța Kubernetes a crescut de zece ori. Și dacă sunteți interesat să aflați despre rețele, va trebui mai întâi să vă familiarizați cu Kubernetes. Aflarea despre Kubernetes vă va ajuta să gestionați eficient gestionarea containerelor. Kubernetes este, de asemenea, unul dintre instrumentele DevOps de top de pe piață pentru 2020.

Dar nu vă faceți griji pentru că, în acest ghid detaliat, vom discuta despre același lucru. Kubernetes este un instrument de gestionare a containerelor și, în acest articol, veți afla de ce este utilizat, care sunt componentele rețelei sale și cum direcționează traficul.

Învață Inginerie software online de la cele mai bune universități din lume. Câștigă programe Executive PG, programe avansate de certificat sau programe de master pentru a-ți accelera cariera.

Să ne scufundăm.

Ce este Kubernetes?

Înainte de a începe să discutăm despre rețele în Kubernetes, trebuie să luăm în considerare conceptele de bază ale acestui instrument. În acest fel, nu vă veți confrunta cu confuzie mai târziu în articol și nu veți avea o înțelegere de bază a tot ceea ce este menționat aici.

Kubernetes este un instrument open-source de orchestrare a containerelor. Vă ajută să gestionați containerele, care au devenit cel mai critic aspect al rețelei în aceste zile. Kubernetes are multe funcții, inclusiv scalarea containerelor, implementarea containerelor, detartrarea containerelor etc.

În timp ce Docker îi ajută pe profesioniști cu crearea de containere, Kubernetes îi ajută să gestioneze același container. De aceea, ambele sunt atât de importante. Kubernetes rulează un sistem distribuit pe un cluster. Înțelegerea structurii și a rețelei sale vă va permite să evitați greșelile și să gestionați containerele fără erori.

De ce se folosește Kubernetes?

Cerințele de containere ale companiilor au crescut considerabil în ultimii ani. Dacă nu sunt prea mici, nu se pot baza pe unul sau două containere. Ar trebui să aibă un set mare de containere pentru echilibrarea încărcăturii. Cerința ar putea fi în sute pentru a menține o disponibilitate ridicată și pentru a echilibra traficul.

Când traficul ar crește, ar avea nevoie de mai multe containere pentru tratarea cererilor. În mod similar, atunci când traficul ar fi mai mic, vor trebui să reducă containerele. Gestionarea containerelor în funcție de cerere poate fi o provocare, mai ales dacă o faci manual.

Orchestrarea manuală a containerelor poate dura mult timp și resurse, care ar fi fost cheltuite cu ușurință în altă parte. Automatizarea acestei sarcini face lucrurile mult mai simple. Atunci nu ar trebui să vă faceți griji cu privire la detartrarea și detartrarea recipientelor. Asta face Kubernetes. Citiți cum să creați proiecte DevOps pentru începători cu ajutorul Kubernetes în articolul nostru de top proiecte DevOps pentru începători.

Automatizează orchestrarea și gestionarea containerelor. Este foarte popular datorită funcționalității sale. Este un produs Google, iar performanța sa ajută organizațiile în mod considerabil în automatizarea dimensionării containerelor.

Componentele Kubernetes

Acum că știți ce este Kubernetes și care sunt funcțiile sale, putem începe să discutăm despre multiplele sale componente. Puteți înțelege rețelele în acest instrument numai după ce vă familiarizați cu diferitele sale părți. Nu există prea multe de ce să vă faceți griji, totuși. Asta pentru că suntem aici să ajutăm. În continuare este o scurtă descriere a diferitelor sale componente. Deși descrierea este concisă, ar trebui să fie suficientă pentru a vă oferi o idee generală.

Păstăi

Îți amintești de atomii din chimie, cele mai mici obiecte independente ale materiei? Ei bine, Pod-urile sunt atomii Kubernetes. One Pod este o sarcină de lucru într-un cluster. Poate conține unul sau mai multe recipiente cu depozitare. Fiecare Pod are o adresă IP unică care acționează ca identitate atunci când interacționează cu alte componente ale Kubernetes. Toate containerele unui pod sunt programate și amplasate în cadrul aceleiași mașini.

Controlori

Controlorii construiesc Kubernetes. Controlorii urmăresc starea serverului API pentru a se asigura că starea lui actuală se potrivește cu starea pe care ați specificat-o. Dacă starea serverului API se modifică dintr-un motiv oarecare, acesta reacționează în consecință. Controllerele folosesc o buclă pentru a verifica stările clusterelor și pentru a le compara cu stările necesare. De asemenea, poate efectua sarcini pentru a schimba starea curentă în starea necesară.

Noduri

Dacă Pod-urile sunt atomii, Nodurile sunt angrenajele Kubernetes. Ei conduc clusterul. Mașinile virtuale sunt noduri accesibile în clusterele Kubernetes. Mulți oameni tind să folosească cuvântul „gazdă” în loc de „nod”. Am încercat să folosim în mod consecvent termenul noduri în acest articol.

Server API

Serverul API este poarta de acces către depozitul de date din Kubernetes. Vă permite să specificați starea dorită pentru clustere. Va trebui să efectuați apeluri API dacă doriți să schimbați starea clusterului dvs. Kubernetes și să descrieți starea necesară.

Deoarece sunteți familiarizat cu componentele rețelei Kubernetes, putem începe cu modelul său de rețea și cum funcționează.

Rețeaua Kubernetes explicată

Rețelele Kubernetes urmează un model specific care are următoarele constrângeri:

• Podurile comunică cu toate celelalte poduri fără traducerea adresei de rețea
• Nods pot comunica cu Pod-urile fără traducerea adresei de rețea
• IP-ul unui Pod pe care îl văd alte Pod-uri este același IP pe care îl vede singur

Datorită acestor restricții, Kubernetes are doar câteva secțiuni de rețea. Sunt:

• Transferuri container la container
• Transferuri pod la pod
• Pod la transferuri de servicii
• Internet pentru servicii de transferuri

Container la Container

S-ar putea să credeți că în rețea, o mașină virtuală interacționează direct cu un dispozitiv ethernet, dar există mai mult decât atât.

Dacă utilizați Linux, spațiul de nume de rețea vă va oferi o stivă de rețea care are dispozitivele sale de rețea, rutele și regulile pentru firewall. Fiecare proces care rulează în Linux ar comunica cu acest spațiu de nume de rețea.

Un Pod posedă un grup de containere într-un spațiu de nume de rețea. Aceste containere au același spațiu de port și adresă IP, care le este atribuită prin spațiul de nume de rețea. Aceste containere se găsesc între ele prin localhost, deoarece sunt localizate în același spațiu de nume. Dacă aplicațiile dvs. se află într-un pod, ele pot accesa și volumele partajate.

Pod la Pod

Pod-urile comunică între ele prin adresele lor IP. Fiecare Pod are o adresă IP reală și distinctă în Kubernetes. Știți deja ce sunt Pod-urile, așa că nu trebuie să atingem acest subiect. Știm că Kubernetes folosește IP-uri pentru a facilita comunicarea între poduri; hai sa discutam cum face asta.

Podurile comunică prin nodurile lor. De aceea, pentru a înțelege comunicarea Pod cu pod și va trebui să înțelegeți interacțiunea dintre noduri.

• Comunicare între noduri
• Comunicare intra nod

Vom discuta pe fiecare dintre ele în detaliu:

Comunicare între noduri

Când nodurile sunt situate în diferite poduri, ele vor comunica prin această metodă. Putem înțelege această metodă de comunicare printr-un exemplu ușor. Să presupunem că există patru rețele diferite de pod, și anume pod 1, pod 2, pod 3 și așa mai departe. Podurile 1 și 2 sunt situate în rețeaua rădăcină a Nodului 1, iar podurile 3 și 4 sunt situate în a doua rețea.

Trebuie să transferați un pachet de la pod 1 la pod 4.

Pachetul trebuie mai întâi să părăsească rețeaua pod 1 și să intre în rețeaua rădăcină prin veth0. Trece prin puntea Linux, ceea ce îl ajută să-și găsească destinația. Deoarece nodul nu are un scop în Podul său, este trimis înapoi la interfața eth0. Acum părăsește primul nod pentru tabelul de rute. Tabelul de rute direcționează pachetul către nodul necesar, care este situat în pod4. Pachetul ajunge mai întâi la nodul 2, apoi ajunge la punte, care îl direcționează către destinație.

Comunicare intra nod

Comunicarea Intra Node are loc atunci când nodurile sunt situate în același Pod. Putem explica comunicarea intra-nod în același mod în care am explicat comunicarea inter-nod. În aceste cazuri, pachetul călătorește de la primul Pod la eth0. Intră în rețeaua rădăcină prin veth0. Apoi trebuie să treacă pe pod după care, merge la IP-ul desemnat.

Așa comunică podurile între ele în Kubernetes. Să trecem la următoarea secțiune.

Pod la service

Ați văzut deja în secțiunea anterioară cum este direcționat traficul între adresele IP ale podurilor. Cu toate acestea, există o problemă cu adresele IP. IP-urile podului pot dispărea și reapărea în funcție de scalarea containerelor. Deci, dacă containerele sunt scalate, numărul de IP-uri de pod va crește, este și invers.

Serviciile ajută în gestionarea acestei situații. Iată o scurtă explicație a serviciilor în Kubernetes, astfel încât să nu aveți nicio confuzie.

Ce sunt serviciile în Kubernetes?

Serviciile din Kubernetes configurează proxy-uri care trebuie să transfere cereri către un grup de pod-uri. Aceste poduri primesc trafic, iar selectorul se ocupă de această sarcină. După crearea unui serviciu, acesta primește o adresă IP care se ocupă de solicitările sale. Există mai multe tipuri de servicii și trebuie să le discutăm înainte de a trece la comunicarea Pod pentru servicii.

Există un total de 4 tipuri de servicii în Kubernetes. Sunt:

• ClusterIP
• NodePort
• Echilibrarea greutății
• ExternalName

ClusterIP este tipul de serviciu implicit. În acest tip, serviciul este accesibil doar în cluster. În NodePort, serviciul este expus la IP-ul fiecărui nod. NodePort rutează către un serviciu ClusterIP pe măsură ce sistemul îl creează în prealabil. Spre deosebire de ClusterIP, puteți contacta acest serviciu în afara unui cluster.

LoadBalancer folosește echilibrul de încărcare al unui nor pentru a expune serviciul rețelelor externe. NodePort și ClusterIP sunt create automat datorită acestuia, iar serviciul ExternalName le transferă deoarece reflectă o înregistrare CNAME.

Acum că știți ce sunt serviciile și câte tipuri de servicii există, să discutăm despre modul în care are loc comunicarea Pod la service.

Cum functioneaza?

În acest scenariu, pachetul părăsește Pod prin eth0. Merge la bridge prin dispozitivul Ethernet de unde este transferat pe ruta implicită a eth0. Cu toate acestea, trebuie să treacă prin iptables înainte de a fi acceptat la eth0. iptables determină destinația pachetului folosind regulile specificate pe care le are și trimite pachetul la Podul necesar. Odată ce a făcut acest lucru, pachetul merge la IP-ul real al unui pod în loc de IP-ul virtual al serviciului.

Extern la Service

Cele trei metode anterioare de rutare a traficului se refereau numai la Kubernetes. Dar, în cazuri reale, sunt șanse ca va trebui să vă conectați rețeaua Kubernetes la o rețea terță parte pentru rutarea traficului. Și această secțiune este cam aceeași.

Când este conectat la o rețea externă, Kubernetes poate îndeplini două funcții:

• Dirijați traficul de pe internet către rețeaua acestuia
• Dirijați traficul din rețeaua sa către internet

Primul necesită o rețea Ingress, iar cel de-al doilea necesită o rețea Egress. Să aruncăm o privire la ele.

Intrare

Dirijarea traficului de la o rețea publică către sistemul Kubernetes este foarte dificilă. Este necesar ca LoadBalancer și Controller să gestioneze pachetele. Iată un exemplu despre cum funcționează.

Mai întâi, veți implementa un serviciu, iar furnizorul dvs. de cloud va crea un nou echilibrator de încărcare. Echilibratorul de încărcare va distribui traficul pe mașinile virtuale din clusterul dvs. utilizând portul desemnat al serviciului dvs. Aici, iptables transferă traficul pe care îl primesc de la echilibrul de încărcare la Podul necesar. Pod-ul va răspunde clientului cu IP-ul său, iar conntrack ajută la rescrierea IP-urilor în mod corect.

Echilibratoarele de încărcare Layer-7 prezente în rețea sunt capabile să segmenteze traficul de intrare în funcție de URL-uri și căi. Acest lucru este foarte util atunci când lucrați cu o rețea Ingress.

Ieşire

Când direcționați traficul de la un nod al rețelei dvs. Kubernetes către internet, depinde foarte mult de configurațiile rețelei dvs. cu privire la modul în care ar funcționa totul. Vom discuta aici un exemplu general pentru a atinge subiectul.

Pachetul începe de la spațiul de nume al Podului și merge la spațiul de nume rădăcină prin veth. Apoi merge la bridge de unde călătorește la serviciul implicit, deoarece IP-ul la care trebuie să meargă nu este în legătură cu bridge-ul. Trece prin iptables în timp ce merge la spațiul de nume rădăcină.

Citiți: Condiție prealabilă pentru DevOps: Nu este ceea ce credeți că este

Acum gateway-urile de internet acceptă numai adrese IP care sunt în legătură cu mașinile virtuale. Și podul sursă al buzunarului nostru nu este conectat la un VM. Deci iptables fac un NAT sursă și schimbă sursa pachetului. Acum ajunge la gateway-ul de internet unde trece printr-un alt NAT și apoi intră în internetul public (destinația acestuia).

Și asta este. Acum știți totul despre rețelele Kubernetes și despre diferitele sale componente.

Concluzie

Kubernetes este, fără îndoială, unul dintre instrumentele esențiale pe care ar trebui să le înveți dacă ești interesat de rețele. Cei care nu sunt familiarizați cu acest domeniu nu ar ști cât de vital este el. Gestionarea containerelor și direcționarea traficului în conformitate cu aceste cerințe de trafic vă poate ajuta considerabil. Am încercat să păstrăm acest ghid cât mai clar posibil pentru a vă ajuta să înțelegeți totul.

Dacă doriți să învățați și să stăpâniți Kubernetes, DevOps și multe altele, consultați Programul Executive PG de la IIIT-B și upGrad în Dezvoltare Software - Specializare în Dezvoltare Full Stack.