自己总结|K8S-遇到问题-解决日记


文章目录

  • 问题一:etcd和apiserver无法正常启动
            • 问题查看nodes节点发生报错
      • 解决方法/步骤
            • 步骤一:K8S集群节点异常重启后,再终端执行kubectl get nodes命令,出现报错dial tcp 10.200.18.100:6443: connect: connection refused。
            • 步骤二:通过docker ps -a可以看到api现在处于exit退出状态。
            • 步骤三:查看apiserver服务容器的启动日志, 发现又出现报错Error while dialing dial tcp 127.0.0.1:2379: connect: connection refused,2379是etcd的端口,那么apiserver是由于etcd无法连接而启动不了。
            • 步骤四:
            • 接着查看etcd的启动日志,发现报错mvcc: cannot unmarshal event: proto: wrong wireType = 0 for field Key。经查询资料,此报错是由于服务器非正常关机(意外掉电,强制拔电)后 etcd数据损坏导致的,这个节点之前确实是出现异常关机,etcd无法启动,那么解决此问题就行了。
            • 步骤五:
            • 按照指导进行操作,在故障节点上停止etcd服务并删除损坏的 etcd 数据,现在etcd服务本来就没有启动,删除前先备份数据,最后启动etcd服务。
            • 注:容器的数据在/var/lib目录下,按照下图操作。
            • 步骤六:最后先启动etcd服务,然后启动api-server,执行kubectl get nodes后可以正常显示节点状态,问题解决。
  • 问题二:ImagePullBackOff 缺少镜像
      • 解决方法步骤
            • 查看pod的详细信息
            • 报错查看缺少kube-state-metrics镜像
            • 再次查看pod报错已经解决
  • 问题三:部署Elasticsearch错报
            • 启动es报错
            • 删除非kubectl启动pod
            • 删除html方式启动pod
      • 最终解决方法
  • 问题四:部署rancher页面化错报
            • 访问 https页面报错
            • 访问不到
      • 解决方法:telnet查看端口通不通
            • 端口不通进入容器内部查看
            • 切换版本2.5.3的版本
  • 问题五:
            • 解决:metrics-server启动时报unable to recognize “*“: no matches for kind “*“ in version “*“ 等错误
            • 最终解决
  • 问题六:rancher显示0/1 Running问题排查
            • 问题状态
            • 查看详细信息:
            • 查看pod日志
  • 问题七:日常错误排查
      • 状态查看
            • 查看 Pod 状态以及运行节点
            • 查看 Pod 事件
            • 查看 Node 状态
      • 二、日志查看
            • kube-apiserver 日志
      • kube-controller-manager 日志
      • kube-scheduler 日志
      • kube-dns 日志
      • Kubelet 日志
      • Kube-proxy 日志

问题一:etcd和apiserver无法正常启动 问题查看nodes节点发生报错 自己总结|K8S-遇到问题-解决日记
文章图片

解决方法/步骤
步骤一:K8S集群节点异常重启后,再终端执行kubectl get nodes命令,出现报错dial tcp 10.200.18.100:6443: connect: connection refused。 步骤二:通过docker ps -a可以看到api现在处于exit退出状态。 自己总结|K8S-遇到问题-解决日记
文章图片

步骤三:查看apiserver服务容器的启动日志, 发现又出现报错Error while dialing dial tcp 127.0.0.1:2379: connect: connection refused,2379是etcd的端口,那么apiserver是由于etcd无法连接而启动不了。 自己总结|K8S-遇到问题-解决日记
文章图片

步骤四: 接着查看etcd的启动日志,发现报错mvcc: cannot unmarshal event: proto: wrong wireType = 0 for field Key。经查询资料,此报错是由于服务器非正常关机(意外掉电,强制拔电)后 etcd数据损坏导致的,这个节点之前确实是出现异常关机,etcd无法启动,那么解决此问题就行了。 自己总结|K8S-遇到问题-解决日记
文章图片

自己总结|K8S-遇到问题-解决日记
文章图片

步骤五: 按照指导进行操作,在故障节点上停止etcd服务并删除损坏的 etcd 数据,现在etcd服务本来就没有启动,删除前先备份数据,最后启动etcd服务。 注:容器的数据在/var/lib目录下,按照下图操作。
root@k8s-master:/var/lib/etcd# find ./ -type d -name member ./member root@k8s-master:/var/lib/etcd# cd ./member root@k8s-master:/var/lib/etcd/member# ls snapwal root@k8s-master:/var/lib/etcd/member# mkdir ../bak root@k8s-master:/var/lib/etcd/member# mv * ../bak/ root@k8s-master:/var/lib/etcd/member# ls

自己总结|K8S-遇到问题-解决日记
文章图片

步骤六:最后先启动etcd服务,然后启动api-server,执行kubectl get nodes后可以正常显示节点状态,问题解决。 可以重启容器
root@k8s-master:/var/lib/etcd/member# docker start 37f1e8e68a81重启 etcdroot@k8s-master:/var/lib/etcd/member# docker start c32fbf338038重启 api

自己总结|K8S-遇到问题-解决日记
文章图片

问题二:ImagePullBackOff 缺少镜像 自己总结|K8S-遇到问题-解决日记
文章图片

解决方法步骤
查看pod的详细信息
root@k8s-master:~# kubectl describe -n monitoring poprometheus-adapter-6455646bdc-d72zx#举例查看详细信息

自己总结|K8S-遇到问题-解决日记
文章图片

报错查看缺少kube-state-metrics镜像 【自己总结|K8S-遇到问题-解决日记】拉取镜像修改tag
root@k8s-node2:~# docker pull registry.cn-wulanchabu.aliyuncs.com/moge1/kube-state-metrics:v2.3.0 v2.3.0: Pulling from moge1/kube-state-metrics 2df365faf0e3: Pull complete bbb17218abce: Pull complete Digest: sha256:caf70de8662486ff35ac74e8631e348981faad5dd0c4e370742a141b38acd720 Status: Downloaded newer image for registry.cn-wulanchabu.aliyuncs.com/moge1/kube-state-metrics:v2.3.0 registry.cn-wulanchabu.aliyuncs.com/moge1/kube-state-metrics:v2.3.0 root@k8s-node2:~# docker tag registry.cn-wulanchabu.aliyuncs.com/moge1/kube-state-metrics:v2.3.0 k8s.gcr.io/kube-state-metrics/kube-state-metrics:v2.5.0 root@k8s-node2:~# docker images|grep state k8s.gcr.io/kube-state-metrics/kube-state-metricsv2.5.06ffbf5a790d86 months ago38.7MB registry.cn-wulanchabu.aliyuncs.com/moge1/kube-state-metricsv2.3.06ffbf5a790d86 months ago38.7MB

再次查看pod报错已经解决
kubectl get po --all-namespaces -o wide |grep state

自己总结|K8S-遇到问题-解决日记
文章图片

问题三:部署Elasticsearch错报 启动es报错
helm install elasticsearch -f values.yaml elastic/elasticsearch --namespace elk

自己总结|K8S-遇到问题-解决日记
文章图片

删除非kubectl启动pod
kubectl delete -n elk po elasticsearch-master-0#删除指定命名空间pod kubectl delete -n elk po elasticsearch-master-0 --force --grace-period=0#强制删除命名空间pod

删除html方式启动pod
helm install elasticsearch -f values.yaml elastic/elasticsearch --namespace elk#uninstall卸载的意思

最终解决方法
原因是因为 es是集群方式,然后运行内存是很大的,我的是因为运行内存不够了,才一直起不来
自己总结|K8S-遇到问题-解决日记
文章图片

要么加内存,要么减少一点,尝试能不能起来
问题四:部署rancher页面化错报 访问 https页面报错 自己总结|K8S-遇到问题-解决日记
文章图片

访问不到 自己总结|K8S-遇到问题-解决日记
文章图片

解决方法:telnet查看端口通不通
root@k8s-node1:/var/data# telnet 196.196.196.11 443 Trying 196.196.196.11... telnet: Unable to connect to remote host: Connection refused root@k8s-node1:/var/data# telnet 196.196.196.11 80 Trying 196.196.196.11... telnet: Unable to connect to remote host: Connection refused

端口不通进入容器内部查看 rancher里面内置了迷你版k8s,他会联网安装一些组件
root@k8s-master:~# docker exec -it edc3fd71a33c /bin/bash root@edc3fd71a33c:/var/lib/rancher# ls k3sk3s.logmanagement-state

自己总结|K8S-遇到问题-解决日记
文章图片

问题原因之一,怀疑是k8s-master这台服务器内存不够,因为启动的这个容器,里面是迷你版本的k8s,尝试加大内存,或者修改方式
切换版本2.5.3的版本
docker run -d --restart=always --privileged=true -v /opt/rancher/data:/var/lib/rancher -v /opt/rancher/auditlog:/var/log/auditlog -p 8081:80 -p 8443:443 --name rancher-v2.5.3 rancher/rancher:v2.5.3

问题五: 解决:metrics-server启动时报unable to recognize ““: no matches for kind ““ in version “*“ 等错误 相关报错问题
unable to recognize "auth-delegator.yaml": no matches for kind "ClusterRoleBinding" in version "rbac.authorization.k8s.io/v1beta1" unable to recognize "auth-reader.yaml": no matches for kind "RoleBinding" in version "rbac.authorization.k8s.io/v1beta1" unable to recognize "metrics-apiservice.yaml": no matches for kind "APIService" in version "apiregistration.k8s.io/v1beta1"

自己总结|K8S-遇到问题-解决日记
文章图片

解决:
报错的原因是因为资源文件的版本定义过期了,需要修改下版本
#删除已创建的容器 [root@k8s-master01 1.8+]# kubectl delete -f ./ [root@k8s-master01 1.8+]# sed -i 's#rbac.authorization.k8s.io/v1beta1#rbac.authorization.k8s.io/v1#' auth-reader.yaml [root@k8s-master01 1.8+]# sed -i 's#rbac.authorization.k8s.io/v1beta1#rbac.authorization.k8s.io/v1#' auth-delegator.yaml [root@k8s-master01 1.8+]# sed -i 's#apiregistration.k8s.io/v1beta1#apiregistration.k8s.io/v1#' metrics-apiservice.yaml #重新创建 [root@k8s-master01 1.8+]# kubectl apply -f ./ clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created serviceaccount/metrics-server created deployment.apps/metrics-server created service/metrics-server created clusterrole.rbac.authorization.k8s.io/system:metrics-server created clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created #查看pod是否运行成功 [root@k8s-master01 1.8+]# kubectl get pods -n kube-system metrics-server-644778ff4f-87fgn1/1Running016h

最终解决 查看node节点的
root@k8s-node1:/var/data# cat /etc/kubernetes/kubelet.conf | grep user user: default-auth users: user: root@k8s-node1:/var/data#

执行第一步
kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user default-auth

自己总结|K8S-遇到问题-解决日记
文章图片

执行第二步
curl --insecure -sfL https://196.196.196.11:8443/v3/import/jtbz8lsk9hcl49ggtsrt2vqtqbtjj5b8qcprmbm8gf2sd44pj6stw8.yaml | kubectl apply -f -

自己总结|K8S-遇到问题-解决日记
文章图片

下载yaml文件
wget https://196.196.196.11:8443/v3/import/7bm6x2cwvtrwlx8m2k2n8n5v655gzjpgglqvgvg8rpbwxjl68w9r8j.yaml --no-check-certificate

自己总结|K8S-遇到问题-解决日记
文章图片

sed全局修改配置文件
sed -i 's#rbac.authorization.k8s.io/v1beta1#rbac.authorization.k8s.io/v1#' 7bm6x2cwvtrwlx8m2k2n8n5v655gzjpgglqvgvg8rpbwxjl68w9r8j.yaml

自己总结|K8S-遇到问题-解决日记
文章图片

执行yaml文件
kubectl apply -f 7bm6x2cwvtrwlx8m2k2n8n5v655gzjpgglqvgvg8rpbwxjl68w9r8j.yaml

自己总结|K8S-遇到问题-解决日记
文章图片

删除重新添加就执行
kubectl delete clusterrolebinding cluster-admin-binding

第一步跟第三步就可以了
问题六:rancher显示0/1 Running问题排查 问题状态 自己总结|K8S-遇到问题-解决日记
文章图片

发现k8s-node2节点的coredns出现0/1 Running状态;
查看详细信息:
kubectl describepodcattle-cluster-agent-ccb7694db-htdk8 -n cattle-system

自己总结|K8S-遇到问题-解决日记
文章图片

主要报错信息为:活动探测失败:HTTP探测失败状态码为:503 这个信息对我来说完全没用,目前只知道是node从机kubelet上部署的coreDNS组件工作异常,仅此而已。
查看pod日志
kubectl logs -fcattle-cluster-agent-ccb7694db-htdk8 -n cattle-system

自己总结|K8S-遇到问题-解决日记
文章图片

一、跑Rancher 的机器Docker和K8S Docker容器网段相同! 昨天因为需求,所以需要部署新的环境,然后就创建了kubenetes,想着还是使用rancher来管理来着,但是在导入rancher的时候总是报错:websocket: bad handshake,百度了很久,有的说是因为插件的问题,有的说是计算机名的问题,还有的说是rancher的底层问题。但是我前段时间确实使用的同一个版本的rancher和kubenetes做导入是没有任何问题的。都正常了。没办法,只能一个一个的找了,我发现kubenetes中的pod无法和我node节点同一个网段的节点通信,这个就比较出来了,原来pod不是跟所有node节点,只是和rancher这个服务的节点不能通行,其他都正常,而且rancher客户端的日志出现内容如下:

解决方法:
我尝试着在pod里去ping一下rancher的节点ip,不能通信,和其他的节点正常,这个问题就比较明显了,rancher这个节点有问题。下面继续分析,在rancher这个服务上的docker的ip地址和node节点的ip地址是一个网段的,有冲突了。修改一下docker的节点ip端。
vim /etc/docker/daemon.json { "bip":"192.168.0.1/24" }

我这里docker默认的网断和宿主机是一个网段的,这里做一下修改,然后重启一下docker,在重新试一下问题解决。
问题七:日常错误排查 状态查看
查看 Pod 状态以及运行节点
kubectl get pods -o widekubectl -n kube-system get pods -o wide

查看 Pod 事件
kubectl describe pod

查看 Node 状态
kubectl get nodeskubectl describe node

二、日志查看
kube-apiserver 日志
PODNAME=$(kubectl -n kube-system get pod -l component=kube-apiserver -ojsonpath='{.items[0].metadata.name}')kubectl -n kube-system logs $PODNAME --tail 100

以上命令操作假设控制平面以 Kubernetes 静态 Pod 的形式来运行。如果 kube-apiserver 是用 systemd 管理的,则需要登录到 master 节点上,然后使用
journalctl -u kube-apiserver 查看其日志。

kube-controller-manager 日志
PODNAME=$(kubectl -n kube-system get pod -lcomponent=kube-controller-manager -o jsonpath='{.items[0].metadata.name}')kubectl -n kube-system logs $PODNAME --tail 100

●以上命令操作假设控制平面以 Kubernetes 静态 Pod 的形式来运行。如果 kube-controller-manager 是用 systemd 管理的,则需要登录到 master 节点上,
然后使用 journalctl -u kube-controller-manager 查看其日志。

kube-scheduler 日志
PODNAME=$(kubectl -n kube-system get pod -l component=kube-scheduler -ojsonpath='{.items[0].metadata.name}')kubectl -n kube-system logs $PODNAME --tail 100

●以上命令操作假设控制平面以 Kubernetes 静态 Pod 的形式来运行。如果 kube-scheduler 是用 systemd 管理的,则需要登录到 master 节点上,
然后使用 journalctl -u kube-scheduler 查看其日志。

kube-dns 日志
kube-dns 通常以 Addon 的方式部署,每个 Pod 包含三个容器,最关键的是 kubedns
容器的日志:
PODNAME=$(kubectl -n kube-system get pod -l k8s-app=kube-dns -ojsonpath='{.items[0].metadata.name}')kubectl -n kube-system logs $PODNAME -c kubedns

Kubelet 日志
Kubelet 通常以 systemd 管理。查看 Kubelet 日志需要首先 SSH 登录到 Node
上,推荐使用 kubectl-node-shell而不是为每个节点分配公网 IP 地址。比如:··
[root@localhost ~]# cat kubectl-node_shell #!/bin/sh if [ -z "$1" ]; then echo "Please specify node name" exit 1 fiNODE="$1" IMAGE="alpine" POD="nsenter-$(env LC_CTYPE=C tr -dc a-z0-9 < /dev/urandom | head -c 6)" NAMESPACE=""# Check the node kubectl get node "$NODE" >/dev/null || exit 1OVERRIDES="$(cat <

Kube-proxy 日志
Kube-proxy 通常以 DaemonSet 的方式部署,可以直接用 kubectl 查询其日志
kubectl -n kube-system get pod -l component=kube-proxy NAME READY STATUS RESTARTS AGE kube-proxy-42zpn 1/1 Running 0 1d kube-proxy-7gd4p 1/1 Running 0 3d kube-proxy-87dbs 1/1 Running 0 4d $ kubectl -n kube-system logs kube-proxy-42zpn

ter-i71opm" on “localhost.localdomain”
If you don’t see a command prompt, try pressing enter.
[root@localhost /]# journalctl -l -u kubelet
### Kube-proxy 日志Kube-proxy 通常以 DaemonSet 的方式部署,可以直接用 kubectl 查询其日志```shell kubectl -n kube-system get pod -l component=kube-proxy NAME READY STATUS RESTARTS AGE kube-proxy-42zpn 1/1 Running 0 1d kube-proxy-7gd4p 1/1 Running 0 3d kube-proxy-87dbs 1/1 Running 0 4d $ kubectl -n kube-system logs kube-proxy-42zpn

    推荐阅读