Kubernetes Node 全维度解析

1. 是什么：Node 的核心定义与特征

Kubernetes（k8s）中的 Node 是集群的工作节点（也被称为 minion），是运行容器化应用的物理机或虚拟机，是 k8s 集群的“计算载体”——所有的 Pod（容器组）最终都会调度并运行在 Node 上。

核心内涵

Node 是 k8s 集群的最小计算单元，承载着实际的业务负载，接受 Master 节点（控制平面）的统一管控，是“控制平面指令的执行者”。

关键特征

  • 必备组件：每个 Node 必须部署核心组件才能接入集群，包括 kubelet（与 Master 通信并管理 Pod）、kube-proxy（负责 Node 网络代理与服务转发）、容器运行时（如 containerd、Docker）；
  • 可管控性：Master 可通过 API Server 对 Node 进行标签管理、调度限制、状态监控；
  • 独立性：每个 Node 有独立的主机名、IP 地址，资源（CPU/内存/磁盘）可独立分配；
  • 状态可见性：Node 的状态（Ready/NotReady/Unknown）、资源使用率、运行的 Pod 列表等信息可通过 k8s 管控面实时查看。

2. 为什么需要：Node 解决的核心痛点与价值

核心痛点解决

没有 Node 的话，k8s 集群只是“空的控制平面”，无法运行任何业务负载，Node 解决了以下核心问题：

  1. 单机部署的局限性：替代单台服务器部署应用的模式，实现应用的分布式运行，避免单点故障；
  2. 资源碎片化：将多台服务器的计算资源整合为集群资源池，统一调度和分配，提升资源利用率；
  3. 运维复杂度：通过 k8s 统一管控所有 Node，实现应用在多节点的自动化部署、扩缩容、故障迁移；
  4. 隔离性不足：基于 Node 划分资源边界，结合 Namespace、资源配额，实现不同业务的资源隔离。

实际应用价值

  • 高可用：单个 Node 故障时，k8s 可将该节点上的 Pod 调度到其他健康 Node，保证业务不中断；
  • 弹性伸缩：根据业务负载，动态增加/减少 Node 数量（集群扩容/缩容），或在 Node 内调整 Pod 资源；
  • 资源精细化管理：针对不同 Node 配置不同资源规格（如高性能 Node 运行核心业务、低配 Node 运行非核心业务），优化资源成本；
  • 跨环境兼容：Node 可部署在物理机、虚拟机、云服务器（ECS/EKS）等不同环境，实现集群的混合部署。

3. 核心工作模式：Node 的运作逻辑与关键要素

核心运作逻辑

Node 是“被动执行 + 主动上报”的工作模式：Master 控制平面下发指令（如调度 Pod、更新 Pod 状态），Node 上的核心组件接收并执行指令，同时将自身状态、Pod 运行状态实时上报给 Master。

关键要素及关联

要素类别 具体组件/对象 核心作用 关联关系
Master 控制面 API Server 作为 Node 与 Master 通信的唯一入口，接收 Node 上报的状态，下发调度指令 Node 上的 kubelet 仅通过 API Server 与 Master 交互，不直接连接其他组件
Scheduler（调度器） 决定 Pod 调度到哪个 Node 运行 根据 Node 的资源、标签、污点/容忍等规则，为 Pod 匹配最优 Node
Controller Manager 监控 Node 状态，若 Node 故障则触发 Pod 迁移等动作 通过 API Server 获取 Node 状态，触发 ReplicaSet/Deployment 等控制器补全 Pod
Node 本地组件 kubelet Node 的“管家”，执行 Master 指令，管理 Pod 生命周期，上报 Node/Pod 状态 核心组件，是 Master 与 Node 交互的核心桥梁
kube-proxy 管理 Node 网络规则，实现 Service 到 Pod 的转发，维护网络连通性 依赖 API Server 获取 Service/Pod 信息，配置 iptables/IPVS 规则
容器运行时（containerd） 实际创建、启动、停止容器，是 Pod 运行的底层依赖 受 kubelet 管控，kubelet 通过 CRI（容器运行时接口）调用其功能
核心对象 Pod 运行在 Node 上的最小部署单元，是 Node 的“工作负载” Node 是 Pod 的载体，一个 Node 可运行多个 Pod
Node 状态（Ready/NotReady） 标识 Node 是否可用，由 kubelet 定期上报 Master 根据状态决定是否向该 Node 调度 Pod

4. 工作流程：Node 接收并运行 Pod 的完整链路

流程图（Mermaid 11.4.1 规范）

graph TD A[用户/运维人员] -->|1.提交Pod配置 yaml/json| B[Master - API Server] B -->|2.存储Pod配置到etcd| C[etcd] B -->|3.通知Scheduler| D[Master - Scheduler] D -->|4.筛选健康Node+资源匹配| E[选择最优Node] D -->|5.将Pod调度结果写入API Server| B B -->|6.推送Pod调度指令| F[目标Node - kubelet] F -->|7.调用容器运行时 containerd| G[创建Pod/容器] F -->|8.通知Node - kube-proxy| H[配置网络规则 iptables/IPVS] H -->|9.网络规则生效| I[Pod网络连通] F -->|10.定期监控Pod/Node状态| J[上报状态到API Server] B -->|11.状态同步到etcd| C B -->|12.用户可通过kubectl查看状态| A style A fill:#f9f,stroke:#333,stroke-width:2px style B fill:#bbf,stroke:#333,stroke-width:2px style F fill:#bfb,stroke:#333,stroke-width:2px style C fill:#fbf,stroke:#333,stroke-width:1px style D fill:#bbf,stroke:#333,stroke-width:1px style E fill:#ffb,stroke:#333,stroke-width:1px style G fill:#bfb,stroke:#333,stroke-width:1px style H fill:#bff,stroke:#333,stroke-width:1px style I fill:#bfb,stroke:#333,stroke-width:1px style J fill:#fbb,stroke:#333,stroke-width:1px

步骤拆解（完整工作链路）

  1. 提交指令：用户通过 kubectl apply 提交 Pod 配置，请求发送至 Master 的 API Server；
  2. 存储与通知：API Server 将 Pod 配置存储到 etcd，并通知 Scheduler（调度器）有新 Pod 待调度；
  3. 节点调度：Scheduler 过滤集群中所有健康的 Node（排除 NotReady、被封锁的 Node），根据资源使用率、标签、亲和性等规则，为 Pod 选择最优 Node；
  4. 下发指令：Scheduler 将调度结果（Pod 应运行在哪个 Node）写入 API Server，API Server 向目标 Node 的 kubelet 推送“创建 Pod”的指令；
  5. 创建 Pod：Node 上的 kubelet 接收指令后，通过 CRI 调用容器运行时（如 containerd）创建 Pod 和容器；
  6. 网络配置：kubelet 通知 kube-proxy，kube-proxy 配置该 Node 的网络规则（如 iptables），确保 Pod 可被 Service 访问；
  7. 状态监控与上报：kubelet 持续监控 Pod 的运行状态（如是否正常运行、资源使用率）和 Node 自身状态（如 CPU/内存使用率、磁盘空间），并定期将状态上报给 API Server；
  8. 状态同步：API Server 将 Node/Pod 状态同步到 etcd，用户可通过 kubectl 实时查看状态。

5. 入门实操：Node 核心操作步骤（可直接落地）

前置条件

  • 已部署 k8s 集群（单节点/多节点均可）；
  • 已配置 kubectl 命令行工具并连接到集群；
  • 具备集群的管理员权限（可执行 kubectl 操作）。

核心实操步骤

步骤1：查看集群所有 Node 列表

# 基础查看（名称、状态、角色、版本）
kubectl get nodes

# 详细查看（包含IP、操作系统、容器运行时等）
kubectl get nodes -o wide

# 查看指定Node的完整信息（JSON格式）
kubectl get node <node名称> -o json

步骤2：给 Node 打标签（用于调度策略）

标签是 Node 的“属性标识”，可用于指定 Pod 只运行在特定标签的 Node 上：

# 给Node打标签（示例：给node-1打标签env=prod，标识生产环境节点）
kubectl label nodes <node名称> env=prod

# 查看Node的标签
kubectl get node <node名称> --show-labels

# 删除Node的标签（末尾加"-"）
kubectl label nodes <node名称> env-

步骤3：封锁/解封 Node（维护时使用）

封锁 Node 可阻止新 Pod 调度到该节点，解封后恢复调度：

# 封锁Node（仅阻止新Pod调度，不影响已运行的Pod）
kubectl cordon <node名称>

# 封锁并驱逐已运行的Pod（维护前清理节点，--ignore-daemonsets忽略DaemonSet Pod）
kubectl drain <node名称> --ignore-daemonsets

# 解封Node（恢复调度）
kubectl uncordon <node名称>

步骤4：查看 Node 状态与资源使用

# 查看Node的状态详情（重点看Conditions字段，Ready状态是否为True）
kubectl describe node <node名称>

# 查看集群所有Node的资源使用情况（需部署metrics-server）
kubectl top nodes

实操注意事项

  1. drain 操作会驱逐 Pod，生产环境需提前确认业务可中断，或确保应用有副本在其他 Node；
  2. 标签命名需规范（如 env=prod/dev/test、role=master/node），避免混乱；
  3. 若 kubectl top nodes 报错，需先部署 metrics-server 组件（集群监控必备）；
  4. 不要直接修改 Node 的核心组件配置（如 kubelet），建议通过 k8s 配置文件或运维工具管理。

6. 常见问题及解决方案

问题1：Node 状态显示 NotReady（最常见）

现象

kubectl get nodes 中 Node 状态为 NotReady，无法调度 Pod。

原因

  • kubelet 未启动或异常退出；
  • 容器运行时（containerd/Docker）故障；
  • Node 网络异常，无法连接 Master 的 API Server；
  • kubelet 配置错误（如 API Server 地址错误）。

解决方案

# 步骤1：登录NotReady的Node，检查kubelet状态
systemctl status kubelet

# 步骤2：若kubelet未启动，启动并设置开机自启
systemctl start kubelet
systemctl enable kubelet

# 步骤3：查看kubelet日志（关键！定位具体错误）
journalctl -u kubelet -f

# 步骤4：检查容器运行时状态（以containerd为例）
systemctl status containerd

# 步骤5：检查Node与API Server的网络连通性（替换为实际API Server地址）
curl -v https://<API Server IP>:6443/healthz

# 步骤6：若kubelet配置错误，修改配置文件（通常在/etc/kubernetes/kubelet.conf）后重启
systemctl restart kubelet

问题2：Node 资源不足（CPU/内存使用率过高）

现象

  • kubectl top nodes 显示 Node 的 CPU/内存使用率 > 90%；
  • Pod 频繁被 OOM（内存溢出）杀死，或出现调度失败（提示 Insufficient CPU/Memory）。

原因

  • 单个 Node 上运行的 Pod 过多，资源耗尽；
  • 部分 Pod 未设置资源限制（requests/limits），抢占大量资源；
  • Node 本身规格过低，无法承载负载。

解决方案

  1. 临时缓解：驱逐非核心 Pod 或封锁 Node，将 Pod 调度到其他节点：
    # 驱逐Pod（保留DaemonSet）
kubectl drain <node名称> --ignore-daemonsets --delete-emptydir-data
  2. 长期优化：
    • 给所有 Pod 设置 resources.requests 和 resources.limits，限制资源使用；
    • 扩容集群（增加 Node 数量），分散负载；
    • 通过 Node 亲和性/反亲和性，将高资源消耗的 Pod 分散到不同 Node。

问题3：kube-proxy 异常导致 Service 无法访问 Pod

现象

  • Pod 本身运行正常，但通过 Service IP/域名无法访问；
  • Node 上的 iptables/IPVS 规则缺失。

解决方案

# 步骤1：检查kube-proxy状态
systemctl status kube-proxy

# 步骤2：重启kube-proxy
systemctl restart kube-proxy

# 步骤3：查看kube-proxy日志，定位错误
journalctl -u kube-proxy -f

# 步骤4：重置Node的iptables规则（谨慎！生产环境先备份）
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
# 重启kube-proxy后重新生成规则
systemctl restart kube-proxy

总结

  1. 核心定义：Node 是 k8s 集群的工作节点，承载 Pod 运行，核心组件为 kubelet、kube-proxy、容器运行时；
  2. 核心价值：解决单机部署的高可用、资源管理问题，是集群运行业务负载的基础；
  3. 关键操作：掌握 Node 列表查看、标签管理、封锁/解封、状态排查，能快速定位 NotReady、资源不足等常见问题；
  4. 核心流程：Node 遵循“Master 下发指令 → kubelet 执行 → kube-proxy 配置网络 → 上报状态”的工作模式，是控制平面与业务负载的桥梁。
posted @ 2026-01-31 14:49  先弓  阅读(0)  评论(0)    收藏  举报