Pentru a înțelege mai bine această întrebare, merită să ne amintim de bază Componentele Kubernetes.
Practic, putem împărți clusterul în:
- Nod principal: Plan de control, responsabil pentru luarea deciziilor globale despre cluster
- Worker Node(s) - responsabil pentru rularea podurilor prin furnizarea mediului de rulare Kubernetes.
Să aruncăm o privire la componentele secțiunii „Nod” (lucrător):
kubelet
Un agent care rulează pe fiecare nodul în cluster. Se asigură că containere aleargă într-o Pod.
Kubelet-ul preia un set de PodSpec-uri care sunt furnizate prin diferite mecanisme și se asigură că containerele descrise în acele PodSpec-uri funcționează și sunt sănătoase. Kubelet nu gestionează containerele care nu au fost create de Kubernetes.
kube-proxy
kube-proxy este un proxy de rețea care rulează pe fiecare nodul în clusterul dvs., implementând o parte din Kubernetes Serviciu concept.
kube-proxy menține regulile de rețea pe noduri. Aceste reguli de rețea permit comunicarea în rețea cu podurile dvs. din sesiunile de rețea din interiorul sau din afara clusterului dvs.
kube-proxy utilizează stratul de filtrare a pachetelor sistemului de operare dacă există unul și este disponibil. În caz contrar, kube-proxy redirecționează traficul în sine.
Durata de rulare a containerului
Durata de rulare a containerelor este software-ul responsabil pentru rularea containerelor.
Kubernetes acceptă mai multe durate de rulare a containerelor: Docher, containerd, CRI-O, și orice implementare a Kubernetes CRI (Container Runtime Interface).
Dupa cum kubelet și Container runtime sunt două componente principale care sunt responsabile pentru rularea podului și stabilirea conexiunii la planul de control, acestea trebuie să fie instalate direct pe sistemul de operare al nodului. Înseamnă și pentru kubelet trebuie să aibă certificate TLS pe care le-ați menționat în întrebarea dvs. pentru a asigura o conexiune sigură la planul de control. Ce ziceti kube-proxy?
Poate fi instalat în două moduri în timpul furnizării clusterului - direct pe sistemul de operare al nodului (de exemplu, acest mod este utilizat în Kubernetes The Hard Way) sau ca DaemonSet (kubeadm).
Când kube-proxy este instalat direct va avea, de asemenea, separat certificate TLS generate, la fel ca kubelet.
A doua modalitate, este „DeamonSet” menționat în întrebarea dvs. Înseamnă, în loc să ruleze ca deamonul sistemului de operare direct pe nod, se va configura prin DeamonSet implementare și va rula ca pod pe fiecare nod. Avantaje față de rularea direct pe sistemul de operare:
- Folosind funcțiile DeamonSet, ne asigurăm că, în caz de eșec, acest pod va fi re-creat automat pe nod
- mai puțină interferență directă cu sistemul de operare al nodului - în loc să generăm perechi noi de certificate TLS, vom folosi doar ServiceAccount
Răspunzând la întrebarea dvs.:
Ce este special aici despre Daemonsets în ceea ce privește autentificarea?
Pentru a o înțelege mai bine, putem arunca o privire mai profundă asupra kube-proxy configurat prin DaemonSets folosind clusterul furnizat cu kubeadm. Bazat pe Documente Kubernetes:
Un cont de serviciu pentru kube-proxy este creat în sistem-kube spatiu de nume; apoi kube-proxy este implementat ca DaemonSet:
- Acreditările (
ca.crt și jeton) către planul de control provin din ServiceAccount
- Locația (URL-ul) serverului API provine dintr-un ConfigMap
- The
kube-proxy ServiceAccount este legat de privilegiile din sistem: nod-proxier ClusterRole
Sunt trei puncte. Să-l verificăm mai întâi pe primul:
Acreditările - secrete
Obțineți numele contului de serviciu din definiția podului:
kubectl obține daemonset kube-proxy -n kube-system -o yaml
...
serviceAccount: kube-proxy
serviceAccountName: kube-proxy
...
După cum se vede, are a atribuit un cont de serviciu numit kube-proxy:
Să verificăm:
kubectl get sa kube-proxy -n kube-system -o yaml
Ieșire:
apiVersion: v1
fel: ServiceAccount
metadate:
CreationTimestamp: „2021-08-16T14:14:56Z”
nume: kube-proxy
spațiu de nume: kube-system
resourceVersion: „259”
uid: (UID)
secrete:
- nume: kube-proxy-token-2qhph
După cum se vede, ne referim la secret numit kube-proxy-token-2qhph:
kubectl obține secret kube-proxy-token-2qhph -n kube-system -o yaml
Ieșire:
apiVersion: v1
date:
ca.crt: (CODIFICAT CA BASE64 AL APISERVER)
spațiu de nume: (NAMESPACE BASE64 ENCODED)
jeton: (BEARER TOKEN BASE64 CODIFICAT)
fel: Secret
metadate:
adnotari:
kubernetes.io/service-account.name: kube-proxy
kubernetes.io/service-account.uid: ...
CreationTimestamp: „2021-08-16T14:14:56Z”
nume: kube-proxy-token-2qhph
spațiu de nume: kube-system
resourceVersion: „256”
uid: (UID)
tip: kubernetes.io/service-account-token
Acest secret conține:
Secretul creat deține CA publică a serverului API și un JSON Web Token (JWT) semnat.
Folosim acest simbol purtător „JSON Web Token” pentru verificarea solicitărilor:
Un cont de serviciu este un autentificator activat automat care utilizează jetoane de purtător semnate pentru a verifica cererile.
JWT semnat poate fi folosit ca un token purtător pentru a se autentifica ca contul de serviciu dat. Vedea de mai sus pentru cum este inclus jetonul într-o solicitare. În mod normal, aceste secrete sunt montate în pod-uri pentru accesul în cluster la serverul API, dar pot fi folosite și din afara clusterului.
Pentru a obține mai multe informații despre jetoanele de bootstrap, vă recomand să citiți următoarele documente Kubernetes: Autentificarea cu jetoane Bootstrap, token kubeadm și Kubernetes RBAC 101: Autentificare.
ConfigMap
Urmând pași similari ca pentru obținerea numelui ServiceAccount, vom obține numele ConfigMap care este montat pe kube-proxy pod:
kubectl obține daemonset kube-proxy -n kube-system -o yaml
...
volume:
- configMap:
defaultMode: 420
nume: kube-proxy
...
Acum, să obținem definiția ConfigMap:
kubectl obține cm kube-proxy -n kube-system -o yaml
kubeconfig.conf: |-
apiVersion: v1
fel: Config
clustere:
- cluster:
autoritate de certificare: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
server: https://10.230.0.12:6443
nume: implicit
contexte:
- context:
cluster: implicit
spatiu de nume: implicit
utilizator: implicit
nume: implicit
contextul curent: implicit
utilizatori:
- nume: implicit
utilizator:
tokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
Această adresă IP este în sub Server: este adresa API deci kube-proxy îl cunoaște și poate comunica cu el.
Există și referințe la cart și jeton care sunt montate din kube-proxy-token-2qhph secret.
ClusterRole
Să verificăm ClusterRole menționat mai devreme - sistem: nod-proxier:
kubectl descrie clusterrole system:node-proxier
Nume: system:node-proxier
Etichete: kubernetes.io/bootstrapping=rbac-defaults
Adnotări: rbac.authorization.kubernetes.io/autoupdate: true
Regula politică:
Resurse URL-uri non-resurse Nume de resurse Verbe
--------- ----------------- -------------- -----
evenimente [] [] [creați actualizarea corecțiilor]
events.events.k8s.io [] [] [creează o actualizare de corecție]
noduri [] [] [obține vizionarea listei]
puncte finale [] [] [listă de urmărire]
servicii [] [] [listă de urmărire]
endpointslices.discovery.k8s.io [] [] [listă de urmărire]
Putem ca acest rol să enumere și să urmărească punctele finale ale nodului, punctelor, serviciilor etc...
Prin descrierea ClusterRoleBinding kubeadm:node-proxier putem confirma acest rol sistem: nod-proxier este folosit de kube-proxy Cont de serviciu:
kubectl descrie clusterrolebinding kubeadm:node-proxier
Nume: kubeadm:node-proxier
Etichete: <niciuna>
Adnotări: <niciuna>
Rol:
Tip: ClusterRole
Nume: system:node-proxier
Subiecte:
Kind Name Spațiu de nume
---- ---- ---------
ServiceAccount kube-proxy kube-system
Pentru a obține mai multe detalii, vă recomand să citiți kubeadm detalii de implementare.
Răspunzând la a doua întrebare:
Care este rostul din spate"Deoarece kubelet-ul în sine este încărcat pe fiecare nod și este suficient pentru a porni serviciile de bază" ?
Înseamnă doar că acel nod a stabilit o conexiune cu Control Plane (ca kubelet este componenta responsabilă pentru asta), astfel încât Planul de control poate începe programarea kube-proxy pod pe nod folosind durata de rulare a containerului predefinit.
