目录

一、节点配额和内核参数调整

二、内核参数优化

2.1  内核参数详解

2.2   其他的内核参数

三、Etcd 性能优化

3.1  磁盘

3.2、etcd进程设置优先级

3.3、增大etcd的存储限制

3.4、提高etcd对于对等网络流量优先级

3.5、其他优化方案

3.6、etcd的备份

3.6.1、内置快照

3.6.2、卷快照

3.7、etcd恢复

四、镜像拉取相关配置优化

4.1、docker优化

4.1.1、配置docker daemon并行拉取镜像,以提高镜像拉取效率

4.1.2、使用local SSD或者高性能云盘作为docker容器的持久数据目录

4.1.3、预加载pause镜像

4.2、kubelet优化

4.2.1、增加并发度

4.2.2、配置镜像拉取超时

4.2.3、单节点允许运行的最大 Pod 数

五、kube-apiserver优化

5.1、高可用优化

5.2、node节点数量的优化

5.2.1、node节点数量在 1000 -- 3000

5.2.2、node节点数量大于3000

5.3、配置kube-apiserver的内存

六、kube-controller-manager优化

6.1、可通过 leader election 实现高可用

6.2、限制与kube-apiserver通信的qps

七、kube-scheduler优化

7.1、可通过 leader election 实现高可用

7.2、限制与kube-apiserver通信的qps

八、kube-proxy优化

8.1、使用 ipvs 模式 

8.2、独立部署

九、Pod优化

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

9.2、使用保护机制

9.3、使用控制器来管理容器


一、节点配额和内核参数调整

对于公有云上的 Kubernetes 集群,规模大了之后很容器碰到配额问题,需要提前在云平台上增大配额。这些需要增大的配额包括:

  • 虚拟机个数

  • vCPU 个数

  • 内网 IP 地址个数

  • 公网 IP 地址个数

  • 安全组条数

  • 路由表条数

  • 持久化存储大小

参考gce随着node节点的增加master节点的配置:

  • 1-5 nodes: n1-standard-1

  • 6-10 nodes: n1-standard-2

  • 11-100 nodes: n1-standard-4

  • 101-250 nodes: n1-standard-8

  • 251-500 nodes: n1-standard-16

  • more than 500 nodes: n1-standard-32

参考阿里云配置:

节点规模    Master规格
1-5个节点    4C8G(不建议2C4G)
6-20个节点    4C16G
21-100个节点    8C32G
100-200个节点    16C64G

增大内核选项配置 /etc/sysctl.conf:

fs.file-max=1000000
# max-file 表示系统级别的能够打开的文件句柄的数量, 一般如果遇到文件句柄达到上限时,会碰到
# "Too many open files"或者Socket/File: Can’t open so many files等错误。
# 配置arp cache 大小
net.ipv4.neigh.default.gc_thresh1=1024
# 存在于ARP高速缓存中的最少层数,如果少于这个数,垃圾收集器将不会运行。缺省值是128。
net.ipv4.neigh.default.gc_thresh2=4096
# 保存在 ARP 高速缓存中的最多的记录软限制。垃圾收集器在开始收集前,允许记录数超过这个数字 5 秒。缺省值是 512。
net.ipv4.neigh.default.gc_thresh3=8192
# 保存在 ARP 高速缓存中的最多记录的硬限制,一旦高速缓存中的数目高于此,垃圾收集器将马上运行。缺省值是1024。
# 以上三个参数,当内核维护的arp表过于庞大时候,可以考虑优化
net.netfilter.nf_conntrack_max=10485760
# 允许的最大跟踪连接条目,是在内核内存中netfilter可以同时处理的“任务”(连接跟踪条目)
net.netfilter.nf_conntrack_tcp_timeout_established=300
net.netfilter.nf_conntrack_buckets=655360
# 哈希表大小(只读)(64位系统、8G内存默认 65536,16G翻倍,如此类推)
net.core.netdev_max_backlog=10000
# 每个网络接口接收数据包的速率比内核处理这些包的速率快时,允许送到队列的数据包的最大数目。
fs.inotify.max_user_instances=524288
# 默认值: 128 指定了每一个real user ID可创建的inotify instatnces的数量上限
fs.inotify.max_user_watches=524288
# 默认值: 8192 指定了每个inotify instance相关联的watches的上限

二、内核参数优化

2.1  内核参数详解

fs.file-max=1000000
# max-file 表示系统级别的能够打开的文件句柄的数量, 一般如果遇到文件句柄达到上限时,会碰到
# "Too many open files"或者Socket/File: Can’t open so many files等错误。
# 配置arp cache 大小
net.ipv4.neigh.default.gc_thresh1=1024
# 存在于ARP高速缓存中的最少层数,如果少于这个数,垃圾收集器将不会运行。缺省值是128。
net.ipv4.neigh.default.gc_thresh2=4096
# 保存在 ARP 高速缓存中的最多的记录软限制。垃圾收集器在开始收集前,允许记录数超过这个数字 5 秒。缺省值是 512。
net.ipv4.neigh.default.gc_thresh3=8192
# 保存在 ARP 高速缓存中的最多记录的硬限制,一旦高速缓存中的数目高于此,垃圾收集器将马上运行。缺省值是1024。
# 以上三个参数,当内核维护的arp表过于庞大时候,可以考虑优化
net.netfilter.nf_conntrack_max=10485760
# 允许的最大跟踪连接条目,是在内核内存中netfilter可以同时处理的“任务”(连接跟踪条目)
net.netfilter.nf_conntrack_tcp_timeout_established=300
net.netfilter.nf_conntrack_buckets=655360
# 哈希表大小(只读)(64位系统、8G内存默认 65536,16G翻倍,如此类推)
net.core.netdev_max_backlog=10000
# 每个网络接口接收数据包的速率比内核处理这些包的速率快时,允许送到队列的数据包的最大数目。
fs.inotify.max_user_instances=524288
# 默认值: 128 指定了每一个real user ID可创建的inotify instatnces的数量上限
fs.inotify.max_user_watches=524288
# 默认值: 8192 指定了每个inotify instance相关联的watches的上限

2.2   其他的内核参数

详解:
net.ipv4.tcp_keepalive_time=600 #此参数表示TCP发送keepalive探测消息的间隔时间(秒)
net.ipv4.tcp_keepalive_intvl=30 #tcp检查间隔时间(keepalive探测包的发送间隔)
net.ipv4.tcp_keepalive_probes=10  #tcp检查次数(如果对方不予应答,探测包的发送次数)
net.ipv6.conf.all.disable_ipv6=1 #禁用IPv6,修为0为启用IPv6
net.ipv6.conf.default.disable_ipv6=1 #禁用IPv6,修为0为启用IPv6
net.ipv6.conf.lo.disable_ipv6=1 #禁用IPv6,修为0为启用IPv6
net.ipv4.neigh.default.gc_stale_time=120 #ARP缓存条目超时
net.ipv4.conf.all.rp_filter=0  #默认为1,系统会严格校验数据包的反向路径,可能导致丢包
net.ipv4.conf.default.rp_filter=0 #不开启源地址校验
net.ipv4.conf.default.arp_announce=2 #始终使用与目的IP地址对应的最佳本地IP地址作为ARP请求的源IP地址
net.ipv4.conf.lo.arp_announce=2 #始终使用与目的IP地址对应的最佳本地IP地址作为ARP请求的源IP地址
net.ipv4.conf.all.arp_announce=2 #始终使用与目的IP地址对应的最佳本地IP地址作为ARP请求的源IP地址
net.ipv4.ip_local_port_range= 45001 65000 # 定义网络连接可用作其源(本地)端口的最小和最大端口的限制,同时适用于TCP和UDP连接。
net.ipv4.ip_forward=1 # 其值为0,说明禁止进行IP转发;如果是1,则说明IP转发功能已经打开。
net.ipv4.tcp_max_tw_buckets=6000 #配置服务器 TIME_WAIT 数量
net.ipv4.tcp_syncookies=1 #此参数应该设置为1,防止SYN Flood
net.ipv4.tcp_synack_retries=2 #表示回应第二个握手包(SYN+ACK包)给客户端IP后,如果收不到第三次握手包(ACK包),进行重试的次数(默认为5)
net.bridge.bridge-nf-call-ip6tables=1 # 是否在ip6tables链中过滤IPv6包
net.bridge.bridge-nf-call-iptables=1 # 二层的网桥在转发包时也会被iptables的FORWARD规则所过滤,这样有时会出现L3层的iptables rules去过滤L2的帧的问题
net.netfilter.nf_conntrack_max=2310720 #连接跟踪表的大小,建议根据内存计算该值CONNTRACK_MAX = RAMSIZE (in bytes) / 16384 / (x / 32),并满足nf_conntrack_max=4*nf_conntrack_buckets,默认262144
 
net.ipv6.neigh.default.gc_thresh1=8192
net.ipv6.neigh.default.gc_thresh2=32768
net.ipv6.neigh.default.gc_thresh3=65536
 
#gc_thresh3 是表大小的绝对限制
#gc_thresh2 设置为等于系统的最大预期邻居条目数的值
#在这种情况下,gc_thresh3 应该设置为一个比 gc_thresh2 值高的值,例如,比 gc_thresh2 高 25%-50%,将其视为浪涌容量。
#gc_thresh1 提高到较大的值;此设置的作用是,如果表包含的条目少于 gc_thresh1,内核将永远不会删除(超时)过时的条目。
 
net.core.netdev_max_backlog=16384 # 每CPU网络设备积压队列长度
net.core.rmem_max = 16777216 # 所有协议类型读写的缓存区大小
net.core.wmem_max = 16777216 # 最大的TCP数据发送窗口大小
net.ipv4.tcp_max_syn_backlog = 8096 # 第一个积压队列长度
net.core.somaxconn = 32768 # 第二个积压队列长度
fs.inotify.max_user_instances=8192 # 表示每一个real user ID可创建的inotify instatnces的数量上限,默认128.
fs.inotify.max_user_watches=524288 # 同一用户同时可以添加的watch数目,默认8192。
fs.file-max=52706963 # 文件描述符的最大值
fs.nr_open=52706963 #设置最大微博号打开数
kernel.pid_max = 4194303 #最大进程数
net.bridge.bridge-nf-call-arptables=1 #是否在arptables的FORWARD中过滤网桥的ARP包
vm.swappiness=0 # 禁止使用 swap 空间,只有当系统 OOM 时才允许使用它
vm.overcommit_memory=1 # 不检查物理内存是否够用
vm.panic_on_oom=0 # 开启 OOM
vm.max_map_count = 262144

三、Etcd 性能优化

搭建高可用的etcd集群, 集群规模增大时可以自动增加etcd节点;

目前的解决方案是使用etcd operator来搭建etcd 集群,operator是CoreOS推出的旨在简化复杂有状态应用管理的框架,它是一个感知应用状态的控制器,通过扩展Kubernetes API来自动创建、管理和配置应用实例。

etcd operator 有如下特性:

  • ceate/destroy: 自动部署和删除 etcd 集群,不需要人额外干预配置。
  • resize:可以动态实现 etcd 集群的扩缩容。
  • backup:支持etcd集群的数据备份和集群恢复重建
  • upgrade:可以实现在升级etcd集群时不中断服务。
  • 配置etcd使用ssd固态盘存储;

决定 etcd 性能的关键因素,包括:

  • 延迟 (latency):延迟是完成操作的时间。
  • 吞吐量 (throughput):吞吐量是在某个时间期间之内完成操作的总数量。当 etcd 接收并发客户端请求时,通常平均延迟随着总体吞吐量增加而增加。

3.1  磁盘

Etcd对磁盘写入延迟非常敏感,因此对于负载较重的集群,etcd一定要使用local SSD或者高性能云盘。可以使用fio测量磁盘实际顺序 IOPS。

fio -filename=/dev/sda1 -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=4k -size=60G -numjobs=64 -runtime=10 -group_reporting -name=file

3.2、etcd进程设置优先级

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

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

3.3、增大etcd的存储限制

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

| --quota-backend-bytes 8589934592 | header |
| -------------------------------- | ------ |
|                                  |        |

3.4、提高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

可以通过提高etcd对于对等网络流量优先级来解决这些错误在 Linux 上,可以使用 tc 对对等流量进行优先级排序:

tc qdisc add dev eth0 root handle 1: prio bands 3
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip sport 2380 0xffff flowid 1:1
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip dport 2380 0xffff flowid 1:1
tc filter add dev eth0 parent 1: protocol ip prio 2 u32 match ip sport 2379 0xffff flowid 1:1
tc filter add dev eth0 parent 1: protocol ip prio 2 u32 match ip dport 2379 0xffff flowid 1:1

3.5、其他优化方案

1、内存                                                                                                                                            etcd默认的存储大小限制为2GB,可使用–quota-backend-bytes标志进行配置。建议在正常环境下使用8GB的最大大小,如果配置的值超过该值,etcd会在启动时发出警告。
 

2、请求体                                                                                                                                        etcd被设计用于元数据的小键值对的处理。较大的请求将工作的同时,可能会增加其他请求的延迟。默认情况下,任何请求的最大大小为1.5 MiB。这个限制可以通过–max-request-bytesetcd服务器的标志来配置。

3、key的历史记录压缩 ETCD 会存储多版本数据,随着写入的主键增加,历史版本将会越来越多,并且 ETCD 默认不会自动清理历史数据。数据达到 –quota-backend-bytes 设置的配额值时就无法写入数据,必须要压缩并清理历史数据才能继续写入。

--auto-compaction-mode
--auto-compaction-retention

所以,为了避免配额空间耗尽的问题,在创建集群时候建议默认开启历史版本清理功能。

  • 3.3.0 之前的版本,只能按周期 periodic 来压缩。比如设置 –auto-compaction-retention=72h,那么就会每 72 小时进行一次数据压缩。
     
  • 3.3.0 之后的版本,可以通过 –auto-compaction-mode 设置压缩模式,可以选择 revision 或者 periodic 来压缩数据,默认为 periodic。

3.6、etcd的备份

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

备份 etcd 集群可以通过两种方式完成: etcd 内置快照和卷快照

3.6.1、内置快照

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     |
+----------+----------+------------+------------+

3.6.2、卷快照

如果 etcd 运行在支持备份的存储卷(如 Amazon Elastic Block 存储)上,则可以通过获取存储卷的快照来备份 etcd 数据。

3.7、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 实例

四、镜像拉取相关配置优化

4.1、docker优化

4.1.1、配置docker daemon并行拉取镜像,以提高镜像拉取效率

配置docker daemon并行拉取镜像,以提高镜像拉取效率,在/etc/docker/daemon.json中添加以下配置:

"max-concurrent-downloads": 10

4.1.2、使用local SSD或者高性能云盘作为docker容器的持久数据目录

可以使用local SSD或者高性能云盘作为docker容器的持久数据目录,在/etc/docker/daemon.json中添加以下配置:

"data-root": "/ssd_mount_dir"

4.1.3、预加载pause镜像

启动pod时都会拉取pause镜像,为了减小拉取pause镜像网络带宽,可以每个node预加载pause镜像,在每个node节点上执行以下命令:

docker load -i /tmp/preloaded_pause_image.tar

4.2、kubelet优化

4.2.1、增加并发度

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

--serialize-image-pulls=false

4.2.2、配置镜像拉取超时

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

--image-pull-progress-deadline=30

4.2.3、单节点允许运行的最大 Pod 数

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

--max-pods=110

五、kube-apiserver优化

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

5.1、高可用优化

设置 --apiserver-count 和 --endpoint-reconciler-type,可使得多个 kube-apiserver 实例加入到 Kubernetes Service 的 endpoints 中,从而实现高可用。

--apiserver-count
--endpoint-reconciler-type

5.2、node节点数量的优化

5.2.1、node节点数量在 1000 -- 3000

设置 --max-requests-inflight 和 --max-mutating-requests-inflight,默认是 200 和 400。 节点数量在 1000 - 3000 之间时,推荐:

--max-requests-inflight=1500
--max-mutating-requests-inflight=500

5.2.2、node节点数量大于3000

node节点数量 >= 3000, 推荐设置如下配置:

--max-requests-inflight=3000
--max-mutating-requests-inflight=1000

5.3、配置kube-apiserver的内存

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

--target-ram-mb=node_nums * 60

六、kube-controller-manager优化

Controller参数配置:

  • --node-cidr-mask-size # node上的pod cidr掩码位数,默认为24位,即最多253个可用地址,视地址空间和pod数量调整。
  • --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不健康,就会停止驱逐。

6.1、可通过 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

6.2、限制与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

七、kube-scheduler优化

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

  • --kube-api-qps # 请求apiserver的最大qps,默认50
  • --policy-config-file # json文件,不指定时使用默认的调度预选和优选策略,可以自定义指定

7.1、可通过 leader election 实现高可用

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

7.2、限制与kube-apiserver通信的qps

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

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

八、kube-proxy优化

8.1、使用 ipvs 模式 

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

8.2、独立部署

kube-proxy 默认与 kubelet 同时部署在一台 node 上,可以将 kube-proxy 组件独立部署在非 k8s node 上,避免在所有 node 上都产生大量 iptables 规则。

九、Pod优化

9.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。

9.2、使用保护机制

对关键应用使用 nodeAffinity、podAffinity 和 podAntiAffinity 等保护,使其调度分散到不同的node上。比如kube-dns配置

affinity:
 podAntiAffinity:
   requiredDuringSchedulingIgnoredDuringExecution:
   - weight: 100
     labelSelector:
       matchExpressions:
       - key: k8s-app
         operator: In
         values:
         - kube-dns
     topologyKey: kubernetes.io/hostname

9.3、使用控制器来管理容器

尽量使用控制器来管理容器(如 Deployment、StatefulSet、DaemonSet、Job 等)

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐