whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #22952 from tengqm/zh-resync-service-catalog

Browse Source 
[zh] Tweak localization for service calalog
This commit is contained in:
Kubernetes Prow Robot
2020-08-09 06:30:19 -07:00
committed by GitHub
parent 77d5c7b8e0 42a9bbf324
commit 6c84eda356
1 changed files with 125 additions and 134 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/concepts/extend-kubernetes/service-catalog.md
+125 -134
View File
@@ -1,22 +1,18 @@
---
title: 服务目录
reviewers:
- chenopis
content_type: concept
weight: 40
---
<!--
---
title: Service Catalog
reviewers:
- chenopis
content_type: concept
weight: 40
---
-->
<!-- overview -->
{{< glossary_definition term_id="service-catalog" length="all" prepend="" >}}
{{< glossary_definition term_id="service-catalog" length="all" prepend="服务目录（Service Catalog）是" >}}
<!--
A service broker, as defined by the [Open service broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md), is an endpoint for a set of managed services offered and maintained by a third-party, which could be a cloud provider such as AWS, GCP, or Azure.
@@ -24,13 +20,12 @@ Some examples of managed services are Microsoft Azure Cloud Queue, Amazon Simple
Using Service Catalog, a {{< glossary_tooltip text="cluster operator" term_id="cluster-operator" >}} can browse the list of managed services offered by a service broker, provision an instance of a managed service, and bind with it to make it available to an application in the Kubernetes cluster.
-->
服务代理是由[开放服务代理 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 集群中的应用程序使用。
<!-- body -->
<!--
@@ -46,11 +41,15 @@ The application can simply use it as a service.
-->
## 示例用例
应用开发者希望使用消息队列作为其在 Kubernetes 集群中运行的应用程序的一部分。
但是，它们不想承受建立这种服务的开销，也不想自行管理。幸运的是，有一家云服务提供商通过它们的服务代理将消息队列作为托管服务提供。
{{< glossary_tooltip text="应用开发人员" term_id="application-developer" >}}，
希望使用消息队列，作为其在 Kubernetes 集群中运行的应用程序的一部分。
但是，他们不想承受构造这种服务的开销，也不想自行管理。
幸运的是，有一家云服务提供商通过其服务代理以托管服务的形式提供消息队列服务。
集群运维人员可以设置服务目录并使用它与云服务提供商的服务代理 通信，以此提供消息队列服务的实例并使其对 Kubernetes 中的应用程序可用。
因此，应用开发者可以不用关心消息队列的实现细节，也不用对其进行管理。它们的应用程序可以简单的将其作为服务使用。
集群操作员可以设置服务目录并使用它与云服务提供商的服务代理通信，进而部署消息队列服务的实例
并使其对 Kubernetes 中的应用程序可用。
应用开发者于是可以不关心消息队列的实现细节，也不用对其进行管理。
他们的应用程序可以简单的将其作为服务使用。
<!--
## Architecture
@@ -59,18 +58,20 @@ Service Catalog uses the [Open service broker API](https://github.com/openservic
It is implemented as an extension API server and a controller, using etcd for storage. It also uses the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) available in Kubernetes 1.7+ to present its API.
<br>
![Service Catalog Architecture](/images/docs/service-catalog-architecture.svg)
-->
## 架构
服务目录使用[开放服务代理 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 服务器的中介，以便协商启动部署和获取
应用程序使用托管服务时必须的凭据。
<br>
服务目录实现为一个扩展 API 服务器和一个控制器，使用 Etcd 提供存储。
它还使用了 Kubernetes 1.7 之后版本中提供的
[聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
来呈现其 API。
![Service Catalog Architecture](/images/docs/service-catalog-architecture.svg)
![服务目录架构](/images/docs/service-catalog-architecture.svg)
<!--
### API Resources
@@ -89,11 +90,11 @@ When a new `ServiceInstance` resource is created, the Service Catalog controller
These are created by cluster operators who want their applications to make use of a `ServiceInstance`.
Upon creation, the Service Catalog controller creates a Kubernetes `Secret` containing connection details and credentials for the Service Instance, which can be mounted into Pods.
-->
## 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)
<!--
@@ -126,7 +127,7 @@ A cluster operator can use Service Catalog API Resources to provision managed se
-->
## 使用方式
集群运维人员可以使用服务目录 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 包
#####
```
<!--
The following is a sequence diagram illustrating the steps involved in listing managed services and Plans available from a service broker:
![List Services](/images/docs/service-catalog-list.svg)
@@ -161,7 +183,18 @@ The following is a sequence diagram illustrating the steps involved in listing m
1. Once the `ClusterServiceBroker` resource is added to Service Catalog, it triggers a call to the external service broker for a list of available services.
1. The service broker returns a list of available managed services and a list of Service Plans, which are cached locally as `ClusterServiceClass` and `ClusterServicePlan` resources respectively.
1. A cluster operator can then get the list of available managed services using the following command:
-->
下面的时序图展示了从服务代理列出可用托管服务和计划所涉及的各个步骤：
![列举服务](/images/docs/service-catalog-list.svg)
1. 一旦 `ClusterServiceBroker` 资源被添加到了服务目录之后，将会触发一个到外部服务代理的
调用，以列举所有可用服务；
1. 服务代理返回可用的托管服务和服务计划列表，这些列表将本地缓存在 `ClusterServiceClass`
和 `ClusterServicePlan` 资源中。
1. 集群运维人员接下来可以使用以下命令获取可用托管服务的列表：
<!--
kubectl get clusterserviceclasses -o=custom-columns=SERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName
It should output a list of service names with a format similar to:
@@ -180,51 +213,34 @@ The following is a sequence diagram illustrating the steps involved in listing m
86064792-7ea2-467b-af93-ac9694d96d52 service-plan-name
... ...
-->
### 列出托管服务和服务计划
首先，集群运维人员在 `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
... ...
```
下面的顺序图展示了从一个服务代理列出可用托管服务和计划所有涉及的步骤：
他们还可以使用以下命令查看可用的服务计划：
![List Services](/images/docs/service-catalog-list.svg)
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
... ...
```
<!--
### Provisioning a new instance
@@ -248,20 +264,12 @@ spec:
# which may be used by the service broker.
#####
```
The following sequence diagram illustrates the steps involved in provisioning a new instance of a managed service:
![Provision a Service](/images/docs/service-catalog-provision.svg)
1. When the `ServiceInstance` resource is created, Service Catalog initiates a call to the external service broker to provision an instance of the service.
1. The service broker creates a new instance of the managed service and returns an HTTP response.
1. A cluster operator can then check the status of the instance to see if it is ready.
-->
### 配置一个新实例
### 供应一个新实例
集群运维人员 可以通过创建一个 `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.
# 这里可添加额外的参数，供服务代理使用
#####
```
以下顺序图展示了配置托管服务新实例所涉及的步骤：
<!--
The following sequence diagram illustrates the steps involved in provisioning a new instance of a managed service:
![Provision a Service](/images/docs/service-catalog-provision.svg)
1. 当创建 `ServiceInstance` 资源时，服务目录将启动一个到外部服务代理的配置实例调用。
1. When the `ServiceInstance` resource is created, Service Catalog initiates a call to the external service broker to provision an instance of the service.
1. The service broker creates a new instance of the managed service and returns an HTTP response.
1. A cluster operator can then check the status of the instance to see if it is ready.
-->
以下时序图展示了配置托管服务新实例所涉及的步骤：
![供应服务](/images/docs/service-catalog-provision.svg)
1. 创建 `ServiceInstance` 资源时，服务目录将启动一个到外部服务代理的调用，
请求供应一个实例。
1. 服务代理创建一个托管服务的新实例并返回 HTTP 响应。
1. 然后集群运维人员可以检查实例的状态是否就绪。
1. 接下来，集群运维人员可以检查实例的状态是否就绪。
<!--
### Binding to a managed service
@@ -308,14 +325,6 @@ spec:
# service account parameters, which may be used by the service broker.
#####
```
The following sequence diagram illustrates the steps involved in binding to a managed service instance:
![Bind to a managed service](/images/docs/service-catalog-bind.svg)
1. After the `ServiceBinding` is created, Service Catalog makes a call to the external service broker requesting the information necessary to bind with the service instance.
1. The service broker enables the application permissions/roles for the appropriate service account.
1. The service broker returns the information necessary to connect and access the managed service instance. This is provider and service-specific so the information returned may differ between Service Providers and their managed services.
-->
### 绑定到托管服务
@@ -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 名称或者服务账号参数，
#####
```
以下顺序图展示了绑定到托管服务实例的步骤：
<!--
The following sequence diagram illustrates the steps involved in binding to a managed service instance:
![Bind to a managed service](/images/docs/service-catalog-bind.svg)
1. After the `ServiceBinding` is created, Service Catalog makes a call to the external service broker requesting the information necessary to bind with the service instance.
1. The service broker enables the application permissions/roles for the appropriate service account.
1. The service broker returns the information necessary to connect and access the managed service instance. This is provider and service-specific so the information returned may differ between Service Providers and their managed services.
-->
以下顺序图展示了绑定到托管服务实例的步骤：
![绑定到托管服务](/images/docs/service-catalog-bind.svg)
1. 在创建 `ServiceBinding` 之后，服务目录调用外部服务代理，请求绑定服务实例所需的信息。
1. 服务代理为相应服务账户启用应用权限/角色。
1. 服务代理返回连接和访问托管服务示例所需的信息。这是由提供商和服务特定的，故返回的信息可能因服务提供商和其托管服务而有所不同。
@@ -362,7 +379,7 @@ These pieces of information are stored in secrets that the application in the cl
<br>
![Map connection credentials](/images/docs/service-catalog-map.svg)
![映射连接凭据](/images/docs/service-catalog-map.svg)
<!--
#### Pod configuration File
@@ -370,42 +387,14 @@ These pieces of information are stored in secrets that the application in the cl
One method to perform this mapping is to use a declarative Pod configuration.
The following example describes how to map service account credentials into the application. A key called `sa-key` is stored in a volume named `provider-cloud-key`, and the application mounts this volume at `/var/secrets/provider/key.json`. The environment variable `PROVIDER_APPLICATION_CREDENTIALS` is mapped from the value of the mounted file.
```yaml
...
spec:
volumes:
- name: provider-cloud-key
secret:
secretName: sa-key
containers:
...
volumeMounts:
- name: provider-cloud-key
mountPath: /var/secrets/provider
env:
- name: PROVIDER_APPLICATION_CREDENTIALS
value: "/var/secrets/provider/key.json"
```
The following example describes how to map secret values into application environment variables. In this example, the messaging queue topic name is mapped from a secret named `provider-queue-credentials` with a key named `topic` to the environment variable `TOPIC`.
```yaml
...
env:
- name: "TOPIC"
valueFrom:
secretKeyRef:
name: provider-queue-credentials
key: topic
```
-->
#### 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` 中。
<!--
The following example describes how to map secret values into application environment variables. In this example, the messaging queue topic name is mapped from a secret named `provider-queue-credentials` with a key named `topic` to the environment variable `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" %}}
<!--
@@ -448,11 +438,12 @@ The following example describes how to map secret values into application enviro
* Explore the [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) project.
* View [svc-cat.io](https://svc-cat.io/docs/).
-->
* 如果您熟悉{{< 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/)