文章目录
跟着官网看基础架构
官网参考地址: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 成为理想的数据交换语言。 易于人阅读和编写,同时也易于机器解析和生成,并有效地提升网络传输效率。