8.k8s-node组件介绍
k8s-node组件介绍
- 一、节点组件概述
- 二、kubelet
- 2.1 定义与作用
- 2.2 部署方式
- 2.3 核心配置（/var/lib/kubelet/config.yaml）
- 三、kube-proxy
- 3.1 定义与作用
- 3.2 部署方式
- 3.3 工作模式
- 四、集群通信架构
- 4.1 通信协议
- 4.2 架构全景图
- 4.3 关键架构特征
- 五、第三方控制器与扩展机制
- 5.1 需求背景
- 5.2 扩展方式
- 5.3 架构位置
- 六、节点组件故障排查
- 6.1 kubelet 常见问题
- 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 部署方式
二进制进程：
# 通过 yum 安装，systemd 管理yuminstall-y kubelet systemctlenablekubelet 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 自身证书
# 查看 连接 apiserver 的 kubeconfig 文件cat/var/lib/kubelet/config.yamlapiVersion:kubelet.config.k8s.io/v1beta1authentication:anonymous:enabled:falsewebhook:cacheTTL:0senabled:truex509:clientCAFile:/etc/kubernetes/pki/ca.crtauthorization:mode:Webhookwebhook:cacheAuthorizedTTL:0scacheUnauthorizedTTL:0scgroupDriver:systemdclusterDNS:-10.96.0.10clusterDomain:cluster.localcpuManagerReconcilePeriod:0sevictionPressureTransitionPeriod:0sfileCheckFrequency:0shealthzBindAddress:127.0.0.1healthzPort:10248httpCheckFrequency:0simageMinimumGCAge:0skind:KubeletConfigurationlogging:flushFrequency:0options:json:infoBufferSize:"0"verbosity:0memorySwap:{}nodeStatusReportFrequency:0snodeStatusUpdateFrequency:0srotateCertificates:trueruntimeRequestTimeout:0sshutdownGracePeriod:0sshutdownGracePeriodCriticalPods:0sstaticPodPath:/etc/kubernetes/manifestsstreamingConnectionIdleTimeout:0ssyncFrequency:0svolumeStatsAggPeriod:0s三、kube-proxy
3.1 定义与作用
kube-proxy 是运行在每个节点上的网络代理组件，实现 Kubernetes Service 的抽象。
核心职责：
| 职责 | 说明 |
|---|---|
| Service 后端负载均衡 | 将访问 ClusterIP 的流量转发至后端 Pod |
| 服务发现 | 监听 Service 与 Endpoints 变化，动态更新转发规则 |
| 对外暴露服务 | NodePort、LoadBalancer 类型的流量入口 |
本质：kube-proxy 不是网络插件，不负责 Pod 跨主机通信（Pod 网络由 CNI 实现）。
3.2 部署方式
DaemonSet：
# kubeadm 部署的集群，kube-proxy 以 DaemonSet 形式运行kubectl get daemonset -n kube-system kube-proxy优势：
- 声明式管理：只需配置一次，新增节点自动运行
- 故障自愈：Pod 异常时 DaemonSet 自动重建
- 统一版本：全集群 kube-proxy 版本一致
3.3 工作模式
| 模式 | 原理 | 优缺点 |
|---|---|---|
| iptables（默认） | 维护 iptables NAT 规则 | 稳定可靠，大规模集群规则数庞大 |
| IPVS | 使用内核 IPVS 虚拟服务器 | 高性能，支持更复杂的负载均衡算法 |
| userspace（已弃用） | 用户态代理 | 性能差，仅作历史参考 |
规则恢复机制：
# 删除 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 架构全景图
┌─────────────────────┐ │ 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 规则恢复：
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 管连通，三者合一构成节点运行时的完整能力。