Ich habe das gleiche Problem. Ich habe auch versucht, das Netzwerk-ARGS zu entfernen, wie in einem anderen Problem vorgeschlagen. Es hängt immer noch bei waiting for control plane to be ready .

Haben Sie Daemon neu geladen und den Kubelet-Dienst neu gestartet, nachdem Sie die Änderungen vorgenommen haben? Es funktionierte nach dem Wechsel des Treibers und des Kommentarnetzwerks. Für mich dauert es 10 bis 11 Minuten, bis das Kontrollflugzeug das erste Mal fertig ist, ich würde vorschlagen, es für das erste Mal 15 Minuten stehen zu lassen.

Ich habe den Daemon neu geladen und den Kubelet-Dienst jedes Mal neu gestartet. Ich habe das Setup sogar die ganze Nacht ungestört gelassen, aber es wartete immer noch auf das Kontrollflugzeug.

Ich habe den Daemon ( systemctl daemon-reload ) neu geladen und auch Kubelet neu gestartet. Ich führe kubeadm reset aus, bearbeite die Dienstkonfiguration, lade den Daemon neu und führe dann kubeadm init aus.

Apiserver- und etcd-Docker-Container können nicht ausgeführt werden, nachdem die Netzwerkoptionen auskommentiert wurden. Ich habe auch versucht, weave-net manuell zu installieren, damit das Verzeichnis cni config aufgefüllt wird, aber das hat auch nicht funktioniert. Dazu habe ich weave installiert, weave setup und weave launch . Ich weiß nicht wirklich, wie Kubeadm Docker konfiguriert, um die CNI-Einstellungen zu verwenden, aber vielleicht fehlt mir hier ein Schritt.

Sieht so aus, als ob Kubelet den Kube-API-Server nicht erreichen kann.

Mir ist aufgefallen, dass etcd nicht auf Port 2380 lauschen konnte, ich habe diese Schritte erneut befolgt und mein Cluster gestartet:

• Führen Sie kubeadm reset aus, um alle am Server vorgenommenen Änderungen zu entfernen.
• Bringen Sie die Maschine in den Ausgangszustand zurück. Durch Neuinstallation von kubeadm (um die ursprünglichen Konfigurationsdateien wiederherzustellen).
• Entfernen Sie Docker-Container im Zusammenhang mit Kubernetes, falls vorhanden.
• Holen und installieren Sie weben. Führen Sie es nicht aus.
• Starten Sie den Server neu.
• Stellen Sie sicher, dass kubelet nicht ausgeführt wird.
• Führen Sie weave setup und weave launch .
• Führen Sie kubeadm init .

Wenn Sie das Weben von Hand loswerden möchten ...

• Führen Sie weave reset
• Wenden Sie das Weave-Addon für Kubernetes 1.6 an.
• Starten Sie den Server neu.

Kubeadm Join sollte auf anderen Servern funktionieren.

@Yengas Kannst du bitte weitere Details zu den Webschritten angeben? Hast du sie auf allen Nodes ausgeführt oder nur auf dem Master?

@jruels nur der Masterknoten. Weave ist nur eine einzelne Binärdatei. Der Setup-Befehl ohne Argumente lädt Weave-Docker-Images herunter und erstellt die CNI-Konfiguration. Der Startbefehl ohne Argumente startet die Webcontainer nur auf dem Host.

@Yengas Ich bin mir immer noch nicht sicher, was du meinst mit - " Holen und installieren Sie Weave. Führen Sie es nicht aus". ?

Was sagen die Apiserver-Logs?

@rushabh268
Um Weave zu installieren, führen Sie Folgendes auf dem Master aus
sudo curl -L git.io/weave -o /usr/local/bin/weave && chmod a+x /usr/local/bin/weave
Dann renne
weave setup
Wenn das abgeschlossen ist, laufen
weave launch

das brauchst du nicht. kubectl apply -f https://git.io/weave-kube-1.6 sollte ausreichen.

Die Protokolle des API-Servers sagen genau dasselbe aus, wie ich es im Fehler erwähnt habe. Außerdem kann ich kubectl nicht ausführen, da Kubernetes nicht installiert ist

@jruels Ich werde es ausprobieren und diesen Thread aktualisieren!

In der Fehlerbeschreibung gibt es kubeadm-Protokolle und kubelet-Protokolle. Es gibt keine APIServer-Protokolle.

@mikedanese Wie erhalte ich die Apiserver-Protokolle?
@jruels Ich bin in der Lage, Weben zu bringen
@Yengas Auch nachdem ich Ihren Schritten gefolgt bin, sehe ich den folgenden Fehler in den Kubelet-Protokollen:
Apr 06 12:55:56 hostname kubelet[5174]: E0406 12:55:56.858931 5174 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.556067 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://10.X.X.X:6443/api/v1/services?resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.557441 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://10.X.X.X:6443/api/v1/nodes?fieldSelector=metadata.name%3Dhostname&resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:57 hostname kubelet[5174]: E0406 12:55:57.558822 5174 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://10.X.X.X:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0: dial tcp 10.X.X.X:6443: getsockopt: connection refused Apr 06 12:55:58 hostname kubelet[5174]: I0406 12:55:58.347460 5174 kubelet_node_status.go:230] Setting node annotation to enable volume controller attach/detach Apr 06 12:55:58 hostname kubelet[5174]: I0406 12:55:58.405762 5174 kubelet_node_status.go:77] Attempting to register node hostname1

Außerdem habe ich die Firewall gestoppt, also bin ich mir nicht sicher, warum mir die Verbindung verweigert wird.

Ich habe das gleiche Problem, das hier gemeldet wird.

Schneiden Sie meine Systemnachrichten (Master Node) aus, während es feststeckte, nur für den Fall, dass es auf etwas hinweist. Übrigens, ich führe das auf Linode durch.

12. April 02:10:00 localhost audit: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=erfolg
12. April 02:10:00 localhost audit: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=erfolg
12. April 02:10:00 localhost audit: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=erfolg
12. April 02:10:00 localhost systemd: kubelet.service: Wartezeit für Dienst abgelaufen, Neustart geplant.
12. Apr 02:10:00 localhost systemd: Kubelet gestoppt: Der Kubernetes Node Agent.
12. Apr 02:10:00 localhost systemd: Gestartet kubelet: The Kubernetes Node Agent.
12. April 02:10:00 localhost systemd: Tool zur Abrechnung der Systemaktivität wird gestartet ...
12. April 02:10:00 localhost audit: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname= ? addr=? terminal=? res=erfolg
12. April 02:10:00 localhost audit: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname= ? addr=? terminal=? res=erfolg
12. Apr 02:10:00 localhost systemd: Tool zur Abrechnung der Systemaktivität gestartet.
12. Apr 02:10:00 localhost kubelet: I0412 02:10:00.924529 3445 feature_gate.go:144] feature gates: map[]
12. Apr 02:10:00 localhost kubelet: I0412 02:10:00.928973 3445 docker.go:364] Verbinden mit Docker auf unix:///var/run/docker.sock
12. Apr 02:10:00 localhost kubelet: I0412 02:10:00.929201 3445 docker.go:384] Starten Sie den Docker-Client mit Request Timeout=2m0s
12. Apr 02:10:00 localhost kubelet: W0412 02:10:00.941088 3445 cni.go:157] CNI-Konfiguration kann nicht aktualisiert werden: Keine Netzwerke in /etc/cni/net.d gefunden
12. April 02:10:00 localhost kubelet: I0412 02:10:00.948892 3445 manager.go:143] cAdvisor läuft im Container: „/system.slice“
12. April 02:10:00 localhost kubelet: W0412 02:10:00.974540 3445 manager.go:151] Verbindung zum Rkt-API-Dienst nicht möglich: rkt: TCP kann nicht gewählt werden Rkt-API-Dienst: Wählen Sie TCP [::1]:15441: getsockopt: Verbindung abgelehnt
12. Apr 02:10:00 localhost kubelet: I0412 02:10:00.997599 3445 fs.go:117] Dateisystempartitionen: map[/dev/root:{mountpoint:/var/lib/docker/devicemapper major:8 minor:0 fsType:ext4 blockSize:0 }]
12. April 02.10.01 localhost kubelet: I0412 02: 10: 01.001662 3445 manager.go: 198] Maschine: { NumCores: 1 Cpu Frequenz: 2.799.998 Memor yCapacity: 1037021184 MachineID: 5e9a9a0b58984bfb8766dba9afa8a191 S ystemUUID: 5e9a9a0b58984bfb8766dba9afa8a191 BootID: 7ed1a6ff-9848- 437b-9460-981eeefdfe5a Dateisysteme:[{Gerät:/dev/root Kapazität:15447539712 Typ:vfs Inodes:962880 HasInodes:true }] DiskMap:map [43:0:{ Name:nbd0 Major:43 Minor:0 Size:0 Scheduler:none } 43:11:{ Name:nbd11 Major:43 Minor:11 Size:0 Scheduler:none } 43:12:{ Name:nbd12 Major:43 Minor:12 Size:0 Scheduler:none } 43:15: { Name:nbd15 Major:43 Minor:15 Size:0 Scheduler:none } 43:7:{ Name:nbd7 Major:43 Minor:7 Size:0 Scheduler:none } 8:0:{ Name:sda Major:8 Minor :0 Size:15728640000 Scheduler:cfq } 252:0:{ Name:dm-0 Major:252 Minor:0 Size:107374182400 Scheduler:none } 43:1:{ Name:nbd1 Major:43 Minor:1 Size:0 Scheduler :none } 43:13:{ Name:nbd13 Major:43 Minor:13 Size:0 Scheduler:none } 43:8:{ Name:nbd8 Major:43 Minor:8 Size:0 Scheduler:none } 8: 16:{ Name:sdb Major:8 Minor:16 Size:536870912 Scheduler:cfq } 9:0:{ Name:md0 Major:9 Minor:0 Size:0 Scheduler:none } 43:3:{ Name:nbd3 Major: 43 Minor:3 Size:0 Scheduler:none } 43:9:{ Name:nbd9 Major:43 Minor:9 Size:0 Scheduler:none } 43:10:{ Name:nbd10 Major:43 Minor:10 Size:0 Scheduler :none } 43:14:{ Name:nbd14 Major:43 Minor:14 Size:0 Scheduler:none } 43:2:{ Name:nbd2 Major:43 Minor:2 Size:0 Scheduler:none } 43:4:{ Name:nbd4 Major:43 Minor:4 Size:0 Scheduler:none } 43:5:{ Name:nbd5 Major:43 Minor:5 Size:0 Scheduler:none } 43:6:{ Name:nbd6 Major:43 Minor: 6 Size:0 Scheduler:none }] NetworkDevices:[{ Name:dummy0 M acAddress:5a :34:bf:e4:23:cc Speed:0 Mtu:1500 } { Name:eth0 M acAddress:f2 :3c:91: 1f:cd:c3 Geschwindigkeit:-1 Mtu:1500 } { Name:gre0 M acAddress:00 :00:00:00 Geschwindigkeit:0 Mtu:1476 } { Name:gretap0 M acAddress:00 :00:00:00:00 :00 Geschwindigkeit:0 Mtu:1462 } { Name:ip6_vti0 M acAddress:00 :00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 Geschwindigkeit:0 Mtu:1500 } { Name:ip6gre0 MACAdresse:00 :00:00:00:00:00:00:00: 00:00:00:00:00:00:00:00 Geschwindigkeit:0 Mtu:1448 } { Name:ip6tnl0 M acAddress:00 :00:00:00:00:00:00:00:00:00:00 :00:00:00:00:00 Geschwindigkeit:0 Mtu:1452 } { Name:ip_vti0 Ma
12. Apr 02:10:01 localhost kubelet: cAddress:00 :00:00:00 Speed:0 Mtu:1428 } { Name:sit0 M acAddress:00 :00:00:00 Speed:0 Mtu:1480 } { Name: teql0 MacAddress: Speed:0 Mtu:1500 } { Name:tunl0 M acAddress:00 :00:00:00 Speed:0 Mtu:1480 }] Topology:[{Id:0 Memory:1037021184 Cores:[{Id:0 Threads :[0] Caches:[{ Größe:32768 Typ: Datenebene :1 } { Größe:32768 Typ:Anweisungsebene :1 } { Größe:4194304 Typ:Einheitliche Ebene:2 }]}] Caches:[]}] Clou dProvider:Unbekannter Instanztyp:Unbekannte InstanzID:None }
Apr 12 02:10:01 localhost kubelet: I0412 02:10:01.013353 3445 manager.go:204] Version: {Kern elVersion:4.9.15-x86_64-linode81 Container OsVersion:Fedora 25 (Server Edition) Dock erVersion:1.12. 6 CadvisorVersion: CadvisorRevision:}
12. Apr 02:10:01 localhost kubelet: I0412 02:10:01.014086 3445 server.go:509] --cgroups-per-qos aktiviert, aber --cgroup-root wurde nicht angegeben. standardmäßig /
12. Apr 02:10:01 localhost kubelet: W0412 02:10:01.016562 3445 container_manager_linux.go:218] Die Ausführung mit aktiviertem Swap wird nicht unterstützt, bitte deaktivieren Sie Swap! Dies wird ab K8s v1.6 standardmäßig ein schwerwiegender Fehler sein! In der Zwischenzeit können Sie sich dafür entscheiden, dies zu einem schwerwiegenden Fehler zu machen, indem Sie --experimental-fail-swap-on aktivieren.
12. Apr 02:10:01 localhost kubelet: I0412 02:10:01.016688 3445 container_manager_linux.go:245] Container-Manager verifizierter vom Benutzer angegebener cgroup-root existiert: /
Apr 12 02:10:01 localhost kubelet: I0412 02:10:01.016717 3445 container_manager_linux.go:250] Container Manager Objekt basierend auf Node Config erstellen: {RuntimeCgroupsName: SystemCgroupsName: KubeletCgroupsName: Contain erRuntime: docker Cgro upsPerQOS:true CgroupRoot:/ Cgr oupDriver:cgroupfs ProtectKerne lDefaults:false EnableCRI:true NodeAllocatableConfig:{KubeReservedCgroupName: SystemReservedCgroupName: EnforceNodeAl locatable:map [pods:{}] Kub eReserved:map [] Syste mReserved:map [] HardEvictionThresholds:[{ Signal:memory.available Operator :LessThan Value:{ Quantity:100Mi P ercentage:0 } GracePeriod:0s MinReclaim:}]} ExperimentalQO SReserviert:map []}
12. Apr 02:10:01 localhost kubelet: I0412 02:10:01.016943 3445 kubelet.go:255] Manifestdatei wird hinzugefügt: /etc/kubernetes/manifests
12. Apr 02:10:01 localhost kubelet: I0412 02:10:01.016966 3445 kubelet.go:265] Apiserver beobachten
12. Apr 02:10:01 localhost kubelet: E0412 02:10:01.025058 3445 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Fehler beim Auflisten von *v1.Node: Holen Sie https: //50.116.13.214 :6443/api/v1/nodes?fieldSelector=metadata.name%3Dli471-214.members.linode.com&resourceVersion=0: Wählen Sie TCP 50.116.13.214:6443: getsockopt: Verbindung abgelehnt
12. Apr 02:10:01 localhost kubelet: E0412 02:10:01.025342 3445 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Fehler beim Auflisten von *v1.Service: Holen Sie https: //50.116.13.214 :6443/api/v1/services?resourceVersion=0: TCP wählen 50.116.13.214:6443: getsockopt: Verbindung abgelehnt
12. Apr 02:10:01 localhost kubelet: E0412 02:10:01.025397 3445 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Fehler beim Auflisten von *v1.Pod: Get https://50.116.13.214 :6443/api/v1/pods?fieldSelector=spec.nodeName%3Dli471-214.members.linode.com&resourceVersion=0: Wählen Sie TCP 50.116.13.214:6443: getsockopt: Verbindung abgelehnt
12. April 02:10:01 localhost kubelet: W0412 02:10:01.026574 3445 kubelet_network.go:70] Hairpin-Modus auf „promiscuous-bridge“ gesetzt, aber kubenet ist nicht aktiviert und fällt auf „hairpin-veth“ zurück
12. Apr 02:10:01 localhost kubelet: I0412 02:10:01.026599 3445 kubelet.go:494] Hairpin-Modus auf „hairpin-veth“ gesetzt
12. Apr 02:10:01 localhost kubelet: W0412 02:10:01.026661 3445 cni.go:157] CNI-Konfiguration kann nicht aktualisiert werden: Keine Netzwerke in /etc/cni/net.d gefunden
12. Apr 02:10:01 localhost kubelet: W0412 02:10:01.034194 3445 cni.go:157] CNI-Konfiguration kann nicht aktualisiert werden: Keine Netzwerke in /etc/cni/net.d gefunden
12. Apr 02:10:01 localhost kubelet: W0412 02:10:01.043157 3445 cni.go:157] CNI-Konfiguration kann nicht aktualisiert werden: Keine Netzwerke in /etc/cni/net.d gefunden
Apr 12 02:10:01 localhost kubelet: I0412 02:10:01.043183 3445 docker_service.go:187] Docker cri network managed by cni
12. April 02:10:01 localhost kubelet: Fehler: Fehler beim Ausführen von Kubelet: Fehler beim Erstellen von kubelet: Fehlkonfiguration: kubelet cgroup-Treiber: „cgroupfs“ unterscheidet sich vom Docker-cgroup-Treiber: „systemd“
12. April 02:10:01 localhost audit: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kubelet comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=fehlgeschlagen'
12. Apr 02:10:01 localhost systemd: kubelet.service: Hauptprozess beendet, Code=beendet, Status=1/FAILURE
12. April 02:10:01 localhost systemd: kubelet.service: Einheit ist in den Fehlerzustand eingetreten.
12. April 02:10:01 localhost systemd: kubelet.service: Fehler mit Ergebnis 'exit-code'.

@acloudiator Ich denke, Sie müssen den cgroup-driver in der kubeadm-Konfiguration festlegen.

vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Environment="KUBELET_EXTRA_ARGS=--cgroup-driver=systemd"

Starten Sie dann den Kubelet-Dienst neu

Es wäre großartig, wenn kubeadm das Cgroup-Konfigurationsproblem irgendwie lösen könnte.
Ideen:

• Abbruch der Initialisierung bei Fehlkonfiguration
• Überprüfen Sie vorher die Einstellungen von Docker und verwenden Sie das, was Docker verwendet (nicht sicher, ob es hier Auswirkungen gibt).

Nur ein Update, was auch immer ich versucht habe, hat nicht funktioniert. Also bin ich für den Master auf CentOS 7.3 umgestiegen und es funktioniert wie ein Zauber! Ich habe die Minions jedoch auf CentOS 7.2 belassen.

@rushabh268 Hallo, ich habe das gleiche Problem mit Redhat Linux 7.2. Nach der Aktualisierung des systemd ist dieses Problem behoben. Sie können versuchen, systemd vor der Installation zu aktualisieren.
yum update -y systemd
und das Fehlerprotokoll von kubelet:
kubelet.go:1752] skipping pod synchronization - [Failed to start ContainerManager systemd version does not support ability to start a slice as transient unit]

Ich bin auf dieses Problem unter CentOS 7.3 gestoßen. Das Problem ist verschwunden, nachdem ich docker-ce deinstalliert und dann docker-io installiert habe.
Ich bin mir nicht sicher, ob es die eigentliche Ursache ist. Wie auch immer, Sie können es versuchen, wenn die oben genannten Methoden nicht funktionieren.

@ZongqiangZhang Ich habe Docker 1.12.6 auf meinen Knoten installiert. @juntaoXie Ich habe auch versucht, systemd zu aktualisieren, und es steckt immer noch fest

Also habe ich Centos 7.3 mit 1.6.4 ohne Probleme auf einer Reihe von Maschinen ausgeführt.

Hast du sicher gestellt, dass du Selinux deaktiviert hast?

@timothysc Ich habe CentOS 7.2 und nicht CentOS 7.3 und Selinux ist deaktiviert

Ich habe eine CentOS-Linux-Version 7.3.1611 (Core) und KubeAdm 1.6.4 funktioniert nicht.

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
EOF

setenforce 0
# edit /etc/selinux/config and set SELINUX=disabled
yum install docker kubelet kubeadm kubectl kubernetes-cni
systemctl enable docker
systemctl start docker
systemctl enable kubelet
systemctl start kubelet
reboot
kubeadm init

Ausgabe:

kubeadm init
[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters.
[init] Using Kubernetes version: v1.6.4
[init] Using Authorization mode: RBAC
[preflight] Running pre-flight checks
[preflight] WARNING: hostname "kubernet01.localdomain" could not be reached
[preflight] WARNING: hostname "kubernet01.localdomain" lookup kubernet01.localdomain on XXXXXXX:53: read udp XXXXXXX:56624->XXXXXXX:53: i/o timeout
[preflight] Starting the kubelet service
[certificates] Generated CA certificate and key.
[certificates] Generated API server certificate and key.
[certificates] API Server serving cert is signed for DNS names [kubernet01.localdomain kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.11.112.51]
[certificates] Generated API server kubelet client certificate and key.
[certificates] Generated service account token signing key and public key.
[certificates] Generated front-proxy CA certificate and key.
[certificates] Generated front-proxy client certificate and key.
[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[apiclient] Created API client, waiting for the control plane to become ready

Jun 06 17:13:12 kubernet01.localdomain kubelet[11429]: W0606 17:13:12.881451   11429 cni.go:157] Unable to update cni config: No networks found in /etc/cni/net.d
Jun 06 17:13:12 kubernet01.localdomain kubelet[11429]: E0606 17:13:12.882145   11429 kubelet.go:2067] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.519992   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod: Get https://10.11.112.51:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dkubernet01.localdomain&resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.520798   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:382: Failed to list *v1.Service: Get https://10.11.112.51:6443/api/v1/services?resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:13 kubernet01.localdomain kubelet[11429]: E0606 17:13:13.521493   11429 reflector.go:190] k8s.io/kubernetes/pkg/kubelet/kubelet.go:390: Failed to list *v1.Node: Get https://10.11.112.51:6443/api/v1/nodes?fieldSelector=metadata.name%3Dkubernet01.localdomain&resourceVersion=0: dial tcp 10.11.112.51:6443: getsockopt: connection refused
Jun 06 17:13:14 kubernet01.localdomain kubelet[11429]: E0606 17:13:14.337588   11429 event.go:208] Unable to write event: 'dial tcp 10.11.112.51:6443: getsockopt: connection refused' (may retry after sleeping)

@paulobezerr kannst du ein bisschen mehr von kube-apiserver Logs teilen? (die am Ende deines Kommentars)

Erwähnen die Zeilen über dem, was Sie bereits eingefügt haben, dieselbe IP-Adresse? Ich habe kürzlich versucht, k8s auf zwei neuen KVMs auszuführen, eines mit Ubuntu 16.04 und eines mit CentOS 7.3. Beide gaben dies:

​[restful] 2017/05/30 19:31:38 log.go:30: [restful/swagger] listing is available at https://x.x.x.x:6443/swaggerapi/
[restful] 2017/05/30 19:31:38 log.go:30: [restful/swagger] https://x.x.x.x:6443/swaggerui/ is mapped to folder /swagger-ui/
​E0530 19:31:38.313090 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Failed to list *rbac.RoleBinding: Get https://localhost:6443/apis/rbac.authorization.k8s.io/v1beta1/rolebindings?resourceVersion=0: dial tcp y.y.y.y:6443: getsockopt: connection refused

Beachten Sie, dass zuerst die erwähnte IP-Adresse x.x.x.x ist, dann aber localhost in y.y.y.y aufgelöst wird (was in meinem Fall eine öffentliche IP eines anderen KVM war, der auf demselben physischen Server sitzt). Ich konnte kubeadm auf Ubuntu am Ende starten, aber erst nachdem ich dnsmasq ähnlich wie https://github.com/kubernetes/kubeadm/issues/113#issuecomment -273115861 installiert hatte. Der gleiche Workaround unter CentOS hat nicht geholfen.

Kann das ein Fehler in kubedns oder so sein? Interessanterweise brachten dieselben Schritte auf AWS-VMs kubeadm zum Vorschein. Aber EC2-Instances sind für meine persönlichen Projekte zu teuer.

Ich habe das gleiche Problem wie @paulobezerr.

## Versionen :
kubelet-1.6.4-0.x86_64
kubernetes-cni-0.5.1-0.x86_64
kubectl-1.6.4-0.x86_64
kubeadm-1.6.4-0.x86_64
docker-client-1.12.6-28.git1398f24.el7.centos.x86_64
docker-common-1.12.6-28.git1398f24.el7.centos.x86_64
docker-1.12.6-28.git1398f24.el7.centos.x86_64

DAMIT
uname -r > 3.10.0-229.1.2.el7.x86_64
cat /etc/redhat-release > CentOS Linux-Version 7.3.1611 (Core)

## Schritte gefolgt:

    1. sudo yum install -y docker
2. sudo groupadd docker
3. sudo usermod -aG docker $(whoami)
4. curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
5. chmod +x ./kubectl
6. sudo mv ./kubectl /usr/local/bin/kubectl
7. echo "source <(kubectl completion bash)" >> ~/.bashrc
8. sudo -i
9. cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
10. setenforce 0
11. yum install -y docker kubelet kubeadm kubectl kubernetes-cni
12. systemctl enable docker && systemctl start docker
13. systemctl enable kubelet && systemctl start kubelet
    14. echo -e "net.bridge.bridge-nf-call-ip6tables = 1\nnet.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.d/99-sysctl.conf && sudo service network restart
    15. firewall-cmd --zone=public --add-port=6443/tcp --permanent && sudo firewall-cmd --zone=public --add-port=10250/tcp --permanent  && sudo systemctl restart firewalld
    16. firewall-cmd --permanent --zone=trusted --change-interface=docker0

## API-Server-Protokolle:
--> 37.247.XX.XXX ist die öffentliche IP

[restful] 08.06.2017 10:45:19 log.go:30: Die Liste [restful/swagger] ist verfügbar unter https://37.247.XX.XXX :6443/swaggerapi/
[restful] 08.06.2017 10:45:19 log.go:30: [restful/swagger] https://37.247.XX.XXX :6443/swaggerui/ ist dem Ordner /swagger-ui/ zugeordnet
E0608 10:45:19.429839 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: *api.Secret konnte nicht aufgelistet werden: https://localhost abrufen: 6443/api/v1/secrets?resourceVersion=0: Wählen Sie TCP 108.59.253.109:6443: getsockopt: Verbindung abgelehnt
E0608 10:45:19.430419 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Fehler beim Auflisten von *api.ResourceQuota: Get https://localhost : 6443/api/v1/resourcequotas?resourceVersion=0: Wählen Sie TCP 108.59.253.109:6443: getsockopt: Verbindung abgelehnt
E0608 10:45:19.430743 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: *api.ServiceAccount konnte nicht aufgelistet werden: https://localhost abrufen: 6443/api/v1/serviceaccounts?resourceVersion=0: Wählen Sie TCP 108.59.253.109:6443: getsockopt: Verbindung abgelehnt
E0608 10:45:19.431076 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: Fehler beim Auflisten von *storage.StorageClass: Get https://localhost : 6443/apis/storage.k8s.io/v1beta1/storageclasses?resourceVersion=0: Wählen Sie TCP 108.59.253.109:6443: getsockopt: Verbindung abgelehnt
E0608 10:45:19.431377 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: *api.LimitRange konnte nicht aufgelistet werden: https://localhost abrufen: 6443/api/v1/limitranges?resourceVersion=0: Wählen Sie TCP 108.59.253.109:6443: getsockopt: Verbindung abgelehnt
E0608 10:45:19.431678 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: *rbac.RoleBinding konnte nicht aufgelistet werden: https://localhost abrufen: 6443/apis/rbac.authorization.k8s.io/v1beta1/rolebindings?resourceVersion=0: Wählen Sie TCP 108.59.253.109:6443: getsockopt: Verbindung abgelehnt
E0608 10:45:19.431967 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: *rbac.ClusterRoleBinding konnte nicht aufgelistet werden: https://localhost abrufen: 6443/apis/rbac.authorization.k8s.io/v1beta1/clusterrolebindings?resourceVersion=0: Wählen Sie TCP 108.59.253.109:6443: getsockopt: Verbindung abgelehnt
E0608 10:45:19.432165 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: *api.Namespace konnte nicht aufgelistet werden: https://localhost abrufen: 6443/api/v1/namespaces?resourceVersion=0: Wählen Sie TCP 108.59.253.109:6443: getsockopt: Verbindung abgelehnt
E0608 10:45:19.432386 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: *rbac.ClusterRole konnte nicht aufgelistet werden: https://localhost abrufen: 6443/apis/rbac.authorization.k8s.io/v1beta1/clusterroles?resourceVersion=0: Wählen Sie TCP 108.59.253.109:6443: getsockopt: Verbindung abgelehnt
E0608 10:45:19.432619 1 reflector.go:201] k8s.io/kubernetes/pkg/client/informers/informers_generated/internalversion/factory.go:70: *rbac.Role konnte nicht aufgelistet werden: https://localhost abrufen: 6443/apis/rbac.authorization.k8s.io/v1beta1/roles?resourceVersion=0: Wählen Sie TCP 108.59.253.109:6443: getsockopt: Verbindung abgelehnt
I0608 10:45:19.481612 1 serve.go:79] Sicheres Serving auf 0.0.0.0:6443
W0608 10:45:19.596770 1 storage_extensions.go:127] Ressourcensynchronisierung von Drittanbietern fehlgeschlagen: Rufen Sie https://localhost :6443/apis/extensions/v1beta1/thirdpartyresources ab: Wählen Sie TCP 108.59.253.109:6443: getsockopt: Verbindung abgelehnt
E0608 10:45:19.596945 1 client_ca_hook.go:58] Post https://localhost :6443/api/v1/namespaces: TCP 108.59.253.109:6443 wählen: getsockopt: Verbindung abgelehnt
F0608 10:45:19.597174 1 controller.go:128] Die anfängliche IP-Zuweisungsprüfung kann nicht durchgeführt werden: Der Dienst-IP-Block kann nicht aktualisiert werden: Rufen Sie https://localhost :6443/api/v1/services ab: Wählen Sie TCP 108.59.253.109: 6443: getsockopt: Verbindung abgelehnt

@albpal Ich hatte vor einer Woche genau das gleiche Problem: dial tcp X.X.X.X zeigte eine ungerade IP-Adresse und ich konnte dies unter CentOS nicht lösen, selbst nachdem ich dnsmasq installiert und zu Google-DNS-Servern anstelle von DNS von meinem Hosting-Provider gewechselt hatte. Nur aus Neugier: Können Sie überprüfen, ob sich die falsche IP-Adresse, die Sie sehen, im selben Rechenzentrum wie Ihre VM befindet? Sie können http://ipinfo.io verwenden, um das mit einiger Sicherheit abzuschätzen, oder einfach nur Traceroute.

In meinem Fall bezog sich die falsche IP-Adresse auf einen anderen KVM auf demselben physischen Server. Kann etwas mit DNS auf einer physischen Maschine zu tun haben, was möglicherweise eine Problemumgehung innerhalb von kube api oder kube dns erfordert, da sonst das Starten eines Clusters für viele Neulinge zu einem großen Problem wird! Ich habe ein paar Abende verschwendet, bevor ich dial tcp mit einer falschen IP in Protokollen bemerkte, was eine ziemlich traurige erste k8s-Erfahrung war. Ich habe immer noch keine gute Out-of-Box-Lösung für CentOS KVMs bei meinem Hosting-Provider ( firstvds.ru ).

Was kann diese sehr seltsame Nichtübereinstimmung in IP-Adressen verursachen?

@albpal Bitte öffnen Sie ein neues Problem, was Sie beschrieben haben und worum es in diesem Problem geht, sind separate Probleme (ich denke, basierend auf diesen Informationen).

@kachkaev Ich habe gerade überprüft, was Sie vorgeschlagen haben.

Ich habe festgestellt, dass die falsche IP bei einem CPANEL endet: vps-1054290-4055.manage.myhosting.com.

Auf der anderen Seite stammt die öffentliche IP meines VPS aus Italien und diese falsche IP stammt aus den USA derselbe physische Server.

Konntest du k8s installieren?

@luxas Ich habe das gleiche Verhalten, aber ich habe die Docker-Protokolle kopiertauch ausgeben.

Sowohl die Ausgabe von /var/log/messages als auch von kubeadm init sind die gleichen wie beim ursprünglichen Problem.

@albpal , also sind Ihre VM und dieser zweite Computer beide auf CPANEL? Gutes Zeichen, denn dann ist mein Fall der gleiche! Die Tatsache, dass es sich um dieselbe physische Maschine handelte, könnte nur ein Zufall sein.

Ich habe in meinen Experimenten zwei KVMs verwendet, einen mit Ubuntu 16.04 und einen mit CentOS 7.3. Beide hatten das gleiche dial tcp IP-Adressproblem. Am Ende konnte ich kubeadm auf Ubuntu starten, indem ich die DNS-Server meines Providers losgeworden bin. Die Lösung basierte auf dem Rat von ​crilozs :

​apt-get install dnsmasq

rm -rf /etc/resolv.conf
echo "nameserver 127.0.0.1" > /etc/resolv.conf
chmod 444 /etc/resolv.conf
chattr +i /etc/resolv.conf

echo "server=8.8.8.8
server=8.8.4.4" > /etc/dnsmasq.conf

service dnsmasq restart
​# reboot just in case

Dies brachte die richtige IP-Adresse nach dial tcp in Protokollen auf Ubuntu und kubeadm wurde nach ein paar Minuten initialisiert! Ich habe versucht, dnsmasq auf CentOS auf die gleiche Weise einzurichten, aber das hat das Problem nicht gelöst. Aber ich bin ein absoluter Neuling in diesem Betriebssystem, also kann es sein, dass ich einfach vergessen habe, einen Dienst neu zu starten oder einen Cache zu leeren. Probieren Sie diese Idee aus!

Auf jeden Fall fühlt es sich falsch an, einen zusätzlichen Schritt der Neukonfiguration von DNS zu machen, weil es sehr verwirrend ist (ich bin kein Server/Devops-Typ und diese ganze Untersuchung, die ich durchgemacht habe, hat mich fast zum Weinen gebracht :ängstlich:). Ich hoffe, dass kubeadm einmal in der Lage sein wird, zu erkennen, ob die DNS-Server des Anbieters auf seltsame Weise funktionieren, und automatisch alles zu reparieren, was im Cluster benötigt wird.

Wenn jemand aus dem k8s-Team bereit ist, zu sehen, was passiert, teile ich gerne den Root-Zugriff auf ein paar neue FirstVDS-KVMs. Schicken Sie mir einfach eine E-Mail oder DM auf Twitter!

Danke @kachkaev ! Ich werde es morgen versuchen

cc @kubernetes/sig-network-bugs Haben Sie eine Idee, warum die DNS-Auflösung oben fehlschlägt?

Danke @kachkaev , wir werden versuchen, uns das anzusehen. Ich glaube nicht, dass es wirklich die Schuld von kubeadm an sich ist, aber wenn viele Benutzer bei derselben Fehlkonfiguration stecken bleiben, könnten wir sie zu den Fehlerbehebungsdokumenten oder so hinzufügen ...

Meine Protokolle sind sehr wahrscheinlich @albpal- Protokolle.
Aber ich werde es mit dnsmasq versuchen. Danke euch allen!

@kachkaev , es funktioniert nicht. Gleiches Problem 😢
Das komplette Protokoll ist beigefügt.

log.txt

Ich konnte es reparieren!! Vielen Dank @kachkaev für deine Hinweise!

Ich denke das Problem war:

### Szenario:
Ein VPS mit folgendem Konfigurationsschema:

resolv.conf
[ root@apalau ~]# cat resolv.conf
Nameserver 8.8.8.8
Nameserver 8.8.4.4
Nameserver 2001:4860:4860::8888
Nameserver 2001:4860:4860::8844

Es gibt keine Suchdomain!

Gastgeber
[ root@apalau ~]# cat /etc/hosts
127.0.0.1 localhost.localdomain lokalerhost
37.XXX.XX.XXX Name.vpshosting.com

Laut Protokoll versucht der Kubernetes-Container, eine Verbindung herzustellen zu:

Rufen Sie https://localhost :6443/api/v1/secrets?resourceVersion=0 ab

Und wenn ich frage:
$ nslookup "localhost.$(hostname -d)"
Die IP, die ich bekomme, ist die falsche, dh 108.59.253.109.

Ich denke also, dass diese Container versuchen, localhost (ohne Domäne) aufzulösen, und sie erhalten eine falsche IP. Wahrscheinlich, weil "localhost.$(hostname -d)" auf diese IP auflöst, was meiner Meinung nach bei fast allen VPS-Diensten passieren wird.

## Was ich getan habe, um das Problem auf einem VPS CentOS 7.3 zu beheben (ein Teil dieser Schritte wird unter https://kubernetes.io/docs/setup/independent/install-kubeadm/#installing-kubelet-and-kubeadm gezeigt):

Als root:

1. kubeadm zurückgesetzt
2. yum installiere dnsmasq
3. cp /etc/resolv.conf ~/resolv.conf_bck
4. rm -rf /etc/resolv.conf
5. echo -e "nameserver 127.0.0.1\nnameserver $(hostname -i)" >> /etc/resolv.conf
6. chmod 444 /etc/resolv.conf
7. chattr +i /etc/resolv.conf
8. echo -e "server=8.8.8.8\nserver=8.8.4.4" > /etc/dnsmasq.conf
9. echo -e "$(hostname -i)\tlocalhost.$(hostname -d)" >> /etc/hosts
10. Dienst dnsmasq neu starten
11. firewall-cmd --zone=public --add-port=6443/tcp --permanent && sudo firewall-cmd --zone=public --add-port=10250/tcp --permanent && sudo systemctl reset firewalld
12. kubeadm-Init

Ich habe den Hostnamen -i in Schritt 5 hinzugefügt, denn andernfalls fügt Docker 8.8.8.8 zu resolv.conf in den Containern hinzu.

Ich hoffe es hilft auch anderen.

Danke!!

Freut mich zu hören, dass @albpal! Ich bin Ihre Schritte vor kubeadm init durchgegangen und der Cluster wurde schließlich in meinem Test FirstVDS KVM mit CentOS 7.3 initialisiert! Das einzige, was ich zusätzlich tun musste, war, firewalld zu stoppen und zu deaktivieren, da es externe Verbindungen zu Port 6443 blockierte:

systemctl disable firewalld
systemctl stop firewalld

_Ich empfehle dies nicht, da ich mir der Konsequenzen nicht bewusst bin – dies hat mir nur geholfen, einen Test auf einem Betriebssystem durchzuführen, das ich normalerweise nicht verwende._

Jetzt frage ich mich, was getan werden könnte, um den Installationsprozess für Neulinge wie mich zu vereinfachen. Der Weg zwischen dem Hängenbleiben bei Created API client, waiting for the control plane to become ready und dem Sortieren der Dinge ist immer noch riesig, besonders wenn wir die Zeit berücksichtigen, die benötigt wird, um dieses Problem auszugraben und alle Kommentare durchzulesen. __Was könnt ihr vorschlagen?__

@paulobezerr Von dem, was ich in Ihrem Anhang sehe, glaube ich, dass Ihr Problem etwas anders ist. Meine Apiserver-Protokolle enthalten so etwas wie:

reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod:
Get https://localhost:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0:
dial tcp RANDOM_IP:6443: getsockopt: connection refused

während deine sagen:

reflector.go:190] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:46: Failed to list *v1.Pod:
Get https://10.X.X.X:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dhostname&resourceVersion=0:
dial tcp 10.X.X.X:6443: getsockopt: connection refused

(im ersten Fall ist es localhost / RANDOM_IP , im zweiten Fall immer 10.X.X.X )

Leider weiß ich nicht, was ich raten soll, außer verschiedene --apiserver-advertise-address=??? , wenn Sie kubeadm init haben (siehe Dokumentation ). Meine praktische k8s-Erfahrung hat gerade 10 Tage erreicht, von denen die meisten vergebliche Versuche waren, einen Single-Node-Cluster auf FirstVDS zu starten :-)

Ich hoffe, Sie bekommen das sortiert und teilen die Lösung mit anderen!

@kachkaev Ich habe vergessen zu erwähnen, dass ich die folgende Firewall-Regel angewendet habe:

$ firewall-cmd --zone=public --add-port=6443/tcp --permanent && sudo firewall-cmd --zone=public --add-port=10250/tcp --permanent && sudo systemctl restart firewalld

In meiner Umgebung funktioniert es gut, wenn diese Regel angewendet wird, ohne die Firewall zu deaktivieren. Ich werde es meinem vorherigen Kommentar hinzufügen, um alle erforderlichen Schritte zu sammeln.

@juntaoXie Danke. Das Aktualisieren der systemd-Version gemäß Ihrem Kommentar hat bei mir funktioniert.

Ich bekomme dieses Problem seit zwei Tagen immer noch, ich führe das alles hinter einem Proxy aus und es scheint kein Problem zu geben.
kubeadm init wartet darauf, dass die Steuerungsebene bereit wird. Wenn ich docker ps mache, werden die Container gezogen und ausgeführt, aber es werden keine Ports zugewiesen (ich weiß nicht, ob es soll, aber ok). etcd läuft auch einwandfrei. Wenn ich mir jedoch meinen Kubelet-Dienst ansehe, sagt er Unable to update cni config: No networks found in /etc/cni/net.d was https://github.com/kubernetes/kubernetes/issues/43815 sagt, ist ok, du müssen ein CNI-Netzwerk anwenden.
Was ich gemäß https://www.weave.works/docs/net/latest/kubernetes/kube-addon/ mache. Jetzt sagt kubectl, dass 8080 abgelehnt wurde – haben Sie den richtigen Host oder Port angegeben? Scheint ein Henne-Ei-Problem zu sein, wie wende ich ein cni-Netzwerk an, wenn meine kubeadm-Init hängt??? Das ist so verwirrend

Dies ist auch kein Cgroup-Problem, sowohl Docker als auch mein Kubelet-Dienst verwenden systemd.

FWIW, ich hatte dasselbe Problem auf GCP. Ich habe versucht, Ubuntu 16.04 und CentOS mit den folgenden Befehlen in einem sauberen Projekt zu verwenden:

$ gcloud compute instances create test-api-01 --zone us-west1-a --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' Knoten 1 für API-Tests'

$ gcloud compute instances create test-api-02 --zone us-west1-b --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' Knoten 2 für API-Tests'

$ gcloud compute instances create test-api-03 --zone us-west1-c --image-family ubuntu-1604-lts --image-project ubuntu-os-cloud --machine-type f1-micro --description ' Knoten 3 für API-Tests'

$ apt-get update

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key hinzufügen -

$ apt-get update && apt-get install -qy docker.io && apt-get install -y apt-transport-https

$ echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list

$ apt-get update && apt-get install -y kubelet kubeadm kubernetes-cni

$ systemctl startet kubelet neu

$ kubeadm-Init

Nachdem ich mir mehrere Stunden lang den Kopf dagegen geschlagen hatte, ging ich schließlich zu:

$ gcloud beta container --project "weather-177507" cluster create "weather-api-cluster-1" --zone "us-west1-a" --username="admin" --cluster-version "1.6.7" --machine-type "f1-micro" --image-type "COS" --disk-size "100" --scopes " https://www.googleapis.com/auth/compute "," https:// www.googleapis.com/auth/devstorage.read_only "," https://www.googleapis.com/auth/logging.write "," https://www.googleapis.com/auth/monitoring.write "," https://www.googleapis.com/auth/servicecontrol "," https://www.googleapis.com/auth/service.management.readonly "," https://www.googleapis.com/auth/trace. append " --num-nodes "3" --network "default" --enable-cloud-logging --no-enable-cloud-monitoring --enable-legacy-authorization

Ich war in der Lage, einen Cluster zum Laufen zu bringen, wo ich es mit einem leeren Image nicht konnte.

Sogar ich habe das gleiche Problem mit der Kubeadm-Version:

es bleibt stecken
[apiclient] Created API client, waiting for the control plane to become ready

Gleiches Problem wie bei @paulobezerr - meine env: CentOS 7.4.1708 kubeadm-Version: &version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"6e937839ac04a38cac63e6a7a306c5d035fe7b0a", GitTreeState:"clean ", BuildDate:"2017-09-28T22:46:41Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

Für mich lief dieses Problem nicht mit deaktiviertem SELinux. Der Hinweis waren seine Schritte, der Kommentar:

Bearbeiten Sie /etc/selinux/config und setzen Sie SELINUX=disabled

Die Installationsschritte hier (https://kubernetes.io/docs/setup/independent/install-kubeadm/) für CentOS sagen:
"Das Deaktivieren von SELinux durch Ausführen von setenforce 0 ist erforderlich, damit Container auf das Host-Dateisystem zugreifen können."
aber es wird nicht erwähnt (zumindest auf der Registerkarte CentOS/RHEL/Fedora), dass Sie /etc/selinux/config bearbeiten und SELINUX=disabled setzen sollten

Obwohl ich setenforce 0 ausgeführt hatte, bekam ich immer noch die gleichen Fehler. Das Bearbeiten von /etc/selinux/config und das Setzen von SELINUX=disabled und das anschließende Neustarten hat es für mich behoben.

Hier scheinen viele (potenziell orthogonale) Probleme im Spiel zu sein, daher möchte ich, dass wir die Dinge nicht auseinanderlaufen lassen. Bisher scheinen wir 3 Probleme festgestellt zu haben:

1. DNS kann localhost auf einigen Computern nicht richtig auflösen. @kachkaev @paulobezerr Konntest du das beheben? Ich frage mich, wie wir dies in unseren Anforderungen deutlicher machen können, irgendwelche Ideen?

2. Falsche cgroup-driver -Übereinstimmung zwischen Kubelet und Docker. Wir sollten dies zu unserer Anforderungsliste hinzufügen.

3. SELinux ist nicht deaktiviert. Wir sollten dies zu unserer Anforderungsliste hinzufügen.

Sobald alle drei mit PRs angesprochen werden, sollten wir das vielleicht schließen und Leute, die in Zukunft auf Probleme stoßen, ihre eigenen Probleme erstellen lassen. Dadurch erhalten wir strukturiertere Informationen und bieten detailliertere Unterstützung, anstatt mit vielen Dingen in einem Thread zu jonglieren. Was denkst du @luxas?

Für mich ging ich mit Docker 17.06 (17.03 wird empfohlen, ist aber nicht bei docker.io verfügbar) und hatte das gleiche Problem. Das Upgrade auf 17.09 hat das Problem auf magische Weise behoben.

Da dieser Thread so lang geworden ist und es wahrscheinlich viele völlig unterschiedliche Probleme gibt, ist das Produktivste, was ich neben dem hervorragenden Kommentar von @jamiehannaford hinzufügen kann, dass Sie bitte neue, gezielte Probleme mit allen relevanten Protokollen / Informationen öffnen, falls etwas passiert schlägt _mit dem neuesten kubeadm v1.8_ fehl, das einen fehlerhaften Zustand automatisch viel besser erkennt als frühere Versionen. Wir haben auch unsere Dokumentation in Bezug auf Anforderungen und Grenzfälle verbessert, was den Menschen hoffentlich Zeit sparen wird.

Vielen Dank an alle!

Ich hatte das gleiche Problem mit 1.8 in CENTOS 7 mit 1.8? hatte jemand das gleiche Problem oder weiß Abhilfe.

@rushins Wenn Sie Hilfe zu dem möglichen Problem erhalten möchten, das Sie sehen, öffnen Sie hier ein neues Problem mit ausreichenden Details.

Ich habe das gleiche Problem wie @rushabh268 , nämlich connection refused und nicht localhost:6443/api .
Schließlich habe ich es gelöst, indem ich die Domain bemerkt habe, die nach search xxx.xx.xxxx.org sucht.

vi /etc/resolv.congf

------ resolv.congf -----
# Generated by NetworkManager
#search xxx.xx.xxxx.org
nameserver 10.x.xxx.xx
nameserver 10.x.xxx.xx
nameserver 10.x.xxx.xx
--------------------------

Umschlag:
-> CentOS-7-x86_64-Minimal-1708
-> K8s v1.9.2
-> Docker v17.12.0.ce
-> unter privates Netzwerk xxx.xx.xxxx.org

Bitte, um Himmels willen, fügen Sie dies den Dokumenten hinzu. Ich habe viele Nächte nach der Arbeit versucht, meinen Cluster unter dem Deckmantel von "Spaß zu haben und mit Technologie zu spielen" einzurichten. Ich wurde durch den Masterknoten erledigt, der beim Ausführen von nslookup localhost nicht die richtige IP erhielt.

Danke an @kachkaev für die Lösung.