Kubeadm: BUG REPORT: kubelet cgroup Treiber

Fehler: Kubelet konnte nicht ausgeführt werden: Kubelet konnte nicht erstellt werden: Fehlkonfiguration: Kubelet-Cgroup-Treiber: "cgroupfs" unterscheidet sich vom Docker-Cgroup-Treiber: "systemd"

Docker info | grep -i cgroup
Cgroup-Treiber: systemd

Ich kann das bestätigen.

@ lavender2020 Sie müssen --cgroup-driver=systemd manuell an kubelet Startargumente anhängen und die Kubelet-Einheitendatei neu laden, um den Dienst neu zu starten.

Der Standardtreiber, mit dem kubelet cgroups auf dem Host manipuliert, ist cgroupfs .

Die meisten Leute wenden sich an kubeadm , um einen Cluster sehr schnell einzurichten. Es ist einfach und praktisch。

@luxas Sollen wir eine Prefilght-Überprüfung der Konsistenz des cgroup-Treibers zwischen docker und kubelet hinzufügen, um explizitere Warnungen zu geben? Oder fügen Sie ein weiteres Drop-In für kubelet.service ? Oder ändern Sie einfach /etc/systemd/system/kubelet.service.d/10-kubeadm.conf an Ort und Stelle?

In diesem Fall müssen wir möglicherweise Root-Berechtigungen erwerben, um diese Änderungen übernehmen zu können.

Ich habe das gleiche Problem mit kubeadm v1.9.2 festgestellt, aber ich kann sehen, dass kubelet für die Verwendung des systemd cgroup-Treibers konfiguriert ist.

kubelet verwendet --cgroup-driver = systemd

cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true"
Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin"
Environment="KUBELET_DNS_ARGS=--cluster-dns=10.96.0.10 --cluster-domain=cluster.local"
Environment="KUBELET_AUTHZ_ARGS=--authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt"
Environment="KUBELET_CADVISOR_ARGS=--cadvisor-port=0"
Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd"
Environment="KUBELET_CERTIFICATE_ARGS=--rotate-certificates=true --cert-dir=/var/lib/kubelet/pki"
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_CADVISOR_ARGS $KUBELET_CGROUP_ARGS $KUBELET_CERTIFICATE_ARGS $KUBELET_EXTRA_ARGS

Docker-Info |

 WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
Cgroup Driver: systemd

Kubelet-Protokolle

I0206 16:20:40.010949    5712 feature_gate.go:220] feature gates: &{{} map[]}
I0206 16:20:40.011054    5712 controller.go:114] kubelet config controller: starting controller
I0206 16:20:40.011061    5712 controller.go:118] kubelet config controller: validating combination of defaults and flags
W0206 16:20:40.015566    5712 cni.go:171] Unable to update cni config: No networks found in /etc/cni/net.d
I0206 16:20:40.019079    5712 server.go:182] Version: v1.9.2
I0206 16:20:40.019136    5712 feature_gate.go:220] feature gates: &{{} map[]}
I0206 16:20:40.019240    5712 plugins.go:101] No cloud provider specified.
W0206 16:20:40.019273    5712 server.go:328] standalone mode, no API client
W0206 16:20:40.041031    5712 server.go:236] No api server defined - no events will be sent to API server.
I0206 16:20:40.041058    5712 server.go:428] --cgroups-per-qos enabled, but --cgroup-root was not specified.  defaulting to /
I0206 16:20:40.041295    5712 container_manager_linux.go:242] container manager verified user specified cgroup-root exists: /
I0206 16:20:40.041308    5712 container_manager_linux.go:247] Creating Container Manager object based on Node Config: {RuntimeCgroupsName: SystemCgroupsName: KubeletCgroupsName: ContainerRuntime:docker CgroupsPerQOS:true CgroupRoot:/ CgroupDriver:cgroupfs KubeletRootDir:/var/lib/kubelet ProtectKernelDefaults:false NodeAllocatableConfig:{KubeReservedCgroupName: SystemReservedCgroupName: EnforceNodeAllocatable:map[pods:{}] KubeReserved:map[] SystemReserved:map[] HardEvictionThresholds:[{Signal:memory.available Operator:LessThan Value:{Quantity:100Mi Percentage:0} GracePeriod:0s MinReclaim:<nil>} {Signal:nodefs.available Operator:LessThan Value:{Quantity:<nil> Percentage:0.1} GracePeriod:0s MinReclaim:<nil>} {Signal:nodefs.inodesFree Operator:LessThan Value:{Quantity:<nil> Percentage:0.05} GracePeriod:0s MinReclaim:<nil>} {Signal:imagefs.available Operator:LessThan Value:{Quantity:<nil> Percentage:0.15} GracePeriod:0s MinReclaim:<nil>}]} ExperimentalQOSReserved:map[] ExperimentalCPUManagerPolicy:none ExperimentalCPUManagerReconcilePeriod:10s}
I0206 16:20:40.041412    5712 container_manager_linux.go:266] Creating device plugin manager: false
W0206 16:20:40.043521    5712 kubelet_network.go:139] Hairpin mode set to "promiscuous-bridge" but kubenet is not enabled, falling back to "hairpin-veth"
I0206 16:20:40.043541    5712 kubelet.go:571] Hairpin mode set to "hairpin-veth"
I0206 16:20:40.044909    5712 client.go:80] Connecting to docker on unix:///var/run/docker.sock
I0206 16:20:40.044937    5712 client.go:109] Start docker client with request timeout=2m0s
W0206 16:20:40.046785    5712 cni.go:171] Unable to update cni config: No networks found in /etc/cni/net.d
I0206 16:20:40.049953    5712 docker_service.go:232] Docker cri networking managed by kubernetes.io/no-op
I0206 16:20:40.055138    5712 docker_service.go:237] Docker Info: &{ID:ZXWO:G2FL:QM3S:IAWM:ITQL:XHRH:ZA3T:FJMV:5JDW:IMKI:NIFS:2Z4M Containers:8 ContainersRunning:0 ContainersPaused:0 ContainersStopped:8 Images:11 Driver:devicemapper DriverStatus:[[Pool Name docker-253:0-33593794-pool] [Pool Blocksize 65.54 kB] [Base Device Size 10.74 GB] [Backing Filesystem xfs] [Data file /dev/loop0] [Metadata file /dev/loop1] [Data Space Used 1.775 GB] [Data Space Total 107.4 GB] [Data Space Available 14.72 GB] [Metadata Space Used 2.093 MB] [Metadata Space Total 2.147 GB] [Metadata Space Available 2.145 GB] [Thin Pool Minimum Free Space 10.74 GB] [Udev Sync Supported true] [Deferred Removal Enabled true] [Deferred Deletion Enabled true] [Deferred Deleted Device Count 0] [Data loop file /var/lib/docker/devicemapper/devicemapper/data] [Metadata loop file /var/lib/docker/devicemapper/devicemapper/metadata] [Library Version 1.02.140-RHEL7 (2017-05-03)]] SystemStatus:[] Plugins:{Volume:[local] Network:[overlay host null bridge] Authorization:[] Log:[]} MemoryLimit:true SwapLimit:true KernelMemory:true CPUCfsPeriod:true CPUCfsQuota:true CPUShares:true CPUSet:true IPv4Forwarding:true BridgeNfIptables:true BridgeNfIP6tables:true Debug:true NFd:16 OomKillDisable:true NGoroutines:25 SystemTime:2018-02-06T16:20:40.054685386Z LoggingDriver:journald CgroupDriver:systemd NEventsListener:0 KernelVersion:3.10.0-693.el7.x86_64 OperatingSystem:CentOS Linux 7 (Core) OSType:linux Architecture:x86_64 IndexServerAddress:https://index.docker.io/v1/ RegistryConfig:0xc42021a380 NCPU:2 MemTotal:2097782784 GenericResources:[] DockerRootDir:/var/lib/docker HTTPProxy: HTTPSProxy: NoProxy: Name:master1 Labels:[] ExperimentalBuild:false ServerVersion:1.12.6 ClusterStore: ClusterAdvertise: Runtimes:map[docker-runc:{Path:/usr/libexec/docker/docker-runc-current Args:[]} runc:{Path:docker-runc Args:[]}] DefaultRuntime:docker-runc Swarm:{NodeID: NodeAddr: LocalNodeState:inactive ControlAvailable:false Error: RemoteManagers:[] Nodes:0 Managers:0 Cluster:0xc420472640} LiveRestoreEnabled:false Isolation: InitBinary: ContainerdCommit:{ID: Expected:} RuncCommit:{ID: Expected:} InitCommit:{ID: Expected:} SecurityOptions:[seccomp]}
error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "cgroupfs" is different from docker cgroup driver: "systemd"

Versions Information:

 kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2", GitCommit:"5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState:"clean", BuildDate:"2018-01-18T09:42:01Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}

kubelet --version
Kubernetes v1.9.2

docker version
Client:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-1.12.6-71.git3e8e77d.el7.centos.1.x86_64
 Go version:      go1.8.3
 Git commit:      3e8e77d/1.12.6
 Built:           Tue Jan 30 09:17:00 2018
 OS/Arch:         linux/amd64

Server:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-1.12.6-71.git3e8e77d.el7.centos.1.x86_64
 Go version:      go1.8.3
 Git commit:      3e8e77d/1.12.6
 Built:           Tue Jan 30 09:17:00 2018
 OS/Arch:         linux/amd64

@dkirrane Haben Sie die Unit-Datei kubelet.service neu geladen?

Führen Sie systemctl daemon-reload . Und dann systemctl restart kubelet .

Dieses Problem wurde am 1.9.3 nicht behoben

Versions Information:

kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3", GitCommit:"d2835416544f298c919e2ead3be3d0864b52323b", GitTreeState:"clean", BuildDate:"2018-02-07T11:55:20Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}

kubelet --version
Kubernetes v1.9.3

 docker version
Client:
 Version:      1.13.1
 API version:  1.26
 Go version:   go1.6.2
 Git commit:   092cba3
 Built:        Thu Nov  2 20:40:23 2017
 OS/Arch:      linux/amd64

Server:
 Version:      1.13.1
 API version:  1.26 (minimum version 1.12)
 Go version:   go1.6.2
 Git commit:   092cba3
 Built:        Thu Nov  2 20:40:23 2017
 OS/Arch:      linux/amd64
 Experimental: false

@gades Was ist dein cgroup-Treiber?

$ docker info | grep -i cgroup

Das gleiche Problem haben.

docker info | grep -i cgroup
Cgroup Driver: systemd

cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true"
Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin"
Environment="KUBELET_DNS_ARGS=--cluster-dns=10.96.0.10 --cluster-domain=cluster.local"
Environment="KUBELET_AUTHZ_ARGS=--authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt"
Environment="KUBELET_CADVISOR_ARGS=--cadvisor-port=0"
Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd"
Environment="KUBELET_CERTIFICATE_ARGS=--rotate-certificates=true --cert-dir=/var/lib/kubelet/pki"
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_CADVISOR_ARGS $KUBELET_CGROUP_ARGS $KUBELET_CERTIFICATE_ARGS $KUBELET_EXTRA_ARGS

I0227 13:17:43.802942    3493 docker_service.go:237] Docker Info: &{ID:RJUG:6DLB:A4JM:4T6H:JYKO:7JUC:NQCI:SLI2:DC64:ZXOT:DIX6:ASJY Containers:0 ContainersRunning:0 ContainersPaused:0 ContainersStopped:0 Images:0 Driver:overlay DriverStatus:[[Backing Filesystem extfs]] SystemStatus:[] Plugins:{Volume:[local] Network:[bridge overlay null host] Authorization:[] Log:[]} MemoryLimit:true SwapLimit:true KernelMemory:true CPUCfsPeriod:true CPUCfsQuota:true CPUShares:true CPUSet:true IPv4Forwarding:true BridgeNfIptables:true BridgeNfIP6tables:true Debug:false NFd:26 OomKillDisable:true NGoroutines:47 SystemTime:2018-02-27T13:17:43.802488651-08:00 LoggingDriver:journald CgroupDriver:systemd NEventsListener:0 KernelVersion:3.10.0-693.11.6.el7.x86_64 OperatingSystem:CentOS Linux 7 (Core) OSType:linux Architecture:x86_64 IndexServerAddress:https://index.docker.io/v1/ RegistryConfig:0xc42033d7a0 NCPU:64 MemTotal:270186274816 GenericResources:[] DockerRootDir:/var/lib/docker HTTPProxy: HTTPSProxy: NoProxy: Name:param03.lancelot.cluster.bds Labels:[] ExperimentalBuild:false ServerVersion:1.12.6 ClusterStore: ClusterAdvertise: Runtimes:map[docker-runc:{Path:/usr/libexec/docker/docker-runc-current Args:[]} runc:{Path:docker-runc Args:[]}] DefaultRuntime:docker-runc Swarm:{NodeID: NodeAddr: LocalNodeState:inactive ControlAvailable:false Error: RemoteManagers:[] Nodes:0 Managers:0 Cluster:0xc420360640} LiveRestoreEnabled:false Isolation: InitBinary: ContainerdCommit:{ID: Expected:} RuncCommit:{ID: Expected:} InitCommit:{ID: Expected:} SecurityOptions:[seccomp]}
error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "cgroupfs" is different from docker cgroup driver: "systemd"

Gibt es irgendwo anders, wo Kubelet die cgroupfs-Treiberanweisung erhält?

@ mas-dse-greina Bitte beziehen Sie sich auf die Lösung in meinem Kommentar .

@dixudx Auch nach dem Anhängen von --cgroup-driver=systemd an /etc/systemd/system/kubelet.service.d/10-kubeadm.conf bleibt das Problem bestehen.

Dies ist die neueste Datei,
[Service] Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf" Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true" Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin" Environment="KUBELET_DNS_ARGS=--cluster-dns=10.96.0.10 --cluster-domain=cluster.local" Environment="KUBELET_AUTHZ_ARGS=--authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt" Environment="KUBELET_CADVISOR_ARGS=--cadvisor-port=0" Environment="KUBELET_CERTIFICATE_ARGS=--rotate-certificates=true --cert-dir=/var/lib/kubelet/pki" ExecStart= ExecStart=/usr/bin/kubelet --cgroup-driver=systemd $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_CADVISOR_ARGS $KUBELET_CERTIFICATE_ARGS $KUBELET_EXTRA_ARGS

PS: Es wurde behoben. Nach dem Neustart von Daemon und Kubelet habe ich kubeadm init --pod-network-cidr = 10.244.0.0 / 16 verwendet

Ja. Ich finde das Gleiche. Anhängen des --cgroup-driver = systemd
scheint keine Wirkung zu haben. Ich habe den Dienst neu gestartet und sogar
Computer neu gestartet.

Es scheint, dass das Verhalten nur auf dieser einen Maschine ist. Ich bin gewesen
erfolgreich mit 4 anderen Maschinen, aber diese scheint einfach nicht zu wollen
Treten Sie dem Cluster bei.

-Tony

Am Do, 1. März 2018 um 11:44 Uhr, srinivas491-oneconvergence <
[email protected]> schrieb:

@dixudx https://github.com/dixudx Auch nach dem Anhängen der
--cgroup-driver = systemd nach / etc / systemd / system / kubelet.
service.d / 10-kubeadm.conf Das Problem besteht weiterhin.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/kubernetes/kubeadm/issues/639#issuecomment-369707723 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AVReEuQHJR80-8J4VLvACnGt1lTjEbYrks5taE-BgaJpZM4RSs0P
.

Nachdem Sie die Einheitendatei geändert haben, müssen Sie systemdctl daemon-reload eingeben, damit eine Änderung wirksam wird.

FWIW Dies ist standardmäßig in den RPMs, jedoch nicht in .debs. Gibt es eine aktuelle Distribution im Haupt-Support, die jetzt nicht standardmäßig systemd ist?

/ @detiber zuweisen

Ich habe das gleiche Problem mit kubeadm v1.9.3 und v1.9.4 getroffen.

Starten Sie kubelet mit --cgroup-driver = systemd

$ cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true"
Environment="KUBELET_NETWORK_ARGS=--network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin"
Environment="KUBELET_DNS_ARGS=--cluster-dns=10.96.0.10 --cluster-domain=cluster.local"
Environment="KUBELET_AUTHZ_ARGS=--authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt"
Environment="KUBELET_CADVISOR_ARGS=--cadvisor-port=0"
Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd"
Environment="KUBELET_CERTIFICATE_ARGS=--rotate-certificates=true --cert-dir=/var/lib/kubelet/pki"
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_SYSTEM_PODS_ARGS $KUBELET_NETWORK_ARGS $KUBELET_DNS_ARGS $KUBELET_AUTHZ_ARGS $KUBELET_CADVISOR_ARGS $KUBELET_CGROUP_ARGS $KUBELET_CERTIFICATE_ARGS $KUBELET_EXTRA_ARGS

Dienst neu laden

$ systemctl daemon-reload
$ systemctl restart kubelet

Überprüfen Sie die Docker-Informationen

$ docker info |grep -i cgroup
 WARNING: Usage of loopback devices is strongly discouraged for production use. Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.
Cgroup Driver: systemd

Kubelet-Protokolle

$ kubelet logs
error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "cgroupfs" is different from docker cgroup driver: "systemd"

Versions Information

$ kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3", GitCommit:"d2835416544f298c919e2ead3be3d0864b52323b", GitTreeState:"clean", BuildDate:"2018-02-07T11:55:20Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}

$ kubelet --version
Kubernetes v1.9.3

$ docker version
Client:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-1.12.6-71.git3e8e77d.el7.centos.1.x86_64
 Go version:      go1.8.3
 Git commit:      3e8e77d/1.12.6
 Built:           Tue Jan 30 09:17:00 2018
 OS/Arch:         linux/amd64

Server:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-1.12.6-71.git3e8e77d.el7.centos.1.x86_64
 Go version:      go1.8.3
 Git commit:      3e8e77d/1.12.6
 Built:           Tue Jan 30 09:17:00 2018
 OS/Arch:         linux/amd64

$ cat /etc/redhat-release 
CentOS Linux release 7.2.1511 (Core) 

@FrostyLeaf Können Sie in der Befehlszeile von kubelet nachsehen, ob dort ein cgroup-Treiber angegeben ist?

So etwas wie ps aux |grep kubelet oder cat /proc/<kubelet pid>/cmdline sollte Ihnen helfen, das zu erkennen.

@ bart0sh Das ist es:

$  ps aux |grep /bin/kubelet
root     13025  0.0  0.0 112672   980 pts/4    S+   01:49   0:00 grep --color=auto /bin/kubelet
root     30495  4.5  0.6 546152 76924 ?        Ssl  00:14   4:22 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true --network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin --cluster-dns=10.96.0.10 --cluster-domain=cluster.local --authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt --cadvisor-port=0 --cgroup-driver=systemd --rotate-certificates=true --cert-dir=/var/lib/kubelet/pki --fail-swap-on=false

@ FrostyLeaf Danke! Ich könnte das auch reproduzieren. Scheint ein Fehler zu sein. Es ansehen.

Als vorübergehende Problemumgehung können Sie Docker und Kubelet auf den Treiber cgroupfs umstellen. Es sollte funktionieren.

@ bart0sh Gut . Vielen Dank. Ich werde das versuchen.

Hier gilt das gleiche.

Kontext Host = CentOS 7.4, Gast = VirtualBox = Version 5.2.8 r121009 (Qt5.6.1)

[root<strong i="7">@kubernetes</strong> ~]# cat /etc/redhat-release 
CentOS Linux release 7.4.1708 (Core) 

`` `Bash
[ root @ kubernetes ~] # kubelet --version
Kubernetes v1.9.4

```bash
[root<strong i="14">@kubernetes</strong> ~]# docker version
Client:
 Version:         1.13.1
 API version:     1.26
 Package version: <unknown>
 Go version:      go1.8.3
 Git commit:      774336d/1.13.1
 Built:           Wed Mar  7 17:06:16 2018
 OS/Arch:         linux/amd64

Server:
 Version:         1.13.1
 API version:     1.26 (minimum version 1.12)
 Package version: <unknown>
 Go version:      go1.8.3
 Git commit:      774336d/1.13.1
 Built:           Wed Mar  7 17:06:16 2018
 OS/Arch:         linux/amd64
 Experimental:    false

`` `Bash
[ root @ kubernetes ~] # kubeadm version
kubeadm version: & version.Info {Major: "1", Minor: "9", GitVersion: "v1.9.4", GitCommit: "bee2d1505c4fe820744d26d41ecd3fdd4a3d6546", GitTreeState: "clean", BuildDate: "2018-03-12T16: 21: 35Z ", GoVersion:" go1.9.3 ", Compiler:" gc ", Plattform:" linux / amd64 "}

### docker Cgroup is systemd
```bash
 [root<strong i="21">@kubernetes</strong> ~]# docker info | grep Cgroup
  WARNING: You're not using the default seccomp profile
Cgroup Driver: systemd

kubelet.service wurde mit Cgroup = systemd gestartet

[root<strong i="25">@kubernetes</strong> ~]# grep cgroup /etc/systemd/system/kubelet.service.d/10-kubeadm.conf 
Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd --runtime-cgroups=/systemd/system.slice --kubelet-cgroups=/systemd/system.slice"

systemctl kubelet service neu laden und neu starten

[root<strong i="29">@kubernetes</strong> ~]# systemctl daemon-reload
[root<strong i="30">@kubernetes</strong> ~]# systemctl stop kubelet.service
[root<strong i="31">@kubernetes</strong> ~]# systemctl start kubelet.service

Kubelet-Protokolle

[root<strong i="6">@kubernetes</strong> ~]# kubelet logs
I0318 02:07:10.006151   29652 feature_gate.go:226] feature gates: &{{} map[]}
I0318 02:07:10.006310   29652 controller.go:114] kubelet config controller: starting controller
I0318 02:07:10.006315   29652 controller.go:118] kubelet config controller: validating combination of defaults and flags
I0318 02:07:10.018880   29652 server.go:182] Version: v1.9.4
I0318 02:07:10.018986   29652 feature_gate.go:226] feature gates: &{{} map[]}
I0318 02:07:10.019118   29652 plugins.go:101] No cloud provider specified.
W0318 02:07:10.019239   29652 server.go:328] standalone mode, no API client
W0318 02:07:10.068650   29652 **server.go:236] No api server defined - no events will be sent to API server.**
I0318 02:07:10.068670   29652 **server.go:428] --cgroups-per-qos enabled, but --cgroup-root was not specified.  defaulting to /**
I0318 02:07:10.069130   29652 container_manager_linux.go:242] container manager verified user specified cgroup-root exists: /
I0318 02:07:10.069306   29652 container_manager_linux.go:247] Creating Container Manager object based on Node Config: {RuntimeCgroupsName: SystemCgroupsName: KubeletCgroupsName: ContainerRuntime:docker CgroupsPerQOS:true CgroupRoot:/ CgroupDriver:cgroupfs KubeletRootDir:/var/lib/kubelet ProtectKernelDefaults:false NodeAllocatableConfig:{KubeReservedCgroupName: SystemReservedCgroupName: EnforceNodeAllocatable:map[pods:{}] KubeReserved:map[] SystemReserved:map[] HardEvictionThresholds:[{Signal:nodefs.inodesFree Operator:LessThan Value:{Quantity:<nil> Percentage:0.05} GracePeriod:0s MinReclaim:<nil>} {Signal:imagefs.available Operator:LessThan Value:{Quantity:<nil> Percentage:0.15} GracePeriod:0s MinReclaim:<nil>} {Signal:memory.available Operator:LessThan Value:{Quantity:100Mi Percentage:0} GracePeriod:0s MinReclaim:<nil>} {Signal:nodefs.available Operator:LessThan Value:{Quantity:<nil> Percentage:0.1} GracePeriod:0s MinReclaim:<nil>}]} ExperimentalQOSReserved:map[] ExperimentalCPUManagerPolicy:none ExperimentalCPUManagerReconcilePeriod:10s}
I0318 02:07:10.069404   29652 container_manager_linux.go:266] Creating device plugin manager: false
W0318 02:07:10.072836   29652 kubelet_network.go:139] Hairpin mode set to "promiscuous-bridge" but kubenet is not enabled, falling back to "hairpin-veth"
I0318 02:07:10.072860   29652 kubelet.go:576] Hairpin mode set to "hairpin-veth"
I0318 02:07:10.075139   29652 client.go:80] Connecting to docker on unix:///var/run/docker.sock
I0318 02:07:10.075156   29652 client.go:109] Start docker client with request timeout=2m0s
I0318 02:07:10.080336   29652 docker_service.go:232] Docker cri networking managed by kubernetes.io/no-op
I0318 02:07:10.090943   29652 docker_service.go:237] Docker Info: &{ID:DUEI:P7Y3:JKGP:XJDI:UFXG:NAOX:K7ID:KHCF:PCGW:46QA:TQZB:WEXF Containers:18 ContainersRunning:17 ContainersPaused:0 ContainersStopped:1 Images:11 Driver:overlay2 DriverStatus:[[Backing Filesystem xfs] [Supports d_type true] [Native Overlay Diff true]] SystemStatus:[] Plugins:{Volume:[local] Network:[bridge host macvlan null overlay] Authorization:[] Log:[]} MemoryLimit:true SwapLimit:true KernelMemory:true CPUCfsPeriod:true CPUCfsQuota:true CPUShares:true CPUSet:true IPv4Forwarding:true BridgeNfIptables:true BridgeNfIP6tables:true Debug:false NFd:89 OomKillDisable:true NGoroutines:98 SystemTime:2018-03-18T02:07:10.083543475+01:00 LoggingDriver:journald CgroupDriver:systemd NEventsListener:0 KernelVersion:3.10.0-693.21.1.el7.x86_64 OperatingSystem:CentOS Linux 7 (Core) OSType:linux Architecture:x86_64 IndexServerAddress:https://index.docker.io/v1/ RegistryConfig:0xc42027b810 NCPU:2 MemTotal:2097364992 GenericResources:[] DockerRootDir:/var/lib/docker HTTPProxy: HTTPSProxy: NoProxy: Name:kubernetes.master Labels:[] ExperimentalBuild:false ServerVersion:1.13.1 ClusterStore: ClusterAdvertise: Runtimes:map[runc:{Path:docker-runc Args:[]} docker-runc:{Path:/usr/libexec/docker/docker-runc-current Args:[]}] DefaultRuntime:docker-runc Swarm:{NodeID: NodeAddr: LocalNodeState:inactive ControlAvailable:false Error: RemoteManagers:[] Nodes:0 Managers:0 Cluster:0xc4202a8f00} LiveRestoreEnabled:false Isolation: InitBinary:docker-init ContainerdCommit:{ID: Expected:aa8187dbd3b7ad67d8e5e3a15115d3eef43a7ed1} RuncCommit:{ID:N/A Expected:9df8b306d01f59d3a8029be411de015b7304dd8f} InitCommit:{ID:N/A Expected:949e6facb77383876aeff8a6944dde66b3089574} SecurityOptions:[name=seccomp,profile=/etc/docker/seccomp.json name=selinux]}
**error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "cgroupfs" is different from docker cgroup driver: "systemd"**

kube-Prozesse laufen

[root<strong i="6">@kubernetes</strong> ~]# ps aux | grep -i kube
root     10182  0.4  1.2  54512 25544 ?        Ssl  mars17   1:10 kube-scheduler --leader-elect=true --kubeconfig=/etc/kubernetes/scheduler.conf --address=127.0.0.1
root     10235  1.8 12.7 438004 261948 ?       Ssl  mars17   4:44 kube-apiserver --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt --admission-control=Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,ResourceQuota --allow-privileged=true --requestheader-group-headers=X-Remote-Group --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-allowed-names=front-proxy-client --service-account-key-file=/etc/kubernetes/pki/sa.pub --client-ca-file=/etc/kubernetes/pki/ca.crt --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key --requestheader-username-headers=X-Remote-User --tls-private-key-file=/etc/kubernetes/pki/apiserver.key --insecure-port=0 --enable-bootstrap-token-auth=true --tls-cert-file=/etc/kubernetes/pki/apiserver.crt --secure-port=6443 --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --advertise-address=192.168.1.70 --service-cluster-ip-range=10.96.0.0/12 --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt --authorization-mode=Node,RBAC --etcd-servers=http://127.0.0.1:2379
root     10421  0.1  1.0  52464 22052 ?        Ssl  mars17   0:20 /usr/local/bin/kube-proxy --config=/var/lib/kube-proxy/config.conf
root     12199  1.7  8.5 326552 174108 ?       Ssl  mars17   4:11 kube-controller-manager --address=127.0.0.1 --leader-elect=true --controllers=*,bootstrapsigner,tokencleaner --cluster-signing-key-file=/etc/kubernetes/pki/ca.key --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt --use-service-account-credentials=true --kubeconfig=/etc/kubernetes/controller-manager.conf --root-ca-file=/etc/kubernetes/pki/ca.crt --service-account-private-key-file=/etc/kubernetes/pki/sa.key
root     22928  0.0  1.0 279884 20752 ?        Sl   01:10   0:00 /home/weave/weaver --port=6783 --datapath=datapath --name=fe:9b:da:25:e2:b2 --host-root=/host --http-addr=127.0.0.1:6784 --status-addr=0.0.0.0:6782 --docker-api= --no-dns --db-prefix=/weavedb/weave-net --ipalloc-range=10.32.0.0/12 --nickname=kubernetes.master --ipalloc-init consensus=1 --conn-limit=30 --expect-npc 192.168.1.70
root     23308  0.0  0.7  38936 15340 ?        Ssl  01:10   0:01 /kube-dns --domain=cluster.local. --dns-port=10053 --config-dir=/kube-dns-config --v=2
65534    23443  0.0  0.8  37120 18028 ?        Ssl  01:10   0:03 /sidecar --v=2 --logtostderr --probe=kubedns,127.0.0.1:10053,kubernetes.default.svc.cluster.local,5,SRV --probe=dnsmasq,127.0.0.1:53,kubernetes.default.svc.cluster.local,5,SRV
root     29547  1.6  2.9 819012 61196 ?        Ssl  02:07   0:22 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true --network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin --cluster-dns=10.96.0.10 --cluster-domain=cluster.local --authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt --cadvisor-port=0 --cgroup-driver=systemd --runtime-cgroups=/systemd/system.slice --kubelet-cgroups=/systemd/system.slice --rotate-certificates=true --cert-dir=/var/lib/kubelet/pki

v1.9.5 hat dieses Problem behoben, super! @ bart0sh

@FrostyLeaf Ich kann es immer noch mit 1.9.5 reproduzieren:

$ rpm -qa | grep kube
kubeadm-1.9.5-0.x86_64
kubelet-1.9.5-0.x86_64
kubernetes-cni-0.6.0-0.x86_64
kubectl-1.9.5-0.x86_64

$ docker info 2> / dev / null | grep -i cgroup
Cgroup-Treiber: systemd

$ ps aux | grep cgroup-Treiber
root 29078 1,9 0,1 1222632 91824? Ssl 13:45 0:04 / usr / bin / kubelet --bootstrap-kubeconfig = / etc / kubernetes / bootstrap-kubelet.conf --kubeconfig = / etc / kubernetes / kubelet.conf --pod-manifest-path = / etc / kubernetes / manifestes --allow-privileged = true --Netzwerk-Plugin = cni --cni-conf-dir = / etc / cni / net.d --cni-bin-dir = / opt / cni / bin - -cluster-dns = 10.96.0.10 --cluster-domain = cluster.local --authorization-mode = Webhook --client-ca-file = / etc / kubernetes / pki / ca.crt --cadvisor-port = 0 - -cgroup-driver = systemd --rotate-certificates = true --cert-dir = / var / lib / kubelet / pki

I0321 13: 50: 29.901008 30817 container_manager_linux.go: 247] Erstellen eines Container Manager-Objekts basierend auf Node Config: {RuntimeCgroupsName: SystemCgroupsName: KubeletCgroupsName: Enthält erRuntime: Docker Cgro upsPerQOS: true CgroupRoot: / Cgr oupDrelet: c / kubelet ProtectKerne lDefaults: false NodeAllocatableConfig: {KubeReservedCgroupName: SystemReservedCgroupName: EnforceNodeAl lokalisierbar: map [Schoten: {}] Kub eReserved: map [] Syste mReserved: map [] HardEvictionThresholds: [{ Signal: memory.available Betreiber: LessThan Wert: { Menge: 100Mi Prozentsatz: 0 } Gr acePeriod: 0s MinReclaim:} { Signal: nodefs.available Operator: LessThan Wert: {Menge:Prozentsatz: 0.1 } Gr acePeriod: 0s MinReclaim:} { Signal: nodefs.inodesFree Operator: LessThan Wert: {Menge:Prozentsatz: 0,05 } Gr acePeriod: 0s MinReclaim:} { Signal: imagefs.available Operator: LessThan Wert: {Menge:Prozentsatz: 0,15 } Gr acePeriod: 0s MinReclaim:}]} ExperimentalQO SReserved: map [] ExperimentalCPUMana gerPolicy: keine ExperimentalCPUManagerReconc ilePeriod: 10s }
Fehler: Kubelet konnte nicht ausgeführt werden: Kubelet konnte nicht erstellt werden: Fehlkonfiguration: Kubelet-Cgroup-Treiber: "cgroupfs" unterscheidet sich vom Docker-Cgroup-Treiber: "systemd"

Verwenden Sie immer noch den systemd cgroup-Treiber?

Ich schlage vor, dieses Problem zu schließen

Ich habe zwei Gründe beobachtet, die die meisten Berichte hier verursachen:

1. Vergessen, 'systemctl daemon-reload' auszuführen, nachdem systemd Drop-Ins bearbeitet wurden. Obwohl -cgroup-driver = systemd zu /etc/systemd/system/kubelet.service.d/10-kubeadm.conf hinzugefügt wurde, hatte dies keine Auswirkungen und der Standardtreiber (oder zuvor mit --cgroup-driver angegeben) war benutzt.

2. Ausführen des Befehls 'kubelet logs', um kubelet logs anzuzeigen. Der Unterbefehl 'logs' ist in kubelet nicht vorhanden, daher sind 'kubelet logs' und 'kubelet' dieselben Befehle. 'kubelet logs' führt kubelet mit dem Standard-cgroup-Treiber 'cgroupfs' aus und kubelet beschwert sich über Inkonsistenzen zwischen kubelet- und Docker-Treibern. 'journalctl -ux kubelet' sollte verwendet werden, um die Protokolle anzuzeigen.

Ich habe die Option --cgroup-driver = systemd mit kubelet 1.8.0, 1.9.0, 1.9.3 und 1.9.5 getestet. Es gab keine Fehlermeldungen "cgroupfs unterscheidet sich vom Docker-cgroup-Treiber: systemd" in den Protokollen.

@ Timothysc Es gibt keine Einwände gegen meinen letzten Kommentar. Können Sie dieses Problem bitte schließen? Es ist kein Fehler, da es durch mangelndes Wissen über Kubelet und / oder Systemd verursacht wird.

2 Dinge, die aus meiner Sicht sinnvoll sein könnten, sind:

• Implementieren Sie die Preflight-Prüfung für "kubeadm init", um zu überprüfen, ob die Docker- und Kubelet-Gruppentreiber übereinstimmen.
• kubelet fehlschlagen lassen, wenn unbekannte Parameter in der Befehlszeile gefunden werden, z. B. "kubelet-Protokolle" sollten mit der Fehlermeldung "nicht erkannter Parameter: Protokolle" fehlschlagen.

Wir können erwägen, separate Probleme für diese zu erstellen.

Auf jeden Fall kann dieses Problem geschlossen werden.

Dank der Version 1.9.5 sieht es für mich

Stimmen Sie mit @ bart0sh über den Init überein, der die Konsistenz des cgroup-Treibers zwischen Kubelet und Docker überprüft.
Vielleicht sollten die `kublet-Protokolle {auf den journactl -u kubelet.service verweisen

Nur meine 2cts.

Hallo, ich habe das gleiche Problem.
Centos 7
kubeadm version ist: 1.9.6
Docker-Version ist: 1.13.1 API-Version: 1.26
als ich lief: docker info | grep -i cgroup ,
Ich schaff das:
WARNING: You're not using the default seccomp profile Cgroup Driver: systemd

wenn ich cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf laufen
Ich kann die Einstellungen Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd" .

Ich habe systemctl daemon-reload * und * systemctl restart kubelet ausgeführt , aber es wird immer noch angezeigt

Fehlkonfiguration: kubelet cgroup Treiber: "cgroupfs" unterscheidet sich vom Docker cgroup Treiber: "systemd"

Eine andere seltsame Sache ist: als ich sed -i "s/cgroup-driver=systemd/cgroup-driver=cgroupfs/g" /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Ich habe gesehen, dass das Laufwerk --cgroup in
Aber dann wurde genau die gleiche Fehlermeldung angezeigt, als ich kubelet status erneut ausführte.

Fehlkonfiguration: kubelet cgroup Treiber: "cgroupfs" unterscheidet sich vom Docker cgroup Treiber: "systemd"

Ich kann das Problem nicht herausfinden.
Ich werde es mit den oben genannten Versionen versuchen. Weiß jemand, wie man eine ältere Version von Kubernetes installiert? Vielen Dank.

@moqichenle Das ist seltsam. Es sollte funktionieren. Können Sie die Ausgabe der folgenden Befehle anzeigen?

systemctl daemon-reload
systemctl restart kubelet
docker info 2>/dev/null |grep -i group
ps aux |grep group-driver
journalctl -u kubelet.service | grep "is different from docker cgroup driver"

Folgendes sehe ich auf meinem System:

# systemctl daemon-reload
# systemctl restart kubelet
# docker info 2>/dev/null |grep -i group
Cgroup Driver: systemd
# ps aux |grep group-driver
root     25062  5.7  0.1 983760 78888 ?        Ssl  15:26   0:00 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true --network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin --cluster-dns=NN.NN.NN.NN --cluster-domain=cluster.local --authorization-mode=Webhook --client-ca-file=/etc/kubernetes/pki/ca.crt --cadvisor-port=0 --cgroup-driver=systemd --rotate-certificates=true --cert-dir=/var/lib/kubelet/pki
root     25520  0.0  0.0   9288  1560 pts/0    R+   15:26   0:00 grep --color=auto group-driver
# journalctl -u kubelet.service | grep "is different from docker cgroup driver"
#

@ bart0sh Hallo, danke für die Hilfe.
Folgendes habe ich (vor dem Start von kubeadm init):
[root<strong i="8">@localhost</strong> bin]# docker info 2>/dev/null |grep -i group Cgroup Driver: systemd [root<strong i="9">@localhost</strong> bin]# ps aux |grep group-driver root 13472 0.0 0.1 12476 984 pts/0 R+ 13:23 0:00 grep --color=auto group-driver

Nach Eingabe des Befehls kubeadm init,
das ist was ich habe:
[vagrant<strong i="14">@localhost</strong> ~]$ ps aux |grep group-driver root 13606 5.1 4.5 605240 22992 ? Ssl 13:25 0:03 /usr/bin/kubelet --kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true --pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true --network-plugin=cni --cni-conf-dir=/etc/cni/net.d --cni-bin-dir=/opt/cni/bin --cluster-dns=10.96.0.10 --cluster-domain=cluster.local --cgroup-driver=systemd --hostname-override=default vagrant 13924 0.0 0.1 12476 984 pts/1 R+ 13:26 0:00 grep --color=auto group-driver

Aber dann schlägt kubeadm init fehl, weil entweder kubelet nicht gesund ist oder kubelet nicht läuft.

@moqichenle haben Sie laufen systemctl daemon-reload und systemctl restart kubelet vor dem Ausführen von kubeadm init ?

Können Sie journalctl -u kubelet.service nach kubeadm init ausführen und die Ausgabe hier anzeigen?

Ja, ich habe die beiden Befehle vor dem Init ausgeführt.
Seltsame Sache: Ich habe keine Ausgabe gesehen, als ich journalctl -u kubelet.service | grep "is different from docker cgroup driver" .
Ich habe diesen Fehler nur gesehen, als ich kubelet status .

Der Befehl @moqichenle kubelet status existiert nicht. Das bedeutet, dass Sie kubelet mit den Standardparametern (und dem Standard-cgroup-Treiber) ausführen. Deshalb erhalten Sie den Fehler. Weitere Informationen finden Sie in meinen Nachrichten zu kubelet logs .

Sehen Sie etwas Verdächtiges (Fehler, Warnungen) in der Ausgabe von journalctl -u kubelet.service ?

Ah ich sehe. Vielen Dank. :) :)
hmm .. es werden folgende Fehler angezeigt:
Mar 26 13:39:40 localhost.localdomain kubelet[13606]: E0326 13:39:34.198202 13606 kuberuntime_image.go:140] ListImages failed: rpc error: code = DeadlineExceeded desc = context deadline exceeded Mar 26 13:39:45 localhost.localdomain kubelet[13606]: E0326 13:39:44.824222 13606 kubelet.go:1259] Container garbage collection failed: rpc error: code = DeadlineExceeded desc = context deadline exceeded Mar 26 13:39:47 localhost.localdomain kubelet[13606]: W0326 13:39:44.749819 13606 image_gc_manager.go:173] [imageGCManager] Failed to monitor images: rpc error: code = DeadlineExceeded desc = context deadline exceeded Mar 26 13:39:49 localhost.localdomain kubelet[13606]: E0326 13:39:49.486990 13606 kubelet.go:1281] Image garbage collection failed once. Stats initialization may not have completed yet: failed to get image stats: rpc error: code = DeadlineExceeded desc = context deadline exceeded Mar 26 13:42:03 localhost.localdomain kubelet[13606]: E0326 13:42:03.934312 13606 remote_runtime.go:169] ListPodSandbox with filter nil from runtime service failed: rpc error: code = DeadlineExceeded desc = context deadline exceeded Mar 26 13:42:03 localhost.localdomain kubelet[13606]: E0326 13:42:03.934359 13606 kuberuntime_sandbox.go:192] ListPodSandbox failed: rpc error: code = DeadlineExceeded desc = context deadline exceeded Mar 26 13:42:03 localhost.localdomain kubelet[13606]: E0326 13:42:03.934374 13606 generic.go:197] GenericPLEG: Unable to retrieve pods: rpc error: code = DeadlineExceeded desc = context deadline exceeded Mar 26 13:42:03 localhost.localdomain kubelet[13606]: E0326 13:42:03.936761 13606 remote_image.go:67] ListImages with filter nil from image service failed: rpc error: code = DeadlineExceeded desc = context deadline exceeded Mar 26 13:42:03 localhost.localdomain kubelet[13606]: E0326 13:42:03.936788 13606 kuberuntime_image.go:106] ListImages failed: rpc error: code = DeadlineExceeded desc = context deadline exceeded Mar 26 13:42:03 localhost.localdomain kubelet[13606]: W0326 13:42:03.936795 13606 image_gc_manager.go:184] [imageGCManager] Failed to update image list: rpc error: code = DeadlineExceeded desc = context deadline exceeded Mar 26 13:42:03 localhost.localdomain kubelet[13606]: E0326 13:42:03.937002 13606 remote_runtime.go:69] Version from runtime service failed: rpc error: code = DeadlineExceeded desc = context deadline exceeded Mar 26 13:42:03 localhost.localdomain kubelet[13606]: E0326 13:42:03.937020 13606 kuberuntime_manager.go:245] Get remote runtime version failed: rpc error: code = DeadlineExceeded desc = context deadline exceeded

Wenn ich kubeadm init ausgeführt habe, wenn die Einstellungen des cgroup-Laufwerks unterschiedlich sind:
Es zeigt:
`[etcd] Schrieb ein statisches Pod-Manifest für eine lokale etcd-Instanz an" /etc/kubernetes/manifests/etcd.yaml ".
[init] Warten, bis das Kubelet die Steuerebene als statische Pods aus dem Verzeichnis "/ etc / kubernetes / manifests" gestartet hat.
[init] Dies kann eine Minute oder länger dauern, wenn die Bilder der Steuerebene gezogen werden müssen.
[Kubelet-Check] Es scheint, als ob das Kubelet nicht läuft oder gesund ist.
Wenn die Einstellungen des cgroup-Laufwerks identisch sind,
Es hängt nur beim Ziehen des Bedienfelds und führt dazu, dass das Kubelet ungesund ist oder nicht läuft.

@moqichenle es sieht für mich wie ein Docker-Problem aus. Es hat nichts mit diesem zu tun, glaube ich.

Sie können nach "Kontextfrist überschritten" suchen, um weitere Informationen zu erhalten.

@ bart0sh Ja , glaube nicht, dass es mehr mit diesem Problem zu tun hat. Wird besorgt. Vielen Dank: D.

Diese PR sollte dazu beitragen, die Verwirrung zu verringern, die durch das Ausführen von "Kubelet-Protokollen", "Kubelet-Status" und anderen nicht vorhandenen Kubelet-Befehlen verursacht wird: # 61833

Es führt dazu, dass kubelet Fehler erzeugt und beendet wird, wenn es mit einer falschen Befehlszeile ausgeführt wird.

Lesen Sie bitte.

Hallo, ich kann dieses Problem auf 1.10 reproduzieren. Nur um zu überprüfen, ob dies ein Fehler ist und in Version 1.11 behoben wird.

Ist dies ein Fehler und wird in v1.11 behoben

IMO ist dies eine Konfigurationsinkongruenz zwischen docker und kubelet und kein Fehler.

Vor dem Ausführen von kubeadm init sollte eine Überprüfung des cgroup-Treibers durchgeführt werden.

@dixudx Ich versuche, die k8s zu installieren, gefolgt von der Installationsanleitung von der Website https://kubernetes.io/docs/setup/independent/install-kubeadm/ . Die Schritte wurden von diesem Problem ausgeführt. Nachfolgend sind die Details meiner Umgebung aufgeführt ;;

Betriebssystem:

CentOS Linux release 7.4.1708 (Core)

<br i="12"/>
  Server Version:  1.13.1<br i="13"/>
 API version:     1.26 (minimum version 1.12)<br i="14"/>
 Package version: <unknown i="15"><br i="16"/>
 Go version:      go1.8.3<br i="17"/>
 Git commit:      774336d/1.13.1<br i="18"/>
 Built:           Wed Mar  7 17:06:16 2018<br i="19"/>
 OS/Arch:         linux/amd64<br i="20"/>
 Experimental:    false</unknown>

kubeadm.x86_64                     1.10.1-0<br i="24"/>
kubectl.x86_64                     1.10.1-0<br i="25"/>
kubelet.x86_64                     1.10.1-0<br i="26"/>
kubernetes-cni.x86_64              0.6.0-0                          

Die Gruppe zwischen Docker und Kubelet

docker info | grep -i cgroup<br i="30"/>
  WARNING: You're not using the default seccomp profile<br i="31"/>
Cgroup Driver: systemd

 cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf | grep -i cgroup<br i="35"/>
Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd"

Es ist dieselbe cgroup wie systemd, daher muss die cgroelet of kubelet nicht manuell angepasst werden. Und ich fange an, kubelet auszuführen, bin aber aufgrund der genannten Fehlermeldung fehlgeschlagen

[root@K8S-Master /]# kubelet logs
I0424 10:41:29.240854   19245 feature_gate.go:226] feature gates: &{{} map[]}
W0424 10:41:29.247770   19245 cni.go:171] Unable to update cni config: No networks found in /etc/cni/net.d
W0424 10:41:29.253069   19245 hostport_manager.go:68] The binary conntrack is not installed, this can cause failures in network connection cleanup.
I0424 10:41:29.253111   19245 server.go:376] Version: v1.10.1
I0424 10:41:29.253175   19245 feature_gate.go:226] feature gates: &{{} map[]}
I0424 10:41:29.253290   19245 plugins.go:89] No cloud provider specified.
W0424 10:41:29.253327   19245 server.go:517] standalone mode, no API client
W0424 10:41:29.283851   19245 server.go:433] No api server defined - no events will be sent to API server.
I0424 10:41:29.283867   19245 server.go:613] --cgroups-per-qos enabled, but --cgroup-root was not specified.  defaulting to /
I0424 10:41:29.284091   19245 container_manager_linux.go:242] container manager verified user specified cgroup-root exists: /
I0424 10:41:29.284101   19245 container_manager_linux.go:247] Creating Container Manager object based on Node Config: {RuntimeCgroupsName: SystemCgroupsName: KubeletCgroupsName: ContainerRuntime:docker CgroupsPerQOS:true CgroupRoot:/ CgroupDriver:cgroupfs KubeletRootDir:/var/lib/kubelet ProtectKernelDefaults:false NodeAllocatableConfig:{KubeReservedCgroupName: SystemReservedCgroupName: EnforceNodeAllocatable:map[pods:{}] KubeReserved:map[] SystemReserved:map[] HardEvictionThresholds:[{Signal:memory.available Operator:LessThan Value:{Quantity:100Mi Percentage:0} GracePeriod:0s MinReclaim:<nil i="39">} {Signal:nodefs.available Operator:LessThan Value:{Quantity:<nil i="40"> Percentage:0.1} GracePeriod:0s MinReclaim:<nil i="41">} {Signal:nodefs.inodesFree Operator:LessThan Value:{Quantity:<nil i="42"> Percentage:0.05} GracePeriod:0s MinReclaim:<nil i="43">} {Signal:imagefs.available Operator:LessThan Value:{Quantity:<nil i="44"> Percentage:0.15} GracePeriod:0s MinReclaim:<nil i="45">}]} ExperimentalQOSReserved:map[] ExperimentalCPUManagerPolicy:none ExperimentalCPUManagerReconcilePeriod:10s ExperimentalPodPidsLimit:-1 EnforceCPULimits:true}
I0424 10:41:29.284195   19245 container_manager_linux.go:266] Creating device plugin manager: true
I0424 10:41:29.284242   19245 state_mem.go:36] [cpumanager] initializing new in-memory state store
I0424 10:41:29.284292   19245 state_mem.go:87] [cpumanager] updated default cpuset: ""
I0424 10:41:29.284326   19245 state_mem.go:95] [cpumanager] updated cpuset assignments: "map[]"
W0424 10:41:29.286890   19245 kubelet_network.go:139] Hairpin mode set to "promiscuous-bridge" but kubenet is not enabled, falling back to "hairpin-veth"
I0424 10:41:29.286912   19245 kubelet.go:556] Hairpin mode set to "hairpin-veth"
I0424 10:41:29.288233   19245 client.go:75] Connecting to docker on unix:///var/run/docker.sock
I0424 10:41:29.288268   19245 client.go:104] Start docker client with request timeout=2m0s
W0424 10:41:29.289762   19245 cni.go:171] Unable to update cni config: No networks found in /etc/cni/net.d
W0424 10:41:29.292669   19245 hostport_manager.go:68] The binary conntrack is not installed, this can cause failures in network connection cleanup.
I0424 10:41:29.293904   19245 docker_service.go:244] Docker cri networking managed by kubernetes.io/no-op
I0424 10:41:29.302849   19245 docker_service.go:249] Docker Info: &amp;{ID:UJ6K:K2AW:HKQY:5MRL:KROX:FTJV:3TKY:GHGI:L7GV:UQFP:AU2Q:AKC6 Containers:0 ContainersRunning:0 ContainersPaused:0 ContainersStopped:0 Images:0 Driver:overlay2 DriverStatus:[[Backing Filesystem xfs] [Supports d_type true] [Native Overlay Diff true]] SystemStatus:[] Plugins:{Volume:[local] Network:[bridge host macvlan null overlay] Authorization:[] Log:[]} MemoryLimit:true SwapLimit:true KernelMemory:true CPUCfsPeriod:true CPUCfsQuota:true CPUShares:true CPUSet:true IPv4Forwarding:true BridgeNfIptables:true BridgeNfIP6tables:true Debug:false NFd:16 OomKillDisable:true NGoroutines:26 SystemTime:2018-04-24T10:41:29.295491971+08:00 LoggingDriver:journald CgroupDriver:systemd NEventsListener:0 KernelVersion:3.10.0-693.5.2.el7.x86_64 OperatingSystem:CentOS Linux 7 (Core) OSType:linux Architecture:x86_64 IndexServerAddress:https://index.docker.io/v1/ RegistryConfig:0xc4203dcbd0 NCPU:4 MemTotal:8371650560 GenericResources:[] DockerRootDir:/var/lib/docker HTTPProxy: HTTPSProxy: NoProxy: Name:K8S-Master Labels:[] ExperimentalBuild:false ServerVersion:1.13.1 ClusterStore: ClusterAdvertise: Runtimes:map[docker-runc:{Path:/usr/libexec/docker/docker-runc-current Args:[]} runc:{Path:docker-runc Args:[]}] DefaultRuntime:docker-runc Swarm:{NodeID: NodeAddr: LocalNodeState:inactive ControlAvailable:false Error: RemoteManagers:[] Nodes:0 Managers:0 Cluster:0xc4201317c0} LiveRestoreEnabled:false Isolation: InitBinary:docker-init ContainerdCommit:{ID: Expected:aa8187dbd3b7ad67d8e5e3a15115d3eef43a7ed1} RuncCommit:{ID:N/A Expected:9df8b306d01f59d3a8029be411de015b7304dd8f} InitCommit:{ID:N/A Expected:949e6facb77383876aeff8a6944dde66b3089574} SecurityOptions:[name=seccomp,profile=/etc/docker/seccomp.json name=selinux]}
F0424 10:41:29.302989   19245 server.go:233] failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: <font i="46">"cgroupfs"</font> is different from docker cgroup driver: "systemd"</nil></nil></nil></nil></nil></nil></nil>

Die wichtigste Information, die ich aus dem Protokoll sehe, ist, dass CgroupDriver immer noch cgroupfs ist. Ich denke, das ist der Grund für das Problem mit der Nichtübereinstimmung von cgroup. Sie haben jedoch keine Ahnung, wie Sie diesen Standardwert anpassen können. Kannst du helfen, das zu klären, danke!

@wshandao Bitte verwenden Sie kubelet logs nicht mehr. Dies ist nicht der richtige Weg, um das Protokoll

Die korrekte Art, das Protokoll anzuzeigen, ist journalctl -f -u kubelet .

Vielen Dank an @dixudx , mein Fehler und dies ist eigentlich kein Problem, um meine Installation zu halten

Ich stimme den Anfragen zu, diese zu schließen.
In der Dokumentation wird bereits beschrieben, dass die Benutzer einen passenden cgroups-Treiber überprüfen müssen.

Dies ist unabhängig von Kubeadm und eher ein Problem zwischen Kubelet und Docker.

ähnliche Berichte:
https://github.com/kubernetes/kubernetes/issues/59794
https://github.com/openshift/origin/issues/18776
https://github.com/kubernetes/kubernetes/issues/43805

@ Timstclair

FWIW Dies ist standardmäßig in den RPMs, jedoch nicht in .debs. Gibt es eine aktuelle Distribution im Haupt-Support, die jetzt nicht standardmäßig systemd ist?

Ich habe dies auf 3 verschiedenen Bare-Bone-Ubuntu 16.04.2, 16.04.0, 17.04 getestet und es scheint, dass der Docker-Treiber cgroupfs , was dem Standardargumentwert des Kublets entspricht.

Im Gegensatz zu dem Benutzerbericht im ursprünglichen Beitrag, in dem Docker systemd für 16.04.3 , kann es sein, dass die Docker-Konfiguration zwischen Docker-Versionen wechselt. schwer zu erzählen.

Angesichts meiner Tests sehe ich keine Notwendigkeit, Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd" in den Debs hinzuzufügen, da dies zumindest für diese Ubuntu-Versionen falsch wäre.

Was das Kublet wahrscheinlich für eine benutzerfreundliche UX tun sollte, ist, immer automatisch mit dem Docker-Treiber übereinzustimmen.

@ neolit123 stimmte zu.

Ich denke jedoch, wir sollten ein JIC zur Fehlerbehebung für Dokumente öffnen.
Wenn Sie dieses schließen, starten Sie meine Dokumente.

Ich hatte das gleiche Problem unter Ubuntu 16.04, Kube Version v1.10.4. Docker Version 1.13.1
Docker startete mit native.cgroupdriver = systemd. Diese Konfiguration wurde von mir in /etc/docker/daemon.json festgelegt

{
"exec-opts": ["native.cgroupdriver=systemd"]
}

Ich habe die Konfiguration in /etc/systemd/system/kubelet.service.d/10-kubeadm.conf geändert
Neue Zeile hinzugefügt: Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd"
Und fügen Sie den Parameter $KUBELET_CGROUP_ARGS in ExecStart hinzu

Dann wurde ein systemctl-Daemon-Reload und ein Service-Kubelet-Neustart durchgeführt.
Kubelet hat richtig angefangen.

@dragosrosculete

Wir verbessern unsere Fehlerbehebungsdokumente, aber auch in Version 1.11 und höher sollte der cgroup-Treiber für Docker automatisch von kubeadm abgeglichen werden.

Ich denke es ist ein Fehler. Ich habe die Docker-Version und die Kubeadm-Datei überprüft. Natürlich führt das Kubeadm-Skript diese Überprüfung auch durch. Ich bekomme jedoch die Nichtübereinstimmung err msg. Wenn jemand jemals sorgfältig gelesen hat, können Sie sehen, dass einige der oben genannten Probleme auftreten, nachdem der Parameter richtig eingestellt wurde.

das passiert immer noch, nichts hat funktioniert!