Mein Umfeld:
CentOS7-Linux
/etc/hosts:
192.168.0.106 Meister01
192.168.0.107 Knoten02
192.168.0.108 Knoten01
Auf der Maschine master01:
/etc/hostname:
Meister01
Auf der Maschine master01 führe ich Befehle wie folgt aus:
1) Yum install docker-ce kubelet kubeadm kubectl
2) systemctl start docker.service
3) vim /etc/sysconfig/kubelet
BEARBEITEN Sie die Datei:
KUBELET_EXTRA_ARGS="--fail-swap-on=false"
4) systemctl aktivieren docker kubelet
5)kubeadm init --kubernetes-version=v1.12.0 --pod-network-cidr=10.244.0.0/16 servicecidr=10.96.0.0/12 --ignore-preflight-errors=all
DANN
E1002 23:32:36.072441 49157 kubelet.go:2236] Knoten "master01" nicht gefunden
E1002 23:32:36.172630 49157 kubelet.go:2236] Knoten "master01" nicht gefunden
E1002 23:32:36.273892 49157 kubelet.go:2236] Knoten "master01" nicht gefunden
time="2018-10-02T23:32:36+08:00" level=info msg="shim docker-containerd-shim gestartet" address="/containerd-shim/moby/52fbcdb7864cdf8039ded99b501447f13ba81a3897579fb64581c855653f369a/shim.sfalock" debug= pid=49212
E1002 23:32:36.359984 49157 Reflektor.go:134] k8s.io/kubernetes/pkg/kubelet/kubelet.go:451: Fehler beim Auflisten von *v1.Node: https://192.168.0.106 :6443/api/ abrufen v1/nodes?fieldSelector=metadata.name%3Dmaster01&limit=500&resourceVersion=0: tcp wählen 192.168.0.106:6443: Verbinden: Verbindung abgelehnt
I1002 23:32:36.377368 49157 kubelet_node_status.go:276] Einstellen der Knotenanmerkung, um das Anhängen/Abtrennen des Volume-Controllers zu aktivieren
E1002 23:32:36.380290 49157 kubelet.go:2236] Knoten "master01" nicht gefunden
E1002 23:32:36.380369 49157 Reflektor.go:134] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:47: Fehler beim Auflisten von *v1.Pod: https://192.168.0.106 :6443/ abrufen api/v1/pods?fieldSelector=spec.nodeName%3Dmaster01&limit=500&resourceVersion=0: tcp wählen 192.168.0.106:6443: Verbinden: Verbindung abgelehnt
E1002 23:32:36.380409 49157 reflect.go:134] k8s.io/kubernetes/pkg/kubelet/kubelet.go:442: Fehler beim Auflisten von *v1.Service: Get https://192.168.0.106 :6443/api/ v1/services?limit=500&resourceVersion=0: tcp wählen 192.168.0.106:6443: verbinden: Verbindung abgelehnt
time="2018-10-02T23:32:36+08:00" level=info msg="shim docker-containerd-shim gestartet" address="/containerd-shim/moby/f621eca36ce85e815172c37195ae7ac929112c84f3e37d16dd39c7e44ab13b0c/shim.falocks" debug pid=49243
I1002 23:32:36.414930 49157 kubelet_node_status.go:70] Versuch, den Knoten master01 zu registrieren
E1002 23:32:36.416627 49157 kubelet_node_status.go:92] Der Knoten "master01" kann nicht beim API-Server registriert werden: Post https://192.168.0.106 :6443/api/v1/nodes: dial tcp 192.168.0.106:6443: connect : Verbindung abgelehnt
time="2018-10-02T23:32:36+08:00" level=info msg="shim docker-containerd-shim gestartet" address="/containerd-shim/moby/db3f5acb415581d85aef199bea3f85432437c7ef00d357dca1b5684ed95b5591/shim.sockse" debug= pid=49259
E1002 23:32:36.488013 49157 kubelet.go:2236] Knoten "master01" nicht gefunden
time="2018-10-02T23:32:36+08:00" level=info msg="shim docker-containerd-shim gestartet" address="/containerd-shim/moby/505110c39ed4cd5b3fd4fb863012017a71fa782671ead943491afbf38310ffe0/shim.socke" debug=fals pid=49275
E1002 23:32:36.588919 49157 kubelet.go:2236] Knoten "master01" nicht gefunden
E1002 23:32:36.691338 49157 kubelet.go:2236] Knoten "master01" nicht gefunden
Ich habe es oft versucht!
Die erste Fehlermeldung: Client-CA-Datei kann nicht geladen werden /etc/kubernetes/pki/ca.crt: open /etc/kubernetes/pki/ca.crt: no such file or directory
Die erste Fehlermeldung: Client-CA-Datei kann nicht geladen werden /etc/kubernetes/pki/ca.crt: open /etc/kubernetes/pki/ca.crt: no such file or directory
hallo, hier ein paar fragen:
1) beendet kubeadm init und druckt es ein Boostrap-Token?
2) Container-Laufzeitversion?
3) sind die kubelet und kubeadm Version 1.12?
/Priorität braucht mehr Beweise
muss systemctl start kubelet ausführen, bevor kubeadm init
Ich habe das gleiche Problem, weil der Kern der Tasse weniger als 2 ist
gleicher Fehler
@javacppc wie hast du das gelöst? Wenn ich systemctl start kubelet ausgeführt habe, bekomme ich error code
gleiches Problem mit Kubernetes 1.12.2.
@Javacppc wie hast du das gelöst?
gleicher Fehler
gleicher Fehler
Hallo Leute,
Ich stehe hier vor dem gleichen Problem, wenn ich den Cluster starte, habe ich die Nachricht vom Token erhalten, aber ich kann kein Cloud-Gewebe installieren:
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
The connection to the server 192.168.56.104:6443 was refused - did you specify the right host or port?
Wenn ich zu den Protokollen gehe, bekomme ich die Meldung zum Knotennamen:
Dec 02 22:27:55 kubemaster5 kubelet[2838]: E1202 22:27:55.128645 2838 kubelet.go:2236] node "kubemaster5" not found
Kann mir bitte jemand etwas Licht schicken?
Dankeschön!
Mein Problem ist gelöst und eigentlich ist es kein Fehler, es liegt daran, dass der Apiserver aus irgendeinem Grund nicht gestartet wurde.
"Apiserver konnte aus irgendeinem Grund nicht gestartet werden"? Kannst du ein paar Details nennen??
Ich habe mein Problem vor einigen Tagen gelöst. Update von 1.11.4 -> 1.12.3. Ich habe:
api-server
- läuft in einer bestimmten virtuellen Schnittstelle mit eigenem Netzwerk. ( blankes Metall ).kubeadm init/join
mit dem Flag apiserver-advertise-address
startete es auf einer bestimmten Schnittstelle, aber Pakete mit Einstellungen/Zustandsprüfungen durchlaufen die Standardroute der Routingtabelle (Standardschnittstelle). Hat Parameter bind-address
in /etc/kubernetes/manifests/kube-apiserver.yaml
bei der Bindung an die IP der virtuellen Schnittstelle geholfen.flannel
- die gleiche Situation mit dem Netzwerk nach dem Erstellen von controller
, scheduler
Pods. DNS-Bereitstellung fehlgeschlagen, weil connection refused
an ClusterIP des API-Servers 10.96.0.1:443
. (Standard-Routing-Tabelle) Ich habe node-ip
des Clusterknotens durch das Flag --node-ip
in /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
mit der IP der virtuellen Schnittstelle angegeben.Danach habe ich den Knoten mit der Version 1.12.3 fertig. Die hilfreichsten Informationen waren in docker logs + kubectl logs
gleiches Problem hier mit v1.13.0
Gleiches Problem hier mit Kubernetes v1.13.0
CentOS 7
docker-ce 18.06 (neueste validierte Version)
dockerd: aktiv, läuft
kubelet: aktiv, läuft
Selinux: deaktiviert
Firewall: deaktiviert
FEHLER ist:
kubelet[98023]: E1212 21:10:01.708004 98023 kubelet.go:2266] node "node1" not found
/etc/hosts enthält den Knoten, er ist pingebar, er ist erreichbar -- tatsächlich macht er einen Single-Master-Single-Worker (dh ein verdorbener Knoten).
Wo sucht K8S nach diesem Wert? in /etc/hosts?
Ich kann Fehler beheben und bei Bedarf weitere Beweise liefern.
--> beendet kubeadm init und druckt es ein Boostrap-Token?
Es endet mit einem langen Fehler:
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [node1 localhost] and IPs [10.10.128.186 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [node1 localhost] and IPs [10.10.128.186 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[kubelet-check] Initial timeout of 40s passed.
Unfortunately, an error has occurred:
timed out waiting for the condition
This error is likely caused by:
- The kubelet is not running
- The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)
If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'
Additionally, a control plane component may have crashed or exited when started by the container runtime.
To troubleshoot, list all containers using your preferred container runtimes CLI, e.g. docker.
Here is one example how you may list all Kubernetes containers running in docker:
- 'docker ps -a | grep kube | grep -v pause'
Once you have found the failing container, you can inspect its logs with:
- 'docker logs CONTAINERID'
error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster
HINWEIS: Keiner der nach dem Timeout vorgeschlagenen Befehle hat hier etwas Nennenswertes gemeldet.
kubelet- und kubeadm-Version?
---> 1.13.0
kubeadm-Version: &version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.0", GitCommit:"ddf47ac13c1a9483ea035a79cd7c10005ff21a6d", GitTreeState:"clean", BuildDate:"2018-12-03T21:02: 01Z", GoVersion:"go1.11.2", Compiler:"gc", Plattform:"linux/amd64"}
Sollte nicht auch eine bessere Fehlermeldung als "node not found" mit etwas mehr Klarheit/Ausführlichkeit in den Kube-Logs eingestellt werden?
Vielen Dank
Gleicher Fehler...
$ systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf
Active: active (running) since Fri 2018-12-14 19:05:47 UTC; 2min 2s ago
Docs: https://kubernetes.io/docs/home/
Main PID: 9114 (kubelet)
Tasks: 23 (limit: 4915)
CGroup: /system.slice/kubelet.service
└─9114 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-d
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.862262 9114 kuberuntime_manager.go:657] createPodSandbox for pod "kube-scheduler-pineview_kube-system(7f99b6875de942b000954351c4a
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.862381 9114 pod_workers.go:186] Error syncing pod 7f99b6875de942b000954351c4ac09b5 ("kube-scheduler-pineview_kube-system(7f99b687
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.906855 9114 remote_runtime.go:96] RunPodSandbox from runtime service failed: rpc error: code = Unknown desc = failed to start san
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.906944 9114 kuberuntime_sandbox.go:65] CreatePodSandbox for pod "etcd-pineview_kube-system(b7841e48f3e7b81c3cda6872104ba3de)" fai
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.906981 9114 kuberuntime_manager.go:657] createPodSandbox for pod "etcd-pineview_kube-system(b7841e48f3e7b81c3cda6872104ba3de)" fa
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.907100 9114 pod_workers.go:186] Error syncing pod b7841e48f3e7b81c3cda6872104ba3de ("etcd-pineview_kube-system(b7841e48f3e7b81c3c
Dec 14 19:07:49 pineview kubelet[9114]: E1214 19:07:49.933627 9114 kubelet.go:2236] node "pineview" not found
Dec 14 19:07:50 pineview kubelet[9114]: E1214 19:07:50.033880 9114 kubelet.go:2236] node "pineview" not found
Dec 14 19:07:50 pineview kubelet[9114]: E1214 19:07:50.134064 9114 kubelet.go:2236] node "pineview" not found
Dec 14 19:07:50 pineview kubelet[9114]: E1214 19:07:50.184943 9114 event.go:212] Unable to write event: 'Post https://192.168.1.235:6443/api/v1/namespaces/default/events: dial tcp 192.
Gleicher Fehler:
Ubuntu 18.04.1 LTS
Kubernetes v1.13.1 (mit cri-o 1.11)
Befolgt die Installationsanweisungen auf kubernetes.io:
https://kubernetes.io/docs/setup/independent/install-kubeadm/
https://kubernetes.io/docs/setup/cri/#cri -o
systemctl enable kubelet.service
kubeadm init --pod-network-cidr=192.168.0.0/16 --cri-socket=/var/run/crio/crio.sock
/etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.1.1 master01.mydomain.tld master01
::1 master01.mydomain.tld master01
/etc/hostname
systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf
Active: active (running) since Tue 2018-12-18 16:19:54 CET; 20min ago
Docs: https://kubernetes.io/docs/home/
Main PID: 10148 (kubelet)
Tasks: 21 (limit: 2173)
CGroup: /system.slice/kubelet.service
└─10148 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --container-runtime=remote --container-runtime-endpoint=/var/run/crio/crio.sock --resolv-conf=/run/systemd/resolve/resolv.conf
Dec 18 16:40:52 master01 kubelet[10148]: E1218 16:40:52.795313 10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:52 master01 kubelet[10148]: E1218 16:40:52.896277 10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:52 master01 kubelet[10148]: E1218 16:40:52.997864 10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.098927 10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.200355 10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.281586 10148 reflector.go:134] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:47: Failed to list *v1.Pod: Get https://192.168.178.27:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dmaster01limit=500&resourceVersion=0: dial tcp 192.168.178.27:6443: connect: connection refused
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.282143 10148 reflector.go:134] k8s.io/kubernetes/pkg/kubelet/kubelet.go:444: Failed to list *v1.Service: Get https://192.168.178.27:6443/api/v1/services?limit=500&resourceVersion=0: dial tcp 192.168.178.27:6443: connect: connection refused
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.283945 10148 reflector.go:134] k8s.io/kubernetes/pkg/kubelet/kubelet.go:453: Failed to list *v1.Node: Get https://192.168.178.27:6443/api/v1/nodes?fieldSelector=metadata.name%3Dmaster01limit=500&resourceVersion=0: dial tcp 192.168.178.27:6443: connect: connection refused
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.301468 10148 kubelet.go:2266] node "master01" not found
Dec 18 16:40:53 master01 kubelet[10148]: E1218 16:40:53.402256 10148 kubelet.go:2266] node "master01" not found
@fhemberger Ich habe mein Problem herausgefunden. Es hat snap
, um Docker zu installieren. Wenn ich das deinstalliert und mit apt
neu installiert habe, hat kubeadm gut funktioniert.
@cjbottaro Ich verwende Docker überhaupt nicht, sondern cri-o.
gleiches Problem hier mit v1.13.1
Wenn Sie systemd und cri-o verwenden, stellen Sie sicher, dass Sie es als cgroup-Treiber in /var/lib/kubelet/config.yaml
festlegen (oder übergeben Sie das Snippet unten als Teil von kubeadm init --config=config.yaml
).
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd
Wenn Sie dies in Ihren Kubelet-Logs bemerken:
remote_runtime.go:96] RunPodSandbox from runtime service failed: rpc error: code = Unknown desc = cri-o configured with systemd cgroup manager, but did not receive slice as parent: /kubepods/besteffort/…
Ich bin heute auf das gleiche Problem gestoßen.
Ich habe es behoben, indem ich rm -rf /var/lib/kubelet/ entfernt und neu installiert habe
@JishanXing danke! Dies löste auch mein Problem mit der Ausführung auf Raspbian Sketch lite
Ich habe es behoben, indem ich /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf entfernt habe
Es wäre besser, den Befehl kubeadm reset
.
@fhemberger wie man es löst , die gleiche Frage, danke
Ich bin auf das gleiche Problem gestoßen, als ich k8s von 1.13.3 auf 1.13.4 aufrüste ...
Ich löse es, nachdem ich /etc/kubernetes/manifests/kube-scheduler.yaml
bearbeitet habe. Ändern Sie die Image-Version
image: k8s.gcr.io/kube-scheduler:v1.13.3 ==> image: k8s.gcr.io/kube-scheduler:v1.13.4
das gleiche gilt für kube-controller-manager.yaml und kube-apiserver.yaml.
Der neueste Weg ist das Hinzufügen der Option --image-repository Registry.aliyuncs.com/google_containers , meine k8s-Version ist 1.14.0, Docker-Version: 18.09.2,
` kubeadm init --image-repository Registry.aliyuncs.com/google_containers --kubernetes-version v1.14.0 --pod-network-cidr=192.168.0.0/16
[init] Kubernetes-Version verwenden: v1.14.0
[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/
[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] Generieren von "front-proxy-ca"-Zertifikat und Schlüssel
[certs] Generieren von "Front-Proxy-Client"-Zertifikat und Schlüssel
[certs] Generieren von "ca"-Zertifikat und -Schlüssel
[certs] Generieren von "apiserver" -Zertifikat und -Schlüssel
[certs] Apiserver-Serving-Zertifikat ist für DNS-Namen [jin-virtual-machine kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] und IPs [10.96.0.1 192.168.232.130] signiert
[certs] Generieren von "apiserver-kubelet-client"-Zertifikat und -Schlüssel
[certs] Generieren von "etcd/ca"-Zertifikat und Schlüssel
[certs] Generieren von "etcd/server"-Zertifikat und Schlüssel
[certs] etcd/server Serving Cert ist für DNS-Namen [jin-virtual-machine localhost] und IPs [192.168.232.130 127.0.0.1 ::1] signiert.
[certs] Generieren von "etcd/peer"-Zertifikat und Schlüssel
[certs] etcd/peer Serving Zertifikat ist für DNS-Namen [jin-virtual-machine localhost] und IPs [192.168.232.130 127.0.0.1 ::1] signiert.
[certs] Generieren von "apiserver-etcd-client"-Zertifikat und -Schlüssel
[certs] Generieren von "etcd/healthcheck-client"-Zertifikat und -Schlüssel
[certs] Generieren von "sa"-Schlüssel und öffentlichem Schlüssel
[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
[apiclient] Alle Komponenten der Steuerungsebene sind nach 17.004356 Sekunden fehlerfrei
[upload-config] speichert die in ConfigMap verwendete Konfiguration "kubeadm-config" im "kube-system" Namespace
[kubelet] Erstellen einer ConfigMap "kubelet-config-1.14" im Namespace kube-system mit der Konfiguration für die Kubelets im Cluster
[upload-certs] Überspringen der Phase. Siehe --experimental-upload-certs
[mark-control-plane] Markieren des Knotens jin-virtual-machine als control-plane durch Hinzufügen des Labels "node-role.kubernetes.io/master=''"
[mark-control-plane] Markieren des Knotens jin-virtual-machine als Control-Plane durch Hinzufügen der Taints [node-role.kubernetes.io/ master:NoSchedule ]
[bootstrap-token] Token verwenden: xucir0.o4kzo3qqjyjnzphl
[bootstrap-token] Bootstrap-Token konfigurieren, Cluster-Info ConfigMap, RBAC-Rollen
[bootstrap-token] konfigurierte RBAC-Regeln, um es Node-Bootstrap-Tokens zu ermöglichen, CSRs zu posten, damit Knoten langfristige Zertifikatsanmeldeinformationen erhalten können
[bootstrap-token] konfigurierte RBAC-Regeln, damit der csrapprover-Controller CSRs von einem Node-Bootstrap-Token automatisch genehmigen kann
[bootstrap-token] konfigurierte RBAC-Regeln, um die Zertifikatsrotation für alle Knoten-Client-Zertifikate im Cluster zuzulassen
[bootstrap-token] erstellt die ConfigMap "cluster-info" im Namespace "kube-public"
[Addons] Angewandtes wesentliches Addon: CoreDNS
[Addons] Angewandtes essentielles Addon: kube-proxy
Ihre Kubernetes-Steuerungsebene wurde erfolgreich initialisiert!
Um Ihren Cluster zu verwenden, müssen Sie als normaler Benutzer Folgendes ausführen:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
Sie sollten jetzt ein Pod-Netzwerk für den Cluster bereitstellen.
Führen Sie "kubectl apply -f [podnetwork].yaml" mit einer der unter aufgeführten Optionen aus:
https://kubernetes.io/docs/concepts/cluster-administration/addons/
Dann können Sie einer beliebigen Anzahl von Worker-Knoten beitreten, indem Sie auf jedem als Root Folgendes ausführen:
kubeadm Join 192.168.232.130:6443 --token xucir0.o4kzo3qqjyjnzphl
--discovery-token-ca-cert-hash sha256:022048b22926a2cb2f8295ce2e3f1f6fa7ffe1098bc116f7d304a26bcfb78656
`
Hatte das gleiche Problem mit Kubernetes v1.14.1 und cri-o v1.14.0 auf einer GCP Ubuntu 18.04 VM. Bei der Verwendung von Docker funktionierte es jedoch gut. Verweis: https://github.com/cri-o/cri-o/issues/2357
Mein Problem war mit den verschiedenen cgroup-Treibern. CRIO verwendet standardmäßig systemd, kubelet verwendet standardmäßig cgroupfs.
cat /etc/crio/crio.conf | grep cgroup
# cgroup_manager is the cgroup management implementation to be used
cgroup_manager = "systemd"
In diesem Fall siehe https://kubernetes.io/docs/setup/independent/install-kubeadm/#configure -cgroup-driver-used-by-kubelet-on-master-node
Schreiben Sie einfach die Datei
echo "KUBELET_EXTRA_ARGS=--cgroup-driver=systemd" > /etc/default/kubelet
und führen Sie danach kubeadm init aus. Oder ändern Sie cgroup_manager in cgroupfs
im Gegensatz zu docker sind cri-o und containerd in Bezug auf die Erkennung von Cgroup-Treibern etwas schwieriger zu verwalten, aber es gibt einige Pläne, dies von kubeadm zu unterstützen.
docker wird bereits behandelt.
Es gibt also anscheinend keine Lösung, außer den Cluster $(yes | kubeadm reset) zurückzusetzen, was meiner Meinung nach keine Lösung ist!
Das Ändern des Image-Repositorys hat für mich funktioniert, aber dies ist keine großartige Lösung.
--image-repository Registry.aliyuncs.com/google_containers
mein Fall hat damit funktioniert
sed -i 's/cgroup-driver=systemd/cgroup-driver=cgroupfs/g' /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Ich habe das gleiche Problem. Ich verwende kubeadm init --config=init-config.yaml
und bin fehlgeschlagen, diese Datei wurde von kubeadm generiert. es gibt ein Feld AdvertiseAddress default is 1.2.3.4 in file , wodurch der Start von etcd contianer fehlschlägt. wenn ich auf 127.0.0.1 wechsle, startet etcd contianer erfolgreich und kubeadm init erfolgreich
Um dieses Problem zu lösen, verwenden Sie docker ps -a
Liste aller Container Überprüfen Sie, ob einige von ihnen beendet wurden. Wenn ja, verwenden Sie docker logs CONTIANER_ID
sehen Sie, was passiert ist. ich hoffe es hilft
Hallo zusammen, hat jemand eine Lösung? Gleiches Problem hier, aber mit k3s .
@MateusMac Sie sollten wahrscheinlich auch einen Fehlerbericht gegen k3s öffnen.
Habe eine Woche lang daran gearbeitet, dass kubeadm
weiterarbeitet
Ubuntu 18.04
docker 18.06-2-ce
k8s 1.15.1
sudo kubeadm init --pod-network-cidr=10.244.0.0/16
Fails with:
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[kubelet-check] Initial timeout of 40s passed.
Unfortunately, an error has occurred:
timed out waiting for the condition
This error is likely caused by:
- The kubelet is not running
- The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)
If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'
Additionally, a control plane component may have crashed or exited when started by the container runtime.
To troubleshoot, list all containers using your preferred container runtimes CLI, e.g. docker.
Here is one example how you may list all Kubernetes containers running in docker:
- 'docker ps -a | grep kube | grep -v pause'
Once you have found the failing container, you can inspect its logs with:
- 'docker logs CONTAINERID'
error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster
Die Kubelet-Protokolle zeigen, dass die Knoten einfach nicht gefunden werden können, um an der ersten Basis vorbeizukommen:
warproot<strong i="15">@warp02</strong>:~$ systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf
Active: active (running) since Sun 2019-08-04 18:22:26 AEST; 5min ago
Docs: https://kubernetes.io/docs/home/
Main PID: 12569 (kubelet)
Tasks: 27 (limit: 9830)
CGroup: /system.slice/kubelet.service
└─12569 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-dri
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.322762 12569 kuberuntime_sandbox.go:68] CreatePodSandbox for pod "kube-scheduler-warp02_kube-system(ecae9d12d3610192347be3d1aa5aa552)"
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.322806 12569 kuberuntime_manager.go:692] createPodSandbox for pod "kube-scheduler-warp02_kube-system(ecae9d12d3610192347be3d1aa5aa552)
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.322872 12569 pod_workers.go:190] Error syncing pod ecae9d12d3610192347be3d1aa5aa552 ("kube-scheduler-warp02_kube-system(ecae9d12d36101
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.373094 12569 kubelet.go:2248] node "warp02" not found
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.375587 12569 reflector.go:125] k8s.io/client-go/informers/factory.go:133: Failed to list *v1beta1.CSIDriver: Get https://10.1.1.4:6443
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.473295 12569 kubelet.go:2248] node "warp02" not found
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.573567 12569 kubelet.go:2248] node "warp02" not found
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.575495 12569 reflector.go:125] k8s.io/client-go/informers/factory.go:133: Failed to list *v1beta1.RuntimeClass: Get https://10.1.1.4:6
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.590886 12569 event.go:249] Unable to write event: 'Post https://10.1.1.4:6443/api/v1/namespaces/default/events: dial tcp 10.1.1.4:6443
Aug 04 18:28:03 warp02 kubelet[12569]: E0804 18:28:03.673767 12569 kubelet.go:2248] node "warp02" not found
Ich sollte beachten, dass ich auf diesen Bare-Metal-Maschinen mehrere NICs habe:
warproot<strong i="6">@warp02</strong>:~$ ifconfig
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
inet6 fe80::42:feff:fe65:37f prefixlen 64 scopeid 0x20<link>
ether 02:42:fe:65:03:7f txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 6 bytes 516 (516.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp35s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.2 netmask 255.255.255.0 broadcast 10.0.0.255
inet6 fe80::32b5:c2ff:fe02:410b prefixlen 64 scopeid 0x20<link>
ether 30:b5:c2:02:41:0b txqueuelen 1000 (Ethernet)
RX packets 46 bytes 5821 (5.8 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 70 bytes 7946 (7.9 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp6s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.1.1.4 netmask 255.255.255.0 broadcast 10.1.1.255
inet6 fd42:59ff:1166:0:25a7:3617:fee6:424e prefixlen 64 scopeid 0x0<global>
inet6 fe80::1a03:73ff:fe44:5694 prefixlen 64 scopeid 0x20<link>
inet6 fd9e:fdd6:9e01:0:1a03:73ff:fe44:5694 prefixlen 64 scopeid 0x0<global>
ether 18:03:73:44:56:94 txqueuelen 1000 (Ethernet)
RX packets 911294 bytes 1361047672 (1.3 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 428759 bytes 29198065 (29.1 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 17
ib0: flags=4099<UP,BROADCAST,MULTICAST> mtu 4092
unspec A0-00-02-10-FE-80-00-00-00-00-00-00-00-00-00-00 txqueuelen 256 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ib1: flags=4099<UP,BROADCAST,MULTICAST> mtu 4092
unspec A0-00-02-20-FE-80-00-00-00-00-00-00-00-00-00-00 txqueuelen 256 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 25473 bytes 1334779 (1.3 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 25473 bytes 1334779 (1.3 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Ich weiß nicht, ob das ein Problem ist, aber ich habe meine /etc/hosts
Datei eingerichtet als
warproot<strong i="7">@warp02</strong>:~$ cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
# add our host name
10.1.1.4 warp02 warp02.ad.xxx.com
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
# add our ipv6 host name
fd42:59ff:1166:0:25a7:3617:fee6:424e warp02 warp02.ad.xxx.com
warproot<strong i="8">@warp02</strong>:~$
Es ist also eingerichtet (glaube ich), die NIC 10.1.1.4 als "Netzwerk" für k8s zu betrachten
nslookup gegen den Knotennamen scheint gut zu funktionieren:
warproot<strong i="13">@warp02</strong>:~$ nslookup warp02
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: warp02.ad.xxx.com
Address: 10.1.1.4
Name: warp02.ad.xxx.com
Address: fd42:59ff:1166:0:25a7:3617:fee6:424e
warproot<strong i="14">@warp02</strong>:~$
Ich habe die Installationsdokumentation von kubeadm
mehrmals durchgesehen.
Seltsam. Es kann das Netzwerk einfach nicht finden.
Verblüfft.
Für Version 1.15.3
ich dies unter Ubuntu 18.04 beheben, indem ich hinzufüge
kind: InitConfiguration
nodeRegistration:
kubeletExtraArgs:
cgroup-driver: "systemd"
in meine kubeadm-Konfiguration und dann kubeadm init
ausführen
Ich habe hier das gleiche Problem mit Version 1.15.3 unter Ubuntu 18.04
@kris-nova Ich würde mich sehr freuen, wenn Sie angeben könnten, wo sich diese Konfigurationsdatei befindet :-)
UPDATE: Ich kann nicht wirklich sagen warum, aber es funktioniert jetzt, ohne irgendeine Konfiguration zu ändern!
(Hinweis: Ich weiß nicht, ob es damit zusammenhängt, aber ich habe Docker von v.19.03.1 auf v.19.03.2 aktualisiert, bevor ich es erneut mit kubeadm init
versuche)
Beim Ausführen von kubeadm init wurde der folgende Fehler angezeigt, dh Nodexx wurde nicht gefunden.
[ root@node01 ~]# journalctl -xeu kubelet
07. Nov 10:34:02 node01 kubelet[2968]: E1107 10:34:02.682095 2968 kubelet.go:2267] Knoten "node01" nicht gefunden
07. Nov 10:34:02 node01 kubelet[2968]: E1107 10:34:02.782554 2968 kubelet.go:2267] Knoten "node01" nicht gefunden
07. Nov 10:34:02 node01 kubelet[2968]: E1107 10:34:02.829142 2968 reflect.go:123] k8s.io/client-go/informers/factory.go:134: Fehler beim Auflisten von *v1beta1.CSID
07. Nov 10:34:02 node01 kubelet[2968]: E1107 10:34:02.884058 2968 kubelet.go:2267] Knoten "node01" nicht gefunden
07. Nov 10:34:02 node01 kubelet[2968]: E1107 10:34:02.984510 2968 kubelet.go:2267] Knoten "node01" nicht gefunden
07. Nov 10:34:03 node01 kubelet[2968]: E1107 10:34:03.030884 2968 Reflektor.go:123]
Gelöst über:
gleicher Fehler
In meinem Fall wurde das durch eine Zeitdrift im Masterknoten verursacht, _die nach einem Stromausfall passierte_.
Ich habe das durch Laufen behoben
# Correcting the time as mentioned here https://askubuntu.com/a/254846/861548
sudo service ntp stop
sudo ntpdate -s time.nist.gov
sudo service ntp start
# Then restarting the kubelet
sudo systemctl restart kubelet.service
# I also had to run daemon-reload as I got the following warning
# Warning: The unit file, source configuration file or drop-ins of kubelet.service changed on disk. Run 'systemctl daemon-reload' to reload units.
sudo systemctl daemon-reload
# I also made another restart, which I don't know whether needed or not
sudo systemctl restart kubelet.service
Ich habe mein gleiches Problem behoben node "xxxx" not found
, Versuchen Sie, das Containerprotokoll zu sehen, verwenden Sie Docker-Protokolle container_id , dann sehe ich, dass der Apiserver versucht, eine Verbindung zu 127.0.0.1:2379 herzustellen , die Datei bearbeiten ·
Hilfreichster Kommentar
Gleiches Problem hier mit Kubernetes v1.13.0
CentOS 7
docker-ce 18.06 (neueste validierte Version)
dockerd: aktiv, läuft
kubelet: aktiv, läuft
Selinux: deaktiviert
Firewall: deaktiviert
FEHLER ist:
kubelet[98023]: E1212 21:10:01.708004 98023 kubelet.go:2266] node "node1" not found
/etc/hosts enthält den Knoten, er ist pingebar, er ist erreichbar -- tatsächlich macht er einen Single-Master-Single-Worker (dh ein verdorbener Knoten).
Wo sucht K8S nach diesem Wert? in /etc/hosts?
Ich kann Fehler beheben und bei Bedarf weitere Beweise liefern.
--> beendet kubeadm init und druckt es ein Boostrap-Token?
Es endet mit einem langen Fehler:
HINWEIS: Keiner der nach dem Timeout vorgeschlagenen Befehle hat hier etwas Nennenswertes gemeldet.
kubelet- und kubeadm-Version?
---> 1.13.0
kubeadm-Version: &version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.0", GitCommit:"ddf47ac13c1a9483ea035a79cd7c10005ff21a6d", GitTreeState:"clean", BuildDate:"2018-12-03T21:02: 01Z", GoVersion:"go1.11.2", Compiler:"gc", Plattform:"linux/amd64"}
Sollte nicht auch eine bessere Fehlermeldung als "node not found" mit etwas mehr Klarheit/Ausführlichkeit in den Kube-Logs eingestellt werden?
Vielen Dank