3. Open Service Broker API (OSB)

Open Service Broker API（OSB）是 Kubernetes 服务目录（Service Catalog）与外部托管服务（如数据库、消息队列、对象存储）之间的核心集成协议。它定义了一组标准化的 RESTful 接口，使得云原生应用能够以一致的方式发现、申请、绑定和释放托管服务，而无需关心底层基础设施的差异。

核心价值：OSB 将服务管理从“运维手动配置”转变为“开发者自助申请”，实现了服务生命周期的完全自动化，是 Kubernetes 生态中实现“服务网格”和“平台工程”的关键技术基础。

3.1 OSB 规范概述

OSB 规范由 Cloud Foundry 社区发起，后由 Open Service Broker API 工作组维护，目前已成为云原生计算基金会（CNCF）的孵化项目。其核心思想是引入一个 Service Broker（服务代理）作为中间层，统一管理服务的生命周期。

规范定义了三个主要角色：

  • Service Broker： 实现 OSB API 的服务提供者，负责管理底层服务实例的生命周期。每个 Broker 对外暴露一个 RESTful 端点。
  • Service Catalog： Kubernetes 集群内的资源控制器，负责与 Broker 通信，将 Broker 提供的服务列表同步为集群内的 ClusterServiceClass 和 ClusterServicePlan 资源。
  • Application / User： 服务的消费者，通过创建 ServiceInstance 和 ServiceBinding 资源来申请和使用服务。
OSB 架构与角色关系图 OSB 架构与角色关系 Kubernetes 集群 Service Catalog ServiceInstance ServiceBinding Service Broker 创建 创建 provision bind

3.2 核心接口详解

OSB API 定义了五个核心接口，覆盖了服务从注册到销毁的完整生命周期。每个接口都对应一个标准的 HTTP 方法和路径，Broker 必须实现这些端点。

接口名称 HTTP 方法 路径模板 功能描述
catalog GET /v2/catalog 返回 Broker 提供的所有服务及其可用的服务计划（plan）列表。
provision PUT /v2/service_instances/:instance_id 创建一个新的服务实例（如一个数据库实例）。
bind PUT /v2/service_instances/:instance_id/service_bindings/:binding_id 将应用绑定到服务实例，返回连接凭证（如用户名、密码、地址）。
unbind DELETE /v2/service_instances/:instance_id/service_bindings/:binding_id 解除应用与服务实例的绑定关系，删除连接凭证。
deprovision DELETE /v2/service_instances/:instance_id 删除一个服务实例，释放底层资源。
关键设计原则：OSB 接口设计遵循“异步操作”模式。对于耗时较长的操作（如 provision、deprovision），Broker 可以返回 202 Accepted 状态码，并提供一个 last_operation 端点供客户端轮询操作状态。这保证了 API 在面对复杂后端服务时的健壮性。

3.3 生命周期管理

OSB 的生命周期管理围绕“服务实例”和“服务绑定”两个核心资源展开，形成一个清晰的状态机模型。

3.3.1 服务实例生命周期

  1. 发现（Discover）： Service Catalog 调用 Broker 的 catalog 接口，获取服务列表和计划。
  2. 申请（Provision）： 用户创建 ServiceInstance 资源，Catalog 调用 Broker 的 provision 接口，Broker 在后台创建实际服务资源（如 RDS 实例、Redis 集群）。
  3. 使用（Use）： 实例处于 Ready 状态，可以被绑定和使用。
  4. 释放（Deprovision）： 用户删除 ServiceInstance 资源，Catalog 调用 Broker 的 deprovision 接口，Broker 销毁后台资源。

3.3.2 服务绑定生命周期

  1. 绑定（Bind）： 用户创建 ServiceBinding 资源，Catalog 调用 Broker 的 bind 接口，Broker 生成连接凭证并返回。
  2. 注入（Inject）： Catalog 将凭证以 Kubernetes Secret 的形式注入到用户的 Pod 中。
  3. 解绑（Unbind）： 用户删除 ServiceBinding 资源，Catalog 调用 Broker 的 unbind 接口，Broker 吊销凭证。
服务实例与绑定生命周期状态机 服务实例与绑定生命周期状态机 服务实例 (ServiceInstance) Pending Ready Deprovisioning provision deprovision 服务绑定 (ServiceBinding) Pending Bound Unbinding bind unbind 绑定依赖于实例

3.4 接口调用示例

以下是一个典型的 provision 请求示例，展示了如何向 Broker 申请一个 PostgreSQL 实例。

PUT /v2/service_instances/abc-123-def-456 HTTP/1.1
Host: broker.example.com
Content-Type: application/json
X-Broker-API-Version: 2.16

{
  "service_id": "postgresql-db-service",
  "plan_id": "standard-plan",
  "organization_guid": "org-guid-here",
  "space_guid": "space-guid-here",
  "parameters": {
    "db_name": "myapp_db",
    "storage_gb": 20
  }
}

Broker 成功创建实例后，返回以下响应：

HTTP/1.1 201 Created
Content-Type: application/json

{
  "dashboard_url": "https://broker.example.com/dashboard/abc-123-def-456",
  "operation": "provisioning-abc-123"
}
注意事项：
  • X-Broker-API-Version 头部是必须的，用于指定 API 版本。
  • organization_guid 和 space_guid 是 Cloud Foundry 遗留字段，在 Kubernetes 环境中通常使用 context 对象替代。
  • 对于异步操作，Broker 应返回 202 Accepted，客户端需通过 GET /v2/service_instances/:instance_id/last_operation 轮询最终状态。

3.5 OSB 在 Kubernetes 中的价值

OSB 规范为 Kubernetes 服务目录提供了标准化的“服务抽象层”，其核心价值体现在：

  • 解耦： 应用开发者无需关心服务是如何部署和管理的，只需通过声明式 API 申请即可。
  • 可移植性： 同一套应用代码可以无缝对接不同云厂商提供的 Broker 实现（如 AWS Service Broker、GCP Service Broker）。
  • 自动化： 服务的全生命周期（创建、配置、绑定、销毁）完全自动化，消除了人工操作带来的延迟和错误。
  • 生态丰富： 社区提供了大量现成的 Broker 实现，覆盖数据库、缓存、消息队列、监控等常见中间件。
← 上一章 📖 返回目录 下一章 →