k8s 到底是什么，架构是怎么样的？

报错小能手

318人浏览 · 2026-06-21 22:27:16

报错小能手 · 2026-06-21 22:27:16 发布

你是一个程序员，你用代码写了一个博客应用服务，并将它部署在了云平台上。
但应用服务太过受欢迎，访问量太大，经常会挂。

所以你用了一些工具自动重启挂掉的应用服务，并且将应用服务部署在了好几个服务器上，总算抗住了。

后来你又上线了商城应用服务和语音应用服务，随着应用服务变多，需求也千奇百怪。有的应用服务不希望被外网访问到，有的部署的时候要求内存得大于 xxGB 才能正常跑。
你每次都需要登录到各个服务器上，执行手动操作更新。不仅容易出错，还贼浪费时间。

原本就没时间找女朋友的你，现在哭得更大声了。

那么问题就来了，有没有一个办法，可以解决上面的问题？当然有，没有什么是加一个中间层不能解决的，如果有，那就再加一层。
这次我们要加的中间层，叫 Kubernetes。

Kubernetes的位置

Kubernetes 是什么？

Kubernetes，它是 G 家开源的神器，因为单词太长，所以我们习惯省略中间 8 个字母，简称它为 k8s。

k8s名称的由来

它介于应用服务和服务器之间，能够通过策略，协调和管理多个应用服务，只需要一个 yaml 文件配置，定义应用的部署顺序等信息，就能自动部署应用到各个服务器上，还能让它们挂了自动重启，自动扩缩容。

听起来有些厉害，它是怎么实现这些功能的呢？

Kubernetes 架构原理

为了实现上面的功能，Kubernetes 会将我们的服务器划为两部分，一部分叫控制平面（control plane，以前叫master），另一部分叫工作节点，也就是 Node。简单来说它们的关系就是老板和打工人，用现在流行的说法就是训练师和帕鲁。控制平面负责控制和管理各个 Node，而 Node 则负责实际运行各个应用服务。

k8s控制平面和Node的关系

我们依次看下这两者的内部架构。

控制平面内部组件

• 以前我们需要登录到每台服务器上，手动执行各种命令，现在我们只需要调用 k8s 的提供的 api 接口，就能操作这些服务资源，这些接口都由 API Server 组件提供。
• 以前我们需要到处看下哪台服务器 cpu 和内存资源充足，然后才能部署应用，现在这部分决策逻辑由 Scheduler（调度器）来完成。
• 找到服务器后，以前我们会手动创建，关闭服务，现在这部分功能由 Controller Manager（控制器管理器）来负责。
• 上面的功能都会产生一些数据，这些数据需要被保存起来，方便后续做逻辑，因此 k8s 还会需要一个存储层，用来存放各种数据信息，目前是用的 etcd，这部分源码实现的很解耦，后续可能会扩展支持其他中间件。

以上就是控制平面内部的组件。

k8s控制平面组件

我们接下来再看看 Node 里有哪些组件。

Node 内部组件

Node 是实际的工作节点，它既可以是裸机服务器，也可以是虚拟机。它会负责实际运行各个应用服务。多个应用服务共享一台 Node 上的内存和 CPU 等计算资源。

Node可以是裸机服务器或虚拟机

在文章开头，我们聊到了部署多个应用服务的场景。以前我们需要上传代码到服务器，而用了 k8s 之后，我们只需要将服务代码打包成Container Image(容器镜像)，就能一行命令将它部署。

如果你不了解容器镜像的含义，你可以简单理解为它其实就是将应用代码和依赖的系统环境打了个压缩包，在任意一台机器上解压这个压缩包，就能正常运行服务。为了下载和部署镜像，Node 中会有一个 Container runtime 组件。

将容器镜像粗略理解为压缩包

每个应用服务都可以认为是一个 Container（容器）, 并且大多数时候，我们还会为应用服务搭配一个日志收集器 Container 或监控收集器 Container，多个 Container 共同组成一个一个 Pod，它运行在 Node 上。

一个pod内有多个容器

k8s 可以将 pod 从某个 Node 调度到另一个 Node，还能以 pod 为单位去做重启和动态扩缩容的操作。
所以说 Pod 是 k8s 中最小的调度单位。

Node调度Pod

另外，前面提到控制平面会用 Controller Manager （通过API Server）控制 Node 创建和关闭服务，那 Node 也得有个组件能接收到这个命令才能去做这些动作，这个组件叫 kubelet，它主要负责管理和监控 Pod。最后，Node 中还有个 Kube Proxy ，它负责 Node 的网络通信功能，有了它，外部请求就能被转发到 Pod 内。

控制平面和Node的组件

Cluster

控制平面和Node 共同构成了一个 Cluster，也就是集群。在公司里，我们一般会构建多个集群, 比如测试环境用一个集群，生产环境用另外一个集群。同时，为了将集群内部的服务暴露给外部用户使用，我们一般还会部署一个入口控制器，比如 Ingress 控制器（比如Nginx），它可以提供一个入口让外部用户访问集群内部服务。

生产和测试环境

kubectl 是什么

上面提到说我们可以使用 k8s 提供的 API 去创建服务，但问题就来了，这是需要我们自己写代码去调用这些 API 吗？答案是不需要，k8s 为我们准备了一个命令行工具 kubectl，我们只需要执行命令，它内部就会调用 k8s 的 API。

kubectl调用k8s的API

接下来我们以部署服务为例子，看下 k8s 是怎么工作的。

怎么部署服务？

首先我们需要编写 YAML 文件，在里面定义 Pod 里用到了哪些镜像，占用多少内存和 CPU 等信息。然后使用 kubectl 命令行工具执行 kubectl apply -f xx.yaml ，此时 kubectl 会读取和解析 YAML 文件，将解析后的对象通过 API 请求发送给 Kubernetes 控制平面内的 API Server。API Server 会根据要求，驱使 Scheduler 通过 etcd 提供的数据寻找合适的 Node， Controller Manager 会通过 API Server 控制 Node 创建服务，Node 内部的 kubelet 在收到命令后会开始基于 Container runtime 组件去拉取镜像创建容器，最终完成 Pod 的创建。

至此服务完成创建。

部署应用服务

整个过程下来，我们只需要写一遍 yaml 文件，和执行一次 kubectl 命令，比以前省心太多了！部署完服务后，我们来看下服务是怎么被调用的。

怎么调用服务？

以前外部用户小明，直接在浏览器上发送 http 请求，就能打到我们服务器上的 Nginx，然后转发到部署的服务内。用了 k8s 之后，外部请求会先到达 Kubernetes 集群的 Ingress 控制器，然后请求会被转发到 Kubernetes 内部的某个 Node 的 Kube Proxy 上，再找到对应的 pod，然后才是转发到内部容器服务中，处理结果原路返回，到这就完成了一次服务调用。

用户调用k8s内应用服务的流程

到这里我们就大概了解了 k8s 的工作原理啦，它本质上就是应用服务和服务器之间的中间层，通过暴露一系列 API 能力让我们简化服务的部署运维流程。

并且，不少中大厂基于这些 API 能力搭了自己的服务管理平台，程序员不再需要敲 kubectl 命令，直接在界面上点点几下，就能完成服务的部署和扩容等操作，是真的嘎嘎好用。

总结

• k8s 是 G 家开源的神器，用于管理海量容器服务。
• k8s 集群内分为控制平面和 Node，控制平面是大脑，负责发指令，Node 是手脚，负责执行任务。
• 控制平面内有 API Server，Scheduler，Controller Manager 以及 etcd 等组件。Node 中含有 Pod，Kubelet,Container runtime, Kube Proxy 等组件。控制平面和 Node 共同构成一个 Cluster。
• 文章通过怎么部署服务和怎么调用服务两个例子将这些组件串联了起来，方便大家加深理解。

Kubernetes（K8s）全面详解

Kubernetes（常简称 K8s，名字源于首字母 K + 中间 8 个字母 + 尾字母 s）是目前行业事实标准的容器编排与集群管理平台，核心解决「大规模容器如何跨主机部署、自动运维、弹性伸缩、服务治理」的问题。

简单类比：Docker 负责管理单个容器，相当于给应用打包、启动；而 K8s 负责管理成百上千台机器上的海量容器，相当于一个自动化的容器 “数据中心操作系统”。

一、整体架构总览

K8s 采用经典的控制面 - 数据面（Master-Worker）分布式架构，集群由两类节点组成：

控制平面（Master 节点）：集群的 “大脑”，负责全局决策、调度、状态维护、API 接入，不运行业务容器。
工作节点（Worker 节点）：集群的 “干活的工人”，真正运行业务容器，接收并执行控制面的指令。

所有组件之间不直接互相通信，全部统一通过 kube-apiserver 交互，数据全部持久化在 etcd 中，整体架构高度解耦。

二、控制平面（Master）核心组件

控制平面是集群的管理中枢，通常由 3~5 台节点组成高可用集群，包含 5 个核心组件。

1. kube-apiserver（API 服务器）

集群的唯一入口，所有组件、所有用户操作都必须通过它。

对外提供 RESTful API，验证并处理所有请求（kubectl 命令、组件内部调用都走这里）。
是唯一能直接操作 etcd 的组件，其他组件都不能直接读写数据。
自带鉴权、授权、准入控制机制，是集群安全的第一道关卡。

2. etcd

分布式、强一致的键值存储数据库，是集群的 “数据库”。

保存集群所有元数据：节点信息、Pod 配置、Service 规则、配置密钥等所有状态数据。
是集群状态的唯一真实来源，控制面所有决策都基于 etcd 中的数据。
生产环境必须部署 3 或 5 节点的 etcd 集群，保证高可用。

3. kube-scheduler（调度器）

集群的 “调度专员”，负责给新创建的 Pod 分配具体的 Worker 节点。

监听尚未分配节点的 Pod，按照预设规则筛选出所有符合条件的节点。
通过打分算法（资源剩余量、亲和性规则、污点容忍、本地缓存等）选出最优节点。
只做 “分配决策”，不直接启动 Pod，决策结果写入 apiserver，由对应节点的 kubelet 执行。

4. kube-controller-manager（控制器管理器）

集群的 “运维自动化大脑”，运行着一系列控制器循环，核心逻辑是：不断对比 “期望状态” 和 “实际状态”，如果不一致就自动修正。常见的核心控制器：

节点控制器：监控节点故障，及时发现并处理离线节点。
副本控制器：保证 Deployment 对应的 Pod 副本数量始终符合预期。
端点控制器：维护 Service 和 Pod 之间的对应关系。
服务账号控制器：为新命名空间自动创建默认账号。

5. cloud-controller-manager（云控制器管理器）

可选组件，用于对接公有云厂商（阿里云、AWS 等）的 API。

让 K8s 可以直接调用云厂商能力创建负载均衡、云硬盘、VPC 网络等资源。
私有部署、物理机部署的集群通常不需要该组件。

三、工作节点（Worker）核心组件

Worker 节点是真正运行业务容器的机器，每个节点都必须运行以下 3 个核心组件。

1. kubelet

节点上的 “代理管家”，是 Master 在 Worker 节点上的代言人。

持续监听 apiserver，获取分配到本节点的 Pod 任务。
调用本机的容器运行时，完成 Pod 的创建、启动、停止、销毁全生命周期管理。
定期上报节点和 Pod 的健康状态、资源使用情况给 Master。
负责 Pod 的健康检查（存活探针、就绪探针），异常时自动重启容器。

2. kube-proxy

节点上的 “网络代理”，负责实现 Service 的网络规则与负载均衡。

监听 apiserver 中 Service 和 Endpoint 的变化。
在本机配置 iptables/ipvs 规则，实现 Service 虚拟 IP 到后端 Pod IP 的转发与负载均衡。
保证集群内任意节点都能通过 Service IP 访问到对应的后端服务。

3. 容器运行时（Container Runtime）

真正负责运行容器的底层组件，kubelet 通过 CRI（容器运行时接口）标准对接。

主流实现：containerd（目前 K8s 默认推荐）、CRI-O 等。
注意：Docker 本身已不是 K8s 默认运行时，1.24 版本后正式移除 dockershim；Docker 镜像依然可以正常运行，因为符合 OCI 标准。

四、核心资源对象

K8s 的所有操作本质都是对「资源对象」的操作，用户通过 YAML 文件声明对象的 “期望状态”，集群自动落地实现。以下是最常用的核心对象。

1. 基础调度单元：Pod

Pod 是 K8s 中最小的调度与部署单元，而不是容器。

一个 Pod 可以包含 1 个或多个容器，这些容器共享同一个网络命名空间（同一个 IP、端口空间）、共享存储卷。
Pod 是临时的、 disposable 的：故障、重启、调度都会导致 Pod 重建，IP 也会变化。
绝大多数场景下，一个 Pod 只跑一个业务容器；仅当有紧密耦合的辅助容器（如日志采集、配置同步 sidecar）时才多容器同 Pod。

2. 工作负载类对象

用于管理不同类型业务应用的部署与运行，是用户最常接触的上层对象。

资源对象	定位与适用场景	核心特点
Deployment	无状态应用部署（Web 服务、API 服务等）	最常用；支持滚动更新、版本回滚、水平扩缩容；通过 ReplicaSet 管理 Pod 副本
StatefulSet	有状态应用部署（数据库、分布式存储等）	Pod 有稳定的唯一标识、稳定的持久化存储、有序的部署 / 扩缩 / 删除顺序
DaemonSet	全节点部署（日志采集 Agent、监控 Agent、网络插件等）	每个 Worker 节点上自动运行一个 Pod 副本；新增节点时自动部署
Job	一次性任务（数据计算、批量处理）	Pod 运行完成后自动退出，保证任务成功执行
CronJob	定时任务（定时备份、定时报表）	基于 Cron 表达式周期性创建 Job 执行任务

3. 服务发现与网络对象

因为 Pod IP 不固定，K8s 通过以下对象提供稳定的服务访问能力。

Service：给一组 Pod 提供固定的虚拟访问入口（ClusterIP），自带四层负载均衡，后端 Pod 变化时自动更新转发规则。
- 常见类型：ClusterIP（集群内访问）、NodePort（节点端口暴露）、LoadBalancer（对接云厂商负载均衡）。
Ingress：七层 HTTP/HTTPS 路由入口，支持按域名、路径转发到不同 Service，是集群对外暴露 Web 服务的主流方式。
- Ingress 本身只是规则，需要配合 Ingress 控制器（如 Nginx Ingress）才能真正生效。

4. 存储对象

解决容器数据持久化、跨容器 / 跨 Pod 共享数据的问题。

Volume：Pod 级别的存储卷，生命周期和 Pod 一致，Pod 删除则数据丢失。
PersistentVolume（PV）：集群级别的持久化存储资源，由管理员提前创建，生命周期独立于 Pod。
PersistentVolumeClaim（PVC）：用户对存储的 “申请单”，声明需要的容量、读写模式，系统自动匹配可用的 PV。
StorageClass：定义存储类型，支持动态创建 PV，无需管理员提前批量预置。

5. 配置与密钥对象

实现配置与镜像解耦，不用改镜像就能修改配置。

ConfigMap：存储非敏感的配置信息（环境变量、配置文件内容），可挂载到 Pod 中使用。
Secret：存储敏感信息（密码、密钥、证书），默认以 base64 编码存储，可通过加密方案进一步加固。

6. 命名空间（Namespace）

集群内部的逻辑隔离单元，相当于 “虚拟子集群”。

可以将开发、测试、生产环境用不同 Namespace 隔开。
支持基于 Namespace 做资源配额、权限控制。
注意：Node、PV 等底层资源不属于任何 Namespace，是集群全局的。

五、核心设计理念与机制

1. 声明式 API

K8s 最核心的设计思想：用户只需要在 YAML 中声明 “我想要什么状态”，集群自动想办法达到这个状态。

对比：传统运维是「命令式」—— 执行一条条命令一步步部署；K8s 是「声明式」—— 描述最终目标，平台自动执行。
优势：幂等、可重复、可版本管理，天然适合自动化和 GitOps 流程。

2. 控制器模式

所有运维自动化能力都基于「控制循环」实现：

监听资源的期望状态（来自 apiserver）
获取当前实际状态
对比差异，执行调和操作，让实际状态向期望状态对齐
循环往复

这就是 K8s “自愈能力” 的本质：Pod 挂了、节点挂了，控制器会自动重建补足，始终逼近用户声明的期望状态。

3. 标签与选择器（Label & Selector）

K8s 中资源之间的关联不靠 ID 绑定，全靠标签。

标签是键值对，给资源打标记（如 app=nginx、env=prod）。
选择器通过标签筛选资源，比如 Service 通过 selector: app=nginx 匹配所有带该标签的 Pod 作为后端。
非常灵活：可以按业务、环境、模块任意打标，支持复杂的筛选逻辑。

4. 滚动更新与灰度发布

以 Deployment 为例，滚动更新的逻辑是：

逐步启动新版本 Pod，确认就绪后，再逐步销毁旧版本 Pod。
整个过程服务不中断，可配置最大超发数、最大不可用数。
支持随时暂停、回滚到历史版本。

六、一次应用部署的完整执行流程

以用户执行 kubectl apply -f nginx-deployment.yaml 为例，串起所有组件的协作：

请求接入：kubectl 校验 YAML 后，将请求发送给 kube-apiserver。
认证与存储：apiserver 完成鉴权后，将 Deployment 配置写入 etcd。
控制器调和：Deployment 控制器监听到新的 Deployment 对象，创建对应数量的 ReplicaSet 和 Pod 模板。
调度决策：kube-scheduler 监听到未分配节点的 Pod，经过筛选打分，将 Pod 绑定到合适的 Worker 节点。
节点执行：对应 Worker 节点的 kubelet 监听到分配给自己的 Pod，调用容器运行时拉取镜像、启动容器。
健康检查：kubelet 执行 Pod 的存活和就绪探针，确认服务正常。
网络配置：Endpoint 控制器更新对应 Service 的后端端点，kube-proxy 更新本机转发规则，服务可被访问。
持续监控：各控制器持续监控状态，出现异常时自动修正，始终保持期望状态。

七、K8s 与 Docker 的关系辨析

很多初学者容易混淆二者，核心区别：

层级不同：Docker 是容器运行时，属于 “单机容器工具”；K8s 是容器编排平台，属于 “集群管理系统”。
能力边界：Docker 解决 “如何把应用打包成容器、在一台机器上跑起来”；K8s 解决 “如何把成千上万的容器在多台机器上管理好、稳定运行”。
对接关系：K8s 不直接运行容器，它通过 CRI 接口对接容器运行时；Docker 只是众多可对接的运行时之一，现在 K8s 主流运行时是 containerd。