Kubernetes架构介绍、Node与Pod的区别

csdn_tom_168

于 2025-06-07 00:09:52 发布

阅读量751

点赞数 10

CC 4.0 BY-SA版权

分类专栏： k8s 文章标签： kubernetes 架构容器

本文链接：https://blog.youkuaiyun.com/csdn_tom_168/article/details/148475911

k8s 专栏收录该内容

11 篇文章

订阅专栏

(一) Kubernetes架构介绍

一、Kubernetes架构图示

+-------------------+       +-------------------+       +-------------------+
|   用户接口层      | <---> |   控制平面层      | <---> |   数据平面层      |
| (kubectl等)       |       | (Master节点)      |       | (Worker节点)      |
+-------------------+       +-------------------+       +-------------------+
        |                           |                           |
        v                           v                           v
+-------------------+       +-------------------+       +-------------------+
|   命令行工具      |       |   API Server      |       |   kubelet         |
|   Dashboard等     |       |   (集群网关)      |       |   (节点代理)      |
+-------------------+       +-------------------+       +-------------------+
        |                           |                           |
        v                           v                           v
+-------------------+       +-------------------+       +-------------------+
|   Web UI          |       |   Controller      |       |   容器运行时      |
|                   |       |   Manager         |       |   (Docker等)      |
+-------------------+       +-------------------+       +-------------------+
        |                           |                           |
        v                           v                           v
+-------------------+       +-------------------+       +-------------------+
|   CLI工具         |       |   Scheduler       |       |   CNI插件         |
|                   |       |   (调度器)        |       |   (网络插件)      |
+-------------------+       +-------------------+       +-------------------+

二、核心组件详解

一、控制平面组件（Master节点）

kube-apiserver
- 作用：Kubernetes集群的网关，所有操作（如创建Pod、查询状态）都通过它提供的RESTful API进行
- 特点：
  - 所有组件（如Controller、Scheduler）都通过它与集群交互
  - 负责请求验证、授权和数据持久化到etcd
  - 支持多种客户端（kubectl、Dashboard、其他系统集成）
etcd
- 作用：分布式键值存储，保存集群的所有配置数据和状态（如Pod信息、节点状态、配置参数）
- 特点：
  - 高可用、强一致性（使用Raft算法）
  - 是Kubernetes的“数据库”，所有关键数据都存储在这里
  - 需要部署为多节点集群以保证高可用
kube-scheduler
- 作用：负责将Pod调度到合适的Node上运行
- 调度逻辑：
  - 考虑资源需求（CPU/内存）
  - 硬件/软件约束（如节点标签、污点容忍）
  - 亲和性/反亲和性规则
  - 负载均衡（避免单个Node过载）
kube-controller-manager
- 作用：运行各种控制器，维护集群的期望状态（如副本数、节点健康状态）
- 包含的控制器：
  - Node Controller：监控节点状态
  - Replication Controller：管理Pod副本数
  - Endpoint Controller：维护Service与Pod的关联
  - ServiceAccount & Token Controller：管理ServiceAccount
cloud-controller-manager（云厂商专用）
- 作用：与云平台交互的控制器（如AWS、Azure、GCP）
- 功能：
  - 管理云资源（如负载均衡器、存储卷）
  - 处理节点生命周期（如自动扩缩容节点）
  - 仅在使用云服务时需要部署

二、数据平面组件（Worker节点）

kubelet
- 作用：节点代理，负责与Master通信并管理Pod
- 具体工作：
  - 从API Server接收Pod创建/删除指令
  - 调用容器运行时（如Docker）启动/停止容器
  - 上报节点和Pod状态给Master
  - 执行本地资源管理（如磁盘清理）
kube-proxy
- 作用：实现Service的网络代理和负载均衡
- 工作原理：
  - 维护iptables/ipvs规则，将Service的虚拟IP映射到后端Pod
  - 支持TCP/UDP协议
  - 实现Service的ClusterIP和NodePort访问
Container Runtime（容器运行时）
- 作用：实际运行容器的软件
- 常见实现：
  - Docker（传统方案，逐渐被替代）
  - containerd（Kubernetes原生推荐，轻量级）
  - CRI-O（专为Kubernetes设计的运行时）
- 功能：
  - 拉取镜像、创建容器、管理容器生命周期
  - 提供容器网络和存储接口（通过CNI/CRI规范）

三、组件关系图示

三、关键工作流程

部署应用流程
服务发现流程

四、架构特点

声明式API
- 用户通过YAML/JSON声明期望状态
- 控制器自动维护实际状态与期望状态一致
自愈能力
- 自动检测节点故障
- 自动重新调度Pod到健康节点
弹性伸缩
- 支持Horizontal Pod Autoscaler自动扩缩容
- 根据CPU/内存使用率或自定义指标调整副本数
服务发现与负载均衡
- 内置Service机制提供稳定的访问入口
- 自动负载均衡到后端Pod

五、典型组件关系图

六、总结

Kubernetes架构采用控制平面+数据平面的分层设计：

控制平面：负责集群管理、调度决策、状态维护
数据平面：负责实际运行容器、网络通信、节点管理

其核心优势在于：

声明式管理，简化运维
自愈能力，高可用性
弹性伸缩，适应业务变化
统一的服务发现和负载均衡机制

Kubernetes通过组件间的紧密协作，实现了容器化应用的自动化部署、扩展和管理。

(二) Node与Pod的区别

一、Node与Pod组成对比

Node（节点）组成
- 物理/虚拟机：Kubernetes集群中的计算资源载体
- 核心组件：
  - kubelet：节点代理，负责与Master通信
  - kube-proxy：网络代理，实现Service负载均衡
  - 容器运行时（如Docker/containerd）：实际运行容器的软件
  - CNI插件：提供网络功能（如Flannel/Calico）
- 特点：
  - 是集群的计算单元
  - 可以运行多个Pod
  - 需要满足Kubernetes的节点要求（如操作系统、资源等）
Pod组成
- 最小调度单元：Kubernetes中可创建和管理的最小单位
- 核心组成：
  - 1个或多个容器（通常为1个主容器+可选的Sidecar容器）
  - 共享的网络命名空间（所有容器可通过localhost通信）
  - 共享的存储卷（所有容器可访问相同数据）
  - 共享的环境变量和配置
- 特点：
  - 是应用部署的基本单位
  - 通常包含一个完整的应用组件（如前端服务、后端服务等）
  - 生命周期由Kubernetes管理

二、Node与Pod区别对比表

对比维度	Node（节点）	Pod（容器组）
层级关系	集群的计算资源载体	应用部署的最小单位
组成内容	包含kubelet、kube-proxy等系统组件	包含1个或多个容器
网络	提供物理网络连接	提供应用层网络（共享网络命名空间）
存储	提供节点级存储	提供Pod级存储卷
生命周期	长期存在（除非节点故障或维护）	短期存在（按需创建和销毁）
管理对象	由Master节点管理	由Controller（如Deployment）管理
资源隔离	物理/虚拟机级别的隔离	容器级别的隔离
典型用途	运行Pod的载体	运行应用组件的载体

三、Node与Pod关系图示

四、关键区别说明

层级关系
- Node是物理/虚拟机层面的概念
- Pod是应用层面的概念
- 1个Node可以运行多个Pod，但1个Pod只能运行在1个Node上
网络隔离
- Node提供物理网络连接（如IP地址）
- Pod提供应用层网络隔离（所有容器共享网络命名空间）
生命周期
- Node通常长期存在（除非节点故障或维护）
- Pod通常是短期的，按需创建和销毁（由Controller管理）
管理对象
- Node由Kubernetes Master节点管理
- Pod由Controller（如Deployment、StatefulSet等）管理
资源隔离
- Node提供物理/虚拟机级别的隔离（不同Node之间完全隔离）
- Pod提供容器级别的隔离（同一Pod内容器共享网络和存储）

五、实际应用中的关系

典型部署场景
- 一个Web应用可能包含：
  - 1个Pod运行前端服务
  - 1个Pod运行后端服务
  - 1个Pod运行数据库服务
- 这些Pod可以分布在不同的Node上
扩展性
- 当需要扩展时：
  - 可以增加Pod数量（通过Controller）
  - 可以增加Node数量（扩展集群）
故障处理
- 如果某个Node故障：
  - 该Node上的Pod会被重新调度到其他健康Node上
  - 用户无需关心具体运行在哪个Node上