简介

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

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

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

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

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

终于来到了这一篇，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使用的比较简单，只用到了它最基础的功能，即路由功能，这里就重点分析下这个功能。

Kubernetes使用etcd作为后端存储，etcd是一个分布式的，高可靠性的键值存储系统，跟传统的平台系统不同，Kubernetes把所有的数据都存储到了kv数据库中，而没有像OpenStack一样使用像MySQL这种关系型数据库，做这种选型的原因，我想可能一方面是由于Kubernetes中存储的数据，关系性不是很强，更多的是类似配置管理这类数据，一方面是由于etcd的特性，像效率比较高的gRPC接口、支持事务以及Kubernetes严重依赖的Watch机制等，能够通过单一数据库就满足它的需求，不用再引入其他组件实现类似功能，简化了架构的复杂性。

断断续续研究Kubernetes代码已经大半年时间了，一直在看APIServer相关的代码，因为API是一个系统的入口，是所有功能对外的抽象体现，同时也是其它组件都依赖的一个组件，处于非常核心的地位，因此它被社区进行了精心的设计，了解了它，就可以顺藤摸瓜去了解其他核心的功能。不过，经过这么长时间的摸索，发现Kubernetes的代码是真心复杂，明显感觉要比看OpenStack的代码费劲多了，感觉它的复杂性主要来自于以下几个方面：

背景

研究kubernetes有一段时间了，k8s作为容器编排领域的标准，相比传统架构，在应用发布，运行，维护上具有颠覆性的变革，这场变革以“云原生”为口号，如火如荼的发展起来。可以想象，在不远的将来，大家的应用都以标准的形式，运行在以k8s为代表容器平台上，k8s让devops真正融合在了一起，尤其对运维，k8s定义了对应用的标准运维方式，平台替人做了很多toil的运维工作，通过各种机制保障应用的可用性，这对运维来说，是最激动人心的。在IaaS平台上构建起来的容器平台，还可以通过API的方式消费IaaS平台的网络和存储等资源，真正将IaaS平台的弹性、灵活性利用起来，容器平台将作为最接近应用的基础平台，是一个公司非常重要的IT基础设施，这一如当年的Linux给业界带来的变革。