Kubernetes 架构概览

Kubernetes 采用主从架构：

• • Master 节点（控制平面）：负责集群管理和决策，包括 API Server、Scheduler、Controller Manager 和 Etcd。

• • Worker 节点：运行实际工作负载，包括 Kubelet、Kube-Proxy 和容器运行时（如 Docker 或 containerd）。

集群通过 API Server 作为入口，用户提交 YAML 或 JSON 格式的声明式配置，系统自动调和实际状态与期望状态。

核心组件详解

• • API Server：集群的网关，提供 RESTful API，支持认证、授权和资源验证。所有组件通过它通信。

• • Scheduler：根据资源需求、亲和性等策略，将 Pod 调度到合适节点。

• • Controller Manager：运行多个控制器，如 Deployment Controller，确保资源状态一致。

• • Etcd：分布式键值存储，保存集群状态数据。高可用性通过 Raft 协议实现。

• • Kubelet：节点代理，管理 Pod 生命周期，报告节点状态。

• • Kube-Proxy：处理服务发现和负载均衡，使用 iptables 或 IPVS 实现。

iptables：成熟稳定的 kube-proxy 代理模式，Kubernetes service 的服务发现和负载均衡使用 iptables 规则配置，但性能一般，受规模影响较大，适用于集群存在少量的 service。

IPVS：高性能的 kube-proxy 代理模式，Kubernetes service 的服务发现和负载均衡使用 Linux IPVS 模块进行配置，适用于集群存在大量的 service，对负载均衡有高性能要求的场景。

这些组件协作形成闭环控制系统：观察 → 决策 → 执行。

分层解析：从微观到宏观

第1层：容器 (Container)

• 是什么？：软件打包和运行的最基本单元。它将应用代码、运行时环境、库、配置等打包成一个独立、轻量级、可移植的软件包。Docker 是最常见的容器运行时。

• 职责：运行一个特定的进程（如 Nginx、Node.js 应用）。它本身对 Kubernetes 无感知。

• 类比：一个独立的、已经配置好环境的软件进程。好比是厨房里一个正在炖汤的锅，里面已经放好了所有食材和调料。

第2层：Pod

• 是什么？：Kubernetes 管理和调度的最小单元。一个 Pod 包含一个或多个（通常是一个）紧密相关的容器。这些容器共享网络命名空间（相同的 IP 和端口空间）和存储卷。

• 职责：为容器提供一个“逻辑主机”环境，使其能通过 localhost 通信并共享存储。

• 关键点：Kubernetes 不直接管理容器，而是管理 Pod。Pod 是短暂的（ephemeral）。

• 类比：一个餐盘 (Pod)。餐盘上可以放一个主菜锅（主容器），也可以同时放一个小碟蘸料（辅助容器，如日志收集器）。餐盘上的所有东西总是一起被摆放、一起被收走。

第3层：节点 (Node)

• 是什么？：一个节点是一个工作机器，过去被称为 Minion。通常是一台物理机或虚拟机。每个节点上运行着必要的服务来托管 Pod。

• 组件：

  • Kubelet：与 Master 节点通信，管理本节点上 Pod 的生命周期。

  • 容器运行时 (如 Docker, containerd)：负责拉取镜像和运行容器。

  • kube-proxy：维护节点上的网络规则，实现 Service 的网络代理和负载均衡。

• 职责：承载 Pod 的运行，是集群的“劳动力”。

• 类比：厨房里的一个灶台 (Node)。灶台提供水、电、燃气等基础资源，上面可以放置多个餐盘（Pod）来进行烹饪。

第4层：命名空间 (Namespace)

• 是什么？：一种在单个物理集群中创建多个虚拟集群的机制。它为资源和名称提供了一个作用域。

• 职责：

  • 资源隔离：将集群资源分配给不同的用户、团队或项目（如 development, production, testing 命名空间）。

  • 资源配额：限制每个命名空间可以使用的计算资源总量。

• 关键点：大部分资源都在某个命名空间内，但有些（如节点、持久化存储卷）是集群级别的。

• 类比：一家大餐厅里的不同包间 (Namespace)。每个包间（如“开发包间”、“生产包间”）里有自己的一套桌椅（资源），互不干扰。服务员（用户）需要进入正确的包间才能操作里面的东西。

第5层：服务 (Service)

• 是什么？：一个抽象层，它定义了一组 Pod 的逻辑集合和访问它们的策略。Pod 是动态的（IP会变），Service 提供了一個稳定的访问入口。

• 职责：

  • 服务发现：为一组 Pod 提供一个固定的 DNS 名称和虚拟 IP（ClusterIP）。

  • 负载均衡：将请求自动分发到后端的多个 Pod 上。(kube-proxy 实现的负载均衡机制，将请求转发到其中一个 Pod 默认情况下，这个选择是随机的，但会尽量保持均匀分布)

• 关键点：通过标签选择器 (Label Selector) 来找到它要代理的 Pod。

• 类比：餐厅的固定菜单和前台服务员 (Service)。顾客（用户）不需要关心后厨（Pod）是哪个厨师（Pod IP）在做菜，他们只需要找服务员点“鱼香肉丝”（Service Name）这道菜，服务员会自动把请求分配给空闲的厨师。

第6层：控制平面 (Master)

• 是什么？：集群的“大脑”，负责管理、调度、监控整个集群。通常由多个高可用的服务器组成。

• 核心组件：

  • API Server：集群的网关，所有内外部的通信都必须通过它。

  • Scheduler：负责决策将 Pod 放在哪个 Node 上运行。

  • Controller Manager：运行各种控制器，确保集群的实际状态符合用户期望的状态（如确保 Deployment 的副本数）。

  • etcd：一个高可用的键值数据库，存储了整个集群的所有配置和数据状态。

• 职责：做出全局决策，响应集群事件，维护集群的期望状态。

• 类比：餐厅的总经理和后厨管理系统 (Master)。总经理（Controller Manager）根据客流量（期望状态）决定需要多少厨师（Pod），排班系统（Scheduler）安排厨师到具体灶台（Node）上班，所有指令都通过经理办公室（API Server）下达，并记录在总账本（etcd）里。

第7层：网络 (Network)

• 是什么？：这不是一个具体的对象，而是 Kubernetes 的一个核心概念和一套要求，通常由第三方网络插件（CNI, Container Network Interface）实现，如 Calico, Flannel, Weave Net 等。

• 核心原则：

  1. 每个 Pod 都有一个唯一的集群内可路由的 IP 地址（IP-per-Pod）。

  2. 所有 Pod 都可以在不使用 NAT 的情况下与其他所有 Pod 通信，无论它们在哪台节点上。

  3. 所有节点上的代理（kube-proxy）和网络规则，使得 Pod 可以与 Service 通信。

• 职责：为 Pod、Service、节点之间提供连通性，是集群的“神经系统”。

• 类比：连接餐厅所有部分的传菜通道、电话系统和订单流 (Network)。它确保前台服务员的点单（Service 请求）能准确、快速地送到后厨正确的灶台和餐盘（Pod）上，并且各个灶台之间也可以直接传递东西（Pod-to-Pod通信）。

总结与关系图

关系总结：

• 容器 运行在 Pod 里。

• Pod 被调度到 节点 上运行。

• Service 代理一组具有相同标签的 Pod，提供稳定访问。

• 命名空间 将上述资源（Pod, Service等）隔离成虚拟集群。

• 控制平面 (Master) 管理所有节点和上面的Pod，其状态存储在etcd中。

• 网络 是所有组件间通信的基础设施，由插件实现。

区别与关系表格：

这个生态系统协同工作，使得Kubernetes能够高效、可靠地运行和管理大规模的容器化应用。