Kubernetes各组件参数配置优化建议
kubernetes虽然默认配置下已经足够可用满足常见的中小规模场景，但是若是将各组件参数、内核参数进行适当的调整，以达到更贴合使用场景的参数值，对集群运行的稳定性、故障切换能力等方面会有不小的提升。下面介绍一下各组件生产运行常做的一些参数调整。
Kubelet参数配置
kubelet在各个组件之中，作为唯一的分布在每个节点上的daemon控制程序，应该也是需要调整参数最多的组件了，从此前的flag形式的传参，到自1.11版本起的改用专属配置文件，充分说明了其配置调整是很常用的场景，下面举几个常见的配置项，如node状态汇报频率、pod最大数量、以及生产运行非常重要的pod驱逐、资源保留等。
旧版本kubelet配置
在1.11版本之前，kubelet通过命令flag的方式指定和调整参数，例如：
--node-status-update-frequency=5s# 向apiserver刷新node状态的时间间隔，默认10s
--serialize-image-pulls=false# 是否串行拉取镜像，默认为true，false改为并行，提升拉取镜像速度
--max-pods=200# 单node运行的最大pod数量，默认110，注意调整不要超过pod CIDR的单个子网可用地址数量。
--eviction-hard=memory.available<1024Mi,nodefs.available<10%# 节点资源小于指定值时开启硬驱逐上吗的pod
资源保留配置
为防止pod使用过多的资源，从而挤占和影响了k8s控制组件(例如kubelet)、系统管理进程的正常运行，指定以下配置为这两者保留一部分的资源。与pod QOS 一样，资源保留的方式同样也是使用cgroup来做资源隔离保证。
--enforce-node-allocatable=pods,kube-reserved,system-reserved# 开启针对这几者的cgroup资源管理。
--kube-reserved-cgroup=/system.slice/kubelet.service# 指定k8s组件保留资源对应的cgroup路径
--system-reserved-cgroup=/system.slice# 指定系统组件保留资源对应的cgroup路径
–kube-reserved=cpu=1,memory=2Gi# 指定k8s组件保留1g/1c的资源
–system-reserved=cpu=1,memory=1Gi# 为系统运行保留1g/1c的资源
以上参数配置在kubelet systemd启动服务内，例如kubeadm安装的集群，kubelet启动服务一般在/etc/systemd/system/kubelet.service.d/10-kubeadm.conf路径内，配置环境变量的形式来修改启动配置，例如：
增加一个变量
Environment="RESOUCE_RESERVE_CONFIG_ARGS=--kube-reserved-cgroup=/system.slice/kubelet.service --system-reserved-cgroup=/system.slice --kube-reserved=cpu=1,memory=2Gi,ephemeral-storage=1Gi --system-reserved=cpu=1,memory=1Gi,ephemeral-storage=1Gi
# 启动命令末尾加入参数变量
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS $RESOUCE_RESERVE_CONFIG_ARGS
新版本kubelet配置
1.11及以后的版本，开始使用配置文件的形式指定kubelet配置，不再建议使用flag参数的形式。配置文件的路径在启动服务的文件里可以找到，如果使用的是kubeadm安装的，路径一般是/var/lib/kubelet/config.yaml各版本可能有些许不同。参数其实还是与上方一致，只不过abc-def式写法变成了go更推荐的驼峰式写法，这里不再对参数作解释，直接贴出配置
address: 0.0.0.0
apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
anonymous:
enabled: false
webhook:
cacheTTL: 2m0s
enabled: true
x509:
clientCAFile: /etc/kubernetes/pki/ca.crt
authorization:
mode: Webhook
webhook:
cacheAuthorizedTTL: 5m0s
cacheUnauthorizedTTL: 30s
cgroupDriver: cgroupfs
cgroupsPerQOS: true
clusterDNS:
- 10.112.0.10
clusterDomain: cluster.local
configMapAndSecretChangeDetectionStrategy: Watch
containerLogMaxFiles: 5
containerLogMaxSize: 10Mi
contentType: application/vnd.kubernetes.protobuf
cpuCFSQuota: true
cpuCFSQuotaPeriod: 100ms
cpuManagerPolicy: none
cpuManagerReconcilePeriod: 10s
enableControllerAttachDetach: true
enableDebuggingHandlers: true
# 这里添加kube-reserved, system-reserved仅作参考，官方建议不要开启
enforceNodeAllocatable:
- pods
- kube-reserved
- system-reserved
eventBurst: 10
eventRecordQPS: 5
evictionHard:
imagefs.available: 15%
# 加到1G
memory.available: 1024Mi
nodefs.available: 10%
nodefs.inodesFree: 5%
evictionPressureTransitionPeriod: 3m0s
failSwapOn: true
fileCheckFrequency: 20s
hairpinMode: promiscuous-bridge
healthzBindAddress: 127.0.0.1
healthzPort: 10248
httpCheckFrequency: 20s
imageGCHighThresholdPercent: 85
imageGCLowThresholdPercent: 80
imageMinimumGCAge: 2m0s
iptablesDropBit: 15
iptablesMasqueradeBit: 14
kind: KubeletConfiguration
kubeAPIBurst: 10
kubeAPIQPS: 5
makeIPTablesUtilChains: true
maxOpenFiles: 1000000
# 调整为200
maxPods: 200
nodeLeaseDurationSeconds: 40
nodeStatusReportFrequency: 1m0s
nodeStatusUpdateFrequency: 10s
oomScoreAdj: -999
podPidsLimit: -1
port: 10250
registryBurst: 10
registryPullQPS: 5
resolvConf: /etc/resolv.conf
rotateCertificates: true
runtimeRequestTimeout: 2m0s
serializeImagePulls: false
staticPodPath: /etc/kubernetes/manifests
streamingConnectionIdleTimeout: 4h0m0s
syncFrequency: 1m0s
volumeStatsAggPeriod: 1m0s
kubeReservedCgroup: /system.slice/kubelet.service
kubeReserved:
cpu: "1"
memory: 2Gi
systemReservedCgroup: /system.slice
官方不建议开启systemReserved，因为可能会带来某些不可控的系统关键进程的异常，这里列出仅作参考
systemReserved:
cpu: "1"
memory: 2Gi
看到网上有很多内容高度一致的文章将systemReserved和kubeReserved两者都同时开启了，其实官方不建议开启systemReserved，因为这可能会导致系统关键进程遭遇不可控的风险，说明如下：
Be extra careful while enforcing system-reserved
注：非常重要！kubelet并不会自动创建cgroup，因此，需要在启动服务前为其指定创建相应cgroup的命令,建议写入启动服务文件内，无论是传统指定flag方式，还是配置文件方式，都需要在启动服务文件内添加创建cgroup的命令，否则kubelet服务会启动失败
这里贴一个新版本的启动服务文件内容：
~# cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
# Note: This dropin only works with kubeadm and kubelet v1.11+
[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
# 下面两条命令提前创建cgroup
ExecStartPre=/bin/mkdir -p /sys/fs/cgroup/cpuset/system.slice/kubelet.service
ExecStartPre=/bin/mkdir -p /sys/fs/cgroup/hugetlb/system.slice/kubelet.service
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
修改完以上配置后，执行systemctl daemon-reload && systemctl restart kubelet重启kubelet，若无意外，kubelet重启正常后，可检验cgroup是否如期创建指定的内存限制，如下刚好是2g，说明cgroup指定已成功：
cat /sys/fs/cgroup/memory/system.slice/kubelet.service/memory.limit_in_bytes
2147483648
当然，以上的kubelet配置修改需要重启kubelet，如果你需要直接在线更新kubelet配置的话，可以参考官方的的步骤进行修改配置：
Reconfiguring the Kubelet on a Live Node in your Cluster
Controller参数配置
controller常调整的参数是针对其驱逐功能的，即在node进入离线状态后，将node置为ConditionUnknown状态，并在持续一段时间后开始依一定的次序驱逐问题node上面pod到其他node上，以尽快恢复到声明数量的ready副本数。
--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不健康，就会停止驱逐。
配置建议：
中大规模集群(500+ node)
大规模集群一般节点数较多，优势是可用性、抗风险能力强，劣势是组件之间的交互频繁，会给apiServer和etcd带来较大的压力，因此配置建议：
--node-monitor-period适当增加
--large-cluster-size-threshold适当增加
--unhealthy-zone-threshold适当减小
--pod-eviction-timeout视服务可用性保障级别适当调整
--node-eviction-rate视服务可用性保障级别适当增加
--secondary-node-eviction-rate视服务可用性保障级别适当增加
小规模集群(100- node)
小规模集群一般节点数不多，因此副本数量一般也较小，对节点中断的容忍度和容忍时间较低，因此配置建议：
--node-monitor-period不变或可适当减小
--pod-eviction-timeout大幅减小，如1m-2m，单节点故障尽快转移上面的pod
--node-eviction-rate建议减小，避免问题pod转移导致集群快速雪崩，预留防范处理时间
如果使用kubeadm部署的，修改yaml文件即可自动触发 apiserver/scheduler/controller这几个static pod的重启, 3者的yaml文件都位于：/etc/kubernetes/manifests/下，修改保存pod即会自动重启加载新配置。
另注：默认驱逐pod的优先级
根据pod的QOS保证级别，优先驱逐调度保证保障质量高级别的pod最先恢复正常：
BestEffort > Burstable > Guaranteed
ApiServer参数配置
--max-mutating-requests-inflight# 单位时间内的最大修改型请求数量，默认200
--max-requests-inflight# 单位时间内的最大非修改型(读)请求数量，默认400
--watch-cache-sizes# 各类resource的watch cache，默认100，资源数量较多时需要增加
Scheduler参数配置
scheduler的配置项比较少，因为调度规则已经是很明确了，不过可以自定义预选和优选策略。
--kube-api-qps# 请求apiserver的最大qps，默认50
--policy-config-file# json文件，不指定时使用默认的调度预选和优选策略，可以自定义指定，样例参考：scheduler-policy-config.json
调度策略分为预选和优选两个步骤，建议对其过程或源码有一定了解后，再做策略调整，调度过程可以参考我的源码笔记：
《Kubernetes Source Code Note》
调度策略的调整要与自身的环境结合，默认的优选策略中，每一项计算纬度的权重默认几乎都是1，在我的环境中，比较重视资源平均利用率以及服务副本的高可用性，因此，将SelectorSpreadPriority和BalancedResourceAllocation调高。下面是我的json文件：
scheduler-policy-config.json
{
"apiVersion": "v1",
"kind": "Policy",
"predicates": [
{"name": "NoVolumeZoneConflict"},
{"name": "MaxEBSVolumeCount"},
{"name": "MaxGCEPDVolumeCount"},
{"name": "MaxAzureDiskVolumeCount"},
{"name": "MatchInterPodAffinity"},
{"name": "NoDiskConflict"},
{"name": "GeneralPredicates"},
{"name": "PodToleratesNodeTaints"},
// 下面三项在v1.12及之后的版本下需要删除掉，这是一个bug，删掉不影响正常工作。
// 参考：https://github.com/kubernetes/kops/issues/7740
{"name": "CheckNodeMemoryPressure"},
{"name": "CheckNodeDiskPressure"},
{"name": "CheckNodeCondition"},
{
"argument": {
"serviceAffinity": {
"labels": [
"region"
]
}
},
"name": "Region"
}
],
"priorities": [
{
"name": "SelectorSpreadPriority",
"weight": 3
},
{
"name": "BalancedResourceAllocation",
"weight": 3
},
{
"name": "InterPodAffinityPriority",
"weight": 1
},
{
"name": "LeastRequestedPriority",
"weight": 1
},
{
"name": "NodePreferAvoidPodsPriority",
"weight": 10000
},
{
"name": "NodeAffinityPriority",
"weight": 1
},
{
"name": "TaintTolerationPriority",
"weight": 1
},
{
"argument": {
"serviceAntiAffinity": {
"label": "zone"
}
},
"name": "Zone",
"weight": 2
}
]
}
注意
指定policy配置启动scheduler后，会完全覆盖默认注册的所有调度策略，因此，即使是无需改动的策略纬度，必须完全显示的在policy json中写出来，如果不写出，scheduler重启后该项纬度不再使用。
配置完成后，修改scheduler的启动参数，指定此json文件，同时，最好将此文件使用configMap形式或其他形式持久化挂载。
内核参数配置
fs.file-max=1000000
# max-file 表示系统级别的能够打开的文件句柄的数量
# 配置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
# 每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目。
关于conntrack的详细说明：https://testerhome.com/topics/7509
fs.inotify.max_user_instances=524288
# 默认值: 128 指定了每一个real user ID可创建的inotify instatnces的数量上限
fs.inotify.max_user_watches=524288
# 默认值: 8192 指定了每个inotify instance相关联的watches的上限
————————————————
版权声明：本文为CSDN博主「ywq935」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/ywq935/article/details/103124541
