欢迎来到深入学习 Kubernetes API Server 的系列文章， 在本系列文章中我们将深入的探究 Kubernetes API Server 的相关实现 。如果你对 Kubernetes 的内部实现机制比较感兴趣或者正在进行 Kubernetes 项目的相关开发工作，那么本系列文章能够为你提供一些帮助。了解学习过 go 语言，会在某些方面帮助你更好的理解本系列文章。
在本期文章中，我们首先会对 Kubernetes API Server 进行一个总体的大致说明，然后对 API 的技术术语及请求流作说明。在下几期的文章中则主要对 API Server 与 etcd 存储的交互以及对 API Server 进行相关扩展进行探讨，说明。
API Server 的总体说明
从理论上来说， Kubernetes 是由一些具有不同角色的节点组成的。作为控制面的主节点主要部署有 API Server, Controller Manager 和 Scheduler(s) 等组件。 API Server 作为 Kubernetes 中的管理中心，是唯一能够与存储 etcd 交互通信的组件。它主要能够提供如下服务：
1. 作为 Kubernetes API 的服务端，为集群内的节点以及 kubectl 工具提供 API 服务。
2. 作为集群组件的代理，例如 Kubernetes UI
3. 通过 API Server 能够对 Kubernetes 的 API 对象比如 pods ， services 进行增删查改等操作。
4. 保证在分布式存储系统 (etcd) 中的 Kubernetes API 对象的状态一致。
Kubernetes API 是一个 HTTP 形式的 API ， JSON 格式是它主要的序列化架构。同时它也支持协议缓冲区（ Protocol Buffers ）的形式，这种形式主要是用在集群内通信中。出于可扩展性原因考虑， Kubernetes 可支持多个 API 版本，通过不同的 API 路径的方式区分。比如 /api/v1 和 /apis/extensions/v1beta1 ，不同的 API 版本代表了这个 API 处于不同的版本稳定性阶段。
1. Alpha 阶段，比如 v1alpha1 ，在默认状态下为关闭状态。只在某个分支中支持使用，在将来可能会被废弃。一般只支持在测试环境中短期使用。
2. Beta 阶段，比如 v2beta3 ，在默认状态下为开启状态。表示这部分代码已经经过测试，基本功能已经通过验证。但是这个状态的 API 对象将来还是有可能发生不可兼容的改动以过度到 stable 稳定阶段。
3. Stable 阶段，比如 v1 ，是一个稳定的软件发布阶段， API 对象一般之后不会有太大改动。
接下去，我们介绍一下 HTTP API 主要结构。首先我们需要区分三种不同的 API 形式： core group API （在 /api/v1 路径下，由于某些历史原因而并没有在 /apis/core/v1 路径下）和 named groups API （在对应的 /apis/$NAME/$VERSION 路径下）及 system-wide API （比如 /metrics,/healthz ）。
一个 HTTP API 的主要结构如下所示：
接下去我们主要列举 batch group 下的两个 API 例子来讲解说明。在 Kubernetes 1.5 版本中， batch 群组下有 /apis/batch/v1 和 /apis/batch/v2alpha1 两个 API 版本来供开发者使用。我们来看一下 API 的整体实现（下面列举的 API 例子我们是 通过 proxy 命令 kubectl proxy --port=8080 直接访问 API 获得）。
$ curl http://127.0.0.1:8080/apis/batch/v1
{
"kind": "APIResourceList",
"apiVersion": "v1",
"groupVersion": "batch/v1",
"resources": [
{
"name": "jobs",
"namespaced": true,
"kind": "Job"
},
{
"name": "jobs/status",
"namespaced": true,
"kind": "Job"
}
]
}
在将来，将会使用更新的 alpha 版本：
$ curl http://127.0.0.1:8080/apis/batch/v2alpha1
{
"kind": "APIResourceList",
"apiVersion": "v1",
"groupVersion": "batch/v2alpha1",
"resources": [
{
"name": "cronjobs",
"namespaced": true,
"kind": "CronJob"
},
{
"name": "cronjobs/status",
"namespaced": true,
"kind": "CronJob"
},
{
"name": "jobs",
"namespaced": true,
"kind": "Job"
},
{
"name": "jobs/status",
"namespaced": true,
"kind": "Job"
},
{
"name": "scheduledjobs",
"namespaced": true,
"kind": "ScheduledJob"
},
{
"name": "scheduledjobs/status",
"namespaced": true,
"kind": "ScheduledJob"
}
]
}
总体上来说 Kubernetes API 支持对 API 对象的增删查改（ create, update, delete, retrieve ）通过使用 JSON 作为默认格式的 HTTP ( POST , PUT , DELETE , GET) 方式来实现。
大多数 API 对象会区分对象想要达到的预期状态以及当前对象所处的实际状态。所以一个规范的 API 描述应该对于这两种状态都有完整的描述说明并在储存（ etcd ）中记录。
API Server 的术语说明
在对 API Server 以及 HTTP API 结构进行总体说明后，接下去我们对一些术语来进行说明解释。 Kubernetes 的主要 API 对象主要有 pods, services, endpoints, deployment 等。一个 API 对象主要由以下条目
Kind: 是一个 API 对象的类型。它告诉了 client( 比如 kubectl) 这种 API 对象所代表的实体类型。比如一个 pod
apiVersion: v1
kind: Pod
metadata:
name: webserver
spec:
containers:
- name: nginx
image: nginx:1.9
ports:
- containerPort: 80
目前 API 中有三种 Kinds 类型：
1. Object 对象代表了系统中持久存在的实体，一个 object 对象可能具有多个 resources 资源能让客户端来执行一些特定的操作。比如 Pod 和 namespace.
2. Lists 代表了一些 resources 资源或者 object 实体对象的集合。比如 PodLists 和 NodeLists.
3. 代表了一个对实体对象的操作或一个非实体存在的状态过程。比如 binding 或者 status 等。
API Group : 是一组相关的 Kind 的集合。比如在 Kind:Job 以及 Kind:ScheduleJob 都属于 batch 的 API Group.
Version ：每个 API Group 下面都能存在有多个 version 版本。比如在一个 group 群组中最早有第一个 v1alpha1 版本，后来中间发展到了 v1beta1 版本，最终发展到 v1 的稳定版本。如果在系统创建了一个 v1beta1 版本的对象，那么它能过被 Group 任一支持的版本（比如 v1 ）检索到。这是由于 API server 能够支持不同版本对象之间的无损耗转换。
Resource ：代表以 JSON 格式通过 HTTP 发送或检索的资源实体。它既可以使一个单独的 resource 资源（比如 .../namespaces/default ）也可以是一组 resource 资源（比如 .../jobs ）
一个 API Group 群组，一个 Version 版本，一个 Resource （ GVR ）资源就能过定义一个唯一的 HTTP 路径。
实际上，一个 job 对象的 API 路径为 /apis/batch/v1/namespaces/$NAMESPACE/jobs ，因为 jobs 并不是 cluster 侧的资源，所以需要有 namespace 字段。与之相对 node 作为 cluster 侧的资源，它的 API 路径就没有 $NAMESPACE 的部分。
值得注意的是 Kinds 不一定只在同一个 Group 群组下存在不同的 Version 版本，它在不同的 Group 群组也有可能存在不同的 Version 版本。比如 Deployment 一开始在 extensions group 群组中作为 alpha 版本存在，但最后它发展成 GA version 版本时拥有了一个新的独立的 Group 群组 apps.k8s.io 。因此，如果想要区分唯一的 Kinds, 必须要有 API Group ， Version 以及 Kind(GVK) 三部分。
API 请求流过程
在对 Kubernetes API 中的术语有了了解之后，接下去我们将讨论 API 请求的处理流程。相关 API 主要在 k8s.io/pkg/api 可以看到，它既处理来自集群内的 API 请求也处理来自集群外的 API 请求。
当 API Server 接收到一个 HTTP 的 Kubernetes API 请求时，它主要处理流程如下所示：
1. HTTP 请求通过一组定义在 DefaultBuildHandlerChain() （ config.go ）函数中的过滤处理函数处理，并进行相关操作（相关过滤处理函数如下图所示）。这些过滤处理函数将 HTTP 请求处理后存到中 ctx.RequestInfo ，比如用户的相关认证信息，或者相应的 HTTP 请求返回码。
2. 接着 multiplexer （ container.go ）基于 HTTP 路径会将 HTTP 请求发给对应的各自的处理 handlers 。
3. routes （在 routes/* 定义）路由将 HTTP 路径与 handlers 处理器关联。
4. 根据每个 API Group 注册的处理程序获取 HTTP 请求相关内容对象（比如用户，权限等），并将请求的内容对象存入存储中。
完整的处理流程如下图所示
再次提醒，为简洁起见，我们省略了上图中 HTTP 路径的 $NAMESPACE 字段。
下面我们来仔细看一下定义在 DefaultBuildHandlerChain() ( config.go ) 函数中的相关 filters 过滤处理函数：
1. 定义在 requestinfo.go 中的 WithRequestInfo() 函数主要获取 HTTP 请求的 RequestInfo 内容。
2. 定义在 maxinflight.go 的中的 WithMaxInFlightLimit() 函数限制请求的 in-flight 数量。
3. 定义在 timeout.go 的中的 WithTimeoutForNonLongRunningRequests() 函数主要定义了类似 GET , PUT , POST , DELETE 等 non-long-running 请求的超时时间。
4. 定义在 wrap.go 中的 WithPanicRecovery() 函数主要定义了当发生 panic 之后的相关处理。
5. 定义在 cors.go 中的 WithCORS() 函数主要提供了 CORS 实现。 CORS 代表跨源资源共享，它是一种机制，允许能够处理嵌入在 HTML 页面中的 JavaScript 的 XMLHttpRequests 请求。
6. 定义在 authentication.go 中的 WithAuthentication() 函数主要对请求中的用户信息进行验证，并将用户信息存到相应的 context 中。如果认证成功，那么 Authorization HTTP 头将会在 request 请求体中移除。
7. 定义在 audit.go 中的 WithAudit() 函数主要将 request 的用户信息进行相关处理。然后将 Request 请求的源 IP ，用户名，用户操作及 namespace 等信息记入到相关审计日志中。
8. 定义在 impersonation.go 中的 WithImpersonation() 函数主要处理用户模拟，通过尝试修改请求的用户 ( 比如 sudo) 的方式。
9. 定义在 authorization.go 中的 WithAuthorization() 函数主要请求中的用户权限就行验证，如果验证通过则发送给相应的 handler 进行处理，如果权限验证不通过则拒绝此次请求，返回相应错误。
本部分文章主要对 API Server 进行了一个总体介绍。下一部分，我们将对 API 资源的序列化以及如何存入到相关分布式存储中进行探究。https://www.huaweicloud.com/product/cce.html
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31543630/viewspace-2213240/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/31543630/viewspace-2213240/
112
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
