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、etcd性能优化
Etcd对磁盘写入延迟非常敏感，因此对于负载较重的集群，etcd一定要使用local SSD或者高性能云盘。可以使用fio测量磁盘实际顺序 IOPS
3、docker优化
3.1、配置docker daemon并行拉取镜像，以提高镜像拉取效率，在/etc/docker/daemon.json中添加以下配置：
"max-concurrent-downloads": 10
3.2、可以使用local SSD或者高性能云盘作为docker容器的持久数据目录，在/etc/docker/daemon.json中添加以下配置：
"data-root": "/ssd_mount_dir"
3.3、启动pod时都会拉取pause镜像，为了减小拉取pause镜像网络带宽，可以每个node预加载pause镜像，在每个node节点上执行以下命令：
docker load -i /tmp/preloaded_pause_image.tar
4、kubelet优化
4.1、设置 --serialize-image-pulls=false， 该选项配置串行拉取镜像，默认值时true，配置为false可以增加并发度。但是如果docker daemon 版本小于 1.9，且使用 aufs 存储则不能改动该选项。
4.2、设置--image-pull-progress-deadline=30， 配置镜像拉取超时。默认值时1分，对于大镜像拉取需要适量增大超时时间。
4.3、kubelet 单节点允许运行的最大 Pod 数：--max-pods=110（默认是 110，可以根据实际需要设置）
5、kube-apiserver优化
5.1、设置 --apiserver-count 和 --endpoint-reconciler-type，可使得多个 kube-apiserver 实例加入到 Kubernetes Service 的 endpoints 中，从而实现高可用。
]5.2、设置 --max-requests-inflight 和 --max-mutating-requests-inflight，默认是 200 和 400。 节点数量在 1000 - 3000 之间时，推荐：
--max-requests-inflight=1500
--max-mutating-requests-inflight=500
节点数量大于 3000 时，推荐：
--max-requests-inflight=3000
--max-mutating-requests-inflight=1000
5.3、使用--target-ram-mb配置kube-apiserver的内存，按以下公式得到一个合理的值：
--target-ram-mb=node_nums * 60
6、kube-controller-manager优化
6.1、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
--kube-api-burst=150
7、kube-scheduler优化
7.1、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-api-qps=100
--kube-api-burst=150
8、pod优化
8.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。
8.2、对关键应用使用 nodeAffinity、podAffinity 和 podAntiAffinity 等保护，使其调度分散到不同的node上。比如kube-dns配置
8.3、尽量使用控制器来管理容器（如 Deployment、StatefulSet、DaemonSet、Job 等）
9、kubernetes集群数据备份
9.1、etcd数据备份