RELATÓRIO DE ERRO
versão do kubeadm
versão do kubelet
kubernetes- cni : 0.6.0-00 amd64
versão docker-ce
versão do sistema
Maquina fisica
Instale o cluster do Kubernetes no Ubuntu 16.04. Ao executar o kubeadm init, ocorre um erro:
[init] Isso pode levar um minuto ou mais se as imagens do plano de controle tiverem que ser extraídas.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
Depois que vi o syslog / var / log / syslog, ocorreram os seguintes erros:
04 de janeiro 16:20:58 master03 kubelet [10360]: W0104 16: 20: 58.268285 10360 cni.go: 171] Não foi possível atualizar a configuração do cni: nenhuma rede encontrada em /etc/cni/net.d
04 de janeiro 16:20:58 master03 kubelet [10360]: W0104 16: 20: 58.269487 10360 cni.go: 171] Não é possível atualizar a configuração do cni: nenhuma rede encontrada em /etc/cni/net.d
04 de janeiro 16:20:58 master03 kubelet [10360]: I0104 16: 20: 58.269527 10360 docker_service.go: 232] Rede Docker cri gerenciada por cni
04 de janeiro 16:20:58 master03 kubelet [10360]: I0104 16: 20: 58.274386 10360 docker_service.go: 237] Informações do Docker: & {ID: 3 XXZ : XEDW: ZDQS : AEN: CFEP : 44AQ: YDS4 : CRME: UBRS : 46LI: C ontainers MXNS: 0 Containe rsRunning: 0 Cont
04 de janeiro 16:20:58 master03 kubelet [10360]: erro: falha ao executar Kubelet: falha ao criar kubelet: configuração incorreta: driver kubelet cgroup: "cgroupfs" é diferente do driver docker cgroup: "systemd"
E eu verifiquei o driver do docker cgroup: docker info | grep -i cgroup
Driver Cgroup: systemd
versão kubeadm (use kubeadm version
):
Meio Ambiente :
kubectl version
):uname -a
):erro: falha ao executar Kubelet: falha ao criar kubelet: configuração incorreta: driver kubelet cgroup: "cgroupfs" é diferente do driver docker cgroup: "systemd"
informações do docker | grep -i cgroup
Driver Cgroup: systemd
Eu posso confirmar isso.
@ lavender2020 Você precisa anexar manualmente --cgroup-driver=systemd
a kubelet
args de inicialização e recarregar o arquivo de unidade kubelet para reiniciar o serviço.
O driver padrão que kubelet
usa para manipular cgroups no host é cgroupfs
.
A maioria das pessoas recorre a kubeadm
principalmente para configurar um cluster muito rapidamente. É simples e prático。
@luxas Devemos adicionar uma verificação prévia na consistência do driver cgroup entre docker
e kubelet
para fornecer avisos mais explícitos? Ou adicionar outro drop-in para kubelet.service
? Ou apenas modifique /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
no lugar?
Mas se for assim, podemos precisar adquirir privilégio de root para assumir essas mudanças.
Eu encontrei o mesmo problema com kubeadm v1.9.2
mas posso ver que o kubelet está configurado para usar o driver cgroup systemd.
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
informações do 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
registros do 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"
Informação da versão:
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 Você recarregou o arquivo de unidade kubelet.service
?
Execute systemctl daemon-reload
. E então systemctl restart kubelet
.
Este problema não foi corrigido no 1.9.3
Informação da versão:
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 Qual é o seu driver cgroup?
$ docker info | grep -i cgroup
Tendo o mesmo 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"
Existe algum outro lugar onde o Kubelet está obtendo a diretiva do driver cgroupfs?
@ mas-dse-greina Por favor, consulte a solução em meu comentário .
@dixudx Mesmo depois de anexar --cgroup-driver=systemd
a /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
o problema ainda persiste.
Este é o arquivo mais recente,
[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: Foi consertado. Depois de reiniciar o daemon e o kubelet, usei kubeadm init --pod-network-cidr = 10.244.0.0 / 16
sim. Estou descobrindo a mesma coisa. Anexando o --cgroup-driver = systemd
não parece ter nenhum efeito. Eu reiniciei o serviço e até
reiniciou o computador.
Parece que o comportamento é apenas nesta máquina. Eu estive
bem-sucedido com 4 outras máquinas, mas esta simplesmente não parece querer
junte-se ao cluster.
-Tony
Na quinta, 1º de março de 2018 às 11h44, srinivas491-oneconvergence <
notificaçõ[email protected]> escreveu:
@dixudx https://github.com/dixudx Mesmo depois de anexar o
--cgroup-driver = systemd para / etc / systemd / system / kubelet.
service.d / 10-kubeadm.conf o problema ainda persiste.-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/kubeadm/issues/639#issuecomment-369707723 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AVReEuQHJR80-8J4VLvACnGt1lTjEbYrks5taE-BgaJpZM4RSs0P
.
Depois de alterar o arquivo de unidade, você precisa systemdctl daemon-reload
para que uma alteração tenha efeito.
FWIW é padronizado nos RPMs, mas não nos .debs. Existe alguma distribuição atual no suporte principal que não seja padronizada como systemd agora?
/ assign @detiber
Eu tive esse mesmo problema com kubeadm v1.9.3 e v1.9.4.
Inicie o kubelet com --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
Recarregar serviço
$ systemctl daemon-reload
$ systemctl restart kubelet
Verifique as informações do 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
registros do kubelet
$ kubelet logs
error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "cgroupfs" is different from docker cgroup driver: "systemd"
Informação da versão
$ 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 Você pode olhar a linha de comando da execução do kubelet para ver se o driver cgroup está especificado lá?
Algo como ps aux |grep kubelet
ou cat /proc/<kubelet pid>/cmdline
deve ajudá-lo a ver isso.
@ bart0sh É isso:
$ 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 Obrigado! Eu poderia reproduzir isso também. Parece ser um bug. Olhando para ele.
Como solução temporária, você pode alternar o docker e o kubelet para o driver cgroupfs. Deve funcionar.
@ bart0sh Ótimo . Muito obrigado. Vou tentar isso.
Mesmo aqui.
[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 ~] # versão do kubeadm
kubeadm version: & version.Info {Major: "1", Minor: "9", GitVersion: "v1.9.4", GitCommit: "bee2d1505c4fe820744d26d26d41ecd3fdd4a3d6546", GitTreeState: "clean", BuildDate: "2018-03T16 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 corrigiu esse problema, incrível! @ bart0sh
@FrostyLeaf ainda sou capaz de reproduzi-lo com 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
Driver Cgroup: systemd
$ ps aux | grep cgroup-driver
root 29078 1,9 0,1 1222632 91824? SSL 13:45 0:04 / usr / bin / kubelet --bootstrap-kubeconfig = / etc / kubernetes / bootstrap-kubelet.conf --kubeconfig = / etc / kubernetes / kubelet.conf --pod-manifest-path = / etc / kubernetes / 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
I0321 13: 50: 29.901008 30817 container_manager_linux.go: 247] Criando objeto do Container Manager com base na configuração do nó: {RuntimeCgroupsName: SystemCgroupsName: KubeletCgroupsName: Contain erRuntime: docker Cgro upsPerQOS: true CgroupRoot: / CgrootR oupDrubgrupo: KubeletRoupDrub: grupo CgroupRoot: / CgrootDir / cgroupDrub: true CgroupRoot: cgrootDir / cDrubDriver / kubelet ProtectKerne lDefaults: false NodeAllocatableConfig: {KubeReservedCgroupName: SystemReservedCgroupName: EnforceNodeAl localizável: map [pods: {}] Kub eReserved: map [] Syste mReserved: map [] HardEvictionThresholds: [{ Signal: MemoryThannel : menos disponível : Quantidade: 100Mi P ercentage: 0 } Gr acePeriod: 0s MinReclaim:
erro: falha ao executar Kubelet: falha ao criar kubelet: configuração incorreta: driver kubelet cgroup: "cgroupfs" é diferente do driver docker cgroup: "systemd"
Você ainda está usando o driver cgroup systemd?
Eu proponho encerrar este assunto
Eu observei 2 razões que causam a maioria dos relatórios aqui:
esquecendo de executar 'systemctl daemon-reload' após editar drop-ins do systemd. Eventhough -cgroup-driver = systemd foi adicionado a /etc/systemd/system/kubelet.service.d/10-kubeadm.conf não fez nenhum efeito e o driver padrão (ou previamente especificado com --cgroup-driver) foi usava.
executando o comando 'kubelet logs' para ver os logs do kubelet. O subcomando 'logs' não existe no kubelet, então 'kubelet logs' e 'kubelet' são os mesmos comandos. 'kubelet logs' executa o kubelet com o driver cgroup padrão 'cgroupfs' e kubelet reclama sobre inconsistência entre os drivers kubelet e docker. 'journalctl -ux kubelet' deve ser usado para ver os logs.
Testei a opção --cgroup-driver = systemd com kubelet 1.8.0, 1.9.0, 1.9.3 e 1.9.5. Não houve mensagens de erro "cgroupfs é diferente do driver docker cgroup: systemd" nos logs.
@timothysc Não há objeções quanto ao meu último comentário. Você pode encerrar este problema, por favor? Não é um bug, pois é causado por uma falta de conhecimento sobre o kubelet e / ou systemd.
Duas coisas que podem fazer sentido do meu ponto de vista são:
Podemos considerar a criação de questões separadas para eles.
De qualquer forma, este assunto pode ser encerrado.
As coisas parecem bem para mim graças à v1.9.5.
Concorde com @ bart0sh sobre a verificação de inicialização da consistência do driver cgroup entre o kubelet e o docker.
Talvez os `kublet logs {devam apontar para o journactl -u kubelet.service
Apenas meus 2 cts.
Oi, estou tendo o mesmo problema.
Centos 7
A versão do kubeadm é: 1.9.6
A versão do docker é: 1.13.1 Versão da API: 1.26
quando eu corri: docker info | grep -i cgroup
,
Eu tenho esse:
WARNING: You're not using the default seccomp profile
Cgroup Driver: systemd
quando executo cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
,
Eu posso ver as configurações Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd"
no lugar.
Eu executei systemctl daemon-reload * e * systemctl restart kubelet , mas ainda mostrado
configuração incorreta: driver kubelet cgroup: "cgroupfs" é diferente do driver docker cgroup: "systemd"
Outra coisa estranha é: quando executei sed -i "s/cgroup-driver=systemd/cgroup-driver=cgroupfs/g" /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Eu vi que o --cgroup-drive foi alterado para cgroupfs .
Mas então exatamente a mesma mensagem de erro foi exibida quando executei kubelet status
novamente.
configuração incorreta: driver kubelet cgroup: "cgroupfs" é diferente do driver docker cgroup: "systemd"
Eu não consigo descobrir o problema.
Vou tentar com as versões mencionadas acima. Alguém sabe como instalar uma versão mais antiga do kubernetes? Obrigada.
@moqichenle Isso é estranho. Deve funcionar. Você pode mostrar a saída dos seguintes 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"
Aqui está o que vejo no meu 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 Oi, obrigado pela ajuda.
Isto é o que eu tenho (antes de iniciar o 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
Depois de digitar o comando kubeadm init,
isso é o que eu tenho:
[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
Mas então o init do kubeadm falhará porque o kubelet não está íntegro ou o kubelet não está em execução.
@moqichenle você executou systemctl daemon-reload
e systemctl restart kubelet
antes de executar kubeadm init
?
Você pode executar journalctl -u kubelet.service
após kubeadm init
e mostrar sua saída aqui?
Sim, executei os dois comandos antes do init.
Coisa estranha: não vi nenhuma saída quando executei journalctl -u kubelet.service | grep "is different from docker cgroup driver"
.
Só vi esse erro quando executei kubelet status
.
O comando @moqichenle kubelet status
não existe. Isso significa que você executa o kubelet com os parâmetros padrão (e o driver cgroup padrão). É por isso que você está recebendo o erro. Veja minhas mensagens sobre kubelet logs
para mais detalhes.
Você vê algo suspeito (erros, avisos) na saída de journalctl -u kubelet.service
?
Ah, entendo. Obrigada. :)
hmm .. existem erros mostrados abaixo:
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
Quando executei kubeadm init, se as configurações da unidade cgroup forem diferentes:
Isto mostra:
`[etcd] Escreveu o manifesto do pod estático para uma instância local do etcd em" /etc/kubernetes/manifests/etcd.yaml "
[init] Aguardando o kubelet inicializar o plano de controle como pods estáticos do diretório "/ etc / kubernetes / manifests".
[init] Isso pode levar um minuto ou mais se as imagens do plano de controle tiverem que ser extraídas.
[kubelet-check] Parece que o kubelet não está funcionando ou está íntegro.
Quando as configurações da unidade cgroup são iguais,
ele apenas trava na etapa de puxar o painel de controle e acaba com o kubelet com problemas ou não funcionando.
@moqichenle , para mim, parece um problema do docker. Não está relacionado a este, eu acredito.
Você pode pesquisar "prazo de contexto excedido" para obter mais informações.
@ bart0sh Sim, acho que não está mais relacionado a esse problema. vai fazer. Muito obrigada: D
este PR deve ajudar a diminuir a confusão causada pela execução de 'kubelet logs', 'kubelet status' e outros comandos kubelet não existentes: # 61833
Faz com que o kubelet produza um erro e saia se for executado com uma linha de comando incorreta.
Por favor revise.
Olá, posso reproduzir este problema no 1.10, só para verificar se é um bug e será corrigido no v1.11?
isso é um bug e será corrigido na v1.11
IMO, esta é uma incompatibilidade de configuração entre docker
e kubelet
, ao invés de um bug.
Antes de executar kubeadm init
, uma verificação de pré -
@dixudx Estou tentando instalar o k8s seguido pelo guia de instalação do site https://kubernetes.io/docs/setup/independent/install-kubeadm/ , e as etapas foram suspensas por este problema, abaixo estão os detalhes do meu ambiente ;
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
O cgroup entre docker e 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"
É o mesmo cgroup que o systemd, portanto, não há necessidade de ajustar o cgroup do kubelet manualmente. E eu comecei a executar o kubelet, mas falhei devido à mensagem de erro mencionada
[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>
A informação chave que vejo no log é CgroupDriver ainda cgroupfs, acho que é a razão que causou o problema de incompatibilidade do cgroup, mas não tem ideia de como ajustar esse valor padrão? você pode ajudar a esclarecer para isso, obrigado!
@wshandao Por favor, pare de usar kubelet logs
, que não é a maneira correta de ver o log.
A maneira correta de ver o log é journalctl -f -u kubelet
.
Obrigado @dixudx , meu erro e este não é realmente um problema para segurar minha instalação
Eu apoio os pedidos para fechar este.
a documentação já cobre que os usuários precisam verificar um driver cgroups correspondente.
isso é independente do kubeadm e é mais um problema de kubelet versus docker.
relatórios semelhantes:
https://github.com/kubernetes/kubernetes/issues/59794
https://github.com/openshift/origin/issues/18776
https://github.com/kubernetes/kubernetes/issues/43805
@timstclair
FWIW é padronizado nos RPMs, mas não nos .debs. Existe alguma distribuição atual no suporte principal que não seja padronizada como systemd agora?
Eu testei isso em 3 diferentes sistemas Ubuntu 16.04.2, 16.04.0, 17.04 e parece que o driver do docker é cgroupfs
, que corresponde ao valor do argumento padrão do kublet.
ao contrário do relatório do usuário na postagem original, onde o docker está usando systemd
em 16.04.3
, então pode ser a configuração do docker mudando entre as versões do docker. difícil dizer.
dados meus testes não vejo a necessidade de adicionar Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd"
no debs porque isso seria errado para essas versões do Ubuntu, pelo menos.
o que o kublet provavelmente deve fazer para uma experiência do usuário amigável é sempre corresponder ao driver do docker automaticamente.
@ neolit123 concordou.
No entanto, acho que devemos abrir um documento de solução de problemas JIC.
Fechando este e começarei meus documentos.
Eu tive esse mesmo problema no Ubuntu 16.04, Kube versão v1.10.4. Docker versão 1.13.1
O Docker estava começando com native.cgroupdriver = systemd. Esta configuração foi definida por mim em /etc/docker/daemon.json
{
"exec-opts": ["native.cgroupdriver=systemd"]
}
Eu modifiquei a configuração em /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Adicionada uma nova linha: Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd"
E adicione o parâmetro $KUBELET_CGROUP_ARGS
no ExecStart
Em seguida, fez um systemctl daemon-reload e um service kubelet restart.
Kubelet começou corretamente.
@dragosrosculete
estamos melhorando nossos documentos de solução de problemas, mas também na versão 1.11 e posterior, o driver cgroup para docker deve ser correspondido automaticamente pelo kubeadm.
Eu realmente acho que é um bug. Eu verifiquei a versão do docker e o arquivo kubeadm, é claro que o script kubeadm faz essa verificação também. no entanto, recebo a mensagem de erro de incompatibilidade. Se alguém já leu com atenção, você pode ver que algum dos itens acima tem o problema DEPOIS de definir corretamente o parâmetro.
isso ainda está acontecendo, nada funcionou!
Comentários muito úteis
Eu encontrei o mesmo problema com kubeadm
v1.9.2
mas posso ver que o kubelet está configurado para usar o driver cgroup systemd.kubelet está usando --cgroup-driver = systemd
informações do docker |
registros do kubelet
Informação da versão: