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 Manager 和 Scheduler
只是通过API Server更新了期望的集群状态。
5、一旦Pod被分配到某个 Worker节点，API Server就会通知相应的节点上面的Kubelet
6、Kubelet接收到通知后，就会指示本节点上面的Container Runtime 去运行对应的容器，Container Runtime就会下载镜像，启动容器，同时Kubelet就会监控容器的运行，此时应用容器就会正式的运行起来了。

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