În blogul anterior de pe , trebuie să fi înțeles despre Kubernetes. În acest blog despre rețeaua Kubernetes, mă voi concentra în primul rând pe conceptele de rețea implicate în Kubernetes.
În acest blog despre rețeaua Kubernetes, veți înțelege următoarele subiecte:
Ce este Kubernetes?
Puteți defini Kubernetes ca un instrument open-source de orchestrare a containerelor care oferă o platformă portabilă pentru automatizarea implementării aplicațiilor containerizate.
Acum, oricine lucrează cu Kubernetes trebuie să aibă o înțelegere clară a clusterului Kubernetes, deoarece acest lucru vă va ajuta să înțelegeți rețeaua Kubernetes.
Clusterul Kubernetes
Platforma Kubernetes oferă o gestionare a stării dorită, care permite serviciilor de cluster să ruleze, configurația alimentată în infrastructură. Lasă-mă să explic cu un exemplu.
Luați în considerare un fișier YAML care conține toate informațiile de configurare care trebuie introduse în serviciile cluster. Deci, acest fișier este alimentat către API-ul serviciilor de cluster, iar apoi va reveni serviciilor de cluster să descopere cum să programeze pod-uri în mediu. Deci, să presupunem că există două imagini de container pentru podul 1 cu trei replici și o imagine de container pentru podul 2 cu două replici, va reveni serviciilor cluster să aloce aceste perechi pod-replică lucrătorilor.
diferite tipuri de cadru în seleniu
Consultați diagrama de mai sus. Acum, după cum puteți vedea, serviciile cluster au alocat primul lucrător cu două perechi de replici pod, al doilea lucrător cu o singură pereche pod-replică și al treilea lucrător cu două perechi de replici pod. Acum, procesul Kubelet este responsabil pentru comunicarea serviciilor cluster cu lucrătorii.
Deci, toată această configurație de servicii de cluster și lucrătorii înșiși alcătuiesc acest lucru Clusterul Kubernetes !!
Cum, credeți că aceste păstăi alocate individual comunică între ele?
Răspunsul se află în rețeaua Kubernetes!
Abonați-vă la canalul nostru YouTube pentru a primi noi actualizări ..!
Există în principal 4 probleme de rezolvat cu conceptele de rețea.
- Comunicare container-container
- Comunicare Pod to Pod
- Pod pentru comunicarea de servicii
- Comunicare externă la serviciu
Acum, permiteți-mi să vă spun cum sunt rezolvate problemele de mai sus cu Kubernetes Networking.
Rețea Kubernetes
Comunicarea dintre pod-uri, servicii și servicii externe către cele dintr-un cluster aduce conceptul de rețea Kubernetes.
Deci, pentru o mai bună înțelegere, permiteți-mi să împart conceptele în cele ce urmează.
- Comunicare Pods & Container
- Servicii
- Conectarea externă la servicii prin rețeaua de intrare
Comunicare Pods & Container
Înainte de a vă spune cum comunică păstăile, permiteți-mi să vă prezint ce sunt păstăile?
Păstăi
Pod-urile sunt unități de bază ale aplicațiilor Kubernetes, care constă dintr-unul sau mai multe containere alocate pe aceeași gazdă pentru a partaja o stivă de rețea și alte resurse. Deci, acest lucru implică faptul că toate containerele dintr-un pod pot ajunge la altele de pe o gazdă locală.
Acum, permiteți-mi să vă informez despre cum comunică aceste păstăi?
Există 2 tipuri de comunicare. comunicare între noduri si comunicare intra-nod.
Deci, să începem cu comunicarea intra-nod, dar înainte de asta, permiteți-mi să vă prezint componentele rețelei de pod-uri.
Intra-nod Sub rețea
Rețeaua de poduri intra-nod este practic comunicarea între două noduri diferite pe același pod. Permiteți-mi să vă explic cu un exemplu.
Să presupunem că un pachet merge de la pod1 la pod2.
- Pachetul părăsește rețeaua Pod 1 la eth0 și intră în rețeaua rădăcină la veth0
- Apoi, pachetul trece pe podul Linux (cbr0) care descoperă destinația utilizând o cerere ARP
- Deci, dacă veth1 are IP-ul, podul știe acum de unde să redirecționeze pachetul.
Acum, în mod similar, permiteți-mi să vă spun despre comunicarea pod inter-nod.
Vrei să înveți Kubernetes?Inter-nod sub rețea
Luați în considerare două noduri care au diverse spații de nume de rețea, interfețe de rețea și o punte Linux.
Acum, să presupunem că un pachet se deplasează de la pod1 la pod4 care se află pe un alt nod.
- Pachetul părăsește rețeaua pod 1 și intră în rețeaua rădăcină la veth0
- Apoi pachetul trece la podul Linux (cbr0) a cărui responsabilitate este să facă o cerere ARP pentru a găsi destinația.
- După ce podul își dă seama că acest pod nu are adresa de destinație, pachetul revine la interfața principală de rețea eth0.
- Pachetul părăsește acum nodul 1 pentru a-și găsi destinația pe celălalt nod și intră în tabelul de rute care direcționează pachetul către nodul al cărui bloc CIDR conține pod4.
- Deci, acum pachetul ajunge la nodul 2 și apoi podul ia pachetul care face o cerere ARP pentru a afla că IP-ul aparține veth0.
- În cele din urmă, pachetul traversează perechea de țevi și ajunge la pod4.
Deci, așa comunică păstăile între ele. Acum, să mergem mai departe și să vedem cum ajută serviciile în comunicarea podurilor.
Deci, ce credeți că sunt serviciile?
Servicii
Practic, serviciile sunt un tip de resursă care configurează un proxy pentru a redirecționa cererile către un set de pod-uri, care vor primi trafic și este determinat de selector. Odată ce serviciul este creat, acesta are o adresă IP atribuită, care va accepta cererile din port.
Acum, există diferite tipuri de servicii care vă oferă opțiunea de a expune un serviciu în afara adresei IP a clusterului.
Tipuri de servicii
Există în principal 4 tipuri de servicii.
ClusterIP: Acesta este tipul de serviciu implicit care expune serviciul pe un IP intern al clusterului, făcând serviciul accesibil numai în cadrul clusterului.
NodePort: Aceasta expune serviciul pe IP-ul fiecărui nod la un port static. De când, a ClusterIP serviciul, către care va direcționa serviciul NodePort, este creat automat. Putem contacta serviciul NodePort în afara clusterului.
Echilibrarea greutății: Acesta este tipul de serviciu care expune serviciul extern utilizând echilibrul de încărcare al unui furnizor de cloud. Deci, serviciile NodePort și ClusterIP, către care va direcționa echilibrul de încărcare extern, sunt create automat.
Numele extern : Acest tip de serviciu mapează serviciul la conținutul fișierului externalName câmp prin returnarea unui CNAME înregistrare cu valoarea sa.
Așadar, băieți, totul era despre servicii. Acum, s-ar putea să vă întrebați cum se conectează serviciile externe la aceste rețele, nu?
Ei bine, nu este altceva decât Ingress Network .
Ingress Network
Ei bine, rețeaua de intrare este cel mai puternic mod de expunere a serviciilor, deoarece este o colecție de reguli care permit conexiuni de intrare, care pot fi configurate pentru a oferi servicii extern prin intermediul adreselor URL accesibile. Deci, acționează practic ca un punct de intrare în clusterul Kubernetes care gestionează accesul extern la serviciile dintr-un cluster.
Acum, permiteți-mi să vă explic funcționarea Ingress Network cu un exemplu.
Avem 2 noduri, având spațiile de nume ale rețelei pod și rădăcină cu un pod Linux. În plus, avem și un nou dispozitiv ethernet virtual numit flannel0 (plugin de rețea) adăugat la rețeaua rădăcină.
Acum, dorim ca pachetul să curgă de la pod1 la pod 4.
- Deci, pachetul părăsește rețeaua pod1 la eth0 și intră în rețeaua rădăcină la veth0.
- Apoi este trecut la cbr0, ceea ce face ca cererea ARP să găsească destinația și apoi află că nimeni de pe acest nod nu are adresa IP de destinație.
- Deci, podul trimite pachetul către flannel0 deoarece tabelul de rute al nodului este configurat cu flannel0.
- Acum, demonul de flanelă vorbește cu serverul API al Kubernetes pentru a cunoaște toate IP-urile podului și nodurile respective pentru a crea mapări pentru IP-urile podurilor către IP-urile nodurilor.
- Pluginul de rețea înfășoară acest pachet într-un pachet UDP cu anteturi suplimentare care schimbă sursa și destinația IP-urilor către nodurile lor respective și trimite acest pachet prin eth0.
- Acum, deoarece tabelul de rute știe deja cum să direcționeze traficul între noduri, acesta trimite pachetul către nodul de destinație2.
- Pachetul ajunge la eth0 al nodului2 și revine la flannel0 pentru a decapsula și îl emite înapoi în spațiul de nume al rețelei rădăcină.
- Din nou, pachetul este redirecționat către podul Linux pentru a face o cerere ARP pentru a afla adresa IP care aparține veth1.
- Pachetul traversează în cele din urmă rețeaua rădăcină și ajunge la destinația Pod4.
Deci, așa sunt conectate serviciile externe cu ajutorul unei rețele de intrare. Acum, în timp ce vorbeam despre pluginurile de rețea, permiteți-mi să vă prezint lista de pluginuri de rețea populare disponibile.
Acum, că v-am spus atât de multe despre Kubernetes Networking, permiteți-mi să vă arăt un studiu de caz din viața reală.
Studiu de caz: Wealth Wizard Utilizarea rețelei Kubernetes
Wealth Wizards este o platformă de planificare financiară online care combină planificarea financiară și tehnologia software inteligentă pentru a oferi consultanță de specialitate la un cost accesibil.
Provocări
Acum, a fost extrem de important pentru companie să descopere și să elimine rapid vulnerabilitățile codului cu o vizibilitate deplină a mediului lor cloud, dar a dorit să controleze traficul prin restricții de acces.
Așadar, au folosit infrastructura Kubernetes pentru a gestiona aprovizionarea și lansarea clusterelor cu ajutorul instrumentelor pentru gestionarea implementării și configurării microserviciilor prin intermediul clusterelor Kube.
De asemenea, au folosit o funcție de politică de rețea a Kubernetes pentru a le permite să controleze traficul prin restricții de acces.
Acum, problema a fost că aceste politici sunt orientate către aplicație și pot evolua doar odată cu aplicațiile, dar nu a existat nicio componentă care să aplice aceste politici.
Așadar, singura soluție pe care compania a putut să o găsească pentru aceasta a fost utilizarea unui plugin de rețea și, prin urmare, au început să folosească Weave Net.
Soluţie
Acest plugin de rețea creează o rețea virtuală care are un controler de politică de rețea pentru a gestiona și a aplica regulile din Kubernetes. Nu numai aceasta, ci conectează și containerele Docker între mai multe gazde și permite descoperirea automată a acestora.
Deci, să presupunem că aveți o sarcină de lucru în cluster și doriți să opriți orice altă sarcină de lucru din cluster vorbind cu acesta. Puteți realiza acest lucru creând o politică de rețea care restricționează accesul și permite accesul la acesta numai prin intermediul controlerului de intrare pe un anumit port.
Acum, odată cu implementarea sa pe fiecare nod Kubernetes, pluginul gestionează rutare inter-pod și are acces la manipularea regulilor IPtables. În termeni simpli, fiecare politică este convertită într-o colecție de reguli IPtables, coordonate și configurate pe fiecare mașină pentru a traduce etichetele Kubernetes.
Bine, acum că ați trecut prin atâta teorie despre rețeaua Kubernetes, permiteți-mi să vă arăt cum se face practic.
Implicat activ
Deci, presupunând că toți ați instalat Kubernetes pe sistemele dvs., am un scenariu de prezentat.
Să presupunem că doriți să stocați numele produsului și ID-ul produsului, pentru aceasta veți avea nevoie de o aplicație web. Practic, aveți nevoie de un container pentru aplicația web și aveți nevoie de încă un container ca MySQL pentru backend și acel container MySQL ar trebui să fie conectat la containerul aplicației web.
Ce zici să execut practic exemplul menționat mai sus.
Să începem!
Pasul 1: Creați un folder în directorul dorit și schimbați calea directorului de lucru în acel folder.
mkdir HandsOn cd HandsOn /
Pasul 2: Acum creați fișiere YAML de implementare, pentru aplicația web și baza de date MySQL.
Pasul 3: După ce creați fișierele de implementare, implementați ambele aplicații.
kubectl apply -f webapp.yml kubectl apply -f mysql.yml
Pasul 3.1: Verificați ambele implementări.
kubectl obține implementarea
Pasul 4: Acum, trebuie să creați servicii pentru ambele aplicații.
kubectl apply -f webservice.yml kubectl apply -f sqlservice.yml
Pasul 4.1: Odată ce serviciile sunt create, implementați serviciile.
Pasul 4.2: Verificați dacă serviciile au fost create sau nu.
kubectl obține servicii
Pasul 5: Acum, verificați configurația podurilor rulante.
kubectl obține păstăi
Pasul 6: Accesați containerul din interiorul podului webapp.
kubectl exec -it container_id bash nano var / www / html / index.php
Pasul 6.1 : Acum, schimbați $ servername de la localhost la numele serviciului SQL care este „ webapp-sql1 ”În acest caz și $ parola de la catre ' edureka ”. De asemenea, completați toate detaliile bazei de date necesare și salvați fișierul index.php utilizând comanda rapidă de la tastatură Ctrl + x și după aceea apăsați Da pentru a salva și apăsați introduce .
Pasul 7: Acum, intrați în containerul MySQL prezent în pod.
kubectl executați container_id bash
Pasul 7.1: Obțineți accesul pentru a utiliza containerul MySQL.
mysql -u root -p edureka
Unde -u reprezintă utilizatorul și -p este parola mașinii dvs.
Pasul 7.2: Creați o bază de date în MySQL care va fi utilizată pentru a obține date de pe webapp.
CREAȚI BAZA DE DATE Detalii produs
Pasul 7.3: Utilizați baza de date creată.
UTILIZARE Detalii produs
Pasul 7.4: Creați un tabel în această bază de date în MySQL care va fi utilizat pentru a obține date de pe webapp.
CREAȚI produse TABLE (nume_produs VARCHAR (10), product_id VARCHAR (11))
Pasul 7.5: Acum, ieșiți și din containerul MySQL folosind comanda Ieșire .
Pasul 8: Verificați numărul de port pe care funcționează aplicația dvs. web.
kubectl obține servicii
Pasul 8.1: Acum, deschideți aplicația web pe numărul de port alocat.
Pasul 9: După ce faceți clic pe Trimite interogarea , accesați nodul în care rulează serviciul dvs. MySQL și apoi intrați în container.
Aceasta vă va arăta rezultatul tuturor produselor din listă, despre care ați completat detaliile.
Vrei să înveți Kubernetes?Dacă ați găsit relevant acest blog Kubernetes Networking, consultați de Edureka, o companie de învățare online de încredere, cu o rețea de peste 250.000 de elevi mulțumiți răspândiți pe tot globul.