update typo (#13678)

content/zh/about/faq/setup/install-method-selection.md

@@ -24,11 +24,11 @@ weight: 10
 
 1. [使用 Istio Operator 安装](/zh/docs/setup/install/operator/)
 
-    没有 `istioctl` 二进制文件的简单安安装方式。这是推荐的方法。用于简单升级工作，无需考虑运行集群内的高权限 Controller。
+    没有 `istioctl` 二进制文件的简单安装方式。这是推荐的方法。用于简单升级工作，无需考虑运行集群内的高权限 Controller。
 
     优点:
 
-    - 具有与 `istioctl install` 相同的 API ，但是通过据群众具有高权限的 Controller Pod 通过完全声明的方式进行操作。
+    - 具有与 `istioctl install` 相同的 API ，但是通过集群中具有高权限的 Controller Pod 通过完全声明的方式进行操作。
     - 使用提供了扩展的配置、自定义选项的 `IstioOperator` API。
     - 不需要管理多个 `istioctl` 的二进制文件。
 

content/zh/blog/2017/0.1-using-network-policy/index.md

@@ -37,10 +37,10 @@ Istio 的代理基于 [`Envoy`](https://envoyproxy.github.io/envoy/)，它作为
 
 Envoy 代理的策略执行是在 pod 中，作为同一网络命名空间中的 sidecar 容器。这使得部署模型简单。某些容器赋予权限可以重新配置其 pod 中的网络（`CAP_NET_ADMIN`）。如果此类服务实例绕过代理受到损害或行为不当（如：在恶意租户中）。
 
-虽然这不会让攻击者访问其他启用了 Istio 的 pod ，但通过配置，会打开几种攻击：
+虽然这不会让攻击者访问其他启用了 Istio 的 Pod，但通过配置，会打开几种攻击：
 
-- 攻击未受保护的 pods
-- 尝试通过发送大量流量为受保护的 pods 造成访问拒绝
+- 攻击未受保护的 Pod
+- 尝试通过发送大量流量为受保护的 Pod 造成访问拒绝
 - 在 pod 中收集的漏出数据
 - 攻击集群基础设施（服务器或 Kubernetes 服务）
 - 攻击网格外的服务，如数据库，存储阵列或遗留系统。

content/zh/docs/concepts/security/index.md

@@ -832,8 +832,8 @@ Istio 使用双向 TLS 将某些信息从客户端安全地传递到服务器。
 - `source.principal` 自定义条件
 - `source.namespace` 自定义条件
 
-请注意，强烈建议始终在 PeerAuthentication 中以 STRICT 双向 TLS 模式使用这些字段，
-以避免在 PERMISSIVE 双向 TLS 模式中使用纯文本流量时可能出现的意外请求拒绝或绕过安全策略。
+请注意，强烈建议始终在 `PeerAuthentication` 中以 `STRICT` 双向 TLS 模式使用这些字段，
+以避免在 `PERMISSIVE` 双向 TLS 模式中使用纯文本流量时可能出现的意外请求拒绝或绕过安全策略。
 
 如果您无法启用严格的双向 TLS 模式，
 请查看[安全公告](/zh/news/security/istio-security-2021-004)以获取更多详细信息和替代方案。

content/zh/docs/concepts/traffic-management/index.md

@@ -60,7 +60,7 @@ YAML 进行配置。
 - [服务入口](#service-entries)
 - [Sidecar](#sidecars)
 
-指南也对构建在 API 资源内的[网络弹性和测试](#network-resilience-and-testing)做了概述。
+指南也对 API 资源内构建的[网络弹性和测试](#network-resilience-and-testing)做了概述。
 
 ## 虚拟服务 {#virtual-services}
 
@@ -73,7 +73,7 @@ YAML 进行配置。
 ### 为什么使用虚拟服务？ {#why-use-virtual-services}
 
 虚拟服务在增强 Istio 流量管理的灵活性和有效性方面，发挥着至关重要的作用，
-通过对客户端请求的目标地址与真实响应请求的目标工作负载进行解耦来实现。
+实现方式是解耦客户端请求的目标地址与实际响应请求的目标工作负载。
 虚拟服务同时提供了丰富的方式，为发送至这些工作负载的流量指定不同的路由规则。
 
 为什么这如此有用？就像在介绍中所说，如果没有虚拟服务，
@@ -147,7 +147,7 @@ hosts:
 
 虚拟服务主机名可以是 IP 地址、DNS 名称，或者依赖于平台的一个简称（例如 Kubernetes
 服务的短名称），隐式或显式地指向一个完全限定域名（FQDN）。您也可以使用通配符（“\*”）前缀，
-让您创建一组匹配所有服务的路由规则。虚拟服务的 `hosts` 字段实际上不必是 Istio
+创建一组匹配所有服务的路由规则。虚拟服务的 `hosts` 字段实际上不必是 Istio
 服务注册的一部分，它只是虚拟的目标地址。这让您可以为没有路由到网格内部的虚拟主机建模。
 
 #### 路由规则 {#routing-rules}
@@ -414,7 +414,7 @@ spec:
 来添加一个入口到 Istio 内部维护的服务注册中心。添加了服务入口后，Envoy 代理可以向服务发送流量，
 就好像它是网格内部的服务一样。配置服务入口允许您管理运行在网格外的服务的流量，它包括以下几种能力：
 
--   为外部目标重定向和转发请求，例如来自 web 端的 API 调用，或者流向遗留老系统的服务。
+-   为外部目标重定向和转发请求，例如来自 Web 端的 API 调用，或者流向遗留老系统的服务。
 -   为外部目标定义[重试](#retries)、[超时](#timeouts)和[故障注入](#fault-injection)策略。
 -   添加一个运行在虚拟机的服务来[扩展您的网格](/zh/docs/examples/virtual-machines/single-network/#running-services-on-the-added-VM)。
 
@@ -479,7 +479,7 @@ spec:
 您可以指定将 Sidecar 配置应用于特定命名空间中的所有工作负载，或者使用
 `workloadSelector` 选择特定的工作负载。例如，下面的 Sidecar 配置将
 `bookinfo` 命名空间中的所有服务配置为仅能访问运行在相同命名空间和 Istio
-控制平面中的服务（Istio 的egress和遥测功能需要使用）：
+控制平面中的服务（Istio 的 Egress 和遥测功能需要使用）：
 
 {{< text yaml >}}
 apiVersion: networking.istio.io/v1alpha3
@@ -509,7 +509,7 @@ spec:
 这意味着如果服务在 15 秒内没有响应，调用将失败。
 
 对于某些应用程序和服务，Istio 的缺省超时可能不合适。例如，超时太长可能会由于等待失败服务的回复而导致过度的延迟；
-而超时过短则可能在等待涉及多个服务返回的操作时触发不必要地失败。为了找到并使用最佳超时设置，
+而超时过短则可能在等待涉及多个服务返回的操作时触发不必要的失败。为了找到并使用最佳超时设置，
 Istio 允许您使用[虚拟服务](#virtual-services)按服务轻松地动态调整超时，而不必修改您的业务代码。
 下面的示例是一个虚拟服务，它对 ratings 服务的 v1 子集的调用指定 10 秒超时：
 

content/zh/docs/ops/best-practices/observability/index.md

@@ -147,7 +147,7 @@ spec:
 {{< /tabset >}}
 
 {{< tip >}}
-以上的记录规则只是同聚合得到 pods 以及实例级别的指标。这仍然完整的保留了
+以上的记录规则只是同聚合得到 Pod 以及实例级别的指标。这仍然完整的保留了
 [Istio 标准指标](/zh/docs/reference/config/metrics/)中的全部项，包括全部的 Istio 维度。
 尽管这有助于通过联邦控制指标维度，您可能仍想进一步优化记录规则来匹配您现有的仪表盘、告警以及特定的引用。
 

content/zh/docs/reference/config/analysis/ist0144/index.md

@@ -5,7 +5,7 @@ owner: istio/wg-user-experience-maintainers
 test: n/a
 ---
 
-当工作负载以 User ID (UID) `1337` 运行时，会出现此消息。应用程序的 Pods 不应该以 User ID (UID) `1337` 运行，因为 istio-proxy 容器默认以 UID `1337` 运行。当使用相同的 UID 运行您的容器应用时，将导致它的 `iptables` 配置冲突。
+当工作负载以 User ID (UID) `1337` 运行时，会出现此消息。应用程序的 Pod 不应该以 User ID (UID) `1337` 运行，因为 istio-proxy 容器默认以 UID `1337` 运行。当使用相同的 UID 运行您的容器应用时，将导致它的 `iptables` 配置冲突。
 
 {{< warning >}}
 User ID (UID) `1337` 为 Sidecar Proxy 保留。

content/zh/docs/releases/contribute/style-guide/index.md

@@ -47,9 +47,9 @@ front-matter 中 `title:` 字段的文本必须使用首字母大小写。即：
 
 | 正确做法                          | 错误做法
 |----------------------------|------
-|创建 `ReplicaSet`, ... | 为了要创建 `ReplicaSet`, ...
+|创建 `ReplicaSet`，... | 为了要创建 `ReplicaSet`，...
 |参见配置文件。 | 请参见配置文件。
-|查看 Pods。              | 通过下一个命令，可查看 Pods。
+|查看 Pod。              | 通过下一个命令，可查看 Pod。
 
 ## 使用“您”称呼读者{#address-the-reader-as-you}
 

content/zh/news/releases/1.12.x/announcing-1.12/change-notes/index.md

@@ -151,7 +151,7 @@ aliases:
 - **修复** 修复了 `istioctl admin log` 格式。
   ([Issue #34982](https://github.com/istio/istio/issues/34982))
 
-- **修复了** 修复了在第一次安装 Istio 时没有使用 'istio-system' 作为 Istio 命名空间，APP pods（比如 httpbin）无法创建的问题。`istioctl install`，`istioctl tag set` 和 `istioctl tag generate` 将受到影响。例如，用户可以设置指定的命名空间（以 `mesh-1` 为例），通过 `istioctl install --set profile=demo --set values.global.istioNamespace=mesh-1 -y` 来安装 Istio。
+- **修复了** 修复了在第一次安装 Istio 时没有使用 'istio-system' 作为 Istio 命名空间，APP Pod（比如 httpbin）无法创建的问题。`istioctl install`，`istioctl tag set` 和 `istioctl tag generate` 将受到影响。例如，用户可以设置指定的命名空间（以 `mesh-1` 为例），通过 `istioctl install --set profile=demo --set values.global.istioNamespace=mesh-1 -y` 来安装 Istio。
   ([Issue #35539](https://github.com/istio/istio/issues/35539))
 
 - **修复** 修复了当 `--exclude` 没有设置时，`istioctl bug-report` 会显示额外的默认系统命名空间的问题。