diff --git a/content/zh/docs/concepts/extend-kubernetes/service-catalog.md b/content/zh/docs/concepts/extend-kubernetes/service-catalog.md
index 0ee381052c..29b12f6bea 100644
--- a/content/zh/docs/concepts/extend-kubernetes/service-catalog.md
+++ b/content/zh/docs/concepts/extend-kubernetes/service-catalog.md
@@ -1,22 +1,18 @@
---
title: 服务目录
-reviewers:
-- chenopis
content_type: concept
weight: 40
---
-{{< glossary_definition term_id="service-catalog" length="all" prepend="" >}}
+{{< glossary_definition term_id="service-catalog" length="all" prepend="服务目录（Service Catalog）是" >}}
-服务代理是由[开放服务代理 API 规范](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)定义的一组托管服务的终结点，由第三方提供并维护，其中的第三方可以是 AWS，GCP 或 Azure 等云服务提供商。
-托管服务的一些示例是 Microsoft Azure Cloud Queue，Amazon Simple Queue Service 和 Google Cloud Pub/Sub，但它们是可以使用应用程序的任何软件产品。
-
-使用服务目录，集群操作者可以浏览其提供的托管服务列表，提供托管服务实例并与之绑定，以使其可以被 Kubernetes 集群中的应用程序使用。
-
-
+服务代理（Service Broker）是由[Open Service Broker API 规范](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)定义的一组托管服务的端点，这些服务由第三方提供并维护，其中的第三方可以是 AWS、GCP 或 Azure 等云服务提供商。
+托管服务的一些示例是 Microsoft Azure Cloud Queue、Amazon Simple Queue Service 和 Google Cloud Pub/Sub，但它们可以是应用程序能够使用的任何软件交付物。
+使用服务目录，{{< glossary_tooltip text="集群操作员" term_id="cluster-operator" >}}
+可以浏览某服务代理所提供的托管服务列表，供应托管服务实例并与之绑定，
+以使其可以被 Kubernetes 集群中的应用程序使用。
## 示例用例
-应用开发者希望使用消息队列作为其在 Kubernetes 集群中运行的应用程序的一部分。
-但是，它们不想承受建立这种服务的开销，也不想自行管理。幸运的是，有一家云服务提供商通过它们的服务代理将消息队列作为托管服务提供。
+{{< glossary_tooltip text="应用开发人员" term_id="application-developer" >}}，
+希望使用消息队列，作为其在 Kubernetes 集群中运行的应用程序的一部分。
+但是，他们不想承受构造这种服务的开销，也不想自行管理。
+幸运的是，有一家云服务提供商通过其服务代理以托管服务的形式提供消息队列服务。
-集群运维人员可以设置服务目录并使用它与云服务提供商的服务代理 通信，以此提供消息队列服务的实例并使其对 Kubernetes 中的应用程序可用。
-因此，应用开发者可以不用关心消息队列的实现细节，也不用对其进行管理。它们的应用程序可以简单的将其作为服务使用。
+集群操作员可以设置服务目录并使用它与云服务提供商的服务代理通信，进而部署消息队列服务的实例
+并使其对 Kubernetes 中的应用程序可用。
+应用开发者于是可以不关心消息队列的实现细节，也不用对其进行管理。
+他们的应用程序可以简单的将其作为服务使用。
-## 架构
-服务目录使用[开放服务代理 API](https://github.com/openservicebrokerapi/servicebroker) 与服务代理进行通信，并作为 Kubernetes API Server 的中介，以便协商首要规定并获取应用程序使用托管服务的必要凭据。
+## 架构 {#architecture}
-它被实现为一个扩展 API 服务和一个控制器管理器，使用 Etcd 作为存储。它还使用了 Kubernetes 1.7+ 版本中提供的 [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 来呈现其 API。
+服务目录使用[Open Service Broker API](https://github.com/openservicebrokerapi/servicebroker)
+与服务代理进行通信，并作为 Kubernetes API 服务器的中介，以便协商启动部署和获取
+应用程序使用托管服务时必须的凭据。
-
+服务目录实现为一个扩展 API 服务器和一个控制器，使用 Etcd 提供存储。
+它还使用了 Kubernetes 1.7 之后版本中提供的
+[聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+来呈现其 API。
-
+
-## API 资源
+## API 资源 {#api-resources}
服务目录安装 `servicecatalog.k8s.io` API 并提供以下 Kubernetes 资源：
-* `ClusterServiceBroker`：服务目录的集群内代表，封装了它的服务连接细节。集群运维人员创建和管理这些资源，并希望使用该代理服务在集群中提供新类型的托管服务。
+* `ClusterServiceBroker`：服务目录的集群内表现形式，封装了其服务连接细节。集群运维人员创建和管理这些资源，并希望使用该代理服务在集群中提供新类型的托管服务。
* `ClusterServiceClass`：由特定服务代理提供的托管服务。当新的 `ClusterServiceBroker` 资源被添加到集群时，服务目录控制器将连接到服务代理以获取可用的托管服务列表。然后为每个托管服务创建对应的新 `ClusterServiceClass` 资源。
* `ClusterServicePlan`：托管服务的特定产品。例如托管服务可能有不同的计划可用，如免费版本和付费版本，或者可能有不同的配置选项，例如使用 SSD 存储或拥有更多资源。与 `ClusterServiceClass` 类似，当一个新的 `ClusterServiceBroker` 被添加到集群时，服务目录会为每个托管服务的每个可用服务计划创建对应的新 `ClusterServicePlan` 资源。
* `ServiceInstance`：`ClusterServiceClass` 提供的示例。由集群运维人员创建，以使托管服务的特定实例可供一个或多个集群内应用程序使用。当创建一个新的 `ServiceInstance` 资源时，服务目录控制器将连接到相应的服务代理并指示它调配服务实例。
@@ -107,11 +108,11 @@ Service Catalog supports these methods of authentication:
* Basic (username/password)
* [OAuth 2.0 Bearer Token](https://tools.ietf.org/html/rfc6750)
-->
-### 认证
+### 认证 {#authentication}
服务目录支持这些认证方法：
-* 基础认证（用户名/密码）
+* 基本认证（用户名/密码）
* [OAuth 2.0 不记名令牌](https://tools.ietf.org/html/rfc6750)
## 使用方式
-集群运维人员可以使用服务目录 API 资源来提供托管服务并使其在 Kubernetes 集群内可用。涉及的步骤有：
+集群运维人员可以使用服务目录 API 资源来供应托管服务并使其在 Kubernetes 集群内可用。涉及的步骤有：
1. 列出服务代理提供的托管服务和服务计划。
2. 配置托管服务的新实例。
@@ -153,7 +154,28 @@ spec:
# with the service broker, such as bearer token info or a caBundle for TLS.
#####
```
+-->
+### 列出托管服务和服务计划
+首先，集群运维人员在 `servicecatalog.k8s.io` 组内创建一个 `ClusterServiceBroker` 资源。此资源包含访问服务代理终结点所需的 URL 和连接详细信息。
+
+这是一个 `ClusterServiceBroker` 资源的例子：
+
+```yaml
+apiVersion: servicecatalog.k8s.io/v1beta1
+kind: ClusterServiceBroker
+metadata:
+ name: cloud-broker
+spec:
+ # 指向服务代理的末端。(这里的 URL 是无法使用的)
+ url: https://servicebroker.somecloudprovider.com/v1alpha1/projects/service-catalog/brokers/default
+ #####
+ # 这里可以添加额外的用来与服务代理通信的属性值,
+ # 例如持有者令牌信息或者 TLS 的 CA 包
+ #####
+```
+
+
+下面的时序图展示了从服务代理列出可用托管服务和计划所涉及的各个步骤：
+
+
+1. 一旦 `ClusterServiceBroker` 资源被添加到了服务目录之后，将会触发一个到外部服务代理的
+ 调用，以列举所有可用服务；
+1. 服务代理返回可用的托管服务和服务计划列表，这些列表将本地缓存在 `ClusterServiceClass`
+ 和 `ClusterServicePlan` 资源中。
+1. 集群运维人员接下来可以使用以下命令获取可用托管服务的列表：
+
+
-### 列出托管服务和服务计划
-首先，集群运维人员在 `servicecatalog.k8s.io` 组内创建一个 `ClusterServiceBroker` 资源。此资源包含访问服务代理终结点所需的 URL 和连接详细信息。
+ ```shell
+ kubectl get clusterserviceclasses \
+ -o=custom-columns=SERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
+ ```
-这是一个 `ClusterServiceBroker` 资源的例子：
+ 它应该输出一个和以下格式类似的服务名称列表：
-```yaml
-apiVersion: servicecatalog.k8s.io/v1beta1
-kind: ClusterServiceBroker
-metadata:
- name: cloud-broker
-spec:
- # Points to the endpoint of a service broker. (This example is not a working URL.)
- url: https://servicebroker.somecloudprovider.com/v1alpha1/projects/service-catalog/brokers/default
- #####
- # Additional values can be added here, which may be used to communicate
- # with the service broker, such as bearer token info or a caBundle for TLS.
- #####
-```
+ ```
+ SERVICE NAME EXTERNAL NAME
+ 4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468 cloud-provider-service
+ ... ...
+ ```
-下面的顺序图展示了从一个服务代理列出可用托管服务和计划所有涉及的步骤：
+ 他们还可以使用以下命令查看可用的服务计划：
-
-
-1. 一旦 `ClusterServiceBroker` 资源被添加到了服务目录之后，将会触发一个到外部服务代理的 List Services 调用。
-1. 服务代理返回可用的托管服务和服务计划列表，这些列表将本地缓存在 `ClusterServiceClass` 和 `ClusterServicePlan` 资源中。
-1. 然后集群运维人员可以使用以下命令获取可用托管服务的列表：
-
- kubectl get clusterserviceclasses -o=custom-columns=SERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
-
- 它应该输出一个和以下格式类似的服务名称列表：
-
- SERVICE NAME EXTERNAL NAME
- 4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468 cloud-provider-service
- ... ...
-
- 他们还可以使用以下命令查看可用的服务计划：
-
- kubectl get clusterserviceplans -o=custom-columns=PLAN\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
+ ```shell
+ kubectl get clusterserviceplans \
+ -o=custom-columns=PLAN\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
+ ```
它应该输出一个和以下格式类似的服务计划列表：
- PLAN NAME EXTERNAL NAME
- 86064792-7ea2-467b-af93-ac9694d96d52 service-plan-name
- ... ...
+ ```
+ PLAN NAME EXTERNAL NAME
+ 86064792-7ea2-467b-af93-ac9694d96d52 service-plan-name
+ ... ...
+ ```
-### 配置一个新实例
+### 供应一个新实例
集群运维人员 可以通过创建一个 `ServiceInstance` 资源来启动一个新实例的配置。
-这是一个 `ServiceInstance` 资源的例子：
+下面是一个 `ServiceInstance` 资源的例子：
```yaml
apiVersion: servicecatalog.k8s.io/v1beta1
@@ -270,22 +278,31 @@ metadata:
name: cloud-queue-instance
namespace: cloud-apps
spec:
- # References one of the previously returned services
+ # 引用之前返回的服务之一
clusterServiceClassExternalName: cloud-provider-service
clusterServicePlanExternalName: service-plan-name
#####
- # Additional parameters can be added here,
- # which may be used by the service broker.
+ # 这里可添加额外的参数，供服务代理使用
#####
```
-以下顺序图展示了配置托管服务新实例所涉及的步骤：
+
+以下时序图展示了配置托管服务新实例所涉及的步骤：
+
+
+
+1. 创建 `ServiceInstance` 资源时，服务目录将启动一个到外部服务代理的调用，
+ 请求供应一个实例。
1. 服务代理创建一个托管服务的新实例并返回 HTTP 响应。
-1. 然后集群运维人员可以检查实例的状态是否就绪。
+1. 接下来，集群运维人员可以检查实例的状态是否就绪。
### 绑定到托管服务
@@ -333,15 +342,23 @@ spec:
instanceRef:
name: cloud-queue-instance
#####
- # Additional information can be added here, such as a secretName or
- # service account parameters, which may be used by the service broker.
+ # 这里可以添加供服务代理使用的额外信息，例如 Secret 名称或者服务账号参数，
#####
```
-以下顺序图展示了绑定到托管服务实例的步骤：
+
+以下顺序图展示了绑定到托管服务实例的步骤：
+
+
+
1. 在创建 `ServiceBinding` 之后，服务目录调用外部服务代理，请求绑定服务实例所需的信息。
1. 服务代理为相应服务账户启用应用权限/角色。
1. 服务代理返回连接和访问托管服务示例所需的信息。这是由提供商和服务特定的，故返回的信息可能因服务提供商和其托管服务而有所不同。
@@ -362,7 +379,7 @@ These pieces of information are stored in secrets that the application in the cl
-
+
#### Pod 配置文件
执行此映射的一种方法是使用声明式 Pod 配置。
-以下示例描述了如何将服务账户凭据映射到应用程序中。名为 `sa-key` 的密钥保存在一个名为 `provider-cloud-key` 的卷中，应用程序会将该卷挂载在 `/var/secrets/provider/key.json` 路径下。环境变量 `PROVIDER_APPLICATION_CREDENTIALS` 将映射为挂载文件的路径。
+以下示例描述了如何将服务账户凭据映射到应用程序中。名为 `sa-key` 的密钥保存在一个名为
+`provider-cloud-key` 的卷中，应用程序会将该卷挂载在 `/var/secrets/provider/key.json`
+路径下。环境变量 `PROVIDER_APPLICATION_CREDENTIALS` 将映射为挂载文件的路径。
```yaml
...
@@ -424,8 +413,12 @@ The following example describes how to map secret values into application enviro
value: "/var/secrets/provider/key.json"
```
-以下示例描述了如何将 secret 值映射为应用程序的环境变量。在这个示例中，消息队列的主题名从 secret `provider-queue-credentials` 中名为 `topic` 的 key 项映射到环境变量 `TOPIC` 中。
-
+
+以下示例描述了如何将 Secret 值映射为应用程序的环境变量。
+在这个示例中，消息队列的主题名从 Secret `provider-queue-credentials` 中名为
+`topic` 的主键映射到环境变量 `TOPIC` 中。
```yaml
...
@@ -437,9 +430,6 @@ The following example describes how to map secret values into application enviro
key: topic
```
-
-
-
## {{% heading "whatsnext" %}}
-* 如果您熟悉{{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}，您可以[使用 Helm 将服务目录](/docs/tasks/service-catalog/install-service-catalog-using-helm/)安装到 Kubernetes 集群中。或者，您可以[使用 SC 工具安装服务目录](/docs/tasks/service-catalog/install-service-catalog-using-sc/)。
-* 查看[服务代理示例](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers)。
-* 浏览 [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 项目。
-* 查看 [svc-cat.io](https://svc-cat.io/docs/)。
-
-
+* 如果你熟悉 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}，
+ 可以[使用 Helm 安装服务目录](/zh/docs/tasks/service-catalog/install-service-catalog-using-helm/)
+ 到 Kubernetes 集群中。或者，你可以
+ [使用 SC 工具安装服务目录](/zh/docs/tasks/service-catalog/install-service-catalog-using-sc/)。
+* 查看[服务代理示例](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers)
+* 浏览 [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 项目
+* 查看 [svc-cat.io](https://svc-cat.io/docs/)