kube-apiserver RestFul API route创建流程分析

看完《kubernetes权威指南》和《Go程序设计语言》两本书之后，终于可以进入实际的代码分析阶段，根据之前熟悉其他开源项目源码（如libvirt、OpenStack等）的经验，首先从接口/API开始分析。

k8s开发环境搭建：使用kubeasz快速搭建k8s集群all-in-one开发测试环境

Golang调试环境搭建：kubernetes源码调试体验

k8s源码版本：v1.10

分析API：GET 127.0.0.1:8080/api/v1/nodes/10.0.90.22（10.0.90.22是我环境中的一个node，8080为kubectl proxy API代理端口）

分析目标：搞清楚用户发送请求到这个API之后kube-apiserver的处理流程

参考资料：http://www.wklken.me/posts/2017/09/23/source-apiserver-04.html（还有前面几篇，这里面讲的是老版本的，有很多代码已经改了，但是主要流程值得参考）

源码流程很绕（至少目前我是这么认为，可能是因为我刚开始看源码），需要多看，多动手调试，看很多遍，调很多遍，整天琢磨它，应该都能看明白。

route注册（{path} to {handler}）

要搞清楚route注册流程，就必须先把go-restful框架的用法搞明白，官方Readme文档有说明，也有示例代码。这里给出上面提到的参考资料：http://www.wklken.me/posts/2017/09/23/source-apiserver-01.html

我们只需要记住，go-restful框架中route注册需要经过如下几个步骤：

1. 创建一个container（默认使用default）
2. 创建一个web service
3. 创建handler（也就是API的请求处理函数）
4. 把API path和handler绑定到web service
5. 把web service（可多个，但root Path不能相同）绑定到container
6. 启动包含container（可多个）的http server

我这边试验的一个简单的示例代码：

 

我们下面所有的流程都以这个为基础进行分析。

kube-apiserver的main入口：

这里用到了github.com/spf13/cobra这个包来解析启动参数并启动可执行程序。

具体注册流程就不一步一步的分析了，直接根据断点的bt输出跟着代码查看吧：

NewLegacyRESTStorage这个方法（注意是LegacyRESTStorageProvider类型的方法），返回了3个参数，restStorage, apiGroupInfo, nil，最后一个是错误信息可忽略，第一个对我们流程分析没啥影响（应该是），中间这个apiGroupInfo是重点，InstallLegacyAPIGroup就是注册/api这个path的，apiPrefix这个参数是 DefaultLegacyAPIPrefix = "/api" ，apiGroupInfo.PrioritizedVersions目前就”v1″一个版本。

注意这里的getAPIGroupVersion方法，它把apiGroupInfo封装到了apiGroupVersion结构体里面，具体是apiGroupVersion.Storage，下面会用到：

 

paths变量就是上面NewLegacyRESTStorage里restStorageMap map的key，也即”pods”、”nodes”等path。a.registerResourceHandlers()就是注册各个path的handler，也即restStorageMap的value。

下面分析handler具体是什么方法？以restfulGetResource为例：

也即r.Get是最终的实际请求处理函数，它是怎么来的？

r就是getter也就是storage.(rest.Getter)，上面提到过参数storage是restStorageMap的value，path是key，针对我们分析的API对应”nodes”: nodeStorage.Node（storage == nodeStorage.Node）。rest.Getter是一个go-restful里面定义的接口，接口也是一种类型，根据Go语言的接口类型定义，接口即约定，可以在任何地方（包）为任何数据类型（int、string、struct等等）实现接口（也即实现接口约定的具有指定参数类型和返回类型的函数），我们看下这个接口的定义：

再看下storage也即nodeStorage.Node有没有实现它，很郁闷，没找到，但是不要灰心，想想看，struct是可以嵌套的（类似父子类的继承关系），并且支持匿名成员，使用匿名成员可以省略中间struct的名称（尤其是匿名成员根本没有嵌套的中间struct变量名可用）（如果没印象了，可以翻看一下《Go程序设计语言》），看看Node的嵌套struct里面有没有实现接口，

对，最终我们在genericregistry.Store这个struct定义的包文件里面找到了它的Get接口实现方法：

下面继续找e.Storage.Get，其实根据接口的定义，我已经找到了真正的后端实现了，k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/storage/etcd3.(*store).Get，为啥是etcd3？需要分析etcd存储后端（k8s元数据存储后端）类型注册（默认是etcd3后端）过程：

fff但是怎么反推回来handler？也就是e.Storage.Get，最简单的办法当然是加断点调试，调试结果在下面的请求处理部分有贴出来，这里就不贴了。但是看了之后还是有疑问，怎么从e.Storage.Get走到etcd3的Get方法的？

NewCacherFromConfig返回的Cache结构体指针，结构体实现了storage.Interface定义的各个接口，

所以e.Storage.Get就是k8s.io/apiserver/pkg/storage/cacher.go:Get方法，它里面又调用了etcd3后端的Get方法：

c.storage==config.Storage由NewRawStorage生成，根据上面的调试结果可以确定它最终调用到k8s.io/kubernetes/vendor/k8s.io/apiserver/pkg/storage/etcd3.newStore，所以c.storage.Get调用的就是：

这个Get就是最终处理用户发送的Get API请求的位置。

 

请求处理（HTTP RestFul request to {handler}）

这部分就不多说了，直接看调用栈吧：

 

未解决的问题

• 上面代码分析过程中没搞清楚的两个Go语言知识点，都是关于接口的
• container到http server，这个应该不复杂，不在本次代码分析的目标之内，就没关注
• 各种filter注册和使用，同上，没关注
• etcd部署及使用，etcd在k8s中的使用，这部分属于扩展知识，有时间再看下

跟OpenStack API处理流程的比较

最大的差异当然还是语言上的，python和Go还是有点不太一样的，所以用到的RestFul HTTP Server的框架也不一样，route定义和注册流程也差别比较大，当然还是习惯问题，如果整天看这些代码，用这些框架，也就不会有刚开始看代码时很强烈的差异感了。犹记得当年刚开始看OpenStack nova-api route注册转发流程也是一脸懵逼好久好久。。。

其他方面就是交互流程不一样，当然Get方法差不多，都是接收用户API请求，然后分发到具体的处理方法（route到controller或handler），之后controller或handler从后端数据库（MySQL或etcd）查询用户请求的数据，最后封装返回给用户，再由controller或handler获取请求数据之前还会对用户请求进行多次filter过程，把不合法或不合适的请求过滤掉，只允许合法合适（如未被限流）的请求被controller或handler处理并正常返回用户。

而Create方法，则差异比较大，OpenStack一般是用消息队列进行消息传递，从API服务把具体执行的动作RPC到其他服务（如调度服务、计算节点管理服务等），动作执行过程中或者执行完毕也会通过RPC更新操作状态到数据库（当然最开始是直接访问数据库，后面为了安全改为经过RPC）。而k8s则是完全通过etcd来完成各个组件之间的异步交互，通过watch各自关系的key来实现消息传递和异步调用，操作状态更新也是通过更新etcd来实现。