Configurez etcd pentru a bootstrap folosind descoperirea DNS, dar spune că serverul este configurat greșit și pare să interogă portul greșit, iar înregistrările SRV nu par corecte.
Vă rog, ați putea să revizuiți cele de mai jos și să vedeți întrebările mele în partea de jos a acestei postări?
Specificații
domeniu rădăcină: etcd.ksone
înregistrarea SRV a serverului:
_etcd-server-ssl._tcp.etcd.ksone SRV Simplu -
0 0 2380 etcd2.ksone
0 0 2380 etcd1.ksone
înregistrarea SRV a clientului:
_etcd-client-ssl._tcp.etcd.ksone SRV Simplu -
0 0 2379 etcd2.ksone
0 0 2379 etcd1.ksone
folosind TLS: Adevărat
OS:
[fedora@ip-10-0-0-245 ~]$ uname
Linux
[fedora@ip-10-0-0-245 ~]$ cat /etc/os-release
NAME=Fedora
VERSION="24 (douăzeci și patru)"
ID=fedora
VERSION_ID=24
PRETTY_NAME="Fedora 24 (douăzeci și patru)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:fedoraproject:fedora:24"
HOME_URL="https://fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=24
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=24
PRIVACY_POLICY_URL=https://fedoraproject.org/wiki/Legal:PrivacyPolicy
versiunea etcdctl
[fedora@ip-10-0-0-245 ~]$ etcdctl --version
etcdctl versiunea 2.2.5
Listează membrii
Încerc să listez membrii folosind comanda de mai jos și obțin următoarea eroare:
bash-4.3# etcdctl --ca-file /etc/etcd/ca.pem --key-file /etc/etcd/kubernetes-key.pem --cert-file /etc/etcd/kubernetes.pem --discovery- srv etcd.ksone --debug lista de membri
începeți să sincronizați clusterul folosind punctele finale (https://etcd1.ksone.:2380,https://etcd2.ksone.:2380)
Comanda cURL: curl -X GET https://etcd1.ksone.:2380/v2/members
am primit endpoints() după sincronizare
Puncte finale ale clusterului:
Comanda cURL: curl -X GET /v2/membri
client: clusterul etcd este indisponibil sau configurat greșit
Sănătatea clusterului
În mod similar, pot solicita cluster-health cu următoarea comandă și rezultat:
bash-4.3# etcdctl --ca-file /etc/etcd/ca.pem --key-file /etc/etcd/kubernetes-key.pem --cert-file /etc/etcd/kubernetes.pem --discovery- srv etcd.ksone --debug cluster-health
Puncte finale ale clusterului: https://etcd1.ksone.:2380, https://etcd2.ksone.:2380
===> NOTĂ: ÎNCERCĂ (IN CORECT?) PE PORTUL 2380 (SERVER) cURL Comanda: curl -X GET https://etcd1.ksone.:2380/v2/members
clusterul poate fi nesănătos: nu s-a putut enumera membrii
Eroare: cod de stare neașteptat 404
înregistrări SRV
Am configurat înregistrările SRV după cum urmează
- listează SRV pentru domeniul rădăcină, adică „etcd.ksone” (rezultatul așteptat --> ar trebui să arate înregistrările SRV complete, dar nu returnează nimic?):
dig +noall +answer SRV etcd.ksone
==> <consola nu arată nicio ieșire - goală!>
- listează SRV în mod explicit pentru server:
# dig +noall +answer SRV _etcd-server-ssl._tcp.etcd.ksone
_etcd-server-ssl._tcp.etcd.ksone. 33 IN SRV 0 0 2380 etcd2.ksone.
_etcd-server-ssl._tcp.etcd.ksone. 33 IN SRV 0 0 2380 etcd1.ksone.
- enumerați SRV în mod explicit pentru client:
/ # dig +noall +answer SRV _etcd-client-ssl._tcp.etcd.ksone
_etcd-client-ssl._tcp.etcd.ksone. 300 IN SRV 0 0 2379 etcd1.ksone.
_etcd-client-ssl._tcp.etcd.ksone. 300 IN SRV 0 0 2379 etcd2.ksone.
Încercați punctul final al clientului în mod explicit (SUCCES, dar nu folosiți cu adevărat descoperirea dns!)
bash-4.3# etcdctl --ca-file /etc/etcd/ca.pem --key-file /etc/etcd/kubernetes-key.pem --cert-file /etc/etcd/kubernetes.pem --debug - -endpoint https://etcd1.ksone:2379 cluster-health
Puncte finale ale clusterului: https://etcd1.ksone:2379
Comanda cURL: curl -X GET https://etcd1.ksone:2379/v2/members
membrul 499073e22ac73562 este sănătos: a primit un rezultat sănătos de la https://etcd1.ksone:2379
membrul b98d4fc780a787fe este sănătos: a primit un rezultat sănătos de la https://etcd2.ksone:2379
cluster este sănătos
etcd Service Setup
starea systemctl etcd
_ etcd.service - etcd
Încărcat: încărcat (/etc/systemd/system/etcd.service; activat; prestabilit furnizor: dezactivat)
Activ: activ (în rulare) din duminica 01-08-2021 07:17:39 UTC; acum 1h 23min
Documente: https://github.com/coreos
PID principal: 2363 (etcd)
Sarcini: 7 (limită: 512)
CGroup: /system.slice/etcd.service
__2363 /usr/bin/etcd --name etcd1.ksone --discovery-srv=etcd.ksone --initial-advertise-peer-urls https://etcd1.ksone:2380 --initial-cluster-token etcd-cluster -0 --initial-cluster-state new --advertise-client-urls https://etcd1.ksone:2379 --listen-client-urls https://etcd1.ksone:2379,http://127.0.0.1 :2379 --listen-peer-urls https://etcd1.ksone:2380 --data-dir=/var/lib/etcd/data --cert-file=/etc/etcd/kubernetes.pem --key- file=/etc/etcd/kubernetes-key.pem --peer-cert-file=/etc/etcd/kubernetes.pem --peer-key-file=/etc/etcd/kubernetes-key.pem --trusted- ca-file=/etc/etcd/ca.pem --peer-trusted-ca-file=/etc/etcd/ca.pem
Aug 01 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: 499073e22ac73562 a devenit candidat la termenul 41
Aug 01 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: 499073e22ac73562 a primit vot de la 499073e22ac73562 la termenul 41
Aug 01 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: 499073e22ac73562 [logterm: 1, index: 2] a trimis cerere de vot către b98d4fc780a787fe la termenul 417fe
Aug 01 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: 499073e22ac73562 a primit vot de la b98d4fc780a787fe la termenul 41
Aug 01 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: 499073e22ac73562 [q:2] a primit 2 voturi și 0 voturi respinse
Aug 01 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: 499073e22ac73562 a devenit lider la termenul 41
Aug 01 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: raft.node: 499073e22ac73562 lider ales 499073e22ac73562 la mandatul 41
01 august 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: publicat {Name:etcd1.ksone ClientURLs:[https://etcd1.ksone:2379 ]} pentru a cluster 1c370848b4697ef2
01 august 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: configurarea versiunii inițiale a clusterului la 2.2
01 august 07:18:32 ip-10-0-0-245.eu-west-1.compute.internal etcd[2363]: setați versiunea inițială a clusterului la 2.2
Rezumatul observațiilor
- Mecanismul de descoperire de pe clientul etcd nu pare să funcționeze, așa cum demonstrează eroarea de mai sus, adică
clusterul este indisponibil sau configurat greșit sau ``Eroare: cod de stare neașteptat 404```.
- Jurnalele de depanare par să indice că încearcă să se conecteze la portul peer, adică 2380, în loc de portul client, adică 2379.
- Pot să-l fac să funcționeze numai setând în mod explicit comutatorul punctului final la portul 2379
- Interogarea SRV pe domeniul rădăcină nu pare să funcționeze corect, adică returnează un rezultat necompletat (nicio ieșire)
starea systemctl etcd pare să indice că punctul final a fost configurat corect pentru comanda de pornire etcd.
Întrebări
- Cum interog corect înregistrările și care ar putea fi problemele (dacă există) cu configurația dns SRV?
- De ce este etcdctl
--descoperire-srv comutatorul nu funcționează - mă aștept să descopere portul corect, adică 2379 și să nu raporteze erori.
- Etcd ar trebui să fie echilibrat de sarcină? Există un singur punct final pe care îl pot interoga? [De ce] depinde de client să aleagă un punct final? Ar trebui să configurez un echilibrator de încărcare deasupra platformei mele etcd?
Mulţumesc mult!
