一、Master
集群的控制节点，每个kubenetes集群里需要有一个master节点来负责整个集群的管理和控制，基本上kubenetes所有控制命令都是发给它，它来负责具体的执行过程，是整个集群的大脑。
Master节点上运行着以下一组关键进程
- Kubenetes API(kube-apiserver)，提供了HTTP接口的关键服务进程，是kubenetes里所有资源的增、删、改、查等操作的唯一接口，也是集群控制的入口进程。
- kubenetes controller manager(kube-controller-manager)，kubenetes里所有资源对象的自动化控制中心，可以理解为对象的“大部管”。
- kubenetes scheduler(kube-scheduler)，负责资源调度（POD）的进程，相当于公交公司的“调度室”。
其实master节点上往往还启动一个etcd server进程，因为kubenetes里所有的资源对象的数据全部保存在etcd中的。
二、Node
每个Node节点上都运行着以下一组关键进程
- kubelet：负责Pod对应的容的创建、启停等任务，同时与master节点密切协作，实现集群管理的基本功能。
- kube-proxy：实现kubenetes service的通信与负载均衡机制的重要组件。
- Docker Engine（docker）：Docker引擎，负责本机的容器创建和管理工作。
Node节眯可以在运行期间动态增加到kubenetes集群中，一旦Node被纳入集群管理范围，kubelet进程会定时向master节点汇报自身的情报，如操作系统，docker版本，机器的CPU和内存情况，以及之前有哪些POD在运行等，这样master可以获知每个NODE的资源使用情况，关实现高效均衡的资源调度策略。而某个Node超过指定时间不上报信息时，会被master判定为失聪，Node的状态被标记为不可用（Not Ready），随后master会触发“工作负载大转移”的自动流程。
三、Pod
kubenetes的最重要也最基本的概念，每个pod都有一个特殊的被称为“根容器”的pause容器。pause容器对应的镜像属于kubenetes平台的一部分，除了pause容器，每个pod还包含一个或多个紧密相关的用户业务容器。
设计一个全新的pod容器的概念并且pod有这样特殊的组成结构
原因一：在一组容器作为一个单元的情况下，我们难以对整体简单地进行判断及有效地进行行动，如，一个容器列亡了，此时算是整体死亡么？引入业务无关并且不易死亡的pause容器作为pod的根容器，以它的状态代表整个容器组的状态，就简单，巧妙地解决了这个难题。
原因二：pod里的多个业务容器共享pause 容器的IP，共享pause容器挂载的volume，这样即简化了密切关联的业务容器之间的通信问题，也很好地解决了它们之间的文件共享问题。kubenetes为每个pod都分配了一个IP地址，称为podip，一个pod里的多个容器共享podip地址，要求底层网络支持集群内任意两个pod之间的tcp/ip直接通信。这通常采用的是虚拟二层网络技术来实现，例如：flannel,openvswitch等。因此我们需要牢记一点，在kubenetes里，一个pod里的容器与另外主机上的pod容器能直接通信。
pod分为两类型：普通的pod及静态的pod（static pod），后者比较特殊，它并不存放在kubenetes的etcd里，而是存放在某个具体的node上的一个具体文件中，并且只在此node上启动运行，而普通的pod一旦被创建，就会被放入到etcd中存储，然后会被kubenetes master调度到某个具体的node上并进行绑定，随后该pod被对应的node上的kubelet进程实例化成一组相关的docker容器并运行起来。在默认情况下，当pod里的某个容器停止时，kubenetes会自动检测到这个问题并且重新启动这个pod（重启pod里的所有容器），如果pod所在的node宕机，则会将这个node上的所有pod重新调度到其他节点上，pod、容器与node的关系如下图
