kubernetes进阶-集群优化笔记

isekiro 收录于 Kubernetes

2023-07-23 约 1339 字预计阅读 3 分钟

kubernetes 集群优化，一些微薄的经验之谈.

基础设施

节点级别的优化，主要分 2 个层面，硬件和软件。

硬件，没什么好说，cpu、内存和磁盘IO。
软件方面，就是内核参数的优化了。
网络，硬件和软件方面都有关联，有部分内核参数涉及到网络方面的，硬件方面，也需要网络设备支持。

硬件优化

根据场景购买或使用对应级别的硬件设施即可，这种当然是节点性能越高越好，当然也需要按需选择，避免浪费，这里没有什么好说的。

内核优化

最大线程数和文件打开数。

编辑 /etc/security/limits.conf 。

1
2
3
4
5
6
7
8


root soft nofile 655350
root hard nofile 655350
root soft nproc 655350
root hard nproc 655350
* soft nofile 655350
* hard nofile 655350
* soft nproc 655350
* hard nproc 655350

内核优化，重点优化以下参数。

编辑 /etc/sysctl.conf 。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


# 容器环境下，优化这些参数可以避免 NAT 过的 TCP 连接带宽上不去。
net.netfilter.nf_conntrack_tcp_be_liberal = 1 
net.netfilter.nf_conntrack_tcp_loose = 1 
net.netfilter.nf_conntrack_max = 3200000
net.netfilter.nf_conntrack_buckets = 1600512
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30
net.netfilter.nf_conntrack_tcp_timeout_established = 1200

# tcp 队列
net.ipv4.tcp_syncookies = 1
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 8192

# 端口范围
net.ipv4.ip_local_port_range = "1024 65000"

# timewait相关优化
net.ipv4.tcp_max_tw_buckets = 50000
net.ipv4.tcp_fin_timeout = 30

# 以下三个参数是 arp 缓存的 gc 阀值
net.ipv4.neigh.default.gc_thresh1="2048"
net.ipv4.neigh.default.gc_thresh2="4096"
net.ipv4.neigh.default.gc_thresh3="8192"

# 磁盘 IO 优化
vm.dirty_background_ratio = 5
vm.dirty_expire_centisecs = 300
vm.dirty_ratio = 10
vm.dirty_writeback_centisecs = 50
vm.dirtytime_expire_seconds = 43200

# fd优化
fs.file-max=655360
fs.inotify.max_user_instances="8192"
fs.inotify.max_user_watches="524288"
# 最大线程数量
kernel.pid_max = 655350

网络

带宽，良好的网络环境可以提供稳定的网络传输性能，一般，如果是云商环境的话，不是特殊情况基本不用理会。 idc 环境的话，尽量使用千兆以上的交换机。
路由，尽量使用 Underlay 网络模式，比如 flannel ，使用 host-gw 模式，直接使用主机路由来进行跨主机数据传输，极大提高网络传输性能。再比如 calico 的 BGP 模式，不过这种需要网络设备支持才行。

集群维度

集群维护就是对 kubernetes 集群内部组件和容器的一些优化。

etcd 优化

etcd 优化在不同的时期可以有不同程度的优化，当然，如果条件允许，也可以把所有优化的点子都全部应用上（不过笔者目前还没达到比较大的集群规模，还停留在 1 阶段）。

etcd 采用本地 ssd 盘作为后端存储存储（规模小）。
etcd 需要配置单独的 etcd 集群存储 kube-apiserver 的 event （规模中以上）。
etcd 独立部署在非 kubernetes node 上（规模大）。

pod 优化

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

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

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

Guaranteed
Burstable
BestEffort

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

必要时可以使用开源的或者自己开发的控制器来清理状态异常的 pod ，防止异常状态 pod 对节点产生一些直接的影响。例如：descheduler 。

kubelet

pod 个数

最好按默认 110 个配置，因为如果单个节点配置的 pod 数量太多，容易引起 pleg 、磁盘IO压力或者 cpu 负载高等问题。
压力驱逐

kubelet 监控集群节点的 CPU、内存、磁盘空间和文件系统的 inode 等资源，根据 kubelet 启动参数中的驱逐策略配置，当这些资源中的一个或者多个达到特定的消耗水平，kubelet 可以主动地驱逐节点上一个或者多个 pod ，以回收资源，降低节点资源压力。

kubelet 的默认硬驱逐条件：
- memory.available<100Mi
- nodefs.available<10%
- imagefs.available<15%
- nodefs.inodesFree<5%（Linux 节点）

kube-proxy

使用 ipvs 模式

由于 iptables 匹配时延和规则更新时延在大规模集群中呈指数增长，增加以及删除规则非常耗时，所以需要转为 ipvs ，ipvs 使用 hash 表，其增加或者删除一条规则几乎不受规则基数的影响。iptables 以及 ipvs 详细的介绍在前面的源码章节中有分析过。

总结

目前能想到的暂时就这些，笔者的集群规模也不大，现在只是把目前遇到过的优化做一个整理和总结，以后有想到其他的，或者有新的优化场景出现，再来更新。

目录