Langchain系列文章目录

01-玩转LangChain：从模型调用到Prompt模板与输出解析的完整指南
02-玩转 LangChain Memory 模块：四种记忆类型详解及应用场景全覆盖
03-全面掌握 LangChain：从核心链条构建到动态任务分配的实战指南
04-玩转 LangChain：从文档加载到高效问答系统构建的全程实战
05-玩转 LangChain：深度评估问答系统的三种高效方法（示例生成、手动评估与LLM辅助评估）
06-从 0 到 1 掌握 LangChain Agents：自定义工具 + LLM 打造智能工作流！
07-【深度解析】从GPT-1到GPT-4：ChatGPT背后的核心原理全揭秘
08-【万字长文】MCP深度解析：打通AI与世界的“USB-C”，模型上下文协议原理、实践与未来

Python系列文章目录

PyTorch系列文章目录

机器学习系列文章目录

深度学习系列文章目录

Java系列文章目录

JavaScript系列文章目录

Python系列文章目录

Go语言系列文章目录

Docker系列文章目录

01-【Docker-Day 1】告别部署噩梦：为什么说 Docker 是每个开发者的必备技能？
02-【Docker-Day 2】从零开始：手把手教你在 Windows、macOS 和 Linux 上安装 Docker
03-【Docker-Day 3】深入浅出：彻底搞懂 Docker 的三大核心基石——镜像、容器与仓库
04-【Docker-Day 4】从创建到删除：一文精通 Docker 容器核心操作命令
05-【Docker-Day 5】玩转 Docker 镜像：search, pull, tag, rmi 四大金刚命令详解
06-【Docker-Day 6】从零到一：精通 Dockerfile 核心指令 (FROM, WORKDIR, COPY, RUN)
07-【Docker-Day 7】揭秘 Dockerfile 启动指令：CMD、ENTRYPOINT、ENV、ARG 与 EXPOSE 详解
08-【Docker-Day 8】高手进阶：构建更小、更快、更安全的 Docker 镜像
09-【Docker-Day 9】实战终极指南：手把手教你将 Node.js 应用容器化
10-【Docker-Day 10】容器的“持久化”记忆：深入解析 Docker 数据卷 (Volume)
11-【Docker-Day 11】Docker 绑定挂载 (Bind Mount) 实战：本地代码如何与容器实时同步？
12-【Docker-Day 12】揭秘容器网络：深入理解 Docker Bridge 模式与端口映射
13-【Docker-Day 13】超越默认Bridge：精通Docker Host、None与自定义网络模式
14-【Docker-Day 14】Docker Compose深度解析
15-【Docker-Day 15】一键部署 WordPress！Docker Compose 实战终极指南
16-【Docker-Day 16】告别单机时代：为什么 Docker Compose 不够用，而你需要 Kubernetes？
17-【Docker-Day 17】K8s 架构全解析：深入理解 Kubernetes 的大脑 (Master) 与四肢 (Node)

---

---

摘要

在上一篇文章中，我们探讨了从 Docker Compose 到 Kubernetes 的演进，理解了为什么在规模化应用场景下我们需要一个强大的容器编排系统。今天，我们将深入 Kubernetes 的核心，解剖其赖以运行的底层架构。本文将详细解析 Kubernetes 的两大核心组成部分——Master 节点（控制平面）和 Node 节点（工作节点），并逐一拆解它们内部的关键组件，如 api-server、etcd、scheduler、controller-manager、kubelet 和 kube-proxy。通过本文，您将建立一个清晰的 K8s 架构心智模型，并理解一个 Pod 从创建到运行的完整生命周期中，这些组件是如何协同工作的。

一、Kubernetes 架构概览：主从模型的艺术

Kubernetes（简称 K8s）采用了一种经典的主从（Master-Node）分布式架构。这种架构设计将集群的管理和工作负载的运行清晰地分离开来，使得整个系统既强大又易于管理。

1.1 为什么是主从架构？

我们可以用一个公司的组织架构来类比：

• Master 节点（控制平面）: 就像公司的管理层（CEO、部门经理）。他们不直接参与生产产品的具体工作，而是负责决策、分配任务、监控项目进度、确保资源充足，并处理各种异常情况。
• Node 节点（工作节点）: 就像公司的员工。他们是实际执行任务、生产产品的主体。他们接收管理层下发的指令，利用分配给他们的资源（工位、电脑）完成具体工作，并向管理层汇报自己的状态。

这种分工明确的架构带来了显而易见的好处：

• 集中控制：所有管理和决策都在 Master 节点上进行，简化了集群的管理。
• 清晰职责：Master 负责“想什么”和“要什么”，Node 负责“怎么做”。
• 高可用性与可扩展性：我们可以有多个 Master 节点来保证管理层的高可用，同时可以轻松地增加或减少 Node 节点（员工）来应对工作负载的变化。

1.2 Master 节点与 Node 节点的核心职责

下表清晰地展示了二者的核心职责：

组件	角色	核心职责	类比
Master 节点	控制平面	接收用户指令，做出调度决策，存储集群状态，监控和维护集群健康。	大脑
Node 节点	工作节点	运行用户应用容器（在 Pod 中），提供计算、网络和存储资源，并向 Master 汇报状态。	四肢

二、控制平面 (Control Plane) 深度解析：Kubernetes 的大脑

控制平面是 Kubernetes 的“大脑”，它负责管理整个集群。一个生产环境的控制平面通常会部署在多个 Master 节点上以实现高可用。它由以下几个关键组件构成。

2.1 API Server (kube-apiserver)：集群的唯一入口

API Server 是 Kubernetes 控制平面的前端，是整个系统的神经中枢和唯一入口。

2.1.1 核心作用

API Server 就像是公司唯一的对外接口人或总前台。无论是外部用户通过 kubectl 命令行工具下达指令，还是集群内部组件之间的通信，都必须经过 API Server。

2.1.2 功能剖析

（1）提供 RESTful API

它以 HTTP RESTful API 的形式暴露了 Kubernetes 的所有功能。我们常用的 kubectl 命令，本质上就是对这些 API 的调用封装。例如，kubectl get pods 实际上是向 API Server 发送了一个 GET 请求。

（2）多重访问控制

作为集群的入口，安全至关重要。API Server 负责执行一系列的访问控制检查，包括：

• 认证 (Authentication)：验证请求者的身份，“你是谁？”。
• 授权 (Authorization)：验证请求者是否有权限执行该操作，“你被允许做什么？”。
• 准入控制 (Admission Control)：在请求被持久化到 etcd 之前，进行更复杂的校验或修改。

（3）状态操作的唯一通道

API Server 是唯一一个可以直接与 etcd 交互的组件。其他所有组件想要查询或修改集群状态，都必须通过 API Server，这保证了数据的一致性和安全性。

2.2 etcd：集群的“真理”之源

etcd 是一个高可用的分布式键值存储系统，它保存了 Kubernetes 集群的全部状态数据。

2.2.1 核心作用

etcd 存储了集群的“期望状态”（用户希望集群是什么样子）和“实际状态”（集群当前是什么样子）。它就是 Kubernetes 的“单一数据源” (Single Source of Truth)。

2.2.2 重要性类比

如果说 API Server 是大脑的嘴巴和耳朵，那么 etcd 就是大脑的记忆中枢。它记录了关于集群的一切：创建了哪些 Pod、Deployment、Service，每个 Node 的状态，分配了哪些 IP 地址等等。如果 etcd 的数据丢失，整个 Kubernetes 集群就相当于“失忆”了，所有状态都会丢失。 因此，在生产环境中，对 etcd 的备份和高可用部署是至关重要的。

2.3 调度器 (Scheduler, kube-scheduler)：为 Pod 找个“家”

当一个新的 Pod 被创建出来时，它并没有被分配到任何一个 Node 上。Scheduler 的工作就是为这个“无家可归”的 Pod 寻找一个最合适的 Node。

2.3.1 核心作用

Scheduler 持续地通过 API Server 监控那些尚未被调度的 Pod，然后根据一系列复杂的算法为它们选择一个最佳的运行节点。

2.3.2 调度流程简介

调度过程主要分为两个阶段：

（1）过滤 (Filtering)

Scheduler 首先会过滤掉所有不满足 Pod 运行条件的 Node。例如：

• Node 的资源（CPU、内存）不足。
• Node 不满足 Pod 的特定标签要求 (nodeSelector)。
• Node 上有“污点”(Taints)，而 Pod 没有相应的“容忍”(Tolerations)。

（2）打分 (Scoring)

在过滤后剩下的一组候选 Node 中，Scheduler 会对每个 Node 进行打分，以评估其“优劣”。评分策略可能包括：

• 优先选择资源使用率较低的 Node。
• 尽量将同一组应用的 Pod 分散到不同的 Node 上以提高可用性。
• …

最终，Scheduler 会选择得分最高的 Node，并通过 API Server 将 Pod 绑定到该 Node 上。

2.4 控制器管理器 (Controller Manager, kube-controller-manager)：状态的守护者

Controller Manager 负责维护集群的状态，确保集群的当前状态与 etcd 中存储的期望状态保持一致。

2.4.1 核心作用

它内部包含了一系列独立的控制器，每个控制器都像一个不知疲倦的“状态调节器”。它们通过 API Server 监控特定资源的状态，并自动执行纠正操作。这个过程被称为“调节循环”（Reconciliation Loop）。

2.4.2 常见的控制器举例

Controller Manager 将多个控制器编译在一个二进制文件中运行，主要包括：

• Deployment Controller: 监控 Deployment 对象，并确保相应数量的 Pod 正在运行。当 Deployment 更新时，它负责执行滚动更新。
• ReplicaSet Controller: 确保在任何时候都有指定数量的 Pod 副本在运行。
• Node Controller: 负责监控 Node 节点的状态。如果一个 Node 长时间无响应，它会将其标记为 NotReady，并可能驱逐上面的 Pod。
• Service Account & Token Controllers: 为新的 Namespace 创建默认的服务账户和 API 访问令牌。

三、工作节点 (Node) 深度解析：Kubernetes 的四肢

Node 节点是 Kubernetes 集群中真正运行应用负载的地方。每个 Node 节点都由控制平面管理，并包含运行 Pod 所需的服务。

3.1 Kubelet：节点的“大管家”

Kubelet 是运行在每个 Node 上的主要代理程序，是 Node 与 Master 之间最重要的沟通桥梁。

3.1.1 核心作用

Kubelet 负责与 Master 节点上的 API Server 通信，接收并执行 Master 发来的指令。

3.1.2 主要职责

（1）Pod 管理

Kubelet 从 API Server 接收分配给其所在节点的 Pod 规范（PodSpec）。然后，它与容器运行时交互，根据这些规范创建、启动、停止和监控容器，确保 Pod 中的容器都按照预期运行。

（2）节点与容器状态上报

Kubelet 会定期向 API Server 汇报其所在节点的健康状况以及其上运行的 Pod 的状态。这使得 Master 能够实时了解整个集群的资源使用情况和健康状况。

3.2 Kube-proxy：集群网络的“交通警察”

Kube-proxy 运行在每个 Node 上，负责实现 Kubernetes 的 Service 概念，管理 Pod 之间的网络通信以及 Pod 与外部世界的通信。

3.2.1 核心作用

它就像每个 Node 上的“交通警察”，根据 API Server 中 Service 和 Endpoints 的定义，维护节点上的网络规则（例如，使用 iptables 或 IPVS），并将发往 Service 虚拟 IP 的流量正确地转发到后端相应的 Pod 上。

3.2.2 工作模式简介

Kube-proxy 确保了即使 Pod 的 IP 地址会变化，我们依然可以通过一个稳定的 Service IP 地址来访问应用。它监听 API Server 中 Service 和 Endpoints 对象的变化，并动态更新节点上的路由规则，实现服务的发现和负载均衡。

3.3 容器运行时 (Container Runtime)：容器的“发动机”

容器运行时是真正负责运行容器的软件。

3.3.1 核心作用

Kubelet 通过它来管理容器的整个生命周期，包括拉取镜像、创建和销毁容器等。

3.3.2 常见的运行时

Kubernetes 支持多种容器运行时，只要它们符合 CRI (Container Runtime Interface) 规范即可。最常见的包括：

• Docker: 曾经是唯一的选择，现在更多是作为一种运行时，但 Kubernetes 社区已逐渐转向更轻量的运行时。
• containerd: 从 Docker 项目中分离出来的核心容器运行时，现在是 CNCF 的毕业项目，也是许多 K8s 发行版的默认选择。
• CRI-O: 专门为 Kubernetes 设计的轻量级容器运行时。

四、组件协同工作流程：一张图看懂 K8s 运行机制

了解了各个组件后，让我们通过一个实际的例子——“部署一个 Pod”——来串联起所有知识点。

4.1 部署一个 Pod 的生命周期

1. 用户提交请求：用户通过 kubectl 执行 kubectl apply -f my-pod.yaml。kubectl 将 YAML 文件转换为 JSON 格式，并向 API Server 发送一个创建 Pod 的 HTTP POST 请求。

2. API Server 处理请求：API Server 接收到请求，进行认证、授权和准入控制。验证通过后，它将这个新的 Pod 对象信息写入 etcd，此时 Pod 的状态为 Pending。

3. Scheduler 介入：Scheduler 通过 API Server 的 Watch 机制，发现了一个新的、尚未分配节点的 Pod。

4. Scheduler 决策：Scheduler 开始执行调度算法，经过“过滤”和“打分”，为该 Pod 选择一个最合适的 Node。

5. Scheduler 更新状态：Scheduler 将决策结果（即选定的 Node 名称）通过 API Server 更新到该 Pod 的 .spec.nodeName 字段中，并再次将状态写入 etcd。

6. Kubelet 发现任务：目标 Node 上的 Kubelet 同样在 Watch API Server，它发现有一个新的 Pod 被分配给了自己。

7. Kubelet 执行创建：Kubelet 读取 Pod 的详细配置信息（如需要哪个镜像、挂载哪些数据卷等），然后调用 容器运行时 (Container Runtime) 来：

   • 拉取所需的容器镜像。
   • 创建并启动容器。
   • 配置网络和存储。

8. Kubelet 上报状态：容器成功启动后，Kubelet 会将 Pod 的状态（例如 Running）以及容器的 IP 地址等信息通过 API Server 更新到 etcd。

9. Controller Manager 监控：在此期间，Controller Manager 中的相关控制器（如 Deployment Controller）也在持续监控，确保 Pod 的实际状态与期望状态一致。

10. Kube-proxy 更新网络：如果该 Pod 属于某个 Service，Kube-proxy 会检测到这一变化，并更新所在节点的网络规则，以便将发往该 Service 的流量可以路由到这个新创建的 Pod。

至此，一个 Pod 的部署流程就完成了，它已经成功运行在集群中并可以对外提供服务。

五、总结

通过本文的深度解析，我们可以得出以下核心结论：

1. 主从架构是基石：Kubernetes 采用 Master-Node 架构，实现了管理与执行的分离，为集群的稳定性、可扩展性和易管理性奠定了基础。
2. Master 是大脑：控制平面由四个核心组件构成：API Server 是所有交互的唯一入口；etcd 是存储集群状态的真理之源；Scheduler 负责为 Pod 智能选址；Controller Manager 负责维护集群状态的最终一致性。
3. Node 是四肢：工作节点是应用负载的实际运行地，其核心组件包括：Kubelet 作为节点的代理，负责与 Master 通信并管理 Pod；Kube-proxy 负责实现服务发现和负载均衡的网络功能；Container Runtime 是运行容器的引擎。
4. 协同工作是关键：所有组件各司其职，通过以 API Server 为中心的 Watch 和 RESTful 通信机制紧密协作，共同完成从接收用户意图到最终在节点上运行应用的完整闭环。
5. 声明式 API 的威力：用户只需声明“我想要什么”，而 Kubernetes 的各个组件会通过持续的调节循环，自动地将系统“驱动”到用户期望的状态。理解这套架构是深入学习和排查 Kubernetes 问题的根本。

---