[zh]Resync Extend Kubernetes files

content/zh/docs/tasks/extend-kubectl/kubectl-plugins.md

@@ -16,7 +16,7 @@ content_type: task
 <!-- overview -->
 <!--
 This guide demonstrates how to install and write extensions for [kubectl](/docs/reference/kubectl/kubectl/). By thinking of core `kubectl` commands as essential building blocks for interacting with a Kubernetes cluster, a cluster administrator can think
-  of plugins as a means of utilizing these building blocks to create more complex behavior. Plugins extend `kubectl` with new sub-commands, allowing for new and custom features not included in the main distribution of `kubectl`.
+of plugins as a means of utilizing these building blocks to create more complex behavior. Plugins extend `kubectl` with new sub-commands, allowing for new and custom features not included in the main distribution of `kubectl`.
 -->
 本指南演示了如何为 [kubectl](/zh/docs/reference/kubectl/kubectl/) 安装和编写扩展。
 通过将核心 `kubectl` 命令看作与 Kubernetes 集群交互的基本构建块，
@@ -35,12 +35,12 @@ You need to have a working `kubectl` binary installed.
 <!--
 ## Installing kubectl plugins
 
-A plugin is nothing more than a standalone executable file, whose name begins with `kubectl-`. To install a plugin, simply move this executable file to anywhere on your PATH.
+A plugin is a standalone executable file, whose name begins with `kubectl-`. To install a plugin, move its executable file to anywhere on your `PATH`.
 -->
 ## 安装 kubectl 插件
 
-插件只不过是一个独立的可执行文件，名称以 `kubectl-` 开头。
-要安装插件，只需将此可执行文件移动到 PATH 中的任何位置。
+插件是一个独立的可执行文件，名称以 `kubectl-` 开头。
+要安装插件，将其可执行文件移动到 `PATH` 中的任何位置。
 
 <!--
 You can also discover and install kubectl plugins available in the open source
@@ -112,14 +112,14 @@ You can write a plugin in any programming language or script that allows you to
 <!--
 There is no plugin installation or pre-loading required. Plugin executables receive
 the inherited environment from the `kubectl` binary.
-A plugin determines which command path it wishes to implement based on its name. For
-example, a plugin wanting to provide a new command `kubectl foo`, would simply be named
-`kubectl-foo`, and live somewhere in the user's PATH.
+A plugin determines which command path it wishes to implement based on its name.
+For example, a plugin named `kubectl-foo` provides a command `kubectl foo`. You must
+install the plugin executable somewhere in your `PATH`.
 -->
 不需要安装插件或预加载，插件可执行程序从 `kubectl` 二进制文件接收继承的环境，
 插件根据其名称确定它希望实现的命令路径。
-例如，一个插件想要提供一个新的命令 `kubectl foo`，它将被简单地命名为 `kubectl-foo`，
-并且位于用户 PATH 的某个位置。
+例如，名为 `kubectl-foo` 的插件提供了命令 `kubectl foo`。
+必须将插件的可执行文件安装在 `PATH` 中的某个位置。
 
 <!--
 ### Example plugin
@@ -152,11 +152,11 @@ echo "I am a plugin named kubectl-foo"
 ### 使用插件
 
 <!--
-To use the above plugin, simply make it executable:
+To use a plugin, make the plugin executable:
 -->
-要使用上面的插件，只需使其可执行：
+要使用某插件，先要使其可执行：
 
-```
+```shell
 sudo chmod +x ./kubectl-foo
 ```
 
@@ -165,7 +165,7 @@ and place it anywhere in your PATH:
 -->
 并将它放在你的 PATH 中的任何地方：
 
-```
+```shell
 sudo mv ./kubectl-foo /usr/local/bin
 ```
 
@@ -174,9 +174,10 @@ You may now invoke your plugin as a `kubectl` command:
 -->
 你现在可以调用你的插件作为 `kubectl` 命令：
 
-```
+```shell
 kubectl foo
 ```
+
 ```
 I am a plugin named kubectl-foo
 ```
@@ -186,9 +187,10 @@ All args and flags are passed as-is to the executable:
 -->
 所有参数和标记按原样传递给可执行文件：
 
-```
+```shell
 kubectl foo version
 ```
+
 ```
 1.0.0
 ```
@@ -202,6 +204,7 @@ All environment variables are also passed as-is to the executable:
 export KUBECONFIG=~/.kube/config
 kubectl foo config
 ```
+
 ```
 /home/<user>/.kube/config
 ```
@@ -209,6 +212,7 @@ kubectl foo config
 ```shell
 KUBECONFIG=/etc/kube/config kubectl foo config
 ```
+
 ```
 /etc/kube/config
 ```
@@ -584,7 +588,6 @@ installs easier.
 * In case of any questions, feel free to reach out to the [CLI SIG team](https://github.com/kubernetes/community/tree/master/sig-cli).
 * Read about [Krew](https://krew.dev/), a package manager for kubectl plugins.
 -->
-
 * 查看 CLI 插件库示例，查看用 Go 编写的插件的[详细示例](https://github.com/kubernetes/sample-cli-plugin)
 * 如有任何问题，请随时联系 [SIG CLI ](https://github.com/kubernetes/community/tree/master/sig-cli)
 * 了解 [Krew](https://krew.dev/)，一个 kubectl 插件管理器。

content/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md

@@ -15,26 +15,25 @@ weight: 20
 <!-- overview -->
 
 <!--
-Kubernetes ships with a default scheduler that is described [here](/docs/admin/kube-scheduler/).
+Kubernetes ships with a default scheduler that is described
+[here](/docs/reference/command-line-tools-reference/kube-scheduler/).
 If the default scheduler does not suit your needs you can implement your own scheduler.
-Not just that, you can even run multiple schedulers simultaneously alongside
-the default scheduler and instruct Kubernetes what scheduler to use for each
-of your pods. Let's learn how to run multiple schedulers in Kubernetes with an
-example.
+Moreover, you can even run multiple schedulers simultaneously alongside the default
+scheduler and instruct Kubernetes what scheduler to use for each of your pods. Let's
+learn how to run multiple schedulers in Kubernetes with an example.
 -->
 Kubernetes 自带了一个默认调度器，其详细描述请查阅
 [这里](/zh/docs/reference/command-line-tools-reference/kube-scheduler/)。
 如果默认调度器不适合你的需求，你可以实现自己的调度器。
-不仅如此，你甚至可以和默认调度器一起同时运行多个调度器，并告诉 Kubernetes 为每个
+而且，你甚至可以和默认调度器一起同时运行多个调度器，并告诉 Kubernetes 为每个
 Pod 使用哪个调度器。
 让我们通过一个例子讲述如何在 Kubernetes 中运行多个调度器。
 
 <!--
-A detailed description of how to implement a scheduler is outside the scope of
-this document. Please refer to the kube-scheduler implementation
-in[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param
-"githubbranch" >}}/pkg/scheduler)in the Kubernetes source directory for a
-canonical example.
+A detailed description of how to implement a scheduler is outside the scope of this
+document. Please refer to the kube-scheduler implementation in
+[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/pkg/scheduler)
+in the Kubernetes source directory for a canonical example.
 -->
 关于实现调度器的具体细节描述超出了本文范围。
 请参考 kube-scheduler 的实现，规范示例代码位于
@@ -50,15 +49,15 @@ canonical example.
 ## Package the scheduler
 
 Package your scheduler binary into a container image. For the purposes of this example,
-let's just use the default scheduler (kube-scheduler) as our second scheduler as well.
-Clone the [Kubernetes source code from Github](https://github.com/kubernetes/kubernetes)
+you can use the default scheduler (kube-scheduler) as your second scheduler.
+Clone the [Kubernetes source code from GitHub](https://github.com/kubernetes/kubernetes)
 and build the source.
 -->
 ## 打包调度器
 
-将调度器可执行文件打包到容器镜像中。出于示例目的，我们就使用默认调度器
-（kube-scheduler）作为我们的第二个调度器。
-克隆 [Github 上 Kubernetes 源代码](https://github.com/kubernetes/kubernetes)，
+将调度器可执行文件打包到容器镜像中。出于示例目的，可以使用默认调度器
+（kube-scheduler）作为第二个调度器。
+克隆 [GitHub 上 Kubernetes 源代码](https://github.com/kubernetes/kubernetes)，
 并编译构建源代码。
 
 ```shell
@@ -68,13 +67,14 @@ make
 ```
 
 <!--
-Create a container image containing the kube-scheduler binary. Here is the `Dockerfile`to build the image:
+Create a container image containing the kube-scheduler binary. Here is the `Dockerfile`
+to build the image:
 -->
 创建一个包含 kube-scheduler 二进制文件的容器镜像。用于构建镜像的 `Dockerfile` 内容如下：
 
 ```docker
 FROM busybox
-ADD ./_output/dockerized/bin/linux/amd64/kube-scheduler /usr/local/bin/kube-scheduler
+ADD ./_output/local/bin/linux/amd64/kube-scheduler /usr/local/bin/kube-scheduler
 ```
 
 <!--
@@ -96,9 +96,9 @@ gcloud docker -- push gcr.io/my-gcp-project/my-kube-scheduler:1.0
 <!--
 ## Define a Kubernetes Deployment for the scheduler
 
-Now that we have our scheduler in a container image, we can just create a pod
-config for it and run it in our Kubernetes cluster. But instead of creating a pod
-directly in the cluster, let's use a [Deployment](/docs/concepts/workloads/controllers/deployment/)
+Now that you have your scheduler in a container image, create a pod
+configuration for it and run it in your Kubernetes cluster. But instead of creating a pod
+directly in the cluster, you can use a [Deployment](/docs/concepts/workloads/controllers/deployment/)
 for this example. A [Deployment](/docs/concepts/workloads/controllers/deployment/) manages a
 [Replica Set](/docs/concepts/workloads/controllers/replicaset/) which in turn manages the pods,
 thereby making the scheduler resilient to failures. Here is the deployment
@@ -106,7 +106,7 @@ config. Save it as `my-scheduler.yaml`:
 -->
 ## 为调度器定义 Kubernetes Deployment
 
-现在我们将调度器放在容器镜像中，我们可以为它创建一个 Pod 配置，并在我们的 Kubernetes 集群中
+现在将调度器放在容器镜像中，为它创建一个 Pod 配置，并在 Kubernetes 集群中
 运行它。但是与其在集群中直接创建一个 Pod，不如使用
 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/)。
 Deployment 管理一个 [ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/)，
@@ -134,18 +134,22 @@ Note also that we created a dedicated service account `my-scheduler` and bind th
 绑定到它，以便它可以获得与 `kube-scheduler` 相同的权限。
 
 <!--
-Please see the[kube-scheduler documentation](/docs/admin/kube-scheduler/) for detailed description of other command line arguments.
+Please see the
+[kube-scheduler documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for
+detailed description of other command line arguments.
 -->
-请参阅 [kube-scheduler 文档](/docs/reference/command-line-tools-reference/kube-scheduler/)以获取其他命令行参数的详细说明。
+请参阅 [kube-scheduler 文档](/docs/reference/command-line-tools-reference/kube-scheduler/)
+以获取其他命令行参数的详细说明。
 
 <!--
 ## Run the second scheduler in the cluster
 
-In order to run your scheduler in a Kubernetes cluster, just create the deployment specified in the config above in a Kubernetes cluster:
+In order to run your scheduler in a Kubernetes cluster, create the deployment
+specified in the config above in a Kubernetes cluster:
 -->
 ## 在集群中运行第二个调度器
 
-为了在 Kubernetes 集群中运行我们的第二个调度器，只需在 Kubernetes 集群中创建上面配置中指定的 Deployment：
+为了在 Kubernetes 集群中运行我们的第二个调度器，在 Kubernetes 集群中创建上面配置中指定的 Deployment：
 
 ```shell
 kubectl create -f my-scheduler.yaml
@@ -170,7 +174,8 @@ my-scheduler-lnf4s-4744f                       1/1       Running   0          2m
 ```
 
 <!--
-You should see a "Running" my-scheduler pod, in addition to the default kube-scheduler pod in this list.
+You should see a "Running" my-scheduler pod, in addition to the default kube-scheduler
+pod in this list.
 -->
 此列表中，除了默认的 `kube-scheduler` Pod 之外，你应该还能看到处于 “Running” 状态的
 `my-scheduler` Pod。
@@ -190,14 +195,24 @@ First, update the following fields in your YAML file:
 首先，更新上述 Deployment YAML（my-scheduler.yaml）文件中的以下字段：
 
 * `--leader-elect=true`
-* `--lock-object-namespace=lock-object-namespace`
-* `--lock-object-name=lock-object-name`
+* `--lock-object-namespace=<lock-object-namespace>`
+* `--lock-object-name=<lock-object-name>`
+
+{{< note >}}
+<!--
+The control plane creates the lock objects for you, but the namespace must already exist.
+You can use the `kube-system` namespace.
+-->
+控制平面会为你创建锁对象，但是命名空间必须已经存在。
+你可以使用 `kube-system` 命名空间。
+{{< /note >}}
 
 <!--
-If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role. Add you scheduler name to the resourceNames of the rule applied for endpoints resources, as in the following example:
+If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role.
+Add your scheduler name to the resourceNames of the rule applied for `endpoints` and `leases` resources, as in the following example:
 -->
 如果在集群上启用了 RBAC，则必须更新 `system：kube-scheduler` 集群角色。
-将调度器名称添加到应用于端点资源的规则的 resourceNames，如以下示例所示：
+将调度器名称添加到应用了 `endpoints` 和 `leases` 资源的规则的 resourceNames 中，如以下示例所示：
 
 ```shell
 kubectl edit clusterrole system:kube-scheduler
@@ -211,11 +226,13 @@ kubectl edit clusterrole system:kube-scheduler
 ## 为 Pod 指定调度器
 
 <!--
-Now that our second scheduler is running, let's create some pods, and direct them to be scheduled by either the default scheduler or the one we just deployed. In order to schedule a given pod using a specific scheduler, we specify the name of the scheduler in that pod spec. Let's look at three examples.
+Now that your second scheduler is running, create some pods, and direct them
+to be scheduled by either the default scheduler or the one you deployed.
+In order to schedule a given pod using a specific scheduler, specify the name of the
+scheduler in that pod spec. Let's look at three examples.
 -->
-现在我们的第二个调度器正在运行，让我们创建一些 Pod，并指定它们由默认调度器或我们刚部署的
-调度器进行调度。
-为了使用特定的调度器调度给定的 Pod，我们在那个 Pod 的规约中指定调度器的名称。让我们看看三个例子。
+现在第二个调度器正在运行，创建一些 Pod，并指定它们由默认调度器或部署的调度器进行调度。
+为了使用特定的调度器调度给定的 Pod，在那个 Pod 的 spec 中指定调度器的名称。让我们看看三个例子。
 
 <!--
 - Pod spec without any scheduler name
@@ -225,7 +242,8 @@ Now that our second scheduler is running, let's create some pods, and direct the
   {{< codenew file="admin/sched/pod1.yaml" >}}
 
   <!--
-  When no scheduler name is supplied, the pod is automatically scheduled using the  default-scheduler.
+  When no scheduler name is supplied, the pod is automatically scheduled using the
+  default-scheduler.
   -->
   如果未提供调度器名称，则会使用 default-scheduler 自动调度 pod。
 
@@ -246,7 +264,8 @@ Now that our second scheduler is running, let's create some pods, and direct the
   {{< codenew file="admin/sched/pod2.yaml" >}}
 
   <!--
-  A scheduler is specified by supplying the scheduler name as a value to `spec.schedulerName`. In this case, we supply the name of the  default scheduler which is `default-scheduler`.
+  A scheduler is specified by supplying the scheduler name as a value to `spec.schedulerName`. In this case, we supply the name of the
+  default scheduler which is `default-scheduler`.
   -->
   通过将调度器名称作为 `spec.schedulerName` 参数的值来指定调度器。
   在这种情况下，我们提供默认调度器的名称，即 `default-scheduler`。
@@ -268,10 +287,9 @@ Now that our second scheduler is running, let's create some pods, and direct the
   {{< codenew file="admin/sched/pod3.yaml" >}}
 
   <!--
-  In this case, we specify that this pod should be scheduled using the
-  scheduler that we  deployed - `my-scheduler`. Note that the value of
-  `spec.schedulerName` should match the name supplied to the scheduler  command
-  as an argument in the deployment config for the scheduler.
+  In this case, we specify that this pod should be scheduled using the scheduler that we
+  deployed - `my-scheduler`. Note that the value of `spec.schedulerName` should match the name supplied to the scheduler
+  command as an argument in the deployment config for the scheduler.
   -->
   在这种情况下，我们指定此 pod 使用我们部署的 `my-scheduler` 来调度。
   请注意，`spec.schedulerName` 参数的值应该与 Deployment 中配置的提供给
@@ -287,13 +305,13 @@ Now that our second scheduler is running, let's create some pods, and direct the
   ```
 
 <!--
-Verify that all three pods are running.
+  Verify that all three pods are running.
 -->
-确认所有三个 pod 都在运行。
+  确认所有三个 pod 都在运行。
 
-```shell
-kubectl get pods
-```
+  ```shell
+  kubectl get pods
+  ```
 
 <!-- discussion -->
 
@@ -303,7 +321,14 @@ kubectl get pods
 ### 验证是否使用所需的调度器调度了 pod
 
 <!--
-In order to make it easier to work through these examples, we did not verify that the pods were actually scheduled using the desired schedulers. We can verify that by changing the order of pod and deployment config submissions above. If we submit all the pod configs to a Kubernetes cluster before submitting the scheduler deployment config,we see that the pod `annotation-second-scheduler` remains in "Pending" state forever while the other two pods get scheduled. Once we submit the scheduler deployment config and our new scheduler starts running, the `annotation-second-scheduler` pod gets scheduled as well.
+In order to make it easier to work through these examples, we did not verify that the
+pods were actually scheduled using the desired schedulers. We can verify that by
+changing the order of pod and deployment config submissions above. If we submit all the
+pod configs to a Kubernetes cluster before submitting the scheduler deployment config,
+we see that the pod `annotation-second-scheduler` remains in "Pending" state forever
+while the other two pods get scheduled. Once we submit the scheduler deployment config
+and our new scheduler starts running, the `annotation-second-scheduler` pod gets
+scheduled as well.
 -->
 为了更容易地完成这些示例，我们没有验证 Pod 实际上是使用所需的调度程序调度的。
 我们可以通过更改 Pod 的顺序和上面的部署配置提交来验证这一点。
@@ -313,7 +338,8 @@ In order to make it easier to work through these examples, we did not verify tha
 一旦我们提交调度器部署配置并且我们的新调度器开始运行，注解了
 `annotation-second-scheduler` 的 pod 就能被调度。
 <!--
-Alternatively, one could just look at the "Scheduled" entries in the event logs to verify that the pods were scheduled by the desired schedulers.
+Alternatively, you can look at the "Scheduled" entries in the event logs to
+verify that the pods were scheduled by the desired schedulers.
 -->
 或者，可以查看事件日志中的 “Scheduled” 条目，以验证是否由所需的调度器调度了 Pod。
 
@@ -321,3 +347,11 @@ Alternatively, one could just look at the "Scheduled" entries in the event logs
 kubectl get events
 ```
 
+<!--
+You can also use a [custom scheduler configuration](/docs/reference/scheduling/config/#multiple-profiles)
+or a custom container image for the cluster's main scheduler by modifying its static pod manifest
+on the relevant control plane nodes.
+-->
+你也可以使用[自定义调度器配置](/zh/docs/reference/scheduling/config/#multiple-profiles)
+或自定义容器镜像，用于集群的主调度器，方法是在相关控制平面节点上修改其静态 pod 清单。
+

content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md

@@ -131,7 +131,7 @@ after upgrading the objects to a new stored version.
 Removing an old version:
 
 1. Ensure all clients are fully migrated to the new version. The kube-apiserver
-   logs can reviewed to help identify any clients that are still accessing via
+   logs can be reviewed to help identify any clients that are still accessing via
    the old version.
 1. Set `served` to `false` for the old version in the `spec.versions` list. If
    any clients are still unexpectedly using the old version they may begin reporting
@@ -608,14 +608,14 @@ how to [authenticate API servers](/docs/reference/access-authn-authz/extensible-
 A conversion webhook must not mutate anything inside of `metadata` of the converted object
 other than `labels` and `annotations`.
 Attempted changes to `name`, `UID` and `namespace` are rejected and fail the request
-which caused the conversion. All other changes are just ignored.  
+which caused the conversion. All other changes are ignored. 
 -->
 #### 被允许的变更
 
 转换 Webhook 不可以更改被转换对象的 `metadata` 中除 `labels` 和 `annotations`
 之外的任何属性。
 尝试更改 `name`、`UID` 和 `namespace` 时都会导致引起转换的请求失败。
-所有其他变更只是被忽略而已。
+所有其他变更都被忽略。
 
 <!--
 ### Deploy the conversion webhook service
@@ -833,14 +833,13 @@ API 服务器一旦确定请求应发送到转换 Webhook，它需要知道如
 The `host` should not refer to a service running in the cluster; use
 a service reference by specifying the `service` field instead.
 The host might be resolved via external DNS in some apiservers
-(i.e., `kube-apiserver` cannot resolve in-cluster DNS as that would 
+(i.e., `kube-apiserver` cannot resolve in-cluster DNS as that would
 be a layering violation). `host` may also be an IP address.
 
 Please note that using `localhost` or `127.0.0.1` as a `host` is
 risky unless you take great care to run this webhook on all hosts
 which run an apiserver which might need to make calls to this
-webhook. Such installs are likely to be non-portable, i.e., not easy
-to turn up in a new cluster.
+webhook. Such installations are likely to be non-portable or not readily run in a new cluster.
 -->
 url 以标准 URL 形式给出 Webhook 的位置（`scheme://host:port/path`）。
 `host` 不应引用集群中运行的服务，而应通过指定 `service` 字段来提供
@@ -851,8 +850,7 @@ url 以标准 URL 形式给出 Webhook 的位置（`scheme://host:port/path`）
 
 请注意，除非你非常小心地在所有运行着可能调用 Webhook 的 API 服务器的
 主机上运行此 Webhook，否则将 `localhost` 或 `127.0.0.1` 用作 `host`
-是风险很大的。这样的安装很可能是不可移植的，即很难在新集群中启用。
-
+是风险很大的。这样的安装可能是不可移植的，或者不容易在一个新的集群中运行。
 <!--
 The scheme must be "https"; the URL must begin with "https://".
 

content/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md

@@ -842,12 +842,12 @@ CustomResourceDefinition and migrating your objects from one version to another.
 
 <!--
 *Finalizers* allow controllers to implement asynchronous pre-delete hooks.
-Custom objects support finalizers just like built-in objects.
+Custom objects support finalizers similar to built-in objects.
 
 You can add a finalizer to a custom object like this:
 -->
 *Finalizer* 能够让控制器实现异步的删除前（Pre-delete）回调。
-定制对象和内置对象一样支持 Finalizer。
+与内置对象类似，定制对象也支持 Finalizer。
 
 你可以像下面一样为定制对象添加 Finalizer：
 

content/zh/docs/tasks/extend-kubernetes/setup-extension-api-server.md

@@ -77,14 +77,14 @@ Alternatively, you can use an existing 3rd party solution, such as [apiserver-bu
 1. Make sure that your extension-apiserver loads those certs from that volume and that they are used in the HTTPS handshake.
 1. Create a Kubernetes service account in your namespace.
 1. Create a Kubernetes cluster role for the operations you want to allow on your resources.
-1. Create a Kubernetes cluster role binding from the service account in your namespace to the cluster role you just created.
+1. Create a Kubernetes cluster role binding from the service account in your namespace to the cluster role you created.
 1. Create a Kubernetes cluster role binding from the service account in your namespace to the `system:auth-delegator` cluster role to delegate auth decisions to the Kubernetes core API server.
 1. Create a Kubernetes role binding from the service account in your namespace to the `extension-apiserver-authentication-reader` role. This allows your extension api-server to access the `extension-apiserver-authentication` configmap.
 -->
 8.  确保你的扩展 apiserver 从该卷中加载了那些证书，并在 HTTPS 握手过程中使用它们。
 9.  在你的命令空间中创建一个 Kubernetes 服务账号。
 10. 为资源允许的操作创建 Kubernetes 集群角色。
-11. 用你命令空间中的服务账号创建一个 Kubernetes 集群角色绑定，绑定到你刚创建的角色上。
+11. 用你命令空间中的服务账号创建一个 Kubernetes 集群角色绑定，绑定到你创建的角色上。
 12. 用你命令空间中的服务账号创建一个 Kubernetes 集群角色绑定，绑定到 `system:auth-delegator`
     集群角色，以将 auth 决策委派给 Kubernetes 核心 API 服务器。
 13. 以你命令空间中的服务账号创建一个 Kubernetes 集群角色绑定，绑定到