kubernetes API server是由kube-apiserver进程实现的，它运行在kubernetes的管理节点—master上并对外提供kubernetes Restful  API服务，它提供的主要是与集群管理相关的API服务，例如校验pod、services、replication controller的配置并存储到后端的etcd server上。下面我们分别对其启动过程、关键代码分析及设计总结等进行深入讲解。

 

进程启动过程分析

kube-apiserver进程的入口类源码位置如下：

\kubernetes-master\cmd\kube-apiserver\apiserver.go

入口main函数的逻辑如下：

上述代码的核心为下面三行，创建一个APIServer结构体，并将命令行启动参数传入，最后启动监听：

我们先来看看都有哪些常用的命令行参数被传递到了APIServer对象，下面是运行在Master节点的kube-apiserver进程的命令行信息：

可以看到关键的几个参数有etcd_servers的地址，APIServer绑定和监听的本地地址、kubelet的运行端口及kubernetes服务的clusterIP地址。

下面是app.NewAPIServer()的代码，我们看到这里的控制还是很全面的，包括安全控制（Certdirectory、HTTPS默认启动）、

权限控制（AuthorizationMode、AdmissionControl）、服务限流控制（APIRate、APIBurst）等，这些逻辑说明了APIServer是按照企业级平台的标准所设计和实现的。

创建了APIServer结构体实例后，apiserver.go将此实例传入子包app/server.go的func(s*APIServer) Run(_ []string)方法里，最终绑定本地端口并创建一个HTTP server与一个HTTPS server，从而完成整个进程的启动过程。

 

Run方法的代码有很多，这里就不再列出源码，对该方法的源码解读如下。

1.调用verifyClusterIPFlags方法，验证CLusterIP参数是否设置以及是否有效。

2.验证etcd-servers的参数是否已设置。

3.如果初始化CloudProvider，且没有CloudProvider的参数，则日志警告并继续。

4.根据kubeletconfig的配置参数，调用pkg/Client/kubeclient.go中的方法NewKubeletClient()创建一个kubelet Client对象，这其实是一个HTTPKubeletClient实例，目前只用于kubelet的健康检查（KubeletHealthChecker）。

5.判断哪些API version需要关闭，目前在1.0代码中默认关闭了v1 beta3的API版本。

6.创建一个kubernetes的RestClient对象，具体的代码在pkg/client/helper.go的transportFor()方法里完成，通过它完成Pod，replication controller及kubernetes service等对象的CRUD操作。

7.创建用于访问etcd server的客户端，具体代码在newEtcd()方法里实现，从代码调用中可以看出，kubernetes采用的是coreos/go-etcd/client.go这个客户端实现。

8.建立鉴权（authentication）、授权（authorzer）、服务许可框架和插件（admissioncontrol）的相关代码逻辑。

9.获取和设置APIServer的externalHost的名称，如果没有提供ExternalHost参数，且kubernetes运行在谷歌的GCE云平台上，则尝试通过CloudProvider接口获取本机节点的外部IP地址。

10.如果运行在云平台上，则安装本机的SSH key到kubernetes集群中的所有虚拟机上。

11.用APIServer的数据及上述过程中创建的一些对象（kubeletClient、etcdClient、authenticator、admissionController等）作为参数，构造kubernetes Master的config构造（pkg/master/master.go），以此生成一个Master实例。

12.用上述创建的Master实例，分别创建HTTP server及安全的HTTPS Server来开始监控客户端的请求，至此整个进程启动完毕。

 

关键代码分析

kubernetes api service的关键代码就隐藏在pkg/master/master.go中，APIServer这个结构体只不过是一个参数传递通道而已，它的数据最终传给了pkg/master/master.go里的master结构体，下面是其完整定义：

      

在这段代码里，除了之前我们熟悉的那些变量，又多了几个陌生的重要变量，接下来我们逐一对其进行分析讲解。

首先是类型为apiserver.Mux（来自pkg/apiserver/apiserver.go）的mux变量，下面是对它的定义：

如果你熟悉socket编程，特别使用过或者研究过HTTP Rest的一些框架，那么对于这个Mux接口就很熟悉了，它是一个HTTP的多分器（Multiplexer），其实它也是GolangHTTP基础包里的http.ServeMux的一个接口子集，用于派发（dispatch）某个request路径到对应的http.Handler进行处理。实际上在master.go代码中是生成了一个http.ServeMux对象并赋值给apiserver.Mux变量，在代码中还有强制类型转换的语句。从上述分析来看，apiserver.Mux的引入是设计的一个败笔，并没有增加什么价值，反而增加了理解代码的难度，此外，为了更好实现Rest服务，kubernetes在这里引入了一个第三方的REST框架：go-restful

go-restful采用了路由映射的设计思想，并在API设计中使用了流行的Fluent Style风格，使用起来酣畅淋漓，也难怪kubernetes选择它。

go-restful框架中的核心对象如下：

restful.container： 代表一个HTTP Rest服务器，包括一组restful.WebService对象和一个http.ServeMux对象，使用RouteSelector进行请求派发。

restful.Webservice：表示一个rest服务，由多个rest路由（rest.route）组成，这一组rest路由共享一个root path。

rest.Route：表示一个route路由，rest路由主要由rest path、HTTP Method、输入输出类型（HTML/JSON）及对应的回调函数组成。

rest.RouteFunction：一个用于处理具体的REST调用的函数接口定义，具体定义为type RouteFunction func(*request, *response)。

Master结构体包含了对restful.container与restful.webservice这两个go-restful核心对象的引用，在接下来的Master对象的构造方法中被初始化。那么问题又来了，kubernetes的一堆rest API又是在哪定义的，是如何被绑定到restful.Route中的呢？

要理解这个问题，我们首先要弄清楚Master结构体的变量：

storage map[string] rest.Storage

storage变量是一个Map，key为Rest API的path，value是rest.storage接口，此接口是一个通用的符合restful要求的资源存储服务接口，每个服务接口负责处理一类数据对象-资源数据，只有一个接口方法：new(),new()方法返回该storage服务所能识别和管理的某种具体的资源数据的一个空实例。

在运行期间，kubernetes API Runtime运行时框架会把new()方法返回的空对象的指针传入Codec.DecodeInto方法中，从而完成HTTP Rest请求中的Byte数组反序列化逻辑。kubernetes API Server中所有对外提供服务的restful资源都实现了此接口，这些资源包括pods，bindings，podTemplates, replicationcontrollers， service等，完整的列表就在master.go的func(m *Master)init(c *Config)中，下面是相关代码片段。

                    

  

看到这段代码，你在潜意识里已经明白，这其实就是似曾相识的kubernetes rest API列表，storage这个map的key就是rest API的访问路径，value却不是之前说好的restful.route。聪明的你一定想到了答案：必然存在一个转换适配的方法来实现上述转换。方法在pkg/apiserver/api_installer.go中：

该方法把一个path对应的rest.storage转换成一系列的restful.route并添加到指针restful.webservice中。

 

为了区分API的版本，在apiserver.go里定义了一个结构体：APIGroupVersion。以下是代码：

 

我们注意到APIGroupVersion是与rest.Storage map捆绑的，并且绑定了相应版本的codec、convertor用于版本转换，这样就很容易理解kubernetes是如何区分多版本API的rest服务的。以下是过程详解：

首先，在APIGroupVersion的InstallREST方法里，用Version变量来构造一个Rest API Path前缀并赋值给APIINstaller的prefix变量，并调用它的install（）方法完成Rest API的转换。

接着，在APIINstaller的install方法中用prefix前缀生成webservice的相对根路径：

 

最后，在kubernetes的master初始化方法func(m* master) init(c* config)里生成不同的APIGroupVersion对象，并调用installRest（）方法，完成最终的多版本API的Rest服务装配流程：

至此，Rest API的多版本问题还有最后一个问题需要澄清，在不同版本接口的输入输出参数的格式是有差别的，kubernetes如何处理的？

要弄明白这一点，首先要研究kubernetes API的数据对象的序列化、反序列化的实现机制，为了同时解决数据对象的序列化、反序列化与多版本数据对象的兼容和转换问题，kubernetes设计了一套复杂的机制，首先设计了conversion.scheme这个结构体，以下是对她的定义：

在上述代码中可以看到，typetoversion与versionMap属性是为了解决数据对象的序列化和反序列化问题，converter属性则负责不同版本的数据对象转换问题，kubernetes这个设计思路简单方便解决了多版本的序列化和版本转换问题。

下面是conversion.scheme里序列化、反序列化的核心方法NewObject()的代码：通过查找versionMap里匹配的注册类型，以反射方式生成一个空的数据对象：

而pkg/conversion/encode.go与decode.go则在conversion.scheme提供的基础功能之上，完成了最终的序列化、反序列化功能。下面是encode.go里的主方法encodeToVersion()的关键代码片段：

再进一步，kubernetes在conversion.scheme的基础上又做了一个封装工具类runtime.scheme，可以看作前者的代理类，主要增加了fieldLabelConversionFuncs这个Map属性，用于解决数据对象的属性名称的兼容性转换和校验，比如将需要兼容Pod的spec.host属性改为spec.nodeName的情况。

注意到conversion.scheme只是实现了一个序列化与类型转换的框架API，提供了注册资源数据类型与转换函数的功能，那么具体的资源数据对象类型、转换函数又是在哪个包里实现的呢？答案是pkg/api。kubernetes为不同的API版本提供了独立的数据类型和相关的转换函数并按照版本号命名package，如pkg/api/v1，pkg/api/v1beta3等，而当前默认版本则存在于pkg/api目录下。

以pkg/api/v1为例，以每个目录里都包含如下关键源码：

1.types.go定义了rest API接口里所涉及的所有数据类型，v1版本有2000行代码：

2.在conversion.go与conversion_generated.go里定义了conversion.scheme所需的从内部版本到v1版本的类型转换函数，其中conversion_generated.go中的代码有5000行之多，当然这是通过工具自动生成的代码；

3.register.go负责将types.go里定义的数据类型与conversion.go定义的数据转换函数注册到runtime.schema里。

pkg/api里的register.go初始化生成并持有一个全局的runtime.schema对象，并把当前默认版本的数据类型注册进去，相关代码如下：

而pkg/api/v1/register.go与v1beta3下的register.go在初始化过程中分别把与版本相关的数据类型和转换函数注册到全局的runtime.scheme中：

这样一来，其他地方就可以通过runtime.scheme这个全局变量来完成kubernetes API中的数据对象的序列化和反序列化逻辑了，比如kubernetes API Client包就大量使用了它，下面是pkg/client/pods.go里pod删除的delete()方法的代码：

清楚了kubernetes Rest API的数据对象的序列化机制及多版本的实现原理之后，我们接着分析下面这个重要流程的实现细节。

kubernetes中实现了rest.storage接口的服务在转换成restful.routefunction以后，是怎样处理一个rest请求并最终完成基于后端存储服务etcd上的具体操作过程的？

首先，kubernetes设计了一个名为注册表的package(pkg/registry)，这个package按照rest.storage服务所管理的资源数据的类型而划分为不同的子包，每个子包都由相同命名的一组golang代码来完成具体的rest接口的实现逻辑。

下面我们以pod的rest服务实现为例，其与注册表相关的代码位于pkg/registry/pod中，在registry.go里定义了pod注册表服务的接口：

我们看到这个pod注册表服务是针对pod的CRUD的操作接口的一个定义，在入口参数中除了调用的上下文环境api.context，就是我们之前分析过的pkg/api包中的pod这个资源数据对象，为了实现强类型的方法调用，在registry.go里定义了一个名为storage的结构体，storage实现registry接口，可以看做一种代理设计模式，因为具体的操作都是通过内部rest.standardstorage来实现的，下面是截取的registry.go中的create、update、delete的源码：

那么，这个实现了rest.standardstorage通用接口的真正storage又是什么？从master对象的初始化函数中，我们发现了下面的相关代码：

master对象创建了一个私有变量podstorage，其类型为PodStorage，pod注册表服务实例（podregistry）里真正的storage是podstorage.pod。下面是podetcd的函数newstorage中的关键代码：

在上述代码可以看到，位于pkg/registry/generic/etcd/etcd.go里的etcd才是真正的storage实现。而具体操作etcd的代码是靠tools.etcdhelper这个类完成的，通过分析etcd.go里的func(e* etcd) Create方法，我们知道创建一个etcd里的键值对的关键逻辑如下：

注意到之前podstorage创建store时重载了objectNameFunc()、KetFunc()\NewFunc()等函数，于是完成了针对pod的创建过程，kubernetes API服务中的其他数据对象也都遵循同样的设计模式。

进一步研究代码，我们发现podstorage中的Pod、Binding、Status等属性是pkg/api/rest/rest.go中几个不同的Rest接口的实现，并且通过ercdgeneric.etcd这个实例来完成Pod的一些具体操作，比如这里的statusREST。下面是其相关代码片段：

下表展现了podstorage中的各个XXXREST接口与pkg/api/rest.go的相关Rest接口的一一对应关系。

 

对kubernetes RestAPI Server的复杂实现机制和调用流程总结入下：

在pkg/api包定义了Rest API涉及的资源对象、提供的rest接口、类型转换框架和具体转换函数、序列化反序列化等代码，其中，资源对象和转换函数按照版本分包，形成了kubernetes API server基础的框架，其中核心是各类资源（Node。pod，service

等）以及这些资源对应的rest.storage。

在pkg/runtime包最重要的对象就是schema，它保存了kubernetes API service中注册的资源对象类型、转换函数等重要基础数据，另外runtime包也提供了获取json/yaml序列化、反序列化的codec结构体，runtime总体上与pkg/api密切关联，分离出来的目的是供其他模块方便使用。

pkg/registry包其实是把pkg/api中定义的各种资源对象所提供的rest接口进一步规范定义并且实现对应的接口，其中generate/etcd/etcd.go里的rtcd对象是一个真正实现了rest.storage接口的基于etcd后端存储的服务框架。

kubernetes采用了go-restful这个第三方rest框架，简化了rest服务的开发，主要代码在pkg/apiserver中，通过APIGroupVersion这个结构体可以完成不同API版本的rest路径映射，而api_installer.go则实现了从kubernetes rest storage接口到go-restful的映射连接逻辑，对应rest.storage的具体restful.routefunction则在resthandler.go里实现。