Puncte:0

HA în clusterul k8s în cazul eșecului nodului indicat de înregistrarea A a domeniului

drapel cn

Am o întrebare de tipul „ce-ar fi dacă”.

Să presupunem că există un cluster Kubernetes cu 4 noduri și un domeniu care indică IP-ul nodului nr. 1 și aplicația web care utilizează acest domeniu având 1 pod per nod. Dacă nodul 1 va eșua, atunci în starea actuală a cunoștințelor mele, aplicația va eșua deoarece O înregistrare indică acel nod care este rupt

Cum poate fi rezolvată menținerea mediului HA?

Puncte:1
drapel in

Aceasta este problema că a Serviciu este conceput pentru a rezolva, iar dacă vă aflați într-un mediu cloud (sau altfel aveți un operator care va furniza ceva care arata ca un echilibrator de sarcină), atunci tip: LoadBalancer va furniza un punct de intrare stabil din exteriorul clusterului în interiorul clusterului, iar apoi kubernetes va direcționa în jurul eșecului nodului respectiv.

Sub cuverturi, tip: LoadBalancer este doar lipici între tip: NodePort și echilibrul de încărcare, deci chiar dacă nu aveți la dispoziție un mecanism formal de echilibrare a încărcăturii, folosind tip: NodePort și o copie a haproxy arătată spre fiecare Nodul din clusterul dvs. va face un drum lung în abordarea riscului dvs

drapel cn
Deci echilibrul de sarcină va fi un singur punct de eșec și în acest caz, nu? în cazul în care este offline, cineva va trebui să schimbe o înregistrare pentru a atenua acest eșec? sau poate există o opțiune de a face automat ca „în caz de eșec nod/LB1 punct de domeniu la nod/LB2” multumesc si eu pentru raspuns :)
drapel in
Heh, sunt țestoase până jos! Dar, serios, _intotdeauna_ va fi un punct de eșec, dar fără să știi mai multe despre mediul tău și despre modurile în care ai reduce un astfel de risc _din afara_ de kubernetes, este greu să oferi sfaturi concrete despre cum să reduceți riscul _cu_ kubernetes . Știu că unii oameni „bare metal” folosesc IPVS+haproxy, alții au echipamente de rețea de lux care rezolvă aceeași problemă, iar alții folosesc literalmente haproxy doar cu DNS R-R pe mașinile haproxy. Dar pentru a reveni la întrebarea inițială, nu, publicarea IP-urilor Node este întotdeauna proastă
Puncte:0
drapel ci

Multumesc mdaniel pentru clarificare!

De asemenea, am găsit link-uri utile pentru a explora mai adânc

Este posibil să faceți redundanță pe serverul HAProxy?

Cum se configurează HAProxy cu failover?

De asemenea, este o idee bună să verificați subiecte precum ip flotant, keepalived și, dacă furnizorul dvs. are API pentru schimbarea destinației IP-ului plutitor aici pe digitalocean, puteți verifica cum se face https://www.digitalocean.com/community/tutorials/how-to-set-up-highly-available-haproxy-servers-with-keepalived-and-floating-ips-on-ubuntu-14-04

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.