istio
/
istio.io
mirror of https://github.com/istio/istio.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

zh-translation: format for content/zh (#6910) 

x


x
This commit is contained in:
2BFL 2020-03-19 12:07:36 +08:00 committed by GitHub
parent d8a91d037a
commit cf6cb27e44
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
161 changed files with 784 additions and 784 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/zh/about/community/join/index.md
View File

@ -9,7 +9,7 @@ Istio 是一个开源项目，拥有一个支持其使用和持续开发的活
融入 Istio 社区有很多种方式：
{{< community_item logo="./discourse.svg" alt="Discourse" >}}
前往 [Istio discussion board](https://discuss.istio.io) 提出问题、参与讨论、获取故障排除的帮助。您可以使用 GitHub ID （或者 Google、Twitter 或 Yahoo） 登录！
前往 [Istio discussion board](https://discuss.istio.io) 提出问题、参与讨论、获取故障排除的帮助。您可以使用 GitHub ID （或者 Google、Twitter 或 Yahoo）登录！
{{< /community_item >}}
{{< community_item logo="./stackoverflow.svg" alt="Stack Overflow" >}}

4
content/zh/about/contribute/shortcodes/index.md
View File

@ -25,7 +25,7 @@ Hugo 的 shortcode 是具有特定语法的特殊占位符，您可以将其添
*/>}}
{{< /text >}}
`link` 和 `caption` 字段是必填字段， shortcode 还支持可选字段，例如：
`link` 和 `caption` 字段是必填字段，shortcode 还支持可选字段，例如：
{{< text html >}}
{{</* image width="75%" ratio="45.34%"
@ -113,7 +113,7 @@ Hugo 的 shortcode 是具有特定语法的特殊占位符，您可以将其添
## 术语表{#glossary-terms}
当您在页面中介绍一个 Istio 术语时，贡献补充条款要求您将该术语包含在 `glossary` 中，并使用 shortcode `{{</* gloss */>}}` 标记它的第一个实例。 shortcode 会对其进行特殊渲染，读者点击该术语，可以在弹出的窗口中获取该术语的定义。例如：
当您在页面中介绍一个 Istio 术语时，贡献补充条款要求您将该术语包含在 `glossary` 中，并使用 shortcode `{{</* gloss */>}}` 标记它的第一个实例。shortcode 会对其进行特殊渲染，读者点击该术语，可以在弹出的窗口中获取该术语的定义。例如：
{{< text markdown >}}
Mixer 使用 {{</*gloss*/>}}adapters{{</*/gloss*/>}} 与后端进行交互。

22
content/zh/blog/2017/0.1-auth/index.md
View File

@ -10,19 +10,19 @@ aliases:
target_release: 0.1
---
传统的网络安全方式无法解决部署在动态变化环境下分布式应用的安全威胁。这里，我们将描述 Istio Auth 如何帮助企业将其安全从边界保护转变为内部所有服务间通信保护。 使用 Istio Auth 开发人员和运维人员可以在不改动程序代码的情况下，对于敏感数据进行保护，防止未经授权的内部人员访问。
传统的网络安全方式无法解决部署在动态变化环境下分布式应用的安全威胁。这里，我们将描述 Istio Auth 如何帮助企业将其安全从边界保护转变为内部所有服务间通信保护。使用 Istio Auth 开发人员和运维人员可以在不改动程序代码的情况下，对于敏感数据进行保护，防止未经授权的内部人员访问。
Istio Auth 是更广泛的 [Istio 平台](/zh)的安全组件。它结合了 Google 生产环境中保护数百万微服务安全的经验。
## 背景知识{#background}
现代应用程序体系结构越来越多地基于共享服务，共享服务部署在云平台上，可被方便地进行动态部署和扩容。 传统的网络边界安全性（例如防火墙）控制力度太粗，会导致部分非预期的客户端访问。使用盗取合法客户端的认证令牌进行重放攻击，就是一种常见的安全风险。对于持有敏感数据公司而言，内部威胁是一个需要关注的主要风险。其他网络安全方法（如 IP 白名单）通过静态方式定义，难以大规模管理，不适合动态变化的生产环境。
现代应用程序体系结构越来越多地基于共享服务，共享服务部署在云平台上，可被方便地进行动态部署和扩容。传统的网络边界安全性（例如防火墙）控制力度太粗，会导致部分非预期的客户端访问。使用盗取合法客户端的认证令牌进行重放攻击，就是一种常见的安全风险。对于持有敏感数据公司而言，内部威胁是一个需要关注的主要风险。其他网络安全方法（如 IP 白名单）通过静态方式定义，难以大规模管理，不适合动态变化的生产环境。
因此，安全管理员需要一种工具，其可以能够默认开启并且始终保护生产环境中服务间的所有通信。
## 解决方案：增强的服务身份和验证{#solution-strong-service-identity-and-authentication}
多年来，Google 通过研发架构和技术，帮助其生产环境中数百万个微服务抵御了外部攻击和内部威胁。 关键安全原则包括信任端而不是网络，基于服务身份和级别授权的双向强身份验证。Istio Auth 基于相同的原则。
多年来，Google 通过研发架构和技术，帮助其生产环境中数百万个微服务抵御了外部攻击和内部威胁。关键安全原则包括信任端而不是网络，基于服务身份和级别授权的双向强身份验证。Istio Auth 基于相同的原则。
Istio Auth 服务 0.1 版本在 Kubernetes 上运行，并提供以下功能：
@ -34,7 +34,7 @@ Istio Auth 服务 0.1 版本在 Kubernetes 上运行，并提供以下功能：
* 密钥和证书的大规模管理
Istio Auth 基于双向 TLS 和 X.509 等行业标准。 此外，Google 还积极参与一个开放的，社区驱动的 [SPIFFE](https://spiffe.io/) 服务安全框架。 随着 [SPIFFE](https://spiffe.io/) 规范的成熟，我们打算让 Istio 安全验证参考并实现。
Istio Auth 基于双向 TLS 和 X.509 等行业标准。此外，Google 还积极参与一个开放的，社区驱动的 [SPIFFE](https://spiffe.io/) 服务安全框架。随着 [SPIFFE](https://spiffe.io/) 规范的成熟，我们打算让 Istio 安全验证参考并实现。
下图描述了 Kubernetes 上 Istio Auth 服务的体系结构。
@ -44,7 +44,7 @@ Istio Auth 基于双向 TLS 和 X.509 等行业标准。 此外，Google 还积
### 强身份认证{#strong-identity}
Istio Auth 使用了 [Kubernetes 服务帐户](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)来识别服务运行的身份。 身份用于建立信任和定义服务级别访问策略。 身份在服务部署时分配，并在 X.509 证书的 SAN（主题备用名称）字段中进行编码。 使用服务帐户作为身份具有以下优点：
Istio Auth 使用了 [Kubernetes 服务帐户](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)来识别服务运行的身份。身份用于建立信任和定义服务级别访问策略。身份在服务部署时分配，并在 X.509 证书的 SAN（主题备用名称）字段中进行编码。使用服务帐户作为身份具有以下优点：
* 管理员可以使用 Kubernetes 1.6 中引入的 [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) 功能配置谁有权访问服务帐户
@ -54,11 +54,11 @@ Istio Auth 使用了 [Kubernetes 服务帐户](https://kubernetes.io/docs/tasks/
### 通信安全{#communication-security}
服务间通信基于高性能客户端和服务器端 [Envoy](https://envoyproxy.github.io/envoy/) 代理的传输隧道。 代理之间的通信使用双向 TLS 来进行保护。 使用双向 TLS 的好处是服务身份不会被替换为从源窃取或重放攻击的令牌。 Istio Auth 还引入了安全命名的概念，以防止服务器欺骗攻击 - 客户端代理验证允许验证特定服务的授权的服务帐户。
服务间通信基于高性能客户端和服务器端 [Envoy](https://envoyproxy.github.io/envoy/) 代理的传输隧道。代理之间的通信使用双向 TLS 来进行保护。使用双向 TLS 的好处是服务身份不会被替换为从源窃取或重放攻击的令牌。Istio Auth 还引入了安全命名的概念，以防止服务器欺骗攻击 - 客户端代理验证允许验证特定服务的授权的服务帐户。
### 密钥管理和分配{#key-management-and-distribution}
Istio Auth 为每个集群提供 CA（证书颁发机构），并可对密钥和证书自动管理。 这种情况下，Istio Auth 具备以下功能 ：
Istio Auth 为每个集群提供 CA（证书颁发机构），并可对密钥和证书自动管理。这种情况下，Istio Auth 具备以下功能 ：
* 为每个服务帐户生成密钥和证书对。
@ -72,16 +72,16 @@ Istio Auth 为每个集群提供 CA（证书颁发机构），并可对密钥和
{{< image link="istio_auth_workflow.svg" caption="Istio Auth 工作流程" >}}
Istio Auth 是更广泛的容器安全中的一部分。 Red Hat 是 Kubernetes 开发的合作伙伴，定义了 [10 层](https://www.redhat.com/en/resources/container-security-openshift-cloud-devops-whitepaper)容器安全。 Istio 和 Istio Auth 解决了其中两个层：”网络隔离” 和 “API 和服务端点管理”。 随着集群联邦在 Kubernetes 和其他平台上的发展，我们的目的是让 Istio 对跨越多个联邦集群的服务间通信提供保护。
Istio Auth 是更广泛的容器安全中的一部分。Red Hat 是 Kubernetes 开发的合作伙伴，定义了 [10 层](https://www.redhat.com/en/resources/container-security-openshift-cloud-devops-whitepaper)容器安全。Istio 和 Istio Auth 解决了其中两个层：”网络隔离” 和 “API 和服务端点管理”。随着集群联邦在 Kubernetes 和其他平台上的发展，我们的目的是让 Istio 对跨越多个联邦集群的服务间通信提供保护。
## Istio Auth 的优点{#benefits-of-Istio-authentication}
**深度防御**：当与 Kubernetes（或基础架构）网络策略结合使用时，用户可以获得更多的安全信心，因为他们知道 Pod 或服务间的通信在网络层和应用层上都得到保护。
**默认安全**：当与 Istio 的代理和集中策略引擎一起使用时，可在极少或不更改应用的情况下部署并配置 Istio Auth 。 因此，管理员和操作员可以确保默认开启服务通信保护，并且可以跨协议和运行时一致地实施这些策略。
**默认安全**：当与 Istio 的代理和集中策略引擎一起使用时，可在极少或不更改应用的情况下部署并配置 Istio Auth 。因此，管理员和操作员可以确保默认开启服务通信保护，并且可以跨协议和运行时一致地实施这些策略。
**强大的服务认证**：Istio Auth 使用双向 TLS 保护服务通信，以确保服务身份不会是其他来源窃取或重放攻击的令牌。 这可确保只能从经过严格身份验证和授权的客户端才能够访问具有敏感数据的服务。
**强大的服务认证**：Istio Auth 使用双向 TLS 保护服务通信，以确保服务身份不会是其他来源窃取或重放攻击的令牌。这可确保只能从经过严格身份验证和授权的客户端才能够访问具有敏感数据的服务。
## 加入我们{#join-us-in-this-journey}
Istio Auth 是提供完整安全功能的第一步，安全功能可以用于抵御外部攻击和内部威胁，保护服务的敏感数据。 虽然初始版本仅在 Kubernetes 上运行，但我们的目标是使其能够在不同的生产环境中保护服务通信。 我们鼓励更多的社区[加入我们]({{< github_tree >}}/security)，为不同的应用技术栈和运行平台上轻松地提供强大的服务安全保障。
Istio Auth 是提供完整安全功能的第一步，安全功能可以用于抵御外部攻击和内部威胁，保护服务的敏感数据。虽然初始版本仅在 Kubernetes 上运行，但我们的目标是使其能够在不同的生产环境中保护服务通信。我们鼓励更多的社区[加入我们]({{< github_tree >}}/security)，为不同的应用技术栈和运行平台上轻松地提供强大的服务安全保障。

2
content/zh/blog/2017/0.1-canary/index.md
View File

@ -231,4 +231,4 @@ EOF
支持金丝雀部署的智能路由只是 Istio 的众多功能之一，它将使基于大型微服务的应用程序的生产部署变得更加简单。查看 [istio.io](/zh/) 了解更多信息。
可在[此处]({{<github_tree >}}/samples/helloworld) 查看示例代码。
可在[此处]({{<github_tree>}}/samples/helloworld)查看示例代码。

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

@ -9,9 +9,9 @@ aliases:
target_release: 0.1
---
使用网络策略去保护运行在 Kubernetes 上的应用程序现在是一种广泛接受的行业最佳实践。 鉴于 Istio 也支持策略，我们希望花一些时间来解释 Istio 策略和 Kubernetes 网络策略的相互作用和互相支持提供应用程序的安全。
使用网络策略去保护运行在 Kubernetes 上的应用程序现在是一种广泛接受的行业最佳实践。鉴于 Istio 也支持策略，我们希望花一些时间来解释 Istio 策略和 Kubernetes 网络策略的相互作用和互相支持提供应用程序的安全。
让我们从基础开始：为什么你想要同时使用 Istio 和 Kubernetes 网络策略？ 简短的回答是它们处理不同的事情。 表格列出 Istio 和网络策略之间的主要区别（我们将描述“典型”实现，例如：Calico，但具体实现细节可能因不同的网络提供商而异）：
让我们从基础开始：为什么你想要同时使用 Istio 和 Kubernetes 网络策略？简短的回答是它们处理不同的事情。表格列出 Istio 和网络策略之间的主要区别（我们将描述“典型”实现，例如：Calico，但具体实现细节可能因不同的网络提供商而异）：
| | Istio 策略 |网络策略 |
| -------------------- | ----------------- | ------------------ |
@ -23,9 +23,9 @@ target_release: 0.1
从 OSI 模型的角度来看 7 层（应用程序），Istio 策略运行在网络应用程序的“服务”层。但事实上云原生应用程序模型是 7 层实际上至少包含两层：服务层和内容层。服务层通常是 HTTP ，它封装了实际的应用程序数据（内容层）。Istio 的 Envoy 代理运行的 HTTP 服务层。相比之下，网络策略在 OSI 模型中的第 3 层（网络）和第 4 层（传输）运行。
运行在服务层为 Envoy 代理提供了一组丰富的属性，以便基础协议进行策略决策，其中包括 HTTP/1.1 和 HTTP/2（ gRPC 运行在 HTTP/2 上）。因此，您可以基于虚拟主机、URL 或其他 HTTP 头部应用策略。在未来，Istio 将支持广泛的 7 层协议、以及通用的 TCP 和 UDP 传输。
运行在服务层为 Envoy 代理提供了一组丰富的属性，以便基础协议进行策略决策，其中包括 HTTP/1.1 和 HTTP/2（gRPC 运行在 HTTP/2 上）。因此，您可以基于虚拟主机、URL 或其他 HTTP 头部应用策略。在未来，Istio 将支持广泛的 7 层协议、以及通用的 TCP 和 UDP 传输。
相比之下，Istio 策略运行在网络层具有通用的优势，因为所有网络应用程序都使用 IP。无论 7 层协议如何，您都可以在网络层应用策略：DNS 、SQL 数据库、实时流以及许多不使用 HTTP 的其他服务都可以得到保护。网络策略不仅限于经典防火墙的 IP 地址、 协议和端口三元组， Istio 和网络策略都可以使用丰富的 Kubernetes 标签来描述 pod 端点。
相比之下，Istio 策略运行在网络层具有通用的优势，因为所有网络应用程序都使用 IP。无论 7 层协议如何，您都可以在网络层应用策略：DNS 、SQL 数据库、实时流以及许多不使用 HTTP 的其他服务都可以得到保护。网络策略不仅限于经典防火墙的 IP 地址、协议和端口三元组，Istio 和网络策略都可以使用丰富的 Kubernetes 标签来描述 pod 端点。
## 实现{#implementation}
@ -42,21 +42,21 @@ Envoy 代理的策略执行是在 pod 中，作为同一网络命名空间中的
- 攻击未受保护的 pods
- 尝试通过发送大量流量为受保护的 pods 造成访问拒绝
- 在 pod 中收集的漏出数据
- 攻击集群基础设施（ 服务器或 Kubernetes 服务）
- 攻击集群基础设施（服务器或 Kubernetes 服务）
- 攻击网格外的服务，如数据库，存储阵列或遗留系统。
网络策略通常在客户机的网络命名空间之外的主机节点处执行。 这意味着必须避免受损或行为不当的 pod 进入根命名空间的执行。 通过在 Kubernetes 1.8 中添加 egress 策略，这是网络策略成为保护基础设施免受工作负载受损的关键部分。
网络策略通常在客户机的网络命名空间之外的主机节点处执行。这意味着必须避免受损或行为不当的 pod 进入根命名空间的执行。通过在 Kubernetes 1.8 中添加 egress 策略，这是网络策略成为保护基础设施免受工作负载受损的关键部分。
## 举例{#examples}
让我们来看一些 Istio 应用程序使用 Kubernetes 网络策略的示例。 下面我们以 Bookinfo 应用程序为例，介绍网络策略功能的用例：
让我们来看一些 Istio 应用程序使用 Kubernetes 网络策略的示例。下面我们以 Bookinfo 应用程序为例，介绍网络策略功能的用例：
- 减少应用程序入口的攻击面
- 在应用程序中实现细粒度隔离
### 减少应用程序入口的攻击面{#reduce-attack-surface-of-the-application-ingress}
应用程序的 ingress 控制器是外部世界进入我们应用程序的主要入口。 快速查看 `istio.yaml` （用于安装 Istio ）定义了 Istio-ingress，如下所示：
应用程序的 ingress 控制器是外部世界进入我们应用程序的主要入口。快速查看 `istio.yaml` （用于安装 Istio ）定义了 Istio-ingress，如下所示：
{{< text yaml >}}
apiVersion: v1
@ -76,7 +76,7 @@ spec:
istio: ingress
{{< /text >}}
`istio-ingress` 暴露端口 80 和 443 . 我们需要将流入流量限制在这两个端口上。 Envoy 有 [`内置管理接口`](https://www.envoyproxy.io/docs/envoy/latest/operations/admin.html#operations-admin-interface)，我们不希望错误配置 `istio-ingress` 镜像而导致意外地将我们的管理接口暴露给外界。这里深度防御的示例：正确配置的镜像应该暴露接口，正确配置的网络策略将阻止任何人连接到它，要么失败，要么配置错误，受到保护。
`istio-ingress` 暴露端口 80 和 443 . 我们需要将流入流量限制在这两个端口上。Envoy 有 [`内置管理接口`](https://www.envoyproxy.io/docs/envoy/latest/operations/admin.html#operations-admin-interface)，我们不希望错误配置 `istio-ingress` 镜像而导致意外地将我们的管理接口暴露给外界。这里深度防御的示例：正确配置的镜像应该暴露接口，正确配置的网络策略将阻止任何人连接到它，要么失败，要么配置错误，受到保护。
{{< text yaml >}}
apiVersion: networking.k8s.io/v1
@ -105,7 +105,7 @@ spec:
caption="Bookinfo Service Graph"
>}}
此图显示了一个正确功能的应用程序应该允许的每个连接。 所有其他连接，例如从 Istio Ingress 直接到 Rating 服务，不是应用程序的一部分。 让我们排除那些无关的连接，它们不能被攻击者所用。 例如：想象一下，Ingress pod 受到攻击者的攻击，允许攻击者运行任意代码。 如果我们使用网络策略只允许连接到 `productpage`（`http://$GATEWAY_URL/productpage`）的 Pod ，则攻击者不再获得对我的应用程序后端的访问权限，尽管它们已经破坏了服务网格的成员。
此图显示了一个正确功能的应用程序应该允许的每个连接。所有其他连接，例如从 Istio Ingress 直接到 Rating 服务，不是应用程序的一部分。让我们排除那些无关的连接，它们不能被攻击者所用。例如：想象一下，Ingress pod 受到攻击者的攻击，允许攻击者运行任意代码。如果我们使用网络策略只允许连接到 `productpage`（`http://$GATEWAY_URL/productpage`）的 Pod ，则攻击者不再获得对我的应用程序后端的访问权限，尽管它们已经破坏了服务网格的成员。
{{< text yaml >}}
apiVersion: networking.k8s.io/v1
@ -131,6 +131,6 @@ spec:
## 总结{#summary}
我们认为 Istio 和网络策略在应用策略方面有不同的优势。 Istio 具有应用协议感知和高度灵活性，非常适合应用策略来支持运营目标，如：服务路由、重试、熔断等，以及在应用层开启的安全性，例如：令牌验证。 网络策略是通用的、高效的、与 pod 隔离，使其成为应用策略以支持网络安全目标的理想选择。 此外，拥有在网络堆栈的不同层运行的策略是一件非常好的事情，因为它为每个层提供特定的上下文而不会混合状态并允许责任分离。
我们认为 Istio 和网络策略在应用策略方面有不同的优势。Istio 具有应用协议感知和高度灵活性，非常适合应用策略来支持运营目标，如：服务路由、重试、熔断等，以及在应用层开启的安全性，例如：令牌验证。网络策略是通用的、高效的、与 pod 隔离，使其成为应用策略以支持网络安全目标的理想选择。此外，拥有在网络堆栈的不同层运行的策略是一件非常好的事情，因为它为每个层提供特定的上下文而不会混合状态并允许责任分离。
这篇文章是基于 Spike Curtis 的三部分博客系列，他是 Tigera 的 Istio 团队成员之一。 完整系列可以在这里找到：<https://www.projectcalico.org/using-network-policy-in-concert-with-istio/>
这篇文章是基于 Spike Curtis 的三部分博客系列，他是 Tigera 的 Istio 团队成员之一。完整系列可以在这里找到：<https://www.projectcalico.org/using-network-policy-in-concert-with-istio/>

2
content/zh/blog/2017/adapter-model/index.md
View File

@ -75,4 +75,4 @@ Rule 中包含有匹配断言，这个断言是一个返回布尔值的属性表
Handler 为各个适配器提供了配置数据，Template 用于在运行时确定不同的适配器所需的数据类型，Instance 让运维人员准备这些数据，Rule 将这些数据提交给一个或多个 Handler 进行处理。
更多信息可以关注[这里](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/)。更多关于 templates, handlers, 和 rules 的内容可以关注[这里](/zh/docs/reference/config/policy-and-telemetry/)。你也可以在[这里]({{<github_tree >}}/samples/bookinfo) 找到对应的示例。
更多信息可以关注[这里](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/)。更多关于 templates, handlers, 和 rules 的内容可以关注[这里](/zh/docs/reference/config/policy-and-telemetry/)。你也可以在[这里]({{<github_tree>}}/samples/bookinfo)找到对应的示例。

4
content/zh/blog/2018/aws-nlb/index.md
View File

@ -15,7 +15,7 @@ target_release: 1.0
本文提供了使用 [AWS 网络负载均衡器](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html)配置 ingress Istio 的说明。
可以使用网络负载均衡器 (NLB) 来代替传统的负载均衡器。 你可以查看不同的 AWS `负载均衡器` 之间的[比较](https://aws.amazon.com/elasticloadbalancing/details/#Product_comparisons)以获取更多的解释。
可以使用网络负载均衡器 (NLB) 来代替传统的负载均衡器。你可以查看不同的 AWS `负载均衡器` 之间的[比较](https://aws.amazon.com/elasticloadbalancing/details/#Product_comparisons)以获取更多的解释。
## 先行条件{#prerequisites}
@ -25,7 +25,7 @@ target_release: 1.0
## IAM Policy
你需要在主角色上应用策略， 以便能够配置网络负载均衡器。
你需要在主角色上应用策略，以便能够配置网络负载均衡器。
1. 在 AWS `iam` 控制台中，点击策略并单击“创建新策略”：

4
content/zh/blog/2018/egress-https/index.md
View File

@ -77,7 +77,7 @@ $ kubectl apply -f @samples/bookinfo/networking/virtual-service-details-v2.yaml@
仍然提供了应用程序的大多数功能, 我们有**优雅的服务降级**：正如您所看到的，评论和评级正确显示，
应用程序仍然有用。
那可能出了什么问题？ 啊...... 答案是我忘了启用从网格内部到外部服务的流量，在本例中是 Google Book Web 服务。
那可能出了什么问题？啊...... 答案是我忘了启用从网格内部到外部服务的流量，在本例中是 Google Book Web 服务。
默认情况下，Istio sidecar 代理（[Envoy proxies](https://www.envoyproxy.io)）
**阻止到集群外目的地的所有流量**, 要启用此类流量，我们必须定义 [mesh-external service entry](/zh/docs/reference/config/networking/service-entry/)。
@ -145,7 +145,7 @@ serviceentry "googleapis" deleted
并在输出中看到删除了 `ServiceEntry`。
删除 `ServiceEntry` 后访问网页会产生我们之前遇到的相同错误，即 _Error fetching product details_,
正如我们所看到的，，与许多其他 Istio 配置一样，`ServiceEntry` 是**动态定义**的 , Istio 运算符可以动态决定
正如我们所看到的，与许多其他 Istio 配置一样，`ServiceEntry` 是**动态定义**的 , Istio 运算符可以动态决定
它们允许微服务访问哪些域, 他们可以动态启用和禁用外部域的流量，而无需重新部署微服务。
### 清除对 Google 图书网络服务的 HTTPS 访问权限{#cleanup-of-https-access-to-a-google-books-web-service}

16
content/zh/blog/2018/egress-monitoring-access-control/index.md
View File

@ -14,7 +14,7 @@ target_release: 1.1
## 用例{#use-case}
考虑一个运行处理 _cnn.com_ 内容的应用程序的组织。应用程序被解耦为部署在 Istio 服务网格中的微服务。应用程序访问 _cnn.com_ 的各种话题页面：[edition.cnn.com/politics](https://edition.cnn.com/politics)， [edition.cnn.com/sport](https://edition.cnn.com/sport) 和 [edition.cnn.com/health](https://edition.cnn.com/health)。该组织[配置了访问 edition.cnn.com 的权限](/zh/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/)，一切都正常运行。然而，在某一时刻，本组织决定移除政治话题。实际上，这意味着禁止访问 [edition.cnn.com/politics](https://edition.cnn.com/politics) ，只允许访问 [edition.cnn.com/sport](https://edition.cnn.com/sport) 和 [edition.cnn.com/health](https://edition.cnn.com/health) 。该组织将根据具体情况，向个别应用程序和特定用户授予访问 [edition.cnn.com/politics](https://edition.cnn.com/politics) 的权限。
考虑一个运行处理 _cnn.com_ 内容的应用程序的组织。应用程序被解耦为部署在 Istio 服务网格中的微服务。应用程序访问 _cnn.com_ 的各种话题页面：[edition.cnn.com/politics](https://edition.cnn.com/politics)，[edition.cnn.com/sport](https://edition.cnn.com/sport) 和 [edition.cnn.com/health](https://edition.cnn.com/health)。该组织[配置了访问 edition.cnn.com 的权限](/zh/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/)，一切都正常运行。然而，在某一时刻，本组织决定移除政治话题。实际上，这意味着禁止访问 [edition.cnn.com/politics](https://edition.cnn.com/politics) ，只允许访问 [edition.cnn.com/sport](https://edition.cnn.com/sport) 和 [edition.cnn.com/health](https://edition.cnn.com/health) 。该组织将根据具体情况，向个别应用程序和特定用户授予访问 [edition.cnn.com/politics](https://edition.cnn.com/politics) 的权限。
为了实现这一目标，组织的运维人员监控对外部服务的访问，并分析 Istio 日志，以验证没有向 [edition.cnn.com/politics](https://edition.cnn.com/politics) 发送未经授权的请求。他们还配置了 Istio 来防止自动访问 [edition.cnn.com/politics](https://edition.cnn.com/politics) 。
@ -51,7 +51,7 @@ target_release: 1.1
caption="用于 egress 监视和访问策略的实例、规则和处理程序"
>}}
1. 创建 `logentry`、 `rules` 和 `handlers`。 注意您指定了 `context.reporter.uid` 作为
1. 创建 `logentry`、`rules` 和 `handlers`。注意您指定了 `context.reporter.uid` 作为
`kubernetes://istio-egressgateway` 在规则中只能从 egress 网关获取日志信息。
{{< text bash >}}
@ -124,7 +124,7 @@ target_release: 1.1
EOF
{{< /text >}}
1. 发送三个 HTTP 请求到 _cnn.com_ 、 [edition.cnn.com/politics](https://edition.cnn.com/politics)、 [edition.cnn.com/sport](https://edition.cnn.com/sport) 和 [edition.cnn.com/health](https://edition.cnn.com/health)。
1. 发送三个 HTTP 请求到 _cnn.com_ 、[edition.cnn.com/politics](https://edition.cnn.com/politics)、[edition.cnn.com/sport](https://edition.cnn.com/sport) 和 [edition.cnn.com/health](https://edition.cnn.com/health)。
三个请求都应该返回 _200 OK_ 。
{{< text bash >}}
@ -147,7 +147,7 @@ target_release: 1.1
您将看到与您的三个请求相关的四个日志条目。三个关于访问 _edition.cnn.com_ 的 _info_ 信息和一个关于访问 _edition.cnn.com/politics_ 的 _error_ 信息。服务网格 operators 可以查看所有访问实例，还可以搜索日志中表示禁止访问的 _error_ 日志。这是在自动地阻塞禁止访问之前可以应用的第一个安全措施，即将所有禁止访问实例记录为错误。在某些设置中，这可能是一个足够的安全措施。
注意以下属性：
* `destination`、 `path`、 `responseCode` 和 `responseSize` 与请求的 HTTP 参数相关
* `destination`、`path`、`responseCode` 和 `responseSize` 与请求的 HTTP 参数相关
* `sourcePrincipal`:`cluster.local/ns/default/sa/sleep` —— 表示 `default` 命名空间中的 `sleep` 服务帐户的字符串
* `reporterUID`: `kubernetes://istio-egressgateway-747b6764b8-44rrh.istio-system` —— 报告 pod 的 UID，在本例中为 `istio-egressgateway-747b6764b8-44rrh`，位于 `istio-system` 命名空间中
@ -207,7 +207,7 @@ target_release: 1.1
200
{{< /text >}}
向 [edition.cnn.com/politics](https://edition.cnn.com/politics) 发送请求会返回 _404 Not Found_ ， 然而向
向 [edition.cnn.com/politics](https://edition.cnn.com/politics) 发送请求会返回 _404 Not Found_ ，然而向
[edition.cnn.com/sport](https://edition.cnn.com/sport) 和
[edition.cnn.com/health](https://edition.cnn.com/health) 发送请求，会像我们预想的那样返回 _200 OK_ 。
@ -272,7 +272,7 @@ target_release: 1.1
EOF
{{< /text >}}
1. 发送之前的三个 HTTP 请求到 _cnn.com_ ， 这一次您应该会收到三个 _200 OK_ 的响应：
1. 发送之前的三个 HTTP 请求到 _cnn.com_ ，这一次您应该会收到三个 _200 OK_ 的响应：
{{< text bash >}}
$ kubectl exec -it $SOURCE_POD -c sleep -- sh -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
@ -339,7 +339,7 @@ target_release: 1.1
EOF
{{< /text >}}
1. 执行常规测试，将 HTTP 请求发送到 [edition.cnn.com/politics](https://edition.cnn.com/politics)， [edition.cnn.com/sport](https://edition.cnn.com/sport) 和 [edition.cnn.com/health](https://edition.cnn.com/health)。正如所料，对 [edition.cnn.com/politics](https://edition.cnn.com/politics) 的请求返回 _403_ （禁止）。
1. 执行常规测试，将 HTTP 请求发送到 [edition.cnn.com/politics](https://edition.cnn.com/politics)，[edition.cnn.com/sport](https://edition.cnn.com/sport) 和 [edition.cnn.com/health](https://edition.cnn.com/health)。正如所料，对 [edition.cnn.com/politics](https://edition.cnn.com/politics) 的请求返回 _403_ （禁止）。
{{< text bash >}}
$ kubectl exec -it $SOURCE_POD -c sleep -- sh -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
@ -455,7 +455,7 @@ target_release: 1.1
在这个用例中，应用程序使用 HTTP 和 Istio Egress 网关为它们执行 TLS 初始化。或者，应用程序可以通过向 _edition.cnn.com_ 发出 HTTPS 请求来发起 TLS 本身。在本节中，我们将描述这两种方法及其优缺点。
在 HTTP 方法中，请求在本地主机上不加密地发送，由 Istio sidecar 代理拦截并转发到 egress 网关。由于您将 Istio 配置为在 sidecar 代理和 egress 网关之间使用相互的 TLS，因此流量会使 pod 加密。egress 网关解密流量，检查 URL 路径、 HTTP 方法和报头，报告遥测数据并执行策略检查。如果请求没有被某些策略检查阻止，那么 egress 网关将执行 TLS 发起到外部目的地（在我们的示例中是 _cnn.com_ ），因此请求将再次加密并发送到外部目的地。下图演示了这种方法的流程。网关内的 HTTP 协议根据解密后网关看到的协议来指定协议。
在 HTTP 方法中，请求在本地主机上不加密地发送，由 Istio sidecar 代理拦截并转发到 egress 网关。由于您将 Istio 配置为在 sidecar 代理和 egress 网关之间使用相互的 TLS，因此流量会使 pod 加密。egress 网关解密流量，检查 URL 路径、HTTP 方法和报头，报告遥测数据并执行策略检查。如果请求没有被某些策略检查阻止，那么 egress 网关将执行 TLS 发起到外部目的地（在我们的示例中是 _cnn.com_ ），因此请求将再次加密并发送到外部目的地。下图演示了这种方法的流程。网关内的 HTTP 协议根据解密后网关看到的协议来指定协议。
{{< image width="80%"
link="http-to-gateway.svg"

10
content/zh/blog/2018/egress-tcp/index.md
View File

@ -62,7 +62,7 @@ target_release: 1.0
$ mysql -u root -p --host $MYSQL_DB_HOST --port $MYSQL_DB_PORT -e "CREATE USER 'bookinfo' IDENTIFIED BY '<password you choose>'; GRANT SELECT ON test.ratings to 'bookinfo';"
{{< /text >}}
在这里，你会应用[最小特权原则](https://en.wikipedia.org/wiki/Principle_of_least_privilege)，这意味着不在 Bookinfo 应用程序中使用 `admin` 用户。相反，你为应用程序 Bookinfo 创建了一个最小权限的特殊用户 `bookinfo`， 在这种情况下，`bookinfo` 用户只对单个表具有 `SELECT` 特权。
在这里，你会应用[最小特权原则](https://en.wikipedia.org/wiki/Principle_of_least_privilege)，这意味着不在 Bookinfo 应用程序中使用 `admin` 用户。相反，你为应用程序 Bookinfo 创建了一个最小权限的特殊用户 `bookinfo`，在这种情况下，`bookinfo` 用户只对单个表具有 `SELECT` 特权。
在运行命令创建用户之后，你可能会想通过检查最后一个命令的编号并运行 `history -d <创建用户的命令编号>` 来清理我的 bash 历史记录。你可能不希望新用户的密码存储在 bash 历史记录中，如果你使用了 `mysql` 命令行工具，记得要删除 `~/.mysql_history` 文件中的最后一个命令。在 [MySQL 文档](https://dev.mysql.com/doc/refman/5.5/en/create-user.html)中阅读有关新创建用户的密码保护的更多信息。
@ -158,7 +158,7 @@ target_release: 1.0
value: password
{{< /text >}}
替换上面代码段中的值，指定数据库主机，端口，用户和密码，请注意，在 Kubernetes 中使用容器环境变量中密码的正确方法是[使用 secret](https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-environment-variables)，仅对于此示例任务，你可能会在 deployment spec 中直接配置明文的密码， **切记！不要在真实环境中这样做**！我想你们应该也知道，`"password"` 这个值也不应该用作密码。
替换上面代码段中的值，指定数据库主机，端口，用户和密码，请注意，在 Kubernetes 中使用容器环境变量中密码的正确方法是 [使用 secret](https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-environment-variables)，仅对于此示例任务，你可能会在 deployment spec 中直接配置明文的密码，**切记！不要在真实环境中这样做**！我想你们应该也知道，`"password"` 这个值也不应该用作密码。
1. 应用修改后的 `spec` 来部署使用外部数据库的 _ratings_ 服务，_v2-mysql_ 的版本。
@ -244,7 +244,7 @@ target_release: 1.0
[下面](#service-entries-for-tcp-traffic)我将详细讨论 TCP 服务入口。现在先来验证我们添加的出口规则是否解决了问题。访问网页看看评星是否回来了。
有效！ 访问应用程序的网页会显示评级而不会出现错误：
有效！访问应用程序的网页会显示评级而不会出现错误：
{{< image width="80%" link="externalMySQLRatings.png" caption="Book Ratings 显示正常" >}}
@ -272,7 +272,7 @@ target_release: 1.0
## 与网格扩展的关系{#relation-to-virtual-machines-support}
请注意，本文中描述的场景与[集成虚拟机](/zh/docs/examples/virtual-machines/bookinfo/)示例中描述的网格扩展场景不同。 在这种情况下，MySQL 实例在与 Istio 服务网格集成的外部（集群外）机器（裸机或 VM）上运行 ，MySQL 服务成为网格的一等公民，具有 Istio 的所有有益功能，除此之外，服务可以通过本地集群域名寻址，例如通过 `mysqldb.vm.svc.cluster.local`，并且可以通过[双向 TLS 身份验证](/zh/docs/concepts/security/#mutual-TLS-authentication)保护与它的通信，无需创建服务入口来访问此服务; 但是，该服务必须在 Istio 注侧，要启用此类集成，必须在计算机上安装 Istio 组件（ _Envoy proxy_ ，_node-agent_ ，`_istio-agent_` ），并且必须可以从中访问 Istio 控制平面（_Pilot_ ，_Mixer_ ，_Citadel_ ）。有关详细信息，请参阅 [Istio VM 相关](/zh/docs/examples/virtual-machines/)。
请注意，本文中描述的场景与[集成虚拟机](/zh/docs/examples/virtual-machines/bookinfo/)示例中描述的网格扩展场景不同。在这种情况下，MySQL 实例在与 Istio 服务网格集成的外部（集群外）机器（裸机或 VM）上运行 ，MySQL 服务成为网格的一等公民，具有 Istio 的所有有益功能，除此之外，服务可以通过本地集群域名寻址，例如通过 `mysqldb.vm.svc.cluster.local`，并且可以通过[双向 TLS 身份验证](/zh/docs/concepts/security/#mutual-TLS-authentication)保护与它的通信，无需创建服务入口来访问此服务; 但是，该服务必须在 Istio 注侧，要启用此类集成，必须在计算机上安装 Istio 组件（_Envoy proxy_ ，_node-agent_ ，`_istio-agent_` ），并且必须可以从中访问 Istio 控制平面（_Pilot_ ，_Mixer_ ，_Citadel_ ）。有关详细信息，请参阅 [Istio VM 相关](/zh/docs/examples/virtual-machines/)。
在这个的示例中，MySQL 实例可以在任何计算机上运行，也可以由云提供商作为服务进行配置，无需集成机器
与 Istio ，无需从机器访问 Istio 控制平面，在使用 MySQL 作为服务的情况下，运行 MySQL 的计算机可能无法访问，并且可能无法在其上安装必需的组件。在这个的例子中，MySQL 实例可以通过其全局域名进行寻址，如果消费应用程序希望使用该域名，这可能是有益的，当在消费应用程序的部署配置中无法更改预期的域名时，这尤其重要。
@ -317,4 +317,4 @@ target_release: 1.0
## 结论{#conclusion}
在这篇博文中，我演示了 Istio 服务网格中的微服务如何通过 TCP 使用外部服务，默认情况下，Istio 会阻止所有流量（TCP 和 HTTP）到集群外的主机， 要为 TCP 启用此类流量，必须为服务网格创建 TCP 网格外部服务入口。
在这篇博文中，我演示了 Istio 服务网格中的微服务如何通过 TCP 使用外部服务，默认情况下，Istio 会阻止所有流量（TCP 和 HTTP）到集群外的主机，要为 TCP 启用此类流量，必须为服务网格创建 TCP 网格外部服务入口。

8
content/zh/blog/2018/export-logs-through-stackdriver/index.md
View File

@ -34,7 +34,7 @@ Istio 支持将日志导出到 Stackdriver，而 Stackdriver 又可以配置为
#### BigQuery{#big-query}
1. [`创建 BigQuery 数据集`](https://cloud.google.com/bigquery/docs/datasets) 作为日志导出的目标。
1. 记录数据集的 ID。 这里需要设置 Stackdriver 处理程序。它的格式为 `bigquery.googleapis.com/projects/[PROJECT_ID]/datasets/[DATASET_ID]`
1. 记录数据集的 ID。这里需要设置 Stackdriver 处理程序。它的格式为 `bigquery.googleapis.com/projects/[PROJECT_ID]/datasets/[DATASET_ID]`
1. 给 [`接收器授权`](https://cloud.google.com/logging/docs/api/tasks/exporting-logs#writing_to_the_destination)：cloud-logs@system.gserviceaccount.com。它具有 IAM 中的 BigQuery Data Editor 的角色。
1. 如果使用 [`Google Kubernetes Engine`](/zh/docs/setup/platform-setup/gke/)，请确保在集群上启用了 `bigquery` [`Scope`](https://cloud.google.com/sdk/gcloud/reference/container/clusters/create)。
@ -69,7 +69,7 @@ Istio 支持将日志导出到 Stackdriver，而 Stackdriver 又可以配置为
# pushInterval: 1m
# 必须设置 Stacldriver 适配器 project_id 的值。
project_id: "<project_id>"
# apiCredentials 和 apiKey 必须设置之一； 首选方法是`appCredentials`，它对应于 Google 应用程序默认凭据。
# apiCredentials 和 apiKey 必须设置之一；首选方法是`appCredentials`，它对应于 Google 应用程序默认凭据。
# 如果没有提供，我们使用默认应用凭据。
# appCredentials:
# apiKey:
@ -154,10 +154,10 @@ Istio 支持将日志导出到 Stackdriver，而 Stackdriver 又可以配置为
1. 验证日志是否正在通过 Stackdriver 流向配置的接收器。
* Stackdriver：导航到项目的 [`Stackdriver Logs Viewer`](https://pantheon.corp.google.com/logs/viewer)，查看 “GKE Container” -> “Cluster Name” -> “Namespace Id”， 查看 Istio 访问日志。
* Stackdriver：导航到项目的 [`Stackdriver Logs Viewer`](https://pantheon.corp.google.com/logs/viewer)，查看 “GKE Container” -> “Cluster Name” -> “Namespace Id”，查看 Istio 访问日志。
* BigQuery：导航到项目的 [`BigQuery Interface`](https://bigquery.cloud.google.com/)，在接收器的数据集中找到一个前缀为 `accesslog_logentry_istio` 的表。
* GCS：导航到项目的 [`Storage Brower`](https://pantheon.corp.google.com/storage/browser/)，在接收器的桶中找到一个名为 `accesslog.logentry.istio-system` 的桶。
* Pub/Sub：导航到项目的 [`Pub/Sub 主题列表`](https://pantheon.corp.google.com/cloudpubsub/topicList)， 在接收器的主题中找到 `accesslog` 主题。
* Pub/Sub：导航到项目的 [`Pub/Sub 主题列表`](https://pantheon.corp.google.com/cloudpubsub/topicList)，在接收器的主题中找到 `accesslog` 主题。
## 了解发生了什么{#understanding-what-happened}

4
content/zh/blog/2018/hp/index.md
View File

@ -7,7 +7,7 @@ attribution: Steven Ceuppens, Chief Software Architect @ HP FitStation, Open Sou
target_release: 1.0
---
惠普的 FitStation 团队坚信， 未来的 Kubernetes、BPF 和服务网络是云基础设施的下一个标准。
惠普的 FitStation 团队坚信，未来的 Kubernetes、BPF 和服务网络是云基础设施的下一个标准。
我们也很高兴看到 Istio 即将推出其官方的 Istio 1.0 版本 - 这要归功于 2017 年 5 月从 Google、IBM 和 Lyft 开始的联合合作。
在 FitStation 大规模和渐进式云平台的开发过程中，Istio 、Cilium 和 Kubernetes 的技术提供了大量机会，使我们的系统更加健壮和易于扩展。
@ -22,7 +22,7 @@ FitStation 建立在对用户生物识别数据的最终安全性和隐私承诺
使用 Istio 可以大大降低维护大量库和服务的复杂性，从而提供安全的通信服务。
作为使用 Istio 1.0 的额外好处，我们获得了网络可见性，指标和开箱即用的追踪。这极大地改善了我们开发和 DevOps 团队的的决策和响应质量
。团队深入了解包括新应用程序和传统应用程序在内的整个平台的网络通信。 Cilium 与 Envoy 的整合，
。团队深入了解包括新应用程序和传统应用程序在内的整个平台的网络通信。Cilium 与 Envoy 的整合，
让 Istio 服务网格网络通信能力的性能取得了显著提升，同时还提供了内核驱动的细粒度 L7 网络安全层。这归功于 Cilium 为 Istio 提供的 BPF 功能。
我们认为未来将推动 Linux 的内核安全。

2
content/zh/blog/2018/soft-multitenancy/index.md
View File

@ -231,7 +231,7 @@ Error from server (Forbidden): pods is forbidden: User "dev-admin" cannot list p
## 问题{#issues}
* 一个租户（例如， `istio-system` 命名空间）的 CA(Certificate Authority) 和 Mixer 的 Pod 中产生的 Log 包含了另一个租户（例如， `istio-system1` 命名空间）的控制面的 `info` 信息。
* 一个租户（例如，`istio-system` 命名空间）的 CA(Certificate Authority) 和 Mixer 的 Pod 中产生的 Log 包含了另一个租户（例如，`istio-system1` 命名空间）的控制面的 `info` 信息。
## 其他多租户模型的挑战{#challenges-with-other-multi-tenancy-models}

42
content/zh/blog/2018/v1alpha3-routing/index.md
View File

@ -10,23 +10,23 @@ target_release: 0.7
到目前为止，Istio 提供了一个简单的 API 来进行流量管理，该 API 包括了四种资源：`RouteRule`，`DestinationPolicy`，`EgressRule` 和 （Kubernetes 的）`Ingress`。借助此 API，用户可以轻松管理 Istio 服务网格中的流量。该 API 允许用户将请求路由到特定版本的服务，为弹性测试注入延迟和失败，添加超时和断路器等，所有这些功能都不必更改应用程序本身的代码。
虽然目前 API 的功能已被证明是 Istio 非常引人注目的一部分，但用户的反馈也表明，这个 API 确实有一些缺点，尤其是在使用它来管理包含数千个服务的非常大的应用程序，以及使用 HTTP 以外的协议时。 此外，使用 Kubernetes Ingress 资源来配置外部流量的方式已被证明不能满足需求。
虽然目前 API 的功能已被证明是 Istio 非常引人注目的一部分，但用户的反馈也表明，这个 API 确实有一些缺点，尤其是在使用它来管理包含数千个服务的非常大的应用程序，以及使用 HTTP 以外的协议时。此外，使用 Kubernetes Ingress 资源来配置外部流量的方式已被证明不能满足需求。
为了解决上述缺陷和其他的一些问题，Istio 引入了新的流量管理 API v1alpha3，新版本的 API 将完全取代之前的 API。 尽管 v1alpha3 和之前的模型在本质上是基本相同的，但它并不向后兼容的，基于旧 API 的模型需要进行手动转换。
为了解决上述缺陷和其他的一些问题，Istio 引入了新的流量管理 API v1alpha3，新版本的 API 将完全取代之前的 API。尽管 v1alpha3 和之前的模型在本质上是基本相同的，但它并不向后兼容的，基于旧 API 的模型需要进行手动转换。
为了证明该非兼容升级的必要性，v1alpha3 API 经历了漫长而艰苦的社区评估过程，以希望新的 API 能够大幅改进，并经得起时间考验。 在本文中，我们将介绍新的配置模型，并试图解释影响这次变化的一些动机和设计原则。
为了证明该非兼容升级的必要性，v1alpha3 API 经历了漫长而艰苦的社区评估过程，以希望新的 API 能够大幅改进，并经得起时间考验。在本文中，我们将介绍新的配置模型，并试图解释影响这次变化的一些动机和设计原则。
## 设计原则{#design-principles}
路由模型的重构过程中遵循了一些关键的设计原则：
* 除支持声明式（意图）配置外，也支持显式指定模型依赖的基础设施。例如，除了配置入口网关（的功能特性）之外，负责实现 入口网关功能的组件（Controller）也可以在模型指定。
* 编写模型时应该"生产者导向”和"以 Host 为中心”，而不是通过组合多个规则来编写模型。 例如，所有与特定 Host 关联的规则被配置在一起，而不是单独配置。
* 编写模型时应该"生产者导向”和"以 Host 为中心”，而不是通过组合多个规则来编写模型。例如，所有与特定 Host 关联的规则被配置在一起，而不是单独配置。
* 将路由与路由后行为清晰分开。
## v1alpha3 中的配置资源{#configuration-resources-in-v1alpha3}
在一个典型的网格中，通常有一个或多个用于终结外部 TLS 链接，将流量引入网格的负载均衡器（我们称之为 gateway）。 然后流量通过边车网关（sidecar gateway）流经内部服务。 应用程序使用外部服务的情况也很常见（例如访问 Google Maps API），一些情况下，这些外部服务可能被直接调用；但在某些部署中，网格中所有访问外部服务的流量可能被要求强制通过专用的出口网关（Egress gateway）。 下图描绘了网关在网格中的使用情况。
在一个典型的网格中，通常有一个或多个用于终结外部 TLS 链接，将流量引入网格的负载均衡器（我们称之为 gateway）。然后流量通过边车网关（sidecar gateway）流经内部服务。应用程序使用外部服务的情况也很常见（例如访问 Google Maps API），一些情况下，这些外部服务可能被直接调用；但在某些部署中，网格中所有访问外部服务的流量可能被要求强制通过专用的出口网关（Egress gateway）。下图描绘了网关在网格中的使用情况。
{{< image width="80%"
link="gateways.svg"
@ -41,7 +41,7 @@ target_release: 0.7
1. `DestinationRule`
1. `ServiceEntry`
`VirtualService`，`DestinationRule` 和 `ServiceEntry` 分别替换了原 API 中的 `RouteRule`，`DestinationPolicy` 和 `EgressRule`。 `Gateway` 是一个独立于平台的抽象，用于对流入专用中间设备的流量进行建模。
`VirtualService`，`DestinationRule` 和 `ServiceEntry` 分别替换了原 API 中的 `RouteRule`，`DestinationPolicy` 和 `EgressRule`。`Gateway` 是一个独立于平台的抽象，用于对流入专用中间设备的流量进行建模。
下图描述了跨多个配置资源的控制流程。
@ -52,11 +52,11 @@ target_release: 0.7
### `Gateway`
[`Gateway`](/zh/docs/reference/config/networking/gateway/) 用于为 HTTP / TCP 流量配置负载均衡器，并不管该负载均衡器将在哪里运行。 网格中可以存在任意数量的 Gateway，并且多个不同的 Gateway 实现可以共存。 实际上，通过在配置中指定一组工作负载（Pod）标签，可以将 Gateway 配置绑定到特定的工作负载，从而允许用户通过编写简单的 Gateway Controller 来重用现成的网络设备。
[`Gateway`](/zh/docs/reference/config/networking/gateway/) 用于为 HTTP / TCP 流量配置负载均衡器，并不管该负载均衡器将在哪里运行。网格中可以存在任意数量的 Gateway，并且多个不同的 Gateway 实现可以共存。实际上，通过在配置中指定一组工作负载（Pod）标签，可以将 Gateway 配置绑定到特定的工作负载，从而允许用户通过编写简单的 Gateway Controller 来重用现成的网络设备。
对于入口流量管理，您可能会问： _为什么不直接使用 Kubernetes Ingress API_ ？ 原因是 Ingress API 无法表达 Istio 的路由需求。 Ingress 试图在不同的 HTTP 代理之间取一个公共的交集，因此只能支持最基本的 HTTP 路由，最终导致需要将代理的其他高级功能放入到注解（annotation）中，而注解的方式在多个代理之间是不兼容的，无法移植。
对于入口流量管理，您可能会问：_为什么不直接使用 Kubernetes Ingress API_ ？原因是 Ingress API 无法表达 Istio 的路由需求。Ingress 试图在不同的 HTTP 代理之间取一个公共的交集，因此只能支持最基本的 HTTP 路由，最终导致需要将代理的其他高级功能放入到注解（annotation）中，而注解的方式在多个代理之间是不兼容的，无法移植。
Istio `Gateway` 通过将 L4-L6 配置与 L7 配置分离的方式克服了 `Ingress` 的这些缺点。 `Gateway` 只用于配置 L4-L6 功能（例如，对外公开的端口，TLS 配置），所有主流的 L7 代理均以统一的方式实现了这些功能。 然后，通过在 `Gateway` 上绑定 `VirtualService` 的方式，可以使用标准的 Istio 规则来控制进入 `Gateway` 的 HTTP 和 TCP 流量。
Istio `Gateway` 通过将 L4-L6 配置与 L7 配置分离的方式克服了 `Ingress` 的这些缺点。`Gateway` 只用于配置 L4-L6 功能（例如，对外公开的端口，TLS 配置），所有主流的 L7 代理均以统一的方式实现了这些功能。然后，通过在 `Gateway` 上绑定 `VirtualService` 的方式，可以使用标准的 Istio 规则来控制进入 `Gateway` 的 HTTP 和 TCP 流量。
例如，下面这个简单的 `Gateway` 配置了一个 Load Balancer，以允许访问 host `bookinfo.com` 的 https 外部流量进入网格中：
@ -99,7 +99,7 @@ spec:
...
{{< /text >}}
`Gateway` 可以用于建模边缘代理或纯粹的内部代理，如第一张图所示。 无论在哪个位置，所有网关都可以用相同的方式进行配置和控制。
`Gateway` 可以用于建模边缘代理或纯粹的内部代理，如第一张图所示。无论在哪个位置，所有网关都可以用相同的方式进行配置和控制。
### `VirtualService`
@ -165,9 +165,9 @@ spec:
subset: v1
{{< /text >}}
正如你所看到的， 和 `reviews` 服务相关的两个规则集中写在了一个地方。这个改变乍一看可能觉得并没有什么特别的优势， 然而，如果仔细观察这个新模型，会发现它和之前的 API 之间存在着根本的差异，这使得 `v1alpha3` 功能更加强大。
正如你所看到的，和 `reviews` 服务相关的两个规则集中写在了一个地方。这个改变乍一看可能觉得并没有什么特别的优势，然而，如果仔细观察这个新模型，会发现它和之前的 API 之间存在着根本的差异，这使得 `v1alpha3` 功能更加强大。
首先，请注意 `VirtualService` 的目标服务是使用 `hosts` 字段（实际上是重复字段）指定的，然后再在每个路由的 `destination` 字段中指定。 这是与以前模型的重要区别。
首先，请注意 `VirtualService` 的目标服务是使用 `hosts` 字段（实际上是重复字段）指定的，然后再在每个路由的 `destination` 字段中指定。这是与以前模型的重要区别。
`VirtualService` 描述了一个或多个用户可寻址目标到网格内实际工作负载之间的映射。在上面的示例中，这两个地址是相同的，但实际上用户可寻址目标可以是任何用于定位服务的，具有可选通配符前缀或 CIDR 前缀的 DNS 名称。
这对于应用从单体架构到微服务架构的迁移过程特别有用，单体应用被拆分为多个独立的微服务后，采用 `VirtualService` 可以继续把多个微服务对外暴露为同一个目标地址，而不需要服务消费者进行修改以适应该变化。
@ -198,23 +198,23 @@ spec:
...
{{< /text >}}
实际上在 `VirtualService` 中 hosts 部分设置只是虚拟的目的地, 因此不一定是已在网格中注册的服务。这允许用户为在网格内没有可路由条目的虚拟主机的流量进行建模。 通过将 `VirtualService` 绑定到同一 Host 的 `Gateway` 配置（如前一节所述 ），可向网格外部暴露这些 Host。
实际上在 `VirtualService` 中 hosts 部分设置只是虚拟的目的地, 因此不一定是已在网格中注册的服务。这允许用户为在网格内没有可路由条目的虚拟主机的流量进行建模。通过将 `VirtualService` 绑定到同一 Host 的 `Gateway` 配置（如前一节所述 ），可向网格外部暴露这些 Host。
除了这个重大的重构之外， `VirtualService` 还包括其他一些重要的改变：
除了这个重大的重构之外，`VirtualService` 还包括其他一些重要的改变：
1. 可以在 `VirtualService` 配置中表示多个匹配条件，从而减少对冗余的规则设置。
1. 每个服务版本都有一个名称（称为服务子集）。 属于某个子集的一组 Pod/VM 在 `DestinationRule` 定义，具体定义参见下节。
1. 每个服务版本都有一个名称（称为服务子集）。属于某个子集的一组 Pod/VM 在 `DestinationRule` 定义，具体定义参见下节。
1. 通过使用带通配符前缀的 DNS 来指定 `VirtualService` 的 host，可以创建单个规则以作用于所有匹配的服务。 例如，在 Kubernetes 中，在 `VirtualService` 中使用 `*.foo.svc.cluster.local` 作为 host , 可以对 `foo` 命名空间中的所有服务应用相同的重写规则。
1. 通过使用带通配符前缀的 DNS 来指定 `VirtualService` 的 host，可以创建单个规则以作用于所有匹配的服务。例如，在 Kubernetes 中，在 `VirtualService` 中使用 `*.foo.svc.cluster.local` 作为 host , 可以对 `foo` 命名空间中的所有服务应用相同的重写规则。
### `DestinationRule`
[`DestinationRule`](/zh/docs/reference/config/networking/destination-rule/) 配置将流量转发到服务时应用的策略集。 这些策略应由服务提供者撰写，用于描述断路器，负载均衡设置，TLS 设置等。
[`DestinationRule`](/zh/docs/reference/config/networking/destination-rule/) 配置将流量转发到服务时应用的策略集。这些策略应由服务提供者撰写，用于描述断路器，负载均衡设置，TLS 设置等。
除了下述改变外，`DestinationRule` 与其前身 `DestinationPolicy` 大致相同。
1. `DestinationRule` 的 `host` 可以包含通配符前缀，以允许单个规则应用于多个服务。
1. `DestinationRule` 定义了目的 host 的子集 `subsets` （例如：命名版本）。 这些 subset 用于 `VirtualService` 的路由规则设置中，可以将流量导向服务的某些特定版本。 通过这种方式为版本命名后，可以在不同的 virtual service 中明确地引用这些命名版本的 subset，简化 Istio 代理发出的统计数据，并可以将 subset 编码到 SNI 头中。
1. `DestinationRule` 定义了目的 host 的子集 `subsets` （例如：命名版本）。这些 subset 用于 `VirtualService` 的路由规则设置中，可以将流量导向服务的某些特定版本。通过这种方式为版本命名后，可以在不同的 virtual service 中明确地引用这些命名版本的 subset，简化 Istio 代理发出的统计数据，并可以将 subset 编码到 SNI 头中。
为 reviews 服务配置策略和 subsets 的 `DestinationRule` 可能如下所示：
{{< text yaml >}}
@ -249,7 +249,7 @@ spec:
[`ServiceEntry`](/zh/docs/reference/config/networking/service-entry/) 用于将附加条目添加到 Istio 内部维护的服务注册表中。
它最常用于对访问网格外部依赖的流量进行建模，例如访问 Web 上的 API 或遗留基础设施中的服务。
所有以前使用 `EgressRule` 进行配置的内容都可以通过 `ServiceEntry` 轻松完成。 例如，可以使用类似这样的配置来允许从网格内部访问一个简单的外部服务：
所有以前使用 `EgressRule` 进行配置的内容都可以通过 `ServiceEntry` 轻松完成。例如，可以使用类似这样的配置来允许从网格内部访问一个简单的外部服务：
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
@ -308,11 +308,11 @@ $ kubectl apply -f my-updated-rules-for-destination-abc.yaml
通过使用`kubectl apply`更新现有资源，也可以删除特定目的地的最后一个路径规则。
在添加或删除引用服务版本的路由时，需要在该服务相应的 `DestinationRule` 更新 `subsets` 。 正如你可能猜到的，这也是使用 `kubectl apply` 完成的。
在添加或删除引用服务版本的路由时，需要在该服务相应的 `DestinationRule` 更新 `subsets` 。正如你可能猜到的，这也是使用 `kubectl apply` 完成的。
## 总结{#summary}
Istio `v1alpha3` 路由 API 具有比其前身更多的功能，但不幸的是新的 API 并不向后兼容，旧的模型升级需要一次手动转换。 Istio 0.9 以后将不再支持 `RouteRule`，`DesintationPolicy` 和 `EgressRule` 这些以前的配置资源 。Kubernetes 用户可以继续使用 `Ingress` 配置边缘负载均衡器来实现基本的路由。 但是，高级路由功能（例如，跨两个版本的流量分割）则需要使 `用 Gateway` ，这是一种功能更强大，Istio 推荐的 `Ingress` 替代品。
Istio `v1alpha3` 路由 API 具有比其前身更多的功能，但不幸的是新的 API 并不向后兼容，旧的模型升级需要一次手动转换。Istio 0.9 以后将不再支持 `RouteRule`，`DesintationPolicy` 和 `EgressRule` 这些以前的配置资源 。Kubernetes 用户可以继续使用 `Ingress` 配置边缘负载均衡器来实现基本的路由。但是，高级路由功能（例如，跨两个版本的流量分割）则需要使 `用 Gateway` ，这是一种功能更强大，Istio 推荐的 `Ingress` 替代品。
## 致谢{#acknowledgments}

2
content/zh/blog/2019/announcing-discuss.istio.io/index.md
View File

@ -9,7 +9,7 @@ aliases:
我们在 Istio 论坛中一直努力寻找合适的方法，让用户与论坛的其他成员进行互动、交流，寻求其他用户的帮助，以及与该项目的开发者进行沟通。
我们尝试了几种不同的途径，但是每种途径都有一些不足。 RocketChat 是我们最近的工作，但是缺少某些功能（例如，线程方面），意味着它不再适合围绕任何单一问题进行讨论。这也给一些用户带来了困惑：什么时候应该向 `istio-users@googlegroups.com` 发送电子邮件，什么时候又该使用 RocketChat ？
我们尝试了几种不同的途径，但是每种途径都有一些不足。RocketChat 是我们最近的工作，但是缺少某些功能（例如，线程方面），意味着它不再适合围绕任何单一问题进行讨论。这也给一些用户带来了困惑：什么时候应该向 `istio-users@googlegroups.com` 发送电子邮件，什么时候又该使用 RocketChat ？
我们认为我们已经在单一的平台上找到了正确平衡功能，因此我们很高兴地宣布 [discuss.istio.io](https://discuss.istio.io) 论坛成立啦。这是一个功能全面的论坛，我们将从这里开始对 Istio 进行讨论沟通，它允许你提出问题并获得主题回复！真正的好处是，你可以使用你的 GitHub 身份进行这些操作。

4
content/zh/blog/2019/announcing-istio-client-go/index.md
View File

@ -67,14 +67,14 @@ func main() {
}
{{< /text >}}
您可以在[这里](https://github.com/istio/client-go/blob/{{<source_branch_name >}}/cmd/example/client.go) 找到更详尽的示例。
您可以在[这里](https://github.com/istio/client-go/blob/{{<source_branch_name>}}/cmd/example/client.go)找到更详尽的示例。
## 为生成 Istio client go 而创建的工具{#useful-tools-created-for-generating-Istio-client-go}
如果您想知道为什么花费大量时间也很难生成此客户端，本小节将对此进行说明。在 `Istio` 中，我们使用 [protobuf](https://developers.google.com/protocol-buffers) 规范编写 `API`，然后使用 `protobuf` 工具链将其转换为 `Go` 定义。如果尝试从 `protobuf` 的 `API` 生成 `Kubernetes` 客户端，可能会面临三个主要的挑战：
* **创建 Kubernetes 装饰器类型** - Kubernetes [客户端生成库](https://github.com/kubernetes/code-generator/tree/master/cmd/client-gen)
仅适用于遵循 `Kubernetes` 对象规范的 `Go` 对象， 例如： [Authentication Policy Kubernetes Wrappers](https://github.com/istio/client-go/blob/{{< source_branch_name >}}/pkg/apis/authentication/v1alpha1/types.gen.go)。这意味着对于需要程序访问的每个 API，您都需要创建这些装饰器。此外，每个 `CRD` 组，版本和种类都需要大量的样板，需要用客户端代码生成。为了自动化该过程，我们创建了一个 [Kubernetes type
仅适用于遵循 `Kubernetes` 对象规范的 `Go` 对象，例如：[Authentication Policy Kubernetes Wrappers](https://github.com/istio/client-go/blob/{{< source_branch_name >}}/pkg/apis/authentication/v1alpha1/types.gen.go)。这意味着对于需要程序访问的每个 API，您都需要创建这些装饰器。此外，每个 `CRD` 组，版本和种类都需要大量的样板，需要用客户端代码生成。为了自动化该过程，我们创建了一个 [Kubernetes type
generator](https://github.com/istio/tools/tree/master/cmd/kubetype-gen) 工具，可以基于注释去自动创建 `Kubernetes`类型。该工具的注释和各种可用选项在 [README](https://github.com/istio/tools/blob/master/cmd/kubetype-gen/README.md) 中进行了说明。请注意，如果您使用 `protobuf` 工具生成 `Go` 类型，则需要将这些注释添加到 `proto` 文件中，以便注释出现在生成的 `Go` 文件中，然后供该工具使用。
* **生成 deep copy 方法** - 在 `Kubernetes` 客户端机制中，如果您想对从客户端集返回的任何对象进行修改，则需要创建该对象的副本以防止直接修改缓存中的对象。为了不直接修改缓存中的对象，我们一般是在所有嵌套类型上创建一个 `deep copy` 方法。我们开发了一个 [protoc deep copy

2
content/zh/blog/2019/egress-performance/index.md
View File

@ -75,7 +75,7 @@ target_release: 1.0
## 环境{#environment}
* Istio 版本： 1.0.2
* Istio 版本：1.0.2
* `K8s` 版本：`1.10.5_1517`
* Acmeair 应用：4 个服务（每个服务一个实例），跨服务事务，外部 MongoDB，平均载荷：620 字节。

6
content/zh/blog/2019/egress-traffic-control-in-istio-part-1/index.md
View File

@ -22,7 +22,7 @@ _1.2.1 将入口和出口流量限制为持卡人数据环境所必需的流量
特别是对出口流量：
{{< quote >}}
_1.3.4 不允许持卡人数据环境没有授权的出站流量进入互联网。。。持卡人数据环境流出的所有流量应该做评估，以保证流量符合既定的授权规则。应该检查链接上的流量并限制只允许认证过的通信（例如：通过限制源/目的的地址/端口，包括限制传输内容）。_
_1.3.4 不允许持卡人数据环境没有授权的出站流量进入互联网。持卡人数据环境流出的所有流量应该做评估，以保证流量符合既定的授权规则。应该检查链接上的流量并限制只允许认证过的通信（例如：通过限制源/目的的地址/端口，包括限制传输内容）。_
{{< /quote >}}
我们从涉及出口流量的攻击开始。
@ -61,7 +61,7 @@ Istio 1.1 满足所有的收集要求：
必须阻止所有未明确的访问。
1. 定义和执行**每个源的策略**， _Kubernetes 可感知_：
1. 定义和执行**每个源的策略**，_Kubernetes 可感知_：
* 应用 `A` 可能访问 `*.foo.com`。
@ -78,7 +78,7 @@ Istio 1.1 满足所有的收集要求：
第二个要求指出：必须监控 SNI 和流量源。监控是防止攻击的第一步。即使攻击者可以从集群内访问外部服务，如果监控了访问请求，就会有机会发现可疑流量并且采取纠正措施。
注意如果是应用程序发起的 TLS，Istio 的 sidecar 代理就只能看到 TCP 流量和包含 SNI 的 TLS 握手。 源 pod 的标签可以识别出流量来源，但是 pod 的服务账号或者其它源识标识符也可以用来识别流量。我们把出口流量管控系统的这个特性叫做 _Kubernetes 可感知_：这个系统必须理解 Kubernetes 组件，比如 pod 和服务账号。如果这个系统不是 Kubernetes 可感知的，那它只能监控 IP 地址，并把它作为源的标示。
注意如果是应用程序发起的 TLS，Istio 的 sidecar 代理就只能看到 TCP 流量和包含 SNI 的 TLS 握手。源 pod 的标签可以识别出流量来源，但是 pod 的服务账号或者其它源识标识符也可以用来识别流量。我们把出口流量管控系统的这个特性叫做 _Kubernetes 可感知_：这个系统必须理解 Kubernetes 组件，比如 pod 和服务账号。如果这个系统不是 Kubernetes 可感知的，那它只能监控 IP 地址，并把它作为源的标示。
第三个要求指出：Istio 运维人员必须能为整个集群所有的出口流量定规策略。策略指出集群中的 pod 可能会访问哪些外部服务。外部服务可以通过服务的[全域名](https://en.wikipedia.org/wiki/Fully_qualified_domain_name) （比如 `www.ibm.com`）或者泛域名（比如：`*.ibm.com`）进行标示。只有指定的外部服务可以访问，其它所有的出口流量都要被阻止。

4
content/zh/blog/2019/egress-traffic-control-in-istio-part-2/index.md
View File

@ -22,7 +22,7 @@ target_release: 1.2
如果应用程序发送 HTTP 请求，并且由出口网关发起执行 TLS，你就可以监控 HTTP 信息，像 HTTP 方法、HTTP 头和 URL 路径。也可以根据上面说的 HTTP 信息来[定义策略](/zh/blog/2018/egress-monitoring-access-control)。如果是由应用程序发起执行 TLS，你就可以对源 pod 的 TLS 流量的 [SNI 和服务账号进行监控](/zh/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/)，并且基于 SNI 和服务账号定义策略。
你必须确保你集群到外部的流量不能绕过出口网关。Istio 不能给你确保这一点，所以你必需使用一些[附加的安全机制](/zh/docs/tasks/traffic-management/egress/egress-gateway/#additional-security-considerations)，比如 [Kubernetes 网络策略](https://kubernetes.io/docs/concepts/services-networking/network-policies/)或者 L3 防火墙。 看一个 [Kubernetes 网络策略配置](/zh/docs/tasks/traffic-management/egress/egress-gateway/#apply-Kubernetes-network-policies)的例子。
你必须确保你集群到外部的流量不能绕过出口网关。Istio 不能给你确保这一点，所以你必需使用一些[附加的安全机制](/zh/docs/tasks/traffic-management/egress/egress-gateway/#additional-security-considerations)，比如 [Kubernetes 网络策略](https://kubernetes.io/docs/concepts/services-networking/network-policies/)或者 L3 防火墙。看一个 [Kubernetes 网络策略配置](/zh/docs/tasks/traffic-management/egress/egress-gateway/#apply-Kubernetes-network-policies)的例子。
根据[纵深防御](https://en.wikipedia.org/wiki/Defense_in_depth_(computing))的概念，为同一个目标使用的安全机制越多越安全。
你也必需也要确保 Istio 控制平面和出口网关不能被破坏。你的集群里面可能有成百上千的应用程序 pod，而只有十几个 Istio 控制平面 pod 和网关。
@ -38,7 +38,7 @@ target_release: 1.2
一旦你通过出口网关引导了出口流量，并且应用了附加的安全机制，就可以进行安全的监控和施加对流量的安全策略。
下图展示了 Istio 的安全架构，用 L3 防火墙进行了加强， L3 防火墙就是[附加安全机制](/zh/docs/tasks/traffic-management/egress/egress-gateway/#additional-security-considerations)的一部分，它应该在 Istio 的外面。
下图展示了 Istio 的安全架构，用 L3 防火墙进行了加强，L3 防火墙就是[附加安全机制](/zh/docs/tasks/traffic-management/egress/egress-gateway/#additional-security-considerations)的一部分，它应该在 Istio 的外面。
{{< image width="80%" link="./SecurityArchitectureWithL3Firewalls.svg" caption="带有出口网关和 L3 防火钱的 Istio 安全架构" >}}

4
content/zh/blog/2019/egress-traffic-control-in-istio-part-3/index.md
View File

@ -21,7 +21,7 @@ target_release: 1.2
1. 用 [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication) 或者用 [TLS 源](/zh/docs/reference/glossary/#tls-origination)来支持 [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security)。
1. **监控** SNI 和每个出口访问的 workload 源。
1. 定义和执行 **每个集群的策略**。
1. 定义和执行 **每个源的策略**， Kubernetes 可感知。
1. 定义和执行 **每个源的策略**，Kubernetes 可感知。
1. **阻止篡改**。
1. 对应用程序来说流量管控是 **透明的**。
@ -46,7 +46,7 @@ Istio 出口流量管控对 TLS 流量是 **透明的**，因为 Istio 是透明
Istio 出口流量管控是 **Kubernetes 可感知的**：出口流量源的身份是基于 Kubernetes 服务账号的。Istio 出口流量管控比现有的 DNS 感知的代理或者防火墙要好，因为它们都是不透明的，也不是 Kubernetes 可感知的。
Istio 出口流量管控是 **安全的**：它基于 Istio 的强身份认证， 当使用[附加安全措施](/zh/docs/tasks/traffic-management/egress/egress-gateway/#additional-security-considerations)时，Istio 的流量管控具有防篡改功能。
Istio 出口流量管控是 **安全的**：它基于 Istio 的强身份认证，当使用[附加安全措施](/zh/docs/tasks/traffic-management/egress/egress-gateway/#additional-security-considerations)时，Istio 的流量管控具有防篡改功能。
另外，Istio 的出口流量管控提供了以下的优势：

2
content/zh/blog/2019/isolated-clusters/index.md
View File

@ -21,7 +21,7 @@ target_release: 1.3
将敏感数据环境与其他信息系统隔离可以减少合规性检查的范围并提高敏感数据的安全性。缩小范围可降低合规性检查失败的风险，并降低合规性成本，因为根据合规性要求，要检查和保护的组件较少。
通过将处理数据的应用程序各部分分离到单独的服务网格中（最好也是在单独的网络上），然后将具有不同合规性要求的网格连接到 {{< gloss "multi-mesh" >}}多网格{{< /gloss >}} 部署中，可以实现敏感数据的隔离。 连接网间应用程序的过程称为 {{< gloss "mesh federation" >}}网格联邦{{< /gloss >}}。
通过将处理数据的应用程序各部分分离到单独的服务网格中（最好也是在单独的网络上），然后将具有不同合规性要求的网格连接到 {{< gloss "multi-mesh" >}}多网格{{< /gloss >}} 部署中，可以实现敏感数据的隔离。连接网间应用程序的过程称为 {{< gloss "mesh federation" >}}网格联邦{{< /gloss >}}。
请注意，使用网格联邦来创建多网格部署与创建 {{< gloss "multicluster" >}}多集群{{< /gloss >}} 部署非常不同，后者定义了一个由跨多个群集的服务组成的单个服务网格。与多网格不同，多群集部署不适用于需要隔离和边界保护的应用程序。

2
content/zh/blog/2019/knative-activator-adapter/index.md
View File

@ -38,7 +38,7 @@ Mixer 是一个属性处理引擎，它使用面向操作员（operator-supplied
{{< image width="60%" link="knative-mixer-adapter.png" caption="Knative scale-from-zero" >}}
在这种设计中，无需像 Knative 原有的设置中那样为空闲应用程序更改到 **Activator** 的路由。当由 Istio 代理（ingress gateway）收到对空闲应用程序的新请求时，它将通知 Mixer，包括所有相关的元数据信息。 然后 Mixer 调用您的适配器，该适配器使用 Knative 原有的协议触发 Knative Autoscaler。
在这种设计中，无需像 Knative 原有的设置中那样为空闲应用程序更改到 **Activator** 的路由。当由 Istio 代理（ingress gateway）收到对空闲应用程序的新请求时，它将通知 Mixer，包括所有相关的元数据信息。然后 Mixer 调用您的适配器，该适配器使用 Knative 原有的协议触发 Knative Autoscaler。
{{< idea >}}
通过使用这种设计，您不需要处理缓存，重试和负载平衡，因为 Istio 代理已经处理了这些。

2
content/zh/blog/2019/monitoring-external-service-traffic/index.md
View File

@ -125,7 +125,7 @@ Istio 控制平面使用了预定义集群 BlackHoleCluster 和 Passthrough 来
## 使用增强指标{#using-the-augmented-metrics}
要捕获两种情况（ BlackHole 或 Passthrough）中的所有外部服务流量，你将需要监控 `istio_requests_total` 和 `istio_tcp_connections_closed_total` 指标。
要捕获两种情况（BlackHole 或 Passthrough）中的所有外部服务流量，你将需要监控 `istio_requests_total` 和 `istio_tcp_connections_closed_total` 指标。
根据 Envoy 监听器的类型，即被调用的 TCP 代理或 HTTP 代理，将增加相应的指标。
此外，如果使用 TCP 代理监听器以查看被 BlackHole 阻止或被 Passthrough 透传的外部服务的 IP 地址，

14
content/zh/blog/2020/wasm-announce/index.md
View File

@ -9,7 +9,7 @@ keywords: [wasm,extensibility,alpha,performance,operator]
自 2016 年使用 [Envoy](https://www.envoyproxy.io/) 以后，Istio 项目一直想提供一个平台，在此平台上可以构建丰富的扩展，以满足用户多样化的需求。有很多要向服务网格的数据平面增加功能的理由 --- 比如：支持更新的协议，与专有安全控件集成，或是通过自定义度量来增强可观察性。
在过去的一年半中，我们在 Google 的团队一直在努力用 [WebAssembly](https://webassembly.org/) 来为 Envoy 代理添加动态扩展。今天我们很高兴与大家分享这项工作，并推出 [针对代理的 WebAssembly (Wasm)](https://github.com/proxy-wasm/spec) (Proxy-Wasm)：包括一个会标准化的 ABI，SDK，以及它的第一个重点实现：新的，低延迟的 [Istio 遥测系统](/zh/docs/reference/config/telemetry)。
在过去的一年半中，我们在 Google 的团队一直在努力用 [WebAssembly](https://webassembly.org/) 来为 Envoy 代理添加动态扩展。今天我们很高兴与大家分享这项工作，并推出[针对代理的 WebAssembly (Wasm)](https://github.com/proxy-wasm/spec) (Proxy-Wasm)：包括一个会标准化的 ABI，SDK，以及它的第一个重点实现：新的，低延迟的 [Istio 遥测系统](/zh/docs/reference/config/telemetry)。
我们还与社区紧密合作，以确保为用户提供良好的开发者体验，帮助他们快速上手。Google 团队一直与 [Solo.io](https://solo.io) 团队紧密合作，Solo 他们已经建立了 [WebAssembly Hub](https://webassemblyhub.io/) 服务，用于构建，共享，发现和部署 Wasm 扩展。有了 WebAssembly Hub，Wasm 扩展就会像容器一样易于管理，安装和运行。
@ -33,7 +33,7 @@ Envoy 模型强化了单体构建过程，并要求使用 C++ 编写扩展，从
## 把 WebAssembly 引入 Envoy {#bringing-WebAssembly-to-Envoy}
[在过去的18个月中](https://github.com/envoyproxy/envoy/issues/4272)，我们一直与 Envoy 社区合作把 Wasm 的扩展引入 Envoy，并将其贡献到上游。我们很高兴地宣布，此特性在 [Istio 1.5](/zh/news/releases/1.5.x/announcing-1.5/) 自带的 Envoy 中以 Alpha 版本可用了，其源代码在 [`envoy-wasm`](https://github.com/envoyproxy/envoy-wasm/) 开发分支中，并且正在努力将其合并到 Envoy 主干上。该实现使用了 Google 高性能 [V8 引擎](https://v8.dev/) 中内置的 WebAssembly 运行时。
[在过去的 18 个月中](https://github.com/envoyproxy/envoy/issues/4272)，我们一直与 Envoy 社区合作把 Wasm 的扩展引入 Envoy，并将其贡献到上游。我们很高兴地宣布，此特性在 [Istio 1.5](/zh/news/releases/1.5.x/announcing-1.5/) 自带的 Envoy 中以 Alpha 版本可用了，其源代码在 [`envoy-wasm`](https://github.com/envoyproxy/envoy-wasm/) 开发分支中，并且正在努力将其合并到 Envoy 主干上。该实现使用了 Google 高性能 [V8 引擎](https://v8.dev/)中内置的 WebAssembly 运行时。
除了构建底层的运行时，我们还构建了：
@ -45,17 +45,17 @@ Envoy 模型强化了单体构建过程，并要求使用 C++ 编写扩展，从
使用 Wasm 扩展 Envoy 带来了几个主要好处：
- 敏捷性：可以用 Istio 控制平面在运行时下发和重载扩展。这就可以快速的进行扩展开发→测试→发布周期，而无需重启 Envoy。
- 敏捷性：可以用 Istio 控制平面在运行时下发和重载扩展。这就可以快速的进行扩展开发→ 测试→ 发布周期，而无需重启 Envoy。
- 发布库：一旦完成合并到主树中之后，Istio 和其它程序将能够使用 Envoy 的发布库，而不是自己构建。这也方便 Envoy 社区迁移某些内置扩展到这个模型，从而减少他们的工作。
- 可靠性和隔离性：扩展部署在具有资源限制的沙箱中，这意味着它们现在可以崩溃或泄漏内存，但不会让整个 Envoy 挂掉。CPU 和内存使用率也可以受到限制。
- 安全性：沙盒具有一个明确定义的 API，用于和 Envoy 通信，因此扩展只能访问和修改链接或者请求中有限数量的属性。此外，由于 Envoy 协调整个交互，因此它可以隐藏或清除扩展中的敏感信息（例如，HTTP 头中的 “Authorization”和“Cookie”，或者客户端的 IP 地址）。
- 灵活性：[可以将超过 30 种编程语言编译为 WebAssembly](https://github.com/appcypher/awesome-wasm-langs)，可以让各种技术背景的开发人员都可以用他们选择的语言来编写 Envoy 扩展，比如：C++，Go，Rust，Java，TypeScript 等。
“看到 Envoy 上支持了 WASM，我感到非常兴奋；这是 Envoy 可扩展的未来。Envoy 的 WASM 支持与社区驱动的 hub 相结合，将在服务网格和 API 网关用例中开启出令人难以置信的网络创新。 我迫不及待地想看到社区构建是如何向前发展的。” – Envoy 创造者 Matt Klein。
“看到 Envoy 上支持了 WASM，我感到非常兴奋；这是 Envoy 可扩展的未来。Envoy 的 WASM 支持与社区驱动的 hub 相结合，将在服务网格和 API 网关用例中开启出令人难以置信的网络创新。我迫不及待地想看到社区构建是如何向前发展的。” – Envoy 创造者 Matt Klein。
有关实现的技术细节，请关注即将在 [Envoy 博客](https://blog.envoyproxy.io/)上发的文章。
主机环境和扩展之间的 [Proxy-Wasm](https://github.com/proxy-wasm)接口有意设计为代理无感知的。我们已将其内置到了 Envoy 中，但它是为其它代理供应商设计的。我们希望看为 Istio 和 Envoy 编写的扩展也可以在其它基础设施中运行。很快就会有更多相关的设计和实现了。
主机环境和扩展之间的 [Proxy-Wasm](https://github.com/proxy-wasm) 接口有意设计为代理无感知的。我们已将其内置到了 Envoy 中，但它是为其它代理供应商设计的。我们希望看为 Istio 和 Envoy 编写的扩展也可以在其它基础设施中运行。很快就会有更多相关的设计和实现了。
## Istio 中的 WebAssembly 构建 {#building-on-WebAssembly-in-Istio}
@ -83,10 +83,10 @@ WebAssembly Hub 工具提供了功能强大的 CLI 和优雅且易于使用的
## 了解更多 {#learn-more}
- WebAssembly SF talk (视频): [网络代理扩展](https://www.youtube.com/watch?v=OIUPf8m7CGA), by John Plevyak
- WebAssembly SF talk (视频) : [网络代理扩展](https://www.youtube.com/watch?v=OIUPf8m7CGA), by John Plevyak
- [Solo 博客](https://www.solo.io/blog/an-extended-and-improved-webassembly-hub-to-helps-bring-the-power-of-webassembly-to-envoy-and-istio/)
- [Proxy-Wasm ABI 说明](https://github.com/proxy-wasm/spec)
- [Proxy-Wasm C++ SDK](https://github.com/proxy-wasm/proxy-wasm-cpp-sdk/blob/master/docs/wasm_filter.md) 和其 [开发者文档](https://github.com/proxy-wasm/proxy-wasm-cpp-sdk/blob/master/docs/wasm_filter.md)
- [Proxy-Wasm C++ SDK](https://github.com/proxy-wasm/proxy-wasm-cpp-sdk/blob/master/docs/wasm_filter.md) 和其[开发者文档](https://github.com/proxy-wasm/proxy-wasm-cpp-sdk/blob/master/docs/wasm_filter.md)
- [Proxy-Wasm Rust SDK](https://github.com/proxy-wasm/proxy-wasm-rust-sdk)
- [Proxy-Wasm AssemblyScript SDK](https://github.com/solo-io/proxy-runtime)
- [指南](https://docs.solo.io/web-assembly-hub/latest/tutorial_code/)

18
content/zh/docs/concepts/security/index.md
View File

@ -25,13 +25,13 @@ Istio Security 尝试提供全面的安全解决方案来解决所有这些问
{{< image width="80%" link="./overview.svg" caption="Istio 安全概述" >}}
Istio 安全功能提供强大的身份，强大的策略，透明的 TLS 加密以及用于保护您的服务和数据的身份验证，授权和审计（AAA）工具。 Istio 安全的目标是：
Istio 安全功能提供强大的身份，强大的策略，透明的 TLS 加密以及用于保护您的服务和数据的身份验证，授权和审计（AAA）工具。Istio 安全的目标是：
- **默认安全**： 应用程序代码和基础结构无需更改
- **默认安全**：应用程序代码和基础结构无需更改
- **深度防御**： 与现有安全系统集成，提供多层防御
- **深度防御**：与现有安全系统集成，提供多层防御
- **零信任网络**： 在不受信任的网络上构建安全解决方案
- **零信任网络**：在不受信任的网络上构建安全解决方案
请访问我们的[双向 TLS 迁移](/zh/docs/tasks/security/authentication/mtls-migration/)相关文章，开始在部署的服务中使用 Istio 安全功能。
请访问我们的[安全任务](/zh/docs/tasks/security/)，以获取有关使用安全功能的详细说明。
@ -60,15 +60,15 @@ Istio 中的安全性涉及多个组件：
不同平台上的 Istio 服务标识：
- **Kubernetes**： Kubernetes 服务帐户
- **Kubernetes**：Kubernetes 服务帐户
- **GKE/GCE**： 可以使用 GCP 服务帐户
- **GKE/GCE**：可以使用 GCP 服务帐户
- **GCP**： GCP 服务帐户
- **GCP**：GCP 服务帐户
- **AWS**： AWS IAM 用户/角色帐户
- **AWS**：AWS IAM 用户/角色帐户
- **本地（非 Kubernetes）**： 用户帐户、自定义服务帐户、服务名称、Istio 服务帐户或 GCP 服务帐户。
- **本地（非 Kubernetes）**：用户帐户、自定义服务帐户、服务名称、Istio 服务帐户或 GCP 服务帐户。
自定义服务帐户引用现有服务帐户，就像客户的身份目录管理的身份一样。

2
content/zh/docs/examples/microservices-istio/setup-local-computer/index.md
View File

@ -31,7 +31,7 @@ weight: 3
您应该在输出中看到命名空间的名称，该命名空间由讲师分配或者在上一个模块中由您自己分配。
1. 下载一个 [Istio 发行版](https://github.com/istio/istio/releases) ，从 `bin` 目录下提出命令行工具 `istioctl`， 使用下边的命令验证 `istioctl` 是否可以正常使用：
1. 下载一个 [Istio 发行版](https://github.com/istio/istio/releases) ，从 `bin` 目录下提出命令行工具 `istioctl`，使用下边的命令验证 `istioctl` 是否可以正常使用：
{{< text bash >}}
$ istioctl version

8
content/zh/docs/examples/microservices-istio/single/index.md
View File

@ -28,7 +28,7 @@ weight: 10
请按照下列步骤下载应用程序的代码，安装其依赖项，然后在本地运行它：
1. 将[服务代码]({{<github_blob >}}/samples/bookinfo/src/ratings/ratings.js) 和
1. 将[服务代码]({{<github_blob>}}/samples/bookinfo/src/ratings/ratings.js)和
[其 package 文件]({{< github_blob >}}/samples/bookinfo/src/ratings/package.json)
下载到一个单独的目录中：
@ -49,12 +49,12 @@ weight: 10
- 状态码
{{< tip >}}
在 Node.js 中，web 服务器的功能嵌入在应用程序的代码中。 一个 Node.js web 应用程序作为一个独立进程运行。
在 Node.js 中，web 服务器的功能嵌入在应用程序的代码中。一个 Node.js web 应用程序作为一个独立进程运行。
{{< /tip >}}
1. Node.js 应用程序是用 JavaScript 编写的，这意味着没有显式编译步骤。相反，它们
使用 [just-in-time 即时编译](https://zh.wikipedia.org/wiki/%E5%8D%B3%E6%97%B6%E7%BC%96%E8%AF%91)。要
构建 Node.js 应用程序， 则意味着要安装其依赖库。 将 `rating` 服务的依赖库安装在存储服务代码和 package 文件的同一目录下：
构建 Node.js 应用程序，则意味着要安装其依赖库。将 `rating` 服务的依赖库安装在存储服务代码和 package 文件的同一目录下：
{{< text bash >}}
$ npm install
@ -66,7 +66,7 @@ weight: 10
added 24 packages in 2.094s
{{< /text >}}
1. 通过传递 `9080` 参数来运行服务， 然后应用程序在 9080 端口上监听。
1. 通过传递 `9080` 参数来运行服务，然后应用程序在 9080 端口上监听。
{{< text bash >}}
$ npm start 9080

2
content/zh/docs/examples/virtual-machines/multi-network/index.md
View File

@ -193,7 +193,7 @@ aliases:
因为 DNS 解析 `*.global` 域上的服务，您需要为这些服务分配一个 IP 地址。
{{< tip >}}
各个服务（ `*.global` DNS 域中）必须在集群中有一个唯一的 IP。
各个服务（`*.global` DNS 域中）必须在集群中有一个唯一的 IP。
{{< /tip >}}
如果全局服务已经有真正的 VIPs，您可以使用它们，否则我们建议使用来自回环段 `127.0.0.0/8` 的还未分配的 IPs 。这些 IPs 在 pod 外不能路由。

2
content/zh/docs/examples/virtual-machines/single-network/index.md
View File

@ -23,7 +23,7 @@ aliases:
这通常需要 VPC 或者 VPN，以及需要提供直接（没有 NAT 或者防火墙拒绝访问）
路由到 endpoint 的容器网络。虚拟机不需要访问 Kubernetes 分配的集群 IP 地址。
- VM 必须有权访问 DNS 服务， 将名称解析为集群 IP 地址。
- VM 必须有权访问 DNS 服务，将名称解析为集群 IP 地址。
选项包括通过内部负载均衡器，使用 [Core DNS](https://coredns.io/) 服务公开的 Kubernetes DNS 服务器，或者在可从 VM 中访问的任何其他 DNS 服务器中配置 IP。
具有以下说明：

4
content/zh/docs/ops/common-problems/injection/index.md
View File

@ -187,7 +187,7 @@ env:
value: 127.0.0.1,localhost,dockerhub.foo.com,devhub-docker.foo.com,10.84.100.125,10.84.100.126,10.84.100.127
{{< /text >}}
使用这些设置，sidecar 自动注入就会失败。 相关的报错可以在 `kube-apiserver` 日志中找到：
使用这些设置，sidecar 自动注入就会失败。相关的报错可以在 `kube-apiserver` 日志中找到：
{{< text plain >}}
W0227 21:51:03.156818 1 admission.go:257] Failed calling webhook, failing open sidecar-injector.istio.io: failed calling admission webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-system.svc:443/inject: Service Unavailable
@ -195,7 +195,7 @@ W0227 21:51:03.156818 1 admission.go:257] Failed calling webhook, failing
根据 `*_proxy` 相关的的环境变量设置，确保 pod 和 service CIDRs 是没有被代理的。检查 `kube-apiserver` 的运行日志验证是否有请求正在被代理。
一种解决方法是在 `kube-apiserver` 的配置中删除代理设置，另一种解决方法是把 `istio-sidecar-injector.istio-system.svc` 或者 `.svc` 加到 `no_proxy` 的 `value` 里面。 每种解决方法都需要重新启动 `kube-apiserver`。
一种解决方法是在 `kube-apiserver` 的配置中删除代理设置，另一种解决方法是把 `istio-sidecar-injector.istio-system.svc` 或者 `.svc` 加到 `no_proxy` 的 `value` 里面。每种解决方法都需要重新启动 `kube-apiserver`。
Kubernetes 与此有关的一个 [issue](https://github.com/kubernetes/kubeadm/issues/666) 已被 [PR #58698](https://github.com/kubernetes/kubernetes/pull/58698#discussion_r163879443) 解决。

2
content/zh/docs/ops/common-problems/network-issues/index.md
View File

@ -114,7 +114,7 @@ spec:
此时你会发现，通过 ingress 网关访问 helloworld 服务的请求没有直接路由到服务实例子集 v1，而是仍然使用默认的轮询调度路由。
Ingress 请求经由网关主机（如： `myapp.com`）进行路由，网关主机将激活 myapp `VirtualService` 中的规则，将请求路由至 helloworld 服务的任何一个实例端点。
Ingress 请求经由网关主机（如：`myapp.com`）进行路由，网关主机将激活 myapp `VirtualService` 中的规则，将请求路由至 helloworld 服务的任何一个实例端点。
只有通过主机 `helloworld.default.svc.cluster.local` 访问的内部请求才会使用 helloworld `VirtualService`，其中的规则直接将流量路由至服务实例子集 v1。
为了控制从 gateway 过来的流量，你需要在 myapp `VirtualService` 的配置中包含 subset 规则配置：

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

@ -28,7 +28,7 @@ Mixer 安装中默认包含一个 Prometheus 适配器，适配器会收到一
### （如果需要）验证 Istio CNI pod 正在运行{#verify-Istio-CNI-pods-are-running}
在 Kubernetes Pod 生命周期设置网络期间，Istio CNI 插件会对 Istio 网格 Pod 执行流量重定向，从而用户在 Istio 网格中部署 Pod 时不需要 [`NET_ADMIN`能力需求](/zh/docs/ops/deployment/requirements/)。 Istio CNI 插件主要用来替代 `istio-init` 容器的一些功能。
在 Kubernetes Pod 生命周期设置网络期间，Istio CNI 插件会对 Istio 网格 Pod 执行流量重定向，从而用户在 Istio 网格中部署 Pod 时不需要 [`NET_ADMIN`能力需求](/zh/docs/ops/deployment/requirements/)。Istio CNI 插件主要用来替代 `istio-init` 容器的一些功能。
1. 验证 `istio-cni-node` pods 正在运行：

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

@ -124,7 +124,7 @@ webhooks:
校验配置如果失败会自动关闭，正常情况下配置存在并校验通过，webhook 将被调用。在资源创建或更新的时候，如果缺失 `caBundle`或者错误的证书，亦或网络连接问题都将会导致报错。如果你确信你的配置没有问题，webhook 没有被调用却看不到任何错误信息，你的集群配置肯定有问题。
## 创建配置失败报错： x509 certificate errors {#x509-certificate-errors}
## 创建配置失败报错：x509 certificate errors {#x509-certificate-errors}
`x509: certificate signed by unknown authority` 错误通常和 webhook 配置中的空 `caBundle` 有关，所以要确认它不为空 (请查阅[验证 webhook 配置](#invalid-configuration-is-accepted))。Istio 有意识的使用 `istio-validation` `configmap` 和根证书，调整了 webhook 配置。
@ -162,7 +162,7 @@ webhooks:
Istio 需要 `validatingwebhookconfigurations` 的写权限来创建和更新 `istio-galley validatingwebhookconfiguration` 配置项。
## 创建配置报错：`no such hosts` 、 `no endpoints available` {#creating-configuration-fail}
## 创建配置报错：`no such hosts` 、`no endpoints available` {#creating-configuration-fail}
如果 `istio-pilot` pod 没有准备就绪，配置是不会被创建或者更新的，在下面的例子里您可以看到关于 `no endpoints available` 的错误信息。

8
content/zh/docs/ops/configuration/mesh/app-health-check/index.md
View File

@ -91,13 +91,13 @@ liveness-6857c8775f-zdv9r 2/2 Running 0 4m
本部分介绍，当双向 TLS 认证开启的时候，如何使用 HTTP 请求方式来做健康检查。
Kubernetes 的 HTTP 健康检查是由 Kubelet 来发送的， 但是 Istio 并未颁发证书给 `liveness-http` 服务。 因此，当启用双向 TLS 认证之后，所有的健康检查请求将会失败。
Kubernetes 的 HTTP 健康检查是由 Kubelet 来发送的，但是 Istio 并未颁发证书给 `liveness-http` 服务。因此，当启用双向 TLS 认证之后，所有的健康检查请求将会失败。
有两种方式来解决此问题：探针重写和端口分离。
### 探针重写{#probe-rewrite}
这种方式重写了应用程序的 `PodSpec` Readiness 和 Liveness 探针， 以便将探针请求发送给
这种方式重写了应用程序的 `PodSpec` Readiness 和 Liveness 探针，以便将探针请求发送给
[Pilot agent](/zh/docs/reference/commands/pilot-agent/). Pilot agent 将请求重定向到应用程序，剥离 response body ，只返回 response code 。
有两种方式来让 Istio 重写 Liveness 探针。
@ -122,7 +122,7 @@ $ kubectl get cm istio-sidecar-injector -n istio-system -o yaml | sed -e 's/"rew
<!-- Add samples YAML or kubectl patch? -->
与安装 Istio 使用的参数方式相似，您也可以使用`sidecar.istio.io/rewriteAppHTTPProbers: "true"`来 [为 pod 添加 annotation](/zh/docs/reference/config/annotations/) 。确保 annotation 成功添加到了 [pod 资源](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) 因为在其他地方（比如封闭的部署资源上）， annotation 会被忽略。
与安装 Istio 使用的参数方式相似，您也可以使用`sidecar.istio.io/rewriteAppHTTPProbers: "true"`来 [为 pod 添加 annotation](/zh/docs/reference/config/annotations/) 。确保 annotation 成功添加到了 [pod 资源](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) 因为在其他地方（比如封闭的部署资源上），annotation 会被忽略。
{{< text yaml >}}
apiVersion: apps/v1
@ -172,7 +172,7 @@ NAME READY STATUS RESTARTS AGE
liveness-http-975595bb6-5b2z7c 2/2 Running 0 1m
{{< /text >}}
默认情况下未启用此功能。 我们希望[收到您的反馈](https://github.com/istio/istio/issues/10357)，
默认情况下未启用此功能。我们希望[收到您的反馈](https://github.com/istio/istio/issues/10357)，
是否应将其更改为 Istio 安装过程中的默认行为。
### 端口分离{#separate-port}

2
content/zh/docs/ops/configuration/mesh/webhook/index.md
View File

@ -10,7 +10,7 @@ aliases:
来自 [Kubernetes 准入控制机制](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)：
{{< tip >}}
准入 Webhook 是 HTTP 方式的回调，接收准入请求并对其进行相关操作。可定义两种类型的准入 Webhook，Validating 准入 Webhook 和 Mutating 准入 Webhook。 使用 Validating Webhook，可以通过自定义的准入策略来拒绝请求；使用 Mutating Webhook，可以通过自定义默认值来修改请求。
准入 Webhook 是 HTTP 方式的回调，接收准入请求并对其进行相关操作。可定义两种类型的准入 Webhook，Validating 准入 Webhook 和 Mutating 准入 Webhook。使用 Validating Webhook，可以通过自定义的准入策略来拒绝请求；使用 Mutating Webhook，可以通过自定义默认值来修改请求。
{{< /tip >}}
Istio 使用 `ValidatingAdmissionWebhooks` 验证 Istio 配置，使用 `MutatingAdmissionWebhooks` 自动将 Sidecar 代理注入至用户 Pod。

4
content/zh/docs/ops/deployment/deployment-models/index.md
View File

@ -105,7 +105,7 @@ Istio 支持跨多种网络拓扑扩展服务网格。
### 单一网络{#single-network}
在最简单的情况下，服务网格在单个完全连接的网络上运行。
在单一网络模型中， {{< gloss "workload instance" >}}工作负载实例{{< /gloss >}}
在单一网络模型中，{{< gloss "workload instance" >}}工作负载实例{{< /gloss >}}
都可以直接相互访问，而无需 Istio 网关。
单一网络模型允许 Istio 以统一的方式在网格上配置服务使用者，从而能够直接处理工作负载实例。
@ -262,7 +262,7 @@ Istio 支持将您的所有服务都放在一个{{< gloss "service mesh" >}}服
为避免服务命名冲突，可以为每个网格赋予全局唯一的 **mesh ID**，以确保每个服务的完全限定域名（FQDN）是不同的。
联合两个不共享同一{{< gloss "trust domain">}}信任域{{< /gloss >}}的网格时， 必须{{< gloss "mesh federation">}}
联合两个不共享同一{{< gloss "trust domain">}}信任域{{< /gloss >}}的网格时，必须{{< gloss "mesh federation">}}
联合{{< /gloss >}}身份标识和它们之间的 **trust bundles**。有关概述请参考[多信任域](#trust-between-meshes)部分。
## 租户模型{#tenancy-models}

2
content/zh/docs/ops/deployment/requirements/index.md
View File

@ -27,7 +27,7 @@ aliases:
- **Service 关联**: 每个 Pod 必须至少属于一个 Kubernetes Service，不管这个 Pod 是否对外暴露端口。如果一个 Pod 同时属于多个 [Kubernetes Service](https://kubernetes.io/docs/concepts/services-networking/service/)，
那么这些 Service 不能同时在一个端口号上使用不同的协议（比如：HTTP 和 TCP）。
- **带有 app 和 version 标签（label） 的 Deployment**: 我们建议显式地给 Deployment 加上 `app` 和 `version` 标签。给使用 Kubernetes
- **带有 app 和 version 标签（label）的 Deployment**: 我们建议显式地给 Deployment 加上 `app` 和 `version` 标签。给使用 Kubernetes
`Deployment` 部署的 Pod 部署配置中增加这些标签，可以给 Istio 收集的指标和遥测信息中增加上下文信息。
- `app` 标签：每个部署配置应该有一个不同的 `app` 标签并且该标签的值应该有一定意义。`app` label 用于在分布式追踪中添加上下文信息。

10
content/zh/docs/ops/diagnostic-tools/component-logging/index.md
View File

@ -32,7 +32,7 @@ Pilot、Citadel 和 Galley 具有它们自己的范围，你可以通过查看
1. info
1. debug
其中 `none` 不产生任何输出信息，并且 `debug` 产生的输出信息最多。 所有作用域的默认级别是 `info` ，为在正常情况下使用 Istio 提供大量的日志信息。
其中 `none` 不产生任何输出信息，并且 `debug` 产生的输出信息最多。所有作用域的默认级别是 `info` ，为在正常情况下使用 Istio 提供大量的日志信息。
要控制输出级别，也可以在命令行使用 `--log_output_level` 选项。例如：
@ -44,15 +44,15 @@ $ mixs server --log_output_level attributes=debug,adapters=warning
## 控制输出{#controlling-output}
日志信息通常发送到组件的标准输出。 `--log_target` 选项可以定向输出到许多不同的位置。你可以使用一个逗号分隔列表中的文件系统路径，以及分别表示标准输出和标准错误输出流的特殊值 `stdout` 和 `stderr` 。
日志信息通常发送到组件的标准输出。`--log_target` 选项可以定向输出到许多不同的位置。你可以使用一个逗号分隔列表中的文件系统路径，以及分别表示标准输出和标准错误输出流的特殊值 `stdout` 和 `stderr` 。
日志信息通常以友好的格式输出。 `--log_as_json` 选项可用于将输出强制转换为 JSON 格式，以便于更简单地被工具处理。
日志信息通常以友好的格式输出。`--log_as_json` 选项可用于将输出强制转换为 JSON 格式，以便于更简单地被工具处理。
## 日志轮转{#log-rotation}
Istio 组件可以自动管理日志的轮转，将庞大的日志分解为较小的日志文件。 `--log_rotate` 选项可以让你基于文件名进行轮转。派生名称将用于单个日志文件。
Istio 组件可以自动管理日志的轮转，将庞大的日志分解为较小的日志文件。`--log_rotate` 选项可以让你基于文件名进行轮转。派生名称将用于单个日志文件。
`--log_rotate_max_age` 选项可以在日志文件被轮转前指定最大天数，然而 `--log_rotate_max_size` 选项可以指定文件轮转之前的最大 size （以兆字节为单位）。最后， `--log_rotate_max_backups` 选项可以控制要保留的最大轮转文件数，较旧的文件将被自动删除。
`--log_rotate_max_age` 选项可以在日志文件被轮转前指定最大天数，然而 `--log_rotate_max_size` 选项可以指定文件轮转之前的最大 size （以兆字节为单位）。最后，`--log_rotate_max_backups` 选项可以控制要保留的最大轮转文件数，较旧的文件将被自动删除。
## 组件调试{#component-debugging}

2
content/zh/docs/reference/config/policy-and-telemetry/expression-language/index.md
View File

@ -11,7 +11,7 @@ aliases:
## 底层{#background}
Mixer 配置使用了一种表达式语言(CEXL) 去描述 match expressions 以及 [mapping expressions](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#attribute-expressions)。
CEXL 表达式为有类型的[值](https://github.com/istio/api/blob/{{<source_branch_name >}}/policy/v1beta1/value_type.proto) 映射了一组带类型的[属性](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes)和常量。
CEXL 表达式为有类型的[值](https://github.com/istio/api/blob/{{<source_branch_name>}}/policy/v1beta1/value_type.proto)映射了一组带类型的[属性](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes)和常量。
## 语法{#syntax}

2
content/zh/docs/reference/config/policy-and-telemetry/metrics/index.md
View File

@ -4,7 +4,7 @@ description: 通过 Mixer 从 Istio 导出的默认监控指标。
weight: 50
---
此页面展示使用初始配置时，Istio 收集的监控指标（metrics）的详细信息。这些指标是内置的，但您可以随时通过更改配置来添加和删除它们。您可以在[这个文件]({{<github_file >}}/manifests/UPDATING-CHARTS.md) 的 "kind: metric” 小节中找到它们。它使用了 [metric 模板](/zh/docs/reference/config/policy-and-telemetry/templates/metric/)来定义指标。
此页面展示使用初始配置时，Istio 收集的监控指标（metrics）的详细信息。这些指标是内置的，但您可以随时通过更改配置来添加和删除它们。您可以在[这个文件]({{<github_file>}}/manifests/UPDATING-CHARTS.md)的 "kind: metric” 小节中找到它们。它使用了 [metric 模板](/zh/docs/reference/config/policy-and-telemetry/templates/metric/)来定义指标。
我们将首先描述监控指标，然后描述每个指标的标签。

4
content/zh/docs/reference/config/policy-and-telemetry/mixer-overview/index.md
View File

@ -64,7 +64,7 @@ source.ip: [192 168 0 1]
destination.service.name: example
{{< /text >}}
Mixer 本质上是一种属性处理器。Envoy sidecar 为每个请求调用 Mixer，为 Mixer 提供一组属性，描述请求和请求所需环境。 根据其配置和给予的特定属性集，Mixer 生成对各种基础架构后端的调用。
Mixer 本质上是一种属性处理器。Envoy sidecar 为每个请求调用 Mixer，为 Mixer 提供一组属性，描述请求和请求所需环境。根据其配置和给予的特定属性集，Mixer 生成对各种基础架构后端的调用。
{{< image width="60%" link="./machine.svg" caption="Attribute Machine" >}}
@ -93,7 +93,7 @@ destination_version: destination.labels["version"] | "unknown"
destination_version: destination.labels["version"] | "unknown"
{{< /text >}}
通过上述操作，`destination_version` 标签被分配的值为 `destination.labels["version"]`。 但是，如果属性不存在，将使用 `"unknown"` 值。
通过上述操作，`destination_version` 标签被分配的值为 `destination.labels ["version"]`。但是，如果属性不存在，将使用 `"unknown"` 值。
有关更多信息，请参阅[属性表达式](/zh/docs/reference/config/policy-and-telemetry/expression-language/)页面。

2
content/zh/docs/reference/config/security/constraints-and-properties/index.md
View File

@ -7,7 +7,7 @@ aliases:
---
{{< warning >}}
RBAC 策略中的约束和属性已经被 `AuthorizationPolicy` 中的条件取代。 请使用 `AuthorizationPolicy` 资源中的条件，此页面仅供参考，以后将被删除。
RBAC 策略中的约束和属性已经被 `AuthorizationPolicy` 中的条件取代。请使用 `AuthorizationPolicy` 资源中的条件，此页面仅供参考，以后将被删除。
{{< /warning >}}
本节包含支持格式化的键和值，你可以将其用作于服务角色和服务角色绑定配置对象中的约束和属性。约束和属性是额外的条件，你可以指定配置对象 `kind:` 字段的值为 `ServiceRole` 或 `ServiceRoleBinding`，以指定详细的访问控制要求。

2
content/zh/docs/reference/config/telemetry/configurable_metrics/index.md
View File

@ -6,7 +6,7 @@ weight: 60
Istio 1.5 包含 `experimental` 支持，用于修改 Istio 标准指标并定义新指标。
配置步骤记录在 Istio [wiki](https://github.com/istio/istio/wiki/Configurable-V2-Metrics)上。
配置步骤记录在 Istio [wiki](https://github.com/istio/istio/wiki/Configurable-V2-Metrics) 上。
{{< warning >}}
作为扩展 API 设计的一部分，用于配置指标的 API 在 Istio 1.6 中肯定会发生更改。

12
content/zh/docs/reference/config/telemetry/metrics/index.md
View File

@ -22,17 +22,17 @@ weight: 50
对于 TCP 流量，Istio 生成以下指标：
* **Tcp发送字节数**（`istio_tcp_sent_bytes_total`）：这是一个用于测量在 TCP 连接下响应期间发送的总字节数的 `COUNTER` 指标。
* **Tcp 发送字节数**（`istio_tcp_sent_bytes_total`）：这是一个用于测量在 TCP 连接下响应期间发送的总字节数的 `COUNTER` 指标。
* **Tcp接收字节数**（`istio_tcp_received_bytes_total`）：这是一个用于测量在 TCP 连接下请求期间接收的总字节数的`COUNTER`指标。
* **Tcp 接收字节数**（`istio_tcp_received_bytes_total`）：这是一个用于测量在 TCP 连接下请求期间接收的总字节数的`COUNTER`指标。
* **Tcp打开连接数**（`istio_tcp_connections_opened_total`）：这是一个用于累加每个打开连接的 `COUNTER` 指标。
* **Tcp 打开连接数**（`istio_tcp_connections_opened_total`）：这是一个用于累加每个打开连接的 `COUNTER` 指标。
* **Tcp关闭连接数** (`istio_tcp_connections_closed_total`): 这是一个用于累加每个关闭连接的 `COUNTER` 指标。
* **Tcp 关闭连接数** (`istio_tcp_connections_closed_total`) : 这是一个用于累加每个关闭连接的 `COUNTER` 指标。
## 标签
* **报告者**：标识请求的报告者。如果报告来自服务端Istio代理，则设置为 `destination` ，如果报告来自客户端Istio代理，则设置为 `source` 。
* **报告者**：标识请求的报告者。如果报告来自服务端 Istio 代理，则设置为 `destination` ，如果报告来自客户端 Istio 代理，则设置为 `source` 。
{{< text yaml >}}
reporter: conditional((context.reporter.kind | "inbound") == "outbound", "source", "destination")
@ -134,7 +134,7 @@ weight: 50
connection_security_policy: conditional((context.reporter.kind | "inbound") == "outbound", "unknown", conditional(connection.mtls | false, "mutual_tls", "none"))
{{< /text >}}
* **响应标志**：有关来自代理的响应或连接的其他详细信息。如果使用 Envoy ，请参阅[Envoy访问日志](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log#configuration)中的 `％RESPONSE_FLAGS％` 以获取更多详细信息。
* **响应标志**：有关来自代理的响应或连接的其他详细信息。如果使用 Envoy ，请参阅 [Envoy 访问日志](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log#configuration)中的 `％RESPONSE_FLAGS％` 以获取更多详细信息。
{{< text yaml >}}
response_flags: context.proxy_error_code | "-"

2
content/zh/docs/reference/glossary/multicluster.md
View File

@ -2,4 +2,4 @@
title: Multicluster
---
Multicluster 是一种部署模型， 由具有多个[集群](/zh/docs/reference/glossary/#cluster)的[网格](/zh/docs/reference/glossary/#service-mesh)组成。
Multicluster 是一种部署模型，由具有多个[集群](/zh/docs/reference/glossary/#cluster)的[网格](/zh/docs/reference/glossary/#service-mesh)组成。

4
content/zh/docs/setup/additional-setup/sidecar-injection/index.md
View File

@ -132,7 +132,7 @@ sleep-776b7bcdcd-gmvnr 1/1 Running 0 2s
#### 理解原理{#understanding-what-happened}
当 Kubernetes 调用 webhook 时，[`admissionregistration`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io) 配置被应用。默认配置将 sidecar 注入到所有拥有 `istio-injection=enabled` 标签的 namespace 下的 pod 中。 `istio-sidecar-injector` 配置字典指定了注入 sidecar 的配置。如需更改指定哪些 namespace 被注入，你可以使用以下命令编辑 `MutatingWebhookConfiguration`：
当 Kubernetes 调用 webhook 时，[`admissionregistration`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#mutatingwebhookconfiguration-v1beta1-admissionregistration-k8s-io) 配置被应用。默认配置将 sidecar 注入到所有拥有 `istio-injection=enabled` 标签的 namespace 下的 pod 中。`istio-sidecar-injector` 配置字典指定了注入 sidecar 的配置。如需更改指定哪些 namespace 被注入，你可以使用以下命令编辑 `MutatingWebhookConfiguration`：
{{< text bash >}}
$ kubectl edit mutatingwebhookconfiguration istio-sidecar-injector
@ -196,7 +196,7 @@ type SidecarTemplateData struct {
}
{{< /text >}}
`ObjectMeta` 和 `Spec` 来源于 pod。 `ProxyConfig` 和 `MeshConfig` 来源于 `istio-system` namespace 下 `istio` 的 ConfigMap。模版可以使用这些数据有条件地定义被注入的卷和容器。
`ObjectMeta` 和 `Spec` 来源于 pod。`ProxyConfig` 和 `MeshConfig` 来源于 `istio-system` namespace 下 `istio` 的 ConfigMap。模版可以使用这些数据有条件地定义被注入的卷和容器。
例如下面的模版。

2
content/zh/docs/setup/getting-started/index.md
View File

@ -32,7 +32,7 @@ Istio {{< istio_version >}} 已经在 Kubernetes 版本 {{< supported_kubernetes
- 通过选择合适的 [platform-specific setup instructions](/zh/docs/setup/platform-setup/) 来创建一个集群。
有些平台提供了 {{< gloss >}}managed control plane{{< /gloss >}}，您可以使用它来代替手动安装 Istio。 如果您选择的平台支持这种方式，并且您选择使用它，那么，在创建完集群后，您将完成 Istio 的安装。因此，可以跳过以下说明。
有些平台提供了 {{< gloss >}}managed control plane{{< /gloss >}}，您可以使用它来代替手动安装 Istio。如果您选择的平台支持这种方式，并且您选择使用它，那么，在创建完集群后，您将完成 Istio 的安装。因此，可以跳过以下说明。
## 下载 Istio {#download}

4
content/zh/docs/setup/install/helm/index.md
View File

@ -55,8 +55,8 @@ $ helm repo add istio.io https://storage.googleapis.com/istio-release/releases/{
1. 如果您使用 [Helm 的 Tiller pod](https://helm.sh/) 来管理 Istio 发行版, 请查看[方案 2](/zh/docs/setup/install/helm/#option-2-install-with-helm-and-tiller-via-helm-install)。
{{< tip >}}
默认情况下，Istio 使用 `LoadBalancer` 服务类型。 而有些平台是不支持 `LoadBalancer`
服务的。 对于不支持 `LoadBalancer` 服务类型的平台, 执行下面的步骤时，可以在 Helm 命令中加入 `--set gateways.istio-ingressgateway.type=NodePort` 选项，使用 `NodePort` 来替代 `LoadBalancer` 服务类型。
默认情况下，Istio 使用 `LoadBalancer` 服务类型。而有些平台是不支持 `LoadBalancer`
服务的。对于不支持 `LoadBalancer` 服务类型的平台, 执行下面的步骤时，可以在 Helm 命令中加入 `--set gateways.istio-ingressgateway.type=NodePort` 选项，使用 `NodePort` 来替代 `LoadBalancer` 服务类型。
{{< /tip >}}
### 方案 1: 使用 `helm template` 命令安装{#option-1-install-with-helm-via-helm-template}

6
content/zh/docs/setup/install/istioctl/index.md
View File

@ -81,7 +81,7 @@ Istio configuration profiles:
## 显示配置文件的配置{#display-the-configuration-of-a-profile}
您可以查看配置文件的配置设置。 例如，通过以下命令查看 `default` 配置文件的设置：
您可以查看配置文件的配置设置。例如，通过以下命令查看 `default` 配置文件的设置：
{{< text bash >}}
$ istioctl profile dump demo
@ -231,7 +231,7 @@ $ istioctl verify-install -f $HOME/generated-manifest.yaml
- [The `IstioOperator` API](/zh/docs/reference/config/istio.operator.v1alpha1/)
可以使用命令上的 `--set` 选项分别设置此 API 中的配置参数。 例如，要在 `default` 配置文件之上启用控制面安全特性，请使用以下命令：
可以使用命令上的 `--set` 选项分别设置此 API 中的配置参数。例如，要在 `default` 配置文件之上启用控制面安全特性，请使用以下命令：
{{< text bash >}}
$ istioctl manifest apply --set values.global.controlPlaneSecurityEnabled=true
@ -421,7 +421,7 @@ spec:
{{< /text >}}
一些参数将在 Helm 和 `IstioOperator` API 中暂时存在，包括 Kubernetes 资源，
命名空间和启用设置。 Istio 社区建议使用 `IstioOperator` API，因为它更专一，经过验证并遵循[社区毕业流程](https://github.com/istio/community/blob/master/FEATURE-LIFECYCLE-CHECKLIST.md#feature-lifecycle-checklist)。
命名空间和启用设置。Istio 社区建议使用 `IstioOperator` API，因为它更专一，经过验证并遵循[社区毕业流程](https://github.com/istio/community/blob/master/FEATURE-LIFECYCLE-CHECKLIST.md#feature-lifecycle-checklist)。
## 卸载 Istio{#uninstall-Istio}

6
content/zh/docs/setup/install/multicluster/shared-gateways/index.md
View File

@ -24,7 +24,7 @@ Istio 位置感知的服务路由特性，可以根据请求源所在的位置
## 前提条件{#prerequisites}
* 两个或多个 Kubernetes 集群，版本为： {{< supported_kubernetes_versions >}}。
* 两个或多个 Kubernetes 集群，版本为：{{< supported_kubernetes_versions >}}。
* 有权限[部署 Istio 控制平面](/zh/docs/setup/install/istioctl/)
@ -103,7 +103,7 @@ Istio 位置感知的服务路由特性，可以根据请求源所在的位置
EOF
{{< /text >}}
本例 `Gateway` 配置 443 端口来将流经的入口流量导向请求 SNI 头中指明的目标服务，其中 SNI 的顶级域名为 _local_（譬如： [Kubernetes DNS 域名](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/)）。
本例 `Gateway` 配置 443 端口来将流经的入口流量导向请求 SNI 头中指明的目标服务，其中 SNI 的顶级域名为 _local_（譬如：[Kubernetes DNS 域名](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/)）。
从源至目标 sidecar，始终使用双向 TLS 连接。
尽管应用于 `cluster1`，该网关实例也会影响 `cluster2`，因为两个集群通过同一个 Pilot 通信。
@ -216,7 +216,7 @@ Istio 位置感知的服务路由特性，可以根据请求源所在的位置
$ echo The ingress gateway of cluster2: address=$INGRESS_HOST, port=$SECURE_INGRESS_PORT
{{< /text >}}
1. 更新网格网络配置中的网关地址。 编辑 `istio` `ConfigMap`：
1. 更新网格网络配置中的网关地址。编辑 `istio` `ConfigMap`：
{{< text bash >}}
$ kubectl edit cm -n istio-system --context=$CTX_CLUSTER1 istio

2
content/zh/docs/setup/install/multicluster/simplified/index.md
View File

@ -78,7 +78,7 @@ keywords: [kubernetes,multicluster]
$ cd ${WORKDIR}
{{< /text >}}
1. 下载[设置脚本]({{<github_file >}}/samples/multicluster/setup-mesh.sh) 到您的工作目录。
1. 下载[设置脚本]({{<github_file>}}/samples/multicluster/setup-mesh.sh)到您的工作目录。
该脚本负责创建必要的证书以启用跨集群通信，它为您准备了默认配置文件，并将在每个集群中部署和配置 Istio。
1. 最后，运行下载的脚本以准备网格。这会创建一个将用于保护网格中群集之间的通信安全的根密钥和证书，以及用于控制所有群集上部署的 Istio 的配置的 `base.yaml` 文件：

4
content/zh/docs/setup/platform-setup/gardener/index.md
View File

@ -24,7 +24,7 @@ keywords: [platform-setup,kubernetes,gardener,sap]
### 访问 Gardener{#access-gardener}
1. 在 Gardener 仪表板中创建一个项目。 这实际上将创建一个名为 `garden-<my-project>` 的 Kubernetes 命名空间。
1. 在 Gardener 仪表板中创建一个项目。这实际上将创建一个名为 `garden-<my-project>` 的 Kubernetes 命名空间。
1. [配置对您的 Gardener 项目的访问权限](https://kubernetes.io/docs/tasks/tools/install-kubectl/#verifying-kubectl-configuration)
使用 kubeconfig，如果您还不是 Gardener 管理员，则可以在 Gardener 仪表板中创建一个用户：转到 "Members" 部分并添加服务帐户。
@ -34,7 +34,7 @@ keywords: [platform-setup,kubernetes,gardener,sap]
### 创建 Kubernetes 集群{#creating-a-Kubernetes-cluster}
您可以通过提供集群规范 yaml 文件，使用 `kubectl` cli 创建集群。 您可以在[这博客里](https://github.com/gardener/gardener/blob/master/example/90-shoot.yaml)找到关于 GCP 的示例。
您可以通过提供集群规范 yaml 文件，使用 `kubectl` cli 创建集群。您可以在[这博客里](https://github.com/gardener/gardener/blob/master/example/90-shoot.yaml)找到关于 GCP 的示例。
确保名称空间与您的项目名称空间匹配。然后只需将准备好的 "shoot" 群集 CRD 与 `kubectl` 配合使用：
{{< text bash >}}

2
content/zh/docs/setup/platform-setup/openshift/index.md
View File

@ -15,7 +15,7 @@ OpenShift 4.1 及以上版本使用的 `nftables` 与 Istio 的 `proxy-init` 容
依照本指南对 OpenShift 集群进行配置以便安装运行 Istio。
默认情况下，OpenShift 不允许容器使用 User ID（UID） 0 来运行。通过以下命令可以让 Istio 的服务账户（Service Accounts）以 UID 0 来运行容器
默认情况下，OpenShift 不允许容器使用 User ID（UID）0 来运行。通过以下命令可以让 Istio 的服务账户（Service Accounts）以 UID 0 来运行容器
（如果你将 Istio 部署到其它命名空间，请注意替换 `istio-system` ）：
{{< text bash >}}

2
content/zh/docs/setup/upgrade/cni-helm-upgrade/index.md
View File

@ -31,7 +31,7 @@ Istio **不支持** 跨版本升级。仅支持从 {{< istio_previous_version >}
您可以使用 Kubernetes 的滚动更新机制来升级 Istio CNI 组件。这适用于使用 `kubectl apply` 部署 Istio CNI 的情况。
1. 检查是否已安装 `istio-cni`。 找到 `istio-cni-node` pod 以及它们运行的命名空间（通常是 `kube-system` 或 `istio-system`）：
1. 检查是否已安装 `istio-cni`。找到 `istio-cni-node` pod 以及它们运行的命名空间（通常是 `kube-system` 或 `istio-system`）：
{{< text bash >}}
$ kubectl get pods -l k8s-app=istio-cni-node --all-namespaces

2
content/zh/docs/tasks/observability/distributed-tracing/lightstep/index.md
View File

@ -7,7 +7,7 @@ aliases:
- /zh/docs/tasks/telemetry/distributed-tracing/lightstep/
---
此任务介绍如何配置 Istio 才能收集追踪 span ， 并且把收集到的 span 发送到 [LightStep Tracing](https://lightstep.com/products/) 或 [LightStep [𝑥]PM](https://lightstep.com/products/)。
此任务介绍如何配置 Istio 才能收集追踪 span ，并且把收集到的 span 发送到 [LightStep Tracing](https://lightstep.com/products/) 或 [LightStep [𝑥]PM](https://lightstep.com/products/)。
LightStep 可以分析来自大规模生产级软件的 100% 未采样的事务数据，并做出容易理解的的分布式追踪和指标信息，这有助于解释性能行为和并加速根因分析。
在此任务的结尾，Istio 将追踪 span 从代理发送到 LightStep Satellite 池，以让它们在 web UI 上展示。

2
content/zh/docs/tasks/observability/distributed-tracing/overview/index.md
View File

@ -11,7 +11,7 @@ aliases:
Istio 利用 [Envoy 的分布式追踪](https://www.envoyproxy.io/docs/envoy/v1.10.0/intro/arch_overview/tracing)功能提供了开箱即用的追踪集成。确切地说，Istio 提供了安装各种各种追踪后端服务的选项，并且通过配置代理来自动发送追踪 span 到追踪后端服务。
请参阅 [Zipkin](../zipkin/)， [Jaeger](../jaeger/) 和 [LightStep](/zh/docs/tasks/observability/distributed-tracing/lightstep/) 的任务文档来了解 Istio 如何与这些分布式追踪系统一起工作。
请参阅 [Zipkin](../zipkin/)，[Jaeger](../jaeger/) 和 [LightStep](/zh/docs/tasks/observability/distributed-tracing/lightstep/) 的任务文档来了解 Istio 如何与这些分布式追踪系统一起工作。
## 追踪上下文传递{#trace-context-propagation}

14
content/zh/docs/tasks/observability/kiali/index.md
View File

@ -28,7 +28,7 @@ aliases:
### 创建 secret{#create-a-secret}
{{< tip >}}
如果您打算按照 [Istio 快速入门](/zh/docs/setup/getting-started/)说明使用 Istio 演示配置文件安装 Kiali，则会为您创建一个默认 secret，用户名为 `admin` ，密码为 `admin`。 因此，您可以跳过此部分。
如果您打算按照 [Istio 快速入门](/zh/docs/setup/getting-started/)说明使用 Istio 演示配置文件安装 Kiali，则会为您创建一个默认 secret，用户名为 `admin` ，密码为 `admin`。因此，您可以跳过此部分。
{{< /tip >}}
在 Istio 命名空间中创建一个 Secret，作为 Kiali 的身份验证凭据。
@ -87,7 +87,7 @@ $ istioctl manifest apply --set values.kiali.enabled=true
{{< /text >}}
{{< idea >}}
该任务不讨论 Jaeger 和 Grafana。 如果已经在集群中安装了它们，并且想了解 Kiali 如何与它们集成，则必须将其他参数传递给 `helm` 命令，例如：
该任务不讨论 Jaeger 和 Grafana。如果已经在集群中安装了它们，并且想了解 Kiali 如何与它们集成，则必须将其他参数传递给 `helm` 命令，例如：
{{< text bash >}}
$ istioctl manifest apply \
@ -149,13 +149,13 @@ $ oc patch clusterrole kiali -p '[{"op":"add", "path":"/rules/-", "value":{"apiG
{{< image width="75%" link="./kiali-overview.png" caption="Example Overview" >}}
1. 要查看名称空间图，请单击 Bookinfo 名称空间卡中的 `bookinfo` 图标。 图形图标位于名称空间卡的左下角，看起来像是一组相连的圈子，页面类似于：
1. 要查看名称空间图，请单击 Bookinfo 名称空间卡中的 `bookinfo` 图标。图形图标位于名称空间卡的左下角，看起来像是一组相连的圈子，页面类似于：
{{< image width="75%" link="./kiali-graph.png" caption="Example Graph" >}}
1. 要查看度量标准摘要，请选择图中的任何节点或边，以便在右侧的 summary details 面板中显示其度量的详细信息。
1. 要使用不同的图形类型查看服务网格，请从 **Graph Type** 下拉菜单中选择一种图形类型。有几种图形类型可供选择： **App**, **Versioned App**, **Workload**, **Service**。
1. 要使用不同的图形类型查看服务网格，请从 **Graph Type** 下拉菜单中选择一种图形类型。有几种图形类型可供选择：**App**, **Versioned App**, **Workload**, **Service**。
* **App** 图形类型将一个应用程序的所有版本聚合到一个图形节点中。以下示例显示了一个单独的 **reviews** 节点，它代表了评论应用程序的三个版本。
@ -167,7 +167,7 @@ $ oc patch clusterrole kiali -p '[{"op":"add", "path":"/rules/-", "value":{"apiG
{{< image width="75%" link="./kiali-versionedapp.png" caption="Example Versioned App Graph" >}}
* **Workload** 图类型显示了服务网格中每个工作负载的节点。
这种图类型不需要您使用 `app` 和 `version` 标签，因此，如果您选择在组件上不使用这些标签， 这是您将使用的图形类型。
这种图类型不需要您使用 `app` 和 `version` 标签，因此，如果您选择在组件上不使用这些标签，这是您将使用的图形类型。
{{< image width="70%" link="./kiali-workload.png" caption="Example Workload Graph" >}}
@ -206,7 +206,7 @@ $ oc patch clusterrole kiali -p '[{"op":"add", "path":"/rules/-", "value":{"apiG
{{< image width="80%" link="./kiali-wiz2-ratings-service-action-menu.png" caption="Service Action Menu" >}}
1. 拖动滑块以指定要路由到每个服务的流量百分比。
对于 `ratings-v1`，将其设置为 10％； 对于 `ratings-v2` ，请将其设置为 90％。
对于 `ratings-v1`，将其设置为 10％；对于 `ratings-v2` ，请将其设置为 90％。
{{< image width="80%" link="./kiali-wiz3-weighted-routing-wizard.png" caption="Weighted Routing Wizard" >}}
@ -319,7 +319,7 @@ Kiali 提供了一个 YAML 编辑器，用于查看和编辑 Istio 配置资源
Kiali Public API 建立在 Prometheus 查询之上，并且取决于标准的 Istio 度量配置。
它还会调用 Kubernetes API 以获取有关您的服务的其他详细信息。
为了获得使用 Kiali 的最佳体验，请在应用程序组件上使用元数据标签 `app` 和 `version`。 作为模板，Bookinfo 示例应用程序遵循此约定。
为了获得使用 Kiali 的最佳体验，请在应用程序组件上使用元数据标签 `app` 和 `version`。作为模板，Bookinfo 示例应用程序遵循此约定。
## 清理{#cleanup}

8
content/zh/docs/tasks/observability/metrics/querying-metrics/index.md
View File

@ -53,7 +53,7 @@ aliases:
1. 执行一个 Prometheus 查询。
在 web 页面顶部的 "Expression" 对话框中，输入文本：
`istio_requests_total`。 然后点击 **Execute** 按钮。
`istio_requests_total`。然后点击 **Execute** 按钮。
结果类似于：
@ -83,13 +83,13 @@ aliases:
### 关于 Prometheus 插件{#about-the-monitor-add-on}
Mixer 自带一个内嵌的 [Prometheus](https://prometheus.io) 适配器，对外暴露一个端点，负责提供度量指标值服务。 Prometheus 插件是一个提前配置好的 Prometheus 服务器，旨在通过 Mixer 端点收集对外暴露的度量指标。插件提供了持久化存储和 Istio 度量指标查询机制。
Mixer 自带一个内嵌的 [Prometheus](https://prometheus.io) 适配器，对外暴露一个端点，负责提供度量指标值服务。Prometheus 插件是一个提前配置好的 Prometheus 服务器，旨在通过 Mixer 端点收集对外暴露的度量指标。插件提供了持久化存储和 Istio 度量指标查询机制。
Prometheus 插件预配抓捕如下端点：
1. `istio-telemetry.istio-system:42422`: `istio-mesh` 任务返回所有 Mixer 生成的度量指标。
1. `istio-telemetry.istio-system:15014`: `istio-telemetry` 任务返回所有 Mixer 特殊的度量指标。该端点用于监控 Mixer 本身。
1. `istio-proxy:15090`: `envoy-stats` 任务返回 Envoy 生成的原始状态。 Prometheus 被配置来查找对外暴露了 `envoy-prom` 端点的 pods。 在收集过程中，插件配置过滤掉大量 envoy 度量指标，从而限制插件进程的数据量。
1. `istio-proxy:15090`: `envoy-stats` 任务返回 Envoy 生成的原始状态。Prometheus 被配置来查找对外暴露了 `envoy-prom` 端点的 pods。在收集过程中，插件配置过滤掉大量 envoy 度量指标，从而限制插件进程的数据量。
1. `istio-pilot.istio-system:15014`: `pilot` 任务返回 Pilot 生成的度量指标。
1. `istio-galley.istio-system:15014`: `galley` 任务返回 Galley 生成的度量指标。
1. `istio-policy.istio-system:15014`: `istio-policy` 任务返回所有策略相关的度量指标。
@ -106,5 +106,5 @@ docs](https://prometheus.io/docs/querying/basics/).
$ killall kubectl
{{< /text >}}
- 若不再执行后续任务， 参考
- 若不再执行后续任务，参考
[Bookinfo cleanup](/zh/docs/examples/bookinfo/#cleanup) 命令关闭应用。

2
content/zh/docs/tasks/policy-enforcement/denial-and-list/index.md
View File

@ -109,7 +109,7 @@ Istio 支持基于属性的白名单和黑名单。
1. 当您不登录去访问 Bookinfo `productpage` (`http://$GATEWAY_URL/productpage`) 时进行验证，会看到红星。
再执行以下步骤之后，除非您以 "json" 用户登录，否则不会看到星标。
1. 将配置应用于 [`list`](/zh/docs/reference/config/policy-and-telemetry/adapters/list/) 适配器以让 `v1， v2` 版本位于白名单中；
1. 将配置应用于 [`list`](/zh/docs/reference/config/policy-and-telemetry/adapters/list/) 适配器以让 `v1，v2` 版本位于白名单中；
{{< text bash >}}
$ kubectl apply -f @samples/bookinfo/policy/mixer-rule-deny-whitelist.yaml@

4
content/zh/docs/tasks/policy-enforcement/rate-limiting/index.md
View File

@ -104,7 +104,7 @@ aliases:
{{< /text >}}
`quota` 模板通过 `memquota` 或 `redisquota` 定义了三个维度以匹配特定的属性的方式设置优先规则。
`目标服务`会被设置为 `destination.labels["app"]`，`destination.service.host`，或 `"unknown"` 中的第一个非空值。
`目标服务`会被设置为 `destination.labels ["app"]`，`destination.service.host`，或 `"unknown"` 中的第一个非空值。
表达式的更多信息，见 [Expression Language](/zh/docs/reference/config/policy-and-telemetry/expression-language/)。
1. 确认 `quota rule` 已被创建：
@ -132,7 +132,7 @@ aliases:
`QuotaSpecBinding` 绑定了您上面创建的 `QuotaSpec` 与您想要生效的服务。`productpage` 显式的绑定了 `request-count`，
注意您必须定义与 `QuotaSpecBinding` 不同的命名空间。
如果最后一行注释被打开， `service: '*'` 将绑定所有服务到 `QuotaSpec` 使得首个 entry 是冗余的。
如果最后一行注释被打开，`service: '*'` 将绑定所有服务到 `QuotaSpec` 使得首个 entry 是冗余的。
1. 在浏览器上刷新 product 页面。

2
content/zh/docs/tasks/security/authentication/authn-policy/index.md
View File

@ -729,7 +729,7 @@ EOF
因此，您不需要添加这个 destination rule 。另外，您仍然需要添加 `mtls` 段到认证策略，因为特定服务策略将完全覆盖网格范围（或者命名空间范围）的策略。
{{< /tip >}}
修改这些后，从 Istio 服务，包括 ingress gateway， 到 `httpbin.foo` 的流量将使用双向 TLS。上述测试命令将仍然会正常工作。给定正确的 token，从 Istio 服务直接到 `httpbin.foo` 的请求也会正常工作：
修改这些后，从 Istio 服务，包括 ingress gateway，到 `httpbin.foo` 的流量将使用双向 TLS。上述测试命令将仍然会正常工作。给定正确的 token，从 Istio 服务直接到 `httpbin.foo` 的请求也会正常工作：
{{< text bash >}}
$ TOKEN=$(curl {{< github_file >}}/security/tools/jwt/samples/demo.jwt -s)

2
content/zh/docs/tasks/security/authentication/mtls-migration/index.md
View File

@ -39,7 +39,7 @@ aliases:
$ kubectl apply -f @samples/sleep/sleep.yaml@ -n legacy
{{< /text >}}
* （使用 curl 命令）从每个 sleep pod （命名空间为 `foo`， `bar` 或 `legacy`） 分别向 `httpbin.foo` 发送 http 请求。所有请求都应成功响应，返回 HTTP code 200。
* （使用 curl 命令）从每个 sleep pod （命名空间为 `foo`，`bar` 或 `legacy`）分别向 `httpbin.foo` 发送 http 请求。所有请求都应成功响应，返回 HTTP code 200。
{{< text bash >}}
$ for from in "foo" "bar" "legacy"; do kubectl exec $(kubectl get pod -l app=sleep -n ${from} -o jsonpath={.items..metadata.name}) -c sleep -n ${from} -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "sleep.${from} to httpbin.foo: %{http_code}\n"; done

2
content/zh/docs/tasks/security/authorization/authz-http/index.md
View File

@ -128,7 +128,7 @@ aliases:
EOF
{{< /text >}}
在浏览器访问 Bookinfo `productpage` (`http://$GATEWAY_URL/productpage`)。现在你将看到 “Bookinfo Sample” 页面， “Book Details” 在左下方， “Book Reviews” 在右下方。但是在 “Book Reviews” 部分有 `Ratings service currently unavailable` 的错误。
在浏览器访问 Bookinfo `productpage` (`http://$GATEWAY_URL/productpage`)。现在你将看到 “Bookinfo Sample” 页面，“Book Details” 在左下方，“Book Reviews” 在右下方。但是在 “Book Reviews” 部分有 `Ratings service currently unavailable` 的错误。
这是因为 `reviews` 工作负载没有权限访问 `ratings` 工作负载。为修复这个问题，你需要授权 `reviews` 工作负载可以访问 `ratings` 工作负载。下一步我们配置一个策略来容许 `reviews` 工作负载访问。

8
content/zh/docs/tasks/security/authorization/rbac-groups/index.md
View File

@ -58,8 +58,8 @@ aliases:
## 使用双向 TLS 配置 JSON Web 令牌（JWT）认证{#configure-json-web-token-JWT-authentication-with-mutual-TLS}
您接下来应用的认证策略会强制要求访问 `httpbin` 服务需要具备有效的 JWT。
策略中定义的 JSON Web 密钥集（ JWKS ）端点必须对 JWT 进行签名。
本教程使用 Istio 代码库中的 [JWKS 端点]({{<github_file >}}/security/tools/jwt/samples/jwks.json) 并使用[此示例 JWT]({{< github_file >}}/security/tools/jwt/samples/groups-scope.jwt)。
策略中定义的 JSON Web 密钥集（JWKS ）端点必须对 JWT 进行签名。
本教程使用 Istio 代码库中的 [JWKS 端点]({{<github_file>}}/security/tools/jwt/samples/jwks.json)并使用[此示例 JWT]({{< github_file >}}/security/tools/jwt/samples/groups-scope.jwt)。
示例 JWT 包含一个标识为 `groups` 的声明键和一个 [`"group1"`，`"group2"`] 字符串列表的声明值。
JWT 声明值可以是字符串或字符串列表；两种类型都支持。
@ -217,7 +217,7 @@ JWT 声明值可以是字符串或字符串列表；两种类型都支持。
$ kubectl exec $(kubectl get pod -l app=sleep -n $NS -o jsonpath={.items..metadata.name}) -c sleep -n $NS -- curl http://httpbin.$NS:8000/ip -s -o /dev/null -w "%{http_code}\n" --header "Authorization: Bearer $TOKEN"
{{< /text >}}
HTTP Header 包含一个有效的 JWT，其 `groups` 声明值为[`"group1"`，`"group2"`]，因为它包含 `group1`，所以返回 HTTP 状态码为 200。
HTTP Header 包含一个有效的 JWT，其 `groups` 声明值为 [`"group1"`，`"group2"`]，因为它包含 `group1`，所以返回 HTTP 状态码为 200。
## 配置列表类型声明的授权{#configure-the-authorization-of-list-typed-claims}
@ -256,7 +256,7 @@ Istio RBAC 支持配置列表类型声明的授权。
$ kubectl exec $(kubectl get pod -l app=sleep -n $NS -o jsonpath={.items..metadata.name}) -c sleep -n $NS -- curl http://httpbin.$NS:8000/ip -s -o /dev/null -w "%{http_code}\n" --header "Authorization: Bearer $TOKEN"
{{< /text >}}
HTTP Header 包含一个有效的 JWT，`scope` 的声明值为[`"scope1"`，`"scope2"`]，因为它包含 `scope1`， 所以返回 HTTP 状态码为 200。
HTTP Header 包含一个有效的 JWT，`scope` 的声明值为 [`"scope1"`，`"scope2"`]，因为它包含 `scope1`，所以返回 HTTP 状态码为 200。
## 清理{#cleanup}

10
content/zh/docs/tasks/security/citadel-config/auth-sds/index.md
View File

@ -21,7 +21,7 @@ aliases:
这些问题都在 Istio 1.1 中通过提供 SDS 身份认证解决了。
整个过程可以描述如下：
1. workload 边车 Envoy 向 Citadel 代理请求密钥和证书：Citadel 代理是一个 SDS 服务，作为每个节点上的 `DaemonSet` 运行。 Envoy 在请求时会传一个 Kubernetes 服务帐号的 JWT 到代理。
1. workload 边车 Envoy 向 Citadel 代理请求密钥和证书：Citadel 代理是一个 SDS 服务，作为每个节点上的 `DaemonSet` 运行。Envoy 在请求时会传一个 Kubernetes 服务帐号的 JWT 到代理。
1. Citadel 代理产生密钥对并且发送 CSR 请求给 Citadel 服务：Citadel 服务验证收到的 JWT 并且向 Citadel 颁发证书。
@ -74,7 +74,7 @@ $ kubectl exec -it $(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..me
## 使用 pod 上的安全策略来保护 SDS {## securing-SDS-with-pod-security-policies}
Istio 的密钥发现服务（SDS）使用 Citadel 代理通过 Unix domain 套接字来给 Envoy 边车分发证书。 所有在同一个 Kubernetes 节点上的 pod 通过 Unix domain 套接字共享同一个 Citadel 代理。
Istio 的密钥发现服务（SDS）使用 Citadel 代理通过 Unix domain 套接字来给 Envoy 边车分发证书。所有在同一个 Kubernetes 节点上的 pod 通过 Unix domain 套接字共享同一个 Citadel 代理。
为了防止对 Unix domain 套接字的意外修改，需要启用 [pod 安全策略](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)来限制 pod 对 Unix domain 套接字的权限。否则，有权限修改 deployment 的恶意用户会劫持 Unix domain 套接字来断开 SDS 服务，或者会从运行在同一个 Kubernetes 节点上的其它 pod 那里偷取身份证书。
@ -133,7 +133,7 @@ Istio 的密钥发现服务（SDS）使用 Citadel 代理通过 Unix domain 套
EOF
{{< /text >}}
1. 要阻止其它 pod 修改 Unix domain 套接字，就要修改配置项 `allowedHostPaths` ，读写权限配置为`readOnly: true`， 这个选项是 Citadel 代理用于配置 Unix domain 套接字路径的。
1. 要阻止其它 pod 修改 Unix domain 套接字，就要修改配置项 `allowedHostPaths` ，读写权限配置为`readOnly: true`，这个选项是 Citadel 代理用于配置 Unix domain 套接字路径的。
{{< warning >}}
假设以下的 pod 安全策略是之前其它 pod 没有使用过的。如果你已经实施了其它的 pod 安全策略，则给已经存在的策略新增以下的配置值，而不是直接实施配置。
@ -252,7 +252,7 @@ Istio 的密钥发现服务（SDS）使用 Citadel 代理通过 Unix domain 套
normal-64c6956774-ptpfh 2/2 Running 0 8s
{{< /text >}}
1. 启动一个恶意 pod， 这个 pod 会尝试挂载一个有写权限的 Unix domain 套接字。
1. 启动一个恶意 pod，这个 pod 会尝试挂载一个有写权限的 Unix domain 套接字。
{{< text bash >}}
$ cat <<EOF | kubectl apply -f -
@ -325,4 +325,4 @@ Istio 的密钥发现服务（SDS）使用 Citadel 代理通过 Unix domain 套
* SDS 目前只支持 [Alpha](/zh/about/feature-stages/#security-and-policy-enforcement) 版本。
* 目前还无法流畅的将群集从使用密钥卷装载方式迁移到使用 SDS ， 功能还在开发中。
* 目前还无法流畅的将群集从使用密钥卷装载方式迁移到使用 SDS ，功能还在开发中。

6
content/zh/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md
View File

@ -85,7 +85,7 @@ aliases:
如果在输出中看到 _301 Moved Permanently_，说明 `ServiceEntry` 配置正确。
1. 为 _edition.cnn.com_ 创建一个 egress `Gateway`， 端口 443，以及一个 sidecar 请求的目标规则，sidecar 请求被直接导向 egress 网关。
1. 为 _edition.cnn.com_ 创建一个 egress `Gateway`，端口 443，以及一个 sidecar 请求的目标规则，sidecar 请求被直接导向 egress 网关。
根据需要开启源 pod 与 egress 网关之间的[双向 TLS 认证](/zh/docs/tasks/security/authentication/mutual-tls/)，选择相应的命令。
@ -319,7 +319,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn
为了模拟一个真实的支持双向 TLS 协议的外部服务，
在 Kubernetes 集群中部署一个 [NGINX](https://www.nginx.com) 服务器，该服务器运行在 Istio 服务网格之外，譬如：运行在一个没有开启 Istio sidecar proxy 注入的命名空间中。
1. 创建一个命名空间，表示 Istio 网格之外的服务， `mesh-external`。注意在这个命名空间中，sidecar 自动注入是没有[开启](/zh/docs/setup/additional-setup/sidecar-injection/#deploying-an-app)的，不会在 pods 中自动注入 sidecar proxy。
1. 创建一个命名空间，表示 Istio 网格之外的服务，`mesh-external`。注意在这个命名空间中，sidecar 自动注入是没有[开启](/zh/docs/setup/additional-setup/sidecar-injection/#deploying-an-app)的，不会在 pods 中自动注入 sidecar proxy。
{{< text bash >}}
$ kubectl create namespace mesh-external
@ -642,7 +642,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn
$ kubectl exec -it -n istio-system $(kubectl -n istio-system get pods -l istio=egressgateway -o jsonpath='{.items[0].metadata.name}') -- ls -al /etc/nginx-client-certs /etc/nginx-ca-certs
{{< /text >}}
`tls.crt` 与 `tls.key` 在 `/etc/istio/nginx-client-certs` 中， 而 `ca-chain.cert.pem` 在 `/etc/istio/nginx-ca-certs` 中。
`tls.crt` 与 `tls.key` 在 `/etc/istio/nginx-client-certs` 中，而 `ca-chain.cert.pem` 在 `/etc/istio/nginx-ca-certs` 中。
### 为 egress 流量配置双向 TLS{#configure-mutual-TLS-origination-for-egress-traffic}

2
content/zh/docs/tasks/traffic-management/egress/egress-kubernetes-services/index.md
View File

@ -97,7 +97,7 @@ Kubernetes [ExternalName](https://kubernetes.io/docs/concepts/services-networkin
EOF
{{< /text >}}
1. 通过带有 Istio Sidecar 的源 pod 通过 Kubernetes 服务的主机名访问 `httpbin.org`。注意 Istio Sidecar 添加的 headers，例如， `X-Istio-Attributes` 和 `X-Envoy-Decorator-Operation`。另请注意 `Host` header 等于您的服务的主机名。
1. 通过带有 Istio Sidecar 的源 pod 通过 Kubernetes 服务的主机名访问 `httpbin.org`。注意 Istio Sidecar 添加的 headers，例如，`X-Istio-Attributes` 和 `X-Envoy-Decorator-Operation`。另请注意 `Host` header 等于您的服务的主机名。
{{< text bash >}}
$ kubectl exec -it $SOURCE_POD -c sleep -- curl my-httpbin.default.svc.cluster.local/headers

2
content/zh/docs/tasks/traffic-management/ingress/ingress-certmgr/index.md
View File

@ -24,7 +24,7 @@ aliases:
{{< /text >}}
{{< tip >}}
默认情况下， `istio-ingressgateway` 会以 `LoadBalancer` 的服务类型开放出来。您可以根据自己的 Kubernetes 环境把 `gateways.istio-ingressgateway.type` 设置为 `NodePort`。
默认情况下，`istio-ingressgateway` 会以 `LoadBalancer` 的服务类型开放出来。您可以根据自己的 Kubernetes 环境把 `gateways.istio-ingressgateway.type` 设置为 `NodePort`。
{{< /tip >}}
1. [安装 cert-manager](https://docs.cert-manager.io/en/latest/getting-started/install/kubernetes.html) 以便实现证书的自动管理。

8
content/zh/docs/tasks/traffic-management/ingress/ingress-control/index.md
View File

@ -35,7 +35,7 @@ istio-ingressgateway LoadBalancer 172.21.109.129 130.211.10.121 80:31380/
{{< /text >}}
如果 `EXTERNAL-IP` 值已设置，说明环境正在使用外部负载均衡，可以用其为 ingress gateway 提供服务。
如果 `EXTERNAL-IP` 值为 `<none>` （或持续显示 `<pending>`）， 说明环境没有提供外部负载均衡，无法使用 ingress gateway。
如果 `EXTERNAL-IP` 值为 `<none>` （或持续显示 `<pending>`），说明环境没有提供外部负载均衡，无法使用 ingress gateway。
在这种情况下，你可以使用服务的 [node port](https://kubernetes.io/docs/concepts/services-networking/service/#nodeport) 访问网关。
选择符合自身环境的指令执行：
@ -180,7 +180,7 @@ Ingress [Gateway](/zh/docs/reference/config/networking/gateway/) 描述运行在
{{< warning >}}
来自网格内部其他服务的内部请求无需遵循这些规则，而是默认遵守轮询调度路由规则。
你可以为 `gateways` 列表添加特定的 `mesh` 值，将这些规则同时应用到内部请求。
由于服务的内部主机名可能与外部主机名不一致（譬如： `httpbin.default.svc.cluster.local`），你需要同时将内部主机名添加到 `hosts` 列表中。
由于服务的内部主机名可能与外部主机名不一致（譬如：`httpbin.default.svc.cluster.local`），你需要同时将内部主机名添加到 `hosts` 列表中。
详情请参考[操作指南](/zh/docs/ops/common-problems/network-issues#route-rules-have-no-effect-on-ingress-gateway-requests)。
{{< /warning >}}
@ -213,7 +213,7 @@ Ingress [Gateway](/zh/docs/reference/config/networking/gateway/) 描述运行在
## 通过浏览器访问 ingress 服务{#accessing-ingress-services-using-a-browser}
在浏览器中输入 `httpbin` 服务的 URL 不能获得有效的响应，因为无法像 `curl` 那样，将请求头部参数 _Host_ 传给浏览器。在现实场景中，这并不是问题，因为你需要合理配置被请求的主机及可解析的 DNS，从而在 URL 中使用主机的域名，譬如： `https://httpbin.example.com/status/200`。
在浏览器中输入 `httpbin` 服务的 URL 不能获得有效的响应，因为无法像 `curl` 那样，将请求头部参数 _Host_ 传给浏览器。在现实场景中，这并不是问题，因为你需要合理配置被请求的主机及可解析的 DNS，从而在 URL 中使用主机的域名，譬如：`https://httpbin.example.com/status/200`。
为了在简单的测试和演示中绕过这个问题，请在 `Gateway` 和 `VirtualService` 配置中使用通配符 `*`。譬如，修改 ingress 配置如下：
@ -288,7 +288,7 @@ EOF
## 清除{#cleanup}
删除 `Gateway` 和 `VirtualService` 配置， 并关闭服务 [httpbin]({{< github_tree >}}/samples/httpbin)：
删除 `Gateway` 和 `VirtualService` 配置，并关闭服务 [httpbin]({{< github_tree >}}/samples/httpbin)：
{{< text bash >}}
$ kubectl delete gateway httpbin-gateway

2
content/zh/docs/tasks/traffic-management/ingress/ingress-sni-passthrough/index.md
View File

@ -162,7 +162,7 @@ aliases:
## 配置 ingress gateway{#configure-an-ingress-gateway}
1. 定义一个 `server` 部分的端口为 443 的 `Gateway`。 注意，`PASSTHROUGH tls mode` 指示 gateway 按原样通过入口流量，而不终止 TLS。
1. 定义一个 `server` 部分的端口为 443 的 `Gateway`。注意，`PASSTHROUGH tls mode` 指示 gateway 按原样通过入口流量，而不终止 TLS。
{{< text bash >}}
$ kubectl apply -f - <<EOF

6
content/zh/docs/tasks/traffic-management/ingress/secure-ingress-sds/index.md
View File

@ -27,7 +27,7 @@ keywords: [traffic-management,ingress,sds-credentials]
如果上面的命令输出了一段 LibreSSL 的版本信息，就说明你的 `curl` 命令可以完成本任务的内容。否则就要想办法换一个不同的 `curl` 了，例如可以换用一台运行 Linux 的工作站。
{{< tip >}}
如果使用[基于文件安装的方法](/zh/docs/tasks/traffic-management/ingress/secure-ingress-mount)配置了 ingress gateway ，并且想要迁移 ingress gateway 使用 SDS 方法。 无需其他步骤。
如果使用[基于文件安装的方法](/zh/docs/tasks/traffic-management/ingress/secure-ingress-mount)配置了 ingress gateway ，并且想要迁移 ingress gateway 使用 SDS 方法。无需其他步骤。
{{< /tip >}}
## 为服务器和客户端生成证书 {#generate-client-and-server-certificates-and-keys}
@ -176,7 +176,7 @@ keywords: [traffic-management,ingress,sds-credentials]
EOF
{{< /text >}}
1. 配置 Gateway 的 Ingress 流量路由，并配置对应的 `VirtualService`：：
1. 配置 Gateway 的 Ingress 流量路由，并配置对应的 `VirtualService`：
{{< text bash >}}
$ cat <<EOF | kubectl apply -f -
@ -549,7 +549,7 @@ $ kubectl create -n istio-system secret generic httpbin-credential \
-n istio-system -o jsonpath='{.items[0].metadata.name}') -c ingress-sds
{{< /text >}}
正常情况下，日志中应该显示 `httpbin-credential` 已经成功创建。如果使用的是双向 TLS，还应该看到 `httpbin-credential-cacert`。通过对日志的查看，能够验证 Ingress Gateway 代理从 Ingress Gateway 收到了 SDS 请求，资源名称是 `httpbin-credential`，Ingress Gateway 最后得到了应有的密钥/证书对。如果使用的是双向 TLS，日志会显示出密钥/证书对已经发送给 Ingress Gateway ， Gateway 代理接收到了资源名为 `httpbin-credential-cacert` 的 SDS 请求，Ingress Gateway 用这种方式获取根证书。
正常情况下，日志中应该显示 `httpbin-credential` 已经成功创建。如果使用的是双向 TLS，还应该看到 `httpbin-credential-cacert`。通过对日志的查看，能够验证 Ingress Gateway 代理从 Ingress Gateway 收到了 SDS 请求，资源名称是 `httpbin-credential`，Ingress Gateway 最后得到了应有的密钥/证书对。如果使用的是双向 TLS，日志会显示出密钥/证书对已经发送给 Ingress Gateway ，Gateway 代理接收到了资源名为 `httpbin-credential-cacert` 的 SDS 请求，Ingress Gateway 用这种方式获取根证书。
## 清理 {#cleanup}

4
content/zh/docs/tasks/traffic-management/request-routing/index.md
View File

@ -120,7 +120,7 @@ Istio [Bookinfo](/zh/docs/examples/bookinfo/) 示例包含四个独立的微服
您可以通过再次刷新 Bookinfo 应用程序的 `/productpage` 轻松测试新配置。
1. 在浏览器中打开 Bookinfo 站点。 网址为 `http://$GATEWAY_URL/productpage`，其中 `$GATEWAY_URL` 是外部的入口 IP 地址，如 [Bookinfo](/zh/docs/examples/bookinfo/#determine-the-ingress-IP-and-port) 文档中所述。
1. 在浏览器中打开 Bookinfo 站点。网址为 `http://$GATEWAY_URL/productpage`，其中 `$GATEWAY_URL` 是外部的入口 IP 地址，如 [Bookinfo](/zh/docs/examples/bookinfo/#determine-the-ingress-IP-and-port) 文档中所述。
请注意，无论您刷新多少次，页面的评论部分都不会显示评级星标。这是因为您将 Istio 配置为
将评论服务的所有流量路由到版本 `reviews:v1`，而此版本的服务不访问星级评分服务。
@ -131,7 +131,7 @@ Istio [Bookinfo](/zh/docs/examples/bookinfo/) 示例包含四个独立的微服
接下来，您将更改路由配置，以便将来自特定用户的所有流量路由到特定服务版本。在这，来自名为 Jason 的用户的所有流量将被路由到服务 `reviews:v2`。
请注意，Istio 对用户身份没有任何特殊的内置机制。事实上， `productpage` 服务在所有到 `reviews` 服务的 HTTP 请求中都增加了一个自定义的 `end-user` 请求头，从而达到了本例子的效果。
请注意，Istio 对用户身份没有任何特殊的内置机制。事实上，`productpage` 服务在所有到 `reviews` 服务的 HTTP 请求中都增加了一个自定义的 `end-user` 请求头，从而达到了本例子的效果。
请记住，`reviews:v2` 是包含星级评分功能的版本。

2
content/zh/events/banners/kubecon-america-2019.md
View File

@ -6,4 +6,4 @@ max_impressions: 20
timeout: 20
---
KubeCon 2019 北美会议， 11 月 18 日至 11 月 21 日，在圣地亚哥举办。
KubeCon 2019 北美会议，11 月 18 日至 11 月 21 日，在圣地亚哥举办。

2
content/zh/events/banners/kubecon-europe-2020.md
View File

@ -6,4 +6,4 @@ max_impressions: 20
timeout: 20
---
KubeCon 2020 欧洲会议， 3 月 30 日至 4 月 2 日，在阿姆斯特丹举办。
KubeCon 2020 欧洲会议，3 月 30 日至 4 月 2 日，在阿姆斯特丹举办。

2
content/zh/faq/_index.md
View File

@ -10,4 +10,4 @@ aliases:
icon: faq
---
您有问题吗？ 我们有答案！
您有问题吗？我们有答案！

2
content/zh/faq/applications/cassandra.md
View File

@ -5,7 +5,7 @@ weight: 50
keywords: [cassandra]
---
默认情况下，Cassandra 广播用于绑定（接受连接）到其他 Cassandra 节点的地址作为其地址。这通常是 Pod IP 地址，无需服务网格即可正常工作。但是，对于服务网格，此配置不起作用。Istio 和其他服务网格需要 `localhost` （`127.0.0.1`） 作为绑定地址。
默认情况下，Cassandra 广播用于绑定（接受连接）到其他 Cassandra 节点的地址作为其地址。这通常是 Pod IP 地址，无需服务网格即可正常工作。但是，对于服务网格，此配置不起作用。Istio 和其他服务网格需要 `localhost` （`127.0.0.1`）作为绑定地址。
有两个配置参数要注意：
[`listen_address`](http://cassandra.apache.org/doc/latest/configuration/cassandra_config_file.html?highlight=listen_address#listen-address) 和 [`broadcast_address`](http://cassandra.apache.org/doc/latest/configuration/cassandra_config_file.html?highlight=listen_address#broadcast-address)。为了在 Istio 网格中运行 Cassandra，应该将 `listen_address` 参数设置为 `127.0.0.1`，将 `broadcast_address` 参数设置为 Pod IP 地址。

2
content/zh/faq/distributed-tracing/how-distributed-tracing-works.md
View File

@ -3,6 +3,6 @@ title: 如何使用 Istio 实现分布式追踪？
weight: 0
---
Istio 以两种不同的方式与分布式追踪系统集成: 基于 [Envoy](#how-envoy-based-tracing-works)(#how-mixer-based-tracing-works) 的和基于 [Mixer](#how-mixer-based-tracing-works) 的。 这两种追踪集成方法，都由[应用程序负责为后续传出请求转发追踪的 header 信息](#istio-copy-headers)。
Istio 以两种不同的方式与分布式追踪系统集成: 基于 [Envoy](#how-envoy-based-tracing-works)(#how-mixer-based-tracing-works) 的和基于 [Mixer](#how-mixer-based-tracing-works) 的。这两种追踪集成方法，都由[应用程序负责为后续传出请求转发追踪的 header 信息](#istio-copy-headers)。
您可以在 Istio 分布式追踪（[Jaeger](/zh/docs/tasks/observability/distributed-tracing/jaeger/), [LightStep](/zh/docs/tasks/observability/distributed-tracing/lightstep/), [Zipkin](/zh/docs/tasks/observability/distributed-tracing/zipkin/)）任务以及 [Envoy 追踪文档](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/tracing)中找到更多信息。

2
content/zh/faq/distributed-tracing/how-envoy-based-tracing-works.md
View File

@ -12,4 +12,4 @@ Envoy：
- 将生成的跟踪范围发送到跟踪后端
- 将跟踪头转发到代理的应用程序
Istio 支持基于 Envoy 的 [LightStep](/zh/docs/tasks/observability/distributed-tracing/lightstep/) 和 [Zipkin](/zh/docs/tasks/observability/distributed-tracing/zipkin/) 的集成， 以及所有与 Zipkin API 兼容的后端，包括 [Jaeger](/zh/docs/tasks/observability/distributed-tracing/jaeger/)。
Istio 支持基于 Envoy 的 [LightStep](/zh/docs/tasks/observability/distributed-tracing/lightstep/) 和 [Zipkin](/zh/docs/tasks/observability/distributed-tracing/zipkin/) 的集成，以及所有与 Zipkin API 兼容的后端，包括 [Jaeger](/zh/docs/tasks/observability/distributed-tracing/jaeger/)。

2
content/zh/faq/distributed-tracing/how-mixer-based-tracing-works.md
View File

@ -3,7 +3,7 @@ title: 基于 Mixer 的跟踪是如何工作的？
weight: 12
---
对于基于 Mixer 的跟踪集成，Mixer （通过 `istio-telemetry` 服务解决） 提供了后端跟踪的集成。Mixer 集成允许操作员对分布式跟踪进行更高级别的控制，包括对跟踪范围中包含的数据进行细粒度选择。它还提供将跟踪发送给 Envoy 不直接支持的后端。
对于基于 Mixer 的跟踪集成，Mixer （通过 `istio-telemetry` 服务解决）提供了后端跟踪的集成。Mixer 集成允许操作员对分布式跟踪进行更高级别的控制，包括对跟踪范围中包含的数据进行细粒度选择。它还提供将跟踪发送给 Envoy 不直接支持的后端。
对于基于 Mixer 的集成，Envoy：

6
content/zh/faq/distributed-tracing/how-to-support-tracing.md
View File

@ -3,9 +3,9 @@ title: 使用 Istio 进行分布式追踪需要什么？
weight: 10
---
Istio 允许报告服务网格中工作负载到工作负载间通信的追踪 span。 然而，为了将各种追踪 span 整合在一起以获得完整的流量图，应用程序必须在传入和传出请求之间传播追踪上下文信息。
Istio 允许报告服务网格中工作负载到工作负载间通信的追踪 span。然而，为了将各种追踪 span 整合在一起以获得完整的流量图，应用程序必须在传入和传出请求之间传播追踪上下文信息。
特别是，Istio 依赖于应用程序传播 [B3 追踪 headers](https://github.com/openzipkin/b3-propagation) 以及由 Envoy 生成的请求 ID。 这些 header 包括:
特别是，Istio 依赖于应用程序传播 [B3 追踪 headers](https://github.com/openzipkin/b3-propagation) 以及由 Envoy 生成的请求 ID。这些 header 包括:
- `x-request-id`
- `x-b3-traceid`
@ -19,4 +19,4 @@ Istio 允许报告服务网格中工作负载到工作负载间通信的追踪 s
- `x-ot-span-context`
Header 传播可以通过客户端库完成，例如 [Zipkin](https://zipkin.io/pages/tracers_instrumentation.html) 或 [Jaeger](https://github.com/jaegertracing/jaeger-client-java/tree/master/jaeger-core#b3-propagation)。 当然，这也可以手动完成，正如[分布式追踪任务](/zh/docs/tasks/observability/distributed-tracing/overview#trace-context-propagation)中所描述的那样。
Header 传播可以通过客户端库完成，例如 [Zipkin](https://zipkin.io/pages/tracers_instrumentation.html) 或 [Jaeger](https://github.com/jaegertracing/jaeger-client-java/tree/master/jaeger-core#b3-propagation)。当然，这也可以手动完成，正如[分布式追踪任务](/zh/docs/tasks/observability/distributed-tracing/overview#trace-context-propagation)中所描述的那样。

4
content/zh/faq/metrics-and-logs/life-of-a-request.md
View File

@ -36,10 +36,10 @@ weight: 80
$ kubectl get virtualservices
{{< /text >}}
* Mixer 访问日志： Mixer 的访问日志中包含了关于请求的信息。您可以通过这样获取：
* Mixer 访问日志：Mixer 的访问日志中包含了关于请求的信息。您可以通过这样获取：
{{< text plain >}}
# 将 <istio namespace> 处改为您自己的 Istio namespace。 比如： istio-system
# 将 <istio namespace> 处改为您自己的 Istio namespace。比如：istio-system
$ TELEMETRY_POD=`kubectl get po -n <istio namespace> | grep istio-telemetry | awk '{print $1;}'`
$ kubectl logs $TELEMETRY_POD -c mixer -n istio-system | grep accesslog
{{< /text >}}

4
content/zh/faq/mixer/header-rules.md
View File

@ -8,5 +8,5 @@ Mixer 的规则必须在运行时验证。这意味着匹配条件的必须是[
并且规则所指向的 handler 和 instance 也必须存在。
在执行规则之前，属性值通常会被标准化。比如，在 `request.headers` 和 `response.headers` 属性中，HTTP 头的键是小写的。
表达式 `request.headers["X-Forwarded-Proto"] == "http"` 不会匹配任何请求，即使 HTTP 头部是不区分大小写的。
相反，应该使用这样的表达式 `request.headers["x-forwarded-proto"] == "http"`。
表达式 `request.headers ["X-Forwarded-Proto"] == "http"` 不会匹配任何请求，即使 HTTP 头部是不区分大小写的。
相反，应该使用这样的表达式 `request.headers ["x-forwarded-proto"] == "http"`。

2
content/zh/faq/mixer/writing-custom-adapters.md
View File

@ -8,7 +8,7 @@ weight: 40
了解有关如何为 Mixer 实施新适配器。
{{< idea >}}
Istio 1.0 开始支持进程外适配器。 这是推荐与 Mixer 持续集成的方法。 有关如何开始构建进程外适配器的文档有
Istio 1.0 开始支持进程外适配器。这是推荐与 Mixer 持续集成的方法。有关如何开始构建进程外适配器的文档有
[进程外适配器开发指南](https://github.com/istio/istio/wiki/Mixer-Out-Of-Process-Adapter-Dev-Guide)
和[进程外适配器概览](https://github.com/istio/istio/wiki/Mixer-Out-Of-Process-Adapter-Walkthrough)。
{{< /idea >}}

2
content/zh/faq/security/accessing-non-istio-services.md
View File

@ -3,7 +3,7 @@ title: 如何让 Istio 服务访问非 Istio 服务？
weight: 40
---
当启用了全局双向 TLS， *全局* 目标规则会匹配集群中的所有服务，无论这些服务是否具有 Istio sidecar。
当启用了全局双向 TLS，*全局* 目标规则会匹配集群中的所有服务，无论这些服务是否具有 Istio sidecar。
包括 Kubernetes API 服务器，以及群集中所有的非 Istio 服务。
想要通过具有 Istio sidecar 的服务访问这些非 Istio 服务，你需要设置目标规则，以豁免该服务。例如：

2
content/zh/faq/security/secret-encryption.md
View File

@ -5,4 +5,4 @@ weight: 125
默认情况下，它们是 base64 编码的，但未加密。但是，您可以按照 Kubernetes 中支持的[加密特性](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)来进行操作。
请注意，在 Google Container Engine (GKE) 中尚未启用此功能。 尽管可能不会在主节点上运行的 etcd 内部对数据进行加密，但主节点本身的内容将被加密，更多相关信息，请参照[此处](https://cloud.google.com/security/encryption-at-rest/default-encryption/#encryption_of_data_at_rest) 。
请注意，在 Google Container Engine (GKE) 中尚未启用此功能。尽管可能不会在主节点上运行的 etcd 内部对数据进行加密，但主节点本身的内容将被加密，更多相关信息，请参照[此处](https://cloud.google.com/security/encryption-at-rest/default-encryption/#encryption_of_data_at_rest) 。

2
content/zh/news/releases/0.x/announcing-0.1/index.md
View File

@ -15,7 +15,7 @@ aliases:
- /zh/news/announcing-0.1
---
Google、 IBM 和 Lyft 骄傲的宣布了 [Istio](/zh) 的首个公开版本。Istio 是一个以统一方式对微服务实施连接、管理、监控以及安全增强的开源项目。当前版本专注于支持 [Kubernetes](https://kubernetes.io/) 环境，我们计划在接下来的几个月添加诸如虚拟机和 Cloud Foundry 等环境的支持。
Google、IBM 和 Lyft 骄傲的宣布了 [Istio](/zh) 的首个公开版本。Istio 是一个以统一方式对微服务实施连接、管理、监控以及安全增强的开源项目。当前版本专注于支持 [Kubernetes](https://kubernetes.io/) 环境，我们计划在接下来的几个月添加诸如虚拟机和 Cloud Foundry 等环境的支持。
Istio 为微服务添加了流量管理能力，同时为比如安全、监控、路由、连接管理和策略等附加能力打下了基础。此软件构建于来自 Lyft 的经过实战检验的 [Envoy](https://envoyproxy.github.io/envoy/) 代理之上，能在 *无需改动任何应用代码* 的情况下赋予对应用流量的可见性和控制能力。Istio 为 CIO 们提供了一个在企业内加强安全、策略和合规性的强有力的工具。
## 背景{#background}

32
content/zh/news/releases/0.x/announcing-0.2/index.md
View File

@ -16,7 +16,7 @@ aliases:
我在 2017 年 5 月 24 日发布了 Istio ，它是一个用于连接、管理、监控和保护微服务的开放平台。看着饱含浓厚兴趣的开发者、运营商、合作伙伴和不断发展的社区，我们感到十分的欣慰。我们 0.1 版本的重点是展示 Istio 在 Kubernetes 中的所有概念。
今天我们十分高兴地宣布推出 0.2 版本，它提高了稳定性和性能、允许在 Kubernetes 集群中广泛部署并自动注入 sidecar 、为 TCP 服务添加策略和身份验证、同时保证扩展网格收录那些部署在虚拟机中的服务。此外，Istio 可以利用 Consul/Nomad 或 Eureka 在 Kubernetes 外部运行。 除了核心功能，Istio 的扩展已经准备由第三方公司和开发人员编写。
今天我们十分高兴地宣布推出 0.2 版本，它提高了稳定性和性能、允许在 Kubernetes 集群中广泛部署并自动注入 sidecar 、为 TCP 服务添加策略和身份验证、同时保证扩展网格收录那些部署在虚拟机中的服务。此外，Istio 可以利用 Consul/Nomad 或 Eureka 在 Kubernetes 外部运行。除了核心功能，Istio 的扩展已经准备由第三方公司和开发人员编写。
## 0.2 版本的亮点{#highlights-for-the-0.2-release}
@ -26,19 +26,19 @@ aliases:
- _TCP 服务的策略与安全_: 除了 HTTP ，我们还为 TCP 服务增加了透明双向 TLS 认证和策略实施。这将让拥有像遥测，策略和安全等 Istio 功能的同时，保护更多 Kubernetes deployment 。
- _自动注入 sidecar_: 通过利用 Kubernetes 1.7 提供的 alpha [初始化程序](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) ，当您的集群启用了该程序时，envoy sidecar 就可以自动注入到应用的 deployment 里。 这使得你可以使用 `kubectl` 命令部署微服务， 这与您通常在没有 Istio 的情况下部署微服务的命令完全相同。
- _自动注入 sidecar_: 通过利用 Kubernetes 1.7 提供的 alpha [初始化程序](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) ，当您的集群启用了该程序时，envoy sidecar 就可以自动注入到应用的 deployment 里。这使得你可以使用 `kubectl` 命令部署微服务，这与您通常在没有 Istio 的情况下部署微服务的命令完全相同。
- _扩展 Istio_ : 改进的 Mixer 设计，可以允许供应商编写 Mixer 适配器以实现对其自身系统的支持，例如应用管理或策略实施。该 [Mixer 适配器开发指南](https://github.com/istio/istio/wiki/Mixer-Compiled-In-Adapter-Dev-Guide)可以轻松的帮你将 Istio 集成于你的解决方案。
- _使用您自己的 CA 证书_: 允许用户提供自己的密钥和证书给 Istio CA 和永久 CA 密钥/证书存储，允许在持久化存储中提供签名密钥/证书，以便于 CA 重启。
- _改进路由和指标_: 支持 WebSocket 、MongoDB 和 Redis 协议。 您可以将弹性功能（如熔断器）应用于第三方服务。除了 Mixer 的指标外，数以百计 Envoy 指标现在已经在 Prometheus 中可见，它们用于监控 Istio 网格中的流量吞吐。
- _改进路由和指标_: 支持 WebSocket 、MongoDB 和 Redis 协议。您可以将弹性功能（如熔断器）应用于第三方服务。除了 Mixer 的指标外，数以百计 Envoy 指标现在已经在 Prometheus 中可见，它们用于监控 Istio 网格中的流量吞吐。
### 跨环境支持{#cross-environment-support}
- _网格扩展_: Istio 网格现在可以在 Kubernetes 之外跨服务 —— 就像那些运行在虚拟机中的服务一样，他们同时享受诸如自动双向 TLS 认证、流量管理、遥测和跨网格策略实施带来的好处。
- _运行在 Kubernetes 外部_: 我们知道许多客户使用其他的服务注册中心和 orchestration 解决方案（如 Consul/Nomad 和 Eureka）， Istio Pilot 可以在 Kubernetes 外部单独运行，同时从这些系统中获取信息，并在虚拟机或容器中管理 Envoy fleet 。
- _运行在 Kubernetes 外部_: 我们知道许多客户使用其他的服务注册中心和 orchestration 解决方案（如 Consul/Nomad 和 Eureka），Istio Pilot 可以在 Kubernetes 外部单独运行，同时从这些系统中获取信息，并在虚拟机或容器中管理 Envoy fleet 。
## 加入到塑造 Istio 未来的队伍中{#get-involved-in-shaping-the-future-of-Istio}
@ -54,43 +54,43 @@ aliases:
### 通用{#general}
- **更新配置模型**。 Istio 现在使用了 Kubernetes 的 [Custom Resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
- **更新配置模型**。Istio 现在使用了 Kubernetes 的 [Custom Resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
来描述和存储其配置。当运行在 Kubernetes 上时，现在可以使用 `kubectl` 命令来管理配置。
- **多 namespace 的支持**。 Istio 控制平面组件现在位于专用的 `istio-system` namespace 下。
- **多 namespace 的支持**。Istio 控制平面组件现在位于专用的 `istio-system` namespace 下。
Istio 可以管理其他非系统名称空间中的服务。
- **Mesh 扩展**。 初步支持将非 Kubernetes 服务（以 VM 和/或 物理机的形式）添加到网格中。
- **Mesh 扩展**。初步支持将非 Kubernetes 服务（以 VM 和/或 物理机的形式）添加到网格中。
这是此功能的早期版本，存在一些限制（例如，要求在容器和 VM 之间建立扁平网络）。
- **多环境的支持**。初步支持将 Istio 与其他服务注册表（包括 Consul 和 Eureka ）结合使用。
- **自动注入 Sidecar**。 使用 Kubernetes 中的 [Initializers](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) alpha 功能，可以在部署后将 Istio 边车自动注入到 Pod 中。
- **自动注入 Sidecar**。使用 Kubernetes 中的 [Initializers](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) alpha 功能，可以在部署后将 Istio 边车自动注入到 Pod 中。
### 性能及品质{#performance-and-quality}
整个系统在性能和可靠性方面都有许多改进。
我们尚未考虑将 Istio 0.2 用于生产，但我们在这一方面取得了长足的进步。以下是一些注意事项：
- **缓存客户端**。 现在，Envoy 使用的 Mixer 客户端库为 Check 调用提供了缓存，为 Report 调用提供了批处理，从而大大减少了端到端的开销。
- **缓存客户端**。现在，Envoy 使用的 Mixer 客户端库为 Check 调用提供了缓存，为 Report 调用提供了批处理，从而大大减少了端到端的开销。
- **避免热重启**。 通过有效使用 LDS/RDS/CDS/EDS，基本上消除了 Envoy 需要热重启的情况。
- **避免热重启**。通过有效使用 LDS/RDS/CDS/EDS，基本上消除了 Envoy 需要热重启的情况。
- **减少内存使用**。 大大减少了 Sidecar 辅助代理的大小，从 50Mb 减少到了 7Mb。
- **减少内存使用**。大大减少了 Sidecar 辅助代理的大小，从 50Mb 减少到了 7Mb。
- **改善 Mixer 延迟**。 Mixer 现在可以清楚地描述配置时间和请求时间的计算，这样可以避免在请求时针对初始请求进行额外的设置工作，从而提供更平滑的平均延迟。
- **改善 Mixer 延迟**。Mixer 现在可以清楚地描述配置时间和请求时间的计算，这样可以避免在请求时针对初始请求进行额外的设置工作，从而提供更平滑的平均延迟。
更好的资源缓存还有助于提高端到端性能。
- **减少 Egress 流量的延迟**。现在，我们直接将流量从 sidecar 转发到外部服务。
### 流量管理{#traffic-management}
- **Egress 规则**。 现在可以为 Egress 流量指定路由规则。
- **Egress 规则**。现在可以为 Egress 流量指定路由规则。
- **新协议**。 Mesh-wide 现在支持 WebSocket 链接, MongoDB 代理,
- **新协议**。Mesh-wide 现在支持 WebSocket 链接, MongoDB 代理,
和 Kubernetes [headless 服务](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services)。
- **其它改进**。 Ingress 正确支持 gRPC 服务，更好的支持健康检查和 Jaeger 追踪。
- **其它改进**。Ingress 正确支持 gRPC 服务，更好的支持健康检查和 Jaeger 追踪。
### 策略执行及遥测{#policy-enforcement-telemetry}
@ -108,7 +108,7 @@ Istio 可以管理其他非系统名称空间中的服务。
- **Mixer Adapter 更新**。内置适配器已全部重写以适合新的适配器模型。该版本已添加了 `stackdriver` 适配器。
实验性的 `redisquota` 适配器已从 0.2 版本中删除，但有望在 生产就绪的 0.3 版本中回归。
- **Mixer 调用追踪**。 现在可以在 Zipkin 仪表板中跟踪和分析 Envoy 和 Mixer 之间的调用。
- **Mixer 调用追踪**。现在可以在 Zipkin 仪表板中跟踪和分析 Envoy 和 Mixer 之间的调用。
### 安全{#security}

2
content/zh/news/releases/0.x/announcing-0.5/index.md
View File

@ -36,7 +36,7 @@ aliases:
## 安全{#security}
- **使用你自己的 CA**。多项针对 ‘使用你自己的 CA’ 特性的改进。[了解更多](/zh/docs/tasks/security/citadel-config/plugin-ca-cert/)
- **使用你自己的 CA**。多项针对 ‘使用你自己的 CA’特性的改进。[了解更多](/zh/docs/tasks/security/citadel-config/plugin-ca-cert/)
- **PKCS8**。将 PKCS8 密钥的支持添加到 Istio PKI。

4
content/zh/news/releases/0.x/announcing-0.8/index.md
View File

@ -18,9 +18,9 @@ aliases:
## 网络{#networking}
- **改良的流量管理模型**。我们终于准备好完成我们的[新流量管理 API](/zh/blog/2018/v1alpha3-routing/) 的总结。 我们相信，在涵盖更多实际部署[用例](/zh/docs/tasks/traffic-management/)的同时，这种新模型更易于理解。 对于从早期发行版升级的人，这儿有一个[迁移指南](/zh/docs/setup/upgrade/)和内置在 `istioctl` 中的转换工具，可帮助您从旧模型转换配置。
- **改良的流量管理模型**。我们终于准备好完成我们的[新流量管理 API](/zh/blog/2018/v1alpha3-routing/) 的总结。我们相信，在涵盖更多实际部署[用例](/zh/docs/tasks/traffic-management/)的同时，这种新模型更易于理解。对于从早期发行版升级的人，这儿有一个[迁移指南](/zh/docs/setup/upgrade/)和内置在 `istioctl` 中的转换工具，可帮助您从旧模型转换配置。
- **Envoy 流式配置**。默认情况下，Pilot 现在使用其 [ADS API](https://github.com/envoyproxy/data-plane-api/blob/master/xds_protocol.rst) 将配置流式传输到 Envoy。 这种新方法提高了有效的可伸缩性，减少了推出延迟，应该能消除虚假的 404 错误。
- **Envoy 流式配置**。默认情况下，Pilot 现在使用其 [ADS API](https://github.com/envoyproxy/data-plane-api/blob/master/xds_protocol.rst) 将配置流式传输到 Envoy。这种新方法提高了有效的可伸缩性，减少了推出延迟，应该能消除虚假的 404 错误。
- **Ingress/Egress 的 Gateway**。我们不再支持将 Kubernetes Ingress 规范与 Istio 路由规则结合使用，因为它导致了许多错误和可靠性问题。Istio 现在支持用于 ingress 和 egress 代理的独立于平台的 [Gateway](/zh/docs/concepts/traffic-management/#gateways) 模型，该模型可跨 Kubernetes 和 Cloud Foundry 使用，并与路由无缝协作。Gateway 支持基于[服务器名称指示](https://en.wikipedia.org/wiki/Server_Name_Indication)的路由，并基于客户端提供的服务器名称提供证书。

2
content/zh/news/releases/1.0.x/announcing-1.0.7/index.md
View File

@ -37,7 +37,7 @@ aliases:
- 1.0.6 与 1.0.7 是基于相同源码构建的，仅添加了解决 CVE 的 Envoy 补丁。
- 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8
- 这些发行版不再受支持，也不会进行修补。 请升级到受支持的版本，以获取必要的修复程序。
- 这些发行版不再受支持，也不会进行修补。请升级到受支持的版本，以获取必要的修复程序。
## 漏洞影响{#vulnerability-impact}

2
content/zh/news/releases/1.1.x/announcing-1.1.2/index.md
View File

@ -37,7 +37,7 @@ aliases:
- 1.0.6 与 1.0.7 是基于相同源码构建的，仅添加了解决 CVE 的 Envoy 补丁。
- 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8
- 这些发行版不再受支持，也不会进行修补。 请升级到受支持的版本，以获取必要的修复程序。
- 这些发行版不再受支持，也不会进行修补。请升级到受支持的版本，以获取必要的修复程序。
## 漏洞影响{#vulnerability-impact}

2
content/zh/news/releases/1.1.x/announcing-1.1.4/index.md
View File

@ -40,7 +40,7 @@ aliases:
- 修复了节点代理中的崩溃错误 ([Issue 13325](https://github.com/istio/istio/issues/13325))。
- 添加了缺少的验证，以防止网关名称包含点（.） ([Issue 13211](https://github.com/istio/istio/issues/13211))。
- 添加了缺少的验证，以防止网关名称包含点（.）([Issue 13211](https://github.com/istio/istio/issues/13211))。
- 修复了 [`ConsistentHashLB.minimumRingSize`](/zh/docs/reference/config/networking/destination-rule#LoadBalancerSettings-ConsistentHashLB)
默认为 0 而不是记录的 1024 ([Issue 13261](https://github.com/istio/istio/issues/13261))。

2
content/zh/news/releases/1.1.x/announcing-1.1/change-notes/index.md
View File

@ -102,7 +102,7 @@ aliases:
### 配置管理{#configuration-management}
- **Galley**。添加 [Galley](/zh/docs/ops/deployment/architecture/#galley) 作为 Istio 主要的配置收集和分发装置。它提供了一个健壮的模型来验证，转换配置状态并将其分配给 Istio 组件，从而将 Istio 组件与 Kubernetes 详细信息隔离开来。Galley 使用[网格配置协议](https://github.com/istio/api/tree/{{<source_branch_name >}}/mcp) 与组件进行交互。
- **Galley**。添加 [Galley](/zh/docs/ops/deployment/architecture/#galley) 作为 Istio 主要的配置收集和分发装置。它提供了一个健壮的模型来验证，转换配置状态并将其分配给 Istio 组件，从而将 Istio 组件与 Kubernetes 详细信息隔离开来。Galley 使用[网格配置协议](https://github.com/istio/api/tree/{{<source_branch_name>}}/mcp)与组件进行交互。
- **监听端口**。将 Galley 的默认监听端口从 9093 修改为 15014。

2
content/zh/news/releases/1.2.x/announcing-1.2.1/index.md
View File

@ -20,7 +20,7 @@ aliases:
- 修复在安装中生成重复 CRD 的问题（[Issue 14976](https://github.com/istio/istio/issues/14976)）
- 修复禁用 Galley 时无法启动 Mixer 的问题（[Issue 14841](https://github.com/istio/istio/issues/14841)）
- 修复环境变量遮蔽的问题（NAMESPACE 用于监控的命名空间覆盖了 Citadel 的存储命名空间（istio-system））
- 修复环境变量遮蔽的问题（NAMESPACE 用于监控的命名空间覆盖了 Citadel 的存储命名空间（istio-system）
- 修复升级过程中的 'TLS error: Secret is not supplied by SDS' 错误（[Issue 15020](https://github.com/istio/istio/issues/15020)）
## 次要改进{#minor-enhancements}

2
content/zh/news/releases/1.2.x/announcing-1.2.10/index.md
View File

@ -17,7 +17,7 @@ aliases:
- **ISTIO-SECURITY-2019-007** 在 Envoy 中发现了堆溢出和不正确的输入验证。
__[CVE-2019-18801](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18801)__：修复了一个影响 Envoy 处理大型 HTTP/2 请求 header 的漏洞。 成功利用此漏洞可能导致拒绝服务、特权提升或信息泄露。
__[CVE-2019-18801](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18801)__：修复了一个影响 Envoy 处理大型 HTTP/2 请求 header 的漏洞。成功利用此漏洞可能导致拒绝服务、特权提升或信息泄露。
__[CVE-2019-18802](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18802)__：修复了 HTTP/1 header 值后的空格引起的漏洞，该漏洞可能使攻击者绕过 Istio 的策略检查，从而可能导致信息泄露或特权提升。

8
content/zh/news/releases/1.2.x/announcing-1.2/change-notes/index.md
View File

@ -8,7 +8,7 @@ aliases:
## 通用功能 {#general}
- **增加** `traffic.sidecar.istio.io/includeInboundPorts` 标注可以让服务所有者不需要在 deployment yaml 文件中配置 `containerPort` 字段。 这会是未来版本中的默认做法。
- **增加** `traffic.sidecar.istio.io/includeInboundPorts` 标注可以让服务所有者不需要在 deployment yaml 文件中配置 `containerPort` 字段。这会是未来版本中的默认做法。
- **增加** 对 Kubernetes 集群的 IPv6 试验性支持。
## 流量管理 {#traffic-management}
@ -23,8 +23,8 @@ aliases:
## 安全 {#security}
- **改进** 将自签名 Citadel 根证书的默认生存期延长到 10 年。
- **增加** 通过[标注](/zh/docs/ops/configuration/mesh/app-health-check/#use-annotations-on-pod) `PodSpec` 中`sidecar.istio.io/rewriteAppHTTPProbers: "true"` 字段，Kubernetes 的健康检查探测器会重写每个 deployment。
- **增加** 支持给 Istio 双向 TLS 证书配置密钥路径。 更多信息请看[这里](https://github.com/istio/istio/issues/11984)。
- **增加** 通过 [标注](/zh/docs/ops/configuration/mesh/app-health-check/#use-annotations-on-pod) `PodSpec` 中`sidecar.istio.io/rewriteAppHTTPProbers: "true"` 字段，Kubernetes 的健康检查探测器会重写每个 deployment。
- **增加** 支持给 Istio 双向 TLS 证书配置密钥路径。更多信息请看[这里](https://github.com/istio/istio/issues/11984)。
- **增加** 通过启用 Citadel 上的 `pkcs8-keys` 来支持 workload 使用 [PKCS 8](https://en.wikipedia.org/wiki/PKCS_8) 私钥。
- **改进** JWT 公钥获取逻辑在网络失败的时候更可靠。
- **修复** workload 证书中的 [SAN](https://tools.ietf.org/html/rfc5280#section-4.2.1.6) 字段设置为 `critical`。这是修复了一些自定义证书验证服务无法验证 Istio 证书的问题。
@ -56,7 +56,7 @@ aliases:
- **增加** `sidecarInjectorWebhook.neverInjectSelector` 和 `sidecarInjectorWebhook.alwaysInjectSelector` 配置，通过标签选择器让用户可以进一步控制 workload 是否应该自动注入 sidecar。
- **增加** `global.logging.level` 和 `global.proxy.logLevel` 配置，允许用户方便的给控制平面和数据平面组件全局的配置日志。
- **增加** 支持通过设置 [`global.tracer.datadog.address`](/zh/docs/reference/config/installation-options/#global-options) 来配置 Datadog 的地址。
- **移除** 默认情况下禁止使用早期[被弃用](https://discuss.istio.io/t/deprecation-notice-custom-mixer-adapter-crds/2055) 的适配器和 CRD 模版。可以使用 `mixer.templates.useTemplateCRDs=true` 和 `mixer.adapters.useAdapterCRDs=true` 安装配置项来重新启用这两个功能。
- **移除** 默认情况下禁止使用早期[被弃用](https://discuss.istio.io/t/deprecation-notice-custom-mixer-adapter-crds/2055)的适配器和 CRD 模版。可以使用 `mixer.templates.useTemplateCRDs=true` 和 `mixer.adapters.useAdapterCRDs=true` 安装配置项来重新启用这两个功能。
要看全部的变动，请参阅[安装选项变动页面](/zh/news/releases/1.2.x/announcing-1.2/helm-changes/)。

4
content/zh/news/releases/1.3.x/announcing-1.3.3/index.md
View File

@ -17,8 +17,8 @@ aliases:
## Bug 修复{#bug-fixes}
- **Fixed** 当使用 `istioctl x manifest apply` 时导致 Prometheus 安装不正确的问题。（[Issue 16970](https://github.com/istio/istio/issues/16970)）
- **Fixed** 本地负载均衡不能从本地节点读取位置信息的错误。 （[Issue 17337](https://github.com/istio/istio/issues/17337)）
- **Fixed** 当侦听器在没有任何用户配置更改的情况下进行重新配置时，Envoy 代理会删除长连接。 （[Issue 17383](https://github.com/istio/istio/issues/17383)，[Issue 17139](https://github.com/istio/istio/issues/17139)）
- **Fixed** 本地负载均衡不能从本地节点读取位置信息的错误。（[Issue 17337](https://github.com/istio/istio/issues/17337)）
- **Fixed** 当侦听器在没有任何用户配置更改的情况下进行重新配置时，Envoy 代理会删除长连接。（[Issue 17383](https://github.com/istio/istio/issues/17383)，[Issue 17139](https://github.com/istio/istio/issues/17139)）
- **Fixed** `istioctl x analyze` 命令的崩溃问题。（[Issue 17449](https://github.com/istio/istio/issues/17449)）
- **Fixed** `istioctl x manifest diff` 命令中 ConfigMaps 中的差异文本块。（[Issue 16828](https://github.com/istio/istio/issues/16828)）
- **Fixed** Envoy proxy 的分段错误崩溃问题。（[Issue 17699](https://github.com/istio/istio/issues/17699)）

2
content/zh/news/releases/1.3.x/announcing-1.3.6/index.md
View File

@ -17,7 +17,7 @@ aliases:
- **ISTIO-SECURITY-2019-007** 在 Envoy 中发现了堆溢出和不正确的输入验证。
__[CVE-2019-18801](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18801)__：修复了一个影响 Envoy 处理大型 HTTP/2 请求 header 的漏洞。 成功利用此漏洞可能导致拒绝服务、特权提升或信息泄露。
__[CVE-2019-18801](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18801)__：修复了一个影响 Envoy 处理大型 HTTP/2 请求 header 的漏洞。成功利用此漏洞可能导致拒绝服务、特权提升或信息泄露。
__[CVE-2019-18802](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18802)__：修复了 HTTP/1 header 值后的空格引起的漏洞，该漏洞可能使攻击者绕过 Istio 的策略检查，从而可能导致信息泄露或特权提升。

2
content/zh/news/releases/1.3.x/announcing-1.3.7/index.md
View File

@ -31,4 +31,4 @@ aliases:
* [**ISTIO-SECURITY-2020-002**](/zh/news/security/istio-security-2020-002) 由于不正确地接受某些请求 header，导致可绕过 Mixer 策略检查。
__[CVE-2020-8843](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8843)__：在某些情况下，可以绕过特定配置的 Mixer 策略。Istio-proxy 在 ingress 处接受 `x-istio-attributes` header，当 Mixer 策略有选择地应用至 source 时，等价于应用至 ingress，其可能会影响策略决策。 Istio 1.3 到 1.3.6 容易受到攻击。
__[CVE-2020-8843](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8843)__：在某些情况下，可以绕过特定配置的 Mixer 策略。Istio-proxy 在 ingress 处接受 `x-istio-attributes` header，当 Mixer 策略有选择地应用至 source 时，等价于应用至 ingress，其可能会影响策略决策。Istio 1.3 到 1.3.6 容易受到攻击。

2
content/zh/news/releases/1.4.x/announcing-1.4.2/index.md
View File

@ -17,6 +17,6 @@ aliases:
- **ISTIO-SECURITY-2019-007** 在 Envoy 中发现了堆溢出和不正确的输入验证。
__[CVE-2019-18801](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18801)__：修复了一个影响 Envoy 处理大型 HTTP/2 请求 header 的漏洞。 成功利用此漏洞可能导致拒绝服务、特权提升或信息泄露。
__[CVE-2019-18801](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18801)__：修复了一个影响 Envoy 处理大型 HTTP/2 请求 header 的漏洞。成功利用此漏洞可能导致拒绝服务、特权提升或信息泄露。
__[CVE-2019-18802](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18802)__：修复了 HTTP/1 header 值后的空格引起的漏洞，该漏洞可能使攻击者绕过 Istio 的策略检查，从而可能导致信息泄露或特权提升。

Some files were not shown because too many files have changed in this diff Show More