Kubernetes APIServer高可用与性能优化

本文主要是介绍Kubernetes APIServer高可用与性能优化，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

之前的apiserver其实讲解的差不多了，其实就是认证，鉴权，准入，以及限流。这是apiserver里面最核心的能力，当然还有一些比如watch的缓存，除了承担上面的职责之外，它还承担的了重要的角色就是保护etcd，apiserver是唯一一个可以访问etcd这样一个组件，因为我可以收敛从外面过来的请求，从apiserver同一个客户端以长连接连接到etcd里面，有效的减小etcd的压力。

同时它具有基于内存的缓存机制，有些读操作你直接到apiserver了，它其实是通过ringbuffer来实现的，如果你去读它的代码。

优化参数

kube-apiserver 推荐优化的参数如下：

--default-watch-cache-size：默认值 100；用于 List-Watch 的缓存池；建议 1000 或更多；
--delete-collection-workers：默认值 1；用于提升 namesapce 清理速度，有利于多租户场景；建议 10；
--event-ttl: 默认值 1h0m0s；用于控制保留 events 的时长；集群 events 较多时建议 30m，以避免 etcd 增长过快；
--max-mutating-requests-inflight: 默认值 200；用于 write 请求的访问频率限制；建议 800 或更高；
--max-requests-inflight: 默认值 400；用于 read 请求的访问频率限制；建议 1600 或更高；
--watch-cache-sizes: 系统根据环境启发式的设定；用于 pods/nodes/endpoints 等核心资源，其他资源参考 default-watch-cache-size 的设定； K8s v1.19 开始，该参数为动态设定，建议使用该版本。

启动APIserver示例

很多参数都是默认配置好了，很少需要自己提供一长串的apiserver的参数。

构建高可用的多副本的apiserver

高可用最常用的模式是冗余部署+负载均衡。

任何的硬件是不可靠的，内存，硬盘，网卡都会坏。所以不能相信基础架构这个层面是完全可靠的。那么我们就要为这种可能出现的过程做准备。

如果你一个节点坏了，那么我能不能多准备几个节点，然后冗余部署多部署几个节点。

apiserver也一样通过冗余部署来实现apiserver的高可用。但是apiserver本身是无状态的rest server。

apiserver要做的事情就是接受请求，然后将请求存下来，这是apiserver唯一要做的事情，所以它本身是无状态的，无状态的服务管理就会变的非常的简单，所以换容易就可以实现扩容和缩容。

说白了apiserver的高可用就是冗余部署+负载均衡。

预留充足的CPU、内存资源

随着集群中节点数量不断增多，APIServer对CPU和内存的开销也不断增大。过少的CPU资源会降低其处理效率，过少的内存资源会导致 Pod被 OOMKilled，直接导致服务不可用。在规划API Server 资源时，不能仅看当下需求，也要为未来预留充分。

如果是通过kubeadm部署的，kubelet将apiserver拉起来的，每个apiserver就被封装为pod，那么我就可以做探活的，因为apiserver里面是支持存活性探测和就绪性探测，那我要去get一个真正的url，然后根据返回的状态决定是否重启。

既然是以pod的方式运行，那么就可以做资源限额的配置，我可以限制你的cpu，限制你的资源。

在早期运行生产化集群，集群规模小，给apiserver预留的cpu memory都很小，然后跑着跑着集群规模越来越大，内存就爆了，天天oom，这个时候就需要去变更将内存扩出来。

然后跑着跑着发现集群越来越慢，因为cpu有限制，给了它很小的cpu，不能够让它高效的跑，所以这个时候要去调整cpu，所以在生产化部署的时候，要预留好集群规模未来有多大，它会使用多少cpu和内存，预留出来，这里面就不要想着省钱了，因为apiserver如此重要。

善用速率限制(RateLimit)

还要确保我的apiserver不会被oom kill掉，在确保它性能基础之上还得限流，通过inflight来保证apiserver的一个总体的并发的requests，确保它不会被压死。

然后配合APF，通过这种方式来确保我做了一个精细化的限流，初始阶段就使用默认的配置就好了，后面随着业务的变更再去做调整。

设置合适的缓存大小 `--watch-cache-sizes`

apiserver本身还是一个缓存，apiserver去get etcd对象的时候，它会有一个本地的cache，这个watch-cache本身是ring buffer。

也就是它从etcd里面拿到数据会存到自己的ringbuffer里面，只要这个ringbuffer没有满，那么所有的信息都会被缓存掉。如果ringbuffer满的话，之前存在的信息就会被覆盖掉。

所以ringbuffer就是环状的内存结构，所以设置合适的缓存大小，比如watch-cache-size，是apiserver的一个参数，通过调节这个参数来调节apiserver这边缓存有多大，你集群越大，建议设置的watch-size越大，这样的话apiserver多去拿缓存数据，那么可以有效的减少对etcd的压力，只要本地有，它就不去查了。

注意：apiserver是允许客户端忽略缓存的，比如要list一个对象，这个对象里面没有加resourceversion，这个时候客户端告诉apiserver说，我是不信任你的缓存的，我要最新数据，这个时候apiserver是穿透的，它要从etcd里面拉取最新的数据。

所以客户端尽量写resourceversion，这样有效的利用apiserver的缓存。

客户端尽量使用长连接

优先使用侦听，少用轮询，后端是分布式的存储，分布式存储支持的并发很弱，然后你又不相信我的apiserver的缓存，你要一直来list这个数据，其实我要将这个请求丢到etcd，etcd很累，它会跟不上，既然etcd和apiserver都支持长连接，支持监听机制，那么建议客户端使用监听机制来获取最新的数据，而不是一直来轮询，一直轮询就会导致我这边压力过大。

监听的话还ok，最多支持一些长连接，如果单实例支持不了那么多长连接，比如几十万，那么还可以横向扩展，通过横向扩展来分散这种并发连接的压力。

所以通过这种机制有效的减少对服务器端的压力。

这里也说明了，为什么apiserver做缓冲的作用非常的大。你想如果没有apiserver，你客户端10w个pod都要去watch某个对象的话，那么你watch的是etcd，那么etcd就需要支持那么多的并发。

如果长连接当中有apiserver这一环，那么相当于这10w个连接可能均分到10个apiserver里面去。

然后apiserver到etcd里面就是一个很少的一个并发的连接了，因为它的连接时复用的。apiserver挡在etcd和客户端之间，有效的减少了对etcd这种访问。

如何访问apiserver

不同云下面，负载均衡可能是不一样的，在内部我们通过clusterIP访问的，有时候集群的外部会配置负载均衡，给一个VIP就行了。

同一个apiserver会有不同的访问入口，一个是从负载均衡上面过来的，一个是从集群的kube-proxy过来的。

我们所有控制平面的组件希望是用同一个访问入口，要么使用负载均衡的VIP，要么使用kube-proxy提供的service的cluster IP。

假设有两个入口，一个入口通的，一个入口坏了。这样就会产生一个问题。整个集群都是自动化的，但是这些组件访问apiserver的时候，它访问的入口不一样。一半工作，一半不工作就会导致你的状态汇报不上来，那节点就宕机了，显示offline或者unknown，但是你的控制器是活的，那么就会驱逐pod，和之前说过的etcd场景就非常的类似了，我们一定要避免这种场景的发生。

所以建议访问入口用同一个。