K8S工作原理详解(图文全面总结)

K8S 能够帮助开发者、和运维人员，自动化应用的部署、扩展、和管理，适用于构建云原生应用。

图片

K8S ，能自动将容器化应用，分配到合适的节点（服务器）上，通过自动调度来确保资源合理分配，最大化资源利用率。

K8S 适合，管理由多个小服务组成的微服务架构，提供自动扩展、自愈、和负载均衡，保证服务的高可用性、和弹性伸缩..等场景。

K8S工作原理

K8S 是一个分布式系统，主要由 Master 节点(主节点)、和Node节点（工作节点）**组成：

如下图所示：

图片

Master 节点负责：整个集群的管理、和调度，而 Node 节点则负责运行应用容器，这是K8S的大致分工。

Master 节点

Master，负责管理整个集群的控制、和调度，决定哪些应用实例部署在 Node 上。

Master，主要包含以下组件：

API Server

APIServer，负责：接收用户的请求，并将请求转化为操作指令交由后端的其他组件执行。

图片

API Server 是集群的入口，所有对 K8S 的操作，如：资源创建、修改、删除...等，都是通过 HTTP 请求与 API Server 交互的。

所有组件都通过 API Server 通信，确保系统的统一性、和安全性，有点类似“微服务网关”的角色。

etcd

etcd，是分布式键值存储数据库，用于保存集群状态信息。

API Server 是 K8S 集群的“控制中心”，与 etcd 进行交互以保存、和检索集群的配置信息、和状态数据。

etcd，会存储：配置信息、Pod 状态、Service 配置...等，所有的配置信息都存储在 etcd 中。

etcd 使用 Raft 协议保证数据一致性，确保即使在集群部分节点失效时，etcd 中的数据依然是可靠的。

Scheduler

调度器，负责：将新创建的 Pod 分配到合适的 Node 节点上。

Scheduler 根据资源使用情况，比如：（CPU、内存等）、拓扑信息（网络、节点可用性...等等），以及调度策略进行选择。

Controller Manager

Controller Manager ，是 K8S 中的控制器执行者，负责：管理各种控制器。

例如：副本控制器、节点控制器、服务控制器...等，如下图所示：

图片

Controller Manager，负责：管理集群的控制循环，包括：节点状态监控、Pod 副本数量维护、处理故障节点。。。等。

Controller Manager ，通过循环检查集群的当前状态，并与期望状态进行比较。

如果存在不一致的地方，控制器会启动相应的操作以纠正实际状态。

比如：ReplicaSet 控制器会确保在任何时刻，Pod 的副本数都、与用户定义的副本数一致。

Node 节点

Node节点，也称为工作节点，负责运行具体的容器化应用，接受 Master 的任务调度。

图片

K8S的工作流程，大致如下：

1. 创建和提交资源定义：用户通过 YAML 文件或 kubectl 命令，提交 Deployment 、或 Pod 等资源定义到 API Server；
2. API Server 处理请求：API Server 验证请求，并将资源定义保存到 etcd，确保资源定义的持久性；
3. 调度和部署：检测到新创建的 Pod，并通过资源调度策略选择合适的 Node 节点；
4. 监控与维护：Controller Manager 持续监控集群状态，出现异常时自动重启、或重新调度。

这些组件共同合作，确保 K8S 集群的资源管理、调度、监控和自愈功能顺利运行。