简介

在 Kubernetes 项目中，默认调度器的主要职责，就是为一个新创建出来的 Pod，寻找一个最合适的节点（Node）。

而这里“最合适”的含义，包括两层：

1. 从集群所有的节点中，根据调度算法挑选出所有可以运行该 Pod 的节点；
2. 从第一步的结果中，再根据调度算法挑选一个最符合条件的节点作为最终结果。

所以在具体的调度流程中，默认调度器会首先调用一组叫作 Predicate 的调度算法，来检查每个 Node。然后，再调用一组叫作 Priority 的调度算法，来给上一步得到的结果里的每个 Node 打分。最终的调度结果，就是得分最高的那个 Node。

Kubernetes的控制器模式是其非常重要的一个设计模式，整个Kubernetes定义的资源对象以及其状态都保存在etcd数据库中，通过apiserver对其进行增删查改，而各种各样的控制器需要从apiserver及时获取这些对象以及其当前定义的状态，然后将其应用到实际中，即将这些对象的实际状态调整为期望状态，让他们保持匹配。因此各种控制器需要和apiserver进行频繁交互，需要能够及时获取对象状态的变化，而如果简单的通过暴力轮询的话，会给apiserver造成很大的压力，且效率很低，因此，Kubernetes设计了Informer这个机制，用来作为控制器跟apiserver交互的桥梁，它主要有两方面的作用：

所谓Glance多后端，其实是针对Cinder的多后端功能对比的，我们知道在Cinder中，cinder-volume后面可以接多个存储后端，并且通过cinder types来选择使用哪个存储后端，Cinder中的这个功能很早就有了，因为Cinder要纳管多种存储，对外提供统一的接口，这个功能是刚需。但是对于Glance来说，类似Cinder的这种Glance多后端就没那么刚了，没有多后端也是可以用的，拿Ceph作为后端存储来说，如果镜像只是存在其中一个存储池A的话，要在另外的存储池B中建虚拟机，发现不能执行rbd clone操作，那么它会将该镜像下载到本地，然后再传到存储池B中，而且下载下来的镜像会缓存到本节点，只要在该节点下载过一次，后面在该节点再使用相同的镜像建虚拟机，就不需要再下载了，这种方式虽然效率低一些，但是不影响使用。但是毕竟不完美啊，所以社区一直到R版，才实现了这个功能，到T版算是生产可用，但是仍然有一些bug还在修复，不过不影响使用。

Glance最核心的功能就是镜像管理，我们最常做的操作就是管理员给Glance上传一个镜像，然后大家就都可以从这个镜像创建虚拟机了，这在私有云场景下，没有任何问题。但是在公有云场景下，需要考虑的问题就比较多了，像“应用市场”就是可以让普通用户上传自己制作的镜像，并且共享给其他人，这一方面是请求量比在私有云场景大了很多，可能同时有很多人在传镜像，而且镜像一般都很大，如果不做优化，Glance API可能很快就卡死了；另一方面是安全性问题，普通用户是不可信的，管理员要对其上传的镜像做各种安全性、合法性检查；其他的，像管理员可能需要对用户上传的镜像自动做类型转换，以及打一些元数据标签之类的；所以，Glance的核心功能虽然简单，但是随着需求的不断提出，它还是经历过了一个比较“漫长”的演进过程。

Token的一点历史

Keystone在早期的版本中，其认证Token有好几种类型，最早期的也是当时最成熟的是UUID类型的Token，它将token以及其元数据存储在数据库中，以一个UUID来标识一个Token，这种方式一个明显的问题就是当Token量很大时，会往数据库中写大量的Token，一个中等集群，往往数据库中有十几G的数据都是Token，需要定期清理，否则会拖慢其他请求；后来发展出了基于公私钥非对称加密的PKI/PKIZ Token，这种Token不需要存数据库，Token元数据直接被编码到Token ID中，而且因为是非对称的，甚至都不需要跟Keystone交互，本地就可以完成验证以及解析Token，但是这种Token，因为Token元数据都在Token ID中，随着集群大小以及复杂度的变化，其长度也会变化，有时会变得非常长，超过了HTTP对Header的长度限制，再加上公私钥的管理也比较复杂，所以PKI体系的Token基本没有被用起来；于是就有了Fernet Token，它可以看成是UUID和PKI折中的一种方案，它有以下几个特点：

终于来到了这一篇，APIServer的扩展机制，前面介绍的那几篇，可以说都是在给这篇铺平道路，先来回顾下：

在Kubernetes APIServer Storage 框架解析中，我们介绍了APIServer相关的存储框架，每个API资源，都有对应的REST store以及etcd store。在Kubernetes APIServer GenericAPIServer中介绍了GenericAPIServer的Handler是如何构建，API对象是如何以APIGroupInfo的形式注册进Handler中的。在Kubernetes APIServer 机制概述中简单介绍了APIServer的扩展机制，即Aggregator, APIExtensions以及KubeAPIServer这三者之间通过Delegation的方式实现了扩展。本篇文章就重点介绍下这三个”扩展对象”中的API对象资源是如何组织成APIGroupInfo的，然后怎么调用GenericAPIServer中暴露出来的安装方法进行安装的，最后盘点下当前版本的Kubernetes中，都有哪些API对象资源。

在Kubernetes APIServer 机制概述中我们介绍到了APIServer的本质其实是一个实现了RESTful API的WebServer，它使用golang的net/http的Server构建，并且Handler是其中非常重要的概念，此外，又简单介绍了APIServer的扩展机制，即Aggregator, APIExtensions以及KubeAPIServer这三者之间通过Delegation的方式实现了扩展。

在go-restful的介绍中，有介绍过Kubernetes中核心的API是使用go-restful来构建的，我们知道除了核心API，Kubernetes APIServer还提供了两种扩展机制，分别为Aggregation和APIExtensions，这两者中的API对象，则是使用NonGoRestfulMux来构建的，之所以不继续使用go-restful，原因还没有细究，可能是因为一些兼容性问题，后续有可能抛弃go-restful，完全切到NonGoRestfulMux上来，但是看改造工作量还是比较大的。下面我们来看看这个NonGoRestfulMux究竟是个什么东西，其代码位于：apiserver/pkg/server/mux/pathrecorder.go

go-restful是一个golang语言实现的RESTful库，因为Kubernetes APIServer使用它实现RESTful API，这里就简单分析下。看它的文档介绍，功能还是挺强大的，主要体现在它的路由策略上，支持静态，谷歌式的自定义方法，正则表达式，以及URL内参数等，此外还支持json/xml等格式化，还有filter过滤器等，虽然有这么多功能，但是Kubernetes使用的比较简单，只用到了它最基础的功能，即路由功能，这里就重点分析下这个功能。