Kubernetes工作流程
客户端创建pod 流程:
- 用户管理员创建 Pod 的请求默认是通过kubectl 客户端管理命令 api server 组件进行交互的,默认会将请求发送给 API Server。
- API Server 会根据请求的类型选择用何种 REST API 对请求作出处理(比如:创建 Pod 时 Storage 类型是 Pods 时,其对应的就是 REST Storage API)。
- REST Storage API 会对请求作相应的处理并将处理的结果存入高可用键值存储系统 Etcd 中。
- 在 API Server 响应管理员kubectl 的请求后,Scheduler 会根据ETCD集群中运行 Pod情况 及 Node 信息进行判断,将需要创建的 Pod 分发到可用的 Node 节点上。然后根据一组相关规则将pod分配到可以运行它们的节点上,并更新数据库,记录pod分配情况。
- Kubelet监控数据库变化,管理后续pod的生命周期,发现被分配到它所在的节点上运行的那些pod,就会进行docker组件的启动,docker组件会启动对应的容器(pod),会在该节点上运行这个新pod。
- kube-proxy运行在集群各个节点主机上,管理网络通信,如服务发现、负载均衡。例如当有数据发送到主机时,将其路由到正确的pod或容器。对于从主机上发出的数据,它可以基于请求地址发现远程服务器,并将数据正确路由,在某些情况下会使用轮训调度算法(Round-robin)将请求发送到集群中的多个实例。
集群功能各模块功能描述:
Master节点: Master节点上面主要由四个模块组成,APIServer,schedule,controller-manager,etcd.
APIServer: APIServer负责对外提供RESTful的kubernetes API的服务,它是系统管理指令的统一接口,任何对资源的增删该查都要交给APIServer处理后再交给etcd,如图,kubectl(kubernetes提供的客户端工具,该工具内部是对kubernetes API的调用)是直接和APIServer交互的。
schedule: schedule负责调度Pod到合适的Node上,如果把scheduler看成一个黑匣子,那么它的输入是pod和由多个Node组成的列表,输出是Pod和一个Node的绑定。 kubernetes目前提供了调度算法,同样也保留了接口。用户根据自己的需求定义自己的调度算法。
controller manager: 如果APIServer做的是前台的工作的话,那么controller manager就是负责后台的。每一个资源都对应一个控制器。而controller manager就是负责管理这些控制器的,比如我们通过APIServer创建了一个Pod,当这个Pod创建成功后,APIServer的任务就算完成了。
etcd:etcd是一个高可用的键值存储系统,kubernetes使用它来存储各个资源的状态,从而实现了Restful的API。
Node节点: 每个Node节点主要由三个模板组成:kublet, kube-proxy
kube-proxy: 该模块实现了kubernetes中的服务发现和反向代理功能。kube-proxy支持TCP和UDP连接转发,默认基Round Robin算法将客户端流量转发到与service对应的一组后端pod。服务发现方面,kube-proxy使用etcd的watch机制监控集群中service和endpoint对象数据的动态变化,并且维护一个service到endpoint的映射关系,从而保证了后端pod的IP变化不会对访问者造成影响,另外,kube-proxy还支持session affinity。
kublet:kublet是Master在每个Node节点上面的agent,是Node节点上面最重要的模块,它负责维护和管理该Node上的所有容器,但是如果容器不是通过kubernetes创建的,它并不会管理。本质上,它负责使Pod的运行状态与期望的状态一致。