INFORME DE ERROR
Versión de kubeadm
versión de kubelet
kubernetes- cni: 0.6.0-00 amd64
versión de docker-ce
versión del sistema
Maquina fisica
instale el clúster de kubernetes en ubuntu 16.04. Al ejecutar kubeadm init, hay un error:
[init] Esto puede tardar un minuto o más si es necesario extraer las imágenes del plano de control.
[kubelet-check] Parece que el kubelet no funciona o no funciona correctamente.
[kubelet-check] Parece que el kubelet no funciona o no funciona correctamente.
[kubelet-check] Parece que el kubelet no funciona o no funciona correctamente.
[kubelet-check] Parece que el kubelet no funciona o no funciona correctamente.
[kubelet-check] Parece que el kubelet no funciona o no funciona correctamente.
[kubelet-check] Parece que el kubelet no funciona o no funciona correctamente.
[kubelet-check] Parece que el kubelet no funciona o no funciona correctamente.
Después de ver el syslog / var / log / syslog, obtuve los siguientes errores:
04 de enero 16:20:58 master03 kubelet [10360]: W0104 16: 20: 58.268285 10360 cni.go: 171] No se puede actualizar la configuración de cni: no se encontraron redes en /etc/cni/net.d
04 de enero 16:20:58 master03 kubelet [10360]: W0104 16: 20: 58.269487 10360 cni.go: 171] No se puede actualizar la configuración de cni: no se encontraron redes en /etc/cni/net.d
04 de enero 16:20:58 master03 kubelet [10360]: I0104 16: 20: 58.269527 10360 docker_service.go: 232] Red Docker cri administrada por cni
04 de enero 16:20:58 master03 kubelet [10360]: I0104 16: 20: 58.274386 10360 docker_service.go: 237] Información de Docker: & {ID: 3 XXZ: XEDW : ZDQS: A2MI : 5 AEN: CFEP : 44AQ: YDS4 : CRME: UBRS : 46LI: MXNS Contenedores: 0 Contenedores en ejecución: 0 Cont
04 de enero 16:20:58 master03 kubelet [10360]: error: no se pudo ejecutar Kubelet: no se pudo crear kubelet: configuración incorrecta: controlador cgroup de kubelet: "cgroupfs" es diferente del controlador cgroup de docker: "systemd"
Y verifiqué el controlador cgroup de la ventana acoplable: información de la ventana acoplable | grep -i cgroup
Controlador de Cgroup: systemd
versión kubeadm (use kubeadm version
):
Medio ambiente :
kubectl version
):uname -a
):error: no se pudo ejecutar Kubelet: no se pudo crear kubelet: mala configuración: kubelet controlador cgroup: "cgroupfs" es diferente del controlador docker cgroup: "systemd"
información de docker | grep -i cgroup
Controlador de Cgroup: systemd
Puedo confirmar esto.
@ lavender2020 Debe agregar manualmente --cgroup-driver=systemd
a kubelet
argumentos de inicio y volver a cargar el archivo de unidad de kubelet para reiniciar el servicio.
El controlador predeterminado que usa kubelet
para manipular cgroups en el host es cgroupfs
.
La mayoría de las personas recurren a kubeadm
principalmente para configurar un clúster muy rápidamente. Es simple y práctico。
@luxas ¿Debemos agregar una verificación previa de la consistencia del controlador cgroup entre docker
y kubelet
para dar advertencias más explícitas? ¿O agregar otro drop-in por kubelet.service
? ¿O simplemente modificar /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
en su lugar?
Pero si es así, es posible que necesitemos adquirir privilegios de root para realizar estos cambios.
Encontré este mismo problema con kubeadm v1.9.2
pero puedo ver que kubelet está configurado para usar el controlador systemd cgroup.
kubelet está usando --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
información de la ventana acoplable |
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
registros de kubelet
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"
Información de la versión:
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 ¿Ha recargado el archivo de unidad kubelet.service
?
Ejecute systemctl daemon-reload
. Y luego systemctl restart kubelet
.
Este problema no se solucionó en 1.9.3
Información de la versión:
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 ¿Cuál es su controlador de cgroup?
$ docker info | grep -i cgroup
Tener el mismo problema.
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"
¿Hay algún otro lugar donde Kubelet obtenga la directiva del controlador cgroupfs?
@ mas-dse-greina Consulte la solución en mi comentario .
@dixudx Incluso después de --cgroup-driver=systemd
a /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
el problema persiste.
Este es el archivo más reciente,
[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
PD: Se arregló. Después de reiniciar el demonio y kubelet, usé kubeadm init --pod-network-cidr = 10.244.0.0 / 16
Si. Encuentro lo mismo. Agregar el --cgroup-driver = systemd
no parece tener ningún efecto. He reiniciado el servicio e incluso
reinicia la computadora.
Parece que el comportamiento es solo en esta máquina. he estado
exitoso con otras 4 máquinas, pero esta simplemente no parece querer
unirse al clúster.
-Tony
El jueves 1 de marzo de 2018 a las 11:44 a. M., Srinivas491-oneconvergence <
[email protected]> escribió:
@dixudx https://github.com/dixudx Incluso después de agregar el
--cgroup-driver = systemd a / etc / systemd / system / kubelet.
service.d / 10-kubeadm.conf el problema aún persiste.-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/kubeadm/issues/639#issuecomment-369707723 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AVReEuQHJR80-8J4VLvACnGt1lTjEbYrks5taE-BgaJpZM4RSs0P
.
Después de cambiar el archivo de unidad, necesita systemdctl daemon-reload
para que el cambio surta efecto.
FWIW esto está predeterminado en los RPM pero no en .debs. ¿Existe alguna distribución actual en el soporte principal que no esté predeterminada en systemd ahora?
/ asignar @detiber
Encontré este mismo problema con kubeadm v1.9.3 y v1.9.4.
Inicie kubelet con --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
Servicio de recarga
$ systemctl daemon-reload
$ systemctl restart kubelet
Verificar la información de la ventana acoplable
$ 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
registros de kubelet
$ kubelet logs
error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "cgroupfs" is different from docker cgroup driver: "systemd"
Información de la versión
$ 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 ¿Puede mirar la línea de comandos de ejecutar kubelet para ver si el controlador cgroup está especificado allí?
Algo como ps aux |grep kubelet
o cat /proc/<kubelet pid>/cmdline
debería ayudarlo a ver eso.
@ bart0sh Esto 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 ¡ Gracias! Podría reproducir esto también. Parece ser un error. Mirándolo.
Como solución temporal, puede cambiar la ventana acoplable y kubelet al controlador cgroupfs. Deberia de funcionar.
@ bart0sh Bien. Muchas gracias. Lo intentaré.
Aquí igual.
[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 ~] # versión kubeadm
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 ", Compilador:" gc ", Plataforma:" 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
[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"
[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"**
[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 solucionó este problema, ¡increíble! @ bart0sh
@FrostyLeaf todavía puedo reproducirlo con 1.9.5:
$ 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
Controlador de Cgroup: systemd
$ ps aux | controlador grep cgroup
raíz 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 / 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 = --authorization-mode = cluster.local web hook --client-ca-file = / etc / kubernetes / pki / ca.crt --cadvisor-port = 0 - -cgroup-driver = systemd --rotate-certificate = true --cert-dir = / var / lib / kubelet / pki
I0321 13: 50: 29.901008 30817 container_manager_linux.go: 247] Creando un objeto Container Manager basado en Node Config: {RuntimeCgroupsName: SystemCgroupsName: KubeletCgroupsName: Contiene erRuntime: docker Cgro upsPerQOS: true CgroupRoot: / Cgr oupfsDiriver: cgroupRoot : / Cgr lDefaults: falsa NodeAllocatableConfig: {KubeReservedCgroupName: SystemReservedCgroupName: EnforceNodeAl localizables: mapa [vainas: {}] Kub eReserved: mapa [] Syste mReserved: mapa [] HardEvictionThresholds: [{ señal: memory.available operador: lessThan Valor: { Cantidad: 100Mi Porcentaje : 0 } Gr acePeriod: 0s MinReclaim:
error: no se pudo ejecutar Kubelet: no se pudo crear kubelet: mala configuración: kubelet controlador cgroup: "cgroupfs" es diferente del controlador docker cgroup: "systemd"
¿Sigues usando el controlador systemd cgroup?
Propongo cerrar este tema
He observado 2 razones que causan la mayoría de los informes aquí:
olvidando ejecutar 'systemctl daemon-reload' después de editar los drop-ins de systemd. Aunque se agregó -cgroup-driver = systemd a /etc/systemd/system/kubelet.service.d/10-kubeadm.conf, no tuvo ningún efecto y el controlador predeterminado (o especificado previamente con --cgroup-driver) fue usó.
ejecutando el comando 'kubelet logs' para ver los registros de kubelet. El subcomando 'logs' no existe en kubelet, por lo que 'kubelet logs' y 'kubelet' son los mismos comandos. 'kubelet logs' ejecuta kubelet con el controlador cgroup predeterminado 'cgroupfs' y kubelet se queja de la inconsistencia entre los controladores kubelet y docker. Se debe usar 'journalctl -ux kubelet' para ver los registros.
Probé la opción --cgroup-driver = systemd con kubelet 1.8.0, 1.9.0, 1.9.3 y 1.9.5. No había mensajes de error "cgroupfs es diferente de la ventana acoplable cgroup driver: systemd" en los registros.
@timothysc No hay objeciones con respecto a mi último comentario. ¿Puede cerrar este problema, por favor? No es un error, ya que es causado por la falta de conocimiento sobre kubelet y / o systemd.
2 cosas que podrían tener sentido hacer desde mi punto de vista son:
Es posible que queramos considerar la posibilidad de crear problemas separados para esos.
De todos modos, este problema se puede cerrar.
Las cosas se ven bien para mí gracias a la v1.9.5.
De acuerdo con @ bart0sh sobre el init que verifica la coherencia del controlador cgroup entre kubelet y docker.
Quizás los `registros de kublet {deberían apuntar al journalnactl -u kubelet.service
Solo mis 2cts.
Hola, tengo el mismo problema.
Centos 7
La versión de kubeadm es: 1.9.6
La versión de Docker es: 1.13.1 Versión de API: 1.26
cuando ejecuté: docker info | grep -i cgroup
,
Tengo esto:
WARNING: You're not using the default seccomp profile
Cgroup Driver: systemd
cuando ejecuto cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
,
Puedo ver la configuración Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd"
en su lugar.
Ejecuté systemctl daemon-reload * y * systemctl restart kubelet , pero todavía se muestra
Configuración incorrecta: controlador kubelet cgroup: "cgroupfs" es diferente del controlador docker cgroup: "systemd"
Otra cosa extraña es: cuando ejecuté sed -i "s/cgroup-driver=systemd/cgroup-driver=cgroupfs/g" /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Vi que --cgroup-drive se cambia a cgroupfs .
Pero luego se mostró exactamente el mismo mensaje de error cuando ejecuté kubelet status
nuevamente.
configuración incorrecta: controlador kubelet cgroup: "cgroupfs" es diferente del controlador docker cgroup: "systemd"
No puedo resolver el problema.
Lo intentaré con las versiones mencionadas anteriormente. ¿Alguien sabe cómo instalar una versión anterior de kubernetes? Gracias.
@moqichenle Eso es extraño. Deberia de funcionar. ¿Puede mostrar el resultado de los siguientes comandos?
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"
Esto es lo que veo en mi sistema:
# 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 Hola, gracias por la ayuda.
Esto es lo que tengo (antes de iniciar 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
Después de escribir el comando kubeadm init,
Esto es lo que tengo:
[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
Pero entonces kubeadm init fallará debido a que kubelet no está en buen estado o kubelet no se está ejecutando.
@moqichenle , ¿ejecutó systemctl daemon-reload
y systemctl restart kubelet
antes de ejecutar kubeadm init
?
¿Puede ejecutar journalctl -u kubelet.service
después de kubeadm init
y mostrar su salida aquí?
Sí, ejecuté los dos comandos antes de init.
Cosa extraña: no vi ningún resultado cuando ejecuté journalctl -u kubelet.service | grep "is different from docker cgroup driver"
.
Solo vi que el error cuando ejecuté kubelet status
.
El comando @moqichenle kubelet status
no existe. Eso significa que ejecuta kubelet con los parámetros predeterminados (y el controlador cgroup predeterminado). Por eso aparece el error. Vea mis mensajes sobre kubelet logs
para más detalles.
¿Ve algo sospechoso (errores, advertencias) en la salida de journalctl -u kubelet.service
?
Ah, ya veo. Gracias. :)
hmm ... hay errores que se muestran a continuación:
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
Cuando ejecuté kubeadm init, si la configuración de la unidad cgroup es diferente:
Muestra:
`[etcd] Escribió el manifiesto de Static Pod para una instancia local de etcd en" /etc/kubernetes/manifests/etcd.yaml "
[init] Esperando que kubelet inicie el plano de control como Static Pods desde el directorio "/ etc / kubernetes / manifests".
[init] Esto puede tardar un minuto o más si es necesario extraer las imágenes del plano de control.
[kubelet-check] Parece que el kubelet no funciona o no funciona correctamente.
Cuando la configuración de la unidad cgroup es la misma,
simplemente se cuelga en el paso de tirar del panel de control y termina con kubelet insalubre o no funcionando.
@moqichenle me parece un problema de
Puede buscar "fecha límite de contexto excedida" para obtener más información.
@ bart0sh Sí, ya no creo que esté relacionado con este problema. servirá. Muchas gracias: D
este PR debería ayudar a disminuir la confusión causada por la ejecución de 'registros de kubelet', 'estado de kubelet' y otros comandos de kubelet no existentes: # 61833
Hace que kubelet produzca un error y salga si se ejecuta con una línea de comando incorrecta.
Por favor revise.
Hola, puedo reproducir este problema en 1.10, solo para verificar si se trata de un error y se solucionará en v1.11.
¿Es esto un error y se solucionará en v1.11?
En mi opinión, esta es una falta de coincidencia de configuración entre docker
y kubelet
, en lugar de un error.
Antes de ejecutar kubeadm init
, se debe realizar una verificación de requisitos previos en el controlador cgroup .
@dixudx Estoy intentando instalar el k8s seguido de la guía de instalación del sitio web https://kubernetes.io/docs/setup/independent/install-kubeadm/ , y los pasos se mantuvieron para este problema, a continuación se muestran los detalles de mi entorno ;
SO:
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
El cgroup entre docker y 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 el mismo cgroup que systemd, por lo que no es necesario ajustar cgroup de kubelet manualmente. Y empiezo a ejecutar kubelet pero fallé debido al mensaje de error mencionado
[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: &{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>
La información clave que veo en el registro es que CgroupDriver sigue siendo cgroupfs, supongo que esa es la razón por la que cgroup no coincide, pero no tengo idea de cómo ajustar este valor predeterminado. ¿Puedes ayudarme a aclararlo? ¡Gracias!
@wshandao Por favor, deje de usar kubelet logs
, que no es la forma correcta de ver el registro.
La forma correcta de ver el registro es journalctl -f -u kubelet
.
Gracias @dixudx , mi error y esto no es un problema para mantener mi instalación
Secundo las solicitudes para cerrar este.
la documentación ya cubre que los usuarios necesitan verificar un controlador cgroups coincidente.
esto es independiente de kubeadm y es más un problema de kubelet vs docker.
informes similares:
https://github.com/kubernetes/kubernetes/issues/59794
https://github.com/openshift/origin/issues/18776
https://github.com/kubernetes/kubernetes/issues/43805
@timstclair
FWIW esto está predeterminado en los RPM pero no en .debs. ¿Existe alguna distribución actual en el soporte principal que no esté predeterminada en systemd ahora?
He probado esto en 3 Ubuntu 16.04.2, 16.04.0, 17.04 bare-bone diferentes y parece que el controlador de la ventana acoplable es cgroupfs
, que coincide con el valor del argumento predeterminado del kublet.
a diferencia del informe del usuario en la publicación original donde Docker usa systemd
en 16.04.3
, por lo que podría ser la configuración de Docker cambiando entre versiones de Docker. difícil de decir.
dadas mis pruebas, no veo la necesidad de agregar Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd"
en las debs porque eso sería incorrecto para estas versiones de Ubuntu al menos.
Lo que probablemente debería hacer el kublet para una UX amigable es hacer coincidir siempre el controlador de la ventana acoplable automáticamente.
@ neolit123 estuvo de acuerdo.
Sin embargo, creo que deberíamos abrir un documento de resolución de problemas JIC.
Cerrando este y comenzaré con mis documentos.
Tuve este mismo problema en Ubuntu 16.04, versión de Kube v1.10.4. Docker versión 1.13.1
Docker estaba comenzando con native.cgroupdriver = systemd. Esta configuración fue establecida por mí en /etc/docker/daemon.json
{
"exec-opts": ["native.cgroupdriver=systemd"]
}
He modificado la configuración en /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Se agregó una nueva línea: Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd"
Y agregue el parámetro $KUBELET_CGROUP_ARGS
en ExecStart
Luego, se reinició systemctl daemon-reload y service kubelet.
Kubelet comenzó correctamente.
@dragosrosculete
estamos mejorando nuestros documentos de resolución de problemas, pero también en la versión 1.11 y posteriores, kubeadm debería hacer coincidir automáticamente el controlador cgroup para la ventana acoplable.
Creo que es un error. Verifiqué la versión de la ventana acoplable y el archivo kubeadm, por supuesto, el script kubeadm también lo hace. sin embargo, aparece el mensaje err de discordancia. Si alguien alguna vez lee con atención, puede ver que algo de lo anterior tiene el problema DESPUÉS de configurar correctamente el parámetro.
esto todavía está sucediendo, ¡nada funcionó!
Comentario más útil
Encontré este mismo problema con kubeadm
v1.9.2
pero puedo ver que kubelet está configurado para usar el controlador systemd cgroup.kubelet está usando --cgroup-driver = systemd
información de la ventana acoplable |
registros de kubelet
Información de la versión: