Kubeadm: Ändern der Master-IP-Adresse

Dies ist keine Einschränkung durch kubeadm, sondern nur allgemeine Sicherheitspraktiken.
Das Zertifikat ist für {your-old-IP-here} signiert und sichere Kommunikation kann dann nicht mit {your-new-ip-here} passieren

Sie können dem Zertifikat jedoch vorher weitere IPs hinzufügen...

Danke für Ihre Antwort.

Da die IP-Adressen vom Cloud-Anbieter vergeben werden, würde die Zertifikatserstellung im Voraus nur funktionieren, wenn ich es auf einen Platzhalter setzen könnte. (Leider habe ich keine Ahnung von Zertifikaten.)

Ich habe übersehen, dass kubeadm reset tatsächlich existiert, da es im Referenzhandbuch nicht erwähnt wird. Reset und Init haben für mich gut genug funktioniert, und ich denke, ich werde es vermeiden, den Master-Rechner herunterzufahren - ich gehe davon aus, dass mein Problem selten ist und weit von allen Anwendungsfällen in der Produktion entfernt ist. Trotzdem frage ich mich, ob es einen besseren Weg gibt. Ich denke, ich könnte kubeadm reset Schritte nachahmen, aber den etcd-Datenordner behalten, um mein Cluster-Setup beizubehalten?

Wie auch immer, vielen Dank für die ganze Arbeit an kubeadm! Es ist magisch zu sehen, wie der Cluster innerhalb von Minuten auftaucht – ich benutze Kubernetes seit 0.14, in Produktion seit 1.0.

@analytik ich habe genau das gleiche problem wie du. Mein Firmennetzwerk blockiert gcr.io . Also verwende ich einen Dongle für die Installation. Die Provider-IP ändert sich jedoch dynamisch und steht nicht unter meiner Kontrolle. Also suche auch ich nach einer Lösung. Auch wenn ich meinen Dongle eingesteckt lasse, manchmal aufgrund von Netzwerk-Resets die IP-Änderungen. Hast du dafür eine Lösung? Wie gehen Sie damit um?
@luxas könnten Sie mir bitte vorschlagen, wie ich vorgehen kann. Ich bin ein Neuling bei K8S. Völlig verloren mit dieser Konfiguration. Könnten Sie mir mitteilen, wie ich dieses Problem mit der dynamischen IP beheben kann?

Wie geht ihr mit der geänderten Master-IP um?

Gibt es zu diesem Thema ein Update?

Selbes Problem hier. Irgendeine Dokumentation, um eine Master-IP-Änderung durchzuführen, ohne den gesamten Cluster zurückzusetzen?

Dies gelang mir durch:

• Ersetzen der IP-Adresse in allen Konfigurationsdateien in /etc/kubernetes
• /etc/kubernetes/pki . sichern
• Identifizieren von Zertifikaten in /etc/kubernetes/pki, die die alte IP-Adresse als alternativen Namen haben[1]
• Löschen sowohl des Zertifikats als auch des Schlüssels für jeden von ihnen (für mich war es nur apiserver und etcd/peer)
• Regenerieren der Zertifikate mit kubeadm alpha phase certs [2]
• Identifizieren der configmap im kube-system Namespace, die auf die alte IP verweist[3]
• manuelles Bearbeiten dieser configmaps
• Kubelet und Docker neu starten (um die Neuerstellung aller Container zu erzwingen)

[1]

/etc/kubernetes/pki# for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done
/etc/kubernetes/pki# grep -Rl 12\\.34\\.56\\.78 .
./apiserver.crt.txt
./etcd/peer.crt.txt
/etc/kubernetes/pki# for f in $(find -name "*.crt"); do rm $f.txt; done

[2]

/etc/kubernetes/pki# rm apiserver.crt apiserver.key
/etc/kubernetes/pki# kubeadm alpha phase certs apiserver
...
/etc/kubernetes/pki# rm etcd/peer.crt etcd/peer.key
/etc/kubernetes/pki# kubeadm alpha phase certs etcd-peer
...

[3]

$ kubectl -n kube-system get cm -o yaml | less
...
$ kubectl -n kube-system edit cm ...

Wow, diese Befehle waren mir nicht bekannt. Tolle Infos, das hat geholfen. Dankeschön !

Gibt es eine Möglichkeit, die configmaps manuell zu finden und zu ändern?

Ich hoffe, kubeadm kann diesen Prozess in einer zukünftigen Version behandeln.

@patricklucas ernsthaft, danke für diese Zuschreibung. Es hat mein Leben gerettet.

Für diejenigen, die noch mehr Klarheit suchen, hier meine Erfahrungen:

1. Ersetzen Sie die IP-Adresse in allen Konfigurationsdateien in /etc/kubernetes
bash oldip=192.168.1.91 newip=10.20.2.210 cd /etc/kubernetes # see before find . -type f | xargs grep $oldip # modify files in place find . -type f | xargs sed -i "s/$oldip/$newip/" # see after find . -type f | xargs grep $newip
2. Sichern von /etc/kubernetes/pki
bash mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
3. Identifizieren von Zertifikaten in /etc/kubernetes/pki , die die alte IP-Adresse als alternativen Namen haben (dies könnte bereinigt werden)
   bash cd /etc/kubernetes/pki for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done grep -Rl $oldip . for f in $(find -name "*.crt"); do rm $f.txt; done

4. Identifizieren Sie configmap im kube-system Namespace, der auf die alte IP verweist, und bearbeiten Sie sie:

   # find all the config map names
   configmaps=$(kubectl -n kube-system get cm -o name | \
     awk '{print $1}' | \
     cut -d '/' -f 2)
   
   # fetch all for filename reference
   dir=$(mktemp -d)
   for cf in $configmaps; do
     kubectl -n kube-system get cm $cf -o yaml > $dir/$cf.yaml
   done
   
   # have grep help you find the files to edit, and where
   grep -Hn $dir/* -e $oldip
   
   # edit those files, in my case, grep only returned these two:
   kubectl -n kube-system edit cm kubeadm-config
   kubectl -n kube-system edit cm kube-proxy
   

5. Ändern Sie die IP-Adresse (über cli oder GUI für Ihre Distribution)

6. Löschen Sie sowohl das Zertifikat als auch den Schlüssel für jedes, das im vorherigen Schritt durch grep identifiziert wurde, und generieren Sie diese Zertifikate neu

   HINWEIS: Bevor Sie die Zertifikate über kubeadm admin phase certs ... erstellen, müssen Sie die neue IP-Adresse anwenden

   rm apiserver.crt apiserver.key
   kubeadm alpha phase certs apiserver
   
   rm etcd/peer.crt etcd/peer.key
   kubeadm alpha phase certs etcd-peer
   

7. Kubelet und Docker neu starten
   bash sudo systemctl restart kubelet sudo systemctl restart docker
8. kopiere die neue config
   bash sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

@mariamTr ^

noch zu beachten, das Ändern der Zertifikate war im Offline-Modus möglich, indem die k8s-Version in einer Konfigurationsdatei angegeben wurde: https://github.com/kubernetes/kubernetes/issues/54188#issuecomment -418880831

@weisjohn Könnten Sie bitte auch Ihren Kommentar aktualisieren, indem Sie

kubectl edit cm -nkube-public cluster-info

wird auch für kubeadm benötigt?

Andernfalls schlagen meine kubeadm-Join-Befehle weiterhin fehl, indem die alte / falsche apiserver-IP nach der Hälfte des Prozesses verwendet wird.

Vielen Dank!

Ich habe alle Schritte von @weisjohn (https://github.com/kubernetes/kubeadm/issues/338#issuecomment-418879755) und @michaelfig (https://github.com/kubernetes/kubeadm/issues/ 338#issuecomment-428340099), um die Adresse überall zu ersetzen.

Dies wird verwendet, damit Kubernetes die neu erstellte VPC-Adresse auf eth1 anstelle der öffentlichen IP auf eth0 verwenden kann. Wenn ich jedoch kubeadm upgrade diff v1.12.3 ausführe, möchte es immer noch die Änderungen in --advertise-address in /etc/kubernetes/manifests/kube-apiserver.yaml .

Irgendwelche Hinweise?

Selbst in kubectl get all --export=true --all-namespaces -o yaml die alte IP nirgendwo vorhanden

Update: Es stellt sich heraus, dass kubeadm upgrade diff eine Änderung vorgeschlagen hat, aber kubeadm upgrade apply die Adresse überhaupt nicht geändert hat. (einer von vielen Bugs Kubernetes 1.13 wie Fixes)

@weisjohn Danke dafür

@patricklucas ernsthaft, danke für diese Zuschreibung. Es hat mein Leben gerettet.

Für diejenigen, die noch mehr Klarheit suchen, hier meine Erfahrungen:

1. Ersetzen Sie die IP-Adresse in allen Konfigurationsdateien in /etc/kubernetes
shell oldip=192.168.1.91 newip=10.20.2.210 cd /etc/kubernetes # see before find . -type f | xargs grep $oldip # modify files in place find . -type f | xargs sed -i "s/$oldip/$newip/" # see after find . -type f | xargs grep $newip
2. Sichern von /etc/kubernetes/pki
shell mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
3. Identifizieren von Zertifikaten in /etc/kubernetes/pki , die die alte IP-Adresse als alternativen Namen haben (dies könnte bereinigt werden)
   shell cd /etc/kubernetes/pki for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done grep -Rl $oldip . for f in $(find -name "*.crt"); do rm $f.txt; done

4. Identifizieren Sie configmap im kube-system Namespace, der auf die alte IP verweist, und bearbeiten Sie sie:

   # find all the config map names
   configmaps=$(kubectl -n kube-system get cm -o name | \
    awk '{print $1}' | \
    cut -d '/' -f 2)
   
   # fetch all for filename reference
   dir=$(mktemp -d)
   for cf in $configmaps; do
    kubectl -n kube-system get cm $cf -o yaml > $dir/$cf.yaml
   done
   
   # have grep help you find the files to edit, and where
   grep -Hn $dir/* -e $oldip
   
   # edit those files, in my case, grep only returned these two:
   kubectl -n kube-system edit cm kubeadm-config
   kubectl -n kube-system edit cm kube-proxy
   

5. Ändern Sie die IP-Adresse (über cli oder GUI für Ihre Distribution)

6. Löschen Sie sowohl das Zertifikat als auch den Schlüssel für jedes, das im vorherigen Schritt durch grep identifiziert wurde, und generieren Sie diese Zertifikate neu

   HINWEIS: Bevor Sie die Zertifikate über kubeadm admin phase certs ... erstellen, müssen Sie die neue IP-Adresse anwenden

   rm apiserver.crt apiserver.key
   kubeadm alpha phase certs apiserver
   
   rm etcd/peer.crt etcd/peer.key
   kubeadm alpha phase certs etcd-peer
   

7. Kubelet und Docker neu starten
   shell sudo systemctl restart kubelet sudo systemctl restart docker
8. kopiere die neue config
   shell sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

@mariamTr ^

Vielen Dank für Schritte.
Können Sie uns näher erläutern, welche Änderungen wir am Master-Knoten vornehmen müssen und welches Verfahren wir danach anwenden müssen, damit der alte Worker-Knoten diesem neu konfigurierten Master-Knoten beitritt?

Danke im Voraus :)

Vielleicht gut zu erwähnen, dass es beim Verschieben der Master-IP in ein privates Netzwerk nützlich sein könnte, auch das Overlay-Netzwerk zu aktualisieren. Calico verwendete die VPC-Schnittstelle nicht, bis sie an diese Schnittstelle gebunden war:

         env:
            - name: IP_AUTODETECTION_METHOD
              value: interface=eth1

kubeadm alpha phase certs apiserver

@weisjohn kubeadm alpha phase certs apiserver funktioniert nicht in v1.13.0 und zeigt "Dieser Befehl ist nicht dazu gedacht, alleine ausgeführt zu werden. Siehe Liste der verfügbaren Unterbefehle." Gibt es aktualisierte Kommentare?

in 1.13 heißt der Befehl kubeadm init phase certs apiserver :
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd -phase-certs

Sehr nützliche Schritte zur Abhilfe - danke @patricklucas und @weisjohn !

Ein zusätzlicher Tipp, wenn Sie wie ich mit dem Zustand beginnen, dass sich die IP-Adresse bereits geändert hat, sodass Sie den API-Server nicht kontaktieren können, um die configmaps in Schritt 4 zu ändern:
Das API-Server-Zertifikat ist für den Hostnamen kubernetes signiert, also können Sie das als Alias ​​zur neuen IP-Adresse in /etc/hosts hinzufügen und dann kubectl --server=https://kubernetes:6443 ... .

@bboreham @weisjohn @patricklucas Vielen Dank für Ihre Erfahrung. Könnten Sie bitte einen Rat geben, was ich auf Worker-Knoten tun soll, nachdem ich die IP auf dem Master-Knoten geändert habe?
Löschen/zum Cluster hinzufügen? Oder einfach _/etc/kubernetes/kubelet.conf_ und _/etc/kubernetes/pki/ca.crt_ manuell ändern?

Ich weiß, es ist ein altes Problem, aber vielleicht ist mein Kommentar für jemanden von Nutzen.
Leider hat die von @patricklucas und @weisjohn vorgeschlagene Lösung bei mir nicht funktioniert, also habe ich meine eigene erstellt:

systemctl stop kubelet docker

cd /etc/

# backup old kubernetes data
mv kubernetes kubernetes-backup
mv /var/lib/kubelet /var/lib/kubelet-backup

# restore certificates
mkdir -p kubernetes
cp -r kubernetes-backup/pki kubernetes
rm kubernetes/pki/{apiserver.*,etcd/peer.*}

systemctl start docker

# reinit master with data in etcd
# add --kubernetes-version, --pod-network-cidr and --token options if needed
kubeadm init --ignore-preflight-errors=DirAvailable--var-lib-etcd

# update kubectl config
cp kubernetes/admin.conf ~/.kube/config

# wait for some time and delete old node
sleep 120
kubectl get nodes --sort-by=.metadata.creationTimestamp
kubectl delete node $(kubectl get nodes -o jsonpath='{.items[?(@.status.conditions[0].status=="Unknown")].metadata.name}')

# check running pods
kubectl get pods --all-namespaces

@valerius257 danke Mann, du

Danke @ valerius257
Ich habe alle Zuschreibungen / Anleitungen von @patricklucas und @weisjohn ausprobiert . Bei meinem Cluster haben sie nicht funktioniert. Das Gute daran ist, dass diese Anweisungen einige der Schlüsselaspekte von Zertifikaten und Schlüsseln hervorheben und zu welchem ​​Zeitpunkt sie sich darum kümmern müssen.

Die von @valerius257 erwähnte Anweisung hat gestoßen bin, die sehr spezifisch für meinen kubeadm-Masterknoten sind. Ich habe versucht, den kubeadm-Masterknoten wiederherzustellen, dessen IP geändert wurde.

Fortsetzung der von @valerius257 erwähnten Schritte posten
Ich habe das Flanell-n/w-Plugin auf einem einzigen Master-Knoten verwendet.
Flannel-Problem: kube-flannel-ds-xxxx Backoff beim Neustart des Containers fehlgeschlagen
Pod-Status: CrashLoopBackOff. Aus diesem Grund können auch andere Pods wie core-dns-xxx nicht angezeigt werden.

Lösung: Da ich den Cluster mit kubeadm init mit cidr n/w gestartet habe (als die IP alt war oder während der Inbetriebnahme des Masterknotens), wurden im folgenden Schritt die cidr-Einstellungen von "/etc/kubernetes/manifests/kube-controller-manager" gelöscht .yaml"-Datei.
kubeadm init --ignore-preflight-errors=DirAvailable--var-lib-etcd.

Wenn Sie also den kubeadm-Masterknoten (mit der ersten IP-Adresse) mit dem Befehl "kubeadm init --token {{ kubeadm_token }} --pod-network-cidr=10.244.0.0/16" " gestartet haben, dann posten Sie die Zuweisung von neue IP sollten Sie folgenden Befehl mit --pod-network-cidr=10.244.0.0/16 ausführen.
" kubeadm init --ignore-preflight-errors=DirAvailable--var-lib-etcd --token {{ kubeadm_token }} --pod-network-cidr=10.244.0.0/16"

Oder ändern Sie die Datei "/etc/kubernetes/manifests/kube-controller-manager.yaml mit den folgenden Parametern, falls diese unter Spec:containers :command fehlen:

• --allocate-node-cidrs=true
• --cluster-cidr=10.244.0.0/16
  
  
  
  • --node-cidr-mask-size=24
    
    Referenz: https://github.com/coreos/flannel/issues/728 , lesen Sie die Lösung von @wkjun
    
    Sobald die oben genannten Änderungen in Kraft sind,
    
    systemctl stop kubelet docker
    
    Schlaf 20
    
    systemctl start docker kubelet
    
    Überprüfen Sie, ob alle Kapseln einschließlich Flanell betriebsbereit sind.
    
    kubect Get Pods -n kube-system
  
  

Problem 2:
Alle Pods im Anwendungs-Namespace oder auf kube-system zeigen Fehler in den Befehlen von describe pod an, etwa wie:
"Warnung FailedScheduling default-scheduler 0/1 Nodes sind verfügbar: 1 Node(s) hatte Taints, die der Pod nicht tolerierte."
Führen Sie den Befehl aus: kubectl taint node --all node-role.kubernetes.io/master-
Beschreiben Sie alle Pods, die im Apps-Workspace oder im kube-system-Namespace ausgeführt werden, erwähnte Fehler werden nicht beobachtet. In Mehrknoten-Clustern müssen Sie möglicherweise besonders vorsichtig sein.

@patricklucas ernsthaft, danke für diese Zuschreibung. Es hat mein Leben gerettet.

Für diejenigen, die noch mehr Klarheit suchen, hier meine Erfahrungen:

1. Ersetzen Sie die IP-Adresse in allen Konfigurationsdateien in /etc/kubernetes
shell oldip=192.168.1.91 newip=10.20.2.210 cd /etc/kubernetes # see before find . -type f | xargs grep $oldip # modify files in place find . -type f | xargs sed -i "s/$oldip/$newip/" # see after find . -type f | xargs grep $newip
2. Sichern von /etc/kubernetes/pki
shell mkdir ~/k8s-old-pki cp -Rvf /etc/kubernetes/pki/* ~/k8s-old-pki
3. Identifizieren von Zertifikaten in /etc/kubernetes/pki , die die alte IP-Adresse als alternativen Namen haben (dies könnte bereinigt werden)
   shell cd /etc/kubernetes/pki for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done grep -Rl $oldip . for f in $(find -name "*.crt"); do rm $f.txt; done

4. Identifizieren Sie configmap im kube-system Namespace, der auf die alte IP verweist, und bearbeiten Sie sie:

   # find all the config map names
   configmaps=$(kubectl -n kube-system get cm -o name | \
    awk '{print $1}' | \
    cut -d '/' -f 2)
   
   # fetch all for filename reference
   dir=$(mktemp -d)
   for cf in $configmaps; do
    kubectl -n kube-system get cm $cf -o yaml > $dir/$cf.yaml
   done
   
   # have grep help you find the files to edit, and where
   grep -Hn $dir/* -e $oldip
   
   # edit those files, in my case, grep only returned these two:
   kubectl -n kube-system edit cm kubeadm-config
   kubectl -n kube-system edit cm kube-proxy
   

5. Ändern Sie die IP-Adresse (über cli oder GUI für Ihre Distribution)

6. Löschen Sie sowohl das Zertifikat als auch den Schlüssel für jedes, das im vorherigen Schritt durch grep identifiziert wurde, und generieren Sie diese Zertifikate neu

   HINWEIS: Bevor Sie die Zertifikate über kubeadm admin phase certs ... erstellen, müssen Sie die neue IP-Adresse anwenden

   rm apiserver.crt apiserver.key
   kubeadm alpha phase certs apiserver
   
   rm etcd/peer.crt etcd/peer.key
   kubeadm alpha phase certs etcd-peer
   

7. Kubelet und Docker neu starten
   shell sudo systemctl restart kubelet sudo systemctl restart docker
8. kopiere die neue config
   shell sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config

@mariamTr ^

anstelle von newip welche ip sollen wir angeben?
Können wir eine eigene IP erstellen?

@VipinKrizz Der Kontext dieses Problems ist, dass sich die IP aufgrund von Faktoren innerhalb der Infrastruktur bereits geändert hat. Niemand kann beantworten, welche IP Sie verwenden sollten, außer jemand, der mit Ihrem speziellen Setup vertraut ist.

Vielleicht findest du auf Slack jemanden, mit dem du dich darüber unterhalten kannst? Kubeadm-Probleme sind nicht der richtige Ort.

@valerius257 vielen Dank für dieses Skript, ich sehe jetzt eine Reihe von Nachteilen in meinem Ansatz. Ich kann bestätigen, dass Ihre Lösung funktioniert hat, es gibt jedoch viele kleine Kanten (wie bei allen k8s). Ich musste alle Patches auf aktivierte Dienste/Einbauten, DNS, spezielle Speicherklassen usw. erneut anwenden.

Aber ja, Ihr Skript hat heute meinen Speck gerettet.

@valerius257 Ich bin deinem Schritt gefolgt,

root@ubuntu :/etc/kubernetes/pki# kubeadm init --ignore-preflight-errors=DirAvailable--var-lib-etcd
W0122 10:15:34.819150 102032 version.go:101] konnte keine Kubernetes-Version aus dem Internet abrufen: URL " https://dl.k8s.io/release/stable-1.txt " kann nicht abgerufen werden: https: //dl.k8s.io/release/stable-1.txt : tcp wählen: dl.k8s.io auf 127.0.0.53:53 suchen: Server-Fehlverhalten
W0122 10:15:34.819340 102032 version.go:102] Zurückgreifen auf die lokale Client-Version: v1.16.3
[init] Kubernetes-Version verwenden: v1.16.3
[Preflight] Ausführen von Pre-Flight-Checks
[WARNUNG IsDockerSystemdCheck]: "cgroupfs" als Docker-Cgroup-Treiber erkannt. Der empfohlene Treiber ist "systemd". Bitte folgen Sie der Anleitung unter https://kubernetes.io/docs/setup/cri/
[WARNUNG DirAvailable--var-lib-etcd]: /var/lib/etcd ist nicht leer
[Preflight] Zum Einrichten eines Kubernetes-Clusters erforderliche Bilder abrufen
[Preflight] Dies kann je nach Geschwindigkeit Ihrer Internetverbindung ein oder zwei Minuten dauern
[Preflight] Sie können diese Aktion auch vorher mit 'kubeadm config images pull' ausführen.
[kubelet-start] Kubelet-Umgebungsdatei mit Flags in die Datei "/var/lib/kubelet/kubeadm-flags.env" schreiben
[kubelet-start] Kubelet-Konfiguration in Datei "/var/lib/kubelet/config.yaml" schreiben
[kubelet-start] Kubelet-Dienst aktivieren
[certs] Verwenden des CertificateDir-Ordners "/etc/kubernetes/pki"
[certs] Vorhandene CA-Zertifizierungsstelle verwenden
[certs] Generieren von "apiserver" -Zertifikat und -Schlüssel
[certs] Apiserver-Serving-Zertifikat ist für DNS-Namen [ubuntu kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] und IPs [10.96.0.1 192.168.120.137] signiert
[certs] Vorhandenes apiserver-kubelet-client-Zertifikat und Schlüssel auf der Festplatte verwenden
[certs] Vorhandene Front-Proxy-CA-Zertifizierungsstelle verwenden
[certs] Vorhandenes Front-Proxy-Client-Zertifikat und Schlüssel auf der Festplatte verwenden
[certs] Vorhandene etcd/ca-Zertifizierungsstelle verwenden
[certs] Vorhandenes etcd/Server-Zertifikat und Schlüssel auf der Festplatte verwenden
[certs] Generieren von "etcd/peer"-Zertifikat und Schlüssel
[certs] etcd/Peer Serving-Zertifikat ist für DNS-Namen [ubuntu localhost] und IPs [192.168.120.137 127.0.0.1 ::1] signiert
[certs] Vorhandenes etcd/healthcheck-client-Zertifikat und Schlüssel auf der Festplatte verwenden
[certs] Verwenden des vorhandenen apiserver-etcd-client-Zertifikats und des Schlüssels auf der Festplatte
[certs] Verwenden des vorhandenen "sa"-Schlüssels
[kubeconfig] Verwenden des kubeconfig-Ordners "/etc/kubernetes"
[kubeconfig] kubeconfig-Datei "admin.conf" schreiben
[kubeconfig] kubeconfig-Datei "kubelet.conf" schreiben
[kubeconfig] kubeconfig-Datei "controller-manager.conf" schreiben
[kubeconfig] kubeconfig-Datei "scheduler.conf" schreiben
[control-plane] Manifestordner "/etc/kubernetes/manifests" verwenden
[control-plane] Statisches Pod-Manifest für "kube-apiserver" erstellen
[control-plane] Statisches Pod-Manifest für "kube-controller-manager" erstellen
[control-plane] Statisches Pod-Manifest für "kube-scheduler" erstellen
[etcd] Erstellen eines statischen Pod-Manifests für lokales etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Warten darauf, dass das Kubelet die Steuerungsebene als statische Pods aus dem Verzeichnis "/etc/kubernetes/manifests" hochfährt. Dies kann bis zu 4m0s dauern
[kubelet-check] Anfängliches Timeout von 40s ist vergangen.
[kubelet-check] Es scheint, als ob das Kubelet nicht läuft oder fehlerfrei ist.
[kubelet-check] Der HTTP-Aufruf gleich 'curl -sSL http://localhost :10248/healthz' ist mit folgendem Fehler fehlgeschlagen: Get http://localhost :10248/healthz: dial tcp 127.0.0.1:10248: connect: connection verweigert.
[kubelet-check] Es scheint, als ob das Kubelet nicht läuft oder fehlerfrei ist.
[kubelet-check] Der HTTP-Aufruf gleich 'curl -sSL http://localhost :10248/healthz' ist mit folgendem Fehler fehlgeschlagen: Get http://localhost :10248/healthz: dial tcp 127.0.0.1:10248: connect: connection verweigert.
[kubelet-check] Es scheint, als ob das Kubelet nicht läuft oder fehlerfrei ist.
[kubelet-check] Der HTTP-Aufruf gleich 'curl -sSL http://localhost :10248/healthz' ist mit folgendem Fehler fehlgeschlagen: Get http://localhost :10248/healthz: dial tcp 127.0.0.1:10248: connect: connection verweigert.
[kubelet-check] Es scheint, als ob das Kubelet nicht läuft oder fehlerfrei ist.
[kubelet-check] Der HTTP-Aufruf gleich 'curl -sSL http://localhost :10248/healthz' ist mit folgendem Fehler fehlgeschlagen: Get http://localhost :10248/healthz: dial tcp 127.0.0.1:10248: connect: connection verweigert.
[kubelet-check] Es scheint, als ob das Kubelet nicht läuft oder fehlerfrei ist.
[kubelet-check] Der HTTP-Aufruf gleich 'curl -sSL http://localhost :10248/healthz' ist mit folgendem Fehler fehlgeschlagen: Get http://localhost :10248/healthz: dial tcp 127.0.0.1:10248: connect: connection verweigert.

Leider ist ein Fehler aufgetreten:
Zeitüberschreitung beim Warten auf die Bedingung

Dieser Fehler wird wahrscheinlich verursacht durch:
- Das Kubelet läuft nicht
- Das Kubelet ist aufgrund einer Fehlkonfiguration des Knotens in irgendeiner Weise fehlerhaft (erforderliche Kontrollgruppen deaktiviert)

Wenn Sie ein systemd-betriebenes System verwenden, können Sie versuchen, den Fehler mit den folgenden Befehlen zu beheben:
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'

Darüber hinaus kann eine Komponente der Steuerungsebene beim Start durch die Container-Laufzeit abgestürzt oder beendet sein.
Um das Problem zu beheben, listen Sie alle Container mit Ihrer bevorzugten Container-Laufzeit-CLI auf, z. B. docker.
Hier ist ein Beispiel, wie Sie alle Kubernetes-Container auflisten können, die in Docker ausgeführt werden:
- 'Docker ps -a | grep kube | grep -v Pause'
Nachdem Sie den fehlerhaften Container gefunden haben, können Sie seine Protokolle überprüfen mit:
- 'Docker-Logs CONTAINERID'
Fehlerausführungsphase wait-control-plane: Kubernetes-Cluster konnte nicht initialisiert werden
Um den Stack-Trace dieses Fehlers anzuzeigen, führen Sie mit --v=5 oder höher aus

freundlich helfen

Dies gelang mir durch:

• Ersetzen der IP-Adresse in allen Konfigurationsdateien in /etc/kubernetes
• /etc/kubernetes/pki . sichern
• Identifizieren von Zertifikaten in /etc/kubernetes/pki, die die alte IP-Adresse als alternativen Namen haben[1]
• Löschen sowohl des Zertifikats als auch des Schlüssels für jeden von ihnen (für mich war es nur apiserver und etcd/peer)
• Regenerieren der Zertifikate mit kubeadm alpha phase certs [2]
• Identifizieren der configmap im kube-system Namespace, die auf die alte IP verweist[3]
• manuelles Bearbeiten dieser configmaps
• Kubelet und Docker neu starten (um die Neuerstellung aller Container zu erzwingen)

[1]

/etc/kubernetes/pki# for f in $(find -name "*.crt"); do openssl x509 -in $f -text -noout > $f.txt; done
/etc/kubernetes/pki# grep -Rl 12\\.34\\.56\\.78 .
./apiserver.crt.txt
./etcd/peer.crt.txt
/etc/kubernetes/pki# for f in $(find -name "*.crt"); do rm $f.txt; done

[2]

/etc/kubernetes/pki# rm apiserver.crt apiserver.key
/etc/kubernetes/pki# kubeadm alpha phase certs apiserver
...
/etc/kubernetes/pki# rm etcd/peer.crt etcd/peer.key
/etc/kubernetes/pki# kubeadm alpha phase certs etcd-peer
...

[3]

$ kubectl -n kube-system get cm -o yaml | less
...
$ kubectl -n kube-system edit cm ...

Hat bei mir funktioniert danke

Das einzige, was Sie verwenden müssen

 kubeadm init phase ..

Für die neuesten kubectl-Versionen

@bboreham
Ich habe die von @patricklucas genannten Schritte befolgt
Wie Sie in Schritt 4 erwähnt haben, müssen Sie in /etc/hosts einige Konfigurationen vornehmen, da sich die IP bereits geändert hat und keine Verbindung zum API-Server hergestellt werden kann.

Zertifikat generieren mit
kubeadm init --kubernetes-version=v1.16.3 phase certs apiserver

Ich habe mich in /etc/hosts geändert

und probierte kubectl --server=https://:6443 funktioniert immer noch nicht :(

muss in /etc/hosts eine bestimmte Konfiguration vorgenommen werden?