diff --git a/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md b/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md
index a37263f949..0db27194c6 100644
--- a/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md
+++ b/content/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer.md
@@ -16,7 +16,7 @@ weight: 10
<!-- overview -->
<!--
-Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs.
+Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs.
-->
配置 [聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 允许
Kubernetes apiserver 使用其它 API 扩展，这些 API 不是核心 Kubernetes API 的一部分。
@@ -26,7 +26,7 @@ Kubernetes apiserver 使用其它 API 扩展，这些 API 不是核心 Kubernete
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!--
-There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA.
+There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA.
-->
{{< note >}}
要使聚合层在您的环境中正常工作以支持代理服务器和扩展 apiserver 之间的相互 TLS 身份验证，
@@ -165,7 +165,7 @@ note:
3.Kube Apiserver 使用任何配置的鉴权方法（例如 RBAC）对请求的 URL 鉴权
kube-apiserver / aggregator -> 聚合的 apiserver:
-
+
note:
4.aggregator 使用`--proxy-client-cert-file`，`--proxy-client-key-file`客户端证书/密钥打开与聚合 Apiserver 的连接以保护通道
@@ -217,7 +217,7 @@ The Kubernetes apiserver now is prepared to send the request to the extension ap
用户与 Kubernetes apiserver 通信，请求访问 path 。Kubernetes apiserver 使用它的标准认证和授权配置来对用户认证，以及对特定 path 的鉴权。
-有关对 Kubernetes 集群认证的概述，请参见 [对集群认证](/docs/reference/access-authn-authz/authentication/)。有关对Kubernetes群集资源的访问鉴权的概述，请参见 [鉴权概述](/zh/docs/reference/access-authn-authz/authorization/)。
+有关对 Kubernetes 集群认证的概述，请参见 [对集群认证](/zh/docs/reference/access-authn-authz/authentication/)。有关对Kubernetes群集资源的访问鉴权的概述，请参见 [鉴权概述](/zh/docs/reference/access-authn-authz/authorization/)。
到目前为止，所有内容都是标准的 Kubernetes API 请求，认证与鉴权。
@@ -283,7 +283,7 @@ When started with these options, the Kubernetes apiserver will:
1. Use them to authenticate to the extension apiserver.
2. Create a configmap in the `kube-system` namespace called `extension-apiserver-authentication`, in which it will place the CA certificate and the allowed CNs. These in turn can be retrieved by extension apiservers to validate requests.
-Note that the same client certificate is used by the Kubernetes apiserver to authenticate against _all_ extension apiservers. It does not create a client certificate per extension apiserver, but rather a single one to authenticate as the Kubernetes apiserver. This same one is reused for all extension apiserver requests.
+Note that the same client certificate is used by the Kubernetes apiserver to authenticate against _all_ extension apiservers. It does not create a client certificate per extension apiserver, but rather a single one to authenticate as the Kubernetes apiserver. This same one is reused for all extension apiserver requests.
-->
使用这些选项启动时，Kubernetes apiserver 将：
@@ -309,7 +309,7 @@ These header names are also placed in the `extension-apiserver-authentication` c
当 Kubernetes apiserver 将请求代理到扩展 apiserver 时，它将向扩展 apiserver 通知原始请求已成功通过其验证的用户名和组。它在其代理请求的 http 标头中提供这些。您必须将要使用的标头名称告知 Kubernetes apiserver。
* 通过`--requestheader-username-headers` 标明用来保存用户名的头部
-* 通过`--requestheader-group-headers` 标明用来保存 group 的头部
+* 通过`--requestheader-group-headers` 标明用来保存 group 的头部
* 通过`--requestheader-extra-headers-prefix` 标明用来保存拓展信息前缀的头部
这些标头名称也放置在`extension-apiserver-authentication` 的 configmap 中，因此扩展 apiserver 可以检索和使用它们。
@@ -323,7 +323,7 @@ The extension apiserver, upon receiving a proxied request from the Kubernetes ap
* Client CA certificate
* List of allowed names (CNs)
* Header names for username, group and extra info
-
+
2. Check that the TLS connection was authenticated using a client certificate which:
* Was signed by the CA whose certificate matches the retrieved CA certificate.
* Has a CN in the list of allowed CNs, unless the list is blank, in which case all CNs are allowed.
@@ -337,7 +337,7 @@ The extension apiserver, upon receiving a proxied request from the Kubernetes ap
* 客户端 CA 证书
* 允许名称（CN）列表
* 用户名，组和其他信息的头部
-
+
2.使用以下证书检查 TLS 连接是否已通过认证：
* 由其证书与检索到的 CA 证书匹配的 CA 签名。
* 在允许的 CN 列表中有一个 CN，除非列表为空，在这种情况下允许所有 CN。
@@ -359,7 +359,7 @@ In order to have permission to retrieve the configmap, an extension apiserver re
<!--
### Extension Apiserver Authorizes the Request
-The extension apiserver now can validate that the user/group retrieved from the headers are authorized to execute the given request. It does so by sending a standard [SubjectAccessReview](/docs/reference/access-authn-authz/authorization/) request to the Kubernetes apiserver.
+The extension apiserver now can validate that the user/group retrieved from the headers are authorized to execute the given request. It does so by sending a standard [SubjectAccessReview](/docs/reference/access-authn-authz/authorization/) request to the Kubernetes apiserver.
In order for the extension apiserver to be authorized itself to submit the `SubjectAccessReview` request to the Kubernetes apiserver, it needs the correct permissions. Kubernetes includes a default `ClusterRole` named `system:auth-delegator` that has the appropriate permissions. It can be granted to the extension apiserver's service account.
-->
@@ -504,7 +504,7 @@ at the subpath "/my-path", and to verify the TLS connection against the ServerNa
path 配置是可选的，默认为`/`。
下面是为可在端口 `1234` 上调用的扩展 apiserver 的配置示例
-服务位于子路径 `/my-path` 下，并针对 ServerName `my-service-name.my-service-namespace.svc`
+服务位于子路径 `/my-path` 下，并针对 ServerName `my-service-name.my-service-namespace.svc`
使用自定义的 CA 包来验证 TLS 连接
使用自定义 CA 捆绑包的`my-service-name.my-service-namespace.svc`。
@@ -533,5 +533,3 @@ spec:
* 使用聚合层[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)。
* 有关高级概述，请参阅[使用聚合层扩展 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)。
* 了解如何 [使用自定义资源扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。
-
-