K8S集群优化的可执行优化

目录

前期环境优化

1.永久关闭交换分区

2.#加载 ip_vs 模块

3.调整内核参数

4.#使用Systemd管理的Cgroup来进行资源控制与管理

5.开机自启kubelet

6.内核参数优化方案

7.etcd优化

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

7.2.提高etcd对于对等网络流量优先级

7.3.etcd被设计用于元数据的小键值对的处理。

7.4.etcd的备份

8.kubelet优化

8.1增加并发度

8.2.配置镜像拉取超时

8.3.单节点允许运行的最大 Pod 数

9.kube-apiserver优化

9.1.配置kube-apiserver的内存

10.kube-controller-manager优化

10.1.Controller参数配置

10.2.可通过 leader election 实现高可用

10.3.限制与kube-apiserver通信的qps

11.kube-scheduler优化

12.kube-proxy优化

13.pod优化

13.1.为容器设置资源请求和限制

14.如何设置k8s节点的CPU限制

验证:

1)k8s dashboard验证

2. 使用kubectl top命令验证:在Node所在的集群上运行以下命令:


前期环境优化

1.永久关闭交换分区


sed -ri 's/.*swap.*/#&/' /etc/fstab

2.#加载 ip_vs 模块


for i in $(ls /usr/lib/modules/$(uname -r)/kernel/net/netfilter/ipvs|grep -o "^[^.]*");do echo $i; /sbin/modinfo -F filename $i >/dev/null 2>&1 && /sbin/modprobe $i;done

3.调整内核参数


cat > /etc/sysctl.d/kubernetes.conf << EOF
#开启网桥模式,可将网桥的流量传递给iptables链
net.bridge.bridge-nf-call-ip6tables=1
net.bridge.bridge-nf-call-iptables=1
#关闭ipv6协议
net.ipv6.conf.all.disable_ipv6=1
net.ipv4.ip_forward=1
EOF

//生效参数
sysctl --system 

4.#使用Systemd管理的Cgroup来进行资源控制与管理

因为相对Cgroupfs而言,Systemd限制CPU、内存等资源更加简单和成熟稳定。
#日志使用json-file格式类型存储,大小为100M,保存在/var/log/containers目录下,方便ELK等日志系统收集和管理日志。配置好这里改成500M
mkdir /etc/docker
cat > /etc/docker/daemon.json < {
  "registry-mirrors": ["https://6ijb8ubo.mirror.aliyuncs.com"],
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  }
}
EOF

systemctl daemon-reload
systemctl restart docker.service
systemctl enable docker.service     开机自启

5.开机自启kubelet


systemctl enable kubelet.service
#K8S通过kubeadm安装出来以后都是以Pod方式存在,即底层是以容器方式运行,所以kubelet必须设置开机自启

6.内核参数优化方案


cat > /etc/sysctl.d/kubernetes.conf < net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-ip6tables=1
net.ipv4.ip_forward=1
net.ipv4.tcp_tw_recycle=0
vm.swappiness=0                                    #禁止使用 swap 空间,只有当系统内存不足(OOM)时才允许使用它
vm.overcommit_memory=1                            #不检查物理内存是否够用
vm.panic_on_oom=0                                #开启 OOM
fs.inotify.max_user_instances=8192
fs.inotify.max_user_watches=1048576
fs.file-max=52706963        ##指定最大文件句柄数
fs.nr_open=52706963        #最大打数                    
net.ipv6.conf.all.disable_ipv6=1
net.netfilter.nf_conntrack_max=2310720
EOF

补充:(#gc_thresh1 提高到较大的值;此设置的作用是,如果表包含的条目少于 gc_thresh1,内核将永远不会删除(超时)过时的条目。
 
net.core.netdev_max_backlog=16384 # 每CPU网络设备积压队列长度
net.core.rmem_max = 16777216 # 所有协议类型读写的缓存区大小
net.core.wmem_max = 16777216 # 最大的TCP数据发送窗口大小
kernel.pid_max = 4194303 #最大进程数
vm.max_map_count = 262144)


7.etcd优化


7.1.增大etcd的存储限制


默认etcd空间配额大小为 2G,超过 2G 将不再写入数据。通过给etcd配置 --quota-backend-bytes 参数增大空间配额,最大支持 8G
 --quota-backend-bytes 8589934592 | header 
7.2.提高etcd对于对等网络流量优先级


如果etcd leader处理大量并发客户端请求,可能由于网络拥塞而延迟处理follower对等请求。在follower 节点上可能会产生如下的发送缓冲区错误的消息:
dropped MsgProp to 247ae21ff9436b2d since streamMsg's sending buffer is full
dropped MsgAppResp to 247ae21ff9436b2d since streamMsg's sending buffer is full

7.3.etcd被设计用于元数据的小键值对的处理。

较大的请求将工作的同时,可能会增加其他请求的延迟。默认情况下,任何请求的最大大小为1.5 MiB。这个限制可以通过–max-request-bytesetcd服务器的标志来配置。
key的历史记录压缩 ETCD 会存储多版本数据,随着写入的主键增加,历史版本将会越来越多,并且 ETCD 默认不会自动清理历史数据。数据达到 –quota-backend-bytes 设置的配额值时就无法写入数据,必须要压缩并清理历史数据才能继续写入。
--auto-compaction-mode
--auto-compaction-retention
所以,为了避免配额空间耗尽的问题,在创建集群时候建议默认开启历史版本清理功能。


7.4.etcd的备份


所有 Kubernetes 对象都存储在 etcd 上。定期备份 etcd 集群数据对于在灾难场景(例如丢失所有主节点)下恢复 Kubernetes 集群非常重要。快照文件包含所有 Kubernetes 状态和关键信息。为了保证敏感的 Kubernetes 数据的安全,可以对快照文件进行加密。 备份 etcd 集群可以通过两种方式完成: etcd 内置快照和卷快照。

内置快照
etcd 支持内置快照,因此备份 etcd 集群很容易。快照可以从使用 etcdctl snapshot save 命令的活动成员中获取,也可以通过从 etcd 数据目录复制 member/snap/db 文件,该 etcd 数据目录目前没有被 etcd 进程使用。获取快照通常不会影响成员的性能。
下面是一个示例,用于获取 $ENDPOINT 所提供的键空间的快照到文件 snapshotdb:
ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot save snapshotdb
# exit 0
 
# verify the snapshot
ETCDCTL_API=3 etcdctl --write-out=table snapshot status snapshotdb
+----------+----------+------------+------------+
|   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE |
+----------+----------+------------+------------+
| fe01cf57 |       10 |          7 | 2.1 MB     |
+----------+----------+------------+------------+


卷快照
如果 etcd 运行在支持备份的存储卷(如 Amazon Elastic Block 存储)上,则可以通过获取存储卷的快照来备份 etcd 数据。
etcd恢复
etcd 支持从 major.minor 或其他不同 patch 版本的 etcd 进程中获取的快照进行恢复。还原操作用于恢复失败的集群的数据。

在启动还原操作之前,必须有一个快照文件。它可以是来自以前备份操作的快照文件,也可以是来自剩余数据目录的快照文件。 有关从快照文件还原集群的详细信息和示例,请参阅 etcd 灾难恢复文档。

如果还原的集群的访问URL与前一个集群不同,则必须相应地重新配置Kubernetes API 服务器。在本例中,使用参数 –etcd-servers=$NEW_ETCD_CLUSTER 而不是参数–etcd-servers=$OLD_ETCD_CLUSTER 重新启动 Kubernetes API 服务器。用相应的 IP 地址替换 $NEW_ETCD_CLUSTER 和 $OLD_ETCD_CLUSTER。如果在etcd集群前面使用负载平衡,则可能需要更新负载均衡器。

如果大多数etcd成员永久失败,则认为etcd集群失败。在这种情况下,Kubernetes不能对其当前状态进行任何更改。虽然已调度的 pod 可能继续运行,但新的pod无法调度。在这种情况下,恢复etcd 集群并可能需要重新配置Kubernetes API服务器以修复问题。

注意:
如果集群中正在运行任何 API 服务器,则不应尝试还原 etcd 的实例。相反,请按照以下步骤还原 etcd:

停止 所有 kube-apiserver 实例
在所有 etcd 实例中恢复状态
重启所有 kube-apiserver 实例


8.kubelet优化

8.1增加并发度


设置 --serialize-image-pulls=false, 该选项配置串行拉取镜像,默认值时true,配置为false可以增加并发度。但是如果docker daemon 版本小于 1.9,且使用 aufs 存储则不能改动该选项。

--serialize-image-pulls=false

8.2.配置镜像拉取超时


设置--image-pull-progress-deadline=30, 配置镜像拉取超时。默认值时1分,对于大镜像拉取需要适量增大超时时间。

--image-pull-progress-deadline=30

8.3.单节点允许运行的最大 Pod 数


kubelet 单节点允许运行的最大 Pod 数:--max-pods=110(默认是 110,可以根据实际需要设置)

--max-pods=110

9.kube-apiserver优化


ApiServer参数配置
--max-mutating-requests-inflight # 单位时间内的最大修改型请求数量,默认200
--max-requests-inflight # 单位时间内的最大非修改型(读)请求数量,默认400
--watch-cache-sizes # 各类resource的watch cache,默认100,资源数量较多时需要增加

9.1.配置kube-apiserver的内存


使用--target-ram-mb配置kube-apiserver的内存,按以下公式得到一个合理的值:

--target-ram-mb=node_nums * 60


10.kube-controller-manager优化

10.1.Controller参数配置


--node-monitor-period # 检查当前node健康状态的周期间隔,默认5s

--node-monitor-grace-period # 当前node超过了这个指定周期后,即视node为不健康,进入ConditionUnknown状态,默认40s

--pod-eviction-timeout # 当node进入notReady状态后,经过这个指定时间后,会开始驱逐node上的pod,默认5m

--large-cluster-size-threshold # 判断集群是否为大集群,默认为 50,即 50 个节点以上的集群为大集群。

--unhealthy-zone-threshold:# 故障节点数比例,默认为 55%

--node-eviction-rate # 开始对node进行驱逐操作的频率,默认0.1个/s,即每10s最多驱逐某一个node上的pod,避免当master出现问题时,会有批量的node出现异常,这时候如果一次性驱逐过多的node,对master造成额外的压力

--secondary-node-eviction-rate: # 当集群规模大于large-cluster-size-threshold个node时,视为大集群, 集群中只要有55%的node不健康, 就会认为master出现了故障, 会将驱逐速率从0.1降为0.001; 如果集群规模小于large-cluster-size-threshold个node, 集群中出现55%的node不健康,就会停止驱逐。


10.2.可通过 leader election 实现高可用


kube-controller-manager可以通过 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

10.3.限制与kube-apiserver通信的qps


调大 –kube-api-qps 值:可以调整至 100,默认值为 20
调大 –kube-api-burst 值:可以调整至 150,默认值为 30
禁用不需要的 controller:kubernetes v1.14 中已有 35 个 controller,默认启动为--controllers,即启动所有 controller,可以禁用不需要的 controller
调整 controller 同步资源的周期:避免过多的资源同步导致集群资源的消耗,所有带有 --concurrent 前缀的参数


限制与kube-apiserver通信的qps,添加以下命令行参数:

--kube-api-qps=100
--kube-api-burst=150

11.kube-scheduler优化

scheduler的配置项比较少,因为调度规则已经是很明确了,不过可以自定义预选和优选策略

--kube-api-qps # 请求apiserver的最大qps,默认50


--policy-config-file # json文件,不指定时使用默认的调度预选和优选策略,可以自定义指定

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

限制与kube-apiserver通信的qps
限制与kube-apiserver通信的qps,添加以下命令行参数:

--kube-api-qps=100
--kube-api-burst=150


12.kube-proxy优化


使用 ipvs 模式 
由于 iptables 匹配时延和规则更新时延在大规模集群中呈指数增长,增加以及删除规则非常耗时,所以需要转为 ipvs,ipvs 使用 hash 表,其增加或者删除一条规则几乎不受规则基数的影响。


13.pod优化

13.1.为容器设置资源请求和限制


spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory
spec.containers[].resources.limits.ephemeral-storage
spec.containers[].resources.requests.ephemeral-storage

在k8s中,会根据pod的limit 和 requests的配置将pod划分为不同的qos类别:

- Guaranteed
- Burstable
- BestEffort

当机器可用资源不够时,kubelet会根据qos级别划分迁移驱逐pod。被驱逐的优先级:BestEffort > Burstable > Guaranteed。

使用控制器管理容器

14.如何设置k8s节点的CPU限制


k8s节点的CPU限制可以通过设置k8s调度器的参数来实现,具体步骤如下:

1)打开k8s调度器的配置文件 kube-scheduler.yaml;

2)在spec configuration parameters中找到--kube-reserved参数,并添加如下配置项: --kube-reserved cpu=1000m,memory=1Gi,ephemeral-storage=1Gi

3)修改配置参数--cpu-limit-percent的数值,将其设置为一个合理的值;

4)保存并退出文件。

这里需要注意的是,对于k8s节点的CPU调度限制的设置,需要根据实际情况进行调整,比如内存大小、容器数量、容器类型等因素。一般情况下,k8s节点的CPU调度限制默认为100%,而实际调度节点的CPU利用率一般不会超过80%左右,因此,合理的CPU限制数值应该小于80%。同时为了保证一定的CPU资源用于Node的正常运行,建议将CPU限制调低一些。


验证:


1)k8s dashboard验证

进入k8s dashboard,选择Pods - Nodes选项卡,在Nodes列表中选择需要验证的Node,在该Node的Details选项中找到Allocated Resources的CPU信息,可以看到该节点的CPU利用率是否达到了限制值。

kubectl proxy
http://localhost:8001/api/v1/nodes/your_node_name_here/proxy/ 
访问dashboard即可。

2. 使用kubectl top命令验证:在Node所在的集群上运行以下命令:

kubectl top node
该命令将返回Node的CPU和内存使用情况,以及节点的CPU利用率。

你可能感兴趣的:(K8S,容器,kubernetes,容器,云原生)