1. 服务目录概念

服务目录（Service Catalog）是 Kubernetes 生态中用于管理、发布和绑定外部服务的标准化扩展组件。它通过 Open Service Broker API 将数据库、消息队列、对象存储等托管服务抽象为集群内可消费的资源，使应用团队无需关心底层基础设施的部署细节。

1.1 服务目录的定义

服务目录本质上是一个 Kubernetes 扩展 API 服务器，它引入了一组自定义资源（CRD），用于描述服务提供方、服务实例以及服务绑定关系。核心资源包括：

1.2 在 Kubernetes 生态中的角色

服务目录在云原生架构中扮演着服务抽象层和治理边界的双重角色。其核心价值体现在以下四个维度：

• 解耦应用与基础设施： 应用只需声明需要什么服务（如“我需要一个 PostgreSQL 数据库”），而不需要关心数据库是部署在集群内还是由云厂商 RDS 提供。
• 统一服务治理入口： 所有外部服务的接入、版本管理、权限控制都通过 Kubernetes API 完成，避免运维人员手动在多个控制台操作。
• 标准化服务消费流程： 开发者通过 kubectl apply -f service-instance.yaml 即可创建服务实例，通过 kubectl get servicebinding 获取连接信息，流程完全一致。
• 多集群服务共享： 结合 ClusterServiceBroker，可以在多个 Kubernetes 集群之间共享同一个外部服务目录，实现跨集群的服务发现与绑定。

1.3 与传统服务目录的区别

传统 IT 服务目录（如 ITIL 框架中的服务目录）与 Kubernetes 服务目录在目标、实现方式和消费模式上存在本质差异。下表从多个维度进行对比：

1.4 服务目录的核心工作流程

一个完整的服务目录消费流程包含以下步骤，开发者只需关注第 2 步和第 4 步：

1. Broker 注册： 集群管理员通过 ClusterServiceBroker 注册外部服务代理（如阿里云 RDS Broker）。
2. 服务类与计划发现： 服务目录自动从 Broker 拉取 ClusterServiceClass 和 ClusterServicePlan，开发者通过 kubectl get clusterserviceclass 查看可用服务。
3. 服务实例创建： 开发者提交 ServiceInstance 资源，指定服务类与计划，控制器调用 Broker 的 provision 接口创建实例。
4. 服务绑定： 开发者提交 ServiceBinding 资源，控制器调用 Broker 的 bind 接口获取凭证，并写入 Kubernetes Secret。
5. 应用消费： 应用 Pod 通过挂载 Secret 或环境变量获取数据库地址、用户名、密码，直接连接外部服务。

1.5 典型应用场景

• 多云服务统一管理： 同时对接阿里云 RDS、AWS RDS、自建 MySQL，通过服务目录统一暴露为 mysql-standard 服务类，开发者无需感知底层云厂商。
• 开发/测试环境快速供给： CI/CD 流水线中自动创建 ServiceInstance，测试完成后自动回收，避免人工创建数据库的等待时间。
• 服务版本灰度： 通过定义不同的 ClusterServicePlan（如 mysql-5.7 vs mysql-8.0），实现服务版本的平滑迁移。
• 成本控制与配额管理： 结合 Kubernetes RBAC，限制特定命名空间只能使用特定服务类或计划，防止开发者误创建高配实例。