k8s学习之路 | Day5 kubernetes架构原理
文章目录
- 跟着官网看基础架构
-
- k8s 组件
-
- 控制平面组件（Control Plane Components）
- node 组件
- 再来一遍基础架构
-
- 集群架构
-
- 工作原理
- 部署一个应用的流程
- 原理分解
-
- 主节点（Master）
- 工作节点（Node）
- 组件交互原理
-
- 核心组件交互
- 核心组件通信协议
跟着官网看基础架构
官网参考地址：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 如何进行交互？
- Master 决定 worker 里面都有什么
- worker 只是和 Master（API）通信，这个 API 通信也可以给别人使用（UI、CLI）
- 每一个节点自己干自己的活
我们使用 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）
组件交互原理
核心组件交互
- 初始状态：
所有节点的 kubelet、master 节点的 scheduler（调度器）、controller-manager（控制管理器）一直监听 master 的 api server 发来的事件变化（for ::）
- 创建一个应用：
使用命令行工具： kubectl 部署应用
kubectl create deploy tomcat --image=tomcat8（告诉master让集群使用 tomcat镜像，部署一个 tomcat 应用）
- 创建信息保存在 etcd：
kubectl 命令行内容发给 api server，api server 保存此次创建信息到 etcd
- etcd 上报创建事件：
etcd 给 api-server上报事件，说刚才有人给我里面保存一个信息：要部署 tomcat[deploy]
- api server 上报事件：
controller-manager 监听到 api server 的事件，是 （部署tomcat[deploy]）
- controller-manager 处理部署事件：
controller-manager 处理此次部署事件，并且会生成 Pod 的部署信息
- 再次将 Pod 部署信息保存在 etcd：
controller-manager 把 Pod 的信息交给 api server，再保存到 etcd
- etcd 再次上报事件：
etcd 上报事件（有一个新的Pod创建信息）报给 api server
- api server 再次上报事件：
scheduler 专门监听[pod信息] ，拿到的内容后进行内部计算，看哪个节点合适部署这个 Pod，并生成这个【节点部署信息】
- 10 将节点部署信息保存在 etcd 中
scheduler 把【节点部署信息】交给 api-server 并保存到 etcd
- etcd再次上报事件：
【这里有个节点运行 pod 的事件】上报给 api server
- 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
-
Google Protocol Buffer(简称 Protobuf )是一种轻便高效的结构化数据存储格式，平台无关、语言无关、可扩展，可用于通讯协议和数据存储等领域.。
-
后起之秀，是谷歌开源的一种数据格式，适合高性能，对响应速度有要求的数据传输场景。因为 profobuf 是二进制数据格式，需要编码和解码。数据本身不具有可读性。因此只能反序列化之后得到真正可读的数据。
- 序列化后体积相比Json和XML很小，适合网络传输
- 跨平台
- 多语言
- 兼容性好
- 序列化反序列化速度很快，快于Json的处理速度
gRPC
gRPC (gRPC Remote Procedure Calls) 是 Google 发起的一个开源远程过程调用系统，该系统基于 HTTP/2 协议传输
JSON
JSON（JavaScript Object Notation, JS对象简谱）是一种轻量级的数据交换格式。简洁和清晰的层次结构使得 JSON 成为理想的数据交换语言。 易于人阅读和编写，同时也易于机器解析和生成，并有效地提升网络传输效率。