节点、pod、容器数量¶

官方标准如下：

• 不超过 5000 个节点
• 不超过 150000 个 pod
• 不超过 300000 个容器
• 每个节点不超过 100 个 pod

Master节点配置优化¶

Master节点上CPU和内存推荐配置：

kube-apiserver 优化¶

高可用

启动多个kube-apiserver实例通过外部LB做负载均衡，而LB本身也需要做高可用，所以我们用的是Keepalived+Haproxy模式，如果LB和Kube-apiserver是分离的，可以使用Keepalived+LVS，效果会更好。

控制连接数

小常识：

在Kubernetes中，"突变请求"（Mutating Requests）是指对资源进行更改的请求，例如创建、更新或删除资源。这些请求会修改集群中的状态或配置。

相对地，"非突变请求"（Non-Mutating Requests）是指不会对资源进行更改的请求，通常是读取或观察资源的请求，例如获取资源的信息或列表。

Kubernetes API Server（apiserver）区分这两种类型的请求，以便能够采取不同的处理策略和并发限制。因为突变请求对集群状态产生更直接的影响，所以通常需要更加谨慎和有限制的处理。

kube-apiserver 以下两个参数可以控制连接数:

• --max-mutating-requests-inflight ： 用于限制并发进行的突变请求的数量。 确保在任何给定时间点上并发进行的突变请求数量不超过设置的限制。这可以帮助防止对apiserver的过度负载，防止资源竞争和故障。如果设置为0表示不限制，默认值为 200。
• --max-requests-inflight ： 用于限制非突变请求的最大并发数。 如果设置为0表示不限制，默认值为 400。

如何设置参数呢？

以直接修改/etc/kubernetes/manifests/kube-apiserver.yaml，增加参数即可

• 节点数量在 1000 - 3000 之间时，推荐：

​ --max-requests-inflight=1500

​ --max-mutating-requests-inflight=500

• 节点数量大于 3000 时，推荐：

​ --max-requests-inflight=3000

​ --max-mutating-requests-inflight=1000

另外一个和内存相关的配置参数

• --target-ram-mb： 用于限制apiserver进程使用的内存量，以防止过度消耗内存资源，它的值是以兆字节（MB）为单位的整数。 比如，可以4G内存的服务器，将该参数设置为1024

kube-scheduler与kube-controller-manager优化¶

高可用

kube-controller-manager 和 kube-scheduler 是通过 leader election 实现高可用，启用时需要添加以下参数:

--leader-elect=true

--leader-elect-lease-duration=15s

--leader-elect-renew-deadline=10s

--leader-elect-resource-lock=endpoints

--leader-elect-retry-period=2s

按照我们在前面高可用部署方法部署就自动增加了--leader-elect=true

该参数需要修改/etc/kubernetes/manifests/kube-controller-manager.yaml和/etc/kubernetes/manifests/kube-scheduler.yaml

控制 QPS（Controller-manager）

与 kube-apiserver 通信的 qps 限制，推荐为：

--kube-api-qps=100

控制burst（Controller-manager）

--kube-api-burst 是 Kubernetes API Server（kube-apiserver）的一个参数，用于控制 API 请求的突发请求数。

该参数定义了 kube-apiserver 在短时间内可以处理的请求数量上限，用于应对突发的请求流量。突发请求数是在超过 --kube-api-qps 参数定义的每秒请求数限制时允许的短期爆发请求的数量。

例如，--kube-api-burst=200 表示在 --kube-api-qps 所定义的每秒请求限制之上，kube-apiserver 可以接受最多 200 个突发请求。推荐为：

--kube-api-burst=200

以上两个参数需要修改 /etc/kubernetes/manifests/kube-controller-manager.yaml

Kubelet 优化¶

• 设置 --image-pull-progress-deadline=30m： 该参数定义了这个拉取过程的超时时间。如果在超时时间内未完成镜像的拉取操作，kubelet 将终止该操作并报告失败。
• 设置 --serialize-image-pulls=false：该参数用于控制容器镜像的并发拉取行为，当设置为 true 时，kubelet 将以串行方式拉取容器镜像。这意味着每个容器将按顺序进行镜像拉取，一个接一个地执行。所以，这里设置为false，可以做到并发拉取镜像。
• 设置--max-pods=110：Kubelet 单节点允许运行的最大 Pod 数，默认是 110，可以根据实际需要设置。

Etcd优化¶

高可用部署

最好是单独拆分出来，部署成一个集群（可以使用kubeadm部署），然后在初始化时再指定外部Etcd集群即可

参考： https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/high-availability/

磁盘IO

对于Etcd使用的磁盘最好是使用SSD盘，提高磁盘的IO性能。

提高Etcd进程的IO优先级

由于 ETCD 必须将数据持久保存到磁盘日志文件中，因此来自其他进程的磁盘活动可能会导致增加写入时间，结果导致 ETCD 请求超时和临时 leader 丢失。当给定高磁盘优先级时，ETCD 服务可以稳定地与这些进程一起运行:

ionice -c2 -n0 -p $(pgrep etcd)

提高存储配额

默认 ETCD 空间配额大小为 2G，超过 2G 将不再写入数据。通过给 ETCD 配置 --quota-backend-bytes 参数增大空间配额，最大支持 8G。

vi /etc/kubernetes/manifests/etcd.yaml增加参数

分离 events 存储

集群规模大的情况下，集群中包含大量节点和服务，会产生大量的 event，这些 event 将会对 etcd 造成巨大压力并占用大量 etcd 存储空间，为了在大规模集群下提高性能，可以将 events 存储在单独的 ETCD 集群中。

配置 kube-apiserver：

--etcd-servers="http://etcd1:2379,http://etcd2:2379,http://etcd3:2379" --etcd-servers-overrides="/events#http://etcd4:2379,http://etcd5:2379,http://etcd6:2379"