zh-translation:content/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/index.md (#6097)

* zh-trans-1632 * zh-trans-1632-after-review
2019-12-25 15:24:19 +08:00 · 2019-12-25 15:24:19 +08:00 · 4902f7b5ce
parent 238e9e6210
commit 4902f7b5ce
1 changed files with 63 additions and 67 deletions
--- a/content/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/index.md
+++ b/content/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/index.md
@ -1,31 +1,30 @@
 ---
-title: 使用通配符主机配置 Egress 流量
+title: Wildcard 主机的 egress
-description: 介绍如何为公共域中的一组主机启用 Egress 流量，而不是单独配置每个主机。
+description: 描述如何开启通用域中一组主机的 egress，无需单独配置每一台主机。
 keywords: [traffic-management,egress]
 weight: 50
 aliases:
  - /zh/docs/examples/advanced-gateways/wildcard-egress-hosts/
 ---
-[控制 Egress 流量](/zh/docs/tasks/traffic-management/egress/)任务和[配置 Egress Gateway](/zh/docs/tasks/traffic-management/egress/egress-gateway/) 示例示例讲述了如何为类似 `edition.cnn.com` 的特定主机名配置 egress 流量。此示例演示了如何为一组处于公共域（如 `*.wikipedia.org`）的主机启用 egress 流量，而非单独配置每个主机。
+[控制 Egress 流量](/zh/docs/tasks/traffic-management/egress/) 任务和[配置一个 Egress 网关](/zh/docs/tasks/traffic-management/egress/egress-gateway/) 示例描述如何配置特定主机的 egress 流量，如：`edition.cnn.com`。本示例描述如何为通用域中的一组特定主机开启 egress 流量，譬如：`*.wikipedia.org`，无需单独配置每一台主机。
 ## 背景{#background}
-假设您希望在 Istio 中为 `wikipedia.org` 网站的所有语言版本启用 egress 流量。每个特定语言版本的 `wikipedia.org`
+假定您想要为 Istio 中所有语种的 `wikipedia.org` 站点开启 egress 流量。每个语种的 `wikipedia.org` 站点均有自己的主机名，譬如：英语和德语对应的主机分别为 `en.wikipedia.org` 和 `de.rikipedia.org`。您希望通过通用配置项开启所有 Wikipedia 站点的 egress 流量，无需单独配置每个语种的站点。
 都有自己的主机名，例如 `en.wikipedia.org` 和 `de.wikipedia.org` 分别对应英文和德文。
 您希望通过通用配置项对所有 `wikipedia` 网站启用 egress 流量，而无需单独配置每个语言的站点。
 {{< boilerplate before-you-begin-egress >}}
-*   [部署 Istio egress gateway](/zh/docs/tasks/traffic-management/egress/egress-gateway/#deploy-Istio-egress-gateway)。
+*   [部署 Istio egress 网关](/zh/docs/tasks/traffic-management/egress/egress-gateway/#deploy-Istio-egress-gateway)。
-*   [开启 Envoy 访问日志](/zh/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging)
+*   [开启 Envoy 的访问日志](/zh/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging)
-## 配置到通配符主机的直接流量{#configure-direct-traffic-to-a-wildcard-host}
+## 引导流量流向 Wildcard 主机{#configure-direct-traffic-to-a-wildcard-host}
-访问公共域中的一组主机的第一种也是最简单的方法是通过配置一个简单的带有通配符主机的 `ServiceEntry`，并直接从 sidecar 调用服务。直接调用服务（即不通过 egress gateway）时，通配符主机与任何其他（例如，全限定的）主机都没有区别，只有当公共域中有许多主机时，此功能才会更加方便。
+访问通用域中一组主机的第一个也是最简单的方法，是使用一个 wildcard 主机配置一个简单的 `ServiceEntry`，直接从 sidecar 调用服务。
 当直接调用服务时（譬如：不是通过一个 egress 网关），一个 wildcard 主机的配置与任何其他主机（如：全域名主机）没有什么不同，只是当通用域中有许多台主机时，这样比较方便。
-1.  为`*.wikipedia.org`配置 `ServiceEntry` 和相应的 `VirtualSevice`：
+1.  为 `*.wikipedia.org` 定义一个 `ServiceEntry` 以及相应的 `VirtualSevice`：
    {{< text bash >}}
    $ kubectl apply -f - <<EOF
@ -61,8 +60,8 @@ aliases:
    EOF
    {{< /text >}}
-1.  向
+1.  发送 HTTPS 请求至
-    [https://en.wikipedia.org](https://en.wikipedia.org) 和 [https://de.wikipedia.org](https://de.wikipedia.org) 发送 HTTP 请求：
+    [https://en.wikipedia.org](https://en.wikipedia.org) and [https://de.wikipedia.org](https://de.wikipedia.org):
    {{< text bash >}}
    $ kubectl exec -it $SOURCE_POD -c sleep -- sh -c 'curl -s https://en.wikipedia.org/wiki/Main_Page | grep -o "<title>.*</title>"; curl -s https://de.wikipedia.org/wiki/Wikipedia:Hauptseite | grep -o "<title>.*</title>"'
@ -70,27 +69,25 @@ aliases:
    <title>Wikipedia – Die freie Enzyklopädie</title>
    {{< /text >}}
-### 清理到通配符主机的直接流量{#cleanup-direct-traffic-to-a-wildcard-host}
+### 清除引导流量至 wildcard 主机{#cleanup-direct-traffic-to-a-wildcard-host}
 {{< text bash >}}
 $ kubectl delete serviceentry wikipedia
 $ kubectl delete virtualservice wikipedia
 {{< /text >}}
-## 配置到通配符主机的 egress gateway 流量{#configure-egress-gateway-traffic-to-a-wildcard-host}
+## 配置访问 wildcard 主机的 egress 网关{#configure-egress-gateway-traffic-to-a-wildcard-host}
-通过出口网关访问通配符主机的配置取决于是否为一组通配符域由单个公共主机提供服务。
+能否配置通过 egress 网关访问 wildcard 主机取决于这组 wildcard 域名有唯一一个通用主机。
-通过 egress gateway 访问通配符主机的配置取决于通配符域名集合和是否由单个公共主机提供。
+以 _*.wikipedia.org_ 为例。每个语种特殊的站点都有自己的 _wikipedia.org_ 服务器。您可以向任意一个 _*.wikipedia.org_ 站点的 IP 发送请求，包括 _www.wikipedia.org_，该站点 [管理服务](https://en.wikipedia.org/wiki/Virtual_hosting) 所有特定主机。
 这是 _*.wikipedia.org_ 的情况。所有特定语言的网站都由 _wikipedia.org_ 服务器之一提供服务。您可以将流量路由到任意 _*.wikipedia.org_ 网站的 IP，包括 _www.wikipedia.org_，然后它将为任意特定网站[提供服务](https://en.wikipedia.org/wiki/Virtual_hosting)。
-在一般情况下，单个主机服务器无法提供通配符的所有域名，
+通常情况下，通用域中的所有域名并不由一个唯一的 hosting server 提供服务。此时，需要一个更加复杂的配置。
 需要更复杂的配置。
-### 单个托管服务器的通配符配置{#wildcard-configuration-for-a-single-hosting-server}
+### 单一 hosting 服务器的 Wildcard 配置{#wildcard-configuration-for-a-single-hosting-server}
-当所有通配符主机都由单个服务器提供服务时，基于 egress gateway 到一个通配符主机的配置和到任意主机的配置非常相似，除了一个例外：配置后的路由目的地址将与配置的主机（通配符）不同。它将使用域名集合的单一服务器主机进行配置。
+当一台唯一的服务器为所有 wildcard 主机提供服务时，基于 egress 网关访问 wildcard 主机的配置与普通主机类似，除了：配置的路由目标不能与配置的主机相同，如：wildcard 主机，需要配置为通用域集合的唯一服务器主机。
-1.   为 _*.wikipedia.org_ 创建一个 egress `Gateway`、一个 destination rule 和一 个 virtual service，以将流量定向到 egress gateway，并从 egress gateway 发送到外部 service。
+1.  为 _*.wikipedia.org_ 创建一个 egress `Gateway`、一个目标规则以及一个虚拟服务，来引导请求通过 egress 网关并从 egress 网关访问外部服务。
    {{< text bash >}}
    $ kubectl apply -f - <<EOF
@ -159,7 +156,7 @@ $ kubectl delete virtualservice wikipedia
    EOF
    {{< /text >}}
-1.  为目标服务创建 `ServiceEntry`，即 _www.wikipedia.org_。
+1.  为目标服务器 _www.wikipedia.org_ 创建一个 `ServiceEntry`。
    {{< text bash >}}
    $ kubectl apply -f - <<EOF
@ -178,7 +175,7 @@ $ kubectl delete virtualservice wikipedia
    EOF
    {{< /text >}}
-1.  发送 HTTP 请求到
+1.  发送请求至
    [https://en.wikipedia.org](https://en.wikipedia.org) 和 [https://de.wikipedia.org](https://de.wikipedia.org)：
    {{< text bash >}}
@ -187,15 +184,14 @@ $ kubectl delete virtualservice wikipedia
    <title>Wikipedia – Die freie Enzyklopädie</title>
    {{< /text >}}
-1.  检查 egress gateway 代理的统计数据，找到对应于到 _*.wikipedia.org_ 的请求的 counter。如果 Istio 部署在 `istio-system`
+1. 检查 egress 网关代理访问 _*.wikipedia.org_ 的计数器统计值。如果 Istio 部署在 `istio-system` 命名空间中，打印输出计数器的命令为：
   namespace 中，打印 counter 的命令为：
    {{< text bash >}}
    $ kubectl exec -it $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -n istio-system -- pilot-agent request GET clusters | grep '^outbound|443||www.wikipedia.org.*cx_total:'
    outbound|443||www.wikipedia.org::208.80.154.224:443::cx_total::2
    {{< /text >}}
-#### 清理单个托管服务器的通配符配置{#cleanup-wildcard-configuration-for-a-single-hosting-server}
+#### 清除单点服务器的 wildcard 配置{#cleanup-wildcard-configuration-for-a-single-hosting-server}
 {{< text bash >}}
 $ kubectl delete serviceentry www-wikipedia
@ -204,32 +200,30 @@ $ kubectl delete virtualservice direct-wikipedia-through-egress-gateway
 $ kubectl delete destinationrule egressgateway-for-wikipedia
 {{< /text >}}
-### 任意域名的通配符配置{#wildcard-configuration-for-arbitrary-domains}
+### 任意域的 Wildcard 配置{#wildcard-configuration-for-arbitrary-domains}
-上一节中的配置之所以有效，是因为所有 _*.wikipedia.org_ 网站都可以由任何一个 _*.wikipedia.org_ 服务器提供服务。然而并非总是如此。
+前面章节的配置生效，是因为 _*.wikipedia.org_ 站点可以由任意一个 _wikipedia.org_ 服务器提供服务。然而，情况并不总是如此。
-例如，您可能希望配置 egress 控制以访问更一般的通配符域名，如 `*.com` 或者 `*.org`。
+譬如，你可能想要配置 egress 控制到更为通用的 wildcard 域，如：`*.com` 或 `*.org`。
-配置到任意通配符域名的流量为 Istio gateway 带来了挑战。在上一节中，您将流量定向到 _www.wikipedia.org_，并且在配置期间，您的 gateway 知道此主机。但是，gateway 无法知道它收到请求的任意主机的 IP 地址。这是由于 [Envoy](https://www.envoyproxy.io) 的限制，默认 Istio egress gateway 使用它作为代理。
+配置流量流向任意 wildcard 域，为 Istio 网关引入一个挑战。在前面的章节中，您在配置中，将 _www.wikipedia.org_ 配置为网关的路由目标主机，将流量导向该地址。
-Envoy 将流量路由到预定义的主机、预定义的 IP 地址或请求的原始目标 IP 地址。在 gateway 的情况下，请求的原始目的 IP 将会丢失，因为请求会首先路由到 egress gateway，故其目标 IP 地址为 gateway 的 IP 地址。
+然而，网关并不知道它接收到的请求中任意 arbitrary 主机的 IP 地址。
 这是 Istio 默认的 egress 网关代理 [Envoy](https://www.envoyproxy.io) 的限制。Envoy 或者将流量路由至提前定义好的主机，或者路由至提前定义好的 IP 地址，或者是请求的最初 IP 地址。在网关案例中，请求的最初目标 IP 被丢弃，因为请求首先路由至 egress 网关，其目标 IP 为网关的 IP 地址。
-因此，基于 Envoy 的 Istio gateway 无法将流量路由到未预先配置的任意主机，也就无法对任意通配符域名执行流量控制。要为 HTTPS 和任何 TLS 启用此类流量控制，
+因此，基于 Envoy 的 Istio 网关无法将流量路由至没有预先配置的 arbitrary 主机，从而，无法对任意 wildcard 域实施流量控制。
-除了 Envoy 之外，还需要部署 SNI 转发代理。Envoy 会将发往通配符域名的请求路由到 SNI 转发代理，而 SNI 转发代理将转发请求到 SNI 值指定的目的地。
+为了对 HTTPS 和任意 TLS 连接开启流量控制，您需要在 Envoy 的基础上再部署一个 SNI 转发代理。Envoy 将访问 wildcard 域的请求路由至 SNI 转发代理，代理反过来将请求转发给 SNI 值中约定的目标地址。
-具有 SNI 代理的 egress gateway 和 Istio 体系结构的相关部分如下图所示：
+带 SNI 代理的 egress 网关，以及相关的 Istio 架构部分如下图所示：
 {{< image width="80%" link="./EgressGatewayWithSNIProxy.svg" caption="Egress Gateway with SNI proxy" >}}
-以下部分介绍如何使用 SNI 代理重新部署 egress gateway，然后配置 Istio 通过 gateway 将 HTTPS 流量路由到任意通配符域名。
+如下章节向您展示如何重新部署带 SNI 代理的 egress 网关，并配置 Istio 通过网关将 HTTPS 请求导向任意 wildcard 域。
-#### 使用 SNI 代理配置 egress gateway{#setup-egress-gateway-with-server-name-indication-proxy}
+#### 安装带 SNI 代理的 egress 网关{#setup-egress-gateway-with-SNI-proxy}
-在本节中，您部署的 egress gateway 在标准的 Istio Envoy 代理之外，还会部署一个 SNI 代理。此示例使用 [Nginx](http://nginx.org) 作为 SNI
+本章节，除了标准的 Istio Envoy 代理，您将再部署一个带 SNI 代理的 egress 网关。本示例使用 [Nginx](http://nginx.org) 作为 SNI 代理。任何一个能够根据任意的、非预先配置的 SNI 值路由流量的 SNI 代理均可。
-代理，但是，任何能够根据任意的、非提前配置的 SNI 值路由流量的 SNI 代理都可以使用。SNI 代理将会监听 `8443` 端口，您也可以使用任何端口，但需与指定给
+SNI 代理将监听在端口 `8443` 上，您可以绑定任意其它端口，egress `Gateway` 和 `VirtualServices` 中配置的端口除外。SNI 代理将流量转发至端口 `443`。
 egress `Gateway` 的和 `VirtualServices` 绑定的端口不同。
 SNI 代理会将流量转发到 `443` 端口。
-1.  为 Nginx SNI 代理创建一个配置文件。当需要时，您可能希望编辑该文件指定附加的 Nginx 配置。请注意，`server` 的 `listen` 指令指定端口 `8443`，
+1.  创建一个 Nginx SNI 代理的配置文件。您可以按需编辑文件指定附加的 Nginx 设置。注意 `server` 的 `listen` 原语指定端口为 `8443`，其 `proxy_pass` 原语使用 `ssl_preread_server_name` 端口为 `443`，`ssl_preread` 为 `on` 以开启 `SNI` 读。
   其 `proxy_pass` 指令使用 `ssl_preread_server_name` 和 `443` 端口及 `ssl_preread` 为 `on` 来启用 `SNI` 读取。
    {{< text bash >}}
    $ cat <<EOF > ./sni-proxy.conf
@ -257,13 +251,13 @@ SNI 代理会将流量转发到 `443` 端口。
    {{< /text >}}
 1.  创建一个 Kubernetes [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/)
-    来保存 Nginx SNI 的配置：
+    来保存 Nginx SNI 代理的配置文件：
    {{< text bash >}}
    $ kubectl create configmap egress-sni-proxy-configmap -n istio-system --from-file=nginx.conf=./sni-proxy.conf
    {{< /text >}}
-1.  以下命令将生成 `istio-egressgateway-with-sni-proxy.yaml` 文件，您可以选择性编辑并部署。
+1.  下面的命令将生成 `istio-egressgateway-with-sni-proxy.yaml`，您可以选择性编辑该配置文件然后部署。
    {{< text bash >}}
    $ cat <<EOF | istioctl manifest generate --set values.global.istioNamespace=istio-system -f - > ./istio-egressgateway-with-sni-proxy.yaml
@ -308,7 +302,7 @@ SNI 代理会将流量转发到 `443` 端口。
    EOF
    {{< /text >}}
-1.  部署新的 egress gateway：
+1.  部署新的 egress 网关：
    {{< text bash >}}
    $ kubectl apply -f ./istio-egressgateway-with-sni-proxy.yaml
@ -320,7 +314,7 @@ SNI 代理会将流量转发到 `443` 端口。
    horizontalpodautoscaler "istio-egressgateway-with-sni-proxy" created
    {{< /text >}}
-1.  验证新的 egress gateway 工作正常。请注意，pod 包含两个容器（一个是 Envoy 代理，另一个是 SNI 代理）。
+1.  验证新的 egress 网关正在运行。注意 pod 有两个容器（一个是 Envoy 代理，另一个是 SNI 代理）。
    {{< text bash >}}
    $ kubectl get pod -l istio=egressgateway-with-sni-proxy -n istio-system
@ -328,7 +322,7 @@ SNI 代理会将流量转发到 `443` 端口。
    istio-egressgateway-with-sni-proxy-79f6744569-pf9t2   2/2       Running   0          17s
    {{< /text >}}
-1.  创建一个 service entry，指定静态地址为 127.0.0.1（`localhost`），并对定向到新 service entry 的流量禁用双向 TLS
+1.  创建一个 service entry，静态地址为 127.0.0.1 (`localhost`)，关闭发送至新 service entry 的双向 TLS 请求。
    {{< text bash >}}
    $ kubectl apply -f - <<EOF
@ -360,7 +354,7 @@ SNI 代理会将流量转发到 `443` 端口。
    EOF
    {{< /text >}}
-#### 通过具有 SNI 代理的 egress gateway 配置流量{#configure-traffic-through-egress-gateway-with-server-name-indication-proxy}
+#### 配置流量流经包含 SNI 代理的 egress 网关{#configure-traffic-through-egress-gateway-with-SNI-proxy}
 1.  为 `*.wikipedia.org` 定义一个 `ServiceEntry`：
@ -380,12 +374,13 @@ SNI 代理会将流量转发到 `443` 端口。
    EOF
    {{< /text >}}
-1.   为 _*.wikipedia.org_ 创建一个端口 443，协议为 TLS 的 egress `Gateway`，和一个 virtual service 以将目的为 _*.wikipedia.org_ 的流量定向到 gateway。
+1.  为 _*.wikipedia.org_ 创建一个 egress `Gateway`，端口 443，协议 TLS，以及一个虚拟服务负责引导目标为 _*.wikipedia.org_ 的流量流经网关。
-    选择与您是否要在源 pod 和 egress gateway 之间启用[双向 TLS 认证](/zh/docs/tasks/security/authentication/mutual-tls/)的相应指示。
+    根据您是否希望在源 pod 与 egress 网关之间开启
    [双向 TLS 认证](/zh/docs/tasks/security/authentication/mutual-tls/)，选择指令。
    {{< idea >}}
-    您可能需要启用双向 TLS，以使 egress gateway 监视源 Pod 的身份，并基于该身份启用 Mixer 策略实施。
+    您可能希望开启双向 TLS 以使得 egress 网关得以监控源 pods 的身份标识并基于身份标识信息启用 Mixer 的强制策略。
    {{< /idea >}}
    {{< tabset category-name="mtls" >}}
@ -467,8 +462,8 @@ SNI 代理会将流量转发到 `443` 端口。
              number: 8443
          weight: 100
    ---
-    # 以下过滤器用于转发原始 SNI（由应用程序发送）作为双向 TLS 连接的 SNI。
+    # 下面的 filter 用于将最初的 SNI （应用发送的）转换为双向 TLS 连接的 SNI。
-    # 转发的 SNI 将报告给 Mixer，以便根据原始 SNI 值实施策略。
+    # 转换后的 SNI 将被报告给 Mixer，以基于初始 SNI 的值强制实施策略。
    apiVersion: networking.istio.io/v1alpha3
    kind: EnvoyFilter
    metadata:
@ -482,7 +477,8 @@ SNI 代理会将流量转发到 `443` 端口。
        filterType: NETWORK
        filterConfig: {}
    ---
-    # 以下过滤器验证双向 TLS 连接的 SNI（报告给 Mixer 的 SNI）与应用程序发布的原始 SNI（用于 SNI Proxy 路由的 SNI）相同。该过滤器可防止 Mixer 被恶意应用程序欺骗：在报告其他 SNI 值的同时路由到一个 SNI。如果原始 SNI 与双向 TLS 连接的 SNI 不匹配，则过滤器将阻止与外部服务的连接。
+    # 下面的 filter 验证双向 TLS 连接的 SNI （报告至 Mixer 的 SNI）与应用发起的初始 SNI（SNI 代理进实施路由的 SNI）相同。
    # Filter 阻止 Mixer 被恶意应用欺骗：路由至一个 SNI，而报告其他的 SNI 值。如果初始 SNI 与双向 TLS 连接的 SNI 不匹配，filter 将截断发往外部服务的连接。
    apiVersion: networking.istio.io/v1alpha3
    kind: EnvoyFilter
    metadata:
@ -575,8 +571,8 @@ SNI 代理会将流量转发到 `443` 端口。
    {{< /tabset >}}
-1.  发送 HTTPS 请求到
+1.  发送 HTTPS 请求至
-    [https://en.wikipedia.org](https://en.wikipedia.org) 和 [https://de.wikipedia.org](https://de.wikipedia.org)：
+    [https://en.wikipedia.org](https://en.wikipedia.org) and [https://de.wikipedia.org](https://de.wikipedia.org):
    {{< text bash >}}
    $ kubectl exec -it $SOURCE_POD -c sleep -- sh -c 'curl -s https://en.wikipedia.org/wiki/Main_Page | grep -o "<title>.*</title>"; curl -s https://de.wikipedia.org/wiki/Wikipedia:Hauptseite | grep -o "<title>.*</title>"'
@ -584,20 +580,20 @@ SNI 代理会将流量转发到 `443` 端口。
    <title>Wikipedia – Die freie Enzyklopädie</title>
    {{< /text >}}
-1.  检查 egress gateway 的 Envoy proxy 的日志。如果 Istio 是被部署到  `istio-system` namespace 中，打印日志的命令是：
+1.  检查 Egress 网关 Envoy 代理的日志。如果 Istio 被部署在 `istio-system` 命名空间中，打印日志的命令为：
    {{< text bash >}}
    $ kubectl logs -l istio=egressgateway-with-sni-proxy -c istio-proxy -n istio-system
    {{< /text >}}
-    你会看到几行类似的日志：
+    您将看到类似如下的内容：
    {{< text plain >}}
    [2019-01-02T16:34:23.312Z] "- - -" 0 - 578 79141 624 - "-" "-" "-" "-" "127.0.0.1:8443" outbound|8443||sni-proxy.local 127.0.0.1:55018 172.30.109.84:443 172.30.109.112:45346 en.wikipedia.org
    [2019-01-02T16:34:24.079Z] "- - -" 0 - 586 65770 638 - "-" "-" "-" "-" "127.0.0.1:8443" outbound|8443||sni-proxy.local 127.0.0.1:55034 172.30.109.84:443 172.30.109.112:45362 de.wikipedia.org
    {{< /text >}}
-1.  检查 SNI 代理的日志。如果 Istio 部署在 `istio-system` namespace 中，打印日志的命令为：
+1.  检查 SNI 代理的日志。如果 Istio 被部署在 `istio-system` 命名空间中，打印日志的命令为：
    {{< text bash >}}
    $ kubectl logs -l istio=egressgateway-with-sni-proxy -n istio-system -c sni-proxy
@ -605,16 +601,16 @@ SNI 代理会将流量转发到 `443` 端口。
    127.0.0.1 [01/Aug/2018:15:32:03 +0000] TCP [de.wikipedia.org]200 67745 291 0.659
    {{< /text >}}
-1.  检查 mixer 日志。如果 Istio 部署在 `istio-system` namespace 中，打印日志的命令为：
+1.  检查 mixer 日志。如果 Istio 部署在 `istio-system` 命名空间中，打印日志的命令为：
    {{< text bash >}}
    $ kubectl -n istio-system logs -l istio-mixer-type=telemetry -c mixer | grep '"connectionEvent":"open"' | grep '"sourceName":"istio-egressgateway' | grep 'wikipedia.org'
    {"level":"info","time":"2018-08-26T16:16:34.784571Z","instance":"tcpaccesslog.logentry.istio-system","connectionDuration":"0s","connectionEvent":"open","connection_security_policy":"unknown","destinationApp":"","destinationIp":"127.0.0.1","destinationName":"unknown","destinationNamespace":"default","destinationOwner":"unknown","destinationPrincipal":"cluster.local/ns/istio-system/sa/istio-egressgateway-with-sni-proxy-service-account","destinationServiceHost":"","destinationWorkload":"unknown","protocol":"tcp","receivedBytes":298,"reporter":"source","requestedServerName":"en.wikipedia.org","sentBytes":0,"sourceApp":"istio-egressgateway-with-sni-proxy","sourceIp":"172.30.146.88","sourceName":"istio-egressgateway-with-sni-proxy-7c4f7868fb-rc8pr","sourceNamespace":"istio-system","sourceOwner":"kubernetes://apis/extensions/v1beta1/namespaces/istio-system/deployments/istio-egressgateway-with-sni-proxy","sourcePrincipal":"cluster.local/ns/sleep/sa/default","sourceWorkload":"istio-egressgateway-with-sni-proxy","totalReceivedBytes":298,"totalSentBytes":0}
    {{< /text >}}
-    注意 `requestedServerName` 属性。
+    注意属性 `requestedServerName`。
-#### 清理任意域名的通配符配置{#cleanup-wildcard-configuration-for-arbitrary-domains}
+#### 清除任意域的 wildcard 配置{#cleanup-wildcard-configuration-for-arbitrary-domains}
 1.  删除 _*.wikipedia.org_ 的配置项：
@ -626,7 +622,7 @@ SNI 代理会将流量转发到 `443` 端口。
    $ kubectl delete --ignore-not-found=true envoyfilter forward-downstream-sni egress-gateway-sni-verifier
    {{< /text >}}
-1.  删除 `egressgateway-with-sni-proxy` `Deployment` 的配置项：
+1.  删除部署 `egressgateway-with-sni-proxy` 的配置项：
    {{< text bash >}}
    $ kubectl delete serviceentry sni-proxy
@ -642,9 +638,9 @@ SNI 代理会将流量转发到 `443` 端口。
    $ rm ./sni-proxy.conf
    {{< /text >}}
-## 清理{#cleanup}
+## 清除{#cleanup}
-关闭 [sleep]({{<github_tree>}}/samples/sleep) service：
+关闭服务 [sleep]({{< github_tree >}}/samples/sleep)：
 {{< text bash >}}
 $ kubectl delete -f @samples/sleep/sleep.yaml@