k8s架构简介 | Forrest’s 博客

type

status

date

slug

summary

Kubernetes是什么

Kubernetes 这个名字源于希腊语，意为舵手、飞行员。由于第一个字母K和最后一个字母s之间有八个字符的关系，所以一般缩写成 K8s。

k8s源于google内部的管理系统Borg。过去十几年来google一直使用Borg系统管理内部数量巨大的应用程序集群。Borg基于容器，目的是实现资源的管理自动化，提升跨多个数据中心的资源利用率，由于k8s汲取了Borg的经验和教训，设计理念比较成熟，得到了开源社区的热烈追捧。

k8s是一个跨多主机的容器编排平台，它使用共享网络将多个主机构成一个统一的集群，使得其中一个活少量几个主机当作主节点，作为集群的控制中心，剩下的主机当作工作节点，负责常规任务的执行。

部署环境的演变历程

物理机时代

早期软件的架构多是单体服务，一个系统的所有功能都运行在同一个进程中，应用程序直接拷贝、部署到物理机，并在物理机上运行。这种方式有很多的缺点

部署麻烦：应用需要的依赖环境需要提前在主机上安装，即使应用在测试环境验证完毕，部署到生产环境时也容易遇到环境依赖造成的事故；

资源无法隔离：多个应用部署在同一个主机上，资源没有隔离，容易导致一个应用耗光了主机的某个资源，导致其他应用无法运行；

资源利用率低：多个应用部署在同一个主机时，应用无法使用同一个端口，即使主机有足够多的计算资源，但也无法部署多个实例来提供服务；

虚拟机时代

作为解决方案，引入了虚拟化技术。虚拟化技术允许一台物理机上运行多个虚拟机，运行在不同的虚拟机上的不同应用程序之间会被隔离。虚拟化技术可以更好的利用物理机的资源，可以通过监控手段，进行自身的伸缩性，添加对应的应用实例，提高系统的资源利用率。但虚拟机未解决部署麻烦的问题，随着时代的发展，应用部署到了容器时代。

容器时代

容器类似于虚拟机，具有自己的文件系统、CPU、内存和进程空间等资源。容器镜像时容器等精髓，他可以保证应用在各个环境的运行时一致。容器镜像可以上传镜像仓库，并且可以在任意节点拉取镜像。和虚拟机相比，容器的优势是它基于进程，而非像虚拟机一样需要模拟一个完整的操作系统，因此启动更快、占用资源少、更好的解决运行时环境和应用程序分发部署的问题。

k8s的主要功能

集群管理：将多个物理机或虚拟机构建成协同运行的集群，并将这些硬件基础设施抽象成一个统一的资源池

应用部署：支持跨主机的自动化容器部署应用；允许多个版本的应用并存；同时提供滚动更新、回滚等功能

资源隔离：支持为租户、项目或应用进行隔离访问

自我修复：使用声明式配置，利用状态检测和重启、驱逐等机制确保容器的健康运行

自动伸缩：支持应用实例的甚至机器节点的自动伸缩，来满足弹性需求

服务发现和负载均衡：为容器分配IP地址和DNS名称；自动进行服务注册和服务发现；实现内部负载均衡，实现的流量合理分配

存储编排：支持多种存储系统（本地存储、云端存储等）；提供持久化存储等能力，可以去管理存储的生命周期

网络管理：支持集群内部的通信；pod间的网络互联；支持多种网络插件；支持配置网络策略

Kubernetes的核心组件

Kubernetes在设计上分为控制平面和工作节点

控制平面

kube-api-server

kube-api-server的核心功能是提供k8s各类型资源对象的CRUD以及watch等HTTP REST的接口。它是集群中各个模块之间的数据交互和通信的中心枢纽配，是整个k8s系统的数据总线和数据中心。除此之外,它还有一下功能特性：

是集群管理API的入口

是资源配额控制的入口

提供了完备的集群管理安全机制

api-sever的架构从上到下可以分为这几层

API层：主要以REST方式提供各种API，除了k8s资源的CRUD和watch等主要API，还有健康检查、UI、日志、性能指标等监控运维相关的

访问控制层：包括认证来解决【你是谁】、授权来解决【你能做什么】、准入控制来完成校验参数和修改配置的工作

注册表层：将k8s集群中的所有资源给出定义，即资源对象的类型、如何创建资源对象、如何转换不同的版本、如何将资源对象进行编码和解码

etcd存储层：用户持久化存储k8s中的资源对象

etcd

etcd 是 CoreOS 基于 Raft 一致性协议实现的分布式键值数据库，用于存储 Kubernetes 集群的所有状态数据，如集群的配置信息、服务发现信息和资源的状态等。

在 Kubernetes 中，所有资源对象（如 Pod、Service、Deployment）的定义和状态最终都会存储到 etcd 中。当集群中的资源对象发生变更时，etcd 会通过其提供的 Watch API 通知 kube-apiserver，从而实现集群状态的及时同步。基于这种 Watch 机制，各种 Kubernetes 组件能够高效协作，保持系统状态一致性。

kube-controller-manager

kube-controller-manager 是 Kubernetes 的核心控制平面组件之一，它负责管理所有控制器（Controller）的运行，这些控制器的职责是维护集群的期望状态与实际状态一致。kube-controller-manager 从 etcd 获取集群的状态信息（通过 kube-apiserver），并根据定义好的控制逻辑，对集群状态进行调整，例如创建或删除 Pod、更新资源状态等。

常见的控制器包括：

Node Controller：负责管理节点的生命周期，例如检测节点是否不可用。

Replication Controller：负责维护 Pod 的副本数与用户期望的一致。

Endpoint Controller：填充服务和 Pod 之间的关联信息。

Service Account Controller：为新创建的命名空间分配默认的 Service Account。

kube-scheduler

kube-scheduler 是 Kubernetes 的调度器，负责将调度未绑定节点的 Pod 分配到合适的节点上。它是 Kubernetes 控制平面中至关重要的组件之一。

核心功能：

Pod 分配：kube-scheduler 根据调度策略和约束条件（如节点的资源情况、Pod 的亲和性和反亲和性规则等），为待调度的 Pod 找到最佳节点。

资源评估：在调度过程中，kube-scheduler 会首先过滤掉不符合要求的节点，然后根据调度算法为剩余节点打分，最终选择得分最高的节点。

调度结果存储：当 kube-scheduler 完成调度后，会将 Pod 的绑定结果（即分配的节点信息）记录到 etcd 中，并通过 kube-apiserver 通知 kubelet 执行后续操作。

工作节点

工作节点是 Kubernetes 中实际运行应用程序容器的节点。每个工作节点都运行以下关键组件：

kubelet

kubelet 是工作节点上的核心代理程序，负责与 Kubernetes 控制平面进行通信，并管理本节点上的容器生命周期。

核心职责：

Pod 生命周期管理：kubelet 通过 kube-apiserver 获取调度后的 Pod 定义信息，并调用容器运行时（如 Docker、containerd）来启动、停止和删除容器。

健康检查：kubelet 定期检查节点上容器的健康状况。如果某个容器状态异常，kubelet 会根据定义的重启策略重新启动容器。

资源报告：kubelet 定期向 kube-apiserver 汇报本节点的资源使用情况（如 CPU、内存使用）。

日志和监控：kubelet 还负责收集节点日志信息，并将其传递给上层监控系统。

kube-proxy

kube-proxy 是工作节点上的网络代理，负责管理 Pod 的网络通信。它为 Kubernetes 集群提供了以下功能：

服务负载均衡：kube-proxy 为每个 Service 创建一个虚拟 IP（ClusterIP），并将流量转发到后端 Pod，实现负载均衡。

网络规则管理：kube-proxy 使用 iptables 或 IPVS 在节点上配置网络规则，确保集群内的 Pod 和 Service 能够互相通信。

跨节点通信：kube-proxy 配合 CNI 插件，允许不同节点上的 Pod 通过 Kubernetes 网络实现跨节点通信。

容器运行时

容器运行时负责在工作节点上运行和管理容器。Kubernetes 支持多种容器运行时，常见的有：

Docker：早期的主流容器运行时，但 Kubernetes 已逐步将其替换。

containerd：由 Docker 项目分离出来的轻量级容器运行时。

CRI-O：专门为 Kubernetes 开发的容器运行时，直接支持 CRI 接口。

其他 CRI 兼容运行时：如 Kata Containers，适用于安全性需求较高的场景。

容器运行时的主要职责：

下载和管理镜像。

启动、停止和删除容器。

提供容器的日志和监控接口。

Kubernetes 通过 CRI（Container Runtime Interface）与容器运行时通信，从而实现容器的标准化管理。

集群模块之间的沟通

这么多的组件，他们是如何分工协作的？以Deployment为例，看看大致的流程图

用户或控制器通过kubectl、RestAPI 或其他客户端向API Server发器创建Deployment 的请求

API Server作为集群的网关，收到用户创建Deploymet的请求后，经过认证、鉴权、准入控制三个环节，将Deployment对象存到etcd中

Controller Manager 中的Deployment Controller监听到Deployment的变更后，在收到该 Deployment 对象的创建事件后，Deployment Controller 会检查当前 namespace 中所有的 ReplicaSet 对象，判断是否存在 ReplicaSet 对象的 OwnerReference 属性为该 Deployment 对象。如果没有的话，Deployment Controller 会向 API Server 发起创建 ReplicaSet 对象的请求，经过 API Server 的检查后，将该 ReplicaSet 对象保存在 etcd 中

同上，Controller Manager 中的 ReplicaSet Controller 会监听 API Server 中所有 ReplicaSet 对象的变更。在收到该 ReplicaSet 对象的创建事件后，ReplicaSet Controller 会检查当前 namespace 中所有的 Pod 对象，判断是否存在 Pod 对象的 OwnerReference 属性为该 ReplicaSet 对象。如果没有的话，ReplicaSet Controller 会向 API Server 发起创建 Pod 对象的请求，经过 API Server 的检查后，将该 Pod 对象保存在 etcd 中

随后 Scheduler 监听到 API Server 中新的 Pod 对象被创建后，它会查看 Pod 是否已经被调度（检查spece.nodeName是否为空），如果该 Pod 并没被调度到任何节点上时，Scheduler 会给它分配一个最优节点，并更新 Pod 对象的 spec.nodeName 属性，随后该 Pod 对象被同步回 API Server 里，并保存在 etcd 中

最后节点中的 kubelet 会一直监听 API Server 的 Pod 资源变化，当其发现有新的 Pod 对象分配到所在节点时，kubelet 将会以 grpc 的形式，通过 CRI 向容器运行时创建容器

🛻k8s架构简介