kube-api 重启的问题

最近在搞节点替换，目前只替换了一个节点，替换之后，过了一天发现 kube-api 的稳定性不太一致

image.png

可以看到master-1 稳的一匹，根本没有重启，而master-2 master-3 重启了好多次，但是看log，根本看不到ERR log

image.png

可以看到内存资源还是比较空闲的

image.png image.png image.png image.png

可以看到iostat显示出了wait 指标，其他指标没有数量级的差距，所以先查下磁盘的io指标

image.png

可以看到磁盘的读写wait 差距差了8-10倍。

然后再查看下读写请求的压力是否基本一致，
基于 pidstat -d 1

[root@pro-k8s-master-1 ~]# pidstat -d 1
Linux 3.10.0-1127.el7.x86_64 (pro-k8s-master-1)         09/28/2022      _x86_64_        (4 CPU)


Average:      UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
Average:        0       595      0.00     11.06      0.00  bash
Average:        0       908      0.00      2.15      0.00  kubectl
Average:        0      1122      0.00      0.31      0.15  rsyslogd
Average:        0      1502      0.00      7.99      3.99  containerd-shim
Average:        0      2552      1.23     99.85      3.07  containerd-shim
Average:        0      2796      0.00      2.00      0.00  ovsdb-server
Average:        0      2914      0.00    318.74      0.00  ovsdb-server
Average:        0      3427      0.00      3.99      3.99  containerd-shim
Average:        0      3692      0.00      6.61      5.07  containerd-shim
Average:        0      3760      0.00      0.15      0.00  ovsdb-server
Average:        0      7892      0.00      1.23      0.92  containerd-shim
Average:        0      7904      0.00      1.23      0.77  containerd-shim
Average:        0      7954      0.00      4.92      0.00  filebeat
Average:        0     12886      0.00      0.77      0.00  dockerd
Average:        0     24840      0.00    250.38      0.00  etcd



[root@pro-k8s-master-2 ~]# pidstat -d 1
Average:      UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
Average:        0      4809      0.00    100.00      4.55  containerd-shim
Average:        0      4969      0.00      2.27      0.00  ovsdb-server
Average:        0      7139      0.00    347.73      0.00  ovsdb-server
Average:        0     16797      0.00      1.70      0.00  dockerd
Average:        0     17399      0.00     10.23      0.00  bash
Average:        0     22026      0.00      3.41      3.41  containerd-shim
Average:    10001     26936      0.00     30.68      0.00  metrics-sidecar
Average:        0     27498      0.00      1.70      1.14  containerd-shim
Average:        0     27524      0.00      1.70      1.14  containerd-shim
Average:        0     28963      0.00    252.84      0.00  etcd
Average:        0     29211      0.00      6.82      3.41  containerd-shim
Average:        0     29652      0.00      4.55      3.41  containerd-shim
Average:        0     29760      0.00      0.57      0.00  ovsdb-server

小结: 可以看到请求量基本是一致的，应该是磁盘性能不同是导致cpu负载的根本原因。
磁盘性能导致cpu wait指标消耗了太多的cpu，导致上下文切换较高，从而导致kube-api无法获取足够的资源保持服务。

这个加cpu和内存资源也可以缓解，但从磁盘解决事半功倍。 用好的ssd 4核8G就足以维持。

之前3节点只有master-1是ssd，当把master-3也变成ssd之后，
###################### 目前只有master-2 是ceph rbd ，但是可以看到master-2的负载也降低了一半
还有一个因素是 我将ovn 的两个raft协议的数据库全部迁移到了master-3，对比一下top

####### master-1

image.png

可以看到负载非常稳定 4核只用了1核

####### master-2

image.png

可以看到master-2的cpu 负载也从之前的7-8 变成了只有2-3

master-3

image.png

可以看到目前master-3 cpu 负载在3-4
io wait 在1-4，那么结论大概可以确定了

结论：

1. etcd对磁盘的占用，并没有ovn 的sb db 和 nbdb 的总和更高。
2. 如果etcd 主节点和ovn sb db 以及 nbdb的主节点重合，那么这三个数据库的compact操作 足以将cpu负载消耗到7-8个cpu的程度，而cpu的核数只有4个。 而且io wai的值 在三个数据库争抢的情况下会变的很难看，今天有观测到master-2 io 延迟高达80ms+

可以看到kube-ovn-controller 1.7 对内存的占用 可以拍到前三，对cpu的占用可以排进前4

1. ovn-controller
2. kube-apiserver
3. etcd
4. kube-controller

        |            |-containerd-shim-+-monitor---ovsdb-server
        |            |                 |-monitor---ovs-vswitchd---5*[{ovs-vswitchd}]
        |            |                 |-monitor---ovn-controller---3*[{ovn-controller}]
        |            |                 |-start-ovs.sh---tail
        |            |                 `-10*[{containerd-shim}]

那么其实  kube-ovn-cni + kube-ovn-controller 就是内存和cpu耗费的前排服务，数一数二

可以看到kebe-ovn-central 1.7 应该能吃掉大概两个cpu

image.png image.png

最终结论：

如果控制面部署了kube-ovn-controller 和 kube-ovn-central 和 etcd，以及k8s的控制面组件，
那么至少要有8C16G的内存，持久化存储最好采用ssd或者高性能hdd