1、K8S是如何对容器编排？
在K8S集群中，容器并非最小的单位，K8S集群中最小的调度单位是Pod，容器则被封装在Pod之中。由此可知，一个容器或多个容器可以同属于在一个Pod之中。
2、Pod是怎么创建出来的？
Pod并不是无缘无故跑出来的，它是一个抽象的逻辑概念，那么Pod是如何创建的呢？Pod是由Pod控制器进行管理控制，其代表性的Pod控制器有Deployment、StatefulSet等。
3、Pod资源组成的应用如何提供外部访问的？
Pod组成的应用是通过Service这类抽象资源提供内部和外部访问的，但是service的外部访问需要端口的映射，带来的是端口映射的麻烦和操作的繁琐。为此还有一种提供外部访问的资源叫做Ingress。
4、Service又是怎么关联到Pod呢？
在上面说的Pod是由Pod控制器进行管理控制，对Pod资源对象的期望状态进行自动管理。而在Pod控制器是通过一个YAML的文件进行定义Pod资源对象的。在该文件中，还会对Pod资源对象进行打标签，用于Pod的辨识，而Servcie就是通过标签选择器，关联至同一标签类型的Pod资源对象。这样就实现了从service-->pod-->container的一个过程。
5、Pod的怎么创建逻辑流程是怎样的？
（1）客户端提交创建请求，可以通过API Server的Restful API，也可以使用kubectl命令行工具。支持的数据类型包括JSON和YAML。
（2）API Server处理用户请求，存储Pod数据到etcd。
（3）调度器通过API Server查看未绑定的Pod。尝试为Pod分配主机。
（4）过滤主机 (调度预选)：调度器用一组规则过滤掉不符合要求的主机。比如Pod指定了所需要的资源量，那么可用资源比Pod需要的资源量少的主机会被过滤掉。
（5）主机打分(调度优选)：对第一步筛选出的符合要求的主机进行打分，在主机打分阶段，调度器会考虑一些整体优化策略，比如把容一个Replication Controller的副本分布到不同的主机上，使用最低负载的主机等。
（6）选择主机：选择打分最高的主机，进行binding操作，结果存储到etcd中。
（7）kubelet根据调度结果执行Pod创建操作： 绑定成功后，scheduler会调用APIServer的API在etcd中创建一个boundpod对象，描述在一个工作节点上绑定运行的所有pod信息。运行在每个工作节点上的kubelet也会定期与etcd同步boundpod信息，一旦发现应该在该工作节点上运行的boundpod对象没有更新，则调用Docker API创建并启动pod内的容器。
三、各类接口是如何调用
当我们通过kubectrl create命令创建一个RC资源对象时，kubectrl通过create rc这个rest接口将数据提交到api server，
随后api server将数据写入etcd里持久保存，与此同时，controller manager 在watch 所有的rc资源对象，因此一旦有rc对象被写入到etcd中，controller manager就得到了通知，
它会读取rc的定义，然后比较rc中所控制的pod的实际副本数与期待值的差异，然后采取对应的行动。
此刻，controller manager发现集群中还没有对应的pod实例，就根据rc里的pod模板(template)定义，
创建一个pod并通过apiserver保存到etcd中。
类似地，scheduler进程在watch所有pod，一旦它发现系统产生了一个新生的pod，
就开始执行调度逻辑，为它安排一个新家(node)，如果一切顺利，此pod就被安排到某个node节点上，即binding to a node。
接下来，scheduler进程就把这个信息及pod状态更新到etcd里，最后目标node节点上的kubelet监听到有新的pod被安排到自己这里来了，
于是就是安排pod里的定义，拉取容器的镜像并且创建对应的容器，当容器成功创建后，kubelet进程再把pod的状态更新为running并通过api server更新到etcd中。
如果此pod还有对应的service，那么接下来就轮到kube-proxy出场了，每个node上的kube-proxy进程会监听所有service及这些service对应的pod实例的变化，一旦发现有变化,就会在所在node节点上的iptables里增加或者删除对应的nat转发规则，最终实现了service的智能负载均衡功能，这一切都是自动完成的，无须人工干预。
如果某个node宕机，则会发生什么事情呢？假如某个node宕机一段时间，则因为此节点上再没有kubelet进程定时汇报这些pod的状态,因此这个node上的所有pod实例会被判定为失败状态，此时controller manager会将这些pod删除并产生新的pod实例，于是这些pod就会被调度到其它node上产生，从而系统自动恢复。