1. 开篇：为什么节点组件如此重要？

在Kubernetes集群中，Node节点像是辛勤的码头工人，负责执行具体的"货物装卸"（Pod调度和运行）任务。Kubelet和Kube-proxy就像是工人的左右手：一个专注于管理集装箱（Pod）的装卸和检查，另一个则负责港口的交通指挥（网络规则）。本文将用生活化的语言，结合真实生产案例，深入分析这两个组件的原理与故障排查方法。

2. Kubelet的核心功能

Kubelet是每个节点上的"超级管理员"，直接与容器运行时（如Docker或containerd）交互。它的核心职责包括：

  • Pod生命周期管理：按控制器指令创建/销毁容器
  • 资源监控与上报：定期向API Server汇报节点状态
  • 健康检查：执行Liveness/Readiness探针
  • 镜像管理：下载和清理容器镜像

示例场景：Pod创建失败排查 假设我们使用Kubernetes v1.24 + containerd运行时，遇到Pod状态卡在ContainerCreating：

kubectl describe pod web-server-5df87f76d-8qpzv

# 事件输出节选：
Events:
  Warning  FailedCreatePodSandBox  2s (x4 over 5s)  kubelet 
  Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network: 
  plugin type="calico" failed: stat /var/lib/calico/nodename: no such file or directory

# 检查Kubelet日志（journalctl查看）
journalctl -u kubelet --since "5 minutes ago" | grep -i calico

原因分析：
Calico网络插件需要节点名称文件存在，但实际未生成。需要检查以下配置项：

# containerd配置文件位置
/etc/containerd/config.toml

# 检查是否启用CNI插件
[plugins."io.containerd.grpc.v1.cri".cni]
  bin_dir = "/opt/cni/bin"
  conf_dir = "/etc/cni/net.d"

3. Kube-proxy的工作原理

Kube-proxy是集群的"交通协管员"，通过维护iptables/ipvs规则实现服务发现和负载均衡。核心机制包括：

  • Endpoint同步：监控Service与Pod的映射关系
  • 规则生成：根据服务类型（ClusterIP/NodePort）创建转发规则
  • 会话保持：通过service.spec.sessionAffinity配置

示例场景：服务无法访问问题 在Kubernetes v1.25 + iptables模式下，发现ClusterIP无法访问：

# 查看服务的Endpoints是否正常
kubectl get endpoints nginx-service

# 验证iptables规则链
iptables -t nat -L KUBE-SERVICES | grep 10.96.88.88

# 如果无对应规则，检查kube-proxy日志
kubectl logs -n kube-system kube-proxy-abcde

典型错误日志：

E0821 11:00:00 sync_proxy_rules.go:786] Failed to execute iptables-restore: 
exit status 1 (iptables-restore: line 42 failed)

解决方案：

  1. 检查/var/lib/kube-proxy目录下的配置文件
  2. 增加iptables锁等待时间：
# kube-proxy配置示例
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
iptables:
  minSyncPeriod: "15s"
  syncPeriod: "30s"
  masqueradeAll: false

4. 深度排查工具箱

Kubelet调试三板斧：

# 查看节点资源容量
kubectl describe node worker-01 | grep -i capacity

# 强制删除卡住Pod（危险操作）
kubectl delete pod stuck-pod --force --grace-period=0

# 采集实时指标
kubectl get --raw /api/v1/nodes/worker-01/proxy/metrics/cadvisor

Kube-proxy网络诊断：

# 查看当前代理模式
kubectl -n kube-system get cm kube-proxy -o yaml | grep mode

# IPVS模式诊断命令
ipvsadm -Ln | grep -A 10 10.96.0.1

# 模拟DNS解析测试
kubectl run -it --rm debug --image=alpine:3.16 -- nslookup kubernetes.default

5. 组件选型与技术折衷

Kube-proxy模式对比：

特性 iptables模式 IPVS模式
性能 万级规则后急剧下降 百万级规则线性扩展
LB算法 随机 支持RR、LC等算法
规则复杂度 链式嵌套难维护 扁平结构易读
资源消耗 内存占用较低 CPU占用更优

生产经验法则：

  • 50节点以下集群：iptables更轻量
  • 高流量服务集群：优先选择IPVS
  • 云厂商托管服务：注意与CNI插件的兼容性

6. 应用场景与避坑指南

典型应用场景：

  1. 自动化修复场景（Kubelet）：
# 当容器内存超限时自动重启
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: web
    livenessProbe:
      exec:
        command: ["check_health.sh"]
    resources:
      limits:
        memory: "512Mi"
  1. 会话保持场景（Kube-proxy）：
apiVersion: v1
kind: Service
spec:
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 3600

防踩坑清单：

  • 始终保证kubelet证书轮换配置正确（RotateKubeletClientCertificate）
  • 禁用Swap分区可能引发未知OOM Killer行为
  • IPVS模式下需确保内核加载ip_vs相关模块
  • 监控kubelet的PLEG（Pod生命周期事件生成器）延迟

7. 总结与最佳实践

通过三个典型场景的分析可以看出：

  • Kubelet问题多与容器运行时、资源配额相关
  • Kube-proxy故障常源于网络插件兼容性
  • 定期检查组件指标（如kubelet的runtime_operations_errors）

推荐监控指标：

kubelet_runtime_operations_errors_total{operation_type="create_container"}
kubeproxy_sync_proxy_rules_duration_seconds_bucket

最终生存法则：
永远为kubelet预留至少20%的系统资源，并定期执行滚动重启！