RAPPORT D'ERREUR
version kubeadm
version kubelet
kubernetes- cni: 0.6.0-00 amd64
version docker-ce
version du système
Machine physique
installez le cluster kubernetes sur ubuntu 16.04. Lors de l'exécution de kubeadm init, il y a une erreur:
[init] Cela peut prendre une minute ou plus si les images du plan de contrôle doivent être extraites.
[kubelet-check] Il semble que le kubelet ne fonctionne pas ou ne fonctionne pas.
[kubelet-check] Il semble que le kubelet ne fonctionne pas ou ne fonctionne pas.
[kubelet-check] Il semble que le kubelet ne fonctionne pas ou ne fonctionne pas.
[kubelet-check] Il semble que le kubelet ne fonctionne pas ou ne fonctionne pas.
[kubelet-check] Il semble que le kubelet ne fonctionne pas ou ne fonctionne pas.
[kubelet-check] Il semble que le kubelet ne fonctionne pas ou ne fonctionne pas.
[kubelet-check] Il semble que le kubelet ne fonctionne pas ou ne fonctionne pas.
Après avoir vu le syslog / var / log / syslog, j'ai eu des erreurs comme suit:
4 janvier 16:20:58 master03 kubelet [10360]: W0104 16: 20: 58.268285 10360 cni.go: 171] Impossible de mettre à jour la configuration cni: aucun réseau trouvé dans /etc/cni/net.d
4 janvier 16:20:58 master03 kubelet [10360]: W0104 16: 20: 58.269487 10360 cni.go: 171] Impossible de mettre à jour la configuration cni: aucun réseau trouvé dans /etc/cni/net.d
4 janvier 16:20:58 master03 kubelet [10360]: I0104 16: 20: 58.269527 10360 docker_service.go: 232] Réseau Docker cri géré par cni
Jan 04 16:20:58 master03 kubelet [10360]: I0104 16: 20: 58.274386 10360 docker_service.go: 237] Docker Info: & {ID: 3 XXZ: XEDW : ZDQS: A2MI : 5 AEN: CFEP : 44AQ: YDS4 : CRME: UBRS : 46LI: MXNS C ontainers: 0 Containe rs Exécution: 0 Cont
4 janvier 16:20:58 master03 kubelet [10360]: erreur: échec de l'exécution de Kubelet: échec de la création de kubelet: mauvaise configuration: pilote de groupe de kubelet: "cgroupfs" est différent du pilote de cgroup docker: "systemd"
Et j'ai vérifié le pilote cgroup docker: info docker | grep -i cgroup
Pilote Cgroup: systemd
version kubeadm (utilisez kubeadm version
):
Environnement :
kubectl version
):uname -a
):erreur: échec de l'exécution de Kubelet: échec de la création de kubelet: mauvaise configuration: pilote de groupe de contrôle de kubelet: "cgroupfs" est différent du pilote de groupe de contrôle de docker: "systemd"
info docker | grep -i cgroup
Pilote Cgroup: systemd
Je peux le confirmer.
@ lavender2020 Vous devez ajouter manuellement --cgroup-driver=systemd
aux arguments kubelet
démarrage
Le pilote par défaut utilisé par kubelet
pour manipuler les groupes de contrôle sur l'hôte est cgroupfs
.
La plupart des gens se tournent vers kubeadm
principalement pour mettre en place un cluster très rapidement. C'est simple et pratique。
@luxas Devons-nous ajouter un contrôle préalable sur la cohérence du pilote de groupe de contrôle entre docker
et kubelet
pour donner des avertissements plus explicites? Ou ajouter un autre drop-in pour kubelet.service
? Ou simplement modifier /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
en place?
Mais si tel est le cas, nous devrons peut-être acquérir le privilège root pour prendre en charge ces changements.
J'ai rencontré le même problème avec kubeadm v1.9.2
mais je peux voir que kubelet est configuré pour utiliser le pilote de cgroup systemd.
kubelet utilise --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
info docker |
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
journaux 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"
Informations sur la version:
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 Avez-vous rechargé le fichier d'unité kubelet.service
?
Exécutez systemctl daemon-reload
. Et puis systemctl restart kubelet
.
Ce problème n'a pas été résolu sur la version 1.9.3
Informations sur la version:
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 Quel est votre pilote de groupe de contrôle?
$ docker info | grep -i cgroup
Avoir le même problème.
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"
Y a-t-il un autre endroit où Kubelet obtient la directive du pilote cgroupfs?
@ mas-dse-greina Veuillez vous référer à la solution dans mon commentaire .
@dixudx Même après avoir --cgroup-driver=systemd
à /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
le problème persiste.
Ceci est le dernier fichier,
[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: Il a été corrigé. Après avoir redémarré le démon et kubelet, j'ai utilisé kubeadm init --pod-network-cidr = 10.244.0.0 / 16
Oui. Je trouve la même chose. Ajout du --cgroup-driver = systemd
ne semble pas avoir d'effet. J'ai redémarré le service et même
redémarré l'ordinateur.
Il semble que le comportement ne concerne que cette seule machine. J'ai été
réussie avec 4 autres machines, mais celle-ci ne semble tout simplement pas vouloir
rejoindre le cluster.
-Tony
Le jeu.1 mars 2018 à 11:44, srinivas491-oneconvergence <
[email protected]> a écrit:
@dixudx https://github.com/dixudx Même après avoir ajouté le
--cgroup-driver = systemd vers / etc / systemd / system / kubelet.
service.d / 10-kubeadm.conf le problème persiste.-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/kubernetes/kubeadm/issues/639#issuecomment-369707723 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AVReEuQHJR80-8J4VLvACnGt1lTjEbYrks5taE-BgaJpZM4RSs0P
.
Après avoir modifié le fichier d'unité, vous devez utiliser systemdctl daemon-reload
pour qu'une modification prenne effet.
FWIW ceci est défini par défaut dans les RPM mais pas dans .debs. Existe-t-il une distribution actuelle dans le support principal qui ne soit pas par défaut systemd maintenant?
/ assign @detiber
J'ai rencontré le même problème avec kubeadm v1.9.3 et v1.9.4.
Démarrez kubelet avec --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
Service de rechargement
$ systemctl daemon-reload
$ systemctl restart kubelet
Vérifier les informations du docker
$ 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
journaux 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"
Informations sur la version
$ 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 Pouvez-vous regarder la ligne de commande de l'exécution de kubelet pour voir si le pilote de groupe de contrôle y est spécifié?
Quelque chose comme ps aux |grep kubelet
ou cat /proc/<kubelet pid>/cmdline
devrait vous aider à voir cela.
@ bart0sh C'est ça:
$ 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 Merci! Je pourrais reproduire cela aussi. Semble être un bug. Regarde ça.
Comme solution de contournement temporaire, vous pouvez basculer docker et kubelet vers le pilote cgroupfs. Cela devrait marcher.
@ bart0sh Très bien. Merci beaucoup. J'essaierai ça.
Pareil ici.
[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 ~] # version kubeadm
kubeadm version: & version.Info {Major: "1", Minor: "9", GitVersion: "v1.9.4", GitCommit: "bee2d1505c4fe820744d26d41ecd3fdd4a3d6546", GitTreeState: "clean", BuildDate: "2018-03-12T16 35Z ", GoVersion:" go1.9.3 ", Compilateur:" gc ", Plate-forme:" 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
La v1.9.5 a corrigé ce problème, génial! @ bart0sh
@FrostyLeaf Je suis toujours capable de le reproduire avec 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 groupe de contrôle
Pilote Cgroup: systemd
$ ps aux | grep cgroup-driver
racine 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-certificates = true --cert-dir = / var / lib / kubelet / pki
I0321 13: 50: 29.901008 30817 container_manager_linux.go: 247] Création d'un objet Container Manager basé sur Node Config: {RuntimeCgroupsName: SystemCgroupsName: KubeletCgroupsName: Contient erRuntime: docker Cgro upsPerQOS: true CgroupRoot: / Cgr oupDriver: cgroupRoot / kubelet ProtectKerne lDefaults: false NodeAllocatableConfig: {KubeReservedCgroupName: SystemReservedCgroupName: EnforceNodeAl locatable : map [pods: {}] Kub eReserved: map [] Syste mReserved: map [] HardEvictionThresholdseulement: [{ Signalator : Value Available Operator] Quantité: 100Mi P ercentage: 0 } Gr acePeriod: 0s MinReclaim:
erreur: échec de l'exécution de Kubelet: échec de la création de kubelet: mauvaise configuration: pilote de groupe de contrôle de kubelet :
Utilisez-vous toujours le pilote de groupe de contrôle systemd?
Je propose de clore ce numéro
J'ai observé 2 raisons qui causent la plupart des rapports ici:
oubliant d'exécuter 'systemctl daemon-reload' après avoir édité les drop-ins de systemd. Eventhough -cgroup-driver = systemd a été ajouté à /etc/systemd/system/kubelet.service.d/10-kubeadm.conf il n'a fait aucun effet et le pilote par défaut (ou précédemment spécifié avec --cgroup-driver) était utilisé.
exécution de la commande 'kubelet logs' pour voir les journaux de kubelet. La sous-commande 'logs' n'existe pas dans kubelet, donc 'kubelet logs' et 'kubelet' sont les mêmes commandes. 'kubelet logs' exécute kubelet avec le pilote de groupe de contrôle par défaut 'cgroupfs' et kubelet se plaint de l'incohérence entre les pilotes kubelet et docker. «journalctl -ux kubelet» doit être utilisé pour voir les journaux.
J'ai testé l'option --cgroup-driver = systemd avec kubelet 1.8.0, 1.9.0, 1.9.3 et 1.9.5. Il n'y avait aucun message d'erreur "cgroupfs est différent du pilote de cgroup docker: systemd" dans les journaux.
@timothysc Il n'y a aucune objection concernant mon dernier commentaire. Pouvez-vous fermer ce problème, s'il vous plaît? Ce n'est pas un bug, car il est causé par un manque de connaissances sur kubelet et / ou systemd.
Deux choses qui pourraient être sensées de mon point de vue sont:
Nous voudrons peut-être envisager de créer des problèmes distincts pour ceux-ci.
Quoi qu'il en soit, ce problème peut être résolu.
Les choses me vont bien grâce à la
D'accord avec @ bart0sh à propos de l'initialisation de la vérification de la cohérence du pilote de groupe de contrôle entre kubelet et docker.
Peut-être que les journaux de kublet {devraient pointer vers le journal journactl -u kubelet.service
Juste mes 2cts.
Salut, j'ai le même problème.
Centos 7
La version de kubeadm est: 1.9.6
la version de docker est: 1.13.1 Version de l'API: 1.26
quand j'ai couru: docker info | grep -i cgroup
,
J'ai ceci:
WARNING: You're not using the default seccomp profile
Cgroup Driver: systemd
quand je lance cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
,
Je peux voir les paramètres Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd"
en place.
J'ai exécuté systemctl daemon-reload * et * systemctl restart kubelet , mais il est toujours affiché
mauvaise configuration: pilote cgroup kubelet: "cgroupfs" est différent du pilote cgroup docker: "systemd"
Une autre chose étrange est: quand j'ai couru sed -i "s/cgroup-driver=systemd/cgroup-driver=cgroupfs/g" /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
J'ai vu que le --cgroup-drive est changé en cgroupfs .
Mais ensuite, le même message d'erreur a été affiché lorsque j'ai réexécuté kubelet status
.
mauvaise configuration: pilote cgroup kubelet: "cgroupfs" est différent du pilote cgroup docker: "systemd"
Je n'arrive pas à comprendre le problème.
J'essaierai avec les versions mentionnées ci-dessus. Quelqu'un sait-il comment installer une ancienne version de kubernetes? Merci.
@moqichenle C'est étrange. Cela devrait marcher. Pouvez-vous afficher la sortie des commandes suivantes?
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"
Voici ce que je vois sur mon système:
# 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 Salut, merci pour l'aide.
Voici ce que j'ai (avant de démarrer 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
Après avoir tapé la commande kubeadm init,
voici ce que j'ai:
[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
Mais alors kubeadm init échouera car soit kubelet n'est pas sain, soit kubelet n'est pas en cours d'exécution.
@moqichenle avez-vous exécuté systemctl daemon-reload
et systemctl restart kubelet
avant d' exécuter kubeadm init
?
Pouvez-vous exécuter journalctl -u kubelet.service
après kubeadm init
et afficher sa sortie ici?
Oui, j'ai exécuté les deux commandes avant l'initialisation.
Chose étrange: je n'ai vu aucune sortie lorsque j'ai exécuté journalctl -u kubelet.service | grep "is different from docker cgroup driver"
.
Je n'ai vu que l'erreur lorsque j'ai exécuté kubelet status
.
La commande @moqichenle kubelet status
n'existe pas. Cela signifie que vous exécutez kubelet avec les paramètres par défaut (et le pilote de groupe de contrôle par défaut). C'est pourquoi vous obtenez l'erreur. Voir mes messages concernant kubelet logs
pour plus de détails.
Voyez-vous quelque chose de suspect (erreurs, avertissements) dans la sortie de journalctl -u kubelet.service
?
Ah, je vois. Merci. :)
hmm .. il y a des erreurs ci-dessous:
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
Lorsque j'ai exécuté kubeadm init, si les paramètres du lecteur de groupe de contrôle sont différents:
Ça montre:
`[etcd] Écrit le manifeste du pod statique pour une instance locale etcd dans" /etc/kubernetes/manifests/etcd.yaml "
[init] Attente que le kubelet démarre le plan de contrôle en tant que pods statiques à partir du répertoire "/ etc / kubernetes / manifestests".
[init] Cela peut prendre une minute ou plus si les images du plan de contrôle doivent être extraites.
[kubelet-check] Il semble que le kubelet ne fonctionne pas ou ne fonctionne pas.
Lorsque les paramètres du lecteur cgroup sont identiques,
il se bloque juste à l'étape de tirer le panneau de commande et se retrouve avec kubelet malsain ou ne fonctionne pas.
@moqichenle, cela ressemble à un problème de docker pour moi. Ce n'est pas lié à celui-ci, je crois.
Vous pouvez rechercher «délai de contexte dépassé» pour plus d'informations.
@ bart0sh Oui, je ne pense plus que ce soit lié à ce problème. ça ira. Merci beaucoup: D
ce PR devrait aider à réduire la confusion causée par l'exécution de 'kubelet logs', 'kubelet status' et d'autres commandes kubelet non existantes: # 61833
Cela oblige kubelet à produire une erreur et à quitter s'il est exécuté avec une ligne de commande incorrecte.
S'il-vous-plaît évaluez.
Salut, je peux reproduire ce problème sur 1.10, juste pour vérifier s'il s'agit d'un bogue et sera corrigé dans la v1.11?
est-ce un bogue et sera corrigé dans la v1.11
IMO, il s'agit d'une incompatibilité de configuration entre docker
et kubelet
, plutôt qu'un bogue.
Avant d'exécuter kubeadm init
, une vérification des prérequis sur le pilote de groupe de contrôle doit être effectuée.
@dixudx J'essaie d'installer le k8 suivi du guide d'installation du site Web https://kubernetes.io/docs/setup/independent/install-kubeadm/ , et les étapes ont été retenues par ce problème, voici les détails de mon environnement ;
OS:
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
Le groupe de contrôle entre docker et 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"
C'est le même groupe de contrôle que systemd, donc pas besoin d'ajuster manuellement le groupe de contrôle de kubelet. Et je commence à exécuter kubelet mais j'ai échoué en raison du message d'erreur mentionné
[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>
L'information clé que je vois dans le journal est que CgroupDriver est toujours cgroupfs, je suppose que c'est la raison pour laquelle un problème de non-correspondance de groupe de contrôle a été causé, mais vous ne savez pas comment ajuster cette valeur par défaut? pouvez-vous aider à clarifier pour cela, merci!
@wshandao Veuillez arrêter d'utiliser kubelet logs
, ce qui n'est pas la bonne façon de voir le journal.
La façon correcte de voir le journal est journalctl -f -u kubelet
.
Merci @dixudx , mon erreur et ce n'est pas vraiment un problème pour tenir mon installation
Je seconde les demandes de fermeture de celui-ci.
la documentation indique déjà que les utilisateurs doivent vérifier un pilote de groupe de contrôle correspondant.
cela est indépendant de kubeadm et est plus un problème de kubelet vs docker.
rapports similaires:
https://github.com/kubernetes/kubernetes/issues/59794
https://github.com/openshift/origin/issues/18776
https://github.com/kubernetes/kubernetes/issues/43805
@timstclair
FWIW ceci est défini par défaut dans les RPM mais pas dans .debs. Existe-t-il une distribution actuelle dans le support principal qui ne soit pas par défaut systemd maintenant?
J'ai testé ceci sur 3 différents Ubuntu bare-bone 16.04.2, 16.04.0, 17.04 et il semble que le pilote docker soit cgroupfs
, ce qui correspond à la valeur d'argument par défaut du kublet.
contrairement au rapport utilisateur dans le post original où docker utilise systemd
sur 16.04.3
, donc il se peut que la configuration du docker change entre les versions de docker. dur à dire.
étant donné mes tests, je ne vois pas la nécessité d'ajouter Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd"
dans les debs car ce serait faux pour ces versions d'Ubuntu au moins.
ce que le kublet devrait probablement faire pour une UX conviviale est de toujours correspondre automatiquement au pilote du docker.
@ neolit123 est d' accord.
Cependant, je pense que nous devrions ouvrir un dossier de dépannage JIC.
En fermant celui-ci et je commencerai mes documents.
J'ai eu ce même problème sur Ubuntu 16.04, version Kube v1.10.4. Docker version 1.13.1
Docker commençait par native.cgroupdriver = systemd. Cette configuration a été définie par moi dans /etc/docker/daemon.json
{
"exec-opts": ["native.cgroupdriver=systemd"]
}
J'ai modifié la configuration dans /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Ajout d'une nouvelle ligne: Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd"
Et ajoutez le paramètre $KUBELET_CGROUP_ARGS
dans ExecStart
Puis a fait un redémarrage du démon systemctl et du service kubelet.
Kubelet a démarré correctement.
@dragosrosculete
nous améliorons nos documents de dépannage, mais aussi dans la version 1.11 et les versions ultérieures, le pilote de groupe de contrôle pour docker devrait être automatiquement mis en correspondance par kubeadm.
Je pense que c'est un bug. J'ai vérifié la version de docker et le fichier kubeadm, bien sûr, le script kubeadm fait également cette vérification. cependant j'obtiens le msg d'erreur de discordance. Si quelqu'un a déjà lu attentivement, vous pouvez voir que certains des éléments ci-dessus ont le problème APRÈS avoir correctement défini le paramètre.
cela se passe toujours, rien n'a fonctionné!
Commentaire le plus utile
J'ai rencontré le même problème avec kubeadm
v1.9.2
mais je peux voir que kubelet est configuré pour utiliser le pilote de cgroup systemd.kubelet utilise --cgroup-driver = systemd
info docker |
journaux de kubelet
Informations sur la version: