REST API是Kubernetes系统的重要部分，组件之间的所有操作和通信均由API Server处理的REST API调用，大多数情况下，API定义和实现都符合标准的HTTP REST格式，可以通过 kubectl命令管理工具或其他命令行工具来执行。
API 版本
为了在兼容旧版本的同时不断升级新的API，Kubernetes支持多种API版本，每种API版本都有不同的API路径，例如/api/v1或 /apis/extensions/v1beta1。
API版本规则是通过基于API level选择版本，而不是基于资源和域级别选择，是为了确保API能够描述一个清晰的连续的系统资源和行为的视图，能够控制访问的整个过程和控制实验性API的访问。
- JSON和Protobuf序列化模式遵循相同的模式变化原则，以下所有描述都涵盖了这两种模式。
需要注意，API版本和软件的版本没有直接关系，不同API版本有不同程度稳定性，API文档中详细描述了每个级别的标准。
-
Alpha级别：
- 包含alpha名称的版本（例如v1alpha1）。
- 该软件可能包含错误。启用一个功能可能会导致bug。默认情况下，功能可能会被禁用。
- 随时可能会丢弃对该功能的支持，恕不另行通知。
- API可能在以后的软件版本中以不兼容的方式更改，恕不另行通知。
- 该软件建议仅在短期测试集群中使用，因为错误的风险增加和缺乏长期支持。
-
Beta级别：
- 包含beta名称的版本（例如v2beta3）。
- 该软件经过很好的测试。启用功能被认为是安全的。默认情况下功能是开启的。
- 细节可能会改变，但功能在后续版本不会被删除
- 对象的模式或语义在随后的beta版本或Stable版本中可能以不兼容的方式发生变化。如果这种情况发生时，官方会提供迁移操作指南。这可能需要删除、编辑和重新创建API对象。
- 该版本在后续可能会更改一些不兼容地方，所以建议用于非关键业务，如果你有多个可以独立升级的集群，你也可以放宽此限制。
- 大家使用过的Beta版本后，可以多给社区反馈，如果此版本在后续更新后将不会有太大变化。
-
Stable级别：
- 该版本名称命名方式：vX这里X是一个整数。
- Stable版本的功能特性，将出现在后续发布的软件版本中。
API groups
API groups使得Kubernetes API的扩展更加方便。API groups是在REST路径和序列化对象的apiVersion字段中被指定。
目前，有几个API groups在使用:
- 核心(also called legacy)组，REST路径在/api/v1,但此路径不是固定的，v1是当前的版本。与之相对应的代码里面的apiVersion字段的值为v1。
- Named Groups，REST路径被指定在/apis/$GROUP_NAME/$VERSION中，并使用apiVersion: $GROUP_NAME/$VERSION（例如apiVersion: batch/v1）。在Kubernetes API参考引用中可以看到API Groups的完整列表。
使用自定义资源扩展API的两种方法：
- CustomResourceDefinition为有基本CRUD需求用户提供。
- 即将推出：需要有完整的Kubernetes API语义的用户，可以实现自定义的api server，并使用聚合器来无缝连接客户端。
启用API Groups
可以使用--runtime-config 在api server上设置来启用或禁用某些资源和API Groups。--runtime-config可以使用逗号分隔值。例如，要禁用batch / v1，set --runtime-config=batch/v1=false, to enable batch/v2alpha1, set --runtime-config=batch/v2alpha1。该标签接受逗号分隔的一组key = value对，描述了运行时的api server配置。
提示：启用和禁用Groups或资源需要重新启动apiserver和controller-manager确保--runtime-config更改生效。
启用组中的资源
DaemonSets，Deployments，HorizontalPodAutoscalers，Ingress，Jobs和ReplicaSets，都是默认启用的。可以通过--runtime-config在api server上设置来启用其他扩展资源。--runtime-config接受逗号来分隔值。例如，要禁用deployments和 jobs，请设置 --runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/jobs=false
Kubernetes API 访问控制
Kubernetes 对 API 访问提供了三种安全访问控制措施：认证、授权和 Admission Control。认证解决用户是谁的问题，授权解决用户能做什么的问题，Admission Control 则是资源管理方面的作用。通过合理的权限管理，能够保证系统的安全可靠。
Kubernetes 集群的所有操作基本上都是通过 kube-apiserver 这个组件进行的，它提供 HTTP RESTful 形式的 API 供集群内外客户端调用。需要注意的是：认证授权过程只存在 HTTPS 形式的 API 中。也就是说，如果客户端使用 HTTP 连接到 kube-apiserver，那么是不会进行认证授权的。所以说，可以这么设置，在集群内部组件间通信使用 HTTP，集群外部就使用 HTTPS，这样既增加了安全性，也不至于太复杂。
下图是 API 访问要经过的三个步骤，前面两个是认证和授权，第三个是 Admission Control
可以使用kubectl、客户端库方式对REST API的访问，Kubernetes的普通账户和Service帐户都可以实现授权访问API。API的请求会经过多个阶段的访问控制才会被接受处理，其中包含认证、授权以及准入控制（Admission Control）等。如下图所示：
需要注意：认证授权过程只存在HTTPS形式的API中。也就是说，如果客户端使用HTTP连接到kube-apiserver，是不会进行认证授权的。所以说，可以这么设置，在集群内部组件间通信使用HTTP，集群外部就使用HTTPS，这样既增加了安全性，也不至于太复杂。
认证
开启TLS时，所有的请求首先需要认证。Kubernetes支持多种认证机制，并支持同时开启多个认证插件（只要有一个认证通过即可）。如果认证成功，则用户的username会传入授权模块做进一步授权验证；对于认证失败的请求则返回HTTP 401。
当TLS建立时，HTTP请求会进行身份认证步骤，如图中步骤1，集群管理器将apiserver配置为运行一个或多个认证器模块。
认证模块包含客户端证书，密码、Plain Tokens、Bootstrap Tokens、JWT Tokens（used for service accounts）。
我们可以指定多个认证模块，每个认证模块都会按顺序进行，直到其中一个成功。
（在GCE上，客户端证书、密码、Plain Tokens和JWT Tokens都会启用。）
更多认证模块的使用方法可以参考 认证
授权
认证之后的请求是授权模块。如图中步骤2 。
请求必须包含请求者的用户名，请求的操作以及受该操作影响的对象，如果策略已经声明用户具有完成请求的权限，则该请求将被授权。
例如：设置如下Bob策略，那么会在namespace projectCaribou 中读取pods
准入控制（Admission Control）
准入控制（Admission Control）用来对请求做进一步的验证或添加默认参数，除了授权模块可用的属性外，准入控制模块还可以访问正在创建或更新对象内容。
也可以可以配置多个准入控制器，每个都会按顺序调用。
如图中步骤3。
与认证和授权模块不同，任何接入控制器模块被遭拒时，请求会立即失败。
当请求通过了所有准入控制（Admission Control），就会使用相应API对象的验证功能，然后写入对象存储（如步骤4所示）
