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

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,在我的环境中,比较重视资源平均利用率以及服务副本的高可用性,因此,将SelectorSpreadPriorityBalancedResourceAllocation调高。下面是我的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的上限
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 技术黑板 设计师: CSDN官方博客
应支付0元
点击重新获取
扫码支付

支付成功即可阅读