k8s-node组件介绍
-
- 一、节点组件概述
- 二、kubelet
-
- [2.1 定义与作用](#2.1 定义与作用)
- [2.2 部署方式](#2.2 部署方式)
- [2.3 核心配置（/var/lib/kubelet/config.yaml）](#2.3 核心配置（/var/lib/kubelet/config.yaml）)
- 三、kube-proxy
-
- [3.1 定义与作用](#3.1 定义与作用)
- [3.2 部署方式](#3.2 部署方式)
- [3.3 工作模式](#3.3 工作模式)
- 四、集群通信架构
-
- [4.1 通信协议](#4.1 通信协议)
- [4.2 架构全景图](#4.2 架构全景图)
- [4.3 关键架构特征](#4.3 关键架构特征)
- 五、第三方控制器与扩展机制
-
- [5.1 需求背景](#5.1 需求背景)
- [5.2 扩展方式](#5.2 扩展方式)
- [5.3 架构位置](#5.3 架构位置)
- 六、节点组件故障排查
-
- [6.1 kubelet 常见问题](#6.1 kubelet 常见问题)
- [6.2 kube-proxy 常见问题](#6.2 kube-proxy 常见问题)
- 七、总结
一、节点组件概述
Kubernetes 节点（Node） 包含两个核心组件，分别负责容器生命周期管理与网络流量转发：
| 组件 | 部署方式 | 核心职责 |
|---|---|---|
| kubelet | 二进制进程（yum安装） | Pod 生命周期管理 |
| kube-proxy | DaemonSet | Service 网络代理与负载均衡 |
注：Master 节点同时也是特殊 Node，同样运行 kubelet 与 kube-proxy。
二、kubelet
2.1 定义与作用
kubelet 是运行在每个节点上的 Kubernetes 代理进程，负责与 Master 通信并管理节点上的容器化工作负载。
核心职责：
| 职责 | 说明 |
|---|---|
| Pod 生命周期管理 | 创建、启动、停止、删除 Pod 中的容器 |
| 状态上报 | 定期向 apiserver 报告节点与 Pod 状态 |
| 健康检查 | 执行 livenessProbe、readinessProbe |
| 资源监控 | 采集节点与容器的 CPU、内存使用数据 |
| Volume 管理 | 挂载和卸载 Pod 声明的存储卷 |
| 静态 Pod 管理 | 监控 staticPodPath 目录，自动创建/删除静态 Pod |
2.2 部署方式
二进制进程：
bash
# 通过 yum 安装，systemd 管理
yum install -y kubelet
systemctl enable kubelet
systemctl start kubeletyum安装的kubelet是二进制方式运行的。
2.3 核心配置（/var/lib/kubelet/config.yaml）
| 配置项 | 作用 | 典型值 |
|---|---|---|
staticPodPath |
静态 Pod 监控目录 | /etc/kubernetes/manifests |
cgroupDriver |
cgroup 驱动，必须与容器运行时一致 | systemd |
clusterDNS |
集群 DNS 服务 IP（CoreDNS） | 10.96.0.10 |
clusterDomain |
集群域名后缀 | cluster.local |
authentication |
与 apiserver 双向 TLS 认证 | 使用 CA 证书 |
authorization |
鉴权模式 | Webhook |
rotateCertificates |
证书自动轮转 | true |
关键文件：
/etc/kubernetes/kubelet.conf：连接 apiserver 的 kubeconfig 文件/etc/kubernetes/pki/ca.crt：集群根 CA 证书/var/lib/kubelet/pki/：kubelet 自身证书
shell
# 查看 连接 apiserver 的 kubeconfig 文件
cat /var/lib/kubelet/config.yaml
yaml
apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
anonymous:
enabled: false
webhook:
cacheTTL: 0s
enabled: true
x509:
clientCAFile: /etc/kubernetes/pki/ca.crt
authorization:
mode: Webhook
webhook:
cacheAuthorizedTTL: 0s
cacheUnauthorizedTTL: 0s
cgroupDriver: systemd
clusterDNS:
- 10.96.0.10
clusterDomain: cluster.local
cpuManagerReconcilePeriod: 0s
evictionPressureTransitionPeriod: 0s
fileCheckFrequency: 0s
healthzBindAddress: 127.0.0.1
healthzPort: 10248
httpCheckFrequency: 0s
imageMinimumGCAge: 0s
kind: KubeletConfiguration
logging:
flushFrequency: 0
options:
json:
infoBufferSize: "0"
verbosity: 0
memorySwap: {}
nodeStatusReportFrequency: 0s
nodeStatusUpdateFrequency: 0s
rotateCertificates: true
runtimeRequestTimeout: 0s
shutdownGracePeriod: 0s
shutdownGracePeriodCriticalPods: 0s
staticPodPath: /etc/kubernetes/manifests
streamingConnectionIdleTimeout: 0s
syncFrequency: 0s
volumeStatsAggPeriod: 0s三、kube-proxy
3.1 定义与作用
kube-proxy 是运行在每个节点上的网络代理组件，实现 Kubernetes Service 的抽象。
核心职责：
| 职责 | 说明 |
|---|---|
| Service 后端负载均衡 | 将访问 ClusterIP 的流量转发至后端 Pod |
| 服务发现 | 监听 Service 与 Endpoints 变化，动态更新转发规则 |
| 对外暴露服务 | NodePort、LoadBalancer 类型的流量入口 |
本质：kube-proxy 不是网络插件，不负责 Pod 跨主机通信（Pod 网络由 CNI 实现）。
3.2 部署方式
DaemonSet：
bash
# kubeadm 部署的集群，kube-proxy 以 DaemonSet 形式运行
kubectl get daemonset -n kube-system kube-proxy优势：
- 声明式管理：只需配置一次，新增节点自动运行
- 故障自愈：Pod 异常时 DaemonSet 自动重建
- 统一版本：全集群 kube-proxy 版本一致
3.3 工作模式
| 模式 | 原理 | 优缺点 |
|---|---|---|
| iptables（默认） | 维护 iptables NAT 规则 | 稳定可靠，大规模集群规则数庞大 |
| IPVS | 使用内核 IPVS 虚拟服务器 | 高性能，支持更复杂的负载均衡算法 |
| userspace（已弃用） | 用户态代理 | 性能差，仅作历史参考 |
规则恢复机制：
bash
# 删除 kube-proxy Pod 将触发重建，自动恢复 iptables 规则
kubectl delete pod -n kube-system kube-proxy-<xxx>四、集群通信架构
4.1 通信协议
Kubernetes 集群所有组件间通信均采用 HTTPS + 双向 TLS 认证。
| 通信链路 | 证书类型 | 特点 |
|---|---|---|
| kubelet ↔ apiserver | 客户端证书 | 双向验证 |
| kube-proxy ↔ apiserver | 客户端证书 | 双向验证 |
| apiserver ↔ etcd | 客户端证书 | 双向验证 |
| apiserver ↔ kubelet | 客户端证书 | apiserver 访问 kubelet 获取 metrics/logs |
| controller-manager/scheduler ↔ apiserver | 客户端证书 | 双向验证 |
与传统 HTTPS 区别：
- 单向 TLS：仅客户端验证服务端证书
- 双向 TLS（mTLS）：服务端与客户端互相验证证书，Kubernetes 采用此模式
4.2 架构全景图
plain
┌─────────────────────┐
│ etcd │
│ （静态 Pod） │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ kube-apiserver │◄────┐
│ （静态 Pod） │ │
└──────────┬──────────┘ │
│ │
┌───────────────────────┼────────────────┼───────────────┐
│ │ │ │
▼ ▼ ▼ │
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │
│ kcm │ │ kube-scheduler │ │ 各种第三方 │ │
│ （静态 Pod） │ │ （静态 Pod） │ │ Controller │ │
└─────────────────┘ └─────────────────┘ └─────────────────┘ │
│ │ │ │
└───────────────────────┼────────────────┘ │
│ │
▼ │
┌─────────────────────┐ │
│ Node(s) │ │
│ ┌───────────────┐ │ │
│ │ kubelet │──┘ │
│ │ （二进制） │ HTTPS(mTLS) │
│ └───────────────┘ ▲ │
│ ┌───────────────┐ │ │
│ │ kube-proxy │──┘ │
│ │ （DaemonSet） │ HTTPS(mTLS) │
│ └───────────────┘ │
│ ┌───────────────┐ │
│ │ CNI │（Pod 网络，非 mTLS） │
│ │ (DaemonSet) │ │
│ └───────────────┘ │
└─────────────────────────────────────────┘4.3 关键架构特征
| 特征 | 说明 |
|---|---|
| apiserver 为中心 | 所有组件只与 apiserver 通信，组件间不直接通信 |
| 双向 TLS | 全链路 mTLS 加密认证 |
| 声明式 API | 所有组件均为 apiserver 的客户端，通过 watch 机制获取状态变更 |
| 可扩展性 | 通过 CRD + 第三方 Controller 扩展平台能力 |
五、第三方控制器与扩展机制
5.1 需求背景
内置控制器（Deployment、StatefulSet 等）仅能管理 Kubernetes 原生资源。
业务需求：
- 云服务商集成（ALB Ingress、云盘自动挂载）
- 自定义业务编排逻辑
- 外部系统联动
5.2 扩展方式
| 扩展点 | 实现方式 | 示例 |
|---|---|---|
| 自定义资源（CRD） | 定义新的 API 对象 | VirtualMachine、Database |
| 自定义控制器 | 监听 CRD 变化，驱动实际状态 | 云盘控制器、负载均衡器控制器 |
| Operator | CRD + 自定义控制器封装 | etcd-operator、prometheus-operator |
5.3 架构位置
第三方控制器与 kube-controller-manager 并列：
- 均作为 apiserver 的客户端
- 均遵循控制器模式（Reconcile Loop）
- 均支持 Leader Election 实现高可用
六、节点组件故障排查
6.1 kubelet 常见问题
| 现象 | 排查命令 | 常见原因 |
|---|---|---|
| kubelet 未运行 | systemctl status kubelet |
未启动、cgroup 驱动不匹配 |
| Node 状态 NotReady | journalctl -u kubelet -f |
网络插件未就绪、证书过期 |
| Pod 无法创建 | kubectl describe pod |
磁盘压力、内存压力、静态 Pod 路径错误 |
6.2 kube-proxy 常见问题
| 现象 | 排查命令 | 常见原因 |
|---|---|---|
| Service ClusterIP 无法访问 | `iptables -t nat -L -n | grep ` |
| NodePort 无法访问 | kubectl logs -n kube-system kube-proxy-<xxx> |
内核模块未加载（IPVS） |
| 部分后端不可达 | kubectl get endpoints <service> |
Endpoints 未正确更新 |
iptables 规则恢复：
bash
kubectl delete pod -n kube-system -l k8s-app=kube-proxy七、总结
| 组件 | 部署形态 | 核心依赖 | 职责边界 |
|---|---|---|---|
| kubelet | 二进制进程 | 无（独立管理静态 Pod） | Pod 生命周期 |
| kube-proxy | DaemonSet | apiserver | Service 网络代理 |
| CNI 插件 | DaemonSet | 无 | Pod 跨主机通信 |
核心结论：
- kubelet 是节点的"心脏"------以二进制形式常驻，独立于集群控制平面
- kube-proxy 是 Service 的"翻译官"------将虚拟 IP 转化为具体转发规则
- Pod 跨主机通信 ≠ kube-proxy------这是 CNI 的职责，常见混淆点
- 全链路 mTLS------Kubernetes 安全架构的基石
- 控制器模式可扩展------第三方 Controller 与核心控制器平等协作
一句话架构：
kubelet 管死活，kube-proxy 管流量，CNI 管连通，三者合一构成节点运行时的完整能力。