vhwwls

@lscexpress #28 哈哈哈哈 老哥说的太对了

修飞机，机场做地勤

没看出来有啥问题，Pod 占用是正常的，节点上的 Load average 高是别的原因，vmstat 看看

T490 ，i5-8265u ，实测，根本带不动。

底层是高度定制化的 KVM ，CPU 和内存当然只能是同一台机器上的，至于硬盘视情况而定，大部分情况是分布式存储上的。

每个月给火狐捐了 10 刀

@Vhc001 #6 会不会编程不敢说，也很难就在线上验证，我觉得至少是没有长期一线搬砖的，身上没有那种该有的扎实气质，讲的都是虚的，就很让人恶

楼上说的都对，这点 K8s 自己没有做，只能延长关闭 Pod 的等待期，其他的得从程序层面考量。

1 、性能是否取决于 service 这一层？
视整体架构而定。只考虑集群内部的网络性能，性能也不仅仅取决于 service 一层。service 的转发性能主要影响客户端对服务的访问这一块，这里的客户端有集群内的其他 service，以及从 Ingress 接入的外部流量。
同时，也应当考虑底层网络插件的网络模型，即跨节点的 Pod 通信模式也能影响应用的整体网络性能，例如，Flannel 的 UDP 模式在封包和解包时因为需要频繁的内核和用户态切换，性能较差。这一点可以自行验证。
总而言之，在不考虑在 Ingress 外部额外再加一层 Nginx （或者其他接入层）的情况下，集群内的整体网络性能取决于 Service 和 Pod 这两层。
2 、如果做测试的话应该要怎么测？
如果你说的测试指的是对 Pod 内的应用做压测，可以从两个维度进行；第一个是从外部直接访问 Pod，即通过 Ingress 接入的流量，即用于模拟用户访问的真实流程；第二个则是服务之间互相调用的压测，即通过服务 A 去调用服务 B，这种访问不经过 Ingress，只是在 Service 层面做互相访问。这两个维度将同时对集群内的网络性能和计算性能都做有限的压力测试，在测试时，重点关注响应延迟和 Pod 内的 CPU 负载。
3 、微服务调用集群内的中间件，微服务逻辑需要修改吗？
通常情况下不需要修改，中间件在集群内和集群外，对微服务自己来说唯一的区别只是访问地址不一样，仅此而已。
4 、vscode
我是个运维，对这块了解不多。
5 、Prometheus
拿来做监控的，在做白盒监控这块比 Zabbix 强大很多，资料看官方文档就够了。