本文已超过一年。较旧的文章可能包含过时内容。请检查页面信息自发布以来是否已失效。

Kubernetes 支持 OpenAPI

作者：Mehdy Bohlool (Google) |

编者按：本文是关于 Kubernetes 1.5 新特性的系列深度文章的一部分

OpenAPI 允许 API 提供商定义其操作和模型，并使开发者能够自动化其工具并生成他们喜欢的语言客户端来与该 API 服务器通信。Kubernetes 曾支持 swagger 1.2（OpenAPI 规范的旧版本）一段时间，但该规范不完整且无效，导致难以基于它生成工具/客户端。

在 Kubernetes 1.4 中，我们通过升级现有模型和操作，引入了对 OpenAPI 规范（在捐赠给 Open API Initiative 之前称为 swagger 2.0）的 Alpha 支持。从 Kubernetes 1.5 开始，通过直接从 Kubernetes 源代码自动生成规范，OpenAPI 规范的支持已趋于完善，这将使规范和文档与未来操作/模型的变更保持完全同步。

新的规范使我们能够拥有更好的 API 文档，我们甚至还推出了一个受支持的 Python 客户端。

该规范是模块化的，按 GroupVersion 划分：这具有前瞻性，因为我们打算允许不同的 GroupVersion 从不同的 API 服务器提供服务。

规范的结构在 OpenAPI spec definition 中有详细解释。我们使用操作的标签 (tags) 来区分每个 GroupVersion，并尽可能详细地填写了有关路径/操作和模型的信息。对于特定的操作，所有参数、调用方法和响应都已记录在案。

例如，读取 Pod 信息的 OpenAPI 规范如下：

{

...  
  "paths": {

"/api/v1/namespaces/{namespace}/pods/{name}": {  
    "get": {  
     "description": "read the specified Pod",  
     "consumes": [  
      "\*/\*"  
     ],  
     "produces": [  
      "application/json",  
      "application/yaml",  
      "application/vnd.kubernetes.protobuf"  
     ],  
     "schemes": [  
      "https"  
     ],  
     "tags": [  
      "core\_v1"  
     ],  
     "operationId": "readCoreV1NamespacedPod",  
     "parameters": [  
      {  
       "uniqueItems": true,  
       "type": "boolean",  
       "description": "Should the export be exact.  Exact export maintains cluster-specific fields like 'Namespace'.",  
       "name": "exact",  
       "in": "query"  
      },  
      {  
       "uniqueItems": true,  
       "type": "boolean",  
       "description": "Should this value be exported.  Export strips fields that a user can not specify.",  
       "name": "export",  
       "in": "query"  
      }  
     ],  
     "responses": {  
      "200": {  
       "description": "OK",  
       "schema": {  
        "$ref": "#/definitions/v1.Pod"  
       }  
      },  
      "401": {  
       "description": "Unauthorized"  
      }  
     }  
    },

…

}

…

利用这些信息和 kube-apiserver 的 URL，即可通过给定 URL (/api/v1/namespaces/{namespace}/pods/{name}) 以及 name、exact、export 等参数来获取 Pod 的信息。客户端库生成器也会使用这些信息来创建用于读取 Pod 信息的 API 函数调用。例如，Python 客户端使得调用此操作变得非常简单，如下所示：

from kubernetes import client

ret = client.CoreV1Api().read\_namespaced\_pod(name="pods\_name", namespace="default")

生成的 read_namespaced_pod 简化版本可以在这里找到。

Swagger-codegen 文档生成器也可以使用相同信息创建文档：

GET /api/v1/namespaces/{namespace}/pods/{name}

(readCoreV1NamespacedPod)

read the specified Pod

Path parameters

name (required)

Path Parameter — name of the Pod

namespace (required)

Path Parameter — object name and auth scope, such as for teams and projects

Consumes

This API call consumes the following media types via the Content-Type request header:

-
\*/\*


Query parameters

pretty (optional)

Query Parameter — If 'true', then the output is pretty printed.

exact (optional)

Query Parameter — Should the export be exact. Exact export maintains cluster-specific fields like 'Namespace'.

export (optional)

Query Parameter — Should this value be exported. Export strips fields that a user can not specify.

Return type

v1.Pod


Produces

This API call produces the following media types according to the Accept request header; the media type will be conveyed by the Content-Type response header.

-
application/json
-
application/yaml
-
application/vnd.kubernetes.protobuf

Responses

200

OK v1.Pod

401

Unauthorized

有两种方式访问 OpenAPI 规范：

  • 从 kuber-apiserver/swagger.json 获取。此文件包含所有已启用的 GroupVersions 路由和模型，并且是与特定 kube-apiserver 最同步的文件。
  • 从 Kubernetes GitHub 仓库获取，其中包含所有核心 GroupVersions。您可以在 master 分支或特定版本（例如 1.5 版本）上访问它。

有许多与此规范兼容的工具。例如，您可以使用 swagger editor 打开规范文件并渲染文档，以及生成客户端；或者您也可以直接使用 swagger codegen 生成文档和客户端。生成的客户端基本上可以直接使用，但您需要一些授权支持和 Kubernetes 特定的实用程序。请使用 Python 客户端作为模板来创建您自己的客户端。

如果您想参与 OpenAPI 支持、客户端库的开发或报告 bug，可以联系 SIG-API-Machinery 的开发者。