[zh-cn] improve proxy-cmd virtual-machines (#13292)

Signed-off-by: xin.li <xin.li@daocloud.io>

content/zh/docs/ops/diagnostic-tools/proxy-cmd/index.md

@@ -11,7 +11,11 @@ owner: istio/wg-user-experience-maintainers
 test: no
 ---
 
-Istio 提供了两个非常有价值的命令来帮助诊断流量管理配置相关的问题，[`proxy-status`](/zh/docs/reference/commands/istioctl/#istioctl-proxy-status) 和 [`proxy-config`](/zh/docs/reference/commands/istioctl/#istioctl-proxy-config) 命令。`proxy-status` 命令容许您获取网格的概况，并识别出导致问题的代理。`proxy-config` 可以被用于检查 Envoy 配置和诊断问题。
+Istio 提供了两个非常有价值的命令来帮助诊断流量管理配置相关的问题，
+[`proxy-status`](/zh/docs/reference/commands/istioctl/#istioctl-proxy-status)
+和 [`proxy-config`](/zh/docs/reference/commands/istioctl/#istioctl-proxy-config)
+命令。`proxy-status` 命令容许您获取网格的概况，并识别出导致问题的代理。
+`proxy-config` 可以被用于检查 Envoy 配置和诊断问题。
 
 如果您想尝试以下的命令，需要：
 
@@ -25,7 +29,8 @@ Istio 提供了两个非常有价值的命令来帮助诊断流量管理配置
 
 ## 获取网格概况{#get-an-overview-of-your-mesh}
 
-`proxy-status` 命令容许您获取网格的概况。如果您怀疑某一个 sidecar 没有接收到配置或配置不同步时，`proxy-status` 将告诉您原因。
+`proxy-status` 命令容许您获取网格的概况。如果您怀疑某一个 Sidecar
+没有接收到配置或配置不同步时，`proxy-status` 将告诉您原因。
 
 {{< text bash >}}
 $ istioctl proxy-status
@@ -42,13 +47,18 @@ reviews-v3-7dbcdcbc56-t8wrx.default                    SYNCED     SYNCED     SYN
 
 如果列表中缺少代理，这意味着它目前没有连接到 Istiod 实例，因此不会接收任何配置。
 
-* `SYNCED` 意思是 Envoy 知晓了 {{< gloss >}}Istiod{{< /gloss >}} 已经将最新的配置发送给了它。
-* `NOT SENT` 意思是 Istiod 没有发送任何信息给 Envoy。这通常是因为 Istiod 没什么可发送的。
-* `STALE` 意思是 Istiod 已经发送了一个更新到 Envoy，但还没有收到应答。这通常意味着 Envoy 和 Istiod 之间存在网络问题，或者 Istio 自身的 bug。
+* `SYNCED` 意思是 Envoy 知晓了 {{< gloss >}}Istiod{{< /gloss >}}
+  已经将最新的配置发送给了它。
+* `NOT SENT` 意思是 Istiod 没有发送任何信息给 Envoy。这通常是因为
+  Istiod 没什么可发送的。
+* `STALE` 意思是 Istiod 已经发送了一个更新到 Envoy，但还没有收到应答。
+  这通常意味着 Envoy 和 Istiod 之间存在网络问题，或者 Istio 自身的 bug。
 
-## 检查 Envoy 和 Istiod 的差异{#retrieve-diffs-between-envoy-and-Istiod}
+## 检查 Envoy 和 Istiod 的差异 {#retrieve-diffs-between-envoy-and-Istiod}
 
-通过提供代理 ID，`proxy-status` 命令还可以用来检查 Envoy 已加载的配置和 Istiod 发送给它的配置有什么异同，这可以帮您准确定位哪些配置是不同步的，以及问题出在哪里。
+通过提供代理 ID，`proxy-status` 命令还可以用来检查 Envoy
+已加载的配置和 Istiod 发送给它的配置有什么异同，这可以帮您准确定位哪些配置是不同步的，
+以及问题出在哪里。
 
 {{< text bash json >}}
 $ istioctl proxy-status details-v1-6dcc6fbb9d-wsjz4.default
@@ -98,9 +108,11 @@ Routes Match (RDS last loaded at Tue, 04 Aug 2020 11:52:54 IST)
 
 从这儿可以看到，监听器和路由是匹配的，但集群不同步。
 
-## 深入 Envoy 配置{#deep-dive-into-envoy-configuration}
+## 深入 Envoy 配置 {#deep-dive-into-envoy-configuration}
 
-`proxy-config` 命令可以用来查看给定的 Envoy 是如何配置的。这样就可以通过 Istio 配置和自定义资源来查明任何您无法检测到的问题。下面的命令为给定 Pod 提供了集群、监听器或路由的基本概要（当需要时可以为监听器或路由改变集群）：
+`proxy-config` 命令可以用来查看给定的 Envoy 是如何配置的。
+这样就可以通过 Istio 配置和自定义资源来查明任何您无法检测到的问题。
+下面的命令为给定 Pod 提供了集群、监听器或路由的基本概要（当需要时可以为监听器或路由改变集群）：
 
 {{< text bash >}}
 $ istioctl proxy-config cluster -n istio-system istio-ingressgateway-7d6874b48f-qxhn5
@@ -130,7 +142,10 @@ xds-grpc                                                                   -
 zipkin                                                                     -         -          -             STRICT_DNS
 {{< /text >}}
 
-为了调试 Envoy 您需要理解 Envoy 集群、监听器、路由、endpoints 以及它们是如何交互的。我们将使用带有 `-o json` 参数的 `proxy-config` 命令，根据标志过滤出并跟随特定的 Envoy，它将请求从 `productpage` pod 发送到 `reviews` pod 9080 端口。
+为了调试 Envoy 您需要理解 Envoy 集群、监听器、路由、endpoints
+以及它们是如何交互的。我们将使用带有 `-o json` 参数的 `proxy-config`
+命令，根据标志过滤出并跟随特定的 Envoy，它将请求从 `productpage` Pod
+发送到 `reviews` Pod 9080 端口。
 
 1. 如果您在一个 Pod 上查询监听器概要信息，您将注意到 Istio 生成了下面的监听器：
     * `0.0.0.0:15001` 监听器接收所有进出 Pod 的流量，然后转发请求给一个虚拟监听器。
@@ -175,7 +190,10 @@ zipkin                                                                     -
     10.111.121.13 15443 ALL                                              Cluster: outbound|15443||istio-ingressgateway.istio-system.svc.cluster.local
     {{< /text >}}
 
-1. 从上面的信息可以看到，每一个 sidecar 有一个绑定到 `0.0.0.0:15001` 的监听器，来确定 IP 表将所有进出 Pod 的流量路由到哪里。监听器设置 `useOriginalDst` 为 true 意味着它将请求传递给最适合原始请求目的地的监听器。如果找不到匹配的虚拟监听器，它会将请求发送到直接连接到目的地的 `PassthroughCluster`。
+1. 从上面的信息可以看到，每一个 Sidecar 有一个绑定到 `0.0.0.0:15001`
+   的监听器，来确定 IP 表将所有进出 Pod 的流量路由到哪里。监听器设置
+   `useOriginalDst` 为 true 意味着它将请求传递给最适合原始请求目的地的监听器。
+   如果找不到匹配的虚拟监听器，它会将请求发送到直接连接到目的地的 `PassthroughCluster`。
 
      {{< text bash json >}}
     $ istioctl proxy-config listeners productpage-v1-6c886ff494-7vxhs --port 15001 -o json
@@ -231,7 +249,9 @@ zipkin                                                                     -
     ]
     {{< /text >}}
 
-1. 我们的请求是到端口 `9080` 的出站 HTTP 请求，它将被传递给 `0.0.0.0:9080` 的虚拟监听器。这一监听器将检索在它配置的 RDS 里的路由配置。在这个例子中它将寻找 Istiod（通过 ADS）配置在 RDS 中的路由 `9080`。
+1. 我们的请求是到端口 `9080` 的出站 HTTP 请求，它将被传递给 `0.0.0.0:9080`
+   的虚拟监听器。这一监听器将检索在它配置的 RDS 里的路由配置。
+   在这个例子中它将寻找 Istiod（通过 ADS）配置在 RDS 中的路由 `9080`。
 
     {{< text bash json >}}
     $ istioctl proxy-config listeners productpage-v1-6c886ff494-7vxhs -o json --address 0.0.0.0 --port 9080
@@ -245,7 +265,11 @@ zipkin                                                                     -
     ...
     {{< /text >}}
 
-1. 对每个服务，`9080` 路由配置只有一个虚拟主机。我们的请求会走到 reviews 服务，因此 Envoy 将选择一个虚拟主机把请求匹配到一个域。一旦匹配到，Envoy 会寻找请求匹配到的第一个路由。本例中我们没有设置任何高级路由规则，因此路由会匹配任何请求。这一路由告诉 Envoy 发送请求到 `outbound|9080||reviews.default.svc.cluster.local` 集群。
+1. 对每个服务，`9080` 路由配置只有一个虚拟主机。我们的请求会走到 reviews
+   服务，因此 Envoy 将选择一个虚拟主机把请求匹配到一个域。一旦匹配到，
+   Envoy 会寻找请求匹配到的第一个路由。本例中我们没有设置任何高级路由规则，
+   因此路由会匹配任何请求。这一路由告诉 Envoy 发送请求到
+   `outbound|9080||reviews.default.svc.cluster.local` 集群。
 
     {{< text bash json >}}
     $ istioctl proxy-config routes productpage-v1-6c886ff494-7vxhs --name 9080 -o json
@@ -284,7 +308,9 @@ zipkin                                                                     -
     ...
     {{< /text >}}
 
-1. 此集群配置为从 Istiod（通过 ADS）检索关联的 endpoints。所以 Envoy 会使用 `serviceName` 字段作为主键，来检查 endpoint 列表并把请求代理到其中之一。
+1. 此集群配置为从 Istiod（通过 ADS）检索关联的 endpoints。
+   所以 Envoy 会使用 `serviceName` 字段作为主键，来检查
+   endpoint 列表并把请求代理到其中之一。
 
     {{< text bash json >}}
     $ istioctl proxy-config cluster productpage-v1-6c886ff494-7vxhs --fqdn reviews.default.svc.cluster.local -o json
@@ -324,9 +350,11 @@ zipkin                                                                     -
     172.17.0.9:9080     HEALTHY     OK                outbound|9080||reviews.default.svc.cluster.local
     {{< /text >}}
 
-## 检查 bootstrap 配置{#inspecting-bootstrap-configuration}
+## 检查 bootstrap 配置 {#inspecting-bootstrap-configuration}
 
-到目前为止，我们已经查看了从 Istiod 检索到的配置（大部分），然而 Envoy 需要一些 bootstrap 配置，其中包括诸如在何处可以找到 Istiod 之类的信息。使用下面的命令查看：
+到目前为止，我们已经查看了从 Istiod 检索到的配置（大部分），
+然而 Envoy 需要一些 bootstrap 配置，其中包括诸如在何处可以找到
+Istiod 之类的信息。使用下面的命令查看：
 
 {{< text bash json >}}
 $ istioctl proxy-config bootstrap -n istio-system istio-ingressgateway-7d6874b48f-qxhn5
@@ -376,9 +404,11 @@ $ istioctl proxy-config bootstrap -n istio-system istio-ingressgateway-7d6874b48
 ...
 {{< /text >}}
 
-## 验证到 Istiod 的连通性{#verifying-connectivity-to-Istiod}
+## 验证到 Istiod 的连通性 {#verifying-connectivity-to-Istiod}
 
-验证与 Istiod 的连通性是一个有用的故障排除步骤。服务网格内的每个代理容器都应该能和 Istiod 通信。这可以通过几个简单的步骤来实现：
+验证与 Istiod 的连通性是一个有用的故障排除步骤。
+服务网格内的每个代理容器都应该能和 Istiod 通信。
+这可以通过几个简单的步骤来实现：
 
 1. 创建一个 `sleep` pod：
 

content/zh/docs/ops/diagnostic-tools/virtual-machines/index.md

@@ -11,25 +11,28 @@ test: n/a
 在此之前，请确保您已经按照[虚拟机安装](/zh/docs/setup/install/virtual-machine/)指南完成了相应操作。
 此外阅读[虚拟机体系架构](/zh/docs/ops/deployment/vm-architecture/)可以帮助您更好的了解组件间是如何交互的。
 
-对 Istio 部署至虚拟机进行故障排除跟对 Kubernetes 内运行的代理问题进行故障排除是类似的，但还是有一些关键点需要注意。
+对 Istio 部署至虚拟机进行故障排除跟对 Kubernetes
+内运行的代理问题进行故障排除是类似的，但还是有一些关键点需要注意。
 
 虽然在两个平台上都可以获得许多相同的信息，但对这些信息的访问是不同的。
 
-## 健康检查{#monitoring-health}
+## 健康检查 {#monitoring-health}
 
-Istio sidecar 通常作为一个 `systemd` 服务(unit)运行。您可以检查其状态来确保运行正常：
+Istio Sidecar 通常作为一个 `systemd` 服务（unit）运行。
+您可以检查其状态来确保运行正常：
 
 {{< text bash >}}
 $ systemctl status istio
 {{< /text  >}}
 
-除此之外您还可以在端点(endpoint)侧以编程的方式检查来 sidecar 的运行情况：
+除此之外您还可以在端点（endpoint）侧以编程的方式检查来 Sidecar
+的运行情况：
 
 {{< text bash >}}
 $ curl localhost:15021/healthz/ready -I
 {{< /text  >}}
 
-## 日志{#logs}
+## 日志 {#logs}
 
 Istio 代理的日志可以在以下地方找到。
 
@@ -39,21 +42,23 @@ Istio 代理的日志可以在以下地方找到。
 $ journalctl -f -u istio -n 1000
 {{< /text  >}}
 
-代理会将 `stderr` 日志和 `stdout` 日志分别重定向到 `/var/log/istio/istio.err.log` 和  `/var/log/istio/istio.log`。
-你可以以类似于 `kubectl` 的格式查看这些内容：
+代理会将 `stderr` 日志和 `stdout` 日志分别重定向到
+`/var/log/istio/istio.err.log` 和  `/var/log/istio/istio.log`。
+您可以以类似于 `kubectl` 的格式查看这些内容：
 
 {{< text bash >}}
 $ tail /var/log/istio/istio.err.log /var/log/istio/istio.log -Fq -n 100
 {{< /text  >}}
 
-修改配置文件 `cluster.env` 可以调整日志级别。如果 `istio` 已经在运行，请务必重新启动服务：
+修改配置文件 `cluster.env` 可以调整日志级别。如果 `istio`
+已经在运行，请务必重新启动服务：
 
 {{< text bash >}}
 $ echo "ISTIO_AGENT_FLAGS=\"--log_output_level=dns:debug --proxyLogLevel=debug\"" >> /var/lib/istio/envoy/cluster.env
 $ systemctl restart istio
 {{< /text  >}}
 
-## Iptables{#iptables}
+## Iptables {#iptables}
 
 确保 `iptables` 规则已经生效：
 
@@ -64,9 +69,10 @@ $ sudo iptables-save
 -A ISTIO_OUTPUT -j ISTIO_REDIRECT
 {{< /text  >}}
 
-## Istioctl{#istioctl}
+## Istioctl {#istioctl}
 
-绝大部分 `istioctl` 指令能在虚拟机中正常运行。例如利用 `istioctl proxy-status` 指令查看所有已连接的代理：
+绝大部分 `istioctl` 指令能在虚拟机中正常运行。例如利用
+`istioctl proxy-status` 指令查看所有已连接的代理：
 
 {{< text bash >}}
 $ istioctl proxy-status
@@ -74,8 +80,9 @@ NAME           CDS        LDS        EDS        RDS      ISTIOD
 vm-1.default   SYNCED     SYNCED     SYNCED     SYNCED   istiod-789ffff8-f2fkt     {{< istio_full_version >}}
 {{< /text  >}}
 
-然而由于 `istioctl proxy-config` 依赖于 Kubernetes 中的连接代理的功能，因此这对条指令无法在虚拟机环境工作。
-不过我们可以传递一个包含 Envoy 配置的文件来替代，举例：
+然而由于 `istioctl proxy-config` 依赖于 Kubernetes
+中的连接代理的功能，因此这对条指令无法在虚拟机环境工作。
+不过我们可以传递一个包含 Envoy 配置的文件来替代，例如：
 
 {{< text bash >}}
 $ curl -s localhost:15000/config_dump | istioctl proxy-config clusters --file -
@@ -86,9 +93,11 @@ istiod.istio-system.svc.cluster.local   15012     -       outbound      EDS
 istiod.istio-system.svc.cluster.local   15014     -       outbound      EDS
 {{< /text  >}}
 
-## 自动注册{#automatic-registration}
+## 自动注册 {#automatic-registration}
 
-当虚拟机连接到 Istiod 时，会自动创建一个 `workloadEntry`。 这使得虚拟机成为 `service` 的一部分，类似于 Kubernetes 中的 `endpoint`。
+当虚拟机连接到 Istiod 时，会自动创建一个 `workloadEntry`。
+这使得虚拟机成为 `service` 的一部分，类似于 Kubernetes
+中的 `endpoint`。
 
 检查这些配置是否正确创建:
 
@@ -100,7 +109,9 @@ vm-10.128.0.50   14m   10.128.0.50
 
 ## 证书{#certificates}
 
-虚拟机处理证书的方式与 Kubernetes Pods 不同，Kubernetes Pods 使用 Kubernetes 提供的 SA 令牌来(service account token)来验证和续订 mTLS 证书。虚拟机则是使用现有的 mTLS 凭据向证书颁发机构进行身份验证并续订证书。
+虚拟机处理证书的方式与 Kubernetes Pod 不同，Kubernetes Pod
+使用 Kubernetes 提供的 SA 令牌来（service account token）来验证和续订
+mTLS 证书。虚拟机则是使用现有的 mTLS 凭据向证书颁发机构进行身份验证并续订证书。
 
 可以使用与 Kubernetes 相同的方式查看这些证书的状态：