容器运维模式(五)-- Master-Node & Api-Server

2020-07-06 00:00:00 连接 都是 节点 运行 组件

继续上文未完的内容

Hi峰叔:容器运维模式(一)-- 概述zhuanlan.zhihu.com

5、Master-Node 模式 与 Api-server

Kubernetes有几个核心组件:kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy、CRI(一般是docker)等等。

它们分别是运行在Master或者Node节点上面,我把Master和Node称为物理组件,因为它们是运行于物理环境的,如物理机或者虚拟机。其中Master提供集群的管理控制中心,而Node是真正接受执行任务的工作节点,可以拟人化得理解为:Master是用人经理,Node是工作人员。

而Etcd是用于存储配置信息或者其他需要持久化的数据,独立于Master和Node节点,一般也是三副本的方式运行。

Master

区别于物理组件,逻辑组件是指在程序内的虚拟概念,例如运行在Master的逻辑组件有kube-apiserver、kube-controller-manager、kube-scheduler。

kube-apiserver用于暴露Kubernetes API。任何的资源请求/调用操作都是通过kube-apiserver提供的接口进行。

kube-controller-manager运行管理控制器,它们是集群中处理常规任务的后台线程。逻辑上,每个控制器是一个单独的进程,但为了降低复杂性,它们都被编译成单个二进制文件,并在单个进程中运行。

kube-scheduler 监视新创建没有分配到Node的Pod,为Pod选择一个Node。

这几个组件的用途不作特别展开,我们后面将详细聊聊Apiserver。

Node

Node是Kubernetes中的工作节点,开始被称为minion。一个Node可以是VM或物理机。每个Node(节点)具有运行pod的一些必要服务,并由Master组件进行管理。

然后介绍运行于Node节点的组件:kubelet、kube-proxy、CRI(一般是docker)。

kubelet是主要的节点代理,它会监视已分配给节点的pod,具体功能如:安装Pod所需的volume;下载Pod的Secrets;Pod中运行的 docker(或experimentally,rkt)容器;定期执行容器健康检查等等。

kube-proxy通过在主机上维护网络规则并执行连接转发来实现Kubernetes服务抽象。

docker等容器运行时,作用当然就是用于运行容器。


对于以上的Kubernetes的Master和Node的节点模式,在很多支持分布式架构的软件中都是类似的,如hadoop等。他们的Master节点往往需要有3个以上,以实现高可用架构。很多软件架构也采取了这样的设计方式,都是为了生产环境所需的高可用性服务。


Api-server

前面介绍过Master和Node,它们之间从Master (apiserver)到集群有两个主要的通信路径。个是从apiserver到在集群中的每个节点上运行的kubelet进程。第二个是通过apiserver的代理功能从apiserver到任何node、pod或service 。

所以说apiserver对于Master-Node模式来说是非常重要的沟通桥梁。

从apiserver到kubelet的连接用于获取pod的日志,通过kubectl来运行pod,并使用kubelet的端口转发功能。这些连接在kubelet的HTTPS终端处终止。

从apiserver到Node、Pod或Service的连接默认为HTTP连接,因此不需进行认证加密。也可以通过HTTPS的安全连接,但是它们不会验证HTTPS 端口提供的证书,也不提供客户端凭据,因此连接将被加密但不会提供任何诚信的保证。这些连接不可以在不受信任/或公共网络上运行。

相关文章