记录遇到的问题,后面会一点点补充

Kubernetes使用到的端口

服务名	备注	需要的端口
kube-scheduler	调度服务	10251 tcp
etcd	2379端口API 服务，2380端口peer 通信	2379，2380 tcp
kube-controller-manager	容器管理	10252 tcp
kube-apiserver	apiserver	443 tcp 此端口随配置而变化
calico-typha	管理calico	5437 tcp
kubelet	认证API	10250 tcp
bird bgp通信		179 tcp
kube-proxy	10249：对外提供 /metrics; 10256：对外提供 /healthz 的访问。	10249，10256 tcp
calico-node	网络接口管理和监听、路由、ARP 管理、ACL 管理和同步、状态上报	9099 tcp
vxlan	vxlan协议端口	4789 udp

一, kubelet#

1 查看节点状态 NotReady#

1.1 PLEG is not healthy#

1.1.1 查看节点信息#

在使用top命令检查系统负载的时候，可以看到Load averages字段，但是这个字段并不是表示 CPU 的繁忙程度，而是度量系统整体负载。系统有很高的负载但是 CPU 使用率却很低，或者负载很低而 CPU 利用率很高，这两者没有直接关系.

pod 数量不算多 70 左右
cpu 使用率不到百分之 20
内存使用率不到百分之 50
top 查看 load 一直持续在 200 以上

1.1.2 检测运行队列中的进程#

1
cat init.sh
2
#!/bin/bash
3
LANG=C
4
PATH=/sbin:/usr/sbin:/bin:/usr/bin
5
interval=1
6
length=86400
7
for i in $(seq 1 $(expr ${length} / ${interval}));do
8
date
9
LANG=C ps -eTo stat,pid,tid,ppid,comm --no-header | sed -e 's/^ \*//' | perl -nE 'chomp;say if (m!^\S*[RD]+\S*!)'
10
date
11
cat /proc/loadavg
12
echo -e "\n"
13
sleep ${interval}
14
done

发现有大量的 mount.nfs 命令处于 D 状态, 估计这是造成 load 上伤的元凶,
D 代表不可中断的睡眼进程

1
.....
2
D    176108 176108 176107 mount.nfs
3
D    179927 179927 179926 mount.nfs
4
D    182432 182432 182431 mount.nfs
5
D    182884 182884 182883 mount.nfs
6
D    183495 183495 183494 mount.nfs
7
D    185283 185283 185282 mount.nfs
8
D    188423 188423 188422 mount.nfs
9
D    189740 189740 189739 mount.nfs
10
D    191333 191333 191332 mount.nfs
11
D    193889 193889 193888 mount.nfs
12
D    196476 196476 196475 mount.nfs
13
D    197029 197029 197028 mount.nfs
14
D    200640 200640 200639 mount.nfs
15
D    200841 200841 200840 mount.nfs
16
D    200992 200992 200991 mount.nfs
17
D    205285 205285 205282 mount.nfs
18
D    209356 209356 209355 mount.nfs
19
D    210161 210161 210160 mount.nfs
20
.....

1.1.3 查看前 20 使用 CPU 比较高的进程#

如果发现 CPU 使用率过高使用此命令

1
 ps -eT -o%cpu,pid,tid,ppid,comm | grep -v CPU | sort -n -r | head -20

1.1.4 查看前 20 使用内存比较高的进程#

如果发现内存使用率过高使用此命令

1
ps -eT -o%mem,pid,tid,ppid,comm  | sort -n -r | head -20

1.1.5 查看有问题的进程#

1
root       210161 210161  0 Aug23 ?        00:00:00 /sbin/mount.nfs 10.1.1.1:/pvc_ad704803_221b_4b54_9b27_c4dc3f8cd3b2/ /data/kubelet/pods/ebc34128-274e-4949-832f-c6c374c95899/volumes/kubernetes.io~csi/pvc-ad7
2
04803-221b-4b54-9b27-c4dc3f8cd3b2/mount -o rw

1.1.6 测试 nfs 地址#

showmount 这个 nfs 服务地址发现直接卡死,所以导致这些进程睡眠

1
showmount 10.1.1.1

1.1.7 关闭异常进程#

1
kill -9 `sh init.sh | grep ^D |awk '{print $2}'`

1.1.8 查看 load#

已经恢复正常,并且查看节点状态不会出现 PLEG

1
uptime
2
 15:26:01 up 65 days, 45 min,  1 user,  load average: 0.17, 2.17, 51.33

2 pod 一直 ContainerCreating 状态#

2.1 查看 pod 事件#

1
kubectl get pod -A -o wide | grep 32.220
2
monitoring          node-exporter-ltw97                0/1     Pending

注意: 只有调度到某个节点事件,后续没任何事件

1
kubectl describe pod -n monitoring
2
Events:
3
  Type    Reason     Age    From               Message
4
  ----    ------     ----   ----               -------
5
  Normal  Scheduled  2m59s  default-scheduler  Successfully assigned monitoring/node-exporter-ltw97 to k8snode-2

2.2 查看节点#

节点状态在这里也是好的

1
kubectl describe node k8snode-2

2.3 查看 kubelet 日志#

到对应节点查询这个 pod 日志

可以看到其中有一个错误是”Error deleting pod from network”

1
cat kubelet.ERROR |grep node-exporter-ltw97
2
E1122 13:35:18.295578  275102 cni.go:380] "Error deleting pod from network" err="error getting ClusterInformation: Get https://[172.123.0.1]:443/apis/crd.projectcalico.org/v1/clusterinformat
3
ions/default: dial tcp 172.123.0.1:443: i/o timeout" pod="monitoring/monitoring-collect-zk56k" podSandboxID={Type:docker ID:46fc59b379bd146d53540a98399dd25d7d0e09e02370c021d70060e633cb71de}
4
podNetnsPath="" networkType="calico" networkName="k8s-pod-network"

2.4 检测此节点 cni#

这里我们用的 calico,并且可以看到 pod 异常,这是导致上面 pod 分配不了网络的直接原因

1
get pod -n kube-system -o wide | grep 32.220
2
kube-system      calico-node-8c9sz                          0/1     CrashLoopBackOff

2.5 查看 calico-node 日志#

看到这里又有新的报错,网上搜的都是账号权限不对,我又尝试 logs 别的节点的 pod 发现没任何问题,说明跟 Role 没关系这里说明 kubelet 连接 api 有问题
扩展下 logs 流程:

kubectl 发起 logs 请求到 apiserver

kubelet watch apiserver 发现有人要看我这个 pod 日志 (这里 kubelet 访问 api 有问题所有就看不了日志了,但是为什么报权限问题我也很迷)

kubelet 处理 logs 请求，实际上是将请求转发给 CRI，CRI 将会启动一个临时的 streaming server 服务，后续 apiserver 的信息获取是与 streaming server 进行交互。

1
kubectl logs -n kube-system      calico-node-8c9sz
2
Error from server (InternalError): Internal error occurred: Authorization error (user=kubernetes, verb=get, resource=nodes, subresource=proxy)

2.6 继续查看 kubelet 日志,尝试搜索 api 相关日志#

可以看到这条日志解析有问题,10.1.1.1 找不到这条 dns 解析这里说下架构,我们是一个 SLB 负载后端三台 master,然后 dns 解析这个 SLB 地址

1
cat kubelet.ERROR |grep api
2
Service: Get "https://api-k8s.test.cc:6443/api/v1/services?limit=500&resourceVersion=0": dial tcp: lookup api-k8s.test.cc on 10.1.1.1:53: no such host

2.6.1 尝试添加 hosts#

1
cat /etc/hosts
2
...
3
10.251.66.185 api-k8s.test.cc

2.6.2 重启后 pod 创建正常#

1
kubectl get pod -A -o wide | grep 32.220
2
kube-system      calico-node-8c9sz                          1/1     Running
3
monitoring       node-exporter-ltw97                        2/2     Running

这个问题挺不好排查,节点没 NoReady,pod 调度上去就是没任何事件,logs 会提示没权限

2.7 无报错#

这种情况一般是运行好长时间,ceph 集群出问题了

2.7.1 现象#

说挂载成功但是一直没下一步

1
Events:
2
  Type    Reason                  Age   From                     Message
3
  ----    ------                  ----  ----                     -------
4
  Normal  SuccessfulAttachVolume  4s    attachdetach-controller  AttachVolume.Attach succeeded for volume "pvc-431074ba-ce3f-4f8d-9f71-04e958695176"
5
[root@1 cephrbd]# kubectl get pod
6
NAME      READY   STATUS              RESTARTS   AGE
7
rbd-pod   0/1     ContainerCreating   0          10s

2.7.2 查看 ceph 集群#

我们 ceph 集群出问题了,所以会这样

1
ceph status
2
  cluster:
3
    id:     f801d435-d991-4b61-9a0f-7face6a1adab
4
    health: HEALTH_WARN
5
            1 osds down
6
            1 host (1 osds) down
7

8
  services:
9
    mon: 3 daemons, quorum a,b,c (age 2d)
10
    mgr: a(active, since 2d)
11
    osd: 3 osds: 2 up (since 5s), 3 in (since 2d)
12

13
  data:
14
    pools:   2 pools, 33 pgs
15
    objects: 7 objects, 577 KiB
16
    usage:   66 MiB used, 600 GiB / 600 GiB avail
17
    pgs:     25 active+clean
18
             8  stale+active+clean

2.7.3 修复 ceph 集群后操作#

1
# 进入对应节点的csi-rbdplugin容器内操作
2
kubectl exec -it  -n kube-system         csi-rbdplugin-sp6k4 -c csi-rbdplugin bash
3
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
4
[root@ /]# lsblk
5
NAME                        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
6
loop0                         7:0    0    20K  1 loop
7
loop1                         7:1    0  89.1M  1 loop
8
loop2                         7:2    0  89.1M  1 loop
9
loop3                         7:3    0   2.8M  1 loop
10
loop4                         7:4    0     1G  0 loop
11
sda                           8:0    0   200G  0 disk
12
|-sda1                        8:1    0   300M  0 part
13
|-sda2                        8:2    0   1.4G  0 part
14
`-sda3                        8:3    0 198.3G  0 part
15
  |-centos-root             253:0    0 192.5G  0 lvm  /var/log/ceph
16
  `-centos-swap             253:1    0     4G  0 lvm
17
sdb                           8:16   0   500G  0 disk
18
`-vol_sltekdbb7ds_01-volume 253:2    0   500G  0 lvm  /data/kubelet/pods
19
sr0                          11:0    1   470K  0 rom
20
rbd0                        252:0    0     1G  0 disk
21

22
# 当时解决问题的时候忘截图了,这节点上有n个rbd设备,卸载不在使用
23
rbd unmap /dev/rbd0

如果卸载不了,节点排水后重启机器

二, flannel#

现象: 在新 dc 添加的 node 节点 pod 里 dns 解析不了,测试命令nslookup kubernetes.default.svc.cluster.local $coredns_svc_ip详细如下: 只有异常节点 pod 通过 svc 访问出现问题

访问方式	访问地址	访问结果
正常节点宿主机	coredns_svc	yes
正常节点宿主机	coredns_pod	yes
正常节点 pod 内	coredns_svc	yes
正常节点 pod 内	coredns_pod	yes
异常节点宿主机	coredns_svc	yes
异常节点宿主机	coredns_pod	yes
异常节点 pod 内	coredns_svc	no
异常节点 pod 内	coredns_pod	yes

1
traceroute $coredns_svc
2
...
3
这部有结果,但是转发到 docker0 网卡的时候特别慢

查询后发现Site Unreachable有一样的情况

1
sudo iptables -A OUTPUT -p udp -m udp --dport 8472 -j MARK --set-xmark 0x0

后面测试 nslookup与traceroute都恢复正常

三,calico#

1 查看节点状态#

因为我们集群都是双网卡,东西流量过第二块网卡
第一块网卡是 10 网段的,第二块网卡是 172 网段的

1
calicoctl node status
2
Calico process is running.
3

4
IPv4 BGP status
5
+--------------+---------------+-------+------------+--------------------------------+
6
| PEER ADDRESS |   PEER TYPE   | STATE |   SINCE    |              INFO              |
7
+--------------+---------------+-------+------------+--------------------------------+
8
| 172.30.0.25  | node specific | start | 2023-03-14 | Connect Received: Hold timer   |
9
|              |               |       |            | expired                        |
10
+--------------+---------------+-------+------------+--------------------------------+

2 查看异常的节点#

1
calicoctl get node -o wide |grep 172.30.0.25
2
10-1-1-1   61230   172.30.0.25/16

3 查看 calico 组件状态#

发现一直为准备好

1
kubectl get pod -n kube-system -o wide |grep 10-1-1-1.ccops.com
2
calico-node-lr6s5                          0/1     Running   0          47m     10.1.1.1     10-1-1-1.ccops.com <none>           <none>

4 查看 calico-node 日志#

日志太多,所以过滤下 INFO 日志,但因为过滤没查到关键信息就不展示结果了

1
logs -f -n kube-system calico-node-lr6s5  |grep -v INFO

5 登录节点查看 kubelet 日志#

一直获取不到对等体,后来在想,是不是网络出问题了

1
tail -n 100000 kubelet.INFO|grep calico-node-lr6s5
2
# 其中最关键的
3
[INFO][254] readiness.go 88: Number of node(s) with BGP peering established = 0

5.1 这里补充下 calico 端口#

角色	服务名	需要的端口	备注
system	calico-typha	5437 tcp	管理 calico
ALL	bird	179 tcp	路由表
ALL	calico-node	9099 tcp	网络接口管理和监听、路由、ARP 管理、ACL 管理和同步、状态上报
ALL	vxlan	4789 udp	vxlan 协议端口

6 尝试测试 bird 端口#

从正常节点 telnet 其他节点没问题,但是故障节点网络就不通
发现故障所在,找网络看看第二块网卡为啥网不通了
这里主要,每个公司环境不同,正常访问第一块网卡 ip+端口就行

1
telnet 172.30.0.12 179
2
Trying 172.30.0.12...
3
Connected to 172.30.0.12.
4
Escape character is '^]'.
5
????????=.
6
 @xA.EF
7
Connection closed by foreign host.
8

9
telnet 172.30.0.25 179
10
Trying 172.30.0.25...
11
^C

四, kube-apiserver#

服务正常,能获取到 pod 信息,但是 get 返回特别慢

1 查看日志#

发现一条关键信息

1
E0804 16:18:58.100247    1704 available_controller.go:524] v1beta1.metrics.k8s.io failed with: Operation cannot be fulfilled on apiservices.apiregistration.k8s.io "v1beta1.metrics.k8s.io": the object has been modified; please apply your changes to the latest version and try again

1.1 简单粗暴解决#

自己环境可以这样搞

看到api 接口有问题,尝试删除v1beta1.metrics.k8s.io 快速测试

1
kubectl delete apiservice v1beta1.metrics.k8s.io

2 修复对应接口服务#

这里就不展示了,因为每个服务修复方式都不一样

记录kubelet问题

一, kubelet#

1 查看节点状态 NotReady#

1.1 PLEG is not healthy#

1.1.1 查看节点信息#

1.1.2 检测运行队列中的进程#

1.1.3 查看前 20 使用 CPU 比较高的进程#

1.1.4 查看前 20 使用内存比较高的进程#

1.1.5 查看有问题的进程#

1.1.6 测试 nfs 地址#

1.1.7 关闭异常进程#

1.1.8 查看 load#

2 pod 一直 ContainerCreating 状态#

2.1 查看 pod 事件#

2.2 查看节点#

2.3 查看 kubelet 日志#

2.4 检测此节点 cni#

2.5 查看 calico-node 日志#

2.6 继续查看 kubelet 日志,尝试搜索 api 相关日志#

2.6.1 尝试添加 hosts#

2.6.2 重启后 pod 创建正常#

2.7 无报错#

2.7.1 现象#

2.7.2 查看 ceph 集群#

2.7.3 修复 ceph 集群后操作#

二, flannel#

三,calico#

1 查看节点状态#

2 查看异常的节点#

3 查看 calico 组件状态#

4 查看 calico-node 日志#

5 登录节点查看 kubelet 日志#

5.1 这里补充下 calico 端口#

6 尝试测试 bird 端口#

四, kube-apiserver#

1 查看日志#

1.1 简单粗暴解决#

2 修复对应接口服务#

文章分享

评论区

音乐

文章目录