[zh] fix typo in `docs/ops` (#14102)

Signed-off-by: guiyong.ou <guiyong.ou@daocloud.io>

content/zh/docs/ops/common-problems/observability-issues/index.md

@@ -47,7 +47,7 @@ Kubernetes 集群内的时间同步服务是否正确运行，以及 Web 客户
 Istio CNI 插件在 Kubernetes Pod 生命周期中的网络配置阶段执行 Istio
 网格 Pod 流量重定向，从而消除了用户将 Pod 部署到 Istio 网格中的
 [`NET_ADMIN` 和 `NET_RAW` 的需求](/zh/docs/ops/deployment/requirements/)。
-Istio CNI 插件取代了 `Istio-init` 容器提供的功能。
+Istio CNI 插件取代了 `istio-init` 容器提供的功能。
 
 1. 验证 `istio-cni-node` Pod 正在运行：
 

content/zh/docs/ops/common-problems/validation/index.md

@@ -103,7 +103,7 @@ webhooks:
 Istio 有意识地使用 `istio-validation` `configmap` 和根证书，调整了
 webhook 配置。
 
-1. 验证 `istio-pilot` Pod 是否在运行：
+1. 验证 `istiod` Pod 是否在运行：
 
     {{< text bash >}}
     $  kubectl -n istio-system get pod -lapp=istiod

content/zh/docs/ops/configuration/traffic-management/dns/index.md

@@ -54,7 +54,7 @@ Istio 的高级[负载均衡能力](/zh/docs/concepts/traffic-management/#load-b
   和[无头服务](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#headless-services)。
 * 在一组静态 IP 地址上进行负载均衡。这种情况适用于 `resolution: STATIC`
   类型的 `ServiceEntry`，这将使用 `spec.endpoints` 中的所有地址，
-  或者对于标准 `Service` 将使用其所有 `Endpoint` 地址。
+  或者对于标准 `Services` 将使用其所有 `Endpoints` 地址。
 * 使用 DNS 定期解析地址，并在所有结果中进行负载均衡。这种情况适用于
   `resolution: DNS` 类型的 `ServiceEntry`。
 
@@ -75,7 +75,7 @@ Istio 代理从不执行同步 DNS 请求。配置 `resolution: DNS`
 的网格而言，尤其是在使用较低 `TTL` 时，可能会导致 DNS 服务器的负载很高。
 在这些情况下，以下行为有助于减轻负载：
 
-* 将 `ServiceEntry` 切换为 `resolution: NONE` 类型以完全避免代理 DNS 查找，
+* 将 `ServiceEntries` 切换为 `resolution: NONE` 类型以完全避免代理 DNS 查找，
   这适用于许多使用场景。
 * 如果您可以控制正在解析的域，请适当增加它们的 TTL。
 * 如果您的 `ServiceEntry` 只有少量工作负载，请使用 `exportTo`
@@ -85,7 +85,7 @@ Istio 代理从不执行同步 DNS 请求。配置 `resolution: DNS`
 
 Istio 提供了[代理 DNS 请求](/zh/docs/ops/configuration/traffic-management/dns-proxy/)的功能。
 这允许 Istio 捕获客户端发送的 DNS 请求并直接返回响应。这可以改善 DNS 延迟，
-减少负载，并解决了 `ServiceEntry` 无法通过 `kube-dns` 解析的问题。
+减少负载，并解决了 `ServiceEntries` 无法通过 `kube-dns` 解析的问题。
 
 请注意，此代理仅适用于用户应用程序发送的 DNS 请求；当使用 `resolution: DNS`
-类型的 `ServiceEntry` 时，DNS 代理对 Istio 代理的 DNS 解析没有影响。
+类型的 `ServiceEntries` 时，DNS 代理对 Istio 代理的 DNS 解析没有影响。

content/zh/docs/ops/diagnostic-tools/istioctl-analyze/index.md

@@ -87,7 +87,7 @@ $ istioctl analyze --use-kube=false samples/bookinfo/networking/*.yaml
 
 从 Istio 1.5 开始，可以通过 `istiod.enableAnalysis` 标志将 Galley
 设置为与其主要负责的配置分发一起执行配置分析。
-此分析使用与 `istioctl analysis` 相同的逻辑和错误消息。
+此分析使用与 `istioctl analyze` 相同的逻辑和错误消息。
 来自分析的验证消息被写入受影响的 Istio 资源的状态子资源。
 
 例如：如果您的 "ratings" VirtualService 上网关配置错误，运行
@@ -113,11 +113,11 @@ status:
 {{< /text >}}
 
 `enableAnalysis` 在后台运行，并将保持资源的状态字段与其当前验证状态保持同步。
-请注意，这不是`istioctl analysis`的替代品：
+请注意，这不是`istioctl analyze` 的替代品：
 
 - 并非所有资源都有自定义状态字段（例如 Kubernetes `namespace` 资源），
   因此附加到这些资源的消息不会显示验证消息。
-- `enableAnalysis` 仅适用于从 1.5 开始的 Istio 版本，而 `istioctl analysis`
+- `enableAnalysis` 仅适用于从 1.5 开始的 Istio 版本，而 `istioctl analyze`
   可用于旧版本。
 - 虽然可以轻松查看特定资源的问题，但很难全面了解网格中的验证状态。
 
@@ -138,7 +138,7 @@ Info [IST0102] (Namespace frod) The namespace is not enabled for Istio injection
 {{< /text >}}
 
 由于您无权更新命名空间，因此无法通过注解命名空间来解析消息。相反，
-您可以使用 `istioctl analysis` 来抑制资源上的上述消息：
+您可以使用 `istioctl analyze` 来抑制资源上的上述消息：
 
 {{< text syntax=bash snip_id=analyze_suppress0102 >}}
 $ istioctl analyze -k --namespace frod --suppress "IST0102=Namespace frod"
@@ -157,7 +157,7 @@ $ istioctl analyze -k --all-namespaces --suppress "IST0102=Namespace frod" --sup
 ### 通过注解忽略特定的分析器消息 {#ignoring-specific-analyzer-messages-via-annotations}
 
 您也可以使用资源上的注解忽略特定的分析器消息。例如，要忽略资源
-`deployment/my deployment` 上的代码IST0107（`MisplacedAnnotation`）：
+`deployment/my-deployment` 上的代码IST0107（`MisplacedAnnotation`）：
 
 {{< text syntax=bash snip_id=annotate_for_deployment_suppression >}}
 $ kubectl annotate deployment my-deployment galley.istio.io/analyze-suppress=IST0107

content/zh/docs/ops/diagnostic-tools/istioctl-describe/index.md

@@ -179,7 +179,7 @@ $ kubectl apply -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
 ## 验证流量路由{#verifying-traffic-routes}
 
 `istioctl describe` 命令还可以展示流量的分隔权重。
-例如，运行如下命令将 90% 的流量路由到 `revis` 服务的 `v1` 子集，将
+例如，运行如下命令将 90% 的流量路由到 `reviews` 服务的 `v1` 子集，将
 10% 路由到 `v2` 子集：
 
 {{< text bash >}}

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

@@ -95,9 +95,9 @@ istiod.istio-system.svc.cluster.local   15014     -       outbound      EDS
 
 ## 自动注册 {#automatic-registration}
 
-当虚拟机连接到 Istiod 时，会自动创建一个 `workloadEntry`。
+当虚拟机连接到 Istiod 时，会自动创建一个 `WorkloadEntry`。
-这使得虚拟机成为 `service` 的一部分，类似于 Kubernetes
+这使得虚拟机成为 `Service` 的一部分，类似于 Kubernetes
-中的 `endpoint`。
+中的 `Endpoint`。
 
 检查这些配置是否正确创建:
 

content/zh/docs/ops/integrations/jaeger/index.md

@@ -28,7 +28,7 @@ $ kubectl apply -f {{< github_file >}}/samples/addons/jaeger.yaml
 Jaeger 与 Istio 一起使用时无需特殊的配置。
 
 安装 Jaeger 完毕后，需要指定 Istio 代理向 Deployment 发送流量。
-在安装时，可以使用 `--set values.global.tracer.zipkin.address=<jaeger-collector-address>:9411`
+在安装时，可以使用 `--set meshConfig.defaultConfig.tracing.zipkin.address=<jaeger-collector-address>:9411`
 进行配置。参考更多 [`ProxyConfig.Tracing`](/zh/docs/reference/config/istio.mesh.v1alpha1/#Tracing)
 高级配置，如 TLS 设置。
 

content/zh/docs/ops/integrations/prometheus/index.md

@@ -78,7 +78,7 @@ Chart 提供的配置。
 
 * 您需要使用 TLS 收集指标。
 * 您的应用程序暴露的指标与 Istio 暴露的指标重名。例如，
-  您的应用程序暴露一个叫做 `istio_request_total` 的指标。
+  您的应用程序暴露一个叫做 `istio_requests_total` 的指标。
   如果应用程序本身正在运行 Envoy，这就有可能发生。
 * 您的 Prometheus Deployment 没有配置通过 `prometheus.io` 注解抓取指标。