容器运维模式（五）-- Master-Node & Api-Server

继续上文未完的内容

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 端口提供的证书，也不提供客户端凭据，因此连接将被加密但不会提供任何诚信的保证。这些连接不可以在不受信任/或公共网络上运行。