Kubernetes各组件参数配置优化建议

最新推荐文章于 2024-09-05 17:12:36 发布

ywq935

最新推荐文章于 2024-09-05 17:12:36 发布

阅读量4.4k

点赞数 4

分类专栏： kubernetes那些事儿 kubernetes Linux

本文链接：https://blog.csdn.net/ywq935/article/details/103124541

版权

kubernetes 同时被 3 个专栏收录

53 篇文章 24 订阅

订阅专栏

kubernetes那些事儿

22 篇文章 14 订阅

订阅专栏

Linux

8 篇文章 1 订阅

订阅专栏

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的上限