Puncte:1

Kubeadm token create fails on self-signed ca cert

drapel cn
Ted

Încerc să implementez un cluster k8s folosind kubespray deasupra unui cluster openstack de servere ubuntu. Instalarea eșuează atunci când kubeadm încearcă să inițieze furnizorul de cloud trimițând o cerere post la punctul final keystone xxx:5000/v3/ pentru a crea simbolul de bootstrap. Kubelet.service nu pornește deoarece punctul final keystone este semnat de un certificat autosemnat. Vezi mai jos. Am salvat certificatul ca de la punctul final keystone și l-am plasat pe nodul master în /etc/kubernetes/ssl/ unde kubelet și kubeadm caută certificate. De asemenea, am actualizat /etc/kubernetes/kubeadm-config.yaml Pe baza documentației Aici și Aici, am actualizat configurația implicită de alăturare kubeadm pentru a include „unsafeSkipCAVerification: true”, dar kubelet.service încă eșuează pe certificatul autosemnat. Kubeadm ar trebui să se autentifice prin numele de utilizator/parola care este stocat în fișierul /etc/kubernetes/cloud_config și am verificat că acele valori sunt corecte. Nu sunt sigur unde să caut să schimb comportamentul. Orice îndrumare ar fi foarte apreciată.

ubuntu:/etc/kubernetes# kubeadm config print join-defaults
apiVersion: kubeadm.k8s.io/v1beta3
caCertPath: /etc/kubernetes/pki/ca.crt
descoperire:
  bootstrapToken:
  apiServerEndpoint: kube-apiserver:6443
  simbol: abcdef.0123456789abcdef
  unsafeSkipCAVerification: adevărat
  timeout: 5m0s
  tlsBootstrapToken: abcdef.0123456789abcdef
fel: JoinConfiguration
  nodeÎnregistrare:
  criSocket: /var/run/dockershim.sock
  imagePullPolicy: IfNotPresent
  nume: mdap-node-01
  vicii: nul

Urmărirea stivei kubelet:

 Dec 15 22:19:51 ubuntu kubelet[388780]: E1215 22:19:51.760564 388780 server.go:294] „Eșuat la rularea kubelet” err="Nu s-a putut rula Kubelet: nu s-a putut iniția furnizorul de cloud \" : Postați \"https://XXX.XXX.XXX.132:5000/v3/auth/tokens\": x509: certificat semnat de o autoritate necunoscută”
 Dec 15 22:19:51 ubuntu systemd[1]: kubelet.service: Proces principal ieșit, cod=ieșit, stare=1/Eșec


FAILED - REÎNCERCARE: creați simbolul kubeadm pentru unirea nodurilor cu expirare de 24 de ore (implicit) (răman 4 încercări). Rezultatul a fost: {
„încercări”: 2,
„schimbat”: fals,
„cmd”: [
    „/usr/local/bin/kubeadm”,
    "--kubeconfig",
    „/etc/kubernetes/admin.conf”,
    "jeton",
    "crea"
],
"delta": "0:01:15.035670",
„sfârșit”: „2021-12-16 15:03:22.901080”,
„invocare”: {
    „module_args”: {
        „_raw_params”: „/usr/local/bin/kubeadm --kubeconfig /etc/kubernetes/admin.conf token create”,
        „_uses_shell”: fals,
        „argv”: nul,
        „chdir”: nul,
        „creează”: nul,
        „executable”: nul,
        „elimină”: nul,
        „stdin”: nul
        „stdin_add_newline”: adevărat,
        „strip_empty_ends”: adevărat,
        „avertizează”: adevărat
    }
},
"msg": "cod returnat diferit de zero",
"rc": 1,
„reîncercări”: 6,
„start”: „2021-12-16 15:02:07.865410”,
"stderr": "a expirat în așteptarea condiției\nPentru a vedea urmărirea stivei acestei erori executată cu --v=5 sau mai mare",
„stderr_lines”: [
    „a expirat în așteptarea stării”,
    „Pentru a vedea urma stivei acestei erori, executați cu --v=5 sau mai mare”
],
"stdout": "",
„stdout_lines”: []
kkopczak avatar
drapel ng
Bună @Ted, ce versiune de Kubernetes ați folosit și cum ați configurat clusterul? Ați folosit instalație bare metal sau vreun furnizor de cloud?
Ted avatar
drapel cn
Ted
@kkopczak conform cerințelor clientului Am folosit terraform v1.1.0 pentru a implementa serverele Ubuntu v20.04.3 într-un cluster openstack care va servi drept noduri k8s. Folosesc kubespray pentru a implementa cluster-ul kubernetes v1.22.4. De asemenea, prin kubespray, folosesc furnizorul de cloud openstack în arbore, deoarece acesta ar trebui să fie în cele din urmă un sistem închis. https://kubespray.io/#/docs/openstack?id=the-in-tree-cloud-provider
Ted avatar
drapel cn
Ted
se pare că am înțeles greșit furnizorii de cloud din arbore: https://kubernetes.io/blog/2019/04/17/the-future-of-cloud-providers-in-kubernetes/
kkopczak avatar
drapel ng
Imi cer scuze pentru raspunsul intarziat. [Aici](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/) este documentația despre Managementul certificatelor. Ați putea verifica rezultatul acestei comenzi `kubeadm certs check-expiration` (aceasta poate arăta dacă certificatul este gestionat extern)?
Wytrzymały Wiktor avatar
drapel it
Salut @Ted. Orice actualizari?
Ted avatar
drapel cn
Ted
@WytrzymaÅyWiktor Am ajuns să elimin setările furnizorului de cloud openstack din configurația kubespray în ./kubespray/inventory/my_inventory/group_vars/all/all.yml deoarece folosim openstack pentru a furniza serverele, dar nu folosim openstack.keystone pentru gestionarea certificatelor/jetonelor la nivelul k8s. Totuși, se pare că ar trebui să fie posibil.
Ted avatar
drapel cn
Ted
după ce am eliminat furnizorul de cloud, kubespray a instalat cluster-ul k8s cu succes. Înțelegerea mea despre eroarea pe care am postat-o ​​este că keystone folosește un certificat autosemnat, în care procesul kubelet nu avea încredere. Am încercat să adaug certificatul public keystone în folderul /etc/kuberenetes/ssl de pe același server ca și procesul kubelet, dar kubespray reprovisionează acele certificate de fiecare dată când este rulat. Voi citi documentul trimis de @kkopczak pentru a vedea dacă pot înțelege mai bine acest lucru.
Wytrzymały Wiktor avatar
drapel it
Salut @Ted. Cum este subiectul acum? Vre-un progres?
Puncte:2
drapel ng

Pentru a clarifica, postez răspunsul comunității Wiki.

Pentru a rezolva această problemă, ați eliminat setările furnizorului de cloud openstack. După aceea, cu kubespray, ați reușit să instalați cluster-ul k8s cu succes.

Pentru a citi despre certificat - așa cum am menționat mai devreme, documentația despre gestionarea certificatelor este sub acest link. Pentru a verifica dacă certificatul este gestionat extern, puteți utiliza următoarea comandă:

kubeadm certs verifica-expirare

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.