1、k8s集群

 

K8s集群中主要有两类角色:Master节点Worker节点。
简单讲,Maser节点主要是用来管理和调度集群资源的,worker节点是资源的提供者
在一个高可用的K8s集群中,Mater节点和Worker节点一般有多个节点构成。这些节点可以是物理机,也可以是虚拟机。
Worker节点所提供的资源单位叫做Pod,简单理解,Pod就是K8s云平台它所提供的虚拟机。Pod里面驻的是应用容器,比如说docker容器。
容器是CPU和内存的资源隔离单位。大部分场景中,一个Pod里面只驻一个应用容器。
也有的场景,一个Pod里面可以驻多个应用容器。其中一个是主容器,其他的是辅助容器。一个Pod里面的所有容器共享Pod的网络栈和存储资源。 

2、Master节点组件构成

Mater节点是K8s集群的大脑中枢。有以下组件构成:

  • etcd:

分布式的KV数据库,采用raft分布式一致性算法,如果高可用部署的话,一般部署三个节点。可以独立部署,也可以跟Master部署在一起。

  • API Server:

K8s的接口和通讯总线,用户通过命令行工具,比如kubectl,dashboard,sdks等方式操作k8s,背后都是通过API  Server与集群进行交互的。

集群内部的其他组件,比如Kubelet,Kube-Proxy,Scheduler,Controller Manager,都是通过 API Server与集群进行交互的。

 API Server 可以认为是etcd的代理(Proxy)
 API Server 是唯一一个能够访问并且能够操作etcd的组件。其他外围的组件,都必须通过API Server 间接地去操作etcd.
 API Server 不仅能够接收其他组件的请求,它还是集群的事件总线。其他组件,可以订阅在API Server 上面。当有新的事件发生的时候,API Server会将相关的事件,通知到外围的感兴趣的组件。

  • Scheduler:

是K8s集群负责调度决策的组件,掌握当前集群资源的使用情况。当有新的应用请求提交到K8s集群中,Scheduler负责决策相应的pods应该分布到哪些空闲的节点上面去。

K8s中的调度决策算法是可以按需扩展的。

  • Controller Manager:

保证集群状态最终一致的组件,通过API Server监控集群的状态,确保实际状态和预期的状态最终一致,如果一个应用要求发布10个pods,Controller Manager 会保证这个应用会最终启动10个pods.

如果中间有Pods挂了,它会负责协调重启pods.如果Pods启动多了,Controller Manager会负责协调关闭多余的Pods.

可以看出,K8s采用的是最终一致策略。它是集群自愈背后实现的机制。

3、Worker节点组件构成

是 K8s集群资源的提供者,由以下组件构成:

  • kubelet:

Worker节点的资源管理者,相当于Agent这个角色,也是监听在API Server上面的,监听API Server的一些事件。根据Mater节点的命令,做一些相关的操作。比如说,启动或关闭Pod和其他资源。

它也会把本节点的状态数据汇报给Master节点。
 如果是Mater节点是K8s集群的大脑,kubelet可以认为是Worker节点上的小脑。

  • Container Runtime:

它是节点的容器资源的管理者.

kubelet并不直接管理节点上的容器资源,委托给Container  Runtime 进行管理。比如启动或管理容器或收集容器的状态等。
Container Runtime在启动容器的时候,如果本地没有镜像缓存,它就会到Docker Hub拉取相应的镜像,然后缓存在本地。

  • kube-proxy:

管理k8s集群中服务网络(service 网络)的组件,pod在k8s集群中是ephemeral(瞬息的、不固定的),Pod的IP可能会改变,为了屏蔽Pod IP可能的变化,k8s引入了Service抽象的概念

service 可以屏蔽应用的Pod IP 并且在调用的时候进行负载均衡
kube-proxy就是实现k8s服务网络也就是service网络背后的机制。另外,将k8s的服务暴露给外网的时候,也是通过kube-proxy进行转发。

4、流程样例

1、假设通过kubectl命令行工具向API Server 发送一个创建一个新的ReplicaSet请求,API Server会将该资源请求先存储到etcd
2、Controller manager会监听ReplicaSet的创建和修改相关的事件,对于上一步新创建的ReplicaSet,它会接收到一个通知
3、Controller manager 会比较当前的集群状态也预期的集群状态,会发现不一致,所以会创建新的Pods,根据在第一步通过kubectl提交的发布模板,就会在API Server中创建预期的Pod资源
4、Schedule组件会监听到需要创建新的Pod,就会运行调度算法,选择空闲的Worker节点,通过API Server 更新 Pod 的定义,把Pod指派到具体要发布到哪些Worker节点上,此时应用还没有真正的发布。Controller ManagerScheduler
只是通过API Server更新了期望的集群状态。
5、一旦Pod被分配到某个 Worker节点,API Server就会通知相应的节点上面的Kubelet
6、Kubelet接收到通知后,就会指示本节点上面的Container Runtime 去运行对应的容器,Container Runtime就会下载镜像,启动容器,同时Kubelet就会监控容器的运行,此时应用容器就会正式的运行起来了。

参考资料:波波微课 https://www.bilibili.com/video/BV1Ja4y1x748

Logo

华为开发者空间,是为全球开发者打造的专属开发空间,汇聚了华为优质开发资源及工具,致力于让每一位开发者拥有一台云主机,基于华为根生态开发、创新。

更多推荐