Puncte:1

Configurația clusterului ETCD pentru Kubernetes: care ar trebui luată în considerare?

drapel sz

Aș dori să știu cum să implementez un cluster ETCD pentru Kubernetes. Se pare că există două documente diferite și nu știu care trebuie luată în considerare sau impactul fiecăreia dintre ele.

De la Documentația Kubernetes pentru un multi-cluster etcd, a sugerat să-l porniți astfel

etcd --listen-client-urls=http://$IP1:2379,http://$IP2:2379,http://$IP3:2379,http://$IP4:2379,http://$ IP5:2379 --advertise-client-urls=http://$IP1:2379,http://$IP2:2379,http://$IP3:2379,http://$IP4:2379,http:/ /$IP5:2379

Aici --ascultă-client-urls-- are lista tuturor punctelor finale ETCD și același lucru pentru --advertise-client-urls iar din documentația Kubernetes acea comandă este rulată o singură dată.

De la documentația ETCD acea comandă trebuie să fie rulată în fiecare nod

$ etcd --name infra0 --initial-advertise-peer-urls https://10.0.1.10:2380 \
  --listen-peer-urls https://10.0.1.10:2380 \
  --listen-client-urls https://10.0.1.10:2379,https://127.0.0.1:2379 \
  --advertise-client-urls https://10.0.1.10:2379 \
  --initial-cluster-token etcd-cluster-1 \
  --initial-cluster infra0=https://10.0.1.10:2380,infra1=https://10.0.1.11:2380,infra2=https://10.0.1.12:2380 \
  --initial-cluster-state new \
  --client-cert-auth --trusted-ca-file=/path/to/ca-client.crt \
  --cert-file=/path/to/infra0-client.crt --key-file=/path/to/infra0-client.key \
  --peer-client-cert-auth --peer-trusted-ca-file=ca-peer.crt \
  --peer-cert-file=/path/to/infra0-peer.crt --peer-key-file=/path/to/infra0-peer.key

și putem observa că --ascultă-client-urls-- conțin doar adresa IP a nodului curent, iar ceilalți parametri nu sunt prezenți în documentația Kubernetes.

De ce sunt atât de diferiți? Ma puteti ajuta sa inteleg? Care este cel bun? Când trebuie folosit fiecare dintre ele?

Puncte:1
drapel in

Pe scurt, vă sugerez să urmați etcd documentație în ceea ce privește înființarea etcd cluster.


Cu mai multe cuvinte, să vedem mai întâi ce înseamnă aceste steaguri.

--listen-client-urls - acesta este un membruSteagul lui (relevant la nivelul nodului):

Listă de adrese URL pe care să le ascultați pentru traficul clienților. Acest steag spune etcd să accepte cererile primite de la clienți la termenul specificat scheme://IP:combinații de port. Schema poate fi http sau https. Dacă 0.0.0.0 este specificat ca IP, etcd ascultă portul dat pe toate interfețele. Dacă este dată o adresă IP precum și un port, etcd va ascultați pe portul și interfața date. Mai multe adrese URL pot fi folosite pentru specificați un număr de adrese și porturi pe care să ascultați. etcd va răspunde solicitărilor de la oricare dintre adresele și porturile enumerate.

etcd - listen clients url

--advertise-client-url - acesta este un cluster steag cu scop (se spune de la sine):

Lista adreselor URL ale clientului acestui membru pentru a face publicitate pentru restul cluster. Aceste adrese URL pot conține nume de domenii.

etcd - advertise-client-url

De asemenea, vă rugăm să găsiți o scurtă clarificare în Întrebări și răspunsuri - diferența dintre steaguri


Cât despre documentația kubernetes pe care ați distribuit-o, acest lucru nu pare logic pentru că etcd comanda ar trebui să ruleze pe fiecare dintre noduri, cu toate acestea, în acest exemplu, nu este clar cum vor obține aceste informații alte noduri.

De asemenea, o altă opțiune este pentru simplitate și pornire rapidă, au oferit astfel de configurații și etcd ar trebui să ignore IP-urile care nu sunt utilizate (de exemplu IP-urile altor noduri pe portul local pentru a asculta traficul clientului). Și nu ar trebui să fie rău dacă tot etcd nodurile pot face publicitate IP-urilor tuturor nodurilor.

in orice caz etcd documentele afirmă clar a începe etcd cu numai adresa locală pe fiecare nod - presupun că este modul corect.

Vă sugerez să vă referiți la configurarea clusterului. Acest document acoperă cum să configurați clusterul HA folosind kubeadm (probabil că nu este cel mai convenabil mod, totuși am reușit să-l configurez și să lucrez). După cum puteți vedea doar în acest exemplu etcd IP-ul nodului este prezentat în config care este aliniat cu etcd docs.

Link-uri utile:

Wytrzymały Wiktor avatar
drapel it
Bună @MaelElvisFosso și bine ați venit la ServerFoult! Vă rugăm să nu uitați să [reacționați la răspunsurile la întrebările dvs.](https://stackoverflow.com/help/someone-answers). În acest fel, știm dacă răspunsurile au fost utile și dacă alți membri ai comunității ar putea beneficia de ele. Încercați să [acceptați răspunsul](https://stackoverflow.com/help/accepted-answer) care este soluția finală pentru problema dvs., votați răspunsurile care sunt utile și comentați cele care ar putea fi îmbunătățite sau necesită o atenție suplimentară. Sedere placuta!
drapel sz
multumesc @moonkotte

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.