Informații necesare legate de serviciul kubernetes

Întrebarea mea este că, dacă un client să presupunem că kubectl trebuie să acceseze un cluster pentru diferite operații de obținere/ștergere/editare, folosește .kube/config fișier și acolo specificăm punctul final API ca intrare DNS. Mai jos este afișată intrarea noastră DNS pentru NLB.

$ cat config |grep 6443
server: https://ac1poc-20210407164708-kube-api-f5082ea18c7584ad.elb.us-east-1.amazonaws.com:6443

2. Și dacă kubelet trebuie să vorbească cu punctul final API, are o intrare similară în fișierul său de configurare /etc/kubernetes/kubelet
3. La fel și pentru kube-proxy. Deci, toate aceste trei API-uri externe au o intrare Network Load Balancer configurată în fișierele de configurare respective. Asta înseamnă că toate acestea trimit pachete către NLB ori de câte ori doresc să comunice cu backend-ul API.

Dar apoi am acest serviciu și așa cum se arată mai jos. Am vrut să întreb când intră în funcțiune acest serviciu. Care API folosește acest serviciu?

$ kubectl descrie svc kubernetes
Nume: kubernetes
Spațiu de nume: implicit
Etichete: component=apiserver
                   provider=kubernetes
Adnotări: <niciuna>
Selector: <niciun>
Tip: ClusterIP
Politica de familie IP: SingleStack
Familii IP: IPv4
IP: 10.96.0.1
IP-uri: 10.96.0.1
Port: https 443/TCP
TargetPort: 6443/TCP
Puncte finale: 172.36.11.131:6443,172.36.12.131:6443,172.36.13.131:6443
Afinitate sesiune: niciuna
Evenimente: <niciunul>

Întrebarea mea este că dacă un client să presupunem că kubectl trebuie să acceseze un cluster pentru diferite operații de obținere/ștergere/editare

2) Și dacă kubelet trebuie să vorbească cu punctul final API

Corect, acele două interacțiuni rezolvă aceeași problemă: cum funcționează un proces care este extern până la clusterul kubernetes ajungeți la planul de control.S-ar putea imagina că ar fi limitat la (de exemplu) doar VPN-ul corporativ pentru kubectl operațiuni, sau doar subrețelele lucrătoare pentru kubelet.

kubelet de fapt nu nevoie pentru a utiliza NLB (adică traficul care iese din VPC prin orice GW Nat/Internet GW către NLB și înapoi în VPC), este perfect sigur și eficient să îndreptați configurația lui Kubelet către partea „internă” a acelui NLB, deci atâta timp cât certificatele planului de control au suficiente intrări Subject Alternative Name pentru a satisface acordul TLS. De aceea, oamenii nu se deranjează să distingă aceste două cazuri, dar dacă este o problemă de securitate (sau cost!) pentru organizația dvs., este 100% posibil să împărțiți aceste două interacțiuni.

Care API folosește acest serviciu?

CNI Serviciu indică același plan de control, dar traficul circulă în interiorul clusterului și asta kubernetes.default.svc.cluster.local Serviciu este disponibil tuturor Spațiu de numeeste tot timpul și este modul în care orice client kubernetes din Pod folosește sistemul încorporat Service Account jeton pentru a ajunge la API-ul kubernetes. În acest fel, nimic care rulează în interiorul clusterului nu trebuie să aibă nicio configurație pentru a ajunge la API -- inclusiv accesul la Internet -- deoarece traficul din cluster nu părăsește rețeaua CNI.