Kubernetes常见错误总结

1、屏幕持续打印Pod日志报error: unexpected EOF错误

Kubernetes: requesting flag for "kubectl logs" to avoid 5-minute timeout if no stdout/stderr 

When running kubectl logs --follow on a pod, after 5 minutes of no stdout/stderr, we received:

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

$ kubectl --kubeconfig=config --namespace=foo logs --follow foo-oneoff-w8npn --container bar   ###################################### #                                    # #  /system_tests/test_derp.py (1/4)  # #                                    # ######################################   RESULTS: [/system_tests/test_derp/TestDerp] Ran 4 tests in 130.044 s, ALL TESTS PASSED     ###################################### #                                    # #  /system_tests/test_fuzz.py (2/4)  # #                                    # ######################################   error: unexpected EOF

 解决方案：

For posterity, the problem here is that we're using haproxy to serve a VIP to balance HA Kubernetes masters.

Specifically we're using HA-Proxy v1.4.21, and we have this in our haproxy cfg:

?

1 2 3

defaults   timeout client  500000   timeout server  500000

2、K8s集群初始化成功后，kubectl get nodes 查看节点信息时报错

报错信息：The connection to the server localhost:8080 was refused - did you specify the right host or port?

解决方法：

?

1 2 3

mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config

3、master节点的calico组件是0/1 Running状态，其他worker节点的calico组件是1/1 Running状态，describe pod发现是

?

1	Readiness probe failed: calico/node is not ready: BIRD is not ready: BGP not established with 10.244.0.1,10.244.2.12020-04-13 06:29:59.582 [INFO][682] health.go 156: Number of node(s) with BGP peering established = 0

解决办法：
修改的calico.yaml，新增两行：

?

1 2	- name: IP_AUTODETECTION_METHOD   value: "interface=eth0"

value指向从ip a看到的实际网卡名。结果如下：

?

1 2 3 4 5 6 7 8 9 10 11

# Cluster type to identify the deployment type - name: CLUSTER_TYPE   value: "k8s,bgp" - name: IP_AUTODETECTION_METHOD   value: "interface=eth0" # Auto-detect the BGP IP address. - name: IP   value: "autodetect" # Enable IPIP - name: CALICO_IPV4POOL_IPIP   value: "Always"

等一会就正常了。

参考：https://blog.csdn.net/majixiang1996/article/details/105438506/

4、使用kubeadm安装kubernetes集群etcd一直卡在starting状态，查看etcd日志报2020-12-08 17:11:10.741954 I | embed: rejected connection from "192.168.100.179:47288" (error "tls: failed to verify client‘s certificate: x509: certificate has expired or is not yet valid", ServerName "") 错误

错误分析：原因是生成证书的机器时间快于etcd服务器时间，导致服务器验证时，证书超出了时间使用范围。

解决办法：

　　1）服务器和生成证书机器进行时间同步更新（高可用k8s集群需要master节点之间时间同步）。

　　2）或者直接调整生成证书的机器时间，使其慢于其他节点服务器的时间。

不推荐第二种方式。

参考：http://www.bubuko.com/infodetail-3670080.html

5、如果使用nfs作为存储方案所有节点都需要保证安装好nfs-client

检查服务器是否已安装好nfs-utils、rpcbind、libtirpc包。

参考：http://www.bubuko.com/infodetail-3546759.html

6、报错 cannot allocate memory 或者 no space left on device ，修复K8S内存泄露问题

链接：https://www.cnblogs.com/zhangmingcheng/p/14309962.html

7、执行kubectl命令时报错 error: You must be logged in to the server (Unauthorized)

链接：https://www.cnblogs.com/zhangmingcheng/p/14317551.html

8、kubectl delete pod kube-scheduler-xxxx  -n=kube-system 后，这个pod没有重启直接删掉了，重启kubelet服务使调度器pod重启

9、关于在k8s-v1.20以上版本使用nfs作为storageclass出现selfLink was empty, can‘t make reference错误

问题原因：kubernetes 1.20版本 禁用了 selfLink

解决方法（每个master节点都要执行）：

vim /etc/kubernetes/manifests/kube-apiserver.yaml

新增配置： - --feature-gates=RemoveSelfLink=false

由于kube-apiserver是静态Pod，修改完静态Pod声明文件（kube-apiserver.yaml）后，无需apply最新的声明文件（kube-apiserver.yaml），即可自动修改静态Pod配置。静态Pod详细内容见：Kubernetes静态Pod 

10、k8s 集群 metrics-server 组件报 authentication.go:65] Unable to authenticate the request due to an error: x509: certificate has expired or is not yet valid 错误

原因 ：k8s集群证书更新后没有自动重启对应的组件

解决方法：

执行如下命令后解决

?

1	docker ps |grep -E 'k8s_kube-apiserver|k8s_kube-controller-manager|k8s_kube-scheduler|k8s_etcd_etcd' | awk -F ' ' '{print $1}' |xargs docker restart

链接：https://www.cnblogs.com/ligang0357/p/15561680.html

11、kubelet 报如下错误：failed to run Kubelet: running with swap on is not supported, please disable swap! or set --fail-swap-on flag to false. /proc/swaps contained: [Filename...

原因： 当前机器没有关闭swap，关闭当前机器swap即可。

链接：https://www.cnblogs.com/zhangmingcheng/p/12671749.html

12、使用systemctl cat kubelet命令可以看到通过systemd配置的与kubelet有关的所有配置文件的路径与内容

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

[root@zmc-manage-uat-106 ~]# systemctl cat kubelet # /etc/systemd/system/kubelet.service [Unit] Description=kubelet: The Kubernetes Node Agent Documentation=http://kubernetes.io/docs/   [Service] ExecStart=/usr/local/bin/kubelet Restart=always StartLimitInterval=0 RestartSec=10   [Install] WantedBy=multi-user.target   # /etc/systemd/system/kubelet.service.d/10-kubeadm.conf # Note: This dropin only works with kubeadm and kubelet v1.11+ [Service] Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf" Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml" # This is a file that "kubeadm init" and "kubeadm join" generate at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env # This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use # the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file. EnvironmentFile=-/etc/default/kubelet Environment="KUBELET_EXTRA_ARGS=--node-ip=10.20.31.106 --hostname-override=zmc-manage-uat-106 " ExecStart= ExecStart=/usr/local/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS [root@zmc-manage-uat-106 ~]#

参考：https://www.cnblogs.com/wangqingyong/p/14542937.html

13、kubectl get cs显示scheduler Unhealthy、controller-manager Unhealthy错误

?

1 2 3 4 5 6

[root@node1 ~]# kubectl get componentstatuses Warning: v1 ComponentStatus is deprecated in v1.19+ NAME                 STATUS      MESSAGE                                                                                       ERROR scheduler            Unhealthy   Get "http://127.0.0.1:10251/healthz": dial tcp 127.0.0.1:10251: connect: connection refused   controller-manager   Unhealthy   Get "http://127.0.0.1:10252/healthz": dial tcp 127.0.0.1:10252: connect: connection refused   etcd-0               Healthy     {"health":"true"}

错误分析：

1）首先确认没有启动10251、10252端口

?

1	netstat -ntlup

2）确认schedule和controller-manager组件配置是否禁用了非安全端口　

解决方法：

分别修改/etc/kubernetes/manifests/kube-scheduler.yaml和/etc/kubernetes/manifests/kube-controller-manager.yaml配置文件，将容器启动参数中 --port=0注释掉，该--port=0表示禁止使用非安全的http接口。下面以修改调度器配置文件为例，控制器配置文件修改和调度器一致。

?

1 2 3 4 5 6 7 8 9 10

containers:   - command:     - kube-scheduler     - --authentication-kubeconfig=/etc/kubernetes/scheduler.conf     - --authorization-kubeconfig=/etc/kubernetes/scheduler.conf     - --bind-address=0.0.0.0     - --feature-gates=ExpandCSIVolumes=true,RotateKubeletServerCertificate=true     - --kubeconfig=/etc/kubernetes/scheduler.conf     - --leader-elect=true   #  - --port=0

重启kubelet服务

?

1	systemctl restart kubelet

问题解决：

?

1 2 3 4 5

[root@node1 ~]# kubectl get cs NAME                 STATUS    MESSAGE             ERROR controller-manager   Healthy   ok                  scheduler            Healthy   ok                  etcd-0               Healthy   {"health":"true"}

再次通过netstat -ntlup命令验证10251、10252端口是否监听：

?

1 2 3 4

.......        tcp6       0      0 :::10250                :::*                    LISTEN      20137/kubelet       tcp6       0      0 :::10251                :::*                    LISTEN      13290/kube-schedule ......

14、configmap中json或者yaml文件内容格式问题

1）问题现象说明：

比如我有一个yaml格式的配置文件config.yaml，内容如下：

?

1 2 3 4 5 6 7 8 9

service:   port: 8001   # release   mode: release   url: kube-prometheus.monitoring   port: 9090 common:   file:     upload: /opt/data/common/file/

把该配置文件使用configmap方式创建：

?

1	kubectl create configmap myconfig --from-file=config.yaml

我们希望在命令行终端查看到的内容如下：

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

[root@node1 ~]# kubectl get configmaps myconfig -o yaml apiVersion: v1 data:   config.yaml: |     service:       port: 8001       # release       mode: release       url: kube-prometheus.monitoring       port: 9090     common:       file:         upload: /opt/data/common/file/ kind: ConfigMap metadata:   creationTimestamp: 2019-04-24T05:59:52Z   name: myconfig   namespace: default   resourceVersion: "1774515"   selfLink: /api/v1/namespaces/default/configmaps/myconfig   uid: 2d066fef-6656-11e9-96e0-005056bf291a [root@node1 ~]#

但是有时候我们看到如下格式错乱的configmap内容：

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14

[root@intellif-0 ~]# kubectl get configmaps myconfig -o yaml apiVersion: v1 data:   config.yaml: "service:\n  port: 8001\n  # release\n  mode: release\n  url: kube-prometheus.monitoring\n     \ port: 9090\ncommon:\n  file:\n    upload: /opt/data/common/file/  \n" kind: ConfigMap metadata:   creationTimestamp: 2019-04-24T06:01:42Z   name: myconfig   namespace: default   resourceVersion: "1774818"   selfLink: /api/v1/namespaces/default/configmaps/myconfig   uid: 6eac963e-6656-11e9-96e0-005056bf291a [root@intellif-0 ~]#

2）分析与解决：

问题原因： 文件中某一行结尾有空格，示例中是最后一行（使用vim工具:set invlist）
正常的yaml文件

?

1 2 3 4 5 6 7 8 9 10 11 12

# vim config.yaml service:$   port: 8001$   # release$   mode: release$   url: kube-prometheus.monitoring$   port: 9090$ common:$   file:$     upload: /opt/data/common/file/$                                                                                                                                                                                     ~                                                                                                                                                                                                                                                                                                                                                                                 :set invlist

异常的yaml文件

?

1 2 3 4 5 6 7 8 9 10 11 12

# vim config.yaml service:$   port: 8001$   # release$   mode: release$   url: kube-prometheus.monitoring$   port: 9090$ common:$   file:$     upload: /opt/data/common/file/  $                                                                                                                                                                                     ~                                                                                                                                                                                                                                                                                                                                                                                :set invlist

参考：https://blog.csdn.net/zhangxiangui40542/article/details/89491740

15、kubelet日志报不能检索密钥，导致拉取镜像不成功问题

kubelet日志：

?

1	kubelet: W1104 18:34:07.882008     843 kubelet_pods.go:863] Unable to retrieve pull secret pro/gb28181server for pro/xxxserver-v1-76cc9b558d-wmbgf due to secret "gb28181server" not found.  The image pull may not succeed.

问题分析：

检查Pod的Yaml文件，发现配置文件中配置了gb28181server这个镜像拉取密钥，但实际当前Pod所在namespace下面是没有这个密钥的。

?

1 2 3 4 5 6 7 8 9 10 11

apiVersion: v1 kind: Pod metadata:  ...... spec:   .......   enableServiceLinks: true   imagePullSecrets:   - name: gb28181server   nodeName: 129   ........

解决方案：

1）如果镜像所在harbor项目是公开项目的话，那么kubelet是有权限直接拉取镜像的，这种情况下可以删掉Pod Yaml文件中的imagePullSecrets配置项；

2）如果镜像所在harbor项目是私有项目的话，那么必须创建认证harbor私有仓库的gb28181server密钥。

参考：kubernetes的imagePullSecrets如何生成及使用 - 走看看

16、Centos7服务器Kubernetes新加入节点访问外部域名不通问题

背景：某项目Kubernetes集群新纳入了12台worker节点，新纳入节点和其他集群节点(master节点和worker节点)网络都是连通的，但是项目实施人员却反馈调度到这12台节点上容器组内部是连不通外部域名的，直接在这12台节点上访问外部域名正常。

问题分析：节点上访问外部域名正常，说明节点dns server配置是没问题的；而容器内部访问不通很可能是以下问题导致：

1）集群dns组件(coredns)异常，但是老节点上的容器组内部是能正常解析外部域名的，所以排除此原因；

2）新加入节点存在未开的端口策略，经检查防火墙策略单及相应测试，也都没问题；

3）容器组配置了错误的 dns server，经测试新节点不仅外部域名不通，k8s内部服务也访问不通，所以基本锁定容器组节点配置了错误的dns server，经检查确实如此。

检查Kubernetes集群DNS服务地址：        

?

1 2	[root@master1 ~]# kubectl get svc -n=kube-system |grep dns coredns                       ClusterIP   10.234.0.3       <none>        53/UDP,53/TCP,9153/TCP         115d

检查新加入节点容器组DNS配置：

?

1 2 3 4 5 6

vim /var/lib/kubelet/config.yaml xxxxx clusterDNS: - xxx.xxx.xxx.xxx clusterDomain: cluster.local xxxxx

经排查两者dns server不一致。

解决方案：修改新加入节点容器组DNS配置。

?

1 2 3 4 5 6

vim /var/lib/kubelet/config.yaml xxxxx clusterDNS: - 10.234.0.3 clusterDomain: cluster.local xxxxx

重启新加节点kubelet服务和容器运行时服务，问题得以解决。