服务目录控制面通信与安全基线核验 - 第3节

3.1 Service Catalog 的定义与核心定位

Service Catalog 是 Kubernetes 生态中用于管理外部服务依赖的扩展组件。它允许集群内的应用通过声明式的方式发现、订阅和绑定由外部 Broker 提供的托管服务（如数据库、消息队列、对象存储等），而无需手动处理连接凭证或网络配置。

从架构视角看，Service Catalog 充当了Kubernetes 控制平面与外部服务市场之间的桥梁。它实现了两个关键能力：

• 服务发现：从 Service Broker 获取可用服务及其方案的目录。
• 服务生命周期管理：通过 Kubernetes 原生资源对象（ClusterServiceClass、ServiceInstance、ServiceBinding）驱动服务的创建、绑定、更新与删除。

3.1.1 核心资源模型

3.2 Open Service Broker API 标准

Open Service Broker API（OSB API）是 Service Catalog 与外部 Broker 通信的标准化协议。它定义了一组 RESTful 端点，用于实现服务的生命周期管理和绑定。该标准由 Cloud Foundry、Kubernetes 和 OpenShift 等社区共同维护，确保了跨平台的服务互操作性。

3.2.1 OSB API 核心端点

3.2.2 异步操作与轮询

对于耗时较长的操作（如创建数据库实例），OSB API 支持异步响应。Broker 在收到请求后立即返回 202 Accepted，并在响应头中提供 Operation 字段。Catalog 控制器随后通过轮询 /v2/service_instances/:id/last_operation 端点来获取操作状态。

# 异步创建实例的典型流程
PUT /v2/service_instances/abc-123
{
  "service_id": "mysql-service-id",
  "plan_id": "small-plan-id",
  "parameters": { "storage_gb": 10 }
}
# 响应：202 Accepted
# Location: /v2/service_instances/abc-123/last_operation?operation=provisioning-001

# 轮询状态
GET /v2/service_instances/abc-123/last_operation?operation=provisioning-001
# 响应：{"state": "in progress"}
# 最终响应：{"state": "succeeded"}

3.3 服务目录的价值

引入 Service Catalog 为云原生平台带来了以下核心价值：

• 标准化服务消费：应用团队无需关心底层基础设施的差异，通过统一的 Kubernetes 资源即可消费任何兼容 OSB API 的服务。
• 降低运维复杂度：服务实例的创建、扩缩容、备份等操作由 Broker 负责，平台团队只需维护 Catalog 控制器的健康。
• 安全凭证管理：绑定操作自动将连接信息写入 Kubernetes Secret，避免硬编码或手动传递敏感信息。
• 多云与混合云支持：同一套 Service Catalog 可以对接多个 Broker（公有云、私有云、本地中间件），实现服务资源的统一视图。

3.4 Service Catalog 与 Broker 的通信架构

下图展示了 Service Catalog 控制器如何通过 OSB API 与外部 Broker 交互，完成服务实例的创建与绑定流程。

3.5 服务目录的典型工作流程

下图展示了从用户提交 ServiceInstance 到应用 Pod 获取凭证的完整时序流程。