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:
$ 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:
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?
解决方法：
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发现是
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，新增两行：
- name: IP_AUTODETECTION_METHOD
value: "interface=eth0"
value指向从ip a看到的实际网卡名。结果如下：
# 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集群证书更新后没有自动重启对应的组件
解决方法：
执行如下命令后解决
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有关的所有配置文件的路径与内容
[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错误
[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端口
netstat -ntlup
2）确认schedule和controller-manager组件配置是否禁用了非安全端口
解决方法：
分别修改/etc/kubernetes/manifests/kube-scheduler.yaml和/etc/kubernetes/manifests/kube-controller-manager.yaml配置文件，将容器启动参数中 --port=0注释掉，该--port=0表示禁止使用非安全的http接口。下面以修改调度器配置文件为例，控制器配置文件修改和调度器一致。
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服务
systemctl restart kubelet
问题解决：
[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端口是否监听：
....... tcp6 0 0 :::10250 :::* LISTEN 20137/kubelet tcp6 0 0 :::10251 :::* LISTEN 13290/kube-schedule ......
14、configmap中json或者yaml文件内容格式问题
1）问题现象说明：
比如我有一个yaml格式的配置文件config.yaml，内容如下：
service:
port: 8001
# release
mode: release
url: kube-prometheus.monitoring
port: 9090
common:
file:
upload: /opt/data/common/file/
把该配置文件使用configmap方式创建：
kubectl create configmap myconfig --from-file=config.yaml
我们希望在命令行终端查看到的内容如下：
[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内容：
[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文件
# 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文件
# 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日志：
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下面是没有这个密钥的。
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服务地址：
[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配置：
vim /var/lib/kubelet/config.yaml xxxxx clusterDNS: - xxx.xxx.xxx.xxx clusterDomain: cluster.local xxxxx
经排查两者dns server不一致。
解决方案：修改新加入节点容器组DNS配置。
vim /var/lib/kubelet/config.yaml xxxxx clusterDNS: - 10.234.0.3 clusterDomain: cluster.local xxxxx
重启新加节点kubelet服务和容器运行时服务，问题得以解决。
