这个问题既然是向非技术人员介绍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。