Kubeadm: ОТЧЕТ ОБ ОШИБКЕ: драйвер cgroup kubelet

ошибка: не удалось запустить Kubelet: не удалось создать кубелет: неверная конфигурация: драйвер cgroup kubelet: «cgroupfs» отличается от драйвера cgroup docker: «systemd»

информация о докере | grep -i cgroup
Драйвер Cgroup: systemd

Я могу это подтвердить.

@ lavender2020 Вам необходимо вручную добавить --cgroup-driver=systemd к аргументам запуска kubelet и перезагрузить файл модуля kubelet, чтобы перезапустить службу.

Драйвер по умолчанию, который kubelet использует для управления контрольными группами на хосте, - это cgroupfs .

Большинство людей обращаются к kubeadm основном для очень быстрой настройки кластера. Это просто и практично。

@luxas Должны ли мы добавить предварительную проверку согласованности драйвера cgroup между docker и kubelet чтобы выдавать более явные предупреждения? Или добавить еще один дроп-ин за kubelet.service ? Или просто изменить /etc/systemd/system/kubelet.service.d/10-kubeadm.conf на месте?

Но если это так, нам может потребоваться получить привилегию root, чтобы принять эти изменения.

Я столкнулся с той же проблемой с kubeadm v1.9.2 но я вижу, что kubelet настроен на использование драйвера cgroup systemd.

kubelet использует --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

информация о докере |

 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

кубелет бревна

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"

Информация о версии:

 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 Вы перезагрузили файл kubelet.service unit?

Запустите systemctl daemon-reload . А потом systemctl restart kubelet .

Эта проблема не была исправлена ​​в версии 1.9.3.

Информация о версии:

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 Какой у вас драйвер

$ docker info | grep -i cgroup

Такая же проблема.

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"

Есть ли где-нибудь еще, что Kubelet получает директиву драйвера cgroupfs?

@ mas-dse-greina См. решение в моем комментарии .

@dixudx Даже после добавления --cgroup-driver=systemd к /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_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: Исправлено. После перезапуска демона и kubelet я использовал kubeadm init --pod-network-cidr = 10.244.0.0 / 16

Да. Я нахожу то же самое. Добавление --cgroup-driver = systemd
похоже, не имеет никакого эффекта. Я перезапустил службу и даже
перезагрузил компьютер.

Похоже, что такое поведение только на этой машине. я был
успешно с 4 другими машинами, но эта, кажется, просто не хочет
присоединиться к кластеру.

-Тони

Чт, 1 марта 2018 г., 11:44, srinivas491-oneconvergence <
[email protected]> написал:

@dixudx https://github.com/dixudx Даже после добавления
--cgroup-driver = systemd в / etc / systemd / system / kubelet.
service.d / 10-kubeadm.conf проблема все еще сохраняется.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/kubernetes/kubeadm/issues/639#issuecomment-369707723 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AVReEuQHJR80-8J4VLvACnGt1lTjEbYrks5taE-BgaJpZM4RSs0P
.

После изменения файла модуля вам нужно systemdctl daemon-reload чтобы изменения вступили в силу.

FWIW это значение по умолчанию в RPM, но не в .debs. Есть ли какой-либо текущий дистрибутив в основной поддержке, который сейчас не используется по умолчанию для systemd?

/ назначить @detiber

Я столкнулся с той же проблемой с kubeadm v1.9.3 и v1.9.4.

Запустите kubelet с помощью --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

Перезагрузить сервис

$ systemctl daemon-reload
$ systemctl restart kubelet

Проверить информацию о докере

$ 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 logs
error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "cgroupfs" is different from docker cgroup driver: "systemd"

Информация о версии

$ 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 Можете ли вы посмотреть в командной строке запуска kubelet, чтобы узнать, указан ли там драйвер cgroup?

Что-то вроде ps aux |grep kubelet или cat /proc/<kubelet pid>/cmdline должно помочь вам в этом.

@ bart0sh Вот и все:

$  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 Спасибо! Я мог бы воспроизвести и это. Кажется, это ошибка. Глядя на это.

В качестве временного решения вы можете переключить docker и kubelet на драйвер cgroupfs. Он должен работать.

@ bart0sh Хорошо. Большое спасибо. Я попробую это.

То же самое.

Хост контекста = CentOS 7.4, Гость = VirtualBox = Версия 5.2.8 r121009 (Qt5.6.1)

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

Баш
[ 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

Баш
[ root @ kubernetes ~] # версия kubeadm
kubeadm version: & version.Info {Major: «1», Minor: «9», GitVersion: «v1.9.4», GitCommit: «bee2d1505c4fe820744d26d41ecd3fdd4a3d6546», GitTreeState: «clean», BuildTate16: «21-03-12» 35Z ", GoVersion:" go1.9.3 ", компилятор:" gc ", платформа:" 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 запущен с Cgroup = systemd

[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

[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

кубелет бревна

[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 запущены

[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 эта проблема исправлена, здорово! @ bart0sh

@FrostyLeaf Я все еще могу воспроизвести его с помощью 1.9.5:

$ rpm -qa | grep kube
kubeadm-1.9.5-0.x86_64
кубелет-1.9.5-0.x86_64
кубернетес-cni-0.6.0-0.x86_64
kubectl-1.9.5-0.x86_64

$ docker info 2> / dev / null | grep -i cgroup
Драйвер Cgroup: systemd

$ ps aux | grep cgroup-драйвер
корень 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 / manifestests --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-Certific = true --cert-dir = / var / lib / kubelet / pki

I0321 13: 50: 29,901008 30817 container_manager_linux.go: 247] Создание объекта Container менеджера на основе Узла Config: {RuntimeCgroupsName: SystemCgroupsName: KubeletCgroupsName: Содержать erRuntime: докер CGRO upsPerQOS: истинный CgroupRoot: / Cgr oupDriver: cgroupfs KubeletRootDir: / вар / Библиотека / kubelet ProtectKerne lDefaults: ложь NodeAllocatableConfig: {KubeReservedCgroupName: SystemReservedCgroupName: EnforceNodeAl передвижными: карта [стручки: {}] Kub eReserved: карта [] Syste mReserved: карта [] HardEvictionThresholds: [{ Сигнал: memory.available Оператор: LessThan Значение: { Количество: 100Mi Процент: 0 } Gr acePeriod: 0s MinReclaim:} { Сигнал: nodefs.available Оператор: LessThan Значение: {Количество:Процент: 0,1 } Gr acePeriod: 0s MinReclaim:} { Сигнал: nodefs.inodesFree Оператор: LessThan Значение: {Количество:Процент: 0,05 } Gr acePeriod: 0s MinReclaim:} { Signal: imagefs.available Оператор: LessThan Значение: {Количество:Процент: 0,15 } Gr acePeriod: 0s MinReclaim:}]} ExperimentalQO SReserved: map [] ExperimentalCPUMana gerPolicy: none ExperimentalCPUManagerReconc ilePeriod: 10s }
ошибка: не удалось запустить Kubelet: не удалось создать кубелет: неверная конфигурация: драйвер cgroup kubelet :

Вы все еще используете драйвер systemd cgroup?

Предлагаю закрыть этот вопрос

Я заметил 2 причины, по которым здесь появляется большинство отчетов:

1. забывая запустить systemctl daemon-reload после редактирования выпадающих файлов systemd. Хотя -cgroup-driver = systemd был добавлен в /etc/systemd/system/kubelet.service.d/10-kubeadm.conf, это не дало никакого эффекта, и драйвер по умолчанию (или ранее указанный с помощью --cgroup-driver) был использовал.

2. запустите команду kubelet logs, чтобы просмотреть журналы kubelet. Подкоманды 'logs' в kubelet нет, поэтому 'kubelet logs' и 'kubelet' - это одни и те же команды. 'kubelet logs' запускает kubelet с драйвером cgroup по умолчанию 'cgroupfs', а kubelet жалуется на несоответствие между драйверами kubelet и docker. Для просмотра журналов следует использовать journalctl -ux kubelet.

Я тестировал параметр --cgroup-driver = systemd с kubelet 1.8.0, 1.9.0, 1.9.3 и 1.9.5. В журналах не было сообщений об ошибках "cgroupfs отличается от docker cgroup driver: systemd".

@timothysc По моему последнему комментарию возражений нет. Не могли бы вы закрыть этот вопрос, пожалуйста? Это не ошибка, так как она вызвана отсутствием знаний о kubelet и / или systemd.

С моей точки зрения, имеет смысл сделать 2 вещи:

• реализовать предполетную проверку для "kubeadm init", чтобы проверить, совпадают ли драйверы контрольной группы docker и kubelet.
• заставить kubelet завершиться ошибкой, если он обнаружит неизвестный параметр в командной строке, например, «журналы kubelet» должны завершиться ошибкой с сообщением об ошибке «нераспознанный параметр: журналы»

Мы можем рассмотреть возможность создания для них отдельных задач.

В любом случае, этот вопрос можно закрыть.

У меня все хорошо благодаря v1.9.5.

Согласитесь с @ bart0sh о том, что инициализация проверяет согласованность драйверов cgroup между kubelet и docker.
Возможно, журналы `kublet {должны указывать на journactl -u kubelet.service

Просто мой 2цт.

Привет, у меня такая же проблема.
Centos 7
версия kubeadm: 1.9.6
версия докера: 1.13.1 Версия API: 1.26
когда я побежал: docker info | grep -i cgroup ,
Получил вот что:
WARNING: You're not using the default seccomp profile Cgroup Driver: systemd

когда я запускаю cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf ,
Я вижу настройки Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd" на месте.

Я запустил systemctl daemon-reload * и * systemctl restart kubelet , но он все еще отображается

неправильная конфигурация: драйвер cgroup kubelet: "cgroupfs" отличается от драйвера cgroup docker: "systemd"

Еще одна странность: когда я запустил sed -i "s/cgroup-driver=systemd/cgroup-driver=cgroupfs/g" /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Я видел, что параметр --cgroup-drive заменен на cgroupfs .
Но затем та же самая ошибка msg была показана, когда я снова запустил kubelet status .

неправильная конфигурация: драйвер cgroup kubelet: "cgroupfs" отличается от драйвера cgroup docker: "systemd"

Я не могу понять проблему.
Я попробую с упомянутыми выше версиями. Кто-нибудь знает, как установить более старую версию кубернетов? Спасибо.

@moqichenle Странно. Он должен работать. Можете ли вы показать вывод следующих команд?

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"

Вот что я вижу в своей системе:

# 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 Привет, спасибо за помощь.
Вот что у меня есть (перед запуском 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

После ввода команды kubeadm init,
вот что у меня есть:
[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

Но тогда kubeadm init завершится ошибкой, потому что либо kubelet не работает, либо kubelet не работает.

@moqichenle вы запускали systemctl daemon-reload и systemctl restart kubelet перед запуском kubeadm init ?

Можете ли вы запустить journalctl -u kubelet.service после kubeadm init и показать здесь результат?

Да, я выполнил две команды до инициализации.
Странная вещь: я не видел никаких результатов, когда запускал journalctl -u kubelet.service | grep "is different from docker cgroup driver" .
Я увидел эту ошибку только при запуске kubelet status .

@moqichenle kubelet status команды не существует. Это означает, что вы запускаете kubelet с параметрами по умолчанию (и драйвером cgroup по умолчанию). Вот почему вы получаете сообщение об ошибке. См. Мои сообщения по поводу kubelet logs для получения дополнительной информации.

Вы видите что-нибудь подозрительное (ошибки, предупреждения) в выводе journalctl -u kubelet.service ?

Ах я вижу. Спасибо. :)
хм .. есть ошибки, показанные ниже:
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

Когда я запускал kubeadm init, если настройки диска cgroup другие:
Это показывает:
`[etcd] Записал манифест статического модуля для локального экземпляра etcd в" /etc/kubernetes/manifests/etcd.yaml "
[init] Ожидание, пока кубелет загрузит плоскость управления как статические модули из каталога "/ etc / kubernetes / manifest".
[init] Это может занять минуту или больше, если нужно извлечь изображения плоскости управления.
[kubelet-check] Кажется, кубелет не работает или не исправен.
Когда настройки cgroup drive такие же,
он просто зависает на шаге вытаскивания панели управления и в итоге кубелет неработоспособен или не работает.

@moqichenle для меня это проблема с докером. Я считаю, что это не связано с этим.

Вы можете выполнить поиск по запросу «истек срок контекста» для получения дополнительной информации.

@ bart0sh Ага, не думаю, что это больше связано с этой проблемой. Сделаю. Большое спасибо: D

этот PR должен помочь уменьшить путаницу, вызванную запуском 'журналов kubelet', 'kubelet status' и других несуществующих команд kubelet: # 61833

Он заставляет kubelet выдавать ошибку и завершать работу, если он запущен с неправильной командной строкой.

Пожалуйста, просмотрите.

Привет, я могу воспроизвести эту проблему в 1.10, просто чтобы проверить, является ли это ошибкой и будет ли она исправлена ​​в версии 1.11?

это ошибка и будет исправлена ​​в v1.11

ИМО, это несоответствие конфигурации между docker и kubelet , а не ошибка.

Перед запуском kubeadm init необходимо выполнить предварительную проверку драйвера cgroup .

@dixudx Я пытаюсь установить k8s, а затем руководство по установке с веб-сайта https://kubernetes.io/docs/setup/independent/install-kubeadm/ , и шаги были задержаны этой проблемой, ниже приведены сведения о моей среде ;

ОПЕРАЦИОННЫЕ СИСТЕМЫ:

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                          

Группа между докером и кубелетом

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"

Это та же контрольная группа, что и systemd, поэтому нет необходимости настраивать контрольную группу kubelet вручную. И я начал запускать kubelet, но не смог из-за сообщения об ошибке, как упоминалось

[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>

Ключевая информация, которую я вижу из журнала, - это CgroupDriver по-прежнему cgroupfs, я думаю, что причина вызвала проблему несоответствия cgroup, но понятия не имею, как настроить это значение по умолчанию? Вы можете помочь прояснить это, спасибо!

@wshandao Пожалуйста, прекратите использовать kubelet logs , это неправильный способ просмотра журнала.

Правильный способ просмотра журнала - journalctl -f -u kubelet .

Спасибо @dixudx , моя ошибка, и на самом деле это не проблема, чтобы задержать мою установку

Я повторяю запросы на закрытие этого.
в документации уже говорится, что пользователям необходимо проверить соответствующий драйвер cgroups.

это не зависит от kubeadm и является скорее проблемой kubelet vs docker.

похожие отчеты:
https://github.com/kubernetes/kubernetes/issues/59794
https://github.com/openshift/origin/issues/18776
https://github.com/kubernetes/kubernetes/issues/43805

@timstclair

FWIW это значение по умолчанию в RPM, но не в .debs. Есть ли какой-либо текущий дистрибутив в основной поддержке, который сейчас не используется по умолчанию для systemd?

Я тестировал это на 3 разных голых Ubuntu 16.04.2, 16.04.0, 17.04, и оказалось, что драйвер докера - cgroupfs , что соответствует значению аргумента по умолчанию для кублета.

в отличие от пользовательского отчета в исходном сообщении, где докер использует systemd на 16.04.3 , так что это может быть конфигурация докера, изменяющаяся между версиями докера. трудно сказать.

учитывая мои тесты, я не вижу необходимости добавлять Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd" в debs, потому что это было бы неправильно, по крайней мере, для этих версий Ubuntu.

то, что кублет, вероятно, должен делать для дружественного UX, - это всегда автоматически соответствовать драйверу докера.

@ neolit123 согласился.

Однако я действительно думаю, что мы должны открыть JIC для устранения неполадок с документом.
Закрываю это, и я начинаю свою документацию.

У меня была такая же проблема на Ubuntu 16.04, версия Kube v1.10.4. Докер версии 1.13.1
Докер начинался с native.cgroupdriver = systemd. Этот конфиг был установлен мной в /etc/docker/daemon.json

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

Я изменил конфигурацию в /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Добавлена ​​новая строка: Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd"
И добавляем параметр $KUBELET_CGROUP_ARGS в ExecStart

Затем выполнил перезагрузку демона systemctl и перезапуск службы kubelet.
Кубелет запустился правильно.

@dragosrosculete

мы улучшаем нашу документацию по устранению неполадок, но также в 1.11 и более поздних версиях драйвер cgroup для docker должен автоматически согласовываться с kubeadm.

Я действительно думаю, что это ошибка. Я проверил версию докера и файл kubeadm, конечно, сценарий kubeadm тоже выполняет эту проверку. однако я получаю сообщение об ошибке несоответствия. Если кто-то когда-либо внимательно прочитал, вы можете увидеть, что некоторые из вышеперечисленных имеют проблему ПОСЛЕ правильной установки параметра.

это все еще происходит, ничего не работает!