K8S的架构及工作原理

1、Master和Node

1）、Master

K8S中的Master是集群控制节点，负责整个集群的管理和控制

在Master上运行着以下关键进程：

**kube-apiserver：**提供了HTTP Rest接口的关键服务进程，是K8S里所有资源的增删改查等操作的唯一入口，也是集群控制的入口进程
kube-controller-manager： K8S里所有资源对象的自动化控制中心，集群内各种资源Controller的核心管理者，针对每一种资源都有相应的Controller，保证其下管理的每个Controller所对应的资源始终处于期望状态
kube-scheduler： 负责资源调度（Pod调度）的进程，通过API Server的Watch接口监听新建Pod副本信息，并通过调度算法为该Pod选择一个最合适的Node
etcd： K8S里的所有资源对象以及状态的数据都被保存在etcd中

2）、Node

Node是K8S集群中的工作负载节点，每个Node都会被Master分配一些工作负载，当某个Node宕机时，其上的工作负载会被Master自动转移到其他节点上

在每个Node上都运行着以下关键进程：

kubelet： 负责Pod对应的容器的创建、启停等任务，同时与Master密切协作，实现集群管理的基本功能
kube-proxy： 实现Kubernetes Service的通信与负载均衡机制的重要组件
Docker Engine： Docker引擎，负责本机的容器创建和管理工作

在默认情况下Kubelet会向Master注册自己，一旦Node被纳入集群管理范围，kubelet进程就会定时向Master汇报自身的信息（例如机器的CPU和内存情况以及有哪些Pod在运行等），这样Master就可以获知每个Node的资源使用情况，并实现高效均衡的资源调度策略。而某个Node在超过指定时间不上报信息时，会被Master判定为失败，Node的状态被标记为不可用，随后Master会触发工作负载转移的自动流程

2、Pod

每个Pod都有一个根容器的Pause容器，还包含一个或多个紧密相关的用户业务容器

Pod里的多个业务容器共享Pause容器的IP，共享Pause容器挂接的Volume。在K8S里，一个Pod里的容器与另外主机上的Pod容器能够直接通信

Pod有两种类型：普通的Pod及静态Pod（Static Pod）。后者并没被存放在K8S的etcd存储里，而是被存放在某个具体的Node上的一个具体文件中，并且只在此Node上启动、运行。而普通的Pod一旦被创建，就会被放入etcd中存储，随后会被K8S的Master调度到某个具体的Node上并进行绑定（Binding），随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器并启动。在默认情况下，当Pod里的某个容器停止时，K8S会自动检测到这个问题并且重新启动这个Pod（重启Pod里的所有容器），如果Pod所在的Node宕机，就会将这个Node上的所有Pod重新调度到其他节点上

3、K8S创建一个Pod的流程

1）、用户提交创建Pod的请求，可以通过API Server的REST API，也可用Kubectl命令行工具

2）、API Server处理用户请求，存储Pod数据到etcd

3）、Schedule通过和API Server的watch机制，查看到新的Pod，尝试为Pod绑定Node

4）、过滤主机：调度器用一组规则过滤掉不符合要求的主机，比如Pod指定了所需要的资源，那么就要过滤掉资源不够的主机

5）、主机打分：对第一步筛选出的符合要求的主机进行打分，在主机打分阶段，调度器会考虑一些整体优化策略，比如把一个Replication Controller的副本分布到不同的主机上，使用最低负载的主机等

6）、选择主机：选择打分最高的主机，进行binding操作，结果存储到etcd中

7）、Kubelet根据调度结果执行Pod创建操作： 绑定成功后，会启动container，Scheduler会调用API在数据库etcd中创建一个bound pod对象，描述在一个工作节点上绑定运行的所有Pod信息。运行在每个工作节点上的Kubelet也会定期与etcd同步bound pod信息，一旦发现应该在该工作节点上运行的bound pod对象没有更新，则调用Docker API创建并启动Pod内的容器

在这期间，Control Manager同时会根据K8S的mainfiles文件执行RC Pod的数量来保证指定的Pod副本数。而其他的组件，比如Scheduler负责Pod绑定的调度，从而完成整个Pod的创建