Încerc să fac o instalare curată a Kubernetes 1.23.x pe un grup de patru Raspberry Pi, fiecare rulând versiunea x64 a sistemului de operare Raspberry Pi, totuși mă confrunt cu o problemă majoră de îndată ce încerc să rulez kubeadm init pe nodul principal (înainte chiar de a încerca să se alăture celorlalte noduri). Și anume: la doar cinci minute după ce ai sunat kubeadm init pe nodul master, clusterul nu mai funcționează. De fapt, nu funcționează niciodată cu adevărat de la început. La început, serverul răspunde spunând că nodul este NotReady, dar apoi după 5 minute nu mai răspunde cu totul.
Iată ce am făcut și ce am văzut: am instalat containerd și kubeadm. Apoi rulez următoarea comandă pe nodul principal pentru a încerca să pornesc Kubernetes:
sudo kubeadm init --pod-network-cidr=10.244.0.0/16 \
--token-ttl=0 --apiserver-advertise-address=192.168.1.194
După rularea acelei comenzi și, ulterior, copierea fișierului /etc/kubernetes/admin.conf în ~/.kube/config, pot rula următoarea comandă:
$ kubectl obține noduri
NUME STARE ROLURI VÂRSTA VERSIUNE
k8s-master-1 NotReady control-plane, master 3m36s v1.23.4
Și va continua să arate starea NotReady timp de aproximativ 5 minute, după care aceeași comandă dă un rezultat foarte diferit:
$ kubectl obține noduri
Conexiunea la serverul 192.168.1.194:6443 a fost refuzată - ați specificat gazda sau portul potrivit?
Nu sunt sigur de ce se întâmplă asta, dar este foarte consistent. Am încercat de câteva ori acum resetarea kubeadm și apoi kubeadm init din nou, iar expirarea conexiunii are loc întotdeauna la marcajul de 5 minute. Așa că ultima dată când am încercat să fac asta, m-am hotărât să pun toate fișierele jurnal sub /var/log/containers/. După marcajul de 5 minute, înregistrează în mod repetat o variație a unei erori de conexiune la 127.0.0.1:2379. De exemplu:
2022-03-09T19:30:29.307156643-06:00 stderr F W0310 01:30:29.306871 1 clientconn.go:1331] [core] grpc: addrConn.createTransport nu a reușit să se conecteze la 0.017.23.0.0.0. }. Err: eroare de conectare: desc = „transport: eroare la apelare dial tcp 127.0.0.1:2379: conectare: conexiune refuzată”. Se reconecta...
Din Google, se pare că etcd rulează pe acel port, dar apoi, la 5 minute, o grămadă de servicii (inclusiv etcd) încep să se închidă. Am încărcat jurnalele complete de atunci kubeadm init aleargă până înainte de temutul marcaj de 5 minute, ca un Gist.
Am verificat deja că toate porturile sunt deschise, de asemenea. (Ei sunt.) În timpul primelor cinci minute, pot face telenet la portul local 2379. De ce nu pornește Kubernetes pe Pi-ul meu? Ce îmi lipsește?
ACTUALIZAȚI: După cum mi-am cerut, pot oferi câteva detalii suplimentare. Am văzut o postare care recomanda setarea valorii lui --apiserver-advertise-address la 0.0.0.0 în loc de IP-ul direct, așa că am încercat asta, dar nu părea să aibă nicio diferență. Am încercat să alerg systemctl status kubelet ceea ce arată că serviciul kubelet este „activ” în perioada inițială de 5 minute.
am alergat si eu kubectl descrie nodul k8s-master-1, care arată patru evenimente din această secvență:
- KubeletHasSuficientMemory
- KubeletHasNoDiskPressure
- KubeletHasSuficientPID
- KubeletNotReady
Ultimul eveniment este însoțit de acest mesaj: „Network runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized.” Deci asta m-a pus pe gânduri. Am așteptat ca Node să apară ca Ready înainte de a instala Flannel (alias pluginul CNI), dar de data aceasta am decis să încerc să instalez Flannel în perioada inițială de 5 minute, folosind această comandă:
kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
Și spre marea mea surpriză, asta a funcționat! Un fel de. Nodul principal a început în cele din urmă să raporteze o stare „Gata”.Și am observat că toate păstăile mele au apărut cu excepția notabilă a păstăilor coredns. Cu toate acestea, după un timp scurt, pod-ul kube-proxy (în spațiul de nume kube-system) moare și rămâne blocat într-un CrashLoopBackoff, iar apoi mai târziu pod-urile kube-controller-manager și kube-scheduler intră în mod similar într-un CrashLoopBackoff. Apoi, de data aceasta, după aproximativ 15 minute, întregul cluster a murit din nou ca înainte (înseamnă că am primit același mesaj „conexiunea la server a fost refuzată”). Așa că simt că sunt puțin mai aproape, dar sunt încă departe de a face acest lucru.
A DOUA ACTUALIZARE: Câteva lucruri: se pare că atunci când instalez pluginul flanel CNI, coredns fie nu este inclus, fie nu funcționează. Dar când instalez Weave Works CNI, atunci cel puțin încearcă să rotească nucleele, deși, din păcate, acele poduri se blochează în ContainerCreating și nu se activează niciodată. Așadar, așa cum mi sa cerut, ofer un număr de jurnale suplimentare. Sunt suficient de lungi pentru a garanta încărcarea lor separat, așa că iată a link la un Gist conținând patru loguri:
- Alergare
kubectl -n kube-system jurnalele pod/coredns-...
- Alergare
kubectl -n jurnalele de sistem kube pod/kube-controller-manager-k8s-master-1
- Alergare
kubectl -n jurnalele de sistem kube pod/kube-proxy-...
- Alergare
kubectl descrie nodul k8s-master-1
Rețineți că înainte ca totul să moară, pod-ul kube-controller-manager-... pornește, dar în curând se găsește într-un CrashLoopBackoff. În timp ce podurile coredns nu pornesc deloc cu succes.
