<p>kubeadm init hängt bei "Erster Knoten hat sich registriert, ist aber noch nicht bereit"</p>

Genau dasselbe passiert mir unter Ubuntu 16.04.02, sowohl GCE- als auch lokale VMWare-Installationen, Docker-Version 1.12.6, Kernel 4.8.0-44-generic 47~16.04.1-Ubuntu SMP.

Das Kubelet-Log zeigt eine Warnung über das Fehlen von /etc/cni/net.d vor dem Fehler, den wir in jimmycuadras Bericht sehen:

Mar 29 04:43:25 instance-1 kubelet[6800]: W0329 04:43:25.763117    6800 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Mar 29 04:43:25 instance-1 kubelet[6800]: E0329 04:43:25.763515    6800 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized

Gleiches Problem bei Ubuntu AWS VM. Docker 1.12.5

root@ip-10-43-0-20 :~# kubeadm-Version
kubeadm version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.0", GitCommit:"fff5156092b56e6bd60fff75aad4dc9de6b6ef37", GitTreeState:"clean", BuildDate:"2017-03-28T16:24: 30Z", GoVersion:"go1.7.5"

root@ip-10-43-0-20 :~# uname -a
Linux ip-10-43-0-20 4.4.0-45-generic #66-Ubuntu SMP Mi 19. Okt 14:12:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

root@ip-10-43-0-20 :~# kubeadm init --config cfg.yaml
[kubeadm] WARNUNG: kubeadm befindet sich in der Beta-Phase, bitte verwenden Sie es nicht für Produktionscluster.
[init] Kubernetes-Version verwenden: v1.6.0
[init] Verwenden des Autorisierungsmodus: RBAC
[init] WARNUNG: Damit Cloudprovider-Integrationen funktionieren, muss --cloud-provider für alle Kubelets im Cluster festgelegt werden.
(/etc/systemd/system/kubelet.service.d/10-kubeadm.conf sollte zu diesem Zweck bearbeitet werden)
[Preflight] Ausführen von Pre-Flight-Checks
[Preflight] Starten des Kubelet-Dienstes
[Zertifikate] Generiertes CA-Zertifikat und -Schlüssel.
[Zertifikate] Generiertes API-Serverzertifikat und -schlüssel.
[Zertifikate] API-Server-Bereitstellungszertifikat ist für DNS-Namen [ip-10-43-0-20 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] und IPs [10.96.0.1 10.43.0.20 . signiert ]
[Zertifikate] Generiertes API-Server-Kubelet-Client-Zertifikat und -Schlüssel.
[Zertifikate] Generierter Dienstkonto-Token-Signaturschlüssel und öffentlicher Schlüssel.
[Zertifikate] Generiertes Front-Proxy-CA-Zertifikat und -Schlüssel.
[Zertifikate] Generiertes Front-Proxy-Client-Zertifikat und -Schlüssel.
[Zertifikate] Gültige Zertifikate und Schlüssel existieren jetzt in "/etc/kubernetes/pki"
[kubeconfig] KubeConfig-Datei auf Datenträger geschrieben: "/etc/kubernetes/admin.conf"
[kubeconfig] KubeConfig-Datei auf Festplatte geschrieben: "/etc/kubernetes/kubelet.conf"
[kubeconfig] KubeConfig-Datei auf Datenträger geschrieben: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] KubeConfig-Datei auf die Festplatte geschrieben: "/etc/kubernetes/scheduler.conf"
[apiclient] API-Client erstellt, der darauf wartet, dass die Steuerungsebene bereit ist
[apiclient] Alle Komponenten der Steuerungsebene sind nach 16.531681 Sekunden fehlerfrei
[apiclient] Warten, bis sich mindestens ein Knoten registriert und bereit ist
[apiclient] Erster Knoten hat sich registriert, ist aber noch nicht bereit
[apiclient] Erster Knoten hat sich registriert, ist aber noch nicht bereit
[apiclient] Erster Knoten hat sich registriert, ist aber noch nicht bereit

++ das gleiche Problem (Ubuntu 16.04.1)

Das gleiche hier auf Ubuntu 16.04

Unter CentOS 7 habe ich das Kubelet auf 1.5.4 herabgestuft. Das hat es für mich gelöst. Es scheint, als ob die Fertigprüfung im 1.6.0 Kubelet anders funktioniert.

Gleiches Problem bei CentOS 7 auf einem Bare-Metal-x64-Rechner, seit dem Upgrade auf k8s 1.6.0

Gleiches Problem unter Ubuntu 16.04

Das gleiche Problem unter Ubuntu 16.04, manuelles Downgrade des kubelet Pakets löste das Problem.

# apt install kubelet=1.5.6-00

@ctrlaltdel bei mir hat es nicht funktioniert.

Ich vermute, dass dies ein Kubelet-Problem ist. Es sollte den Knoten nicht als nicht bereit markieren, wenn CNI nicht konfiguriert ist. Nur Pods, die CNI erfordern, sollten als nicht bereit markiert werden.

@jbeda Weißt du, wann dieses Problem behoben wird?

@kristiandrucker – nein – ich

@jbeda Ok, aber nachdem das Problem behoben ist, was dann? Kubelet aus der Quelle neu erstellen?

@kristiandrucker Dies muss in einem Point-Release von k8s veröffentlicht werden, wenn es sich um ein Kubelet-Problem handelt.

Ich vermute, dass https://github.com/kubernetes/kubernetes/pull/43474 die Ursache ist. Ich werde einen Fehler melden und mich an die Netzwerkleute wenden.

@dcbw Bist du da?

Anscheinend besteht das Problem darin, dass ein DaemonSet nicht für Knoten geplant ist, die die Bedingung Net workReady:false aufweisen , da die Überprüfungen für die Planung von Pods nicht stNetwork:true sollte auf einem Knoten geplant werden, der Net workReady:false ist, ein Pod ho

Funktioniert als Workaround das Hinzufügen der Anmerkung scheduler.alpha.kubernetes.io/critical-pod zu Ihrem DaemonSet wieder?

@janetkuo @lukaszo können Sie das DS-Verhalten untersuchen?

Im #sig-Netzwerk gibt es übrigens auch eine fortlaufende Diskussion über Slack.

Gleiches Problem CentOS 7 x64

@prapdm Dies scheint nicht ausführen .

CentOS Linux-Version 7.3.1611 (Kern)

Ich habe es auf einem Knoten mit Ubuntu 16.04 versucht. Es hängt mit der Meldung "Noch nicht bereit". Ich habe auch Flanell DaemonSet manuell erstellt, aber in meinem Fall hat es ohne Probleme einen Pod geplant. Der Daemon-Pod selbst ging mit dem Fehler in den CrashLoopBackOff: E0329 22:57:03.065651 1 main.go:127] Failed to create SubnetManager: error retrieving pod spec for 'kube-system/kube-flannel-ds-z3xgn': the server does not allow access to the requested resource (get pods kube-flannel-ds-z3xgn)

Ich werde auch Centos anprobieren, aber ich denke nicht, dass DaemonSet hier schuld ist, kubeadm hängt hier.

das ist ein rbac-Berechtigungsfehler.

@jimmycuadra Mir ist gerade aufgefallen, dass Sie es auf einem Raspberry Pi Armprozessor verfügt.

Für das Flanell-Daemon-Set haben Sie:

``` nodeSelector:
beta.kubernetes.io/arch: amd64

but your node is labeled with: 

beta.kubernetes.io/arch=arm
```

DaemonSet kann also keinen Pod auf diesem Knoten essen, ändern Sie einfach die Knotenauswahl und es wird funktionieren.
Sie erhalten den Fehler immer noch mit rbac-Berechtigung, aber vielleicht sagt Ihnen @mikedanese , wie Sie ihn beheben können, da ich ihn nicht kenne.

Ah, danke @lukaszo! Ich habe dieses Mal nicht die RPi-spezifische Anleitung befolgt (die ich für k8s 1.5 verwendet habe) und habe diesen Schritt vergessen. Ich hätte es entdeckt, als das Daemon-Set fehlerhaft war, aber wie sich herausstellte, bin ich nicht so weit gekommen. :}

Ich sehe dieses Problem auch, wenn ich die Anweisungen wie hier beschrieben befolge:
https://blog.hypriot.com/post/setup-kubernetes-raspberry-pi-cluster/

hat es nach der Installation des richtigen Flanell-Netzwerk-Pods zum Laufen gebracht.

Ich denke, @jimmycuadra könnte es mit @lukaszo- Kommentar zum

Wenn die Nachricht [apiclient] First node has registered, but is not ready yet mit dem Fluten beginnt, wird der Kubernetes-API-Server ausgeführt, sodass Sie Folgendes tun können:

curl -sSL https://rawgit.com/coreos/flannel/master/Documentation/kube-flannel.yml | kubectl create -f -

Für die Himbeer-Pi-Installation:

curl -sSL https://rawgit.com/coreos/flannel/master/Documentation/kube-flannel.yml | sed "s/amd64/arm/g" | kubectl create -f -

Dann wird es fertig:

[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node has registered, but is not ready yet
[apiclient] First node is ready after 245.050597 seconds
[apiclient] Test deployment succeeded
[token] Using token: 4dc99e............
[apiconfig] Created RBAC rules
[addons] Created essential addon: kube-proxy
[addons] Created essential addon: kube-dns

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run (as a regular user):

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  http://kubernetes.io/docs/admin/addons/

You can now join any number of machines by running the following on each node
as root:

  kubeadm join --token 4dc99e........... 192.168.1.200:6443

Ich hatte das gleiche Problem und habe es folgendermaßen behoben:
du solltest root sein

in der 1.6.0 von kubeadm sollten Sie die Umgebungsvariable $KUBELET_NETWORK_ARGS in der Systemdatei entfernen: /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

dann Dämonen neu starten

systemctl daemon-reload

kubeadm init

das dauert ein bisschen...nach dem erfolg

Laden Sie das Netzwerk-Add-On herunter, das Sie verwenden möchten: http://kubernetes.io/docs/admin/addons/

Calico scheint der beste zu sein, bin mir nicht sicher, aber noch im Test für mich.

@thelastworm
Ich habe es gerade versucht, und es hat nicht funktioniert.
Ubuntu 16.04.2 LTS, kubeadm 1.6.0
Ich habe folgende Schritte gemacht:

1. Bearbeiten Sie /etc/systemd/system/kubelet.service.d/10-kubeadm.conf und entfernen Sie $KUBELET_NETWORK_ARGS
2. kubeadm reset um den vorherigen Startversuch zu bereinigen
3. kubeadm init --token=<VALUE> --apiserver-advertise-address=<IP>

[BEARBEITET]
Es funktionierte, nachdem @srinat999 auf die Notwendigkeit hingewiesen hatte, systemctl daemon-reload vor kubeadm init auszuführen

Die Lösung von @jcorral hat bei mir mit einer Änderung an der Flanell-Bereitstellung funktioniert, da der unsichere API-Port nicht mehr von kubeadm .

curl -sSL https://rawgit.com/coreos/flannel/master/Documentation/kube-flannel.yml | \
kubectl --kubeconfig /etc/kubernetes/admin.conf create -f -

@MaximF Sie müssen systemctl daemon-reload tun, nachdem Sie die conf-Datei geändert haben. Hat bei mir funktioniert.

@jcorral Deine Lösung funktioniert für mich. Vielen Dank.

@MaximF Ich füge einfach die Befehlszeile für den Neustart des Dämons hinzu

kubeadm init wird erfolgreich abgeschlossen, aber wenn ich die Version überprüfe, erhalte ich die folgende Fehlermeldung:

Client-Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.0", GitCommit:"fff5156092b56e6bd60fff75aad4dc9de6b6ef37", GitTreeState:"clean", BuildDate:"2017-03-28T16:36: 33Z", GoVersion:"go1.7.5", Compiler:"gc", Plattform:"linux/amd64"}
Die Verbindung zum Server localhost:8080 wurde abgelehnt - haben Sie den richtigen Host oder Port angegeben?

@haribole
Sie sollten die KUBECONFIG-Umgebungsvariable setzen

Hat jemand Flannel nach den Problemumgehungen im Zusammenhang mit CNI zum Laufen gebracht? Ich kann das Problem "Nicht bereit" lösen, aber wenn ich Flannel ausführe, erhalte ich eine Fehlermeldung, die wie folgt aussieht:

Failed to create SubnetManager: error retrieving pod spec for 'kube-system/kube-flannel-ds-g5cbj': the server does not allow access to the requested resource (get pods kube-flannel-ds-g5cbj)

Pods-Status zeigt "CrashLoopBackOff" an

Sie müssen rbac-Rollen hinzufügen, um Flannel zum Lesen von der API zu autorisieren.

Sie müssen rbac-Rollen hinzufügen, um Flannel zum Lesen von der API zu autorisieren.

Falls sich noch jemand fragt, was das bedeutet, es sieht so aus, als ob Sie kube-flannel-rbac.yml erstellen müssen, bevor Sie Flanell erstellen:

kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml
kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

Ich denke, da ein Root-Problem gelöst und das zugehörige Ticket geschlossen ist , sollten wir auch dieses schließen :)

Nur zur Information: Bei mir funktioniert es jetzt mit den aktualisierten Paketen unter Ubuntu 16.04.

1.6.1 funktioniert bei mir! Vielen Dank an alle, die geholfen haben, diese Lösung zu finden!

Ich habe meinen Kubernetes-Cluster erfolgreich auf centos-release-7-3.1611.el7.centos.x86_64 eingerichtet, indem ich die folgenden Schritte ausführe (ich gehe davon aus, dass Docker bereits installiert ist):

1) (aus /etc/yum.repo.d/kubernetes.repo) baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64-unstable
=> Um das unstable Repository für das neueste Kubernetes 1.6.1 zu verwenden
2) yum install -y kubelet kubeadm kubectl kubernetes-cni
3) (/etc/systemd/system/kubelet.service.d/10-kubeadm.conf) füge "--cgroup-driver=systemd" am Ende der letzten Zeile hinzu.
=> Dies liegt daran, dass Docker systemd für cgroup-driver verwendet, während kubelet cgroupfs für cgroup-driver verwendet.
4) systemctl kubelet aktivieren && systemctl kubelet starten
5) kubeadm init --pod-network-cidr 10.244.0.0/16
=> Wenn Sie bisher --api-advertise-addresses hinzugefügt haben, müssen Sie stattdessen --apiserver-advertise-address verwenden.
6) cp /etc/kubernetes/admin.conf $HOME/
sudo chown $(id -u):$(id -g) $HOME/admin.conf
export KUBECONFIG=$HOME/admin.conf
=> Ohne diesen Schritt erhalten Sie möglicherweise einen Fehler mit kubectl get
=> Ich habe es nicht mit 1.5.2 gemacht
7) kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml
=> 1.6.0 führt eine rollenbasierte Zugriffskontrolle ein, daher sollten Sie eine ClusterRole und eine ClusterRoleBinding hinzufügen, bevor Sie ein Flannel-Daemonset erstellen
8) kubectl create -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
=> Erstelle ein Flanell-Daemonset
9) (auf jedem Slave-Knoten) kubeadm join --token (Ihr Token) (ip):(port)
=> wie im Ergebnis von kubeadm init gezeigt

Alle oben genannten Schritte sind das Ergebnis der Kombination von Vorschlägen aus verschiedenen Themen rund um Kubernetes-1.6.0, insbesondere kubeadm.

Ich hoffe, das spart Ihnen Zeit.

@eastcirclek @Sliim Du bist großartig

@eastcirclek Dies waren die genauen Schritte, die ich gerade ausgeführt habe, indem ich auch mehrere Foren

Ich habe einen Ubuntu 16.04-Server auf AWS und habe die Schritte befolgt

1. Bearbeiten Sie /etc/systemd/system/kubelet.service.d/10-kubeadm.conf und entfernen Sie $KUBELET_NETWORK_ARGS
2. kubeadm reset, um den vorherigen Startversuch zu bereinigen
3. kubeadm init --token=--apiserver-advertise-address=

was anscheinend richtig funktioniert hat, aber wenn ich dann versuche Calico als Netzwerk-Plugin zu installieren, erhalte ich folgende Fehlermeldung
Die Verbindung zum Server localhost:8080 wurde abgelehnt - haben Sie den richtigen Host oder Port angegeben?

Arbeitet das k8s-Team an einem Patch?

Vielen Dank

@overip Ich glaube, dafür ist kein Patch erforderlich ... Sie müssen nur die richtige kubeconfig-Datei angeben, wenn Sie kubectl verwenden. kubeadm hätte es in /etc/kubernetes/admin.conf schreiben sollen.

@jimmycuadra könntest du bitte die Schritte dazu erklären?

@overip Die Ausgabe von kubeadm init hat die Anweisungen:

To start using your cluster, you need to run (as a regular user):

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

Ich persönlich bevorzuge es, die Datei nach $HOME/.kube/config zu kopieren, wo kubectl standardmäßig danach sucht. Dann müssen Sie die Umgebungsvariable KUBECONFIG nicht setzen.

Wenn Sie kubectl von Ihrem lokalen Computer aus verwenden möchten, können Sie scp (oder einfach den Inhalt kopieren und einfügen), um es auf Ihrem eigenen Computer in ~/.kube/config zu schreiben.

Suchen Sie in dieser GitHub-Ausgabe nach "admin.conf", um weitere Informationen zu erhalten. Es wurde ein paar Mal erwähnt.

@eastcirclek - habe die Schritte befolgt, aber aus irgendeinem Grund können die Knoten Flanell nicht richtig installieren.
(Hinweis: Auf dem Master ist alles glatt.)

Apr 13 22:31:11 node2 kubelet[22893]: I0413 22:31:11.666206   22893 kuberuntime_manager.go:458] Container {Name:install-cni Image:quay.io/coreos/flannel:v0.7.0-amd64 Command:[/bin/sh -c set -e -x; cp -f /etc/kube-flannel/cni-conf.json /etc/cni/net.d/10-flannel.conf; while true; do sleep 3600; done] Args:[] WorkingDir: Ports:[] EnvFrom:[] Env:[] Resources:{Limits:map[] Requests:map[]} VolumeMounts:[{Name:cni ReadOnly:false MountPath:/etc/cni/net.d SubPath:} {Name:flannel-cfg ReadOnly:false MountPath:/etc/kube-flannel/ SubPath:} {Name:flannel-token-g65nf ReadOnly:true MountPath:/var/run/secrets/kubernetes.io/serviceaccount SubPath:}] LivenessProbe:nil ReadinessProbe:nil Lifecycle:nil TerminationMessagePath:/dev/termination-log TerminationMessagePolicy:File ImagePullPolicy:IfNotPresent SecurityContext:nil Stdin:false StdinOnce:false TTY:false} is dead, but RestartPolicy says that we should restart it.
Apr 13 22:31:11 node2 kubelet[22893]: I0413 22:31:11.666280   22893 kuberuntime_manager.go:742] checking backoff for container "install-cni" in pod "kube-flannel-ds-3smf7_kube-system(2e6ad0f9-207f-11e7-8f34-0050569120ff)"
Apr 13 22:31:12 node2 kubelet[22893]: I0413 22:31:12.846325   22893 operation_generator.go:597] MountVolume.SetUp succeeded for volume "kubernetes.io/configmap/2e6ad0f9-207f-11e7-8f34-0050569120ff-flannel-cfg" (spec.Name: "flannel-cfg") pod "2e6ad0f9-207f-11e7-8f34-0050569120ff" (UID: "2e6ad0f9-207f-11e7-8f34-0050569120ff").
Apr 13 22:31:12 node2 kubelet[22893]: I0413 22:31:12.846373   22893 operation_generator.go:597] MountVolume.SetUp succeeded for volume "kubernetes.io/secret/2e6ad0f9-207f-11e7-8f34-0050569120ff-flannel-token-g65nf" (spec.Name: "flannel-token-g65nf") pod "2e6ad0f9-207f-11e7-8f34-0050569120ff" (UID: "2e6ad0f9-207f-11e7-8f34-0050569120ff").

Teilen Sie einfach meine Workaround-Methode. Zuerst wird $KUBELET_NETWORK_ARGS benötigt, ansonsten ist CNI nicht aktiviert/konfiguriert. Das Entfernen und anschließende Wiederherstellen von $KUBELET_NETWORK_ARGS scheint zu kompliziert.
Wenn kubeadm init "[apiclient] First node has registered, but is not ready" anzeigt, ist der k8s-Cluster tatsächlich bereit, Anfragen zu bedienen. Zu diesem Zeitpunkt könnte der Benutzer einfach wie folgt zu Schritt 3/4 von https://kubernetes.io/docs/getting-started-guides/kubeadm/ wechseln.

To start using your cluster, you need to run (as a regular user):

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:  http://kubernetes.io/docs/admin/addons/

Wenn ein Benutzer das Podnetwork installiert, stellen Sie bitte sicher, dass dem Dienstkonto der Podnetwork-Richtlinie ausreichende Berechtigungen erteilt werden. Nehmen wir Flanell als Beispiel. Ich binde einfach die Cluster-Admin-Rolle wie folgt an das Dienstkonto von Flanell. Dies ist möglicherweise nicht ideal, und Sie könnten eine bestimmte Rolle für das Flanell-Servicekonto definieren. Übrigens, wenn ein Benutzer einen anderen Add-On-Dienst wie das Dashboard bereitstellt, muss er dem zugehörigen Dienstkonto auch genügend Berechtigungen erteilen.

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: flannel:daemonset
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: flannel
  namespace:  kube-system

Nachdem der Podnetwork-Server bereit ist, zeigt kubeadm init an, dass der Knoten bereit ist, und der Benutzer kann mit der Anweisung fortfahren.

Nehmen wir Flanell als Beispiel. Ich binde einfach die Cluster-Admin-Rolle wie folgt an das Dienstkonto von Flanell. Dies ist möglicherweise nicht ideal, und Sie könnten eine bestimmte Rolle für das Flanell-Servicekonto definieren.

Es gibt bereits https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel-rbac.yml

Danke an alle für die Hilfe.
Endlich voll funktionsfähige k8s 1.6.1 mit Flanell. Alles ist jetzt in ansible Playbooks.
Getestet auf Centos/RHEL. Die Vorbereitungen begannen auch für Debian-basiert (zB Ubuntu), aber es könnte einige Verfeinerungen erforderlich sein.

https://github.com/ReSearchITEng/kubeadm-playbook/blob/master/README.md

PS: Arbeit basierend auf sjenning/kubeadm-playbook - Vielen Dank @sjenning

Erhalten Sie dies für den Beitritt zu einem Cluster:
[Discovery] Cluster-Info-Discovery-Client erstellt, der Informationen von " https://10.100.2.158 :6443" anfordert
[Discovery] Cluster-Info konnte nicht angefordert werden, wird es erneut versuchen: [configmaps "cluster-info" ist verboten: Benutzer " system:anonymous " kann keine configmaps im Namespace "kube-public" abrufen]
[Discovery] Cluster-Info konnte nicht angefordert werden, wird es erneut versuchen: [configmaps "cluster-info" ist verboten: Benutzer " system:anonymous " kann keine configmaps im Namespace "kube-public" abrufen]

Ich habe den Knoten als SelfHosting gestartet.