diff --git a/cn/docs/admin/service-accounts-admin.md b/cn/docs/admin/service-accounts-admin.md
index 356ad76711..b607591f55 100644
--- a/cn/docs/admin/service-accounts-admin.md
+++ b/cn/docs/admin/service-accounts-admin.md
@@ -4,53 +4,53 @@ assignees:
 - davidopp
 - lavalamp
 - liggitt
-title: Managing Service Accounts
+title: 管理服务帐号（Service Accounts）
 ---
 
-*本文是 service accounts 管理员手册。需要[Service Accounts 用户手册](/cn/docs/user-guide/service-accounts)的知识背景。*
 
-*对于 authorization 和 user accounts 支持已经在计划中，但是还未完成。为了更好地解释 service
-accounts，有时会提到一些未完成的功能特性。*
+
+*本文是服务帐户管理员手册。需要[服务帐户用户手册](/docs/user-guide/service-accounts)的知识背景。*
+
+*对于认证和用户帐号（user accounts）的支持已经在计划中，但是还未完成。为了更好地解释用户帐户，有时会提到一些未完成的功能特性。*
 
 
 ## 用户账号 vs 服务账号
 
 
-Kubernetes 将 user account 和 service account 的概念区分开，主要基于以下几个原因：
+Kubernetes 将用户账号和服务账号的概念区分开，主要基于以下几个原因：
 
-  - user account 是给人使用的。servcice account是给 pod 中运行的进程使用的。
-  - user account 为全局设计。命名必须在一个集群的所有命名空间中唯一，未来的用户资源不会被设计到命名空间中。
-    service account 是按命名空间的。
-  - 典型场景中，一个集群的 user account 是来自于企业数据库的，在数据库中新建用户一般需要特殊权限，并且账号是与复杂都业务流程关联的。
-    service account的创建往往更轻量，允许集群用户为特定的任务创建service account（即，权限最小化原则）。
+  - 用户账号是给人使用的。服务账号是给 pod 中运行的进程使用的。
+  - 用户账号为全局设计的。命名必须在一个集群的所有命名空间中唯一，未来的用户资源不会被设计到命名空间中。
+    服务账号是在命名空间里的。
+  - 典型场景中，一个集群的用户账号是从企业数据库的同步来的，在数据库中新用户帐号一般需要特殊权限，并且账号是与复杂的业务流程关联的。
+    服务账号的创建往往更轻量，允许集群用户为特定的任务创建服务账号（即，权限最小化原则）。
   - 对于人和服务的账号，审计要求会是不同的。
-  - 对于复杂系统而言，配置包可以包含该系统各类组件的 service account 定义，
-    因为 service account 可以有临时的创建需求和自己的命名空间，这类配置是便携式的。
+  - 对于复杂系统而言，配置包可以包含该系统各类组件的服务账号定义，
+    因为服务账号能被临时创建，并且有命名空间分类的名字，这类配置是便携式的。
 
 
 ## 服务账号自动化
 
 
-service accounts 的自动化由三个独立的组建共同配合实现：
+服务账号的自动化由三个独立的组件共同配合实现：
 
-  - A Service account admission controller (service account 准入控制器)
-  - A Token controller (令牌控制器)
-  - A Service account controller (service account 控制器)
+  - 用户账号准入控制器（A Service account admission controller）
+  - 令牌控制器（A Token controller）
+  - 服务账号控制器（A Service account controller）
 
 
 ### 服务账号准入控制器
 
 
-对于 pods 的操作是通过一个叫做 [准入控制器](/cn/docs/admin/admission-controllers) 的插件实现的。它是 apiserver 的一部分。
-当准入控制器被创建或更新时，他会对 pod 同步进行操作。当这个插件时活动状态时（大部分版本默认是活动状态），并在 pod 被创建或者更改时，
+对于 pods 的操作是通过一个叫做 [准入控制器](/docs/admin/admission-controllers) 的插件（plugin）实现的。它是 APIserver 的一部分。
+当 pod 被创建或更新时，它会同步更改 pod。当这个插件是活动状态时（大部分版本默认是活动状态），在 pod 被创建或者更改时，
 它会做如下操作：
 
- 1. 如果 pod 没有配置 `ServiceAccount`，它会将 `ServiceAccount` 设置为  `default`。
- 2. 它会确保被 pod 关联的 `ServiceAccount` 是存在的，否则就拒绝请求。
- 
- 4. 如果 pod 没有包含任何的 `ImagePullSecrets`，那么 `ServiceAccount` 的 `ImagePullSecrets` 就会被添加到 pod。
- 5. 它会把一个 `volume` 添加给 pod， 该 pod 包含有一个用于 API 访问的 token。
- 6. 它会把一个 `volumeSource` 添加到 pod 的每个 container，并挂载到 `/var/run/secrets/kubernetes.io/serviceaccount`。
+ 1. 如果 pod 没有配置 `ServiceAccount`，它会将 `ServiceAccount` 设置为 `default`。
+ 2. 确保被 pod 关联的 `ServiceAccount` 是存在的，否则就拒绝请求。
+ 3. 如果 pod 没有包含任何的 `ImagePullSecrets`，那么 `ServiceAccount` 的 `ImagePullSecrets` 就会被添加到 pod。
+ 4. 它会把 `volume` 添加给 pod，该 pod 包含有一个用于 API 访问的令牌。
+ 5. 它会把 `volumeSource` 添加到 pod 的每个容器，挂载到 `/var/run/secrets/kubernetes.io/serviceaccount`。
 
 
 ### 令牌控制器
@@ -59,21 +59,20 @@ service accounts 的自动化由三个独立的组建共同配合实现：
 令牌控制器（TokenController）作为 controller-manager 的一部分运行。它异步运行。它会：
 
 - 监听对于 serviceAccount 的创建动作，并创建对应的 Secret 以允许 API 访问。
-- 监听对于 serviceAccount 的删除动作，并删除所有对应的 ServiceAccountToken Secrets。
-- 监听对于 secret 的添加动作，确保相关联的 ServiceAccount 是存在的，并在根据需要为 secret 添加一个 token。
+- 监听对于 serviceAccount 的删除动作，并删除所有对应的 ServiceAccountToken Secret。
+- 监听对于 secret 的添加动作，确保相关联的 ServiceAccount 是存在的，并根据需要为 secret 添加一个令牌。
 - 监听对于 secret 的删除动作，并根据需要删除对应 ServiceAccount 的关联。
 
-你必须给令牌控制器（token controller）传递一个 service account 的私钥（private key），可以通过 `--service-account-private-key-file` 参数完成。
-传递的私钥将被用来对 service account tokens 进行签名。类似的，你必须给 kube-apiserver 传递一个公钥（public key），通过 `--service-account-key-file`
-参数完成。传递的公钥会被用来验证认证过程中的令牌（token）。
+你必须给令牌控制器传递一个服务帐号的私钥（private key），通过 `--service-account-private-key-file` 参数完成。传递的私钥将被用来对服务帐号令牌进行签名。
+类似的，你必须给 kube-apiserver 传递一个公钥（public key），通过 `--service-account-key-file` 参数完成。传递的公钥在认证过程中会被用于验证令牌。
 
 
-#### 创建额外的 API 令牌
+#### 创建额外的 API 令牌（API token）
 
 
-控制器的循环运行会确保对于每个 service account 都存在一个带有 API token（API 令牌）的secret。
-如需要为一个 service account 创建一个额外的 API 令牌（API token），可以创建一个 `ServiceAccountToken`
-类型的 secret，并添加与 service account 对应的 annotation 属性，控制器会为它更新 token：
+控制器的循环运行会确保对于每个服务帐号都存在一个带有 API 令牌的 secret。
+如需要为服务帐号创建一个额外的 API 令牌，可以创建一个 `ServiceAccountToken`
+类型的 secret，并添加与服务帐号对应的 annotation 属性，控制器会为它更新令牌：
 
 secret.json:
 
@@ -97,7 +96,7 @@ kubectl describe secret mysecretname
 ```
 
 
-#### 删除／作废服务账号令牌
+#### 删除/作废服务账号令牌
 
 ```shell
 kubectl delete secret mysecretname
@@ -107,5 +106,4 @@ kubectl delete secret mysecretname
 ### 服务账号控制器
 
 
-Service Account Controller 在 namespaces 内管理 ServiceAccount，需要保证名为 "default" 的
-ServiceAccount在每个命名空间中存在。
\ No newline at end of file
+服务帐号控制器在命名空间内管理 ServiceAccount，需要保证名为 "default" 的 ServiceAccount 在每个命名空间中存在。
\ No newline at end of file