În configurația mea actuală de testare, am mai multe VM care rulează Debian-11. Toate nodurile au un IP privat și o a doua interfață wireguard. În viitor, nodurile vor fi în locații diferite, cu rețele diferite, iar Wireguard este folosit pentru a „suprapune” toate mediile de rețea diferite. Vreau să instalez un Kubernetes pe toate nodurile.
nod public ip wireguard ip
vm1 192.168.10.10 10.11.12.10
vm2 192.168.10.11 10.11.12.11
vm3 192.168.10.12 10.11.12.12
...
Așa că am instalat docker și kubeadm/kubelet/kubectl în versiunea 1.23.5 pe toate nodurile. De asemenea, am instalat un haproxy și pe toate nodurile. Funcționează ca echilibrator de încărcare, listând la localhost:443 și redirecționând cererile către unul dintre planurile de control online.
Apoi am pornit cluster-ul cu kubeadm
vm01> kubeadm init --apiserver-advertise-address=10.11.12.10 --pod-network-cidr=10.20.0.0/16
După aceea am testat să integrez fie flanel, fie calico. Fie prin adăugare --iface=<interfață-wireguard> sau prin setarea manifestului personalizat ...nodeAddressAutodetectionV4.interface: <interfață-wireguard>.
Când adaug un nod normal - totul este bine. Nodul este adăugat, pod-urile sunt create și comunicarea se face prin interfața de rețea definită.
Când adaug un plan de control fără interfața wireguard, pot adăuga și diferite planuri de control cu
vm2> kubeadm join 127.0.0.1:443 --token ... --discovery-token-ca-cert-hash sha256:... --control-plane
Desigur, înainte de asta, am copiat mai multe fișiere de la vm01 la vm02 din /etc/kubernetes/pki ca ca.*, sa.*, front-proxy-ca.*, apiserver-kubelet-client.* și etcd/ca.*.
Dar când folosesc rețeaua flanel sau calico împreună cu interfața wireguard, ceva ciudat se întâmplă după comanda join.
root@vm02:~# kubeadm join 127.0.0.1:443 --token nwevkx.tzm37tb4qx3wg2jz --discovery-token-ca-cert-hash sha256:9a97a5846ad823647ccb1894709071000000000000000000000000000000000000001
[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] Se generează certificatul și cheia „front-proxy-client”.
[cert] Se generează certificatul și cheia „etcd/server”.
[certs] certificatul de servire etcd/server este semnat pentru nume DNS [localhost mimas] și IP-uri [192.168.10.11 127.0.0.1 ::1]
[cert] Se generează certificatul și cheia „etcd/peer”.
[cert] etcd/cert de servire peer este semnat pentru nume DNS [localhost mimas] și IP-uri [192.168.10.11 127.0.0.1 ::1]
[cert] Se generează certificatul și cheia „etcd/healthcheck-client”.
[cert] Se generează certificatul și cheia „apiserver-etcd-client”.
[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 mimas] și IP-uri [10.96.0.1 192.168.10.11 127.0.0.
[cert] Folosind certificatul și cheia existente „apiserver-kubelet-client”.
[cert] Certificate și chei valide există acum în „/etc/kubernetes/pki”
[cert] Folosind cheia existentă „sa”.
[kubeconfig] Se generează fișiere kubeconfig
[kubeconfig] Folosind folderul kubeconfig „/etc/kubernetes”
[endpoint] AVERTISMENT: portul specificat în controlPlaneEndpoint înlocuiește bindPort în adresa planului de control
[kubeconfig] Se scrie fișierul kubeconfig „admin.conf”.
[endpoint] AVERTISMENT: portul specificat în controlPlaneEndpoint înlocuiește bindPort în adresa planului de control
[kubeconfig] Se scrie fișierul kubeconfig „controller-manager.conf”.
[endpoint] AVERTISMENT: portul specificat în controlPlaneEndpoint înlocuiește bindPort în adresa planului de control
[kubeconfig] Se scrie fișierul kubeconfig „scheduler.conf”.
[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”
[check-etcd] Verificarea că clusterul etcd este sănătos
[kubelet-start] Se scrie configurația kubelet în fișierul „/var/lib/kubelet/config.yaml”
[kubelet-start] Se scrie un fișier de mediu kubelet cu steaguri în fișierul „/var/lib/kubelet/kubeadm-flags.env”
[kubelet-start] Pornirea kubeletului
[kubelet-start] Se așteaptă ca kubelet să execute TLS Bootstrap...
[etcd] A anunțat un nou membru etcd care se alătură clusterului etcd existent
[etcd] Se creează manifestul Pod static pentru „etcd”
[etcd] Se așteaptă ca noul membru etcd să se alăture grupului. Acest lucru poate dura până la 40 de secunde
[kubelet-check] Timpul de expirare inițial de 40 de secunde a trecut.
eroare faza de execuție control-plane-join/etcd: eroare la crearea fișierului manifest local etcd static pod: timeout așteptând ca clusterul etcd să fie disponibil
Pentru a vedea urma stivei acestei erori, executați cu --v=5 sau mai mare
Și după acel timeout, chiar și pe vm01, serverul API nu mai funcționează, nu mai pot rula nicio comandă kubeadm sau kubectl. Serviciul HTTPS de pe 6443 este mort. Dar nici nu înțeleg de ce serverul API de pe vm01 nu mai funcționează atunci când adaugă un al doilea server API și nici nu pot găsi un motiv, dacă ieșirea vorbește despre IP-uri 192.168...., deoarece clusterul ar trebui să comunice doar prin 10.11.12.0 /24 rețea wireguard.
