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" >}}

2
content/zh/about/contribute/build/index.md
View File

@ -57,4 +57,4 @@ $ make lint
$ make INTERNAL_ONLY=True lint
{{< /text >}}
当修改内容通过所有检查，就可以把修改作为 PR 向仓库提交了。更多信息请访问[如何使用 GitHub](/zh/about/contribute/github)。
当修改内容通过所有检查，就可以把修改作为 PR 向仓库提交了。更多信息请访问[如何使用 GitHub](/zh/about/contribute/github)。

10
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%"
@ -102,7 +102,7 @@ Hugo 的 shortcode 是具有特定语法的特殊占位符，您可以将其添
[RawVM MySQL]({{</* github_blob */>}}/samples/rawvm/README.md)
{{< /text >}}
上面的 shortcode 会根据文档当前的目标分支，生成指向 GitHub 中对应分支的链接。要查看当前目标分支的名称，可以使用 `{{</* source_branch_name */>}}` shortcode 来获取当前目标分支的名称。
上面的 shortcode 会根据文档当前的目标分支，生成指向 GitHub 中对应分支的链接。要查看当前目标分支的名称，可以使用 `{{</* source_branch_name */>}}` shortcode 来获取当前目标分支的名称。
## 版本信息{#version-information}
@ -113,7 +113,7 @@ Hugo 的 shortcode 是具有特定语法的特殊占位符，您可以将其添
## 术语表{#glossary-terms}
当您在页面中介绍一个 Istio 术语时，贡献补充条款要求您将该术语包含在 `glossary` 中，并使用 shortcode `{{</* gloss */>}}` 标记它的第一个实例。 shortcode 会对其进行特殊渲染，读者点击该术语，可以在弹出的窗口中获取该术语的定义。例如：
当您在页面中介绍一个 Istio 术语时，贡献补充条款要求您将该术语包含在 `glossary` 中，并使用 shortcode `{{</* gloss */>}}` 标记它的第一个实例。shortcode 会对其进行特殊渲染，读者点击该术语，可以在弹出的窗口中获取该术语的定义。例如：
{{< text markdown >}}
Mixer 使用 {{</*gloss*/>}}adapters{{</*/gloss*/>}} 与后端进行交互。
@ -177,7 +177,7 @@ Mixer 使用 {{< gloss adapters >}}适配器{{</ gloss >}} 与后端进行交互
## 使用样板文本{#use-boilerplate-text}
要想在保持内容单一来源的情况下重用内容，请使用样板 shortcode 。要将样板文本嵌入任何内容文件中，请使用 `boilerplate` shortcode ，如下所示：
要想在保持内容单一来源的情况下重用内容，请使用样板 shortcode 。要将样板文本嵌入任何内容文件中，请使用 `boilerplate` shortcode ，如下所示：
{{< text markdown >}}
{{</* boilerplate example */>}}
@ -197,7 +197,7 @@ Mixer 使用 {{< gloss adapters >}}适配器{{</ gloss >}} 与后端进行交互
- 不同语言的等效代码
- 替代的配置
要添加选项卡式内容，请组合使用 shortcode `tabset` 和 `tabs`，例如：
要添加选项卡式内容，请组合使用 shortcode `tabset` 和 `tabs`，例如：
{{< text markdown >}}
{{</* tabset category-name="platform" */>}}

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

@ -31,12 +31,12 @@ keywords: [contribute, documentation, guide, code-block]
- “Envoy sidecar” - 这样说没问题
- “Envoy proxy” - 这样说没问题
- “The Istio proxy” -- 最好避免这样说，除非说的是另外一个可能使用其它代理的高级场景。
- “Sidecar” -- 大多时候仅限于概念文档中使用
- “Sidecar” -- 大多时候仅限于概念文档中使用
- “Proxy” -- 只有在上下文非常容易理解的时候
相关术语：
- Proxy agent - 这是一个较小的基础设施组件，应该只出现在低层的详细文档中。它不是专有名词。
- Proxy agent - 这是一个较小的基础设施组件，应该只出现在低层的详细文档中。它不是专有名词。
## 其它 {#miscellaneous}

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)找到对应的示例。

8
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,13 +25,13 @@ target_release: 1.0
## IAM Policy
你需要在主角色上应用策略， 以便能够配置网络负载均衡器。
你需要在主角色上应用策略，以便能够配置网络负载均衡器。
1. 在 AWS `iam` 控制台中，点击策略并单击“创建新策略”：
1. 在 AWS `iam` 控制台中，点击策略并单击“创建新策略”：
{{< image width="80%" link="./createpolicystart.png" caption="创建一个新的策略" >}}
1. 选择 `json`:
1. 选择 `json`:
{{< image width="80%" link="./createpolicyjson.png" caption="选择 json" >}}

2
content/zh/blog/2018/delayering-istio/index.md
View File

@ -116,7 +116,7 @@ AppSwitch 提供了无需 root 特权就能重定向应用连接的方法。这
1. 发送 Socket 对中的一端给应用，应用会用这个 FD 进行读写。它还要确保应用始终视其为合法 Socket，以便于侵入所有对连接属性的查询。
1. 另外一端会通过一个不同的用于开放守护进程 API 的 Unix Socket 发送给 Sidecar。原始目的之类的信息也会由相同的接口进行传输。
{{< image width="50%" link="socket-delegation.png" alt="Socket 委托协议" caption="基于 Socket 委托的连接重定向" >}}
{{< image width="50%" link="socket-delegation.png" alt="Socket 委托协议" caption="基于 Socket 委托的连接重定向" >}}
应用和 Sidecar 连接之后，接下来的事情就很普通了。Sidecar 初始化一个到上游服务器的连接，并在从守护进程接收到的 Socket 和连接到上游服务器的 Socket 之间充当数据代理。这里的主要区别在于，Sidecar 得到的连接不是通过 `accept(2)` 系统调用而来的，而是由守护进程的 Unix socket 来的。Sidecar 不再通过监听来自应用的 `accept(2)` 通道，而是连接到 AppSwitch 守护进程的 REST 端点获取到的 Socket。

16
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}
@ -210,7 +210,7 @@ env:
## 具有 TLS 的 Bookinfo 起源于 Google Books 网络服务{#Bookinfo-with-TLS-origination-to-a-google-books-web-service}
1. 部署 _details v2_ 版本，将 HTTP 请求发送到 [Google Books API](https://developers.google.com/books/docs/v1/getting_started)。
1. 部署 _details v2_ 版本，将 HTTP 请求发送到 [Google Books API](https://developers.google.com/books/docs/v1/getting_started)。
在 [`bookinfo-details-v2.yaml`]({{<github_file>}}/samples/bookinfo/platform/kube/bookinfo-details-v2.yaml) 中，
`DO_NOT_ENCRYPT` 变量设置为 true。
@ -218,13 +218,13 @@ env:
$ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo-details-v2.yaml@
{{< /text >}}
1. 将指向 _details_ 微服务的流量定向到 _details v2_。
1. 将指向 _details_ 微服务的流量定向到 _details v2_。
{{< text bash >}}
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-details-v2.yaml@
{{< /text >}}
1. 为 `www.google.apis` 创建网格外部 `ServiceEntry`，virtual service 将目标端口从 80 重写为 443，并执行 TLS 的 `destination rule`。
1. 为 `www.google.apis` 创建网格外部 `ServiceEntry`，virtual service 将目标端口从 80 重写为 443，并执行 TLS 的 `destination rule`。
{{< text bash >}}
$ kubectl apply -f - <<EOF
@ -277,11 +277,11 @@ env:
EOF
{{< /text >}}
1. 访问应用程序的网页，并验证显示的书籍详细信息没有错误。
1. 访问应用程序的网页，并验证显示的书籍详细信息没有错误。
1. [开启 Envoy 访问记录功能](/zh/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging)
1. [开启 Envoy 访问记录功能](/zh/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging)
1. 检查 _details v2_ 的 sidecar 代理的日志，并查看 HTTP 请求。
1. 检查 _details v2_ 的 sidecar 代理的日志，并查看 HTTP 请求。
{{< text bash >}}
$ kubectl logs $(kubectl get pods -l app=details -l version=v2 -o jsonpath='{.items[0].metadata.name}') istio-proxy | grep googleapis

22
content/zh/blog/2018/egress-mongo/index.md
View File

@ -50,7 +50,7 @@ target_release: 1.1
EOF
{{< /text >}}
1. 创建一个 _collection_ 来保存评级数据。以下命令将两个评级都设置为 `1`，以便在 Bookinfo _ratings_ service 使用数据库时提供视觉验证（默认 Bookinfo _ratings_
1. 创建一个 _collection_ 来保存评级数据。以下命令将两个评级都设置为 `1`，以便在 Bookinfo _ratings_ service 使用数据库时提供视觉验证（默认 Bookinfo _ratings_
为 `4` 和 `5`）
{{< text bash >}}
@ -86,7 +86,7 @@ target_release: 1.1
### Bookinfo 应用程序的初始设置{#Initial-setting-of-Bookinfo-application}
为了演示使用外部数据库的场景，请首先运行一个[安装了 Istio](/zh/docs/setup/getting-started/) 的 Kubernetes 集群。然后部署
[Istio Bookinfo 示例应用程序](/zh/docs/examples/bookinfo/)并[应用默认 destination rules](/zh/docs/examples/bookinfo/#apply-default-destination-rules) 和[改变 Istio 到 blocking-egress-by-default 策略](/zh/docs/tasks/traffic-management/egress/egress-control/#change-to-the-blocking-by-default-policy)。
[Istio Bookinfo 示例应用程序](/zh/docs/examples/bookinfo/)并[应用默认 destination rules](/zh/docs/examples/bookinfo/#apply-default-destination-rules) 和[改变 Istio 到 blocking-egress-by-default 策略](/zh/docs/tasks/traffic-management/egress/egress-control/#change-to-the-blocking-by-default-policy)。
此应用程序从 `ratings` 微服务获取书籍评级（1 到 5 的数字）。评级以星标形式显示每条评论。`ratings` 微服务有几个版本。在下一小节中，请部署使用 [MongoDB](https://www.mongodb.com)
作为 ratings 数据库的版本。
@ -107,7 +107,7 @@ target_release: 1.1
deployment "ratings-v2" created
{{< /text >}}
1. 为你的 MongoDB 设置 `MONGO_DB_URL` 环境变量：
1. 为你的 MongoDB 设置 `MONGO_DB_URL` 环境变量：
{{< text bash >}}
$ kubectl set env deployment/ratings-v2 "MONGO_DB_URL=mongodb://bookinfo:$BOOKINFO_PASSWORD@$MONGODB_HOST:$MONGODB_PORT/test?authSource=test&ssl=true"
@ -191,17 +191,17 @@ $ export MONGODB_IP=$(host $MONGODB_HOST | grep " has address " | cut -d" " -f4)
请注意，和预期的一样，您会看到两个显示评论的一星评级。您将评级设置为一星，以作为外部数据库确实被使用了的视觉证据。
1. 如果要通过出口网关引导流量，请继续下一节。否则，请执行 [cleanup](#cleanup-of-TCP-egress-traffic-control).
1. 如果要通过出口网关引导流量，请继续下一节。否则，请执行 [cleanup](#cleanup-of-TCP-egress-traffic-control).
### 通过 egress gateway 定向 TCP Egress 流量{#direct-TCP-egress-traffic-through-an-egress-gateway}
在本节中，您将处理通过 [egress gateway](/zh/docs/tasks/traffic-management/egress/egress-gateway/#use-case) 定向流量的情况。Sidecar 代理通过匹配 MongoDB 主机的 IP 地址（一个 32 位长度的 CIDR 块），将 TCP 连接从 MongoDB 客户端路由到 egress gateway。Egress gateway 按照其 hostname，转发流量到 MongoDB 主机。
1. [部署 Istio egress gateway](/zh/docs/tasks/traffic-management/egress/egress-gateway/#deploy-Istio-egress-gateway).
1. [部署 Istio egress gateway](/zh/docs/tasks/traffic-management/egress/egress-gateway/#deploy-Istio-egress-gateway).
1. 如果您未执行[上一节](#control-TCP-egress-traffic-without-a-gateway)中的步骤，则立即执行这些步骤。
1. 您可能希望启用 sidecar 代理和 MongoDB 客户端之间以及 egress gateway 的 {{< gloss >}}mutual TLS Authentication{{< /gloss >}}，以使 egress gateway 监控来源 pod 的身份并基于该 identity 启用 Mixer 策略。启用双向 TLS 时同样对流量进行了加密。
1. 您可能希望启用 sidecar 代理和 MongoDB 客户端之间以及 egress gateway 的 {{< gloss >}}mutual TLS Authentication{{< /gloss >}}，以使 egress gateway 监控来源 pod 的身份并基于该 identity 启用 Mixer 策略。启用双向 TLS 时同样对流量进行了加密。
如果你不想开启双向 TLS，参考 [Mutual TLS between the sidecar proxies and the egress gateway](#mutual-TLS-between-the-sidecar-proxies-and-the-egress-gateway) 小节
否则，请继续以下部分。
@ -432,9 +432,9 @@ $ export MONGODB_IP=$(host $MONGODB_HOST | grep " has address " | cut -d" " -f4)
#### 验证 TCP egress 流量是否通过 egress gateway 定向{#verify-that-egress-traffic-is-directed-through-the-egress-gateway}
1. 再次刷新应用程序的网页，并验证等级是否仍正确显示。
1. 再次刷新应用程序的网页，并验证等级是否仍正确显示。
1. [开启 Envoy 访问日志](/zh/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging)
1. [开启 Envoy 访问日志](/zh/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging)
1. 检查 egress gateway 的 Envoy 的统计数据，找到对应请求 MongoDB service 的 counter。如果 Istio 步骤在 `istio-system` namespace 中，打印 counter 的命令为：
@ -508,7 +508,7 @@ Sidecar 代理通过匹配 MongoDB 主机的 SNI，将 TLS 连接从 MongoDB 客
Egress gateway 再将流量转发到 MongoDB 主机。请注意，sidecar 代理会将目的端口重写为 443。
Egress gateway 在 443 端口上接受 MongoDB 流量，按照 SNI 匹配 MongoDB 主机，并再次将端口重写为 MongoDB 服务器的端口。
1. [部署 Istio egress gateway](/zh/docs/tasks/traffic-management/egress/egress-gateway/#deploy-Istio-egress-gateway).
1. [部署 Istio egress gateway](/zh/docs/tasks/traffic-management/egress/egress-gateway/#deploy-Istio-egress-gateway).
1. 为 MongoDB service 创建一个 `ServiceEntry`:
@ -956,7 +956,7 @@ $ kubectl delete destinationrule egressgateway-for-mongo
EOF
{{< /text >}}
1. 将目的为 _*.com_ 的流量路由到 egress gateway，并从 egress gateway 路由到 SNI 代理.
1. 将目的为 _*.com_ 的流量路由到 egress gateway，并从 egress gateway 路由到 SNI 代理.
{{< text bash >}}
$ kubectl apply -f - <<EOF
@ -1000,7 +1000,7 @@ $ kubectl delete destinationrule egressgateway-for-mongo
1. 再次刷新应用程序的网页，验证评级数据仍然显示正确。
1. [开启 Envoy 访问日志](/zh/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging)
1. [开启 Envoy 访问日志](/zh/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging)
1. 检查 egress gateway 的 Envoy 的日志。如果 Istio 部署在 `istio-system` namespace 中，打印日志的的命令为：

52
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 >}}
@ -134,7 +134,7 @@ target_release: 1.1
200
{{< /text >}}
1. 查询 Mixer 日志，查看请求信息出现在日志中:
1. 查询 Mixer 日志，查看请求信息出现在日志中:
{{< text bash >}}
$ kubectl -n istio-system logs -l istio-mixer-type=telemetry -c mixer | grep egress-access | grep cnn | tail -4
@ -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` 命名空间中
@ -155,7 +155,7 @@ target_release: 1.1
启用对 _edition.cnn.com_ 的访问进行日志记录之后，自动执行访问策略，即只允许访问 _/health_ 和 _/sport_ URL 路径。这样一个简单的策略控制可以通过 Istio 路由实现。
1. 为 _edition.cnn.com_ 重定义 `VirtualService` ：
1. 为 _edition.cnn.com_ 重定义 `VirtualService` ：
{{< text bash >}}
$ cat <<EOF | kubectl apply -f -
@ -198,7 +198,7 @@ target_release: 1.1
注意，您通过 `url` 添加添加了一个 `match`，该条件检查 URL 路径是 _/health_ 还是 _/sport_ 。还要注意，此条件已添加到 `VirtualService` 的 `istio-egressgateway` 部分，因为就安全性而言，egress 网关是一个经过加固的组件（请参阅 [egress 网关安全性注意事项](/zh/docs/tasks/traffic-management/egress/egress-gateway/#additional-security-considerations)）。您一定不希望您的任何策略被篡改。
1. 发送之前的三个 HTTP 请求到 _cnn.com_ ：
1. 发送之前的三个 HTTP 请求到 _cnn.com_ ：
{{< 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'
@ -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_ 。
@ -215,7 +215,7 @@ target_release: 1.1
您可能需要等待几秒钟，等待 `VirtualService` 的更新传播到 egress 网关。
{{< /tip >}}
1. 查询 Mixer 日志，可以看到关于请求的信息再次出现在日志中：
1. 查询 Mixer 日志，可以看到关于请求的信息再次出现在日志中：
{{< text bash >}}
$ kubectl -n istio-system logs -l istio-mixer-type=telemetry -c mixer | grep egress-access | grep cnn | tail -4
@ -233,7 +233,7 @@ target_release: 1.1
现在您移除在本节中使用的路由取消访问控制，在下一节将向您演示通过 Mixer 策略检查实现访问控制。
1. 用之前[配置 Egress 网关](/zh/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/#perform-TLS-origination-with-an-egress-gateway)示例中的版本替换 _edition.cnn.com_ 的 `VirtualService`：
1. 用之前[配置 Egress 网关](/zh/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/#perform-TLS-origination-with-an-egress-gateway)示例中的版本替换 _edition.cnn.com_ 的 `VirtualService`：
{{< text bash >}}
$ cat <<EOF | kubectl apply -f -
@ -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'
@ -294,7 +294,7 @@ target_release: 1.1
caption="用于 egress 监视和访问策略的实例、规则和处理程序"
>}}
1. 定义 `path-checker` 和 `request-path`：
1. 定义 `path-checker` 和 `request-path`：
{{< text bash >}}
$ cat <<EOF | kubectl create -f -
@ -317,7 +317,7 @@ target_release: 1.1
EOF
{{< /text >}}
1. 修改 `handle-cnn-access` 策略规则并发送 `request-path` 实例到 `path-checker`：
1. 修改 `handle-cnn-access` 策略规则并发送 `request-path` 实例到 `path-checker`：
{{< text bash >}}
$ cat <<EOF | kubectl apply -f -
@ -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'
@ -352,7 +352,7 @@ target_release: 1.1
在我们用例中的组织设法配置日志和访问控制之后，它决定扩展它的访问策略，允许具有特殊[服务帐户](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)的应用程序访问 _cnn.com_ 的任何主题，而不受监控。您将看到如何在 Istio 中配置此需求。
1. 使用 `politics` 服务账户开启 [sleep]({{< github_tree >}}/samples/sleep) 示例程序。
1. 使用 `politics` 服务账户开启 [sleep]({{< github_tree >}}/samples/sleep) 示例程序。
{{< text bash >}}
$ sed 's/: sleep/: politics/g' samples/sleep/sleep.yaml | kubectl create -f -
@ -361,13 +361,13 @@ target_release: 1.1
deployment "politics" created
{{< /text >}}
1. 定义 `SOURCE_POD_POLITICS` shell 变量来保存带有 `politics` 服务帐户的源 pod 的名称，以便向外部服务发送请求。
1. 定义 `SOURCE_POD_POLITICS` shell 变量来保存带有 `politics` 服务帐户的源 pod 的名称，以便向外部服务发送请求。
{{< text bash >}}
$ export SOURCE_POD_POLITICS=$(kubectl get pod -l app=politics -o jsonpath={.items..metadata.name})
{{< /text >}}
1. 执行常规测试，这次从 `SOURCE_POD_POLITICS` 发送三个 HTTP 请求。对 [edition.cnn.com/politics](https://edition.cnn.com/politics) 的请求返回 _403_ ，因为您没有为 _politics_ 命名空间配置异常。
1. 执行常规测试，这次从 `SOURCE_POD_POLITICS` 发送三个 HTTP 请求。对 [edition.cnn.com/politics](https://edition.cnn.com/politics) 的请求返回 _403_ ，因为您没有为 _politics_ 命名空间配置异常。
{{< text bash >}}
$ kubectl exec -it $SOURCE_POD_POLITICS -c politics -- 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'
@ -376,7 +376,7 @@ target_release: 1.1
200
{{< /text >}}
1. 查询 Mixer 日志，可以看到来自 _politics_ 命名空间的请求信息出现在日志中：
1. 查询 Mixer 日志，可以看到来自 _politics_ 命名空间的请求信息出现在日志中：
{{< text bash >}}
$ kubectl -n istio-system logs -l istio-mixer-type=telemetry -c mixer | grep egress-access | grep cnn | tail -4
@ -388,7 +388,7 @@ target_release: 1.1
注意 `sourcePrincipal` 是 `cluster.local/ns/default/sa/politics`，表示 `default` 命名空间中的 `politics` 服务帐户。
1. 重新定义 `handle-cn-access` 和 `handl-politics` 策略规则，使 _politics_ 命名空间中的应用程序免受监控和策略强制。
1. 重新定义 `handle-cn-access` 和 `handl-politics` 策略规则，使 _politics_ 命名空间中的应用程序免受监控和策略强制。
{{< text bash >}}
$ cat <<EOF | kubectl apply -f -
@ -423,7 +423,7 @@ target_release: 1.1
EOF
{{< /text >}}
1. 从 `SOURCE_POD` 中执行常规测试：
1. 从 `SOURCE_POD` 中执行常规测试：
{{< 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'
@ -434,7 +434,7 @@ target_release: 1.1
由于 `SOURCE_POD` 没有 `politics` 服务帐户，所以像以前一样访问 [edition.cnn.com/politics](https://edition.cnn.com/politics) 会被禁止。
1. 从 `SOURCE_POD_POLITICS` 中执行之前的测试：
1. 从 `SOURCE_POD_POLITICS` 中执行之前的测试：
{{< text bash >}}
$ kubectl exec -it $SOURCE_POD_POLITICS -c politics -- 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'
@ -445,7 +445,7 @@ target_release: 1.1
访问 _edition.cnn.com_ 的所有话题都是被允许的。
1. 检查 Mixer 日志，查看是否有更多使用 `sourcePrincipal` 请求，能够匹配 `cluster.local/ns/default/sa/politics` 的内容出现在日志中。
1. 检查 Mixer 日志，查看是否有更多使用 `sourcePrincipal` 请求，能够匹配 `cluster.local/ns/default/sa/politics` 的内容出现在日志中。
{{< text bash >}}
$ kubectl -n istio-system logs -l istio-mixer-type=telemetry -c mixer | grep egress-access | grep cnn | tail -4
@ -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"
@ -481,9 +481,9 @@ caption="HTTPS egress 流量通过 egress 网关"
## 清理{#cleanup}
1. 执行[配置 Egress 网关](/zh/docs/tasks/traffic-management/egress/egress-gateway/)示例的[清理](/zh/docs/tasks/traffic-management/egress/egress-gateway/#cleanup)部分中的说明。
1. 执行[配置 Egress 网关](/zh/docs/tasks/traffic-management/egress/egress-gateway/)示例的[清理](/zh/docs/tasks/traffic-management/egress/egress-gateway/#cleanup)部分中的说明。
1. 删除日志和策略检查配置：
1. 删除日志和策略检查配置：
{{< text bash >}}
$ kubectl delete logentry egress-access -n istio-system
@ -495,7 +495,7 @@ caption="HTTPS egress 流量通过 egress 网关"
$ kubectl delete -n istio-system listentry request-path
{{< /text >}}
1. 删除 _politics_ 源 pod：
1. 删除 _politics_ 源 pod：
{{< text bash >}}
$ sed 's/: sleep/: politics/g' samples/sleep/sleep.yaml | kubectl delete -f -

12
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_ 的版本。
@ -189,7 +189,7 @@ target_release: 1.0
在[确定入口 IP 和端口](/zh/docs/examples/bookinfo/#determine-the-ingress-IP-and-port)之后，访问应用程序的网页。
你会发现问题，在每次审核下方都会显示消息 _"Ratings service is currently unavailable”_ 而不是评级星标。
你会发现问题，在每次审核下方都会显示消息 _"Ratings service is currently unavailable”_ 而不是评级星标。
{{< image width="80%" link="errorFetchingBookRating.png" caption="Ratings 服务的错误信息" >}}
@ -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 网格外部服务入口。

10
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)。
@ -55,7 +55,7 @@ Istio 支持将日志导出到 Stackdriver，而 Stackdriver 又可以配置为
必须创建 Stackdriver 处理程序，将数据导出到 Stackdriver。Stackdriver 处理程序的配置在 [`此处`](/zh/docs/reference/config/policy-and-telemetry/adapters/stackdriver/) 描述。
1. 保存如下的 yaml 文件为 `stackdriver.yaml` 。并替换 `<project_id>,
1. 保存如下的 yaml 文件为 `stackdriver.yaml` 。并替换 `<project_id>,
<sink_id>, <sink_destination>, <log_filter>` 为相应的值。
{{< text yaml >}}
@ -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 身份进行这些操作。

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

@ -10,7 +10,7 @@ target_release: 1.4
我们很高兴地宣布 [Istio client go](https://github.com/istio/client-go) 的第一个版本发布了，该存储库使开发人员能够在 `Kubernetes` 环境中访问 `Istio API` 。在此存储库中的 `Kubernetes` 程序和客户端使开发人员可以轻松地为所有 `Istio` 客户端自定义的资源 `(CRDs)` 创建，读取，更新和删除 `(CRUD)`。
这是许多 Istio 用户强烈要求的功能，从 [Aspen Mesh](https://github.com/aspenmesh/istio-client-go)
和 [Knative project](https://github.com/knative/pkg) 项目对客户端产生的功能请求中可以明显地看出这一点。如果您正在使用上述客户端之一，则可以像如下这样轻松地切换到 [Istio client go](https://github.com/istio/client-go)：
和 [Knative project](https://github.com/knative/pkg) 项目对客户端产生的功能请求中可以明显地看出这一点。如果您正在使用上述客户端之一，则可以像如下这样轻松地切换到 [Istio client go](https://github.com/istio/client-go)：
{{< text go>}}
import (
@ -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 字节。

18
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 >}}
我们从涉及出口流量的攻击开始。
@ -49,19 +49,19 @@ _1.3.4 不允许持卡人数据环境没有授权的出站流量进入互联网
Istio 1.1 满足所有的收集要求：
1. 使用 [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication) 支持 [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security) 或者用 Istio 支持 [TLS 源](/zh/docs/reference/glossary/#tls-origination)
1. 使用 [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication) 支持 [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security) 或者用 Istio 支持 [TLS 源](/zh/docs/reference/glossary/#tls-origination)
1. **监视器** SNI 和每个出口访问的源 workload。
1. **监视器** SNI 和每个出口访问的源 workload。
1. 定义和执行 **每个集群的策略**，比如：
1. 定义和执行 **每个集群的策略**，比如：
* 集群中所有应用程序可能访问 `service1.foo.com` （指定的主机）
* 集群中所有的应用程序可能访问 `*.bar.com` (泛域名) 下的任何主机
* 集群中所有的应用程序可能访问 `*.bar.com` (泛域名) 下的任何主机
必须阻止所有未明确的访问。
1. 定义和执行**每个源的策略**， _Kubernetes 可感知_：
1. 定义和执行**每个源的策略**，_Kubernetes 可感知_：
* 应用 `A` 可能访问 `*.foo.com`。
@ -69,16 +69,16 @@ Istio 1.1 满足所有的收集要求：
必须阻止其他访问，尤其是应用 `A` 到 `service1.bar.com` 的访问。
1. **防篡改*。万一有一个应用的 pod 被破坏了，要防止受损的 pod 逃离监控，防止发送假信息给监控系统，防止破坏出口策略。
1. **防篡改*。万一有一个应用的 pod 被破坏了，要防止受损的 pod 逃离监控，防止发送假信息给监控系统，防止破坏出口策略。
1. 有这点就更好：流量管控对应用程序要**透明**。
1. 有这点就更好：流量管控对应用程序要**透明**。
对每个要求我来详细介绍以下。第一个要求指出，必须支持对外服务访问只能使用 TLS。在看到所有出集群的流量都必须加密后，这个要求就出现了。这意味着要么是应用程序执行 TLS，要么是 Istio 必须为应用程序执行 TLS。
注意如果应用程序执行了 TLS，Istio 代理是无法看到原始的流量的，只能看到加密后的，所以代理只能看到 TLS 协议。对代理来说它不关心原始协议是 HTTP 还是 MongoDB ，所有的 Istio 代理只能看到 TLS 流量。
第二个要求指出：必须监控 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 地址，

2
content/zh/blog/2019/multicluster-version-routing/index.md
View File

@ -360,7 +360,7 @@ EOF
## 创建 `VirtualService` 来路由 `reviews` 服务的流量{#create-a-destination-rule-on-both-clusters-for-the-local-reviews-service}
目前所有调用 `reviews` 服务的流量都会进入本地的 `reviews` Pod，也就是 `v1`，如果查看一下远吗，会发现 `productpage` 的实现只是简单的对 `http://reviews:9080` （也就是 `reviews.default.svc.cluster.local`）发起了请求，也就是本地版本。对应的远程服务名称为 `reviews.default.global`，所以需要用路由规则来把请求转发到远端集群。
目前所有调用 `reviews` 服务的流量都会进入本地的 `reviews` Pod，也就是 `v1`，如果查看一下远吗，会发现 `productpage` 的实现只是简单的对 `http://reviews:9080` （也就是 `reviews.default.svc.cluster.local`）发起了请求，也就是本地版本。对应的远程服务名称为 `reviews.default.global`，所以需要用路由规则来把请求转发到远端集群。
{{< tip >}}
注意如果所有版本的 `reviews` 服务都在远端，也就是说本地没有 `reviews` 服务，那么 DNS 就会把 `reviews` 直接解析到 `reviews.default.global`，在本文的环境里，无需定义任何路由规则就可以发起对远端集群的请求。

18
content/zh/blog/2019/proxy/index.md
View File

@ -15,7 +15,7 @@ keywords: [traffic-management,ingress,https,http]
## 配置一个入口网关{#configure-an-ingress-gateway}
1. 定义一个入口网关，在 `servers:` 配置中配置 `80` 和 `443` 端口。
1. 定义一个入口网关，在 `servers:` 配置中配置 `80` 和 `443` 端口。
在对端口 `443` 的配置终确定 `tls:` 的 `mode:` 配置为 `PASSTHROUGH`，这配置网关直接透传流量而且不终止 TLS。
{{< text bash >}}
@ -45,7 +45,7 @@ keywords: [traffic-management,ingress,https,http]
EOF
{{< /text >}}
1. 为 `httpbin.org` 和 `edition.cnn.com` 创建服务入口，让他们可以通过入口网关访问：
1. 为 `httpbin.org` 和 `edition.cnn.com` 创建服务入口，让他们可以通过入口网关访问：
{{< text bash >}}
$ kubectl apply -f - <<EOF
@ -79,7 +79,7 @@ keywords: [traffic-management,ingress,https,http]
EOF
{{< /text >}}
1. 创建一个服务入口，并且为 `localhost` 服务配置目的规则。在下一步中，需要这个服务入口作为网格内部应用流量到外部服务的目的地，从而隔断来自网格内部的流量。在此例中把 Istio 用作外部应用和外部服务间的代理。
1. 创建一个服务入口，并且为 `localhost` 服务配置目的规则。在下一步中，需要这个服务入口作为网格内部应用流量到外部服务的目的地，从而隔断来自网格内部的流量。在此例中把 Istio 用作外部应用和外部服务间的代理。
{{< text bash >}}
$ kubectl apply -f - <<EOF
@ -115,7 +115,7 @@ keywords: [traffic-management,ingress,https,http]
EOF
{{< /text >}}
1. 为每个外部服务创建一个虚拟服务并配置路由规则。两个虚拟服务的 `gateways:` 和 `match:` 配置中有针对 HTTP 和 HTTPS 流量相关的 `proxy` 网关配置。
1. 为每个外部服务创建一个虚拟服务并配置路由规则。两个虚拟服务的 `gateways:` 和 `match:` 配置中有针对 HTTP 和 HTTPS 流量相关的 `proxy` 网关配置。
注意 `route:` 配置中的 `mesh` 网关配置，这个网关代表网格内的应用程序。`mesh` 网关中的 `route:` 配置表示如何将流量转向 `localhost.local` 服务，从而有效地阻隔了流量。
@ -189,11 +189,11 @@ keywords: [traffic-management,ingress,https,http]
EOF
{{< /text >}}
1. [启用 Envoy 的访问日志](/zh/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging)。
1. [启用 Envoy 的访问日志](/zh/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging)。
1. 根据[确定入口网关的 IP 和端口](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports)中的命令，设置 `SECURE_INGRESS_PORT` 和 `INGRESS_HOST` 两个环境变量。
1. 根据[确定入口网关的 IP 和端口](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports)中的命令，设置 `SECURE_INGRESS_PORT` 和 `INGRESS_HOST` 两个环境变量。
1. 在上一步中分别把 IP 和端口存储到了环境变量 `$INGRESS_HOST` 和 `$INGRESS_PORT` 中，现在可以用这个 IP 和端口访问 `httbin.org` 服务。访问 `httpbin.org` 服务的 `/status/418` 路径，会返回 [418 我是一个茶壶](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418)的 HTTP 状态码。
1. 在上一步中分别把 IP 和端口存储到了环境变量 `$INGRESS_HOST` 和 `$INGRESS_PORT` 中，现在可以用这个 IP 和端口访问 `httbin.org` 服务。访问 `httpbin.org` 服务的 `/status/418` 路径，会返回 [418 我是一个茶壶](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/418)的 HTTP 状态码。
{{< text bash >}}
$ curl $INGRESS_HOST:$INGRESS_PORT/status/418 -Hhost:httpbin.org
@ -209,13 +209,13 @@ keywords: [traffic-management,ingress,https,http]
`"""`
{{< /text >}}
1. 如果 Istio 入口网关部署在 `istio-system` 名字空间下，使用下面的命令打印网关日志。
1. 如果 Istio 入口网关部署在 `istio-system` 名字空间下，使用下面的命令打印网关日志。
{{< text bash >}}
$ kubectl logs -l istio=ingressgateway -c istio-proxy -n istio-system | grep 'httpbin.org'
{{< /text >}}
1. 检索日志找到类似如下内容：
1. 检索日志找到类似如下内容：
{{< text plain >}}
[2019-01-31T14:40:18.645Z] "GET /status/418 HTTP/1.1" 418 - 0 135 187 186 "10.127.220.75" "curl/7.54.0" "28255618-6ca5-9d91-9634-c562694a3625" "httpbin.org" "34.232.181.106:80" outbound|80||httpbin.org - 172.30.230.33:80 10.127.220.75:52077 -

2
content/zh/blog/2019/webhook/index.md
View File

@ -1,6 +1,6 @@
---
title: 安全管理 Webhook
description: 一种更安全管理 Istio webhook 的方法。
description: 一种更安全管理 Istio webhook 的方法。
publishdate: 2019-11-14
attribution: Lei Tang (Google)
keywords: [security, kubernetes, webhook]

2
content/zh/blog/2020/tradewinds-2020/index.md
View File

@ -31,7 +31,7 @@ Istio 的[认证](/zh/docs/concepts/security/#authentication-policies)和[授权
更换扩展模型后，我们还可以删除数十个 CRD。与 Istio 集成的每个软件都不再需要唯一 CRD。
通过 `preview` 配置文件安装 Istio 1.5 不会再安装 Mixer。安全起见，如果您是从以前的版本升级，或通过 `default` 配置文件安装，我们仍会保留 Mixer。当使用 Prometheus 或 Stackdriver 进行度量时，建议您尝试新模式并查看性能提高了多少。
通过 `preview` 配置文件安装 Istio 1.5 不会再安装 Mixer。安全起见，如果您是从以前的版本升级，或通过 `default` 配置文件安装，我们仍会保留 Mixer。当使用 Prometheus 或 Stackdriver 进行度量时，建议您尝试新模式并查看性能提高了多少。
如果有需要，您可以保持安装并启用 Mixer。最终，Mixer 将成为 Istio 单独的发行组件，成为 [istio-ecosystem](https://github.com/istio-ecosystem/) 的一部分。

16
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,11 +83,11 @@ 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/)
- [Solo.io Youtube 频道](https://www.youtube.com/channel/UCuketWAG3WqYjjxtQ9Q8ApQ)上的视频
- [Solo.io Youtube 频道](https://www.youtube.com/channel/UCuketWAG3WqYjjxtQ9Q8ApQ)上的视频

20
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 服务帐户。
自定义服务帐户引用现有服务帐户，就像客户的身份目录管理的身份一样。
@ -132,7 +132,7 @@ Istio 提供了在 Kubernetes 中使用节点代理进行证书和密钥分配
1. 上述 CSR 过程会定期重复进行证书和密钥轮换。
{{< idea >}}
使用节点代理调试端点可以查看节点代理当前正在为其客户端代理提供服务的 secret。访问代理程序 `8080` 端口上的 `/debug/sds/workload` 以获取当前工作负载 secret，或访问 `/debug/sds/gateway` 以获取当前网关 secret。
使用节点代理调试端点可以查看节点代理当前正在为其客户端代理提供服务的 secret。访问代理程序 `8080` 端口上的 `/debug/sds/workload` 以获取当前工作负载 secret，或访问 `/debug/sds/gateway` 以获取当前网关 secret。
{{< /idea >}}
## 认证{#authentication}

4
content/zh/docs/concepts/traffic-management/index.md
View File

@ -208,7 +208,7 @@ spec:
- 重写 URL。
- 为调用这一目标地址的请求设置[重试策略](#retries)。
想了解如何利用这些操作，查看 [`HTTPRoute` 参考](/zh/docs/reference/config/networking/virtual-service/#HTTPRoute)。
想了解如何利用这些操作，查看 [`HTTPRoute` 参考](/zh/docs/reference/config/networking/virtual-service/#HTTPRoute)。
## 目标规则 {#destination-rules}
@ -319,7 +319,7 @@ spec:
- 为外部目标 redirect 和转发请求，例如来自 web 端的 API 调用，或者流向遗留老系统的服务。
- 为外部目标定义[重试](#retries)、[超时](#timeouts)和[故障注入](#fault-injection)策略。
- 添加一个运行在虚拟机的服务来[扩展您的网格](/zh/docs/examples/virtual-machines/single-network/#running-services-on-the-added-VM)。
- 从逻辑上添加来自不同集群的服务到网格，在 Kubernetes 上实现一个[多集群 Istio 网格](/zh/docs/setup/install/multicluster/gateways/#configure-the-example-services)。
- 从逻辑上添加来自不同集群的服务到网格，在 Kubernetes 上实现一个[多集群 Istio 网格](/zh/docs/setup/install/multicluster/gateways/#configure-the-example-services)。
您不需要为网格服务要使用的每个外部服务都添加服务入口。默认情况下，Istio 配置 Envoy 代理将请求传递给未知服务。但是，您不能使用 Istio 的特性来控制没有在网格中注册的目标流量。

22
content/zh/docs/examples/bookinfo/index.md
View File

@ -52,16 +52,16 @@ Bookinfo 应用中的几个微服务是由不同的语言编写的。
如果运行的是 GKE，请确您的集群具有至少四个标准 GKE 节点。如果使用的是 Minikube，应该有 4G 以上的内存。
{{< /tip >}}
1. 进入 Istio 安装目录。
1. 进入 Istio 安装目录。
1. Istio 默认[自动注入 Sidecar](/zh/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection).
1. Istio 默认[自动注入 Sidecar](/zh/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection).
请为 `default` 命名空间打上标签 `istio-injection=enabled`：
{{< text bash >}}
$ kubectl label namespace default istio-injection=enabled
{{< /text >}}
1. 使用 `kubectl` 部署应用：
1. 使用 `kubectl` 部署应用：
{{< text bash >}}
$ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo.yaml@
@ -82,7 +82,7 @@ Bookinfo 应用中的几个微服务是由不同的语言编写的。
在实际部署中，微服务版本的启动过程需要持续一段时间，并不是同时完成的。
{{< /tip >}}
1. 确认所有的服务和 Pod 都已经正确的定义和启动：
1. 确认所有的服务和 Pod 都已经正确的定义和启动：
{{< text bash >}}
$ kubectl get services
@ -107,7 +107,7 @@ Bookinfo 应用中的几个微服务是由不同的语言编写的。
reviews-v3-1813607990-8ch52 2/2 Running 0 6m
{{< /text >}}
1. 要确认 Bookinfo 应用是否正在运行，请在某个 Pod 中用 `curl` 命令对应用发送请求，例如 `ratings`：
1. 要确认 Bookinfo 应用是否正在运行，请在某个 Pod 中用 `curl` 命令对应用发送请求，例如 `ratings`：
{{< text bash >}}
$ kubectl exec -it $(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}') -c ratings -- curl productpage:9080/productpage | grep -o "<title>.*</title>"
@ -118,13 +118,13 @@ Bookinfo 应用中的几个微服务是由不同的语言编写的。
现在 Bookinfo 服务启动并运行中，您需要使应用程序可以从外部访问 Kubernetes 集群，例如使用浏览器。可以用 [Istio Gateway](/zh/docs/concepts/traffic-management/#gateways) 来实现这个目标。
1. 为应用程序定义 Ingress 网关：
1. 为应用程序定义 Ingress 网关：
{{< text bash >}}
$ kubectl apply -f @samples/bookinfo/networking/bookinfo-gateway.yaml@
{{< /text >}}
1. 确认网关创建完成：
1. 确认网关创建完成：
{{< text bash >}}
$ kubectl get gateway
@ -132,9 +132,9 @@ Bookinfo 应用中的几个微服务是由不同的语言编写的。
bookinfo-gateway 32s
{{< /text >}}
1. 根据[文档](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports)设置访问网关的 `INGRESS_HOST` 和 `INGRESS_PORT` 变量。确认并设置。
1. 根据[文档](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports)设置访问网关的 `INGRESS_HOST` 和 `INGRESS_PORT` 变量。确认并设置。
1. 设置 `GATEWAY_URL`：
1. 设置 `GATEWAY_URL`：
{{< text bash >}}
$ export GATEWAY_URL=$INGRESS_HOST:$INGRESS_PORT
@ -190,13 +190,13 @@ $ kubectl get destinationrules -o yaml
结束对 Bookinfo 示例应用的体验之后，就可以使用下面的命令来完成应用的删除和清理了：
1. 删除路由规则，并销毁应用的 Pod
1. 删除路由规则，并销毁应用的 Pod
{{< text bash >}}
$ @samples/bookinfo/platform/kube/cleanup.sh@
{{< /text >}}
1. 确认应用已经关停
1. 确认应用已经关停
{{< text bash >}}
$ kubectl get virtualservices #-- there should be no virtual services

28
content/zh/docs/examples/microservices-istio/bookinfo-kubernetes/index.md
View File

@ -13,16 +13,16 @@ weight: 30
## 部署应用程序及测试 pod{#deploy-the-application-and-a-testing-pod}
1. 设置环境变量 `MYHOST` 的值为应用程序的 URL：
1. 设置环境变量 `MYHOST` 的值为应用程序的 URL：
{{< text bash >}}
$ export MYHOST=$(kubectl config view -o jsonpath={.contexts..namespace}).bookinfo.com
{{< /text >}}
1. 浏览 [`bookinfo.yaml`]({{< github_blob >}}/samples/bookinfo/platform/kube/bookinfo.yaml)。
1. 浏览 [`bookinfo.yaml`]({{< github_blob >}}/samples/bookinfo/platform/kube/bookinfo.yaml)。
这是该应用的 Kubernetes 部署规范。注意 services 和 deployments。
1. 部署应用到 Kubernetes 集群：
1. 部署应用到 Kubernetes 集群：
{{< text bash >}}
$ kubectl apply -l version!=v2,version!=v3 -f {{< github_file >}}/samples/bookinfo/platform/kube/bookinfo.yaml
@ -36,7 +36,7 @@ weight: 30
deployment "productpage-v1" created
{{< /text >}}
1. 检查 pods 的状态：
1. 检查 pods 的状态：
{{< text bash >}}
$ kubectl get pods
@ -47,7 +47,7 @@ weight: 30
reviews-v1-77c65dc5c6-kjvxs 1/1 Running 0 9s
{{< /text >}}
1. 四个服务达到 `Running` 状态后，就可以扩展 deployment。要使每个微服务的每个版本在三个 pods 中运行，请执行以下命令：
1. 四个服务达到 `Running` 状态后，就可以扩展 deployment。要使每个微服务的每个版本在三个 pods 中运行，请执行以下命令：
{{< text bash >}}
$ kubectl scale deployments --all --replicas 3
@ -59,7 +59,7 @@ weight: 30
deployment "reviews-v3" scaled
{{< /text >}}
1. 检查 pods 的状态。可以看到每个微服务都有三个 pods：
1. 检查 pods 的状态。可以看到每个微服务都有三个 pods：
{{< text bash >}}
$ kubectl get pods
@ -78,13 +78,13 @@ weight: 30
reviews-v1-77c65dc5c6-r55tl 1/1 Running 0 49s
{{< /text >}}
1. 部署测试 pod，[sleep]({{< github_tree >}}/samples/sleep)，用来向您的微服务发送请求：
1. 部署测试 pod，[sleep]({{< github_tree >}}/samples/sleep)，用来向您的微服务发送请求：
{{< text bash >}}
$ kubectl apply -f {{< github_file >}}/samples/sleep/sleep.yaml
{{< /text >}}
1. 从测试 pod 中用 curl 命令发送请求给 Bookinfo 应用，以确认该应用运行正常：
1. 从测试 pod 中用 curl 命令发送请求给 Bookinfo 应用，以确认该应用运行正常：
{{< text bash >}}
$ kubectl exec -it $(kubectl get pod -l app=sleep -o jsonpath='{.items[0].metadata.name}') -c sleep -- curl productpage:9080/productpage | grep -o "<title>.*</title>"
@ -108,7 +108,7 @@ service/productpage patched
### 配置 Kubernetes Ingress 资源并访问应用页面{#configure-the-Kubernetes-Ingress-resource-and-access-your-application-webpage}
1. 创建 Kubernetes Ingress 资源：
1. 创建 Kubernetes Ingress 资源：
{{< text bash >}}
$ kubectl apply -f - <<EOF
@ -142,7 +142,7 @@ service/productpage patched
### 更新 `/etc/hosts` 配置文件{#update-your-etc-hosts-configuration-file}
1. 将以下命令的输出内容追加到 `/etc/hosts` 文件。您应当具有[超级用户](https://en.wikipedia.org/wiki/Superuser)权限，并且可能需要使用 [`sudo`](https://en.wikipedia.org/wiki/Sudo) 来编辑 `/etc/hosts`。
1. 将以下命令的输出内容追加到 `/etc/hosts` 文件。您应当具有[超级用户](https://en.wikipedia.org/wiki/Superuser)权限，并且可能需要使用 [`sudo`](https://en.wikipedia.org/wiki/Sudo) 来编辑 `/etc/hosts`。
{{< text bash >}}
$ echo $(kubectl get ingress istio-system -n istio-system -o jsonpath='{..ip} {..host}') $(kubectl get ingress bookinfo -o jsonpath='{..host}')
@ -150,14 +150,14 @@ service/productpage patched
### 访问应用{#access-your-application}
1. 用以下命令访问应用主页：
1. 用以下命令访问应用主页：
{{< text bash >}}
$ curl -s $MYHOST/productpage | grep -o "<title>.*</title>"
<title>Simple Bookstore App</title>
{{< /text >}}
1. 将以下命令的输出内容粘贴到浏览器的地址栏：
1. 将以下命令的输出内容粘贴到浏览器的地址栏：
{{< text bash >}}
$ echo http://$MYHOST/productpage
@ -170,14 +170,14 @@ service/productpage patched
caption="Bookinfo Web Application"
>}}
1. 观察微服务是如何互相调用的。例如，`reviews` 使用 URL `http://ratings:9080/ratings` 调用 `ratings` 微服务。
1. 观察微服务是如何互相调用的。例如，`reviews` 使用 URL `http://ratings:9080/ratings` 调用 `ratings` 微服务。
查看 [`reviews` 的代码]({{< github_blob >}}/samples/bookinfo/src/reviews/reviews-application/src/main/java/application/rest/LibertyRestEndpoint.java)：
{{< text java >}}
private final static String ratings_service = "http://ratings:9080/ratings";
{{< /text >}}
1. 在一个单独的终端窗口中设置无限循环，将流量发送到您的应用程序，以模拟现实世界中恒定的用户流量：
1. 在一个单独的终端窗口中设置无限循环，将流量发送到您的应用程序，以模拟现实世界中恒定的用户流量：
{{< text bash >}}
$ while :; do curl -s $MYHOST/productpage | grep -o "<title>.*</title>"; sleep 1; done

14
content/zh/docs/examples/microservices-istio/package-service/index.md
View File

@ -10,13 +10,13 @@ weight: 20
本模块展示了如何创建一个 [Docker](https://www.docker.com) 镜像并在本地运行它。
1. 下载微服务 `ratings` 的 [`Dockerfile`](https://docs.docker.com/engine/reference/builder/)。
1. 下载微服务 `ratings` 的 [`Dockerfile`](https://docs.docker.com/engine/reference/builder/)。
{{< text bash >}}
$ curl -s {{< github_file >}}/samples/bookinfo/src/ratings/Dockerfile -o Dockerfile
{{< /text >}}
1. 观察这个`Dockerfile`。
1. 观察这个`Dockerfile`。
{{< text bash >}}
$ cat Dockerfile
@ -25,7 +25,7 @@ weight: 20
请注意，它将文件复制到容器的文件系统中，然后执行你在上一个模块中执行过的 `npm install` 命令。
`CMD` 命令指示 Docker 在 `9080` 端口上运行 `ratings` 服务。
1. 根据 `Dockerfile` 构建出一个镜像：
1. 根据 `Dockerfile` 构建出一个镜像：
{{< text bash >}}
$ docker build -t $USER/ratings .
@ -37,21 +37,21 @@ weight: 20
Successfully tagged user/ratings:latest
{{< /text >}}
1. 在 Docker 中运行 `ratings` 服务. 接下来的 [docker run](https://docs.docker.com/engine/reference/commandline/run/) 命令
1. 在 Docker 中运行 `ratings` 服务. 接下来的 [docker run](https://docs.docker.com/engine/reference/commandline/run/) 命令
指示 Docker 将容器的 `9080` 端口暴露到计算机的 `9081` 端口，从而允许你访问 `9081` 端口上的 `ratings` 微服务。
{{< text bash >}}
$ docker run -d -p 9081:9080 $USER/ratings
{{< /text >}}
1. 在浏览器访问 [http://localhost:9081/ratings/7](http://localhost:9081/ratings/7)，或使用以下的 `curl` 命令：
1. 在浏览器访问 [http://localhost:9081/ratings/7](http://localhost:9081/ratings/7)，或使用以下的 `curl` 命令：
{{< text bash >}}
$ curl localhost:9081/ratings/7
{"id":7,"ratings":{"Reviewer1":5,"Reviewer2":4}}
{{< /text >}}
1. 观察运行中的容器。执行 [docker ps](https://docs.docker.com/engine/reference/commandline/ps/) 命令，列出所有运行中的容器，同时
1. 观察运行中的容器。执行 [docker ps](https://docs.docker.com/engine/reference/commandline/ps/) 命令，列出所有运行中的容器，同时
注意镜像是 `<your user name>/ratings` 的容器。
{{< text bash >}}
@ -61,7 +61,7 @@ weight: 20
...
{{< /text >}}
1. 停止运行中的容器：
1. 停止运行中的容器：
{{< text bash >}}
$ docker stop <the container ID from the output of docker ps>

12
content/zh/docs/examples/microservices-istio/production-testing/index.md
View File

@ -12,7 +12,7 @@ weight: 40
## 测试单个微服务{#testing-individual-microservices}
1. 从测试 pod 中向服务之一发起 HTTP 请求：
1. 从测试 pod 中向服务之一发起 HTTP 请求：
{{< text bash >}}
$ kubectl exec -it $(kubectl get pod -l app=sleep -o jsonpath='{.items[0].metadata.name}') -- curl http://ratings:9080/ratings/7
@ -24,13 +24,13 @@ weight: 40
进行每次混乱的操作后，请访问应用程序的网页，查看是否有任何更改。
使用 `kubectl get pods` 检查 pods 状态。
1. 在 `details` 服务的一个 pod 中终止它。
1. 在 `details` 服务的一个 pod 中终止它。
{{< text bash >}}
$ kubectl exec -it $(kubectl get pods -l app=details -o jsonpath='{.items[0].metadata.name}') -- pkill ruby
{{< /text >}}
1. 检查 pods 状态：
1. 检查 pods 状态：
{{< text bash >}}
$ kubectl get pods
@ -52,13 +52,13 @@ weight: 40
请注意第一个 pod 重启了一次。
1. 在 `details` 的所有 pods 中终止它：
1. 在 `details` 的所有 pods 中终止它：
{{< text bash >}}
$ for pod in $(kubectl get pods -l app=details -o jsonpath='{.items[*].metadata.name}'); do echo terminating $pod; kubectl exec -it $pod -- pkill ruby; done
{{< /text >}}
1. 检查应用的页面：
1. 检查应用的页面：
{{< image width="80%"
link="bookinfo-details-unavailable.png"
@ -67,7 +67,7 @@ weight: 40
请注意详情部分显示的是错误信息而不是书籍详情。
1. 检查 pods 状态：
1. 检查 pods 状态：
{{< text bash >}}
$ kubectl get pods

26
content/zh/docs/examples/microservices-istio/setup-kubernetes-cluster/index.md
View File

@ -12,18 +12,18 @@ weight: 2
如果您在培训班且讲师已准备好了集群，直接前往[设置本地机器](/zh/docs/examples/microservices-istio/setup-local-computer)。
{{</ warning >}}
1. 确保您有 [Kubernetes 集群](https://kubernetes.io/docs/tutorials/kubernetes-basics/)的访问权限。
1. 确保您有 [Kubernetes 集群](https://kubernetes.io/docs/tutorials/kubernetes-basics/)的访问权限。
您可以使用 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/docs/quickstart) 或
[IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-getting-started)。
1. 生成一个环境变量用于存储运行教程指令要用到的命名空间的名字。
1. 生成一个环境变量用于存储运行教程指令要用到的命名空间的名字。
可以用任何名字，比如 `tutorial`。
{{< text bash >}}
$ export NAMESPACE=tutorial
{{< /text >}}
1. 创建命名空间：
1. 创建命名空间：
{{< text bash >}}
$ kubectl create namespace $NAMESPACE
@ -33,11 +33,11 @@ weight: 2
如果您是一位讲师，可以为每个参与者分配独立的命名空间。本教程支持多个参与者在不同的命名空间下同时运行。
{{< /tip >}}
1. [安装 Istio](/zh/docs/setup/)。
1. [安装 Istio](/zh/docs/setup/)。
1. [启用 Envoy 访问日志](/zh/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging)。
1. [启用 Envoy 访问日志](/zh/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging)。
1. 使用 `kubectl` 命令为这些通用 Istio 服务创建一个 Kubernetes Ingress 资源。在教程目前这个阶段要熟悉这些服务并不是必须的。
1. 使用 `kubectl` 命令为这些通用 Istio 服务创建一个 Kubernetes Ingress 资源。在教程目前这个阶段要熟悉这些服务并不是必须的。
- [Grafana](https://grafana.com/docs/guides/getting_started/)
- [Jaeger](https://www.jaegertracing.io/docs/1.13/getting-started/)
@ -86,7 +86,7 @@ weight: 2
EOF
{{< /text >}}
1. 创建一个角色为 `istio-system` 命名空间提供读权限。要在下面的步骤中限制参与者的权限，这个角色是必须要有的。
1. 创建一个角色为 `istio-system` 命名空间提供读权限。要在下面的步骤中限制参与者的权限，这个角色是必须要有的。
{{< text bash >}}
$ kubectl apply -f - <<EOF
@ -102,7 +102,7 @@ weight: 2
EOF
{{< /text >}}
1. 为每个参与者创建服务账号：
1. 为每个参与者创建服务账号：
{{< text bash >}}
$ kubectl apply -f - <<EOF
@ -114,7 +114,7 @@ weight: 2
EOF
{{< /text >}}
1. 限制每个参与者的权限。在教程中，参与者只需要在他们自己的命名空间中创建资源以及从 `istio-system` 命名空间中读取资源。
1. 限制每个参与者的权限。在教程中，参与者只需要在他们自己的命名空间中创建资源以及从 `istio-system` 命名空间中读取资源。
即使使用您自己的集群，这也是一个好的实践，它可以避免影响您集群中的其他命名空间。
创建一个角色为每个参与者的命名空间提供读写权限。为每个参与者赋予这个角色，以及读取 `istio-system` 资源的角色：
@ -162,7 +162,7 @@ weight: 2
EOF
{{< /text >}}
1. 每个参与者需要使用他们自己的 Kubernetes 配置文件。这个配置文件指明了集群的详细信息，服务账号，证书和参与者的命名空间。
1. 每个参与者需要使用他们自己的 Kubernetes 配置文件。这个配置文件指明了集群的详细信息，服务账号，证书和参与者的命名空间。
`kubectl` 命令使用这个配置文件在集群上操作。
为每个参与者创建 Kubernetes 配置文件：
@ -197,13 +197,13 @@ weight: 2
EOF
{{< /text >}}
1. 为 `${NAMESPACE}-user-config.yaml` 配置文件设置环境变量 `KUBECONFIG`：
1. 为 `${NAMESPACE}-user-config.yaml` 配置文件设置环境变量 `KUBECONFIG`：
{{< text bash >}}
$ export KUBECONFIG=./${NAMESPACE}-user-config.yaml
{{< /text >}}
1. 打印当前命名空间以确认配置文件已生效：
1. 打印当前命名空间以确认配置文件已生效：
{{< text bash >}}
$ kubectl config view -o jsonpath="{.contexts[?(@.name==\"$(kubectl config current-context)\")].context.namespace}"
@ -212,7 +212,7 @@ weight: 2
在输出中可以看到命名空间的名字。
1. 如果您为自己设置好了集群，复制前面步骤中提到的 `${NAMESPACE}-user-config.yaml` 文件到您的本地机器，`${NAMESPACE}` 就是前面步骤中的命名空间。比如，`tutorial-user-config.yaml`。
1. 如果您为自己设置好了集群，复制前面步骤中提到的 `${NAMESPACE}-user-config.yaml` 文件到您的本地机器，`${NAMESPACE}` 就是前面步骤中的命名空间。比如，`tutorial-user-config.yaml`。
教程中您将会再次用到这个文件。
如果您是讲师，则将生成的配置文件发送给每个学员。学员必须将该配置文件复制到自己本地的计算机。

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

4
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 外不能路由。
@ -219,7 +219,7 @@ aliases:
protocol: http
resolution: DNS
addresses:
# httpbin.bar.global 将会被解析至这个 IP 地址，它对于给定集群中的各个服务必须是唯一的。
# httpbin.bar.global 将会被解析至这个 IP 地址，它对于给定集群中的各个服务必须是唯一的。
# 这个地址不需要可路由。这个 IP 的流量将会被 sidecar 捕获并路由到合适的地方。
# 同时这个地址也会被添加到 VM 的 /etc/hosts 中
- 127.255.0.3

22
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。
具有以下说明：
@ -121,14 +121,14 @@ aliases:
下一步，将要加入网格的每台机器上运行以下命令：
1. 将之前创建的 `cluster.env` 和 `*.pem` 文件复制到 VM 中。例如：
1. 将之前创建的 `cluster.env` 和 `*.pem` 文件复制到 VM 中。例如：
{{< text bash >}}
$ export GCE_NAME="your-gce-instance"
$ gcloud compute scp --project=${MY_PROJECT} --zone=${MY_ZONE} {key.pem,cert-chain.pem,cluster.env,root-cert.pem} ${GCE_NAME}:~
{{< /text >}}
1. 使用 Envoy sidecar 安装 Debian 软件包。
1. 使用 Envoy sidecar 安装 Debian 软件包。
{{< text bash >}}
$ gcloud compute ssh --project=${MY_PROJECT} --zone=${MY_ZONE} "${GCE_NAME}"
@ -136,33 +136,33 @@ aliases:
$ sudo dpkg -i istio-sidecar.deb
{{< /text >}}
1. 将 Istio 的网关 IP 地址添加到 `/etc/hosts`。重新访问[集群准备](#preparing-the-Kubernetes-cluster-for-VMs)部分以了解如何获取 IP 地址。
1. 将 Istio 的网关 IP 地址添加到 `/etc/hosts`。重新访问[集群准备](#preparing-the-Kubernetes-cluster-for-VMs)部分以了解如何获取 IP 地址。
以下示例使用 Istio 网关地址修改 `/etc/hosts` 文件：
{{< text bash >}}
$ echo "35.232.112.158 istio-citadel istio-pilot istio-pilot.istio-system" | sudo tee -a /etc/hosts
{{< /text >}}
1. 在 `/etc/certs/` 下安装 `root-cert.pem`，`key.pem` 和 `cert-chain.pem`。
1. 在 `/etc/certs/` 下安装 `root-cert.pem`，`key.pem` 和 `cert-chain.pem`。
{{< text bash >}}
$ sudo mkdir -p /etc/certs
$ sudo cp {root-cert.pem,cert-chain.pem,key.pem} /etc/certs
{{< /text >}}
1. 在 `/var/lib/istio/envoy/` 下安装 `cluster.env`。
1. 在 `/var/lib/istio/envoy/` 下安装 `cluster.env`。
{{< text bash >}}
$ sudo cp cluster.env /var/lib/istio/envoy
{{< /text >}}
1. 将 `/etc/certs/` 和 `/var/lib/istio/envoy/` 中文件的所有权转交给 Istio proxy。
1. 将 `/etc/certs/` 和 `/var/lib/istio/envoy/` 中文件的所有权转交给 Istio proxy。
{{< text bash >}}
$ sudo chown -R istio-proxy /etc/certs /var/lib/istio/envoy
{{< /text >}}
1. 验证节点上的 agent 是否正常工作：
1. 验证节点上的 agent 是否正常工作：
{{< text bash >}}
$ sudo node_agent
@ -170,7 +170,7 @@ aliases:
CSR is approved successfully. Will renew cert in 1079h59m59.84568493s
{{< /text >}}
1. 使用 `systemctl` 启动 Istio：
1. 使用 `systemctl` 启动 Istio：
{{< text bash >}}
$ sudo systemctl start istio-auth-node-agent
@ -184,14 +184,14 @@ aliases:
以下示例展示了使用 `/etc/hosts/` 如何从 VM 中访问 Kubernetes 集群上运行的服务，
这里使用 [Bookinfo 示例](/zh/docs/examples/bookinfo/)中的服务。
1. 首先，在集群管理机器上获取服务的虚拟 IP 地址（`clusterIP`）：
1. 首先，在集群管理机器上获取服务的虚拟 IP 地址（`clusterIP`）：
{{< text bash >}}
$ kubectl get svc productpage -o jsonpath='{.spec.clusterIP}'
10.55.246.247
{{< /text >}}
1. 然后在新增的 VM 上，将服务名称和地址添加到其 `etc/hosts` 文件下。
1. 然后在新增的 VM 上，将服务名称和地址添加到其 `etc/hosts` 文件下。
然后您可以从 VM 连接到集群服务，如以下示例：
{{< text bash >}}

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 规则配置：

4
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 正在运行：
@ -56,7 +56,7 @@ Mixer 会生成指标来监控它自身行为。首先，检查这些指标：
如果你没有发现带有 `grpc_server_method="istio.mixer.v1.Mixer/Report"` 的 `grpc_io_server_completed_rpcs` 数据，说明 Envoy 没有调用 Mixer 上报遥测数据。
1. 在这种情况下，请确保已经将服务正确地集成到服务网格中。您可以使用[自动或手动注入 sidecar](/zh/docs/setup/additional-setup/sidecar-injection/) 来完成这个目标。
1. 在这种情况下，请确保已经将服务正确地集成到服务网格中。您可以使用[自动或手动注入 sidecar](/zh/docs/setup/additional-setup/sidecar-injection/) 来完成这个目标。
### 验证 Mixer 规则是否存在{#verify-the-mixer-rules-exist}

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

@ -124,11 +124,11 @@ 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 配置。
1. 验证 `istio-pilot` pod 是否在运行：
1. 验证 `istio-pilot` pod 是否在运行：
{{< text bash >}}
$ kubectl -n istio-system get pod -lapp=pilot
@ -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。

2
content/zh/docs/ops/configuration/telemetry/envoy-stats/index.md
View File

@ -33,7 +33,7 @@ Istio 默认配置下 Envoy 只会记录最小化的统计信息。缺省的关
要查看关于统计数据收集的 Envoy 配置，可以使用
[`istioctl proxy-config bootstrap`](/zh/docs/reference/commands/istioctl/#istioctl-proxy-config-bootstrap) 命令，还可以参考
[深入研究 Envoy 配置](/zh/docs/ops/diagnostic-tools/proxy-cmd/#deep-dive-into-envoy-configuration)更加深入的了解相关的配置。
需要注意的是, 只有那些 `stats_matcher` JSON 字段能匹配上 `inclusion_list` 的元件，Envoy 才会去收集他们的统计数据。
需要注意的是, 只有那些 `stats_matcher` JSON 字段能匹配上 `inclusion_list` 的元件，Envoy 才会去收集他们的统计数据。
要想让 Envoy 去收集出站和入站流量的统计信息，只需将 `sidecar.istio.io/statsInclusionPrefixes` 注解加到 Kubernetes `Deployment` 的 pod 模板里去。
在模板里加上 `cluster.outbound` 前缀就能统计出站流量活动和熔断事件的数据, 相似，如果要收集入站流量的数据，只需加上 `listener` 前缀。

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}

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

@ -1,6 +1,6 @@
---
title: Pod 和 Service
description: 在启用了 Istio 的集群中运行 Kubernetes 的 Pod 和 Service，您需要做些准备。
description: 在启用了 Istio 的集群中运行 Kubernetes 的 Pod 和 Service，您需要做些准备。
weight: 40
keywords:
- kubernetes
@ -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/ops/diagnostic-tools/istioctl-analyze/index.md
View File

@ -45,7 +45,7 @@ $ istioctl analyze --use-kube=false *.yaml
$ istioctl analyze *.yaml
{{< /text >}}
可以运行 `istioctl analyze --help` 来查看完整的选项集。
可以运行 `istioctl analyze --help` 来查看完整的选项集。
## 帮助我们改进此工具{#helping-us-improve-this-tool}

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

@ -116,7 +116,7 @@ istio-egressgateway.istio-system.svc.cluster.local
为了调试 Envoy 您需要理解 Envoy 集群、监听器、路由、endpoints 以及它们是如何交互的。我们将使用带有 `-o json` 参数的 `proxy-config` 命令，根据标志过滤出并跟随特定的 Envoy，它将请求从 `productpage` pod 发送到 `reviews` pod 9080 端口。
1. 如果您在一个 Pod 上查询监听器概要信息，您将注意到 Istio 生成了下面的监听器：
* `0.0.0.0:15001` 监听器接收所有进出 Pod 的流量，然后转发请求给一个虚拟监听器。
* `0.0.0.0:15001` 监听器接收所有进出 Pod 的流量，然后转发请求给一个虚拟监听器。
* 每个服务 IP 一个虚拟监听器，针对每一个非 HTTP 的外部 TCP/HTTPS 流量。
* Pod IP 上的虚拟监听器，针对内部流量暴露的端口。
* `0.0.0.0` 监听器，针对外部 HTTP 流量的每个 HTTP 端口。
@ -294,19 +294,19 @@ $ istioctl proxy-config bootstrap -n istio-system istio-ingressgateway-7d6874b48
验证与 Pilot 的连通性是一个有用的故障排除步骤。服务网格内的每个代理容器都应该能和 Pilot 通信。这可以通过几个简单的步骤来实现：
1. 获取 Istio Ingress pod 的名称：
1. 获取 Istio Ingress pod 的名称：
{{< text bash >}}
$ INGRESS_POD_NAME=$(kubectl get po -n istio-system | grep ingressgateway\- | awk '{print$1}'); echo ${INGRESS_POD_NAME};
{{< /text >}}
1. 通过 exec 进入 Istio Ingress pod：
1. 通过 exec 进入 Istio Ingress pod：
{{< text bash >}}
$ kubectl exec -it $INGRESS_POD_NAME -n istio-system /bin/bash
{{< /text >}}
1. 使用 `curl` 测试与 Pilot 的连通性。下面的示例使用了默认的 Pilot 配置参数和开启双向 TLS 来调用 v1 注册 API：
1. 使用 `curl` 测试与 Pilot 的连通性。下面的示例使用了默认的 Pilot 配置参数和开启双向 TLS 来调用 v1 注册 API：
{{< text bash >}}
$ curl -k --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem --key /etc/certs/key.pem https://istio-pilot:8080/debug/edsz

2
content/zh/docs/reference/config/analysis/_index.md
View File

@ -5,4 +5,4 @@ weight: 70
layout: analysis-landing
---
[`istioctl`](/zh/docs/reference/commands/istioctl/#istioctl-analyze) 提供了对 Istio 配置状态的丰富分析，以便标识无效或次优的配置。这是此分析可能产生的错误或警告消息的列表。
[`istioctl`](/zh/docs/reference/commands/istioctl/#istioctl-analyze) 提供了对 Istio 配置状态的丰富分析，以便标识无效或次优的配置。这是此分析可能产生的错误或警告消息的列表。

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

@ -101,7 +101,7 @@ Istio 中除了 Envoy 是首要的属性生产者外，Mixer 和服务也会产
时间戳属性以 RFC 3339 格式表示。
应用 timestamp 属性时，可以使用 [CEXL](/zh/docs/reference/config/policy-and-telemetry/expression-language/)
中定义的 `timestamp` 函数将 RFC 3339 格式的文本时间戳转换为 `TIMESTAMP` 类型，
中定义的 `timestamp` 函数将 RFC 3339 格式的文本时间戳转换为 `TIMESTAMP` 类型，
例如：`request.time | timestamp("2018-01-01T22:08:41+00:00")`, `response.time > timestamp("2020-02-29T00:00:00-08:00")`。
持续时间属性表示时间量，表示为一系列十进制数，其中可选的小数部分用句点表示，以及单位值。

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}

4
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/)来定义指标。
我们将首先描述监控指标，然后描述每个指标的标签。
@ -134,7 +134,7 @@ Istio 为 HTTP、HTTP/2 和 GRPC 流量创建了下列指标：
connection_security_policy: conditional((context.reporter.kind | "inbound") == "outbound", "unknown", conditional(connection.mtls | false, "mutual_tls", "none"))
{{< /text >}}
* **Response Flags**: 来自代理服务器，包含了响应或者连接的额外细节。如果是 Envoy 代理，可以参考 [Envoy 访问日志](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log#configuration)中的 `%RESPONSE_FLAGS%` 相关说明。
* **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 | "-"

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。模版可以使用这些数据有条件地定义被注入的卷和容器。
例如下面的模版。

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

@ -32,19 +32,19 @@ 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}
下载 Istio，下载内容将包含：安装文件、示例和 [{{< istioctl >}}](/zh/docs/reference/commands/istioctl/) 命令行工具。
1. 访问 [Istio release]({{< istio_release_url >}}) 页面下载与您操作系统对应的安装文件。在 macOS 或 Linux 系统中，也可以通过以下命令下载最新版本的 Istio：
1. 访问 [Istio release]({{< istio_release_url >}}) 页面下载与您操作系统对应的安装文件。在 macOS 或 Linux 系统中，也可以通过以下命令下载最新版本的 Istio：
{{< text bash >}}
$ curl -L https://istio.io/downloadIstio | sh -
{{< /text >}}
1. 切换到 Istio 包所在目录下。例如：Istio 包名为 `istio-{{< istio_full_version >}}`，则：
1. 切换到 Istio 包所在目录下。例如：Istio 包名为 `istio-{{< istio_full_version >}}`，则：
{{< text bash >}}
$ cd istio-{{< istio_full_version >}}
@ -56,7 +56,7 @@ Istio {{< istio_version >}} 已经在 Kubernetes 版本 {{< supported_kubernetes
- `samples/` 目录下，有示例应用程序
- `bin/` 目录下，包含 [`istioctl`](/zh/docs/reference/commands/istioctl) 的客户端文件。`istioctl` 工具用于手动注入 Envoy sidecar 代理。
1. 将 `istioctl` 客户端路径增加到 path 环境变量中，macOS 或 Linux 系统的增加方式如下：
1. 将 `istioctl` 客户端路径增加到 path 环境变量中，macOS 或 Linux 系统的增加方式如下：
{{< text bash >}}
$ export PATH=$PWD/bin:$PATH

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}

8
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
@ -245,7 +245,7 @@ $ istioctl manifest apply -f samples/operator/pilot-k8s.yaml
{{< tip >}}
为了向后兼容，还完全支持 [Helm 安装](/zh/docs/reference/config/installation-options/)。
若要在命令行中设置它们，请在选项名称前面加上 "`values.`"。
若要在命令行中设置它们，请在选项名称前面加上 "`values.`"。
如下所示，下面命令就重写了 Helm 的 `pilot.traceSampling` 配置选项：
{{< text bash >}}
@ -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}

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

@ -88,7 +88,7 @@ Istio 本身不会为两个服务之间的请求使用 DNS。集群本地的服
要为远端集群的服务提供类似的配置，远端集群内的服务需要以 `<name>.<namespace>.global` 的格式命名。
Istio 还附带了一个名为 CoreDNS 的服务，它可以为这些服务提供 DNS 解析。
想要使用 CoreDNS，Kubernetes DNS 的 `.global` 必须配置为 `stub a domain`。
想要使用 CoreDNS，Kubernetes DNS 的 `.global` 必须配置为 `stub a domain`。
{{< warning >}}
一些云提供商的 Kubernetes 服务可能有不同的、特殊的 `DNS domain stub` 程序和功能。
@ -350,7 +350,7 @@ service entry 使用的 host 应该采用如下格式：`<name>.<namespace>.glob
### 通过 egress gateway 发送远程流量{#send-remote-traffic-via-an-egress-gateway}
如果您想在 `cluster1` 中通过一个专用的 egress gateway 路由流量，而不是从 sidecars 直连。
使用下面的 service entry 替换前面一节对 `httpbin.bar` 使用的配置。
使用下面的 service entry 替换前面一节对 `httpbin.bar` 使用的配置。
{{< tip >}}
该配置中使用的 egress gateway 依然不能处理其它的、非 inter-cluster 的 egress 流量。

32
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,36 +103,36 @@ 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 通信。
1. 确定 `cluster1` 的 ingress IP 和端口。
1. 确定 `cluster1` 的 ingress IP 和端口。
1. 设置 `kubectl` 的当前上下文为 `CTX_CLUSTER1`
1. 设置 `kubectl` 的当前上下文为 `CTX_CLUSTER1`
{{< text bash >}}
$ export ORIGINAL_CONTEXT=$(kubectl config current-context)
$ kubectl config use-context $CTX_CLUSTER1
{{< /text >}}
1. 按照[确定 ingress IP 和端口](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports)中的说明，设置环境变量 `INGRESS_HOST` 及 `SECURE_INGRESS_PORT`。
1. 按照[确定 ingress IP 和端口](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports)中的说明，设置环境变量 `INGRESS_HOST` 及 `SECURE_INGRESS_PORT`。
1. 恢复之前的 `kubectl` 上下文：
1. 恢复之前的 `kubectl` 上下文：
{{< text bash >}}
$ kubectl config use-context $ORIGINAL_CONTEXT
$ unset ORIGINAL_CONTEXT
{{< /text >}}
1. 打印 `INGRESS_HOST` 及 `SECURE_INGRESS_PORT`：
1. 打印 `INGRESS_HOST` 及 `SECURE_INGRESS_PORT`：
{{< text bash >}}
$ echo The ingress gateway of cluster1: 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
@ -192,31 +192,31 @@ Istio 位置感知的服务路由特性，可以根据请求源所在的位置
`istio-ingressgateway` 无法就绪，直到在 `cluster1` 的 Istio 控制面板中配置好 watch `cluster2`。下一节执行该操作。
{{< /warning >}}
1. 确定 `cluster2` 的 ingress IP 和口。
1. 确定 `cluster2` 的 ingress IP 和口。
1. 设置 `kubectl` 的当前上下文为 `CTX_CLUSTER2`
1. 设置 `kubectl` 的当前上下文为 `CTX_CLUSTER2`
{{< text bash >}}
$ export ORIGINAL_CONTEXT=$(kubectl config current-context)
$ kubectl config use-context $CTX_CLUSTER2
{{< /text >}}
1. 按照[确定 ingress IP 和端口](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports)中的说明，设置环境变量 `INGRESS_HOST` 和 `SECURE_INGRESS_PORT`。
1. 按照[确定 ingress IP 和端口](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports)中的说明，设置环境变量 `INGRESS_HOST` 和 `SECURE_INGRESS_PORT`。
1. 恢复之前的 `kubectl` 上下文：
1. 恢复之前的 `kubectl` 上下文：
{{< text bash >}}
$ kubectl config use-context $ORIGINAL_CONTEXT
$ unset ORIGINAL_CONTEXT
{{< /text >}}
1. 打印 `INGRESS_HOST` 和 `SECURE_INGRESS_PORT`：
1. 打印 `INGRESS_HOST` 和 `SECURE_INGRESS_PORT`：
{{< text bash >}}
$ 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
@ -266,7 +266,7 @@ Istio 位置感知的服务路由特性，可以根据请求源所在的位置
### 启动 watching 集群 2{start-watching-cluster-2}
1. 执行下面命令，添加并标记 Kubernetes `cluster2` 的 secret。
1. 执行下面命令，添加并标记 Kubernetes `cluster2` 的 secret。
执行完这些命令，`cluster1` 中的 Istio Pilot 将开始 watching `cluster2` 的服务和实例，如同对待 `cluster1` 一样。
{{< text bash >}}
@ -274,7 +274,7 @@ Istio 位置感知的服务路由特性，可以根据请求源所在的位置
$ kubectl label --context=$CTX_CLUSTER1 secret n2-k8s-secret istio/multiCluster=true -n istio-system
{{< /text >}}
1. 等待 `istio-ingressgateway` 就绪：
1. 等待 `istio-ingressgateway` 就绪：
{{< text bash >}}
$ kubectl get pods --context=$CTX_CLUSTER2 -n istio-system -l istio=ingressgateway

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` 文件：

6
content/zh/docs/setup/platform-setup/MicroK8s/index.md
View File

@ -15,19 +15,19 @@ keywords: [platform-setup,kubernetes,MicroK8s]
运行 MicroK8s 需要管理员权限。
{{< /warning >}}
1. 使用如下命令安装最新版本的 [MicroK8s](https://microk8s.io)
1. 使用如下命令安装最新版本的 [MicroK8s](https://microk8s.io)
{{< text bash >}}
$ sudo snap install microk8s --classic
{{< /text >}}
1. 使用如下命令启用 Istio。
1. 使用如下命令启用 Istio。
{{< text bash >}}
$ microk8s.enable istio
{{< /text >}}
1. 当提示出现时，您需要选择是否在 sidecars 之间强制进行双向 TLS 认证。
1. 当提示出现时，您需要选择是否在 sidecars 之间强制进行双向 TLS 认证。
如果您有不支持 Istio 和支持 Istio 服务的混合部署，或者您不确定，请选择 No。
请运行以下命令来检查部署进度：

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

@ -17,16 +17,16 @@ keywords: [platform-setup,kubernetes,gardener,sap]
### 安装并且配置 `kubectl`{#install-and-configure-Kubernetes}
1. 如果您已经有 `kubectl` CLI，请运行 `kubectl version --short` 来检查版本。您需要 `v1.10` 或更高版本。
1. 如果您已经有 `kubectl` CLI，请运行 `kubectl version --short` 来检查版本。您需要 `v1.10` 或更高版本。
如果您的 `kubectl` 较旧，请按照下一步安装新版本。
1. [安装 `kubectl` CLI](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
1. [安装 `kubectl` CLI](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
### 访问 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)
1. [配置对您的 Gardener 项目的访问权限](https://kubernetes.io/docs/tasks/tools/install-kubectl/#verifying-kubectl-configuration)
使用 kubeconfig，如果您还不是 Gardener 管理员，则可以在 Gardener 仪表板中创建一个用户：转到 "Members" 部分并添加服务帐户。
然后，您可以为您的项目下载 kubeconfig。如果使用用户界面创建集群，则可以跳过此步骤。
只有通过程序访问才需要它，请确保在您的 shell 中设置`export KUBECONFIG=garden-my-project.yaml`。
@ -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/gke/index.md
View File

@ -41,7 +41,7 @@ Google 为 GKE 提供了一个插件，
{{< warning >}}
如果需要使用 Istio CNI 功能，
需要在 `gcloud container clusters create` 命令中加入 `--enable-network-policy` 参数，
需要在 `gcloud container clusters create` 命令中加入 `--enable-network-policy` 参数，
以启用 GKE 集群的 [network-policy](https://cloud.google.com/kubernetes-engine/docs/how-to/network-policy) 功能。
{{< /warning >}}

6
content/zh/docs/setup/platform-setup/ibm/index.md
View File

@ -21,9 +21,9 @@ IBM 为 IBM Cloud Kubernetes Service 提供了 {{< gloss >}}managed control plan
要在手动安装 Istio 之前准备群集，请按照下列步骤操作：
1. [安装 IBM Cloud CLI，IBM Cloud Kubernetes Service 插件和 Kubernetes CLI](https://cloud.ibm.com/docs/containers?topic=containers-cs_cli_install).
1. [安装 IBM Cloud CLI，IBM Cloud Kubernetes Service 插件和 Kubernetes CLI](https://cloud.ibm.com/docs/containers?topic=containers-cs_cli_install).
1. 使用以下命令创建标准的 Kubernetes 集群。
1. 使用以下命令创建标准的 Kubernetes 集群。
将 `<cluster-name>` 替换为您用于集群的名称，将 `<zone-name>` 替换为可用区。
{{< tip >}}
@ -42,7 +42,7 @@ IBM 为 IBM Cloud Kubernetes Service 提供了 {{< gloss >}}managed control plan
否则, 将自动为您创建。您可以通过运行 `ibmcloud ks vlans --zone <zone-name>` 来查看可用的 VLAN。
{{< /tip >}}
1. 运行以下命令下载您的 `kubectl` 集群配置，然后按照命令输出的说明来设置 `KUBECONFIG` 环境变量。
1. 运行以下命令下载您的 `kubectl` 集群配置，然后按照命令输出的说明来设置 `KUBECONFIG` 环境变量。
{{< text bash >}}
$ ibmcloud ks cluster-config <cluster-name>

20
content/zh/docs/setup/platform-setup/kind/index.md
View File

@ -18,7 +18,7 @@ kind 主要是为了测试 Kubernetes 自身而设计的，但它也可用于本
## 安装步骤{#installation-steps}
1. 使用下列命令创建一个集群：
1. 使用下列命令创建一个集群：
{{< text bash >}}
$ kind create cluster --name istio-testing
@ -26,14 +26,14 @@ kind 主要是为了测试 Kubernetes 自身而设计的，但它也可用于本
`--name` 用于为集群指定一个名字。默认情况下，该集群将会名为 `kind`。
1. 使用下列命令查看 kind 集群列表：
1. 使用下列命令查看 kind 集群列表：
{{< text bash >}}
$ kind get clusters
istio-testing
{{< /text >}}
1. 使用下列命令查看本地 Kubernetes 环境：
1. 使用下列命令查看本地 Kubernetes 环境：
{{< text bash >}}
$ kubectl config get-contexts
@ -46,7 +46,7 @@ kind 主要是为了测试 Kubernetes 自身而设计的，但它也可用于本
`kind` 会作为前缀加到环境和集群名上，如：`kind-istio-testing`
{{< /tip >}}
1. 如果运行了多套集群，还需要选择 `kubectl` 将要操作哪一套。
1. 如果运行了多套集群，还需要选择 `kubectl` 将要操作哪一套。
可以在 [Kubernetes kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 文件中设置当前环境来指定一个默认集群。
另外，还可以运行下列命令来为 `kubectl` 设置当前环境：
@ -57,7 +57,7 @@ kind 主要是为了测试 Kubernetes 自身而设计的，但它也可用于本
kind 集群设置完成后，就可以开始在它上面[安装 Istio](/zh/docs/setup/getting-started/#download) 了。
1. 当体验过后，想删除集群时，可以使用以下命令：
1. 当体验过后，想删除集群时，可以使用以下命令：
{{< text bash >}}
$ kind delete cluster --name istio-testing
@ -69,13 +69,13 @@ kind 主要是为了测试 Kubernetes 自身而设计的，但它也可用于本
kind 不像 minikube 一样内置了操作界面。但仍然可以设置一个基于网页的 Kubernetes 界面，以查看集群。
参考以下说明来为 kind 设置操作界面。
1. 运行以下命令以部署操作界面：
1. 运行以下命令以部署操作界面：
{{< text bash >}}
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta8/aio/deploy/recommended.yaml
{{< /text >}}
1. 验证操作界面已经部署并且正在运行。
1. 验证操作界面已经部署并且正在运行。
{{< text bash >}}
$ kubectl get pod -n kubernetes-dashboard
@ -84,13 +84,13 @@ kind 不像 minikube 一样内置了操作界面。但仍然可以设置一个
kubernetes-dashboard-b7ffbc8cb-zl8zg 1/1 Running 0 39s
{{< /text >}}
1. 创建 `ClusterRoleBinding` 以提供对新创建的集群的管理权限访问。
1. 创建 `ClusterRoleBinding` 以提供对新创建的集群的管理权限访问。
{{< text bash >}}
$ kubectl create clusterrolebinding default-admin --clusterrole cluster-admin --serviceaccount=default:default
{{< /text >}}
1. 需要用 Bearer Token 来登录到操作界面。使用以下命令将 token 保存到变量。
1. 需要用 Bearer Token 来登录到操作界面。使用以下命令将 token 保存到变量。
{{< text bash >}}
$ token=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.token}"|base64 -d)
@ -102,7 +102,7 @@ kind 不像 minikube 一样内置了操作界面。但仍然可以设置一个
$ echo $token
{{< /text >}}
1. 使用 kubectl 命令行工具运行以下命令以访问操作界面：
1. 使用 kubectl 命令行工具运行以下命令以访问操作界面：
{{< text bash >}}
$ kubectl proxy

8
content/zh/docs/setup/platform-setup/minikube/index.md
View File

@ -20,10 +20,10 @@ keywords: [platform-setup,kubernetes,minikube]
## 安装步骤{#installation-steps}
1. 安装最新的 [minikube](https://kubernetes.io/docs/setup/minikube/)，版本 **1.1.1 或更高**，以及
1. 安装最新的 [minikube](https://kubernetes.io/docs/setup/minikube/)，版本 **1.1.1 或更高**，以及
[minikube 虚拟机驱动](https://kubernetes.io/docs/tasks/tools/install-minikube/#install-a-hypervisor)。
1. 如果你没有使用默认的驱动，需要配置 minikube 虚拟机驱动。
1. 如果你没有使用默认的驱动，需要配置 minikube 虚拟机驱动。
比如，如果你安装了 KVM 虚拟机，使用如下命令设置 minikube 的 `vm-driver` 配置：
@ -31,7 +31,7 @@ keywords: [platform-setup,kubernetes,minikube]
$ minikube config set vm-driver kvm2
{{< /text >}}
1. 以 16384 `MB` 内存和 4 `CPUs` 启动 minikube。这个例子使用了 Kubernetes **1.14.2**。
1. 以 16384 `MB` 内存和 4 `CPUs` 启动 minikube。这个例子使用了 Kubernetes **1.14.2**。
你可以设置 `--kubernetes-version` 的值以指定任意 Istio 支持的 Kubernetes 版本：
{{< text bash >}}
@ -63,7 +63,7 @@ keywords: [platform-setup,kubernetes,minikube]
bookinfo 的 VMWare Fusion 虚拟机中生成的。
{{< /tip >}}
1. （可选，推荐）如果你希望 minikube 提供一个负载均衡给 Istio，你可以使用
1. （可选，推荐）如果你希望 minikube 提供一个负载均衡给 Istio，你可以使用
[minikube tunnel](https://minikube.sigs.k8s.io/docs/tasks/loadbalancer/#using-minikube-tunnel)。
在另一个终端运行这个命令，因为 minikube tunnel 会阻塞的你的终端用于显示网络诊断信息：

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

30
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 上展示。
@ -21,14 +21,14 @@ LightStep 可以分析来自大规模生产级软件的 100% 未采样的事务
对于 LightStep Tracing 的用户，你的 satellites 是已经配置好的。
1. 确保你有 LightStep 的[访问令牌](https://docs.lightstep.com/docs/create-and-manage-access-tokens)。
1. 确保你有 LightStep 的[访问令牌](https://docs.lightstep.com/docs/create-and-manage-access-tokens)。
1. 需要使用你的 satellite 地址来部署 Istio。
1. 需要使用你的 satellite 地址来部署 Istio。
对于 [𝑥]PM 用户，确保你可以使用 `<Host>:<Port>` 格式的地址访问 satellite 池，例如 `lightstep-satellite.lightstep:9292`。
对于 LightStep Tracing 的用户，使用这个地址 `collector-grpc.lightstep.com:443`。
1. 使用以下指定的配置参数部署 Istio：
1. 使用以下指定的配置参数部署 Istio：
- `pilot.traceSampling=100`
- `global.proxy.tracer="lightstep"`
- `global.tracer.lightstep.address="<satellite-address>"`
@ -48,7 +48,7 @@ LightStep 可以分析来自大规模生产级软件的 100% 未采样的事务
--set values.global.tracer.lightstep.cacertPath="/etc/lightstep/cacert.pem"
{{< /text >}}
1. 把 satellite 池证书颁发机构发的证书作为一个密钥存储在默认的命名空间下。
1. 把 satellite 池证书颁发机构发的证书作为一个密钥存储在默认的命名空间下。
对于 LightStep Tracing 用户，要在这里下载并使用[这个证书](https://docs.lightstep.com/docs/instrument-with-istio-as-your-service-mesh)。
如果你把 Bookinfo 应用程序部署在了其它的命名空间下，就要在对的应命名空间下创建相应的密钥证书。
@ -72,33 +72,33 @@ LightStep 可以分析来自大规模生产级软件的 100% 未采样的事务
EOF
{{< /text >}}
1. 按照[部署 Bookinfo 示例应用程序说明](/zh/docs/examples/bookinfo/#deploying-the-application)操作。
1. 按照[部署 Bookinfo 示例应用程序说明](/zh/docs/examples/bookinfo/#deploying-the-application)操作。
## 可视化追踪数据{#visualize-trace-data}
1. 按照[为 Bookinfo 应用程序创建 ingress 网关说明](/zh/docs/examples/bookinfo/#determine-the-ingress-IP-and-port)操作。
1. 按照[为 Bookinfo 应用程序创建 ingress 网关说明](/zh/docs/examples/bookinfo/#determine-the-ingress-IP-and-port)操作。
1. 为了验证上一步是否成功，请确认你在 shell 的环境变量中中设置了 `GATEWAY_URL` 。
1. 为了验证上一步是否成功，请确认你在 shell 的环境变量中中设置了 `GATEWAY_URL` 。
1. 发送流量到示例应用程序。
1. 发送流量到示例应用程序。
{{< text bash >}}
$ curl http://$GATEWAY_URL/productpage
{{< /text >}}
1. 打开 LightStep [web UI](https://app.lightstep.com/)。
1. 打开 LightStep [web UI](https://app.lightstep.com/)。
1. 导航到 Explorer 。
1. 导航到 Explorer 。
1. 在顶部找到查询栏，在这里你可以用 **Service** 、**Operation** 和 **Tag** 的值进行过滤查询。
1. 在顶部找到查询栏，在这里你可以用 **Service** 、**Operation** 和 **Tag** 的值进行过滤查询。
1. 从 **Service** 下拉列表中选择 `productpage.default`。
1. 从 **Service** 下拉列表中选择 `productpage.default`。
1. 点击 **Run** 。可以看到如下类似的内容：
1. 点击 **Run** 。可以看到如下类似的内容：
{{< image link="./istio-tracing-list-lightstep.png" caption="Explorer" >}}
1. 在延迟直方图下面点击示例追踪表格的第一行，就可以查看 `/productpage` 刷新后的详细信息。该页面类似下面：
1. 在延迟直方图下面点击示例追踪表格的第一行，就可以查看 `/productpage` 刷新后的详细信息。该页面类似下面：
{{< image link="./istio-tracing-details-lightstep.png" caption="Detailed Trace View" >}}

4
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}
@ -29,7 +29,7 @@ Istio 利用 [Envoy 的分布式追踪](https://www.envoyproxy.io/docs/envoy/v1.
* `x-b3-flags`
* `x-ot-span-context`
例如，如果你看 Python 的 `productpage` 服务这个例子，可以看到这个应用程序使用了 [OpenTracing](https://opentracing.io/) 库从 HTTP 请求中提取所需的头信息：
例如，如果你看 Python 的 `productpage` 服务这个例子，可以看到这个应用程序使用了 [OpenTracing](https://opentracing.io/) 库从 HTTP 请求中提取所需的头信息：
{{< text python >}}
def getForwardHeaders(request):

16
content/zh/docs/tasks/observability/distributed-tracing/zipkin/index.md
View File

@ -16,7 +16,7 @@ aliases:
## 开始之前{#before-you-begin}
1. 参考[安装指南](/zh/docs/setup/install/istioctl)中的说明，
1. 参考[安装指南](/zh/docs/setup/install/istioctl)中的说明，
使用如下配置安装 Istio：
a) 通过配置 `--set values.tracing.enabled=true` 和 `--set values.tracing.provider=zipkin` 选项可以安装一个“开箱即用”的演示或测试环境。
@ -28,7 +28,7 @@ aliases:
默认采样率为 1%。
{{< /warning >}}
1. 部署 [Bookinfo](/zh/docs/examples/bookinfo/#deploying-the-application) 示例程序。
1. 部署 [Bookinfo](/zh/docs/examples/bookinfo/#deploying-the-application) 示例程序。
## 访问仪表盘{#accessing-the-dashboard}
@ -42,33 +42,33 @@ $ istioctl dashboard zipkin
## 使用 Bookinfo 示例程序生成追踪报告{#generating-traces-using-the-Bookinfo-sample}
1. 当 Bookinfo 程序启动并正常运行后，访问 `http://$GATEWAY_URL/productpage` 一次或多次，
1. 当 Bookinfo 程序启动并正常运行后，访问 `http://$GATEWAY_URL/productpage` 一次或多次，
以生成追踪信息。
{{< boilerplate trace-generation >}}
1. 在顶部面板中，从 **Service Name** 下拉列表中选择感兴趣的服务（或“全部”），
1. 在顶部面板中，从 **Service Name** 下拉列表中选择感兴趣的服务（或“全部”），
然后单击 **Find Traces**:
{{< image link="./istio-tracing-list-zipkin.png" caption="Tracing Dashboard" >}}
1. 单击顶部的最新追踪，查看与之对应的最新 `/productpage` 请求的详细信息：
1. 单击顶部的最新追踪，查看与之对应的最新 `/productpage` 请求的详细信息：
{{< image link="./istio-tracing-details-zipkin.png" caption="Detailed Trace View" >}}
1. 追踪由一组 span 组成，
1. 追踪由一组 span 组成，
其中每个 span 对应一个 Bookinfo 服务，该服务在执行 `/productpage` 请求或 Istio 内部组件时被调用，
例如：`istio-ingressgateway`。
## 清理{#cleanup}
1. 删除所有可能仍在运行的 `istioctl` 进程，使用 control-C 或者：
1. 删除所有可能仍在运行的 `istioctl` 进程，使用 control-C 或者：
{{< text bash >}}
$ killall istioctl
{{< /text >}}
1. 如果您不打算继续深入探索任何后续任务，请
1. 如果您不打算继续深入探索任何后续任务，请
参考 [Bookinfo 清理](/zh/docs/examples/bookinfo/#cleanup)说明
关闭应用程序。

104
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 \
@ -113,71 +113,71 @@ $ oc patch clusterrole kiali -p '[{"op":"add", "path":"/rules/-", "value":{"apiG
## 生成服务图{#generating-a-service-graph}
1. 要验证服务是否在您的群集中运行，请运行以下命令：
1. 要验证服务是否在您的群集中运行，请运行以下命令：
{{< text bash >}}
$ kubectl -n istio-system get svc kiali
{{< /text >}}
1. 要确定 Bookinfo URL，请按照说明确定 [Bookinfo ingress `GATEWAY_URL`](/zh/docs/examples/bookinfo/#determine-the-ingress-IP-and-port).
1. 要确定 Bookinfo URL，请按照说明确定 [Bookinfo ingress `GATEWAY_URL`](/zh/docs/examples/bookinfo/#determine-the-ingress-IP-and-port).
1. 要将流量发送到网格，您有三种选择
1. 要将流量发送到网格，您有三种选择
* 在浏览器中访问 `http://$GATEWAY_URL/productpage`
* 在浏览器中访问 `http://$GATEWAY_URL/productpage`
* 多次使用以下命令：
* 多次使用以下命令：
{{< text bash >}}
$ curl http://$GATEWAY_URL/productpage
{{< /text >}}
* 如果您在系统中安装了 `watch` 命令，请通过以下方式连续发送请求：
* 如果您在系统中安装了 `watch` 命令，请通过以下方式连续发送请求：
{{< text bash >}}
$ watch -n 1 curl -o /dev/null -s -w %{http_code} $GATEWAY_URL/productpage
{{< /text >}}
1. 要打开 Kiali UI，请在您的 Kubernetes 环境中执行以下命令：
1. 要打开 Kiali UI，请在您的 Kubernetes 环境中执行以下命令：
{{< text bash >}}
$ istioctl dashboard kiali
{{< /text >}}
1. 要登录 Kiali UI，请到 Kiali 登录界面，然后输入存储在 Kiali secret 中的用户名和密码。
1. 要登录 Kiali UI，请到 Kiali 登录界面，然后输入存储在 Kiali secret 中的用户名和密码。
1. 登录后立即显示的 **Overview** 页面中查看网格的概述。**Overview** 页面显示了网格中具有服务的所有名称空间。以下屏幕截图显示了类似的页面：
1. 登录后立即显示的 **Overview** 页面中查看网格的概述。**Overview** 页面显示了网格中具有服务的所有名称空间。以下屏幕截图显示了类似的页面：
{{< 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. 要查看度量标准摘要，请选择图中的任何节点或边，以便在右侧的 summary details 面板中显示其度量的详细信息。
1. 要使用不同的图形类型查看服务网格，请从 **Graph Type** 下拉菜单中选择一种图形类型。有几种图形类型可供选择： **App**, **Versioned App**, **Workload**, **Service**。
1. 要使用不同的图形类型查看服务网格，请从 **Graph Type** 下拉菜单中选择一种图形类型。有几种图形类型可供选择：**App**, **Versioned App**, **Workload**, **Service**。
* **App** 图形类型将一个应用程序的所有版本聚合到一个图形节点中。以下示例显示了一个单独的 **reviews** 节点，它代表了评论应用程序的三个版本。
* **App** 图形类型将一个应用程序的所有版本聚合到一个图形节点中。以下示例显示了一个单独的 **reviews** 节点，它代表了评论应用程序的三个版本。
{{< image width="75%" link="./kiali-app.png" caption="Example App Graph" >}}
* **Versioned App** 图类型显示每个应用程序版本的节点，但是特定应用程序的所有版本都组合在一起。
* **Versioned App** 图类型显示每个应用程序版本的节点，但是特定应用程序的所有版本都组合在一起。
下面的示例显示 **reviews** 组框，其中包含三个节点，这些节点代表了评论应用程序的三个版本。
{{< image width="75%" link="./kiali-versionedapp.png" caption="Example Versioned App Graph" >}}
* **Workload** 图类型显示了服务网格中每个工作负载的节点。
这种图类型不需要您使用 `app` 和 `version` 标签，因此，如果您选择在组件上不使用这些标签， 这是您将使用的图形类型。
* **Workload** 图类型显示了服务网格中每个工作负载的节点。
这种图类型不需要您使用 `app` 和 `version` 标签，因此，如果您选择在组件上不使用这些标签，这是您将使用的图形类型。
{{< image width="70%" link="./kiali-workload.png" caption="Example Workload Graph" >}}
* **Service** 图类型显示网格中每个服务的节点，但从图中排除所有应用程序和工作负载。
* **Service** 图类型显示网格中每个服务的节点，但从图中排除所有应用程序和工作负载。
{{< image width="70%" link="./kiali-service-graph.png" caption="Example Service Graph" >}}
## 检查 Istio 配置{#examining-Istio-configuration}
1. 要检查有关 Istio 配置的详细信息，请单击左侧菜单栏上的 **Applications**，**Workloads** 和 **Services** 菜单图标。
1. 要检查有关 Istio 配置的详细信息，请单击左侧菜单栏上的 **Applications**，**Workloads** 和 **Services** 菜单图标。
以下屏幕截图显示了 Bookinfo 应用程序信息：
{{< image width="80%" link="./kiali-services.png" caption="Example Details" >}}
@ -186,41 +186,41 @@ $ oc patch clusterrole kiali -p '[{"op":"add", "path":"/rules/-", "value":{"apiG
您可以使用 Kiali 加权路由转发来定义特定百分比的请求流量以路由到两个或多个工作负载。
1. 查看 `bookinfo` 图的 **Versioned app graph**。
1. 查看 `bookinfo` 图的 **Versioned app graph**。
* 确保已经在 **Edge Labels** 下拉菜单中选择了 **Requests percentage** ，以查看路由到每个工作负载的流量百分比。
* 确保已经在 **Edge Labels** 下拉菜单中选择了 **Requests percentage** ，以查看路由到每个工作负载的流量百分比。
* 确保已经选中 **Display** 下拉菜单中的 **Service Nodes** 复选框，以便在图中查看服务节点。
* 确保已经选中 **Display** 下拉菜单中的 **Service Nodes** 复选框，以便在图中查看服务节点。
{{< image width="80%" link="./kiali-wiz0-graph-options.png" caption="Bookinfo Graph Options" >}}
1. 通过单击 `ratings` 服务 (triangle) 节点，将关注点放在 `bookinfo` 图内的 `ratings` 服务上。
1. 通过单击 `ratings` 服务 (triangle) 节点，将关注点放在 `bookinfo` 图内的 `ratings` 服务上。
注意，`ratings` 服务流量平均分配给两个 `ratings` 服务 `v1` 和 `v2`（每台服务被路由 50％ 的请求）。
{{< image width="80%" link="./kiali-wiz1-graph-ratings-percent.png" caption="Graph Showing Percentage of Traffic" >}}
1. 点击侧面板上的 **ratings** 链接，进入 `ratings` 服务的服务视图。
1. 点击侧面板上的 **ratings** 链接，进入 `ratings` 服务的服务视图。
1. 从 **Action** 下拉菜单中，选择 **Create Weighted Routing** 以访问加权路由向导。
1. 从 **Action** 下拉菜单中，选择 **Create Weighted Routing** 以访问加权路由向导。
{{< image width="80%" link="./kiali-wiz2-ratings-service-action-menu.png" caption="Service Action Menu" >}}
1. 拖动滑块以指定要路由到每个服务的流量百分比。
对于 `ratings-v1`，将其设置为 10％； 对于 `ratings-v2` ，请将其设置为 90％。
1. 拖动滑块以指定要路由到每个服务的流量百分比。
对于 `ratings-v1`，将其设置为 10％；对于 `ratings-v2` ，请将其设置为 90％。
{{< image width="80%" link="./kiali-wiz3-weighted-routing-wizard.png" caption="Weighted Routing Wizard" >}}
1. 单击 **Create** 按钮以创建新的路由。
1. 单击 **Create** 按钮以创建新的路由。
1. 点击左侧导航栏中的 **Graph** 以返回到 `bookinfo` 图表。
1. 点击左侧导航栏中的 **Graph** 以返回到 `bookinfo` 图表。
1. 发送请求到 `bookinfo` 应用程序。例如，要每秒发送一个请求，如果您的系统上装有 `watch`，则可以执行以下命令：
1. 发送请求到 `bookinfo` 应用程序。例如，要每秒发送一个请求，如果您的系统上装有 `watch`，则可以执行以下命令：
{{< text bash >}}
$ watch -n 1 curl -o /dev/null -s -w %{http_code} $GATEWAY_URL/productpage
{{< /text >}}
1. 几分钟后，您会注意到流量百分比将反映新的流量路由，从而确认您的新流量路由已成功将所有流量请求的 90％ 路由到 `ratings-v2`。
1. 几分钟后，您会注意到流量百分比将反映新的流量路由，从而确认您的新流量路由已成功将所有流量请求的 90％ 路由到 `ratings-v2`。
{{< image width="80%" link="./kiali-wiz4-ratings-weighted-route-90-10.png" caption="90% Ratings Traffic Routed to ratings-v2" >}}
@ -234,27 +234,27 @@ Istio 1.4 引入了 `istioctl analyze`，它使您能够以在 CI 管道中使
强制对服务端口名称进行无效配置，以查看 Kiali 如何报告验证错误。
1. 将 `details` 服务的端口名从 `http` 更改为 `foo`：
1. 将 `details` 服务的端口名从 `http` 更改为 `foo`：
{{< text bash >}}
$ kubectl patch service details -n bookinfo --type json -p '[{"op":"replace","path":"/spec/ports/0/name", "value":"foo"}]'
{{< /text >}}
1. 通过单击左侧导航栏上的 **Services**，导航到 **Services** 列表。
1. 通过单击左侧导航栏上的 **Services**，导航到 **Services** 列表。
1. 如果尚未选择，请从 **Namespace** 下拉菜单中选择 `bookinfo`。
1. 如果尚未选择，请从 **Namespace** 下拉菜单中选择 `bookinfo`。
1. 注意在 `details` 行的 **Configuration** 列中显示的错误图标。
1. 注意在 `details` 行的 **Configuration** 列中显示的错误图标。
{{< image width="80%" link="./kiali-validate1-list.png" caption="Services List Showing Invalid Configuration" >}}
1. 单击 **Name** 列中的 **details** 链接，以导航到服务详细信息视图。
1. 单击 **Name** 列中的 **details** 链接，以导航到服务详细信息视图。
1. 将鼠标悬停在错误图标上可以显示描述错误的提示。
1. 将鼠标悬停在错误图标上可以显示描述错误的提示。
{{< image width="80%" link="./kiali-validate2-errormsg.png" caption="Service Details Describing the Invalid Configuration" >}}
1. 将端口名称改回 `http` 以更正配置，并将 `bookinfo` 返回其正常状态。
1. 将端口名称改回 `http` 以更正配置，并将 `bookinfo` 返回其正常状态。
{{< text bash >}}
$ kubectl patch service details -n bookinfo --type json -p '[{"op":"replace","path":"/spec/ports/0/name", "value":"http"}]'
@ -266,46 +266,46 @@ Istio 1.4 引入了 `istioctl analyze`，它使您能够以在 CI 管道中使
Kiali 提供了一个 YAML 编辑器，用于查看和编辑 Istio 配置资源。当检测到错误的配置时，YAML 编辑器还将提供验证消息。
1. 创建 Bookinfo 目标规则：
1. 创建 Bookinfo 目标规则：
{{< text bash >}}
$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all.yaml@
{{< /text >}}
1. 单击左侧导航栏上的 `Istio Config` 以导航到 Istio 配置列表。
1. 单击左侧导航栏上的 `Istio Config` 以导航到 Istio 配置列表。
1. 如果尚未选择，请从 **Namespace** 下拉菜单中选择 `bookinfo`。
1. 如果尚未选择，请从 **Namespace** 下拉菜单中选择 `bookinfo`。
1. 请注意错误消息以及错误警告图标，它们会警告您一些配置问题。
1. 请注意错误消息以及错误警告图标，它们会警告您一些配置问题。
{{< image width="80%" link="./kiali-istioconfig0-errormsgs.png" caption="Istio Config List Incorrect Configuration Messages" >}}
1. 将鼠标悬停在 `details` 行的 **Configuration** 列中的错误图标上，以查看其他消息。
1. 将鼠标悬停在 `details` 行的 **Configuration** 列中的错误图标上，以查看其他消息。
{{< image width="80%" link="./kiali-istioconfig1-tooltip.png" caption="Istio Config List Incorrect Configuration Tool Tips" >}}
1. 单击 **Name** 列中的 **details** 链接，以导航到 `details` 目标规则视图。
1. 单击 **Name** 列中的 **details** 链接，以导航到 `details` 目标规则视图。
1. 请注意消息和图标，它们提醒您一些失败的验证规则。
1. 请注意消息和图标，它们提醒您一些失败的验证规则。
{{< image width="80%" link="./kiali-istioconfig2-details-errormsgs.png" caption="Istio Configuration Details View Showing Errors" >}}
1. 单击 **YAML** 选项卡以查看此 Istio 目标规则资源的 YAML。
1. 单击 **YAML** 选项卡以查看此 Istio 目标规则资源的 YAML。
1. 请注意未通过验证检查的行颜色会突出显示和异常图标。
1. 请注意未通过验证检查的行颜色会突出显示和异常图标。
{{< image width="80%" link="./kiali-istioconfig3-details-yaml1.png" caption="YAML Editor Showing Validation Errors and Warnings" >}}
1. 将鼠标悬停在黄色图标上可以查看工具提示消息，该消息提示您触发了警告的验证检查。
1. 将鼠标悬停在黄色图标上可以查看工具提示消息，该消息提示您触发了警告的验证检查。
有关警告起因和解决方法的更多详细信息，请在 [Kiali Validations page](http://kiali.io/documentation/validations/) 上查找验证警告消息。
{{< image width="80%" link="./kiali-istioconfig3-details-yaml2.png" caption="YAML Editor Showing Warning Tool Tip" >}}
1. 将鼠标悬停在红色图标上可以查看工具提示消息，该消息提示您触发错误的验证检查。有关错误原因和解决方法的更多详细信息，请在 [Kiali Validations page](http://kiali.io/documentation/validations/) 上查找验证错误消息。
1. 将鼠标悬停在红色图标上可以查看工具提示消息，该消息提示您触发错误的验证检查。有关错误原因和解决方法的更多详细信息，请在 [Kiali Validations page](http://kiali.io/documentation/validations/) 上查找验证错误消息。
{{< image width="80%" link="./kiali-istioconfig3-details-yaml3.png" caption="YAML Editor Showing Error Tool Tip" >}}
1. 删除目标规则，使 `bookinfo` 返回其原始状态。
1. 删除目标规则，使 `bookinfo` 返回其原始状态。
{{< text bash >}}
$ kubectl delete -f samples/bookinfo/networking/destination-rule-all.yaml
@ -319,7 +319,7 @@ Kiali 提供了一个 YAML 编辑器，用于查看和编辑 Istio 配置资源
Kiali Public API 建立在 Prometheus 查询之上，并且取决于标准的 Istio 度量配置。
它还会调用 Kubernetes API 以获取有关您的服务的其他详细信息。
为了获得使用 Kiali 的最佳体验，请在应用程序组件上使用元数据标签 `app` 和 `version`。 作为模板，Bookinfo 示例应用程序遵循此约定。
为了获得使用 Kiali 的最佳体验，请在应用程序组件上使用元数据标签 `app` 和 `version`。作为模板，Bookinfo 示例应用程序遵循此约定。
## 清理{#cleanup}

6
content/zh/docs/tasks/observability/logs/access-log/index.md
View File

@ -37,7 +37,7 @@ configmap "istio" replaced
## 测试访问日志{#test-the-access-log}
1. 从 `sleep` 向 `httpbin` 发送一个请求:
1. 从 `sleep` 向 `httpbin` 发送一个请求:
{{< text bash >}}
$ kubectl exec -it $(kubectl get pod -l app=sleep -o jsonpath='{.items[0].metadata.name}') -c sleep -- curl -v httpbin:8000/status/418
@ -63,14 +63,14 @@ configmap "istio" replaced
* Connection #0 to host httpbin left intact
{{< /text >}}
1. 检查 `sleep` 的日志:
1. 检查 `sleep` 的日志:
{{< text bash >}}
$ kubectl logs -l app=sleep -c istio-proxy
[2019-03-06T09:31:27.354Z] "GET /status/418 HTTP/1.1" 418 - "-" 0 135 11 10 "-" "curl/7.60.0" "d209e46f-9ed5-9b61-bbdd-43e22662702a" "httpbin:8000" "172.30.146.73:80" outbound|8000||httpbin.default.svc.cluster.local - 172.21.13.94:8000 172.30.146.82:60290 -
{{< /text >}}
1. 检查 `httpbin` 的日志:
1. 检查 `httpbin` 的日志:
{{< text bash >}}
$ kubectl logs -l app=httpbin -c istio-proxy

6
content/zh/docs/tasks/observability/logs/collecting-logs/index.md
View File

@ -17,7 +17,7 @@ aliases:
## 收集新的日志数据{#collecting-new-logs-data}
1. 为新日志流生效一个 YAML 配置文件，Istio 将自动生成并收集日志信息。
1. 为新日志流生效一个 YAML 配置文件，Istio 将自动生成并收集日志信息。
{{< text bash >}}
$ kubectl apply -f @samples/bookinfo/telemetry/log-entry.yaml@
@ -32,7 +32,7 @@ aliases:
{{< /warning >}}
1. 向示例应用发送流量。
1. 向示例应用发送流量。
以 Bookinfo 为例，在浏览器中访问 `http://$GATEWAY_URL/productpage` 或执行如下命令：
@ -40,7 +40,7 @@ aliases:
$ curl http://$GATEWAY_URL/productpage
{{< /text >}}
1. 验证是否已经生成了日志流并且正向其中不断增添请求。
1. 验证是否已经生成了日志流并且正向其中不断增添请求。
在 Kubernetes 环境中，搜索 `istio-telemetry` pods 的日志信息，如下所示：

4
content/zh/docs/tasks/observability/logs/fluentd/index.md
View File

@ -303,7 +303,7 @@ $ kubectl apply -f @samples/bookinfo/telemetry/fluentd-istio-crd.yaml@
## 查看新日志{#view-the-new-logs}
1. 将流量发送到示例应用程序。
1. 将流量发送到示例应用程序。
对于 [Bookinfo](/zh/docs/examples/bookinfo/#determine-the-ingress-IP-and-port) 示例，
请在您的浏览器中访问 `http://$GATEWAY_URL/productpage`，或使用以下命令在命令行中发送请求：
@ -312,7 +312,7 @@ $ kubectl apply -f @samples/bookinfo/telemetry/fluentd-istio-crd.yaml@
$ curl http://$GATEWAY_URL/productpage
{{< /text >}}
1. 在 Kubernetes 环境中，通过执行以下命令来设置 Kibana 的端口转发：
1. 在 Kubernetes 环境中，通过执行以下命令来设置 Kibana 的端口转发：
{{< text bash >}}
$ kubectl -n logging port-forward $(kubectl -n logging get pod -l app=kibana -o jsonpath='{.items[0].metadata.name}') 5601:5601 &

6
content/zh/docs/tasks/observability/metrics/collecting-metrics/index.md
View File

@ -20,7 +20,7 @@ aliases:
## 采集新的指标{#collecting-new-metrics}
1. 应用配置新指标的 YAML 文件，该指标将由 Istio 自动生成和采集。
1. 应用配置新指标的 YAML 文件，该指标将由 Istio 自动生成和采集。
{{< text bash >}}
$ kubectl apply -f @samples/bookinfo/telemetry/metrics.yaml@
@ -35,7 +35,7 @@ aliases:
{{< /warning >}}
1. 发送流量到示例应用。
1. 发送流量到示例应用。
对于 Bookinfo 示例，从浏览器访问 `http://$GATEWAY_URL/productpage` 或使用下列命令：
@ -43,7 +43,7 @@ aliases:
$ curl http://$GATEWAY_URL/productpage
{{< /text >}}
1. 确认新的指标已被生成并采集。
1. 确认新的指标已被生成并采集。
对于 Kubernetes 环境，执行以下命令为 Prometheus 设置端口转发：

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

@ -18,7 +18,7 @@ aliases:
## 查询 Istio 度量指标{#query-mesh-metrics}
1. 验证自身集群中运行着 `prometheus` 服务。
1. 验证自身集群中运行着 `prometheus` 服务。
在 Kubernetes 环境中，执行如下命令：
@ -28,7 +28,7 @@ aliases:
prometheus 10.59.241.54 <none> 9090/TCP 2m
{{< /text >}}
1. 向网格发送流量。
1. 向网格发送流量。
以 Bookinfo 为例，在 web 浏览器中访问 `http://$GATEWAY_URL/productpage` 或执行如下命令：
@ -40,7 +40,7 @@ aliases:
`$GATEWAY_URL` 是在 [Bookinfo](/zh/docs/examples/bookinfo/) 应用中设置的值。
{{< /tip >}}
1. 打开 Prometheus UI。
1. 打开 Prometheus UI。
在 Kubernetes 环境中，执行如下命令：
@ -50,10 +50,10 @@ aliases:
在 web 浏览器中访问 [http://localhost:9090/graph](http://localhost:9090/graph)。
1. 执行一个 Prometheus 查询。
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) 命令关闭应用。

6
content/zh/docs/tasks/observability/metrics/tcp-metrics/index.md
View File

@ -35,9 +35,9 @@ aliases:
{{< /warning >}}
1. 设置 Bookinfo 使用 Mongodb。
1. 设置 Bookinfo 使用 Mongodb。
1. 安装 `ratings` 服务的 `v2` 版本。
1. 安装 `ratings` 服务的 `v2` 版本。
如果使用的是启用了 Sidecar 自动注入的集群，可以简单使用 `kubectl` 进行服务部署：
@ -68,7 +68,7 @@ aliases:
deployment "mongodb-v1" configured
{{< /text >}}
1. Bookinfo 示例部署了每个微服务的多个版本，因此您将首先创建目标规则定义每个版本对应的服务子集，以及每个子集的负载均衡策略。
1. Bookinfo 示例部署了每个微服务的多个版本，因此您将首先创建目标规则定义每个版本对应的服务子集，以及每个子集的负载均衡策略。
{{< text bash >}}
$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all.yaml@

12
content/zh/docs/tasks/observability/metrics/using-istio-dashboard/index.md
View File

@ -19,7 +19,7 @@ aliases:
## 查看 Istio Dashboard{#viewing-the-Istio-dashboard}
1. 验证 `prometheus` 服务正在集群中运行。
1. 验证 `prometheus` 服务正在集群中运行。
在 Kubernetes 环境中，执行以下命令：
@ -29,7 +29,7 @@ aliases:
prometheus 10.59.241.54 <none> 9090/TCP 2m
{{< /text >}}
1. 验证 Grafana 服务正在集群中运行。
1. 验证 Grafana 服务正在集群中运行。
在 Kubernetes 环境中，执行以下命令：
@ -39,7 +39,7 @@ aliases:
grafana 10.59.247.103 <none> 3000/TCP 2m
{{< /text >}}
1. 通过 Grafana UI 打开 Istio Dashboard。
1. 通过 Grafana UI 打开 Istio Dashboard。
在 Kubernetes 环境中，执行以下命令：
@ -53,7 +53,7 @@ aliases:
{{< image link="./grafana-istio-dashboard.png" caption="Istio Dashboard" >}}
1. 发送流量到网格。
1. 发送流量到网格。
对于 Bookinfo 示例，在浏览器中访问 `http://$GATEWAY_URL/productpage` 或者发出以下命令：
@ -73,7 +73,7 @@ aliases:
这提供了网格以及网格中的服务和工作负载的全局视图。可以通过导航到特定的仪表盘来获取更多关于服务和工作负载的详细信息，如下所述。
1. 可视化服务仪表盘。
1. 可视化服务仪表盘。
从 Grafana 仪表盘左上角的导航菜单中，可以导航到 Istio Service Dashboard 或者在浏览器中访问
[http://localhost:3000/dashboard/db/istio-service-dashboard](http://localhost:3000/dashboard/db/istio-service-dashboard)。
@ -84,7 +84,7 @@ aliases:
这里给出了服务，以及更进一步的服务的客户端工作负载（调用该服务的工作负载）和服务工作负载（提供该服务的工作负载）的详细指标。
1. 可视化工作负载仪表盘。
1. 可视化工作负载仪表盘。
从 Grafana 仪表盘左上角的导航菜单中，可以导航到 Istio Workload Dashboard 或者在浏览器中访问
[http://localhost:3000/dashboard/db/istio-workload-dashboard](http://localhost:3000/dashboard/db/istio-workload-dashboard)。

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

@ -46,7 +46,7 @@ aliases:
考虑 [Bookinfo](/zh/docs/examples/bookinfo/) 示例应用，其中 `ratings` 服务可通过 `reviews` 服务的多个版本进行访问。
我们想切断对 `reviews` 服务 `v3` 版本的访问。
1. 将浏览器定位到 Bookinfo `productpage` (`http://$GATEWAY_URL/productpage`)。
1. 将浏览器定位到 Bookinfo `productpage` (`http://$GATEWAY_URL/productpage`)。
如果您以 "jason" 用户身份登录，则每个评论都应看到黑色的星标，
它表示 `ratings` 服务是通过 "v2" 版本 `reviews` 服务访问到的。
@ -54,7 +54,7 @@ aliases:
如果您以其他任何用户身份登录（或登出），则每个评论都应看到红色的星标，
它表示 `ratings` 服务是通过 "v3" 版本 `reviews` 服务访问到的。
1. 要想明确地拒绝对 `v3` 版本 `reviews` 服务的访问。
1. 要想明确地拒绝对 `v3` 版本 `reviews` 服务的访问。
连同处理程序和实例，执行以下命令来配置拒绝规则。
@ -83,7 +83,7 @@ aliases:
适配器始终拒绝带有预配置状态码和消息的请求。
状态码和消息在 [denier](/zh/docs/reference/config/policy-and-telemetry/adapters/denier/) 适配器配置中指定。
1. 在浏览器里刷新 `productpage`。
1. 在浏览器里刷新 `productpage`。
如果您已登出或以非 "json" 用户登录，因为`v3 reviews` 服务已经被拒绝访问 `ratings` 服务，所以您不会再看到红色星标。
相反，如果您以 "json" 用户（`v2 reviews 服务` 用户）登录，可以一直看到黑色星标。
@ -94,7 +94,7 @@ Istio 支持基于属性的白名单和黑名单。
以下白名单配置等同于上一节的 `denier` 配置。
此规则能有效地拒绝 `v3` 版本 `reviews` 服务的请求。
1. 移除上一节 denier 配置。
1. 移除上一节 denier 配置。
{{< text bash >}}
$ kubectl delete -f @samples/bookinfo/policy/mixer-rule-deny-label.yaml@
@ -106,10 +106,10 @@ Istio 支持基于属性的白名单和黑名单。
$ kubectl delete -f @samples/bookinfo/policy/mixer-rule-deny-label-crd.yaml@
{{< /text >}}
1. 当您不登录去访问 Bookinfo `productpage` (`http://$GATEWAY_URL/productpage`) 时进行验证，会看到红星。
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@
@ -135,7 +135,7 @@ Istio 支持基于 IP 地址的 _白名单_ 和 _黑名单_ 。
1. 您可以访问位于 `http://$GATEWAY_URL/productpage` 的 Bookinfo `productpage` 来进行验证。
一旦应用以下规则，您将无法访问它。
1. 将配置应用于 [`list`](/zh/docs/reference/config/policy-and-telemetry/adapters/list/) 适配器以添加 ingress 网关中的子网 `"10.57.0.0\16"` 到白名单中：
1. 将配置应用于 [`list`](/zh/docs/reference/config/policy-and-telemetry/adapters/list/) 适配器以添加 ingress 网关中的子网 `"10.57.0.0\16"` 到白名单中：
{{< text bash >}}
$ kubectl apply -f @samples/bookinfo/policy/mixer-rule-deny-ip.yaml@
@ -150,7 +150,7 @@ Istio 支持基于 IP 地址的 _白名单_ 和 _黑名单_ 。
{{< /warning >}}
1. 尝试访问位于 `http://$GATEWAY_URL/productpage` 的 Bookinfo `productpage` 进行验证，
1. 尝试访问位于 `http://$GATEWAY_URL/productpage` 的 Bookinfo `productpage` 进行验证，
您会获得一个类似的错误：`PERMISSION_DENIED:staticversion.istio-system:<your mesh source ip> is not whitelisted`
## 清除{#cleanup}

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

@ -1,6 +1,6 @@
---
title: 启用策略检查功能
description: 这个任务将告诉你如何开启 Istio 的策略检查功能。
title: 启用策略检查功能
description: 这个任务将告诉你如何开启 Istio 的策略检查功能。
weight: 1
keywords: [policies]
---

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

@ -28,7 +28,7 @@ aliases:
您需要指定其中一个版本为默认路由。否则，当您向 `reviews` 服务发送请求时，Istio 会随机路由到其中一个服务上，表现为有时显示星星，有时不会。
1. 将所有服务的默认版本设置为 v1。
1. 将所有服务的默认版本设置为 v1。
{{< text bash >}}
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@
@ -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 页面。
@ -167,11 +167,11 @@ spec:
`memquota` 或 `redisquota` 适配器现在只有请求中存在 `session=<sessionid>` cookie 才会被分发。
这可以确保已登录的用户不会受限于这个 quota。
1. 确认速率限制没有生效于已登录的用户。
1. 确认速率限制没有生效于已登录的用户。
以 `jason` 身份登录且反复刷新 `productpage` 页面。现在这样做不会出现任何问题。
1. 确认速率限制 *生效* 于未登录的用户。
1. 确认速率限制 *生效* 于未登录的用户。
退出登录且反复刷新 `productpage` 页面。
您将会再次看到 `RESOURCE_EXHAUSTED:Quota is exhausted for: requestcount`。

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

@ -669,7 +669,7 @@ $ curl $INGRESS_HOST/user-agent -s -o /dev/null -w "%{http_code}\n"
200
{{< /text >}}
确认不带 JWT tokens 的 `/ip` 路径拒绝访问：
确认不带 JWT tokens 的 `/ip` 路径拒绝访问：
{{< text bash >}}
$ curl $INGRESS_HOST/ip -s -o /dev/null -w "%{http_code}\n"
@ -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` 工作负载访问。

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

@ -22,32 +22,32 @@ aliases:
本教程在一个名为 `rbac-groups-test-ns` 的新命名空间中运行，该命名空间有两个服务，`httpbin` 和 `sleep`，两者都各自附带一个 Envoy sidecar 代理。使用以下命令来设置环境变量以存储命名空间的名称，创建命名空间，并启动这两个服务。
在运行以下命令之前，您需要输入包含 Istio 安装文件的目录。
1. 将 `NS` 环境变量的值设置为 `rbac-listclaim-test-ns`：
1. 将 `NS` 环境变量的值设置为 `rbac-listclaim-test-ns`：
{{< text bash >}}
$ export NS=authz-groups-test-ns
{{< /text >}}
1. 确保 `NS` 环境变量指向一个完全用于测试的命名空间。运行以下命令删除 `NS` 环境变量指向的命名空间中的所有资源。
1. 确保 `NS` 环境变量指向一个完全用于测试的命名空间。运行以下命令删除 `NS` 环境变量指向的命名空间中的所有资源。
{{< text bash >}}
$ kubectl delete namespace $NS
{{< /text >}}
1. 为本教程创建命名空间：
1. 为本教程创建命名空间：
{{< text bash >}}
$ kubectl create ns $NS
{{< /text >}}
1. 创建 `httpbin` 和 `sleep` 服务和部署：
1. 创建 `httpbin` 和 `sleep` 服务和部署：
{{< text bash >}}
$ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@) -n $NS
$ kubectl apply -f <(istioctl kube-inject -f @samples/sleep/sleep.yaml@) -n $NS
{{< /text >}}
1. 要验证 `httpbin` 和 `sleep` 服务是否正在运行并且 `sleep` 能够访问 `httpbin`，请运行以下 curl 命令：
1. 要验证 `httpbin` 和 `sleep` 服务是否正在运行并且 `sleep` 能够访问 `httpbin`，请运行以下 curl 命令：
{{< text bash >}}
$ 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"
@ -58,12 +58,12 @@ 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 声明值可以是字符串或字符串列表；两种类型都支持。
1. 应用认证策略同时需要双向 TLS 和 `httpbin` 服务的 JWT 认证。
1. 应用认证策略同时需要双向 TLS 和 `httpbin` 服务的 JWT 认证。
{{< text bash >}}
$ cat <<EOF | kubectl apply -n $NS -f -
@ -84,7 +84,7 @@ JWT 声明值可以是字符串或字符串列表；两种类型都支持。
EOF
{{< /text >}}
1. 在 `sleep` 中应用 `DestinationRule` 策略以使用双向 TLS 与 `httpbin` 通信。
1. 在 `sleep` 中应用 `DestinationRule` 策略以使用双向 TLS 与 `httpbin` 通信。
{{< text bash >}}
$ cat <<EOF | kubectl apply -n $NS -f -
@ -100,13 +100,13 @@ JWT 声明值可以是字符串或字符串列表；两种类型都支持。
EOF
{{< /text >}}
1. 设置 `TOKEN` 环境变量以包含有效的示例 JWT。
1. 设置 `TOKEN` 环境变量以包含有效的示例 JWT。
{{< text bash >}}
$ TOKEN=$(curl {{< github_file >}}/security/tools/jwt/samples/groups-scope.jwt -s)
{{< /text >}}
1. 连接到 `httpbin` 服务：
1. 连接到 `httpbin` 服务：
{{< text bash >}}
$ 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"
@ -114,7 +114,7 @@ JWT 声明值可以是字符串或字符串列表；两种类型都支持。
当附加的 JWT 有效时，它返回 HTTP 状态码为 200。
1. 当没有附加 JWT 时，验证与 `httpbin` 服务的连接是否失败：
1. 当没有附加 JWT 时，验证与 `httpbin` 服务的连接是否失败：
{{< text bash >}}
$ 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"
@ -127,7 +127,7 @@ JWT 声明值可以是字符串或字符串列表；两种类型都支持。
本节创建一个策略授权来自特定组的请求访问 `httpbin` 服务。
由于缓存和其他传播开销可能会有一些延迟，因此请等待新定义的 RBAC 策略生效。
1. 为命名空间启用 Istio RBAC：
1. 为命名空间启用 Istio RBAC：
{{< text bash >}}
$ cat <<EOF | kubectl apply -n $NS -f -
@ -140,7 +140,7 @@ JWT 声明值可以是字符串或字符串列表；两种类型都支持。
EOF
{{< /text >}}
1. 一旦 RBAC 策略生效，验证 Istio 是否拒绝了与 `httpbin` 服务的 curl 连接：
1. 一旦 RBAC 策略生效，验证 Istio 是否拒绝了与 `httpbin` 服务的 curl 连接：
{{< text bash >}}
$ 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"
@ -148,7 +148,7 @@ JWT 声明值可以是字符串或字符串列表；两种类型都支持。
一旦 RBAC 策略生效，该命令返回 HTTP 状态码为 403。
1. 要提供对 `httpbin` 服务的读访问权，请创建 `httpbin-viewer` 服务角色：
1. 要提供对 `httpbin` 服务的读访问权，请创建 `httpbin-viewer` 服务角色：
{{< text bash >}}
$ cat <<EOF | kubectl apply -n $NS -f -
@ -170,7 +170,7 @@ JWT 声明值可以是字符串或字符串列表；两种类型都支持。
EOF
{{< /text >}}
1. 要将 `httpbin-viewer` 角色分配给 `group1` 中的用户，请创建 `bind-httpbin-viewer` 服务角色绑定。
1. 要将 `httpbin-viewer` 角色分配给 `group1` 中的用户，请创建 `bind-httpbin-viewer` 服务角色绑定。
{{< text bash >}}
$ cat <<EOF | kubectl apply -n $NS -f -
@ -211,13 +211,13 @@ JWT 声明值可以是字符串或字符串列表；两种类型都支持。
等待新定义的 RBAC 策略生效。
1. RBAC 策略生效后，验证与 `httpbin` 服务的连接是否成功：
1. RBAC 策略生效后，验证与 `httpbin` 服务的连接是否成功：
{{< text bash >}}
$ 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}
@ -226,7 +226,7 @@ Istio RBAC 支持配置列表类型声明的授权。
您可以使用 `gen-jwt` [python 脚本]({{<github_file>}}/security/tools/jwt/samples/gen-jwt.py)生成带有其他列表类型声明的 JWT 进行测试。
按照 `gen-jwt` 脚本中的说明使用 `gen-jwt.py` 文件。
1. 要将 `httpbin-viewer` 角色分配给一个附加 JWT 其中包含值为 `scope1` 的列表类型 `scope` 声明的请求，请创建名为 `bind-httpbin-viewer` 的服务角色进行绑定：
1. 要将 `httpbin-viewer` 角色分配给一个附加 JWT 其中包含值为 `scope1` 的列表类型 `scope` 声明的请求，请创建名为 `bind-httpbin-viewer` 的服务角色进行绑定：
{{< text bash >}}
$ cat <<EOF | kubectl apply -n $NS -f -
@ -250,13 +250,13 @@ Istio RBAC 支持配置列表类型声明的授权。
等待新定义的 RBAC 策略生效。
1. RBAC 策略生效后，验证与 `httpbin` 服务的连接是否成功：
1. RBAC 策略生效后，验证与 `httpbin` 服务的连接是否成功：
{{< text bash >}}
$ 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/security/citadel-config/health-check/index.md
View File

@ -1,6 +1,6 @@
---
title: Citadel 的健康检查
description: 如何在 Kubernetes 中启用 Citadel 的健康检查。
description: 如何在 Kubernetes 中启用 Citadel 的健康检查。
weight: 20
keywords: [security,health-check]
aliases:
@ -50,14 +50,14 @@ $ kubectl logs `kubectl get po -n istio-system | grep istio-citadel | awk '{prin
...
- --liveness-probe-path=/tmp/ca.liveness # 存活健康检查状态文件的路径
- --liveness-probe-interval=60s # 存活健康状态文件的更新周期
- --probe-check-interval=15s # 健康检查的周期
- --probe-check-interval=15s # 健康检查的周期
livenessProbe:
exec:
command:
- /usr/local/bin/istio_ca
- probe
- --probe-path=/tmp/ca.liveness # 健康状态文件的路径
- --interval=125s # 文件修改时间和当前系统时钟的最大时间差
- --interval=125s # 文件修改时间和当前系统时钟的最大时间差
initialDelaySeconds: 60
periodSeconds: 60
...

2
content/zh/docs/tasks/security/citadel-config/plugin-ca-cert/index.md
View File

@ -79,7 +79,7 @@ aliases:
而 `/tmp/pod-cert-chain.pem` 这个文件则包含了工作负载证书以及传播到 Pod 中的 CA 证书
1. 检查根证书和运维人员指定的证书是否一致：
1. 检查根证书和运维人员指定的证书是否一致：
{{< text bash >}}
$ openssl x509 -in @samples/certs/root-cert.pem@ -text -noout > /tmp/root-cert.crt.txt

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