目录

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

二、内核参数优化

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 等)

# 运维 # kubernetes # 容器
Logo
K8S/Kubernetes

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

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 |  韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号​前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。​长夜有穷，真水无香。领略过了 K8s“身在江

avatar K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub

avatar K8S/Kubernetes

k8s 火了！

2020，上云之年，产品云端化成为一种趋势。在一线城市，很多公司都已经构建了自己的私有云环境，比如阿里云、网易云、华为云等。而Kubernetes 作为基于容器编排领域的王者，具备扩展...

avatar K8S/Kubernetes