Kubernetes 架构-里奥的博客

视频观看地址： https://open.douyin.com/player/video?vid=7364265076712312127&autoplay=0

概述

Kubernetes 这个名字源于希腊语，意为“舵手”或“飞行员”。K8s 这个缩写是因为 K 和 s 之间有 8 个字符的关系。K8s 是一个用于大规模运行分布式应用和服务的开源容器 编排平台。

Kubernetes 集群是一组用于运行容器化应用的节点计算机。如果您正在运行 Kubernetes，那么您运行的其实就是集群。

集群至少包含一个控制平面，以及一个或多个计算机器或节点。控制平面负责维护集群的预期状态，例如运行哪个应用以及使用哪个容器镜像。节点则负责应用和工作负载的实际运行。

下图为稍微详细一点的架构示意图

Kubernetes 集群的神经中枢（即控制平面）用于控制集群的 Kubernetes 组件以及一些有关集群状态和配置的数据。这些核心 Kubernetes 组件负责处理重要的工作，以确保容器以足够的数量和所需的资源运行。

Kubernetes 采用了现今流行的“控制面 / 数据面”（Control Plane / Data Plane）架构，集群里的计算机被称为“节点”（Node），可以是实机也可以是虚机，少量的节点用作控制面来执行集群的管理维护工作，其他的大部分节点都被划归数据面，用来跑业务应用。

控制面的节点在 Kubernetes 里叫做 Master Node，一般简称为 Master，它是整个集群里最重要的部分，可以说是Kubernetes 的大脑和心脏。
数据面的节点叫做 Worker Node，一般就简称为 Worker 或者 Node，相当于 Kubernetes 的手和脚，在 Master 的指挥下干活

Master 里有 4 个组件，分别是 apiserver、etcd、scheduler、controller-manager。

apiserver 是 Master 节点——同时也是整个 Kubernetes 系统的唯一入口，它对外公开了一系列的 RESTful API，并且加上了验证、授权等功能，所有其他组件都只能和它直接通信，可以说是 Kubernetes 里的联络员。负责集群中所有组件通信，访问它必须经过授权于认证。
etcd 是一个高可用的分布式 Key-Value 数据库，用来持久化存储系统里的各种资源对象和状态，相当于 Kubernetes 里的配置管理员。注意它只与 apiserver 有直接联系，也就是说任何其他组件想要读写 etcd 里的数据都必须经过 apiserver。
scheduler 负责容器的编排工作，检查节点的资源状态，把 Pod 调度到最适合的节点上运行，相当于部署人员。因为节点状态和 Pod 信息都存储在 etcd 里，所以 scheduler 必须通过 apiserver 才能获得。
controller-manager 负责维护容器和节点等资源的状态，实现故障检测、服务迁移、应用伸缩等功能，相当于监控运维人员。同样地，它也必须通过 apiserver 获得存储在 etcd 里的信息，才能够实现对资源的各种操作。

Kubernetes 通过将容器放入在节点（Node）上运行的 Pod 中来执行你的工作负载。节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。每个节点包含运行 Pod 所需的服务；这些节点由控制面负责管理。

通常集群中会有若干个节点；而在一个学习所用或者资源受限的环境中，你的集群中也可能只有一个节点。

节点上的组件包括 kubelet、容器运行时（container-runtime）以及 kube-proxy。

kubelet 是 Node 的代理，负责管理 Node 相关的绝大部分操作，Node 上只有它能够与 apiserver 通信，实现状态报告、命令下发、启停容器等功能，相当于是 Node 上的一个“小管家”。工作节点的核心部分。新工作节点加入节点后，Kubelet 会被部署到新节点，然后 Kubelet 将当前节点注册到集群中。它还有一个职责，监听 API Server 分配的任务，监听到就执行该任务，并维护一个与控制平面的通信频道。
kube-proxy 的作用有点特别，它是 Node 的网络代理，只负责管理容器的网络通信，简单来说就是为 Pod 转发 TCP/UDP 数据包，相当于是专职的“小邮差”。
container-runtime 是容器和镜像的实际使用者，在 kubelet 的指挥下创建容器，管理 Pod 的生命周期，是真正干活的“苦力”。工作节点需要通过它来获取、启动、停止执行任务依赖的容器，它负责容器管理与运行逻辑。

因为 Kubernetes 的定位是容器编排平台，所以它没有限定 container-runtime 必须是 Docker，完全可以替换成任何符合标准的其他容器运行时，例如 containerd、CRI-O 等等

这 3 个组件中只有 kube-proxy 被容器化了，而 kubelet 因为必须要管理整个节点，容器化会限制它的能力，所以它必须在 container-runtime 之外运行。

CRI 是一个插件接口，它使 kubelet 能够使用各种容器运行时，无需重新编译集群组件。
你需要在集群中的每个节点上都有一个可以正常工作的容器运行时，这样 kubelet 能启动 Pod 及其容器。
容器运行时接口（CRI）是 kubelet 和容器运行时之间通信的主要协议。
Kubernetes 容器运行时接口（Container Runtime Interface；CRI）定义了主要 gRPC 协议，用于节点组件 kubelet 和容器运行时之间的通信。

每个 Node 上的 kubelet 会定期向 apiserver 上报节点状态，apiserver 再存到 etcd 里。
每个 Node 上的 kube-proxy 实现了 TCP/UDP 反向代理，让容器对外提供稳定的服务。
scheduler 通过 apiserver 得到当前的节点状态，调度 Pod，然后 apiserver 下发命令给某个 Node 的 kubelet，kubelet 调用 container-runtime 启动容器。
controller-manager 也通过 apiserver 得到实时的节点状态，监控可能的异常情况，再使用相应的手段去调节恢复。

集群里的计算机被称为“节点”（Node），可以是实机也可以是虚机
Master节点用作控制面来执行集群的管理维护工作，Worker 或者 Node用来跑业务应用
Master 里有 4 个组件，分别是 apiserver、etcd、scheduler、controller-manager。这 4 个组件也都被容器化了
Node 里有 3 个组件，分别是 kubelet、kube-proxy、container-runtime。这 3 个组件中只有 kube-proxy 被容器化了
kubelet 和容器运行时之间通过容器运行时接口(CRI)通信。
container-runtime 可以是任何符合标准的容器运行时，例如 containerd、CRI-O、Docker 等等