1. 课程导论：K8s节点优化的必要性、性能瓶颈分析、优化目标与衡量指标
1.1 为什么必须优化K8s节点？
在生产环境中，Kubernetes集群的稳定性与性能不仅取决于控制面组件（API Server、Scheduler、Controller Manager）的调度能力，更取决于每个工作节点（Node）的操作系统底层配置与资源容量规划。未经优化的节点往往在以下场景暴露问题：
- Pod启动失败或驱逐：内核参数（如
net.ipv4.ip_local_port_range、vm.max_map_count）不足，导致高并发Pod无法分配端口或内存映射。 - 网络延迟与丢包：默认的
net.core.somaxconn、net.ipv4.tcp_tw_reuse等参数未调优，造成TCP连接队列溢出。 - 磁盘I/O抖动：未配置
vm.dirty_ratio与vm.dirty_background_ratio，导致写缓存刷盘时瞬间卡顿。 - 资源碎片与超分：节点可分配资源（Allocatable）计算不准确，引发Pod调度后OOM或CPU Throttling。
核心认知：K8s节点优化不是“锦上添花”，而是生产集群从“可用”走向“高可用、高性能”的必经之路。一次内核参数调优，往往能消除集群中70%以上的偶发故障。
1.2 性能瓶颈全景分析
节点性能瓶颈通常分布在四个维度。下表总结了各维度的典型问题与根因：
| 维度 | 典型瓶颈现象 | 根因（OS/K8s层面） |
|---|---|---|
| CPU | Pod CPU Throttling、调度延迟 | CFS配额周期过短、NUMA亲和性未配置、内核抢占延迟 |
| 内存 | OOM Killer频繁、Page Cache抖动 | vm.overcommit_memory=0、cgroup memory limit未对齐、透明大页(THP)碎片 |
| 网络 | 连接超时、吞吐量低、端口耗尽 | ip_local_port_range过窄、netdev_budget太小、conntrack表满 |
| 存储 | Pod启动慢、日志写延迟高 | dirty_ratio过高、磁盘调度器未切换、文件系统inode耗尽 |
下图展示了节点内各组件之间的瓶颈传导关系：
1.3 优化目标体系
节点优化应遵循“可量化、可验证、可回滚”的原则。我们将优化目标拆解为三个层级：
- 稳定性目标：消除内核参数导致的Pod驱逐、OOM、连接拒绝等故障，确保节点在极端负载下不崩溃。
- 性能目标：降低Pod启动延迟、网络P99延迟、磁盘I/O等待时间，提升资源利用率。
- 容量目标：精确计算节点可分配资源（Allocatable），避免超分导致资源争抢，同时最大化Pod密度。
优化原则：先稳定，后性能，再容量。不要为了提升Pod密度而牺牲节点稳定性。
1.4 核心衡量指标
以下指标用于量化优化效果，建议在优化前后持续采集并对比：
| 指标类别 | 具体指标 | 优化目标值（参考） | 采集工具 |
|---|---|---|---|
| 稳定性 | Pod OOM次数 / 天 | 0 | kubectl top / cAdvisor |
| 稳定性 | 节点 conntrack 表使用率 | < 80% | conntrack -S |
| 性能 | Pod 就绪延迟（P99） | < 5s | kubelet 事件 / Prometheus |
| 性能 | TCP 连接建立延迟（P99） | < 10ms | ss / tcpdump |
| 容量 | 节点可分配 Pod 数量 | ≥ 110（默认） | kubectl describe node |
| 容量 | CPU / 内存超分比 | CPU ≤ 4:1, 内存 ≤ 1.5:1 | kubelet 指标 / Node Exporter |
1.5 优化工作流概览
本课程将按照以下流程逐步展开节点优化实践：
重要提醒：所有优化操作必须在测试环境验证通过后，再灰度上线生产节点。每次变更前备份
/etc/sysctl.conf 及 /etc/default/grub，确保可快速回滚。