参考文档

APIs 和 CLIs 的设计文档,概念定义以及引用

编辑这个页面

Kubernetes API 概述

用户指南记录了主系统和API概念。

API规范文档描述了API整体规范。

远程访问API在访问文档有讨论。

Kubernetes API是系统描述性配置的基础。 Kubectl 命令行工具被用于创建,更新,删除,获取API对象。

Kubernetes 通过API资源存储自己序列化状态(现在存储在etcd)。

Kubernetes 被分成多个组件,各部分通过API相互交互。

API 更改

根据经验,任何成功的系统都需要成长和改变,可能是一个新的示例出现,也可能是对已有系统进行更改。因此,我们希望Kubernetes API也可以持续的改变和成长。在较长一段时间内,我们不打算中断已有客户端。一般情况,经常会有新的API资源和新的资源字段增加。删除资源或者字段会有一个跟踪废弃流程。删除功能有一个小的废弃策略叫做TBD,但是Kubernetes到达1.0版本时,将会有一个详细的策略代替。

如何构成一个兼容性的改变以及如何更改API的详细信息都在API变化文档

API Swagger definitions

Kubernetes用 Swagger v1.2 记录API所有细节。Kubernetes apiserver (aka “master”)提供了一个API接口用于获取 Swagger Kubernetes API 规范 ,默认在路径/swaggerapi下,/swagger-ui是可以使用浏览器查看API文档的UI 。

我们会定期更新最新 API 文档的 UI。如果你使用不同版本的 Kubernetes,你需要使用不同的规范。

Kubernetes 实现一个用于集群内通信的基于 API 规范的另一种 Protobuf,记录每一个位于 Go packages 内定义的 API 对象。

API 版本

为了使删除字段或者重构资源表示更加容易,Kubernetes支持多个API版本。每一个版本都在不同API路径下,例如 /api/v1 或者/apis/extensions/v1beta1

我们选择版本时时根据API而不是根据资源或者字段来确认的,API为系统资源和行为提供了一个清晰的,一致性的视图,并且可以控制访问生命周期结束和/或测试的APIs。JSON 和 Protobuf格式遵循相同标准,下面所有描述都覆盖这两种格式。

注意API版本控制和软件版本控制只能间接的相关联。文档API 和发布版方案 描述了API版本控制和软件版本控制两者之间的关系。

不同的API版本会有不同级别的稳定性和支持。每个级别的详细描述包含在文档API 文档的更改中。 内容主要概括如下:

API 群组

为了使扩展 Kubernetes API更加简单, 我们正在实现API群组。 API群组是一些可以读和/或更改相同基础资源的简单的不同的接口。API群组被定义在一个REST路径下, 在apiVersion的一个序列化对象的字段。

当前有两个API群组在使用:

  1. “core”群组,在REST路径/api/v1下,但不是apiVersion字段的一部分。例如: apiVersion: v1
  2. “extensions”群组, 在REST路径/apis/extensions/$VERSION下, 并且使用 apiVersion: extensions/$VERSION (例如: 当前是apiVersion: extensions/v1beta1)。 最终这个持有类型可能会移动到其他的 API 组。
  3. “componentconfig” 和 “metrics” API 群组。

未来我们希望有更多的 API 群组,并且所有的群组都在 REST 路径 /apis/$API_GROUP下,并且使用apiVersion: $API_GROUP/$VERSION。 我们希望将来有一种方式支持第三方可以创建自己的 API 群组,并且可以避免命名冲突。

扩展资源

默认情况下DaemonSets, Deployments, HorizontalPodAutoscalers, Ingress,Jobs和ReplicaSets都是可用的。 其他的扩展资源通过设置 apiserver 的 runtime-config 使其可用。 runtime-config 可通过都逗号分开多个值。

例如:禁用deployments和jobs,--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/jobs=false

v1beta1, v1beta2, 和 v1beta3 已经废弃;请转到v1 ASAP

2015年6月4日,开始默认启用Kubernetes v1 API。v1beta1 和 v1beta2 APIs 在2015年6月1日删除。v1beta3 计划会在2015年6月6日删除。

v1 转换技巧(从 v1beta3 )

我们已经将所有文档和例子转换成 v1 版本。使用kubectl create --validate命令可以使你的 json 或者 yaml 遵循 Swagger spec 规范。

v1beta3 和 v1 版本之间最重要的不同是 services 的改变。

v1beta3 和 v1 版本之间其他的不同:

v1beta3 转换技巧(从 v1beta1/2)

v1beta1/2 和 v1beta3 重要不同点:

Analytics