k8s学习之路 | Day5 kubernetes架构原理

跟着官网看基础架构

官网参考地址：https://kubernetes.io/zh-cn/docs/concepts/overview/components/

k8s 组件

k8s 集群的组件：一个正常运行的 k8s 集群所需的各种组件

控制平面组件（Control Plane Components）

控制平面组件会为集群做出全局决策，比如资源的调度。 以及检测和响应集群事件，例如当不满足部署的 replicas 字段时， 要启动新的 pod）。

控制平面组件可以在集群中的任何节点上运行。 然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件， 并且不会在此计算机上运行用户容器。

kube-apiserver

API 服务器是 Kubernetes 控制平面的组件， 该组件负责公开了 Kubernetes API，负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端。

Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。 你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。

etcd

一致且高可用的键值存储，用作 Kubernetes 所有集群数据的后台数据库

k8s 集群所有的环境数据都保存在 etcd 数据库中

kube-scheduler

负责监视新创建的、未指定运行节点（node）的 Pods， 并选择节点来让 Pod 在上面运行。

调度决策考虑的因素包括单个 Pod 及 Pods 集合的资源需求、软硬件及策略约束、 亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。

kube-controller-manager

负责运行控制器进程，从逻辑上讲， 每个控制器都是一个单独的进程， 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。

• 节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应
• 任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
• 端点分片控制器（EndpointSlice controller）：填充端点分片（EndpointSlice）对象（以提供 Service 和 Pod 之间的链接）。
• 服务账号控制器（ServiceAccount controller）：为新的命名空间创建默认的服务账号（ServiceAccount）。

cloud-controller-manager

云控制器管理器（Cloud Controller Manager）允许你将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。cloud-controller-manager 仅运行特定于云平台的控制器。

下面的控制器都包含对云平台驱动的依赖：

• 节点控制器（Node Controller）：用于在节点终止响应后检查云提供商以确定节点是否已被删除
• 路由控制器（Route Controller）：用于在底层云基础架构中设置路由
• 服务控制器（Service Controller）：用于创建、更新和删除云提供商负载均衡器

node 组件

节点组件会在每个节点上运行，负责维护运行的 Pod 并提供 Kubernetes 运行环境

kubelet

• 集群中的每一个 node 上运行，保证容器都运行在 Pod 中
• kubelet 接收一组通过各类机制提供给它的 PodSpecs， 确保这些 PodSpecs 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器

kube-proxy

• 集群中每个节点（node）上所运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分
• 维护节点上的一些网络规则， 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信

容器运行时（Container Runtime）

容器运行环境是负责运行容器的软件

插件（Addons）

插件使用 Kubernetes 资源（DaemonSet、 Deployment 等）实现集群功能。 因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 kube-system 命名空间。

• DNS
• Dashboard
• 容器资源监控
• …

再来一遍基础架构

集群架构

工作原理

集群

主从：

• 主从复制的（mysql主从同步）
• 主管理从的（k8s）

分片：

• 大家都一样的
• 但是每个人存的都是一部分东西

而对于 k8s 来说，属于主管理从的集群架构

• Master：主节点，可能一个，可能多个
• Node：worker 节点，工作节点，有很多个，是真正干应用的活

Master 与 Node 如何进行交互？

1. Master 决定 worker 里面都有什么
2. worker 只是和 Master（API）通信，这个 API 通信也可以给别人使用（UI、CLI）
3. 每一个节点自己干自己的活

我们使用 UI 或者 CLI 命令行操作 k8s 集群的 Master，就可以知道整个集群的状况

• Matser 管理的 Node 节点

部署一个应用的流程

对于官网的组件图来说：

master节点（Control Plane【控制面板】）：master节点控制整个集群

master节点上有一些核心组件：

• Controller Manager：控制管理器
• etcd：键值数据库（redis）
• scheduler：调度器
• api server：api网关（所有的控制都需要通过api-server）-------性能瓶颈

node节点（worker工作节点）：

• kubelet（监工）：每一个node节点上必须安装的组件。
• kube-proxy：代理，代理网络

部署一个应用的大致流程

我来操作：调用CLI告诉master，我们现在要部署一个tomcat应用

• 所有调用都先去master节点的网关api-server。这是matser的唯一入口
• 收到的请求先交给master的api-server。由api-server交给controller-mannager进行控制
• controller-mannager 进行应用部署
• controller-mannager 会生成一次部署信息。 tomcat --image:tomcat6 --port 8080 ,真正不部署应用
• 部署信息被记录在etcd中
• scheduler调度器从etcd数据库中，拿到要部署的应用，开始调度。看哪个节点合适
• scheduler把算出来的调度信息再放到etcd中
• 每一个node节点的监控kubelet，随时和master保持联系的（给api-server发送请求不断获取最新数据），所有节点的kubelet就会从master
• 假设node2的kubelet最终收到了命令，要部署
• kubelet就自己run一个应用在当前机器上，随时给 master 汇报当前应用的状态信息，分配ip，node与node是不需要联系的
• node 和 master 是通过 maste r的 api-server 联系的
• 每一个机器上的 kube-proxy 能知道集群的所有网络。只要 node 访问别人或者别人访问 node，node 上的 kube-proxy 网络代理自动计算进行流量转发

再来一个图加深印象：

原理分解

主节点（Master）

工作节点（Node）

组件交互原理

核心组件交互

0. 初始状态：

所有节点的 kubelet、master 节点的 scheduler（调度器）、controller-manager（控制管理器）一直监听 master 的 api server 发来的事件变化（for ::）

1. 创建一个应用：

使用命令行工具： kubectl 部署应用

kubectl create deploy tomcat --image=tomcat8（告诉master让集群使用 tomcat镜像，部署一个 tomcat 应用）

2. 创建信息保存在 etcd：

kubectl 命令行内容发给 api server，api server 保存此次创建信息到 etcd

3. etcd 上报创建事件：

etcd 给 api-server上报事件，说刚才有人给我里面保存一个信息：要部署 tomcat[deploy]

4. api server 上报事件：

controller-manager 监听到 api server 的事件，是 （部署tomcat[deploy]）

5. controller-manager 处理部署事件：

controller-manager 处理此次部署事件，并且会生成 Pod 的部署信息

6. 再次将 Pod 部署信息保存在 etcd：

controller-manager 把 Pod 的信息交给 api server，再保存到 etcd

7. etcd 再次上报事件：

etcd 上报事件（有一个新的Pod创建信息）报给 api server

8. api server 再次上报事件：

scheduler 专门监听[pod信息] ，拿到的内容后进行内部计算，看哪个节点合适部署这个 Pod，并生成这个【节点部署信息】

9. 10 将节点部署信息保存在 etcd 中

scheduler 把【节点部署信息】交给 api-server 并保存到 etcd

11. etcd再次上报事件：

【这里有个节点运行 pod 的事件】上报给 api server

12. kubelet 判断事件：

每个节点的 kubelet 判断是否属于自己的事情；属于他的就使用 kubelet 启动这个 Pod，最后会将启动好信息汇报给 master

核心组件通信协议

CNI

容器网络接口（Container Network Interface），是 CNCF 旗下的一个项目，由一组用于配置 Linux 容器的网络接口的规范和库组成，同时还包含了一些插件。

• 仅关心容器创建时的网络分配
• 容器被删除时的网络释放

CRI

容器运行时接口（Container Runtime Interface），CRI 中定义了容器和镜像的服务的接口，因为容器运行时与镜像的生命周期是彼此隔离的，因此需要定义两个服务。该接口使用 Protocol Buffer，基于 gRPC。

OCI

容器规范（Open Container Initiative），2015年6月22日，Docker、CoreOS、Google、RedHat等公司共同宣布：Docker公司将Libcontainer捐出，并改名RunC项目，交由一个中立的基金会管理。然后以RunC为依据，共同制定一套容器和镜像的标准和规范。

---

Protobuf

1. Google Protocol Buffer(简称 Protobuf )是一种轻便高效的结构化数据存储格式，平台无关、语言无关、可扩展，可用于通讯协议和数据存储等领域.。

2. 后起之秀，是谷歌开源的一种数据格式，适合高性能，对响应速度有要求的数据传输场景。因为 profobuf 是二进制数据格式，需要编码和解码。数据本身不具有可读性。因此只能反序列化之后得到真正可读的数据。

   • 序列化后体积相比Json和XML很小，适合网络传输
   • 跨平台
   • 多语言
   • 兼容性好
   • 序列化反序列化速度很快，快于Json的处理速度

gRPC

gRPC (gRPC Remote Procedure Calls) 是 Google 发起的一个开源远程过程调用系统，该系统基于 HTTP/2 协议传输

JSON

JSON（JavaScript Object Notation, JS对象简谱）是一种轻量级的数据交换格式。简洁和清晰的层次结构使得 JSON 成为理想的数据交换语言。 易于人阅读和编写，同时也易于机器解析和生成，并有效地提升网络传输效率。