CentOS上Kubernetes的最佳性能调优参数是什么

CentOS 上 Kubernetes 性能调优参数清单

一 系统内核与资源基线

• 文件句柄与 inotify
  • fs.file-max=1000000
  • fs.inotify.max_user_instances=524288
  • fs.inotify.max_user_watches=524288
• 网络与连接跟踪
  • net.ipv4.ip_forward=1
  • net.core.netdev_max_backlog=10000
  • net.ipv4.neigh.default.gc_thresh1=1024；gc_thresh2=4096；gc_thresh3=8192
  • net.netfilter.nf_conntrack_max=10485760
  • net.netfilter.nf_conntrack_tcp_timeout_established=300
  • net.netfilter.nf_conntrack_buckets=655360
• 虚拟内存与 swappiness
  • vm.swappiness=0（或更低，如1；避免交换抖动）
  • vm.max_map_count=655360
  • vm.overcommit_memory=1（允许适度超配，提升内存紧张场景稳定性）
• 容器与日志
  • 容器运行时建议启用 systemd cgroup 驱动（如 Docker/containerd 配置为 systemd）
  • 日志轮转：日志驱动 json-file，单文件最大 100Mi
• 存储 I/O 调度（SSD/NVMe 推荐）
  • 调度器：noop 或 deadline（减少调度开销，适配低时延设备）
• 安全基线（生产慎用）
  • 关闭 swap（生产环境强烈建议）
  • SELinux 可设为 Permissive 或按策略精细化放行（不建议直接 disabled，需评估合规）

二 Kubernetes 组件与 kubelet 关键参数

• kubelet
  • 资源配置：为 kubelet 设置合理的 requests/limits（保证控制面稳定）
  • 节点容量控制：二选一或组合使用
    • podsPerCore：按核数限制每节点 Pod 数（示例 10），注意每个 Pod 至少包含 pause 容器，实际容器数≈2×Pod 数
    • maxPods：固定上限（示例 250），两者取较小值生效
  • 系统/ kube 预留：避免系统/容器争用
    • kube-reserved：cpu=500m, memory=512Mi, ephemeral-storage=1Gi
    • system-reserved：cpu=1000m, memory=1024Mi, ephemeral-storage=1Gi
  • 镜像与磁盘 GC：image-gc-high-threshold=70；image-gc-low-threshold=60
  • CPU 管理策略：–cpu-manager-policy=static（延迟敏感/绑核场景），配合 --cpu-manager-reconcile-period 调整对账周期
• kube-proxy
  • 模式：大规模/高并发优先 ipvs（连接调度更高效），中小规模或兼容性优先 iptables
  • 连接跟踪：按需提升 --conntrack-max 与 --conntrack-ttl，缓解 conntrack 瓶颈
• API Server
  • 并发控制：–max-requests-inflight 与 --max-mutating-requests-inflight
    • 节点数 ≥ 3000：3000 / 1000
    • 节点数 1000–3000：1500 / 500
• Controller Manager / Scheduler
  • 高可用：–leader-elect=true；–leader-elect-lease-duration=15s；–leader-elect-renew-deadline=10s；–leader-elect-retry-period=2s
  • 限流：–kube-api-qps=100；–kube-api-burst=150
• Pod 与 QoS
  • 为所有容器设置 resources.requests/limits（CPU/内存/ephemeral-storage），避免 BestEffort 引发资源争用与不可预期驱逐
  • 关键业务使用 node/pod Affinity/AntiAffinity 分散与亲和调度，提升稳定性与性能

三 网络与存储优化

• CNI 与网络策略
  • 选择高性能 CNI（如 Calico/Cilium/Flannel），结合网络策略减少非必要流量
  • 合理设置 MTU，避免封装/隧道带来的分片与抖动
• 服务暴露与 conntrack 压力
  • 高并发下优先 LoadBalancer/Ingress 承载南北向流量，减少大量 NodePort 导致的五元组转换与 conntrack 压力
• 存储
  • 使用 SSD/NVMe、本地盘或高性能分布式存储（如 Ceph/GlusterFS/云盘），为时延敏感型应用配置 SSD 存储类
  • 为 PV/PVC 设置合理容量与访问模式，避免资源浪费与调度抖动

四 规模与高延迟环境建议

• Master 节点规格与节点规模（经验基线，按实际负载与 API/etcd 指标调整）
  • 1–5 节点：4C8G
  • 6–20 节点：4C16G
  • 21–100 节点：8C32G
  • 100–200 节点：16C64G
• 高延迟/边缘网络
  • 适当放宽节点状态上报与控制面容忍时间，避免误驱逐与调度震荡（如调大 node-monitor-grace-period、default-not-ready-toleration-seconds、default-unreachable-toleration-seconds；具体值以平台提供的延迟配置集为准）
• 监控与容量规划
  • 建立以 Prometheus/Grafana 为核心的监控告警，关注 APIServer 延迟/错误、etcd 延迟/leader 切换、P99 网络时延、磁盘 IOPS/延迟、节点 CPU Throttling、内存与 conntrack 使用率
  • 结合 HPA/VPA 与 Cluster Autoscaler 做弹性与效率平衡

五 落地与回退建议

• 变更顺序：先调系统内核与资源预留 → 再调 kubelet → 其后调 kube-proxy/APIServer/控制面组件 → 最后按业务验证网络与存储
• 灰度与压测：单节点/单机架灰度，使用压测工具（如 wrk/ab、k6、netperf/iperf）验证 P50/P95/P99 与错误率
• 观测与回退：任何参数调整需记录基线指标；出现异常优先回退至上一个稳定版本，再分维度逐步优化
• 风险提示：生产环境谨慎关闭 SELinux/防火墙；调大 conntrack/内核参数需评估内存占用；修改 kubelet 容量参数可能触发节点重启与 Pod 重调度

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！