这个问题既然是向非技术人员介绍kubernetes。这里第一个想到的就是比喻法。毕竟kubernetes涉及到很多操作系统,网络的知识,想一点相关知识不捎带又介绍清楚kubernetes,着实有些难。
先抛一张kubernetes架构图,参照这个咱们分解来说。见下图。
我理解中的Kubernetes,可以看作一个公交枢纽站(不是普通的公交站哟)。其作用是统一的调度管理各路公交车的运营。
集群:一个公交枢纽站可以看做是一个kubernetes集群
Master:作为kubernetes的大脑,负责整个kubernetes集群的管理。其中有三个核心组件,既三个核心部门。
apiserver:作为总控,相当于枢纽站的总控制台。可以理解为管理枢纽站的方方面面。比如门卫室,广播站,购票大厅等等。
controller-manager:在kubernetes中提供多种控制器,管理集群各个资源。既公交枢纽站的具体职权部门。比如一路里应该有几个公交车等
Scheduler:kubernetes负责资源调度。既具体的调度部门,比如这个枢纽站中,某个分站台需要维修,需要把这个站台上停靠的车辆调到其他站台。这就是它做的事。当然不止这些。
Node:kubernetes中各个子节点,各资源项会具体的部署在各节点上。这里包括几个关键概念:
Kubelet:各节点在集群中与apiserver通信的出入口,处理master下发到本节点的任务,并定期向master汇报节点的情况。在这个枢纽站中。类似于每个分站台的控制台。只关注自己分站台的情况,并与总控保持联系。
Kubeproxy:这是一个提供负载均衡和服务发现的组件。其功能多与service绑定。可以理解为,对每路公车发送的信息。由它制定分发规则进行发送。新加入的公车。由它负责注册到service中。
Pod:每一辆公交车可以看做一个pod,这是kubernetes中的基本资源单位。每一个乘客可以看做是一个容器。一辆车上可以有多个乘客。但不管有几个乘客,都必须有一个司机,既pause容器。
Deployment:每一路公车都会之前有一辆公车,如789路。一定不值一辆车,这些车都运行同样的路线,完成同样的功能。就如同deployment,可以部署一类实例多个副本。
Service:这是kubernetes中一个抽象概念。可以这样比喻。本来某一路下所有的公车副本,应该都停靠在一个分站台下。但由于站台位置有限,有一部分车停在了其他分站台。这时候,总控台需要对这一路下的所有车进行管理。该怎么办呢?总控台将这一路车定义为一个service,并建立一个通信的频道。通过这个频道,实现对这一路车的负载均衡,调度管理。车该往哪停,车与车之间通信,都可以通过这个service。