9 - 最佳实践(持续更新)
2、磁盘IO优先级
由于etcd必须将数据持久保存到磁盘日志文件中,因此来自其他进程的磁盘活动可能会导致增加,结果可能会导致etcd请求超时和临时leader
丢失。当给定高磁盘优先级时,etcd服务可以稳定地与这些进程一起运行。
在Linux上,etcd的磁盘优先级可以配置为ionice:
默认ETCD空间配额大小为2G,超过2G将不再写入数据。通过给ETCD配置—quota-backend-bytes
参数增大空间配额,最大支持8G。
RKE或者Rancher UI自定义部署集群的时候,在yaml文件中指定以下参数
services:
etcd:
# 开启自动备份
## rke版本大于等于0.2.x或rancher版本大于等于2.2.0时使用
backup_config:
enabled: true
retention: 6
## rke版本小于0.2.x或rancher版本小于2.2.0时使用
snapshot: true
creation: 5m0s
retention: 24h
# 修改空间配额为$((4*1024*1024*1024)),默认2G,最大8G
extra_args:
quota-backend-bytes: '4294967296'
auto-compaction-retention: 240 #(单位小时)
- 磁盘碎片整理通过对历史数据压缩后,后端数据库可能会出现内部碎片。内部碎片是指空闲状态的,能被后端使用但是仍然消耗存储空间,碎片整理过程将此存储空间释放回文件系统。
要对etcd进行碎片整理,需手动在etcd容器中执行以下命令:
etcdctl defrag
Finished defragmenting etcd member[127.0.0.1:2379]
4、网络延迟
可以通过在客户端提高etcd对等网络流量优先级来解决这些错误。在Linux上,可以使用流量控制机制对对等流量进行优先级排序:
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 2739 0xffff flowid 1:1
net.ipv4.neigh.default.gc_thresh1=<value1>
net.ipv4.neigh.default.gc_thresh2=<value2>
net.ipv4.neigh.default.gc_thresh3=<value3>
根据主机资源大小来调整
<value>
值.
接着执行sysctl -p
1、Docker镜像下载最大并发数
通过配置镜像上传\下载并发数max-concurrent-downloads,max-concurrent-uploads
,缩短镜像上传\下载的时间。
2、配置镜像加速地址
通过配置镜像加速地址registry-mirrors
,可以很大程度提高镜像下载速度。
OverlayFS是一个新一代的联合文件系统,类似于AUFS,但速度更快,实现更简单。Docker为OverlayFS提供了两个存储驱动程序:旧版的overlay,新版的(更稳定)。
4、配置日志文件大小
容器中会产生大量日志文件,很容器占满磁盘空间。通过设置日志文件大小,可以有效控制日志文件对磁盘的占用量。例如:
5、开启WARNING: No swap limit support,WARNING: No memory limit support
支持
对于Ubuntu\Debian系统,执行命令时能看到警告WARNING: No swap limit support或者WARNING: No memory limit support
。因为Ubuntu\Debian系统默认关闭了swap account或者
功能,这样会导致设置容器内存或者swap资源限制不生效,解决方法。
6、综合配置
kube-apiserver
services:
kube-api:
extra_args:
services:
kube-controller:
extra_args:
# 控制器定时与节点通信以检查通信是否正常,周期默认5s
node-monitor-period: '5s'
# 当节点通信失败后,再等一段时间kubernetes判定节点为notready状态。
## 这个时间段必须是kubelet的nodeStatusUpdateFrequency(默认10s)的N倍,
## 其中N表示允许kubelet同步节点状态的重试次数,默认40s。
node-monitor-grace-period: '20s'
# 再持续通信失败一段时间后,kubernetes判定节点为unhealthy状态,默认1m0s。
node-startup-grace-period: '30s'
# 再持续失联一段时间,kubernetes开始迁移失联节点的Pod,默认5m0s。