[TOC] --- ##### **Q：测试过程中，发现经常有虚拟节点NotReady？过一会又好了？** A：经过排查，发现只有10-14主机上的有这个问题，而这几台主机上有650个Pod，其他主机是500个Pod。这些主机发现ssh上去需要很久，而且ping 127.0.0.1时会有`ping: sendmsg: Invalid argument`的报错。当调整了external集群节点的如下参数，就好了： ``` net.ipv4.neigh.default.gc_thresh1 = 512 net.ipv4.neigh.default.gc_thresh2 = 2048 net.ipv4.neigh.default.gc_thresh3 = 10240 ``` --- ##### **Q：在load测试中发现，测试结果显示成功，但Grafana中SLO这个dashboard中的API调用延时还是超过threshold？而Experimental中的API调用延时却没有超过threshold？** A：根据源码，latency_query用的windows是一分钟，也就是Experimental中，所以Experimental中没有超过threshold，测试也是成功的。 --- ##### **Q：PodStartupLatency中，Pod的启动时间是从create到watch，而在测试中我们发现调度吞吐量只有80个/秒，如果一次性创建1000个Pod，那不是要12.5秒才能把所有的Pod调度成功，那不会超过5秒的阈值吗？** A：这个可能是因为kube-controller-manager每秒钟只能创建不超过80个Pod（被kube-api-qps参数限制），所以不会有大量Pod被同时创建。 --- ##### **Q：PodStartupLatency中，我们发现500个Latency Pod中有将近100个Pod的schedule_to_run的时间超过了20秒，但所有Pod的pod_startup（create_to_watch）时间却没有超过5秒，这是为什么？** ``` "dataItems": [ ... { "data": { "Perc50": 0, "Perc90": 26426.999372, "Perc99": 26890.430573 }, "unit": "ms", "labels": { "Metric": "schedule_to_run" } }, ... { "data": { "Perc50": 1358.349293, "Perc90": 1915.898719, "Perc99": 2206.542551 }, "unit": "ms", "labels": { "Metric": "pod_startup" } } ] ``` A：通过修改clusterloader2源码打印Pod的四个阶段的时间点，我们发现有些Pod的watch的时间点比run的时间点要早 > map[test-xfs9b7-1/latency-deployment-0-755db5fb5d-bb7v7:map[create:2022-09-07 16:49:52 +0800 CST run:2022-09-07 16:50:19 +0800 CST schedule:2022-09-07 16:49:52.36205469 +0800 CST watch:2022-09-07 16:49:53.358585277 +0800 CST m=+340.455753216] test-xfs9b7-1/latency-deployment-1-5cf86787f8-q64ls:map[create:2022-09-07 16:49:52 +0800 CST run:2022-09-07 16:49:52 +0800 CST schedule:2022-09-07 16:49:52.556760051 +0800 CST watch:2022-09-07 16:49:53.615868179 +0800 CST m=+340.713036120] ... 很明显这不合理。watch的时间是clusterloader2收到Pod为Running事件时的时间点，它是以clusterloader2所在主机的时间为准，而run的时间点是hollow-node的时间，所以怀疑是该Pod所在的hollow-node的时间与clusterloader2所在主机的时间不一致。最终发现的确是这个原因，有问题的Pod都是在11主机上，该主机是后来加进来的，没有和clusterloader2主机做时间同步。 --- ##### **Q：在grafana的SLO这个dashboard中，经常看到有{resource="services", subresource="proxy", scope="resource", verbs="GET"}超过了threshold，但测试结果却是Success？**  A：在clusterloader2中，是不会统计`subresource="proxy"`的，源码如下： ``` filters = `verb!="WATCH", subresource!~"log|exec|portforward|attach|proxy"` ``` 因为上面的这些API是属于streaming API，而在SLI的定义中，是说Non-streaming API。通过clusterloader2测试时打印的日志也可以看到它的统计方式： ``` I0908 16:12:04.582486 23317 prometheus.go:109] Executing "quantile_over_time(0.99, apiserver:apiserver_request_latency_1m:histogram_quantile{verb!=\"WATCH\", subresource!~\"log|exec|portforward|attach|proxy\"}[95m])" at 2022-09-08T16:12:04+08:00 ``` --- ##### **Q：在load测试中，发现主机的网络流量特别大，发包达300MiB/s，这是为什么？**  A：这里因为某类资源的watch事件比较多，如下为service与endpoints的watch流量：  而造成这一现象的原因是，当创建一个Service对象时，apiserver需要给controller-manager发送一个事件（因为controller-manager需要根据service创建对应的Endpoints），同时apiserver还要给每个节点的kube-proxy发送一个事件（因为kube-proxy要根据service及endpoints对象更新本机的iptables或ipvs规则）。当节点规模太大的时候，创建service需要发送的event就很多。而且，当创建了一个endpoints时，apiserver还要给每个节点上的kube-proxy发送一个event。 在load测试中，6000节点时，会创建9720个service。 ##### **Q：在load测试中，为什么services与endpoints这两类资源的list操作的API调用经常超过阈值而导致测试失败？** A：我们检查了etcd的各项性能指标，目测都在正常范围内。检查apiserver中关于etcd的metrics，发现apiserver在调用etcd来list services时，99%的延时最大也就200多毫秒，应该也正常：  但是在load测试过程中，我们发现有上千个Node会变成NotReady状态：  我们发现，External集群的节点，CPU与内存的使用率已经快到100%，而且有些节点的Prometheus在压测过程中还出现停止上报数据的情况：  External节点的资源被耗尽猜测是由于这上面的hollow-pod接收了大量的apiserver发送的service与endpoints的event所造成。 当这上千个hollow-pod重启恢复正常时，就会list所有的services与endpoints。6000节点时有9720个service与9720个endpoints，`kubectl get service --all-namespaces -o yaml > service.output` 得到的service.output的文件大小有xxM，那么apiserver要发送给1000个hollow-pod，相当于要发送xx * 1000 M，约为xxG，如果Master主机为万兆网卡，那么发送完成需要的时间为 `xx/1.25` 秒。 要解决这个问题，有几种优化方法：（1）给External集群增加物理资源，保持Hollow Pod的稳定性（2）增加kubemark-master节点，比如增加至5个，减少每个kube-apiserver发送事件的数量（比如5个kube-apiserver，6000节点，那么