[zh] Resync configure-service-account.md

Author: windsonsea

content/zh-cn/docs/tasks/configure-pod-container/configure-service-account.md

@@ -1,5 +1,5 @@
 ---
-title: 为 Pod 配置服务账户
+title: 为 Pod 配置服务账号
 content_type: task
 weight: 90
 ---
@@ -23,10 +23,10 @@ as recommended by the Kubernetes project. Your cluster administrator may have
 customized the behavior in your cluster, in which case this documentation may
 not apply.
 -->
-服务账户为 Pod 中运行的进程提供了一个标识。
+服务账号为 Pod 中运行的进程提供了一个标识。
 
 {{< note >}}
-本文是服务账户的用户使用介绍，描述服务账户在集群中如何起作用。
+本文是服务账号的用户使用介绍，描述服务账号在集群中如何起作用。
 你的集群管理员可能已经对你的集群做了定制，因此导致本文中所讲述的内容并不适用。
 {{< /note >}}
 
@@ -37,9 +37,9 @@ usually `admin`, unless your cluster administrator has customized your cluster).
 When they do, they are authenticated as a particular Service Account (for example, `default`).
 -->
 当你（自然人）访问集群时（例如，使用 `kubectl`），API 服务器将你的身份验证为
-特定的用户帐户（当前这通常是 `admin`，除非你的集群管理员已经定制了你的集群配置）。
-Pod 内的容器中的进程也可以与 api 服务器接触。
-当它们进行身份验证时，它们被验证为特定的服务帐户（例如，`default`）。
+特定的用户账号（当前这通常是 `admin`，除非你的集群管理员已经定制了你的集群配置）。
+Pod 内的容器中的进程也可以与 API 服务器接触。
+当它们进行身份验证时，它们被验证为特定的服务账号（例如，`default`）。
 
 ## {{% heading "prerequisites" %}}
 
@@ -56,9 +56,9 @@ If you get the raw json or yaml for a pod you have created (for example, `kubect
 you can see the `spec.serviceAccountName` field has been
 [automatically set](/docs/concepts/overview/working-with-objects/object-management/).
 -->
-## 使用默认的服务账户访问 API 服务器
+## 使用默认的服务账号访问 API 服务器
 
-当你创建 Pod 时，如果没有指定服务账户，Pod 会被指定给命名空间中的 `default` 服务账户。
+当你创建 Pod 时，如果没有指定服务账号，Pod 会被指定给命名空间中的 `default` 服务账号。
 如果你查看 Pod 的原始 JSON 或 YAML（例如：`kubectl get pods/<podname> -o yaml`），
 你可以看到 `spec.serviceAccountName` 字段已经被[自动设置](/zh-cn/docs/concepts/overview/working-with-objects/object-management/)了。
 
@@ -70,13 +70,13 @@ The API permissions of the service account depend on the
 
 You can opt out of automounting API credentials on `/var/run/secrets/kubernetes.io/serviceaccount/token` for a service account by setting `automountServiceAccountToken: false` on the ServiceAccount:
 -->
-你可以使用自动挂载给 Pod 的服务账户凭据访问 API，
+你可以使用自动挂载给 Pod 的服务账号凭据访问 API，
 [访问集群](/zh-cn/docs/tasks/access-application-cluster/access-cluster)页面中有相关描述。
-服务账户的 API 许可取决于你所使用的
-[鉴权插件和策略](/zh-cn/docs/reference/access-authn-authz/authorization/#authorization-modules)。
+服务账号的 API
+许可取决于你所使用的[鉴权插件和策略](/zh-cn/docs/reference/access-authn-authz/authorization/#authorization-modules)。
 
 你可以通过在 ServiceAccount 上设置 `automountServiceAccountToken: false`
-来实现不给服务账户自动挂载 API 凭据到 `/var/run/secrets/kubernetes.io/serviceaccount/token`
+来实现不给服务账号自动挂载 API 凭据到 `/var/run/secrets/kubernetes.io/serviceaccount/token`
 的目的：
 
 ```yaml
@@ -107,18 +107,18 @@ spec:
 <!--
 The pod spec takes precedence over the service account if both specify a `automountServiceAccountToken` value.
 -->
-如果 Pod 和服务账户都指定了 `automountServiceAccountToken` 值，则 Pod 的 spec 优先于服务帐户。
+如果 Pod 和服务账号都指定了 `automountServiceAccountToken` 值，则 Pod 的 spec 优先于服务账号。
 
 <!--
 ## Use Multiple Service Accounts
 
 Every namespace has a default service account resource called `default`.
 You can list this and any other serviceAccount resources in the namespace with this command:
 -->
-## 使用多个服务账户   {#use-multiple-service-accounts}
+## 使用多个服务账号   {#use-multiple-service-accounts}
 
-每个命名空间都有一个名为 `default` 的服务账户资源。
-你可以用下面的命令查询这个服务账户以及命名空间中的其他 ServiceAccount 资源：
+每个命名空间都有一个名为 `default` 的服务账号资源。
+你可以用下面的命令查询这个服务账号以及命名空间中的其他 ServiceAccount 资源：
 
 ```shell
 kubectl get serviceaccounts
@@ -158,7 +158,7 @@ ServiceAccount 对象的名字必须是一个有效的
 <!--
 If you get a complete dump of the service account object, like this:
 -->
-如果你查询服务帐户对象的完整信息，如下所示：
+如果你查询服务账号对象的完整信息，如下所示：
 
 ```shell
 kubectl get serviceaccounts/build-robot -o yaml
@@ -178,23 +178,17 @@ metadata:
   namespace: default
   resourceVersion: "272500"
   uid: 721ab723-13bc-11e5-aec2-42010af0021e
-secrets:
-- name: build-robot-token-bvbk5
 ```
 
 <!--
-then you will see that a token has automatically been created and is referenced by the service account.
-
 You may use authorization plugins to [set permissions on service accounts](/docs/reference/access-authn-authz/rbac/#service-account-permissions).
 
 To use a non-default service account, set the `spec.serviceAccountName`
 field of a pod to the name of the service account you wish to use.
 -->
-那么你就能看到系统已经自动创建了一个令牌并且被服务账户所引用。
-
-你可以使用授权插件来[设置服务账户的访问许可](/zh-cn/docs/reference/access-authn-authz/rbac/#service-account-permissions)。
+你可以使用授权插件来[设置服务账号的访问许可](/zh-cn/docs/reference/access-authn-authz/rbac/#service-account-permissions)。
 
-要使用非默认的服务账户，将 Pod 的 `spec.serviceAccountName` 字段设置为你想用的服务账户名称。
+要使用非默认的服务账号，将 Pod 的 `spec.serviceAccountName` 字段设置为你想用的服务账号名称。
 
 <!--
 The service account has to exist at the time the pod is created, or it will be rejected.
@@ -203,11 +197,11 @@ You cannot update the service account of an already created pod.
 
 You can clean up the service account from this example like this:
 -->
-Pod 被创建时服务账户必须存在，否则会被拒绝。
+Pod 被创建时服务账号必须存在，否则会被拒绝。
 
-你不能更新已经创建好的 Pod 的服务账户。
+你不能更新已经创建好的 Pod 的服务账号。
 
-你可以清除服务账户，如下所示：
+你可以清除服务账号，如下所示：
 
 ```shell
 kubectl delete serviceaccount/build-robot
@@ -219,9 +213,9 @@ kubectl delete serviceaccount/build-robot
 Suppose we have an existing service account named "build-robot" as mentioned above, and we create
 a new secret manually.
 -->
-## 手动创建服务账户 API 令牌
+## 手动创建服务账号 API 令牌
 
-假设我们有一个上面提到的名为 "build-robot" 的服务账户，现在我们手动创建一个新的 Secret。
+假设我们有一个上面提到的名为 "build-robot" 的服务账号，现在我们手动创建一个新的 Secret。
 
 ```shell
 kubectl apply -f - <<EOF
@@ -240,8 +234,8 @@ Now you can confirm that the newly built secret is populated with an API token f
 
 Any tokens for non-existent service accounts will be cleaned up by the token controller.
 -->
-现在，你可以确认新构建的 Secret 中填充了 "build-robot" 服务帐户的 API 令牌。
-令牌控制器将清理不存在的服务帐户的所有令牌。
+现在，你可以确认新构建的 Secret 中填充了 "build-robot" 服务账号的 API 令牌。
+令牌控制器将清理不存在的服务账号的所有令牌。
 
 ```shell
 kubectl describe secrets/build-robot-secret
@@ -282,7 +276,7 @@ The content of `token` is elided here.
 
 - Create an imagePullSecret, as described in [Specifying ImagePullSecrets on a Pod](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
 -->
-## 为服务账户添加 ImagePullSecrets  {#add-imagepullsecrets-to-a-service-account}
+## 为服务账号添加 ImagePullSecrets  {#add-imagepullsecrets-to-a-service-account}
 
 ### 创建 ImagePullSecret
 
@@ -318,9 +312,9 @@ The content of `token` is elided here.
 
 Next, modify the default service account for the namespace to use this secret as an imagePullSecret.
 -->
-### 将镜像拉取 Secret 添加到服务账户
+### 将镜像拉取 Secret 添加到服务账号
 
-接着修改命名空间的 `default` 服务帐户，令其使用该 Secret 用作 `imagePullSecret`。
+接着修改命名空间的 `default` 服务账号，令其使用该 Secret 用作 `imagePullSecret`。
 
 ```shell
 kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'
@@ -350,8 +344,6 @@ metadata:
   namespace: default
   resourceVersion: "243024"
   uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
-secrets:
-- name: default-token-uudge
 ```
 
 <!--
@@ -372,16 +364,14 @@ metadata:
   name: default
   namespace: default
   uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
-secrets:
-- name: default-token-uudge
 imagePullSecrets:
 - name: myregistrykey
 ```
 
 <!--
 Finally replace the serviceaccount with the new updated `sa.yaml` file
 -->
-最后，使用新更新的 `sa.yaml` 文件替换服务账户。
+最后，使用新更新的 `sa.yaml` 文件替换服务账号。
 
 ```shell
 kubectl replace serviceaccount default -f ./sa.yaml
@@ -394,7 +384,7 @@ Now, when a new Pod is created in the current namespace and using the default Se
 -->
 ### 验证镜像拉取 Secret 已经被添加到 Pod 规约
 
-现在，在当前命名空间中创建使用默认服务账户的新 Pod 时，新 Pod
+现在，在当前命名空间中创建使用默认服务账号的新 Pod 时，新 Pod
 会自动设置其 `.spec.imagePullSecrets` 字段：
 
 ```shell
@@ -414,7 +404,7 @@ myregistrykey
 <!--
 ## Service Account Token Volume Projection
 -->
-## 服务帐户令牌卷投射   {#service-account-token-volume-projection}
+## 服务账号令牌卷投射   {#service-account-token-volume-projection}
 
 {{< feature-state for_k8s_version="v1.20" state="stable" >}}
 
@@ -431,7 +421,7 @@ command line arguments to `kube-apiserver`:
 -->
 * `--service-account-issuer`
 
-  此参数可作为服务账户令牌发放者的身份标识（Identifier）。你可以多次指定
+  此参数可作为服务账号令牌发放者的身份标识（Identifier）。你可以多次指定
   `--service-account-issuer` 参数，对于要变更发放者而又不想带来业务中断的场景，
   这样做是有用的。如果这个参数被多次指定，则第一个参数值会被用来生成令牌，
   而所有参数值都会被用来确定哪些发放者是可接受的。你所运行的 Kubernetes
@@ -454,7 +444,7 @@ command line arguments to `kube-apiserver`:
 -->
 * `--service-account-signing-key-file`
 
-  指向包含当前服务账户令牌发放者的私钥的文件路径。
+  指向包含当前服务账号令牌发放者的私钥的文件路径。
   此发放者使用此私钥来签署所发放的 ID 令牌。
 <!--
 * `--api-audiences` (can be omitted)
@@ -463,7 +453,7 @@ command line arguments to `kube-apiserver`:
 -->
 * `--api-audiences` (可以省略)
 
-  服务账户令牌身份检查组件会检查针对 API 访问所使用的令牌，
+  服务账号令牌身份检查组件会检查针对 API 访问所使用的令牌，
   确认令牌至少是被绑定到这里所给的受众（audiences）之一。
   如果此参数被多次指定，则针对所给的多个受众中任何目标的令牌都会被
   Kubernetes API 服务器当做合法的令牌。如果 `--service-account-issuer`
@@ -477,10 +467,10 @@ duration. These properties are not configurable on the default service account
 token. The service account token will also become invalid against the API when
 the Pod or the ServiceAccount is deleted.
 -->
-kubelet 还可以将服务帐户令牌投射到 Pod 中。
+kubelet 还可以将服务账号令牌投射到 Pod 中。
 你可以指定令牌的期望属性，例如受众和有效期限。
-这些属性在 default 服务帐户令牌上无法配置。
-当删除 Pod 或 ServiceAccount 时，服务帐户令牌也将对 API 无效。
+这些属性在 default 服务账号令牌上无法配置。
+当删除 Pod 或 ServiceAccount 时，服务账号令牌也将对 API 无效。
 
 <!--
 This behavior is configured on a PodSpec using a ProjectedVolume type called
@@ -522,7 +512,7 @@ The application is responsible for reloading the token when it rotates. Periodic
 <!--
 ## Service Account Issuer Discovery
 -->
-## 发现服务账户分发者
+## 发现服务账号分发者
 
 {{< feature-state for_k8s_version="v1.21" state="stable" >}}
 
@@ -531,7 +521,7 @@ The Service Account Issuer Discovery feature is enabled when the Service Account
 Token Projection feature is enabled, as described
 [above](#service-account-token-volume-projection).
 -->
-当启用服务账户令牌投射时启用发现服务账户分发者（Service Account Issuer Discovery）
+当启用服务账号令牌投射时启用发现服务账号分发者（Service Account Issuer Discovery）
 这一功能特性，如[上文所述](#service-account-token-volume-projection)。
 
 <!--
@@ -564,9 +554,9 @@ Configuration document at `/.well-known/openid-configuration` and the associated
 JSON Web Key Set (JWKS) at `/openid/v1/jwks`. The OpenID Provider Configuration
 is sometimes referred to as the _discovery document_.
 -->
-发现服务账户分发者这一功能使得用户能够用联邦的方式结合使用 Kubernetes 
+发现服务账号分发者这一功能使得用户能够用联邦的方式结合使用 Kubernetes 
 集群（“Identity Provider”，标识提供者）与外部系统（“Relying Parties”，
-依赖方）所分发的服务账户令牌。
+依赖方）所分发的服务账号令牌。
 
 当此功能被启用时，Kubernetes API 服务器会在 `/.well-known/openid-configuration`
 提供一个 OpenID 提供者配置文档，并在 `/openid/v1/jwks` 处提供与之关联的
@@ -585,8 +575,8 @@ requirements and which external systems they intend to federate with.
 -->
 集群包括一个的默认 RBAC ClusterRole, 名为 `system:service-account-issuer-discovery`。 
 默认的 RBAC ClusterRoleBinding 将此角色分配给 `system:serviceaccounts` 组，
-所有服务帐户隐式属于该组。这使得集群上运行的 Pod
-能够通过它们所挂载的服务帐户令牌访问服务帐户发现文档。
+所有服务账号隐式属于该组。这使得集群上运行的 Pod
+能够通过它们所挂载的服务账号令牌访问服务账号发现文档。
 此外，管理员可以根据其安全性需要以及期望集成的外部系统选择是否将该角色绑定到
 `system:authenticated` 或 `system:unauthenticated`。
 
@@ -599,7 +589,7 @@ validation of Kubernetes service account tokens.
 {{< note >}}
 对 `/.well-known/openid-configuration` 和 `/openid/v1/jwks` 路径请求的响应被设计为与
 OIDC 兼容，但不是与其完全一致。
-返回的文档仅包含对 Kubernetes 服务账户令牌进行验证所必须的参数。
+返回的文档仅包含对 Kubernetes 服务账号令牌进行验证所必须的参数。
 {{< /note >}}
 
 <!--
@@ -608,7 +598,7 @@ the Kubernetes service account tokens. Relying parties first query for the
 OpenID Provider Configuration, and use the `jwks_uri` field in the response to
 find the JWKS.
 -->
-JWKS 响应包含依赖方可以用来验证 Kubernetes 服务账户令牌的公钥数据。
+JWKS 响应包含依赖方可以用来验证 Kubernetes 服务账号令牌的公钥数据。
 依赖方先会查询 OpenID 提供者配置，之后使用返回响应中的 `jwks_uri` 来查找 JWKS。
 
 <!--
@@ -639,7 +629,7 @@ See also:
 -->
 另请参见：
 
-- [服务账户的集群管理员指南](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/)
-- [服务账户签署密钥检索 KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/1393-oidc-discovery)
+- [服务账号的集群管理员指南](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/)
+- [服务账号签署密钥检索 KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/1393-oidc-discovery)
 - [OIDC 发现规范](https://openid.net/specs/openid-connect-discovery-1_0.html)