跟着官网看基础架构

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

k8s 组件

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

image-20230210190235882

控制平面组件(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 来说,属于主管理从的集群架构

kubernetes 整体架构示意图

  • 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 网络代理自动计算进行流量转发

再来一个图加深印象:

image-20230210193353066

原理分解

主节点(Master)

Kubernetes master 架构示意图

工作节点(Node)

kubernetes node 架构示意图

组件交互原理

核心组件交互

image-20230210201439966

  1. 初始状态:

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

  1. 创建一个应用:

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

kubectl create deploy tomcat --image=tomcat8(告诉master让集群使用 tomcat镜像,部署一个 tomcat 应用)

  1. 创建信息保存在 etcd:

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

  1. etcd 上报创建事件:

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

  1. api server 上报事件:

controller-manager 监听到 api server 的事件,是 (部署tomcat[deploy])

  1. controller-manager 处理部署事件:

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

  1. 再次将 Pod 部署信息保存在 etcd:

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

  1. etcd 再次上报事件:

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

  1. api server 再次上报事件:

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

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

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

  1. etcd再次上报事件:

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

  1. kubelet 判断事件:

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

核心组件通信协议

Kuberentes 架构(图片来自于网络)

CNI

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

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

CRI

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

img

OCI

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

OCI容器规范


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 成为理想的数据交换语言。 易于人阅读和编写,同时也易于机器解析和生成,并有效地提升网络传输效率。

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐