Am o problemă cu alăturarea nodurilor mele de lucru în cele trei master configurate.Este demn de remarcat că știu foarte puține despre partea de rețea a acestui lucru (aș prefera să fie explicat ca și cum am cinci ani, astfel încât să fiu sigur că nu ratez nimic.)
Am urmat ghidul aflat la:
https://dockerlabs.collabnix.com/kubernetes/beginners/Install-and-configure-a-multi-master-Kubernetes-cluster-with-kubeadm.html
cu câteva variante - adresele IP sunt diferite, iar configurația pentru kubeadm.k8s.io/v1alpha3 nu este acceptată de K8 actual. M-am actualizat pentru a folosi kubeadm.k8s.io/v1beta3, deși două etichete din configurația inițială nu par să aibă paralele (apiServerCertSANs și apiServerExtraArgs) și nu știu dacă acestea sunt esențiale. Versiunea Kubectl pe care o am este 1.24.0
Masters au fost inițializați cu mesajul:
W0510 09:17:54.102466 8717 initconfiguration.go:306] eroare la anularea configurației schema.GroupVersionKind{Group:"kubeadm.k8s.io", Version:"v1beta3", Kind:"ClusterConfiguration"}: câmp strict "eroare de decodare: necunoscută" apiServerExtraArgs", câmp necunoscut "apiserver-cert-extra-sans"
[init] Folosind versiunea Kubernetes: v1.24.0
[preflight] Executare verificări înainte de zbor
[flight] Extragerea imaginilor necesare pentru configurarea unui cluster Kubernetes
[flight] Acest lucru poate dura un minut sau două, în funcție de viteza conexiunii dvs. la internet
[flight] Puteți efectua această acțiune în prealabil folosind „kubeadm config images pull”
[cert] Folosind folderul certificateDir „/etc/kubernetes/pki”
[cert] Se generează certificatul și cheia „ca”.
[cert] Se generează certificatul și cheia „apiserver”.
[certs] apiserver care servește cert este semnat pentru nume DNS [kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local master1] și IP-uri [10.96.0.1 10.50.0.50 10.50.0.10]
[cert] Se generează certificatul și cheia „apiserver-kubelet-client”.
[cert] Se generează certificatul și cheia „front-proxy-ca”.
[cert] Se generează certificatul și cheia „front-proxy-client”.
[cert] Modul etcd extern: Omiterea generării autorității de certificare etcd/ca
[cert] Modul etcd extern: Sari peste generarea certificatului etcd/server
[cert] Modul etcd extern: se omite generarea certificatului etcd/peer
[cert] Modul etcd extern: Omitere generarea certificatului etcd/healthcheck-client
[cert] Modul etcd extern: Omiterea generării certificatului apiserver-etcd-client
[cert] Se generează cheia „sa” și cheia publică
[kubeconfig] Folosind folderul kubeconfig „/etc/kubernetes”
[kubeconfig] Se scrie fișierul kubeconfig „admin.conf”.
[kubeconfig] Se scrie fișierul kubeconfig „kubelet.conf”.
[kubeconfig] Se scrie fișierul kubeconfig „controller-manager.conf”.
[kubeconfig] Se scrie fișierul kubeconfig „scheduler.conf”.
[kubelet-start] Se scrie un fișier de mediu kubelet cu steaguri în fișierul „/var/lib/kubelet/kubeadm-flags.env”
[kubelet-start] Se scrie configurația kubelet în fișierul „/var/lib/kubelet/config.yaml”
[kubelet-start] Pornirea kubeletului
[control-plane] Folosind folderul manifest „/etc/kubernetes/manifests”
[control-plane] Se creează manifestul Pod static pentru „kube-apiserver”
[control-plane] Se creează manifestul Pod static pentru „kube-controller-manager”
[control-plane] Se creează manifestul static Pod pentru „kube-scheduler”
[wait-control-plane] Se așteaptă ca kubelet să pornească planul de control ca Pod-uri statice din directorul „/etc/kubernetes/manifests”. Acest lucru poate dura până la 4m0s
[apiclient] Toate componentele planului de control sunt sănătoase după 6,521293 secunde
[upload-config] Stocarea configurației utilizate în ConfigMap „kubeadm-config” în spațiul de nume „kube-system”
[kubelet] Crearea unui ConfigMap "kubelet-config" în spațiul de nume kube-system cu configurația pentru kubelets din cluster
[upload-certs] Faza de omitere. Consultați --upload-certs
[mark-control-plane] Marcarea nodului master1 ca control-plane prin adăugarea etichetelor: [node-role.kubernetes.io/control-plane node.kubernetes.io/exclude-from-external-load-balancers]
[mark-control-plane] Marcarea nodului master1 ca control-plane prin adăugarea taint-urilor [node-role.kubernetes.io/master:NoSchedule node-role.kubernetes.io/control-plane:NoSchedule]
[bootstrap-token] Se utilizează jetonul: 1w1x1s.7qwcr1m1e5hj3yp3
[bootstrap-token] Configurarea jetoanelor de bootstrap, ConfigMap despre cluster-info, Roluri RBAC
[bootstrap-token] Reguli RBAC configurate pentru a permite jetoanelor Node Bootstrap să obțină noduri
[bootstrap-token] Regulile RBAC configurate pentru a permite jetoanelor Node Bootstrap să posteze CSR-uri pentru ca nodurile să obțină acreditări de certificat pe termen lung
[bootstrap-token] Reguli RBAC configurate pentru a permite controlorului csrapprover să aprobe automat CSR-urile de la un Node Bootstrap Token
[bootstrap-token] Reguli RBAC configurate pentru a permite rotația certificatelor pentru toate certificatele client nod din cluster
[bootstrap-token] Crearea „cluster-info” ConfigMap în spațiul de nume „kube-public”
[kubelet-finalize] Se actualizează „/etc/kubernetes/kubelet.conf” pentru a indica un certificat și o cheie de client rotativ kubelet
[suplimente] supliment esențial aplicat: CoreDNS
[suplimente] supliment esențial aplicat: kube-proxy
Planul dvs. de control Kubernetes a fost inițializat cu succes!
Dar toate trei sunt listate în noduri (ca NotReady, desigur, dar cred că asta se datorează faptului că nu am implementat ceva de genul Calico) și am ajuns la punctul de a încerca să adaug în nodurile de lucru. rularea comenzii de join furnizată primește mai întâi eroarea:
[preflight] Executare verificări înainte de zbor
[flight preflight] Se citește configurația din cluster...
[flight] FYI: Puteți să vă uitați la acest fișier de configurare cu „kubectl -n kube-system get cm kubeadm-config -o yaml”
verificarea prealabilă a fazei de execuție a erorilor:
Una sau mai multe condiții pentru găzduirea unei noi instanțe de plan de control nu sunt îndeplinite.
[Eșec la încărcarea certificatului pentru CA: nu s-a putut încărca fișierul de certificat /etc/kubernetes/pki/ca.crt: deschide /etc/kubernetes/pki/ca.crt: nu există un astfel de fișier sau director, cheia de încărcare a eșecului pentru contul de serviciu: nu s-a putut încărca fișierul cu cheia privată /etc/kubernetes/pki/sa.key: deschide /etc/kubernetes/pki/sa.key: nu există un astfel de > > fișier sau director, eșec la încărcarea certificatului pentru CA proxy frontal: nu s-a putut" nu încărcați fișierul certificat /etc/kubernetes/pki/front-proxy-ca.crt: deschideți /etc/kubernetes/pki/front-proxy-ca.crt: nu există un astfel de fișier sau director]
Vă rugăm să vă asigurați că:
- Clusterul are o adresă controlPlaneEndpoint stabilă.
- Sunt furnizate certificatele care trebuie partajate între instanțele planului de control.
Pentru a vedea urma stivei acestei erori, executați cu --v=5 sau mai mare
Pentru a remedia acest lucru, am copiat certificatele de la unul dintre comandanți pe muncitorul la /etc/kubernetes/pki/ Apoi am rulat unirea din nou și am primit următoarea eroare:
[preflight] Executare verificări înainte de zbor
[flight preflight] Se citește configurația din cluster...
[flight] FYI: Puteți să vă uitați la acest fișier de configurare cu „kubectl -n kube-system get cm kubeadm-config -o yaml”
[flight] Executare verificări înainte de zbor înainte de a inițializa noua instanță a planului de control
fază de execuție a erorilor preflight: [preflight] Au apărut unele erori fatale:
[EROARE ExternalEtcdClientCertificates]: /etc/etcd/ca.pem nu există
[EROARE ExternalEtcdClientCertificates]: /etc/etcd/kubernetes.pem nu există
[EROARE ExternalEtcdClientCertificates]: /etc/etcd/kubernetes-key.pem nu există
[flight] Dacă știți ce faceți, puteți face o verificare non-fatală cu --ignore-preflight-errors=...
Pentru a vedea urma stivei acestei erori, executați cu --v=5 sau mai mare
Din nou, am copiat certificatele de la maestru la /etc/etcd/ . În sfârșit, primesc această eroare:
[preflight] Executare verificări înainte de zbor
[flight preflight] Se citește configurația din cluster...
[flight] FYI: Puteți să vă uitați la acest fișier de configurare cu „kubectl -n kube-system get cm kubeadm-config -o yaml”
[flight] Executare verificări înainte de zbor înainte de a inițializa noua instanță a planului de control
[flight] Extragerea imaginilor necesare pentru configurarea unui cluster Kubernetes
[flight] Acest lucru poate dura un minut sau două, în funcție de viteza conexiunii dvs. la internet
[flight] Puteți efectua această acțiune în prealabil folosind „kubeadm config images pull”
[cert] Folosind folderul certificateDir „/etc/kubernetes/pki”
[cert] Folosind certificatul și cheia „front-proxy-client” existente
fază de execuție a erorilor control-plane-prepare/certs: eroare la crearea activelor PKI: nu s-a putut scrie sau valida certificatul „apiserver”: certificatul apiserver este nevalid: x509: certificatul este valabil pentru kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes .default.svc.cluster.local, master2, nu worker1
Pentru a vedea urma stivei acestei erori, executați cu --v=5 sau mai mare
Dacă copiez certificatele de la un anumit master, acesta apare ca fiind valabil pentru acel master (master2 de mai sus). Cum generez/folosesc certificate pentru lucrător, deoarece se pare că acestea sunt generate de comanda INIT, mai degrabă decât de comanda JOIN?
Ca o posibilă soluție, m-am uitat la dezactivarea SSL-ului intern, conform acestei postări
https://stackoverflow.com/questions/60970744/how-to-run-kubernetes-without-ssl-network
dar nu găsesc secțiunile relevante din YAML pe care să le modific. Prefer să rulez cu SSL dacă pot, dar sunt deschis pentru cum să-l dezactivez dacă este necesar.
