Puncte:0

Atribuiți un IP public static pentru un pod în kubernetes și specificați în service

drapel cn

Conform Legătură , putem crea pod-uri cu mai multe rețele, dacă aplicația deschide un port cu o rețea non-implicit (eth2,3 etc) Cum o putem expune ca serviciu? În serviciul yaml, nu găsesc nicio modalitate de a expune serviciul în afară de implicit.

Puncte:1
drapel hk
SYN

Multus vă permite să atașați dispozitive de rețea la podurile dvs., deși ar trebui să rețineți că aceste interfețe nu fac parte din SDN-ul nostru cluster Kubernetes.

Cu dispozitive bazate pe Multus: ați aloca IP-uri podurilor dvs., fie folosind DHCP, IP-uri statice, ... în funcție de dvs. Ținând cont că acele adrese sunt independente de SDN-ul tău Kubernetes.

Dacă alți containere din acel cluster trebuie să conecteze acele puncte finale, atunci traficul lor ar trebui să părăsească SDN-ul dvs., trecând prin gateway-ul lor implicit obișnuit, care, la rândul său, ar trebui să aibă cunoștințe despre (ruta către) subrețelele dvs. de adrese Multus.

Cu toate acestea, puteți crea în continuare Servicii, desemnând adrese din SDN-ul dvs. Acest lucru se va realiza prin crearea unui obiect Endpoints, alături de Serviciul dvs., cum ar fi:

---
apiVersion: v1
fel: puncte finale
metadate:
  nume: svc-out-sdn
  spatiu de nume: ns
subseturi:
- adrese:
  - ip: 10.0.0.1
  porturi:
  - nume: tcp-80
    port: 80
    protocol: TCP
---
apiVersion: v1
fel: Serviciu
metadate:
  nume: svc-out-sdn
  spatiu de nume: ns
specificație:
  clusterIP: Niciunul
  porturi:
  - nume: tcp-80
    port: 80
drapel cn
Dacă specificăm în mod explicit EP, atunci dacă un pod nu mai funcționează, IP-ul va fi returnat până când îl actualizăm manual corect?
drapel cn
De asemenea, atunci când serviciul este creat, va avea în continuare clusterIP care este interfața principală?
SYN avatar
drapel hk
SYN
1/ corect. până la client să repete peste IP-urile returnate prin rezoluția DNS, în cazul în care unul dintre ele eșuează.2/ ar putea fi, iar apoi firewall-ul nodurilor tale ar fi redirecționat acel serviciu IP către adresele backend-urilor reale: dar aici, `spec.clusterIP=None` asigură că niciun IP de serviciu nu va fi alocat => DNS-ul intern va reveni cu punctul final adresele backend în schimb.
drapel cn
Cred că aceasta nu poate fi o soluție, dar totuși aceasta este o soluție posibilă, de ce nu poate fi o soluție, deoarece pod-urile pot merge în sus/jos și ar avea nevoie de o aplicație pentru a gestiona eroarea atunci când sunt folosite ip-urile doborâte.
SYN avatar
drapel hk
SYN
Ați lua în considerare configurarea unui LoadBalancer între ele? Poate și în Kubernetes? Un haproxy care efectuează verificări de sănătate TCP (sau orice altceva, verificările haproxy sunt destul de modulare) către adresele tale finale reale și fac ca Serviciul/clienții să indice acel LB?
drapel cn
LB este ceea ce am acum, dar problema este că necesită intervenție manuală atunci când sunt adăugate noduri noi. Deci, scalarea automată este problema.

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.