diff --git a/content/zh/about/community/join/index.md b/content/zh/about/community/join/index.md index 8de805ad87..885fef5470 100644 --- a/content/zh/about/community/join/index.md +++ b/content/zh/about/community/join/index.md @@ -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" >}} diff --git a/content/zh/about/contribute/build/index.md b/content/zh/about/contribute/build/index.md index af0e757f27..a3caf82bef 100644 --- a/content/zh/about/contribute/build/index.md +++ b/content/zh/about/contribute/build/index.md @@ -57,4 +57,4 @@ $ make lint $ make INTERNAL_ONLY=True lint {{< /text >}} -当修改内容通过所有检查，就可以把修改作为 PR 向仓库提交了。更多信息请访问[如何使用 GitHub](/zh/about/contribute/github)。 \ No newline at end of file +当修改内容通过所有检查，就可以把修改作为 PR 向仓库提交了。更多信息请访问[如何使用 GitHub](/zh/about/contribute/github)。 diff --git a/content/zh/about/contribute/shortcodes/index.md b/content/zh/about/contribute/shortcodes/index.md index 7bc486b289..3e32acca29 100644 --- a/content/zh/about/contribute/shortcodes/index.md +++ b/content/zh/about/contribute/shortcodes/index.md @@ -25,7 +25,7 @@ Hugo 的 shortcode 是具有特定语法的特殊占位符，您可以将其添 */>}} {{< /text >}} -`link` 和 `caption` 字段是必填字段， shortcode 还支持可选字段，例如： +`link` 和 `caption` 字段是必填字段，shortcode 还支持可选字段，例如： {{< text html >}} {{}}/samples/rawvm/README.md) {{< /text >}} -上面的 shortcode 会根据文档当前的目标分支，生成指向 GitHub 中对应分支的链接。要查看当前目标分支的名称，可以使用 `{{}}` shortcode 来获取当前目标分支的名称。 +上面的 shortcode 会根据文档当前的目标分支，生成指向 GitHub 中对应分支的链接。要查看当前目标分支的名称，可以使用 `{{}}` shortcode 来获取当前目标分支的名称。 ## 版本信息{#version-information} @@ -113,7 +113,7 @@ Hugo 的 shortcode 是具有特定语法的特殊占位符，您可以将其添 ## 术语表{#glossary-terms} -当您在页面中介绍一个 Istio 术语时，贡献补充条款要求您将该术语包含在 `glossary` 中，并使用 shortcode `{{}}` 标记它的第一个实例。 shortcode 会对其进行特殊渲染，读者点击该术语，可以在弹出的窗口中获取该术语的定义。例如： +当您在页面中介绍一个 Istio 术语时，贡献补充条款要求您将该术语包含在 `glossary` 中，并使用 shortcode `{{}}` 标记它的第一个实例。shortcode 会对其进行特殊渲染，读者点击该术语，可以在弹出的窗口中获取该术语的定义。例如： {{< text markdown >}} Mixer 使用 {{}}adapters{{}} 与后端进行交互。 @@ -177,7 +177,7 @@ Mixer 使用 {{< gloss adapters >}}适配器{{}} 与后端进行交互 ## 使用样板文本{#use-boilerplate-text} -要想在保持内容单一来源的情况下重用内容，请使用样板 shortcode 。要将样板文本嵌入任何内容文件中，请使用 `boilerplate` shortcode ，如下所示： +要想在保持内容单一来源的情况下重用内容，请使用样板 shortcode 。要将样板文本嵌入任何内容文件中，请使用 `boilerplate` shortcode ，如下所示： {{< text markdown >}} {{}} @@ -197,7 +197,7 @@ Mixer 使用 {{< gloss adapters >}}适配器{{}} 与后端进行交互 - 不同语言的等效代码 - 替代的配置 -要添加选项卡式内容，请组合使用 shortcode `tabset` 和 `tabs`，例如： +要添加选项卡式内容，请组合使用 shortcode `tabset` 和 `tabs`，例如： {{< text markdown >}} {{}} diff --git a/content/zh/about/contribute/terminology/index.md b/content/zh/about/contribute/terminology/index.md index 8a98d8565c..e58c995cab 100644 --- a/content/zh/about/contribute/terminology/index.md +++ b/content/zh/about/contribute/terminology/index.md @@ -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} diff --git a/content/zh/blog/2017/0.1-auth/index.md b/content/zh/blog/2017/0.1-auth/index.md index 231d008367..b7f0ffe001 100644 --- a/content/zh/blog/2017/0.1-auth/index.md +++ b/content/zh/blog/2017/0.1-auth/index.md @@ -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)，为不同的应用技术栈和运行平台上轻松地提供强大的服务安全保障。 diff --git a/content/zh/blog/2017/0.1-canary/index.md b/content/zh/blog/2017/0.1-canary/index.md index fc6c5a9f1b..f8e2818da5 100644 --- a/content/zh/blog/2017/0.1-canary/index.md +++ b/content/zh/blog/2017/0.1-canary/index.md @@ -231,4 +231,4 @@ EOF 支持金丝雀部署的智能路由只是 Istio 的众多功能之一，它将使基于大型微服务的应用程序的生产部署变得更加简单。查看 [istio.io](/zh/) 了解更多信息。 -可在[此处]({{}}/samples/helloworld) 查看示例代码。 +可在[此处]({{}}/samples/helloworld)查看示例代码。 diff --git a/content/zh/blog/2017/0.1-using-network-policy/index.md b/content/zh/blog/2017/0.1-using-network-policy/index.md index 51c4ae39ff..a365190618 100644 --- a/content/zh/blog/2017/0.1-using-network-policy/index.md +++ b/content/zh/blog/2017/0.1-using-network-policy/index.md @@ -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 团队成员之一。 完整系列可以在这里找到： +这篇文章是基于 Spike Curtis 的三部分博客系列，他是 Tigera 的 Istio 团队成员之一。完整系列可以在这里找到： diff --git a/content/zh/blog/2017/adapter-model/index.md b/content/zh/blog/2017/adapter-model/index.md index 16bf23f411..d265d93dcc 100644 --- a/content/zh/blog/2017/adapter-model/index.md +++ b/content/zh/blog/2017/adapter-model/index.md @@ -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/)。你也可以在[这里]({{}}/samples/bookinfo) 找到对应的示例。 +更多信息可以关注[这里](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/)。更多关于 templates, handlers, 和 rules 的内容可以关注[这里](/zh/docs/reference/config/policy-and-telemetry/)。你也可以在[这里]({{}}/samples/bookinfo)找到对应的示例。 diff --git a/content/zh/blog/2018/aws-nlb/index.md b/content/zh/blog/2018/aws-nlb/index.md index dab396f95a..19871b7405 100644 --- a/content/zh/blog/2018/aws-nlb/index.md +++ b/content/zh/blog/2018/aws-nlb/index.md @@ -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" >}} diff --git a/content/zh/blog/2018/delayering-istio/index.md b/content/zh/blog/2018/delayering-istio/index.md index cdf61b9c76..40671f7e0f 100644 --- a/content/zh/blog/2018/delayering-istio/index.md +++ b/content/zh/blog/2018/delayering-istio/index.md @@ -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。 diff --git a/content/zh/blog/2018/egress-https/index.md b/content/zh/blog/2018/egress-https/index.md index 0dae251b92..f948e252a4 100644 --- a/content/zh/blog/2018/egress-https/index.md +++ b/content/zh/blog/2018/egress-https/index.md @@ -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`]({{}}/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 - <}} -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 diff --git a/content/zh/blog/2018/egress-mongo/index.md b/content/zh/blog/2018/egress-mongo/index.md index aed369942f..830e54920b 100644 --- a/content/zh/blog/2018/egress-mongo/index.md +++ b/content/zh/blog/2018/egress-mongo/index.md @@ -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 - <}} -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 <}} $ 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 <}} -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 <}} -1. 修改 `handle-cnn-access` 策略规则并发送 `request-path` 实例到 `path-checker`： +1. 修改 `handle-cnn-access` 策略规则并发送 `request-path` 实例到 `path-checker`： {{< text bash >}} $ cat <}} -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 <}} -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 - diff --git a/content/zh/blog/2018/egress-tcp/index.md b/content/zh/blog/2018/egress-tcp/index.md index 709f64cf00..3e9214c19c 100644 --- a/content/zh/blog/2018/egress-tcp/index.md +++ b/content/zh/blog/2018/egress-tcp/index.md @@ -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 ''; 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 网格外部服务入口。 diff --git a/content/zh/blog/2018/export-logs-through-stackdriver/index.md b/content/zh/blog/2018/export-logs-through-stackdriver/index.md index 8ee97821b1..e0d09d2fd2 100644 --- a/content/zh/blog/2018/export-logs-through-stackdriver/index.md +++ b/content/zh/blog/2018/export-logs-through-stackdriver/index.md @@ -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` 。并替换 `, +1. 保存如下的 yaml 文件为 `stackdriver.yaml` 。并替换 `, , , ` 为相应的值。 {{< text yaml >}} @@ -69,7 +69,7 @@ Istio 支持将日志导出到 Stackdriver，而 Stackdriver 又可以配置为 # pushInterval: 1m # 必须设置 Stacldriver 适配器 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} diff --git a/content/zh/blog/2018/hp/index.md b/content/zh/blog/2018/hp/index.md index e075c7a74c..934474c97c 100644 --- a/content/zh/blog/2018/hp/index.md +++ b/content/zh/blog/2018/hp/index.md @@ -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 的内核安全。 diff --git a/content/zh/blog/2018/soft-multitenancy/index.md b/content/zh/blog/2018/soft-multitenancy/index.md index 07ffecb687..1fa7e8faad 100644 --- a/content/zh/blog/2018/soft-multitenancy/index.md +++ b/content/zh/blog/2018/soft-multitenancy/index.md @@ -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} diff --git a/content/zh/blog/2018/v1alpha3-routing/index.md b/content/zh/blog/2018/v1alpha3-routing/index.md index 2dc122334b..c95e0b4799 100644 --- a/content/zh/blog/2018/v1alpha3-routing/index.md +++ b/content/zh/blog/2018/v1alpha3-routing/index.md @@ -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} diff --git a/content/zh/blog/2019/announcing-discuss.istio.io/index.md b/content/zh/blog/2019/announcing-discuss.istio.io/index.md index c96b6de240..1c7ef8a261 100644 --- a/content/zh/blog/2019/announcing-discuss.istio.io/index.md +++ b/content/zh/blog/2019/announcing-discuss.istio.io/index.md @@ -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 身份进行这些操作。 diff --git a/content/zh/blog/2019/announcing-istio-client-go/index.md b/content/zh/blog/2019/announcing-istio-client-go/index.md index cb97826554..33220132bb 100644 --- a/content/zh/blog/2019/announcing-istio-client-go/index.md +++ b/content/zh/blog/2019/announcing-istio-client-go/index.md @@ -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/{{}}/cmd/example/client.go) 找到更详尽的示例。 +您可以在[这里](https://github.com/istio/client-go/blob/{{}}/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 diff --git a/content/zh/blog/2019/egress-performance/index.md b/content/zh/blog/2019/egress-performance/index.md index f9316b18a7..c1ae049f5e 100644 --- a/content/zh/blog/2019/egress-performance/index.md +++ b/content/zh/blog/2019/egress-performance/index.md @@ -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 字节。 diff --git a/content/zh/blog/2019/egress-traffic-control-in-istio-part-1/index.md b/content/zh/blog/2019/egress-traffic-control-in-istio-part-1/index.md index 503fd7a259..ce3e58d4c3 100644 --- a/content/zh/blog/2019/egress-traffic-control-in-istio-part-1/index.md +++ b/content/zh/blog/2019/egress-traffic-control-in-istio-part-1/index.md @@ -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`）进行标示。只有指定的外部服务可以访问，其它所有的出口流量都要被阻止。 diff --git a/content/zh/blog/2019/egress-traffic-control-in-istio-part-2/index.md b/content/zh/blog/2019/egress-traffic-control-in-istio-part-2/index.md index de340939a8..5950c5394c 100644 --- a/content/zh/blog/2019/egress-traffic-control-in-istio-part-2/index.md +++ b/content/zh/blog/2019/egress-traffic-control-in-istio-part-2/index.md @@ -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 安全架构" >}} diff --git a/content/zh/blog/2019/egress-traffic-control-in-istio-part-3/index.md b/content/zh/blog/2019/egress-traffic-control-in-istio-part-3/index.md index 6923e62c21..a96a2fe7ce 100644 --- a/content/zh/blog/2019/egress-traffic-control-in-istio-part-3/index.md +++ b/content/zh/blog/2019/egress-traffic-control-in-istio-part-3/index.md @@ -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 的出口流量管控提供了以下的优势： diff --git a/content/zh/blog/2019/isolated-clusters/index.md b/content/zh/blog/2019/isolated-clusters/index.md index b44c4f71d8..21b75672bf 100644 --- a/content/zh/blog/2019/isolated-clusters/index.md +++ b/content/zh/blog/2019/isolated-clusters/index.md @@ -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 >}} 部署非常不同，后者定义了一个由跨多个群集的服务组成的单个服务网格。与多网格不同，多群集部署不适用于需要隔离和边界保护的应用程序。 diff --git a/content/zh/blog/2019/knative-activator-adapter/index.md b/content/zh/blog/2019/knative-activator-adapter/index.md index b446084d16..1c397cf663 100644 --- a/content/zh/blog/2019/knative-activator-adapter/index.md +++ b/content/zh/blog/2019/knative-activator-adapter/index.md @@ -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 代理已经处理了这些。 diff --git a/content/zh/blog/2019/monitoring-external-service-traffic/index.md b/content/zh/blog/2019/monitoring-external-service-traffic/index.md index bfdc1acb3d..18e433a4ba 100644 --- a/content/zh/blog/2019/monitoring-external-service-traffic/index.md +++ b/content/zh/blog/2019/monitoring-external-service-traffic/index.md @@ -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 地址， diff --git a/content/zh/blog/2019/multicluster-version-routing/index.md b/content/zh/blog/2019/multicluster-version-routing/index.md index 5fc2463d3b..7211d6270e 100644 --- a/content/zh/blog/2019/multicluster-version-routing/index.md +++ b/content/zh/blog/2019/multicluster-version-routing/index.md @@ -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`，在本文的环境里，无需定义任何路由规则就可以发起对远端集群的请求。 diff --git a/content/zh/blog/2019/proxy/index.md b/content/zh/blog/2019/proxy/index.md index 6c51002ab0..34fa823eb9 100644 --- a/content/zh/blog/2019/proxy/index.md +++ b/content/zh/blog/2019/proxy/index.md @@ -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 - <}} -1. 创建一个服务入口，并且为 `localhost` 服务配置目的规则。在下一步中，需要这个服务入口作为网格内部应用流量到外部服务的目的地，从而隔断来自网格内部的流量。在此例中把 Istio 用作外部应用和外部服务间的代理。 +1. 创建一个服务入口，并且为 `localhost` 服务配置目的规则。在下一步中，需要这个服务入口作为网格内部应用流量到外部服务的目的地，从而隔断来自网格内部的流量。在此例中把 Istio 用作外部应用和外部服务间的代理。 {{< text bash >}} $ kubectl apply -f - <}} -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 - diff --git a/content/zh/blog/2019/webhook/index.md b/content/zh/blog/2019/webhook/index.md index 34677866c5..e17687eaa9 100644 --- a/content/zh/blog/2019/webhook/index.md +++ b/content/zh/blog/2019/webhook/index.md @@ -1,6 +1,6 @@ --- title: 安全管理 Webhook -description: 一种更安全管理 Istio webhook 的方法。 +description: 一种更安全管理 Istio webhook 的方法。 publishdate: 2019-11-14 attribution: Lei Tang (Google) keywords: [security, kubernetes, webhook] diff --git a/content/zh/blog/2020/tradewinds-2020/index.md b/content/zh/blog/2020/tradewinds-2020/index.md index 3131b867af..0dae639ad5 100644 --- a/content/zh/blog/2020/tradewinds-2020/index.md +++ b/content/zh/blog/2020/tradewinds-2020/index.md @@ -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/) 的一部分。 diff --git a/content/zh/blog/2020/wasm-announce/index.md b/content/zh/blog/2020/wasm-announce/index.md index 788e306d44..ac1ca2d74c 100644 --- a/content/zh/blog/2020/wasm-announce/index.md +++ b/content/zh/blog/2020/wasm-announce/index.md @@ -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)上的视频 \ No newline at end of file +- [Solo.io Youtube 频道](https://www.youtube.com/channel/UCuketWAG3WqYjjxtQ9Q8ApQ)上的视频 diff --git a/content/zh/docs/concepts/security/index.md b/content/zh/docs/concepts/security/index.md index d361fda985..85b6fd4417 100644 --- a/content/zh/docs/concepts/security/index.md +++ b/content/zh/docs/concepts/security/index.md @@ -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} diff --git a/content/zh/docs/concepts/traffic-management/index.md b/content/zh/docs/concepts/traffic-management/index.md index 25593bf482..7c66708840 100644 --- a/content/zh/docs/concepts/traffic-management/index.md +++ b/content/zh/docs/concepts/traffic-management/index.md @@ -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 的特性来控制没有在网格中注册的目标流量。 diff --git a/content/zh/docs/examples/bookinfo/index.md b/content/zh/docs/examples/bookinfo/index.md index 5ecae1d50a..bd41fd847b 100755 --- a/content/zh/docs/examples/bookinfo/index.md +++ b/content/zh/docs/examples/bookinfo/index.md @@ -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 ".*" @@ -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 diff --git a/content/zh/docs/examples/microservices-istio/bookinfo-kubernetes/index.md b/content/zh/docs/examples/microservices-istio/bookinfo-kubernetes/index.md index 6a0975e7dd..77b4e8dded 100644 --- a/content/zh/docs/examples/microservices-istio/bookinfo-kubernetes/index.md +++ b/content/zh/docs/examples/microservices-istio/bookinfo-kubernetes/index.md @@ -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 ".*" @@ -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 - <}} $ 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 ".*" Simple Bookstore App {{< /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 ".*"; sleep 1; done diff --git a/content/zh/docs/examples/microservices-istio/package-service/index.md b/content/zh/docs/examples/microservices-istio/package-service/index.md index 50364c07d3..82adeec8cd 100644 --- a/content/zh/docs/examples/microservices-istio/package-service/index.md +++ b/content/zh/docs/examples/microservices-istio/package-service/index.md @@ -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/) 命令，列出所有运行中的容器，同时 注意镜像是 `/ratings` 的容器。 {{< text bash >}} @@ -61,7 +61,7 @@ weight: 20 ... {{< /text >}} -1. 停止运行中的容器： +1. 停止运行中的容器： {{< text bash >}} $ docker stop diff --git a/content/zh/docs/examples/microservices-istio/production-testing/index.md b/content/zh/docs/examples/microservices-istio/production-testing/index.md index 6d770cc1ff..fd947f202d 100644 --- a/content/zh/docs/examples/microservices-istio/production-testing/index.md +++ b/content/zh/docs/examples/microservices-istio/production-testing/index.md @@ -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 diff --git a/content/zh/docs/examples/microservices-istio/setup-kubernetes-cluster/index.md b/content/zh/docs/examples/microservices-istio/setup-kubernetes-cluster/index.md index 6be5335409..47cf3e3453 100644 --- a/content/zh/docs/examples/microservices-istio/setup-kubernetes-cluster/index.md +++ b/content/zh/docs/examples/microservices-istio/setup-kubernetes-cluster/index.md @@ -12,18 +12,18 @@ weight: 2 如果您在培训班且讲师已准备好了集群，直接前往[设置本地机器](/zh/docs/examples/microservices-istio/setup-local-computer)。 {{}} -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 - <}} -1. 为每个参与者创建服务账号： +1. 为每个参与者创建服务账号： {{< text bash >}} $ kubectl apply -f - <}} -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`。 教程中您将会再次用到这个文件。 如果您是讲师，则将生成的配置文件发送给每个学员。学员必须将该配置文件复制到自己本地的计算机。 diff --git a/content/zh/docs/examples/microservices-istio/setup-local-computer/index.md b/content/zh/docs/examples/microservices-istio/setup-local-computer/index.md index 9cc2267443..2fc47e40c6 100644 --- a/content/zh/docs/examples/microservices-istio/setup-local-computer/index.md +++ b/content/zh/docs/examples/microservices-istio/setup-local-computer/index.md @@ -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 diff --git a/content/zh/docs/examples/microservices-istio/single/index.md b/content/zh/docs/examples/microservices-istio/single/index.md index 6d900ecb25..dfca3cd8db 100644 --- a/content/zh/docs/examples/microservices-istio/single/index.md +++ b/content/zh/docs/examples/microservices-istio/single/index.md @@ -28,7 +28,7 @@ weight: 10 请按照下列步骤下载应用程序的代码，安装其依赖项，然后在本地运行它： -1. 将[服务代码]({{}}/samples/bookinfo/src/ratings/ratings.js) 和 +1. 将[服务代码]({{}}/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 diff --git a/content/zh/docs/examples/virtual-machines/multi-network/index.md b/content/zh/docs/examples/virtual-machines/multi-network/index.md index 3aa82a3b14..639176a7cf 100644 --- a/content/zh/docs/examples/virtual-machines/multi-network/index.md +++ b/content/zh/docs/examples/virtual-machines/multi-network/index.md @@ -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 diff --git a/content/zh/docs/examples/virtual-machines/single-network/index.md b/content/zh/docs/examples/virtual-machines/single-network/index.md index a01f830351..34442be7e2 100644 --- a/content/zh/docs/examples/virtual-machines/single-network/index.md +++ b/content/zh/docs/examples/virtual-machines/single-network/index.md @@ -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 >}} diff --git a/content/zh/docs/ops/common-problems/injection/index.md b/content/zh/docs/ops/common-problems/injection/index.md index 9cbe3f053e..73b34fb290 100644 --- a/content/zh/docs/ops/common-problems/injection/index.md +++ b/content/zh/docs/ops/common-problems/injection/index.md @@ -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) 解决。 diff --git a/content/zh/docs/ops/common-problems/network-issues/index.md b/content/zh/docs/ops/common-problems/network-issues/index.md index e973359cb6..d47082732d 100644 --- a/content/zh/docs/ops/common-problems/network-issues/index.md +++ b/content/zh/docs/ops/common-problems/network-issues/index.md @@ -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 规则配置： diff --git a/content/zh/docs/ops/common-problems/observability-issues/index.md b/content/zh/docs/ops/common-problems/observability-issues/index.md index f382a13afa..1eee4e9a76 100644 --- a/content/zh/docs/ops/common-problems/observability-issues/index.md +++ b/content/zh/docs/ops/common-problems/observability-issues/index.md @@ -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} diff --git a/content/zh/docs/ops/common-problems/validation/index.md b/content/zh/docs/ops/common-problems/validation/index.md index 9e7f9e6289..e049ec8c43 100644 --- a/content/zh/docs/ops/common-problems/validation/index.md +++ b/content/zh/docs/ops/common-problems/validation/index.md @@ -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` 的错误信息。 diff --git a/content/zh/docs/ops/configuration/mesh/app-health-check/index.md b/content/zh/docs/ops/configuration/mesh/app-health-check/index.md index b4d0849a96..1a5947ffea 100644 --- a/content/zh/docs/ops/configuration/mesh/app-health-check/index.md +++ b/content/zh/docs/ops/configuration/mesh/app-health-check/index.md @@ -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 -与安装 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} diff --git a/content/zh/docs/ops/configuration/mesh/webhook/index.md b/content/zh/docs/ops/configuration/mesh/webhook/index.md index af487b9170..ebe4f6ea6c 100644 --- a/content/zh/docs/ops/configuration/mesh/webhook/index.md +++ b/content/zh/docs/ops/configuration/mesh/webhook/index.md @@ -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。 diff --git a/content/zh/docs/ops/configuration/telemetry/envoy-stats/index.md b/content/zh/docs/ops/configuration/telemetry/envoy-stats/index.md index 52584dfe98..9c83bae539 100644 --- a/content/zh/docs/ops/configuration/telemetry/envoy-stats/index.md +++ b/content/zh/docs/ops/configuration/telemetry/envoy-stats/index.md @@ -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` 前缀。 diff --git a/content/zh/docs/ops/deployment/deployment-models/index.md b/content/zh/docs/ops/deployment/deployment-models/index.md index 7569184558..daca0a9bc3 100644 --- a/content/zh/docs/ops/deployment/deployment-models/index.md +++ b/content/zh/docs/ops/deployment/deployment-models/index.md @@ -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} diff --git a/content/zh/docs/ops/deployment/requirements/index.md b/content/zh/docs/ops/deployment/requirements/index.md index 30f5891fe6..44a981ea81 100644 --- a/content/zh/docs/ops/deployment/requirements/index.md +++ b/content/zh/docs/ops/deployment/requirements/index.md @@ -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 用于在分布式追踪中添加上下文信息。 diff --git a/content/zh/docs/ops/diagnostic-tools/component-logging/index.md b/content/zh/docs/ops/diagnostic-tools/component-logging/index.md index 98681bed31..d6b03bad29 100644 --- a/content/zh/docs/ops/diagnostic-tools/component-logging/index.md +++ b/content/zh/docs/ops/diagnostic-tools/component-logging/index.md @@ -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} diff --git a/content/zh/docs/ops/diagnostic-tools/istioctl-analyze/index.md b/content/zh/docs/ops/diagnostic-tools/istioctl-analyze/index.md index b80db4a077..7a7211dfd2 100644 --- a/content/zh/docs/ops/diagnostic-tools/istioctl-analyze/index.md +++ b/content/zh/docs/ops/diagnostic-tools/istioctl-analyze/index.md @@ -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} diff --git a/content/zh/docs/ops/diagnostic-tools/proxy-cmd/index.md b/content/zh/docs/ops/diagnostic-tools/proxy-cmd/index.md index 5a6c2294d9..8a5be08c2e 100644 --- a/content/zh/docs/ops/diagnostic-tools/proxy-cmd/index.md +++ b/content/zh/docs/ops/diagnostic-tools/proxy-cmd/index.md @@ -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 diff --git a/content/zh/docs/reference/config/analysis/_index.md b/content/zh/docs/reference/config/analysis/_index.md index 5e7517780c..886cebd6a4 100644 --- a/content/zh/docs/reference/config/analysis/_index.md +++ b/content/zh/docs/reference/config/analysis/_index.md @@ -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 配置状态的丰富分析，以便标识无效或次优的配置。这是此分析可能产生的错误或警告消息的列表。 diff --git a/content/zh/docs/reference/config/policy-and-telemetry/attribute-vocabulary/index.md b/content/zh/docs/reference/config/policy-and-telemetry/attribute-vocabulary/index.md index f5bfe98995..7a9480c1c3 100644 --- a/content/zh/docs/reference/config/policy-and-telemetry/attribute-vocabulary/index.md +++ b/content/zh/docs/reference/config/policy-and-telemetry/attribute-vocabulary/index.md @@ -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")`。 持续时间属性表示时间量，表示为一系列十进制数，其中可选的小数部分用句点表示，以及单位值。 diff --git a/content/zh/docs/reference/config/policy-and-telemetry/expression-language/index.md b/content/zh/docs/reference/config/policy-and-telemetry/expression-language/index.md index ea03e39009..e147cd1549 100644 --- a/content/zh/docs/reference/config/policy-and-telemetry/expression-language/index.md +++ b/content/zh/docs/reference/config/policy-and-telemetry/expression-language/index.md @@ -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/{{}}/policy/v1beta1/value_type.proto) 映射了一组带类型的[属性](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes)和常量。 +CEXL 表达式为有类型的[值](https://github.com/istio/api/blob/{{}}/policy/v1beta1/value_type.proto)映射了一组带类型的[属性](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes)和常量。 ## 语法{#syntax} diff --git a/content/zh/docs/reference/config/policy-and-telemetry/metrics/index.md b/content/zh/docs/reference/config/policy-and-telemetry/metrics/index.md index 1de36153bf..60cf7abe68 100644 --- a/content/zh/docs/reference/config/policy-and-telemetry/metrics/index.md +++ b/content/zh/docs/reference/config/policy-and-telemetry/metrics/index.md @@ -4,7 +4,7 @@ description: 通过 Mixer 从 Istio 导出的默认监控指标。 weight: 50 --- -此页面展示使用初始配置时，Istio 收集的监控指标（metrics）的详细信息。这些指标是内置的，但您可以随时通过更改配置来添加和删除它们。您可以在[这个文件]({{}}/manifests/UPDATING-CHARTS.md) 的 "kind: metric” 小节中找到它们。它使用了 [metric 模板](/zh/docs/reference/config/policy-and-telemetry/templates/metric/)来定义指标。 +此页面展示使用初始配置时，Istio 收集的监控指标（metrics）的详细信息。这些指标是内置的，但您可以随时通过更改配置来添加和删除它们。您可以在[这个文件]({{}}/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 | "-" diff --git a/content/zh/docs/reference/config/policy-and-telemetry/mixer-overview/index.md b/content/zh/docs/reference/config/policy-and-telemetry/mixer-overview/index.md index f0827ebac2..9866b1572d 100644 --- a/content/zh/docs/reference/config/policy-and-telemetry/mixer-overview/index.md +++ b/content/zh/docs/reference/config/policy-and-telemetry/mixer-overview/index.md @@ -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/)页面。 diff --git a/content/zh/docs/reference/config/security/constraints-and-properties/index.md b/content/zh/docs/reference/config/security/constraints-and-properties/index.md index d2ba65fb0d..1793ca63a6 100644 --- a/content/zh/docs/reference/config/security/constraints-and-properties/index.md +++ b/content/zh/docs/reference/config/security/constraints-and-properties/index.md @@ -7,7 +7,7 @@ aliases: --- {{< warning >}} -RBAC 策略中的约束和属性已经被 `AuthorizationPolicy` 中的条件取代。 请使用 `AuthorizationPolicy` 资源中的条件，此页面仅供参考，以后将被删除。 +RBAC 策略中的约束和属性已经被 `AuthorizationPolicy` 中的条件取代。请使用 `AuthorizationPolicy` 资源中的条件，此页面仅供参考，以后将被删除。 {{< /warning >}} 本节包含支持格式化的键和值，你可以将其用作于服务角色和服务角色绑定配置对象中的约束和属性。约束和属性是额外的条件，你可以指定配置对象 `kind:` 字段的值为 `ServiceRole` 或 `ServiceRoleBinding`，以指定详细的访问控制要求。 diff --git a/content/zh/docs/reference/config/telemetry/configurable_metrics/index.md b/content/zh/docs/reference/config/telemetry/configurable_metrics/index.md index fd5596679c..49d4cf7d61 100644 --- a/content/zh/docs/reference/config/telemetry/configurable_metrics/index.md +++ b/content/zh/docs/reference/config/telemetry/configurable_metrics/index.md @@ -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 中肯定会发生更改。 diff --git a/content/zh/docs/reference/config/telemetry/metrics/index.md b/content/zh/docs/reference/config/telemetry/metrics/index.md index 56f7804a10..71c5b49b31 100644 --- a/content/zh/docs/reference/config/telemetry/metrics/index.md +++ b/content/zh/docs/reference/config/telemetry/metrics/index.md @@ -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 | "-" diff --git a/content/zh/docs/reference/glossary/multicluster.md b/content/zh/docs/reference/glossary/multicluster.md index 8b39c184d1..8f0dd7e2d9 100644 --- a/content/zh/docs/reference/glossary/multicluster.md +++ b/content/zh/docs/reference/glossary/multicluster.md @@ -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)组成。 diff --git a/content/zh/docs/setup/additional-setup/sidecar-injection/index.md b/content/zh/docs/setup/additional-setup/sidecar-injection/index.md index 859eaf4818..5f6bd732bf 100644 --- a/content/zh/docs/setup/additional-setup/sidecar-injection/index.md +++ b/content/zh/docs/setup/additional-setup/sidecar-injection/index.md @@ -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。模版可以使用这些数据有条件地定义被注入的卷和容器。 例如下面的模版。 diff --git a/content/zh/docs/setup/getting-started/index.md b/content/zh/docs/setup/getting-started/index.md index 4c98396884..b2b715d298 100644 --- a/content/zh/docs/setup/getting-started/index.md +++ b/content/zh/docs/setup/getting-started/index.md @@ -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 diff --git a/content/zh/docs/setup/install/helm/index.md b/content/zh/docs/setup/install/helm/index.md index 6bc5c13780..85e6dd1555 100644 --- a/content/zh/docs/setup/install/helm/index.md +++ b/content/zh/docs/setup/install/helm/index.md @@ -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} diff --git a/content/zh/docs/setup/install/istioctl/index.md b/content/zh/docs/setup/install/istioctl/index.md index a673a80c1b..6dd99ab7a1 100644 --- a/content/zh/docs/setup/install/istioctl/index.md +++ b/content/zh/docs/setup/install/istioctl/index.md @@ -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} diff --git a/content/zh/docs/setup/install/multicluster/gateways/index.md b/content/zh/docs/setup/install/multicluster/gateways/index.md index 8b64e0c0af..fcc3434494 100644 --- a/content/zh/docs/setup/install/multicluster/gateways/index.md +++ b/content/zh/docs/setup/install/multicluster/gateways/index.md @@ -88,7 +88,7 @@ Istio 本身不会为两个服务之间的请求使用 DNS。集群本地的服 要为远端集群的服务提供类似的配置，远端集群内的服务需要以 `..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 应该采用如下格式：`..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 流量。 diff --git a/content/zh/docs/setup/install/multicluster/shared-gateways/index.md b/content/zh/docs/setup/install/multicluster/shared-gateways/index.md index 4acf9d1ab5..13b10a51a4 100644 --- a/content/zh/docs/setup/install/multicluster/shared-gateways/index.md +++ b/content/zh/docs/setup/install/multicluster/shared-gateways/index.md @@ -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 diff --git a/content/zh/docs/setup/install/multicluster/simplified/index.md b/content/zh/docs/setup/install/multicluster/simplified/index.md index 77b8646220..12f1d5be3c 100644 --- a/content/zh/docs/setup/install/multicluster/simplified/index.md +++ b/content/zh/docs/setup/install/multicluster/simplified/index.md @@ -78,7 +78,7 @@ keywords: [kubernetes,multicluster] $ cd ${WORKDIR} {{< /text >}} -1. 下载[设置脚本]({{}}/samples/multicluster/setup-mesh.sh) 到您的工作目录。 +1. 下载[设置脚本]({{}}/samples/multicluster/setup-mesh.sh)到您的工作目录。 该脚本负责创建必要的证书以启用跨集群通信，它为您准备了默认配置文件，并将在每个集群中部署和配置 Istio。 1. 最后，运行下载的脚本以准备网格。这会创建一个将用于保护网格中群集之间的通信安全的根密钥和证书，以及用于控制所有群集上部署的 Istio 的配置的 `base.yaml` 文件： diff --git a/content/zh/docs/setup/platform-setup/MicroK8s/index.md b/content/zh/docs/setup/platform-setup/MicroK8s/index.md index 9c54880dca..8162b9513a 100644 --- a/content/zh/docs/setup/platform-setup/MicroK8s/index.md +++ b/content/zh/docs/setup/platform-setup/MicroK8s/index.md @@ -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。 请运行以下命令来检查部署进度： diff --git a/content/zh/docs/setup/platform-setup/gardener/index.md b/content/zh/docs/setup/platform-setup/gardener/index.md index 94259e4ad6..d6bc4b950d 100644 --- a/content/zh/docs/setup/platform-setup/gardener/index.md +++ b/content/zh/docs/setup/platform-setup/gardener/index.md @@ -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-` 的 Kubernetes 命名空间。 +1. 在 Gardener 仪表板中创建一个项目。这实际上将创建一个名为 `garden-` 的 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 >}} diff --git a/content/zh/docs/setup/platform-setup/gke/index.md b/content/zh/docs/setup/platform-setup/gke/index.md index a1d2df9f35..02e1c8ae84 100644 --- a/content/zh/docs/setup/platform-setup/gke/index.md +++ b/content/zh/docs/setup/platform-setup/gke/index.md @@ -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 >}} diff --git a/content/zh/docs/setup/platform-setup/ibm/index.md b/content/zh/docs/setup/platform-setup/ibm/index.md index c50b031fab..201e8b150e 100644 --- a/content/zh/docs/setup/platform-setup/ibm/index.md +++ b/content/zh/docs/setup/platform-setup/ibm/index.md @@ -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 集群。 将 `` 替换为您用于集群的名称，将 `` 替换为可用区。 {{< tip >}} @@ -42,7 +42,7 @@ IBM 为 IBM Cloud Kubernetes Service 提供了 {{< gloss >}}managed control plan 否则, 将自动为您创建。您可以通过运行 `ibmcloud ks vlans --zone ` 来查看可用的 VLAN。 {{< /tip >}} -1. 运行以下命令下载您的 `kubectl` 集群配置，然后按照命令输出的说明来设置 `KUBECONFIG` 环境变量。 +1. 运行以下命令下载您的 `kubectl` 集群配置，然后按照命令输出的说明来设置 `KUBECONFIG` 环境变量。 {{< text bash >}} $ ibmcloud ks cluster-config diff --git a/content/zh/docs/setup/platform-setup/kind/index.md b/content/zh/docs/setup/platform-setup/kind/index.md index 424af6e8fb..4cb7d479d4 100644 --- a/content/zh/docs/setup/platform-setup/kind/index.md +++ b/content/zh/docs/setup/platform-setup/kind/index.md @@ -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 diff --git a/content/zh/docs/setup/platform-setup/minikube/index.md b/content/zh/docs/setup/platform-setup/minikube/index.md index f31eb32bbc..06a3a6a834 100644 --- a/content/zh/docs/setup/platform-setup/minikube/index.md +++ b/content/zh/docs/setup/platform-setup/minikube/index.md @@ -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 会阻塞的你的终端用于显示网络诊断信息： diff --git a/content/zh/docs/setup/platform-setup/openshift/index.md b/content/zh/docs/setup/platform-setup/openshift/index.md index e9fbb7146c..13b1439db9 100644 --- a/content/zh/docs/setup/platform-setup/openshift/index.md +++ b/content/zh/docs/setup/platform-setup/openshift/index.md @@ -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 >}} diff --git a/content/zh/docs/setup/upgrade/cni-helm-upgrade/index.md b/content/zh/docs/setup/upgrade/cni-helm-upgrade/index.md index 4b270bde52..62180c830d 100644 --- a/content/zh/docs/setup/upgrade/cni-helm-upgrade/index.md +++ b/content/zh/docs/setup/upgrade/cni-helm-upgrade/index.md @@ -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 diff --git a/content/zh/docs/tasks/observability/distributed-tracing/lightstep/index.md b/content/zh/docs/tasks/observability/distributed-tracing/lightstep/index.md index 581aac662d..b3f8d7b6cb 100644 --- a/content/zh/docs/tasks/observability/distributed-tracing/lightstep/index.md +++ b/content/zh/docs/tasks/observability/distributed-tracing/lightstep/index.md @@ -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 用户，确保你可以使用 `:` 格式的地址访问 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=""` @@ -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" >}} diff --git a/content/zh/docs/tasks/observability/distributed-tracing/overview/index.md b/content/zh/docs/tasks/observability/distributed-tracing/overview/index.md index 9808addf08..199378e13a 100644 --- a/content/zh/docs/tasks/observability/distributed-tracing/overview/index.md +++ b/content/zh/docs/tasks/observability/distributed-tracing/overview/index.md @@ -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): diff --git a/content/zh/docs/tasks/observability/distributed-tracing/zipkin/index.md b/content/zh/docs/tasks/observability/distributed-tracing/zipkin/index.md index 22d42e91d7..28be99d2ec 100644 --- a/content/zh/docs/tasks/observability/distributed-tracing/zipkin/index.md +++ b/content/zh/docs/tasks/observability/distributed-tracing/zipkin/index.md @@ -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)说明 关闭应用程序。 diff --git a/content/zh/docs/tasks/observability/kiali/index.md b/content/zh/docs/tasks/observability/kiali/index.md index 3986c8be5e..36e0073a56 100644 --- a/content/zh/docs/tasks/observability/kiali/index.md +++ b/content/zh/docs/tasks/observability/kiali/index.md @@ -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} diff --git a/content/zh/docs/tasks/observability/logs/access-log/index.md b/content/zh/docs/tasks/observability/logs/access-log/index.md index f2ac5ade86..990400d8cc 100644 --- a/content/zh/docs/tasks/observability/logs/access-log/index.md +++ b/content/zh/docs/tasks/observability/logs/access-log/index.md @@ -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 diff --git a/content/zh/docs/tasks/observability/logs/collecting-logs/index.md b/content/zh/docs/tasks/observability/logs/collecting-logs/index.md index 47de7da052..bb49fae436 100644 --- a/content/zh/docs/tasks/observability/logs/collecting-logs/index.md +++ b/content/zh/docs/tasks/observability/logs/collecting-logs/index.md @@ -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 的日志信息，如下所示： diff --git a/content/zh/docs/tasks/observability/logs/fluentd/index.md b/content/zh/docs/tasks/observability/logs/fluentd/index.md index 20e7c8e00d..64080236a5 100644 --- a/content/zh/docs/tasks/observability/logs/fluentd/index.md +++ b/content/zh/docs/tasks/observability/logs/fluentd/index.md @@ -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 & diff --git a/content/zh/docs/tasks/observability/metrics/collecting-metrics/index.md b/content/zh/docs/tasks/observability/metrics/collecting-metrics/index.md index 3b8a8e8894..769b7ea0f0 100644 --- a/content/zh/docs/tasks/observability/metrics/collecting-metrics/index.md +++ b/content/zh/docs/tasks/observability/metrics/collecting-metrics/index.md @@ -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 设置端口转发： diff --git a/content/zh/docs/tasks/observability/metrics/querying-metrics/index.md b/content/zh/docs/tasks/observability/metrics/querying-metrics/index.md index 432e85e8ec..d59cd31859 100644 --- a/content/zh/docs/tasks/observability/metrics/querying-metrics/index.md +++ b/content/zh/docs/tasks/observability/metrics/querying-metrics/index.md @@ -18,7 +18,7 @@ aliases: ## 查询 Istio 度量指标{#query-mesh-metrics} -1. 验证自身集群中运行着 `prometheus` 服务。 +1. 验证自身集群中运行着 `prometheus` 服务。 在 Kubernetes 环境中，执行如下命令： @@ -28,7 +28,7 @@ aliases: prometheus 10.59.241.54 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) 命令关闭应用。 diff --git a/content/zh/docs/tasks/observability/metrics/tcp-metrics/index.md b/content/zh/docs/tasks/observability/metrics/tcp-metrics/index.md index 7c0140b963..6dfc52378f 100644 --- a/content/zh/docs/tasks/observability/metrics/tcp-metrics/index.md +++ b/content/zh/docs/tasks/observability/metrics/tcp-metrics/index.md @@ -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@ diff --git a/content/zh/docs/tasks/observability/metrics/using-istio-dashboard/index.md b/content/zh/docs/tasks/observability/metrics/using-istio-dashboard/index.md index 03a10294a4..b656f8d7a3 100644 --- a/content/zh/docs/tasks/observability/metrics/using-istio-dashboard/index.md +++ b/content/zh/docs/tasks/observability/metrics/using-istio-dashboard/index.md @@ -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 9090/TCP 2m {{< /text >}} -1. 验证 Grafana 服务正在集群中运行。 +1. 验证 Grafana 服务正在集群中运行。 在 Kubernetes 环境中，执行以下命令： @@ -39,7 +39,7 @@ aliases: grafana 10.59.247.103 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)。 diff --git a/content/zh/docs/tasks/policy-enforcement/denial-and-list/index.md b/content/zh/docs/tasks/policy-enforcement/denial-and-list/index.md index f466e0003a..9721be2ecf 100644 --- a/content/zh/docs/tasks/policy-enforcement/denial-and-list/index.md +++ b/content/zh/docs/tasks/policy-enforcement/denial-and-list/index.md @@ -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: is not whitelisted` ## 清除{#cleanup} diff --git a/content/zh/docs/tasks/policy-enforcement/enabling-policy/index.md b/content/zh/docs/tasks/policy-enforcement/enabling-policy/index.md index 8e158f04b5..eb840499ac 100644 --- a/content/zh/docs/tasks/policy-enforcement/enabling-policy/index.md +++ b/content/zh/docs/tasks/policy-enforcement/enabling-policy/index.md @@ -1,6 +1,6 @@ --- -title: 启用策略检查功能 -description: 这个任务将告诉你如何开启 Istio 的策略检查功能。 +title: 启用策略检查功能 +description: 这个任务将告诉你如何开启 Istio 的策略检查功能。 weight: 1 keywords: [policies] --- diff --git a/content/zh/docs/tasks/policy-enforcement/rate-limiting/index.md b/content/zh/docs/tasks/policy-enforcement/rate-limiting/index.md index 346b200bd2..80e50c26d1 100644 --- a/content/zh/docs/tasks/policy-enforcement/rate-limiting/index.md +++ b/content/zh/docs/tasks/policy-enforcement/rate-limiting/index.md @@ -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=` cookie 才会被分发。 这可以确保已登录的用户不会受限于这个 quota。 -1. 确认速率限制没有生效于已登录的用户。 +1. 确认速率限制没有生效于已登录的用户。 以 `jason` 身份登录且反复刷新 `productpage` 页面。现在这样做不会出现任何问题。 -1. 确认速率限制 *生效* 于未登录的用户。 +1. 确认速率限制 *生效* 于未登录的用户。 退出登录且反复刷新 `productpage` 页面。 您将会再次看到 `RESOURCE_EXHAUSTED:Quota is exhausted for: requestcount`。 diff --git a/content/zh/docs/tasks/security/authentication/authn-policy/index.md b/content/zh/docs/tasks/security/authentication/authn-policy/index.md index 0d6d635dfa..c0f03250ee 100644 --- a/content/zh/docs/tasks/security/authentication/authn-policy/index.md +++ b/content/zh/docs/tasks/security/authentication/authn-policy/index.md @@ -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) diff --git a/content/zh/docs/tasks/security/authentication/mtls-migration/index.md b/content/zh/docs/tasks/security/authentication/mtls-migration/index.md index 0dea9c5d79..ce5fe67c02 100644 --- a/content/zh/docs/tasks/security/authentication/mtls-migration/index.md +++ b/content/zh/docs/tasks/security/authentication/mtls-migration/index.md @@ -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 diff --git a/content/zh/docs/tasks/security/authorization/authz-http/index.md b/content/zh/docs/tasks/security/authorization/authz-http/index.md index 0cbb3a48dc..76a107d739 100644 --- a/content/zh/docs/tasks/security/authorization/authz-http/index.md +++ b/content/zh/docs/tasks/security/authorization/authz-http/index.md @@ -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` 工作负载访问。 diff --git a/content/zh/docs/tasks/security/authorization/rbac-groups/index.md b/content/zh/docs/tasks/security/authorization/rbac-groups/index.md index 37eb479da4..26056b20f6 100644 --- a/content/zh/docs/tasks/security/authorization/rbac-groups/index.md +++ b/content/zh/docs/tasks/security/authorization/rbac-groups/index.md @@ -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 端点]({{}}/security/tools/jwt/samples/jwks.json) 并使用[此示例 JWT]({{< github_file >}}/security/tools/jwt/samples/groups-scope.jwt)。 +策略中定义的 JSON Web 密钥集（JWKS ）端点必须对 JWT 进行签名。 +本教程使用 Istio 代码库中的 [JWKS 端点]({{}}/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 <}} -1. 在 `sleep` 中应用 `DestinationRule` 策略以使用双向 TLS 与 `httpbin` 通信。 +1. 在 `sleep` 中应用 `DestinationRule` 策略以使用双向 TLS 与 `httpbin` 通信。 {{< text bash >}} $ cat <}} -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 <}} -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 <}} -1. 要将 `httpbin-viewer` 角色分配给 `group1` 中的用户，请创建 `bind-httpbin-viewer` 服务角色绑定。 +1. 要将 `httpbin-viewer` 角色分配给 `group1` 中的用户，请创建 `bind-httpbin-viewer` 服务角色绑定。 {{< text bash >}} $ cat <}} $ 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 脚本]({{}}/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 <}} $ 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} diff --git a/content/zh/docs/tasks/security/citadel-config/auth-sds/index.md b/content/zh/docs/tasks/security/citadel-config/auth-sds/index.md index 284d6d4fe7..198446b65e 100644 --- a/content/zh/docs/tasks/security/citadel-config/auth-sds/index.md +++ b/content/zh/docs/tasks/security/citadel-config/auth-sds/index.md @@ -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 <}} $ openssl x509 -in @samples/certs/root-cert.pem@ -text -noout > /tmp/root-cert.crt.txt diff --git a/content/zh/docs/tasks/traffic-management/circuit-breaking/index.md b/content/zh/docs/tasks/traffic-management/circuit-breaking/index.md index 1596b0dcb7..1fb62a5f33 100644 --- a/content/zh/docs/tasks/traffic-management/circuit-breaking/index.md +++ b/content/zh/docs/tasks/traffic-management/circuit-breaking/index.md @@ -52,7 +52,7 @@ keywords: [traffic-management,circuit-breaking] EOF {{< /text >}} -1. 验证目标规则是否已正确创建： +1. 验证目标规则是否已正确创建： {{< text bash yaml >}} $ kubectl get destinationrule httpbin -o yaml @@ -230,13 +230,13 @@ keywords: [traffic-management,circuit-breaking] ## 清理{#cleaning-up} -1. 清理规则: +1. 清理规则: {{< text bash >}} $ kubectl delete destinationrule httpbin {{< /text >}} -1. 下线 [httpbin]({{< github_tree >}}/samples/httpbin) 服务和客户端： +1. 下线 [httpbin]({{< github_tree >}}/samples/httpbin) 服务和客户端： {{< text bash >}} $ kubectl delete deploy httpbin fortio-deploy diff --git a/content/zh/docs/tasks/traffic-management/egress/egress-control/index.md b/content/zh/docs/tasks/traffic-management/egress/egress-control/index.md index 965f7ec401..3573630a32 100644 --- a/content/zh/docs/tasks/traffic-management/egress/egress-control/index.md +++ b/content/zh/docs/tasks/traffic-management/egress/egress-control/index.md @@ -150,7 +150,7 @@ Istio 有一个[安装选项](/zh/docs/reference/config/installation-options/) 注意由 Istio sidecar 代理添加的 headers: `X-Envoy-Decorator-Operation`。 -1. 检查 `SOURCE_POD` 的 sidecar 代理的日志: +1. 检查 `SOURCE_POD` 的 sidecar 代理的日志: {{< text bash >}} $ kubectl logs $SOURCE_POD -c istio-proxy | tail @@ -170,7 +170,7 @@ Istio 有一个[安装选项](/zh/docs/reference/config/installation-options/) ### 访问外部 HTTPS 服务{#access-an-external-https-service} -1. 创建一个 `ServiceEntry`，允许对外部服务的访问。 +1. 创建一个 `ServiceEntry`，允许对外部服务的访问。 {{< text bash >}} $ kubectl apply -f - <}} -1. 从 `SOURCE_POD` 往外部 HTTPS 服务发送请求： +1. 从 `SOURCE_POD` 往外部 HTTPS 服务发送请求： {{< text bash >}} $ kubectl exec -it $SOURCE_POD -c sleep -- curl -I https://www.google.com | grep "HTTP/" HTTP/2 200 {{< /text >}} -1. 检查 `SOURCE_POD` 的 sidecar 代理的日志： +1. 检查 `SOURCE_POD` 的 sidecar 代理的日志： {{< text bash >}} $ kubectl logs $SOURCE_POD -c istio-proxy | tail @@ -206,7 +206,7 @@ Istio 有一个[安装选项](/zh/docs/reference/config/installation-options/) 请注意与您对 `www.google.com` 的 HTTPS 请求相关的条目。 -1. 检查 Mixer 日志。如果 Istio 部署的命名空间是 `istio-system`，那么打印日志的命令如下： +1. 检查 Mixer 日志。如果 Istio 部署的命名空间是 `istio-system`，那么打印日志的命令如下： {{< text bash >}} $ kubectl -n istio-system logs -l istio-mixer-type=telemetry -c mixer | grep 'www.google.com' @@ -219,7 +219,7 @@ Istio 有一个[安装选项](/zh/docs/reference/config/installation-options/) 与集群内的请求相似，也可以为使用 `ServiceEntry` 配置访问的外部服务设置 [Istio 路由规则](/zh/docs/concepts/traffic-management/#routing-rules)。在本示例中，你将设置对 `httpbin.org` 服务访问的超时规则。 -1. 从用作测试源的 pod 内部，向外部服务 `httpbin.org` 的 `/delay` endpoint 发出 _curl_ 请求： +1. 从用作测试源的 pod 内部，向外部服务 `httpbin.org` 的 `/delay` endpoint 发出 _curl_ 请求： {{< text bash >}} $ kubectl exec -it $SOURCE_POD -c sleep sh @@ -233,7 +233,7 @@ Istio 有一个[安装选项](/zh/docs/reference/config/installation-options/) 这个请求大约在 5 秒内返回 200 (OK)。 -1. 退出测试源 pod，使用 `kubectl` 设置调用外部服务 `httpbin.org` 的超时时间为 3 秒。 +1. 退出测试源 pod，使用 `kubectl` 设置调用外部服务 `httpbin.org` 的超时时间为 3 秒。 {{< text bash >}} $ kubectl apply -f - <}} -1. 几秒后，重新发出 _curl_ 请求： +1. 几秒后，重新发出 _curl_ 请求： {{< text bash >}} $ kubectl exec -it $SOURCE_POD -c sleep sh @@ -276,7 +276,7 @@ $ kubectl delete virtualservice httpbin-ext --ignore-not-found=true ## 直接访问外部服务{#direct-access-to-external-services} -如果要让特定范围的 ​​IP 完全绕过 Istio，则可以配置 Envoy sidecars 以防止它们[拦截](/zh/docs/concepts/traffic-management/)外部请求。要设置绕过 Istio，请更改 `global.proxy.includeIPRanges` 或 `global.proxy.excludeIPRanges` 配置选项，并使用 `kubectl apply` 命令更新 `istio-sidecar-injector` 的[配置](/zh/docs/reference/config/installation-options/)。`istio-sidecar-injector` 配置的更新，影响的是新部署应用的 pod。 +如果要让特定范围的 ​​IP 完全绕过 Istio，则可以配置 Envoy sidecars 以防止它们[拦截](/zh/docs/concepts/traffic-management/)外部请求。要设置绕过 Istio，请更改 `global.proxy.includeIPRanges` 或 `global.proxy.excludeIPRanges` 配置选项，并使用 `kubectl apply` 命令更新 `istio-sidecar-injector` 的[配置](/zh/docs/reference/config/installation-options/)。`istio-sidecar-injector` 配置的更新，影响的是新部署应用的 pod。 {{< warning >}} 与 [Envoy 转发流量到外部服务](#envoy-passthrough-to-external-services)不同，后者使用 `ALLOW_ANY` 流量策略来让 Istio sidecar 代理将调用传递给未知服务， @@ -304,7 +304,7 @@ $ kubectl delete virtualservice httpbin-ext --ignore-not-found=true service_cluster_ip_range: 10.0.0.1/24 {{< /text >}} -1. 使用 `--set global.proxy.includeIPRanges="10.0.0.1/24"` +1. 使用 `--set global.proxy.includeIPRanges="10.0.0.1/24"` #### IBM Cloud Kubernetes Service @@ -424,7 +424,7 @@ $ kubectl delete -f @samples/sleep/sleep.yaml@ ### 将出站流量策略模式设置为所需的值{#set-the-outbound-traffic-policy-mode-to-your-desired-value} -1. 检查现在的值: +1. 检查现在的值: {{< text bash >}} $ kubectl get configmap istio -n istio-system -o yaml | grep -o "mode: ALLOW_ANY" | uniq @@ -434,7 +434,7 @@ $ kubectl delete -f @samples/sleep/sleep.yaml@ 输出将会是 `mode: ALLOW_ANY` 或 `mode: REGISTRY_ONLY`。 -1. 如果你想改变这个模式，执行以下命令： +1. 如果你想改变这个模式，执行以下命令： {{< tabset category-name="outbound_traffic_policy_mode" >}} diff --git a/content/zh/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md b/content/zh/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md index 1c9734891c..8a6cac54aa 100644 --- a/content/zh/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md +++ b/content/zh/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/index.md @@ -49,7 +49,7 @@ aliases: 本节描述如何使用 egress 网关发起与示例[为 Egress 流量发起 TLS 连接](/zh/docs/tasks/traffic-management/egress/egress-tls-origination/)中一样的 TLS。 注意，这种情况下，TLS 的发起过程由 egress 网关完成，而不是像之前示例演示的那样由 sidecar 完成。 -1. 为 `edition.cnn.com` 定义一个 `ServiceEntry`： +1. 为 `edition.cnn.com` 定义一个 `ServiceEntry`： {{< text bash >}} $ kubectl apply -f - <}} -1. 发送一个请求至 [http://edition.cnn.com/politics](https://edition.cnn.com/politics)，验证 `ServiceEntry` 已被正确应用。 +1. 发送一个请求至 [http://edition.cnn.com/politics](https://edition.cnn.com/politics)，验证 `ServiceEntry` 已被正确应用。 {{< text bash >}} $ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - http://edition.cnn.com/politics @@ -85,7 +85,7 @@ aliases: 如果在输出中看到 _301 Moved Permanently_，说明 `ServiceEntry` 配置正确。 -1. 为 _edition.cnn.com_ 创建一个 egress `Gateway`， 端口 443，以及一个 sidecar 请求的目标规则，sidecar 请求被直接导向 egress 网关。 +1. 为 _edition.cnn.com_ 创建一个 egress `Gateway`，端口 443，以及一个 sidecar 请求的目标规则，sidecar 请求被直接导向 egress 网关。 根据需要开启源 pod 与 egress 网关之间的[双向 TLS 认证](/zh/docs/tasks/security/authentication/mutual-tls/)，选择相应的命令。 @@ -176,7 +176,7 @@ aliases: {{< /tabset >}} -1. 定义一个 `VirtualService` 来引导流量流经 egress 网关，以及一个 `DestinationRule` 为访问 `edition.cnn.com` 的请求发起 TLS 连接： +1. 定义一个 `VirtualService` 来引导流量流经 egress 网关，以及一个 `DestinationRule` 为访问 `edition.cnn.com` 的请求发起 TLS 连接： {{< text bash >}} $ kubectl apply -f - <}} -1. 发送一个 HTTP 请求至 [http://edition.cnn.com/politics](https://edition.cnn.com/politics)。 +1. 发送一个 HTTP 请求至 [http://edition.cnn.com/politics](https://edition.cnn.com/politics)。 {{< text bash >}} $ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - http://edition.cnn.com/politics @@ -242,7 +242,7 @@ aliases: 输出将与在示例[为 Egress 流量发起 TLS 连接](/zh/docs/tasks/traffic-management/egress/egress-tls-origination/)中显示的一样，发起 TLS 连接后，不再显示 _301 Moved Permanently_ 消息。 -1. 检查 `istio-egressgateway` pod 的日志，将看到一行与请求相关的记录。 +1. 检查 `istio-egressgateway` pod 的日志，将看到一行与请求相关的记录。 若 Istio 部署在 `istio-system` 命名空间中，打印日志的命令为： {{< text bash >}} @@ -281,19 +281,19 @@ $ kubectl delete destinationrule egressgateway-for-cnn ### 生成客户端和服务器的证书与密钥{#generate-client-and-server-certificates-and-keys} -1. 克隆示例代码库 ： +1. 克隆示例代码库 ： {{< text bash >}} $ git clone https://github.com/nicholasjackson/mtls-go-example {{< /text >}} -1. 进入克隆的代码库目录： +1. 进入克隆的代码库目录： {{< text bash >}} $ cd mtls-go-example {{< /text >}} -1. 为 `nginx.example.com` 生成证书。 +1. 为 `nginx.example.com` 生成证书。 使用任意 password 执行如下命令： {{< text bash >}} @@ -302,13 +302,13 @@ $ kubectl delete destinationrule egressgateway-for-cnn 所有出现的提示，均选择 `y`。 -1. 将证书迁移至 `nginx.example.com` 目录： +1. 将证书迁移至 `nginx.example.com` 目录： {{< text bash >}} $ mkdir ../nginx.example.com && mv 1_root 2_intermediate 3_application 4_client ../nginx.example.com {{< /text >}} -1. 返回至上一级目录： +1. 返回至上一级目录： {{< text bash >}} $ cd .. @@ -319,20 +319,20 @@ $ kubectl delete destinationrule egressgateway-for-cnn 为了模拟一个真实的支持双向 TLS 协议的外部服务， 在 Kubernetes 集群中部署一个 [NGINX](https://www.nginx.com) 服务器，该服务器运行在 Istio 服务网格之外，譬如：运行在一个没有开启 Istio sidecar proxy 注入的命名空间中。 -1. 创建一个命名空间，表示 Istio 网格之外的服务， `mesh-external`。注意在这个命名空间中，sidecar 自动注入是没有[开启](/zh/docs/setup/additional-setup/sidecar-injection/#deploying-an-app)的，不会在 pods 中自动注入 sidecar proxy。 +1. 创建一个命名空间，表示 Istio 网格之外的服务，`mesh-external`。注意在这个命名空间中，sidecar 自动注入是没有[开启](/zh/docs/setup/additional-setup/sidecar-injection/#deploying-an-app)的，不会在 pods 中自动注入 sidecar proxy。 {{< text bash >}} $ kubectl create namespace mesh-external {{< /text >}} -1. 创建 Kubernetes [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) ，保存服务器和 CA 的证书。 +1. 创建 Kubernetes [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) ，保存服务器和 CA 的证书。 {{< text bash >}} $ kubectl create -n mesh-external secret tls nginx-server-certs --key nginx.example.com/3_application/private/nginx.example.com.key.pem --cert nginx.example.com/3_application/certs/nginx.example.com.cert.pem $ kubectl create -n mesh-external secret generic nginx-ca-certs --from-file=nginx.example.com/2_intermediate/certs/ca-chain.cert.pem {{< /text >}} -1. 生成 NGINX 服务器的配置文件： +1. 生成 NGINX 服务器的配置文件： {{< text bash >}} $ cat < ./nginx.conf @@ -362,13 +362,13 @@ $ kubectl delete destinationrule egressgateway-for-cnn EOF {{< /text >}} -1. 生成 Kubernetes [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) 保存 NGINX 服务器的配置文件： +1. 生成 Kubernetes [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) 保存 NGINX 服务器的配置文件： {{< text bash >}} $ kubectl create configmap nginx-configmap -n mesh-external --from-file=nginx.conf=./nginx.conf {{< /text >}} -1. 部署 NGINX 服务器： +1. 部署 NGINX 服务器： {{< text bash >}} $ kubectl apply -f - <}} -1. 为 `nginx.example.com` 定义一个 `ServiceEntry` 和一个 `VirtualService`，指示 Istio 引导目标为 `nginx.example.com` 的流量流向 NGINX 服务器： +1. 为 `nginx.example.com` 定义一个 `ServiceEntry` 和一个 `VirtualService`，指示 Istio 引导目标为 `nginx.example.com` 的流量流向 NGINX 服务器： {{< text bash >}} $ kubectl apply -f - <}} $ kubectl create secret tls nginx-client-certs --key nginx.example.com/4_client/private/nginx.example.com.key.pem --cert nginx.example.com/4_client/certs/nginx.example.com.cert.pem $ kubectl create secret generic nginx-ca-certs --from-file=nginx.example.com/2_intermediate/certs/ca-chain.cert.pem {{< /text >}} -1. 基于挂载的客户端和 CA 证书，部署 [sleep]({{< github_tree >}}/samples/sleep) 样本应用，测试发送请求至 NGINX 服务器： +1. 基于挂载的客户端和 CA 证书，部署 [sleep]({{< github_tree >}}/samples/sleep) 样本应用，测试发送请求至 NGINX 服务器： {{< text bash >}} $ kubectl apply -f - <}} -1. 定义一个环境变量保存 `sleep` pod 的名称： +1. 定义一个环境变量保存 `sleep` pod 的名称： {{< text bash >}} $ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) {{< /text >}} -1. 使用部署的 [sleep]({{< github_tree >}}/samples/sleep) pod 向 NGINX 服务器发送请求。 +1. 使用部署的 [sleep]({{< github_tree >}}/samples/sleep) pod 向 NGINX 服务器发送请求。 由于 `nginx.example.com` 不是真实存在的，DNS 无法解析，后面的 `curl` 命令使用 `--resolve` 选项手动解析主机名。 --resolve 选项传递的 IP 值（下方所示，1.1.1.1）没有意义。除 127.0.0.1 之外的任意值都可以使用。 一般情况下，目标主机名对应着一个 DNS 项，无需使用 `curl` 的 `--resolve` 选项。 @@ -586,7 +586,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn ... {{< /text >}} -1. 验证服务器要求客户端的证书： +1. 验证服务器要求客户端的证书： {{< text bash >}} $ kubectl exec -it $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl -k --resolve nginx.example.com:443:1.1.1.1 https://nginx.example.com @@ -609,7 +609,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn $ kubectl create -n istio-system secret generic nginx-ca-certs --from-file=nginx.example.com/2_intermediate/certs/ca-chain.cert.pem {{< /text >}} -1. 部署 `istio-egressgateway` 挂载新生成的 secrets 的 volume。使用的参数选项与生成 `istio.yaml` 中的一致： +1. 部署 `istio-egressgateway` 挂载新生成的 secrets 的 volume。使用的参数选项与生成 `istio.yaml` 中的一致： {{< text bash >}} $ istioctl manifest generate --set values.gateways.istio-ingressgateway.enabled=false \ @@ -629,24 +629,24 @@ $ kubectl delete destinationrule egressgateway-for-cnn ./istio-egressgateway.yaml {{< /text >}} -1. 重新部署 `istio-egressgateway`： +1. 重新部署 `istio-egressgateway`： {{< text bash >}} $ kubectl apply -f ./istio-egressgateway.yaml deployment "istio-egressgateway" configured {{< /text >}} -1. 验证密钥和证书被成功装载入 `istio-egressgateway` pod： +1. 验证密钥和证书被成功装载入 `istio-egressgateway` pod： {{< text bash >}} $ kubectl exec -it -n istio-system $(kubectl -n istio-system get pods -l istio=egressgateway -o jsonpath='{.items[0].metadata.name}') -- ls -al /etc/nginx-client-certs /etc/nginx-ca-certs {{< /text >}} - `tls.crt` 与 `tls.key` 在 `/etc/istio/nginx-client-certs` 中， 而 `ca-chain.cert.pem` 在 `/etc/istio/nginx-ca-certs` 中。 + `tls.crt` 与 `tls.key` 在 `/etc/istio/nginx-client-certs` 中，而 `ca-chain.cert.pem` 在 `/etc/istio/nginx-ca-certs` 中。 ### 为 egress 流量配置双向 TLS{#configure-mutual-TLS-origination-for-egress-traffic} -1. 为 `nginx.example.com` 创建一个 egress `Gateway` 端口为 443，以及目标规则和虚拟服务来引导流量流经 egress 网关并从 egress 网关流向外部服务。 +1. 为 `nginx.example.com` 创建一个 egress `Gateway` 端口为 443，以及目标规则和虚拟服务来引导流量流经 egress 网关并从 egress 网关流向外部服务。 {{< text bash >}} $ kubectl apply -f - <}} -1. 定义一个 `VirtualService` 引导流量流经 egress 网关，一个 `DestinationRule` 发起双向 TLS 连接： +1. 定义一个 `VirtualService` 引导流量流经 egress 网关，一个 `DestinationRule` 发起双向 TLS 连接： {{< text bash >}} $ kubectl apply -f - <}} -1. 发送一个 HTTP 请求至 `http://nginx.example.com`： +1. 发送一个 HTTP 请求至 `http://nginx.example.com`： {{< text bash >}} $ kubectl exec -it $SOURCE_POD -c sleep -- curl -s --resolve nginx.example.com:80:1.1.1.1 http://nginx.example.com @@ -759,7 +759,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn ... {{< /text >}} -1. 检查 `istio-egressgateway` pod 日志，有一行与请求相关的日志记录。 +1. 检查 `istio-egressgateway` pod 日志，有一行与请求相关的日志记录。 如果 Istio 部署在命名空间 `istio-system` 中，打印日志的命令为： {{< text bash >}} @@ -774,7 +774,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn ### 清除双向 TLS 连接示例{#cleanup-the-mutual-TLS-origination-example} -1. 删除创建的 Kubernetes 资源： +1. 删除创建的 Kubernetes 资源： {{< text bash >}} $ kubectl delete secret nginx-server-certs nginx-ca-certs -n mesh-external @@ -791,13 +791,13 @@ $ kubectl delete destinationrule egressgateway-for-cnn $ kubectl delete destinationrule egressgateway-for-nginx {{< /text >}} -1. 删除用于生成证书和仓库的路径： +1. 删除用于生成证书和仓库的路径： {{< text bash >}} $ rm -rf nginx.example.com mtls-go-example {{< /text >}} -1. 删除生成并应用于示例中的配置文件 +1. 删除生成并应用于示例中的配置文件 {{< text bash >}} $ rm -f ./nginx.conf ./istio-egressgateway.yaml diff --git a/content/zh/docs/tasks/traffic-management/egress/egress-gateway/index.md b/content/zh/docs/tasks/traffic-management/egress/egress-gateway/index.md index d7969e6049..fa76c4356d 100644 --- a/content/zh/docs/tasks/traffic-management/egress/egress-gateway/index.md +++ b/content/zh/docs/tasks/traffic-management/egress/egress-gateway/index.md @@ -28,7 +28,7 @@ Ingress gateway 使您可以定义所有输入流量流经的网格的入口点 ## 部署 Istio egress gateway{#deploy-Istio-egress-gateway} -1. 检查 Istio egress gateway 是否已布署： +1. 检查 Istio egress gateway 是否已布署： {{< text bash >}} $ kubectl get pod -l istio=egressgateway -n istio-system @@ -36,7 +36,7 @@ Ingress gateway 使您可以定义所有输入流量流经的网格的入口点 如果没有 pod 返回，通过接下来的步骤来部署 Istio egress gateway。 -1. 执行以下命令： +1. 执行以下命令： {{< text bash >}} $ istioctl manifest apply --set values.global.istioNamespace=istio-system \ @@ -54,7 +54,7 @@ Ingress gateway 使您可以定义所有输入流量流经的网格的入口点 首先创建一个 `ServiceEntry` 引导流和到一个外部服务。 -1. 为 `edition.cnn.com` 定义一个 `ServiceEntry`： +1. 为 `edition.cnn.com` 定义一个 `ServiceEntry`： {{< text bash >}} $ kubectl apply -f - <}} -1. 发送 HTTPS 请求到 [https://edition.cnn.com/politics](https://edition.cnn.com/politics)，验证 `ServiceEntry` 是否已正确应用。 +1. 发送 HTTPS 请求到 [https://edition.cnn.com/politics](https://edition.cnn.com/politics)，验证 `ServiceEntry` 是否已正确应用。 {{< text bash >}} $ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - https://edition.cnn.com/politics @@ -94,7 +94,7 @@ Ingress gateway 使您可以定义所有输入流量流经的网格的入口点 不带 TLS 的输出应与 [Egress 流量的 TLS](/zh/docs/tasks/traffic-management/egress/egress-tls-origination/) 任务中的输出相同。 -1. 为 `edition.cnn.com` 端口 80 创建 Egress gateway。除此之外还要创建一个 destination rule 来引导流量通过 Egress gateway 与外部服务通信。 +1. 为 `edition.cnn.com` 端口 80 创建 Egress gateway。除此之外还要创建一个 destination rule 来引导流量通过 Egress gateway 与外部服务通信。 根据在 Istio 中是否启用了[双向 TLS 认证](/zh/docs/tasks/security/authentication/mutual-tls/)，选择相应的说明。 @@ -180,7 +180,7 @@ Ingress gateway 使您可以定义所有输入流量流经的网格的入口点 {{< /tabset >}} -1. 定义 `VirtualService` 来引导流量，从 Sidecar 到 Egress gateway 和 从 Egress gateway 到外部服务： +1. 定义 `VirtualService` 来引导流量，从 Sidecar 到 Egress gateway 和 从 Egress gateway 到外部服务： {{< text bash >}} $ kubectl apply -f - <}} -1. 将 HTTP 请求重新发送到 [https://edition.cnn.com/politics](https://edition.cnn.com/politics)。 +1. 将 HTTP 请求重新发送到 [https://edition.cnn.com/politics](https://edition.cnn.com/politics)。 {{< text bash >}} $ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - https://edition.cnn.com/politics @@ -237,7 +237,7 @@ Ingress gateway 使您可以定义所有输入流量流经的网格的入口点 The output should be the same as in the step 2. -1. 检查 `istio-egressgateway` pod 的日志，并查看与我们的请求对应的行。如果 Istio 部署在 `istio-system` 命名空间中，则打印日志的命令是： +1. 检查 `istio-egressgateway` pod 的日志，并查看与我们的请求对应的行。如果 Istio 部署在 `istio-system` 命名空间中，则打印日志的命令是： {{< text bash >}} $ kubectl logs -l istio=egressgateway -c istio-proxy -n istio-system | tail @@ -267,7 +267,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn 接下来尝试使用 Egress Gateway 发起 HTTPS 请求（TLS 由应用程序发起）。您需要在相应的 `ServiceEntry` 中使用 `TLS` 协议指定的端口 443、egress `Gateway` 、`VirtualService`。 -1. 为 `edition.cnn.com` 定义 `ServiceEntry`： +1. 为 `edition.cnn.com` 定义 `ServiceEntry`： {{< text bash >}} $ kubectl apply -f - <}} -1. 发送 HTTPS 请求到 [https://edition.cnn.com/politics](https://edition.cnn.com/politics)，验证您的 `ServiceEntry` 是否已正确生效。 +1. 发送 HTTPS 请求到 [https://edition.cnn.com/politics](https://edition.cnn.com/politics)，验证您的 `ServiceEntry` 是否已正确生效。 {{< text bash >}} $ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - https://edition.cnn.com/politics @@ -297,7 +297,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn ... {{< /text >}} -1. 为 `edition.cnn.com` 创建 Egress Gateway。除此之外还创建了一个 destination rule 和一个 virtual service，这两个对象用来引导流量通过 Egress gateway 与外部服务通信。 +1. 为 `edition.cnn.com` 创建 Egress Gateway。除此之外还创建了一个 destination rule 和一个 virtual service，这两个对象用来引导流量通过 Egress gateway 与外部服务通信。 根据在 Istio 中是否启用了[双向 TLS](/zh/docs/tasks/security/authentication/mutual-tls/)，选择相应的说明。 @@ -456,7 +456,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn {{< /tabset >}} -1. 发送 HTTPS 请求到 [https://edition.cnn.com/politics](https://edition.cnn.com/politics)。输出应用和之前一样。 +1. 发送 HTTPS 请求到 [https://edition.cnn.com/politics](https://edition.cnn.com/politics)。输出应用和之前一样。 {{< text bash >}} $ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - https://edition.cnn.com/politics @@ -467,7 +467,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn ... {{< /text >}} -1. 检查 `istio-egressgateway` pod 的日志，并查看与我们的请求相对应的行。如果 Istio 部署在 `istio-system` 命名空间中，则打印日志的命令是： +1. 检查 `istio-egressgateway` pod 的日志，并查看与我们的请求相对应的行。如果 Istio 部署在 `istio-system` 命名空间中，则打印日志的命令是： {{< text bash >}} $ kubectl logs -l istio=egressgateway -n istio-system @@ -502,21 +502,21 @@ $ kubectl delete destinationrule egressgateway-for-cnn 本节中展示了如何创建 [Kubernetes 网络策略](https://kubernetes.io/docs/concepts/services-networking/network-policies/)来阻止绕过 Egress gateway 的外发流量。为了测试网络策略，首先创建一个 `test-egress` 命名空间，并在其中部署 [sleep]({{< github_tree >}}/samples/sleep) 示例应用，然后尝试发送请求到一个网关安全的外部服务。 -1. 重复执行[通过 Egress gateway 进行 HTTPS 流量透传](#egress-gateway-for-http-traffic)一节的内容。 +1. 重复执行[通过 Egress gateway 进行 HTTPS 流量透传](#egress-gateway-for-http-traffic)一节的内容。 -1. 创建`test-egress` 命名空间： +1. 创建`test-egress` 命名空间： {{< text bash >}} $ kubectl create namespace test-egress {{< /text >}} -1. 在 `test-egress` 命名空间中部署 [sleep]({{< github_tree >}}/samples/sleep) 示例应用： +1. 在 `test-egress` 命名空间中部署 [sleep]({{< github_tree >}}/samples/sleep) 示例应用： {{< text bash >}} $ kubectl apply -n test-egress -f @samples/sleep/sleep.yaml@ {{< /text >}} -1. 检查生成的 Pod，其中应该只有一个容器，也就是说没有注入 Istio Sidecar： +1. 检查生成的 Pod，其中应该只有一个容器，也就是说没有注入 Istio Sidecar： {{< text bash >}} $ kubectl get pod $(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..metadata.name}) -n test-egress @@ -524,26 +524,26 @@ $ kubectl delete destinationrule egressgateway-for-cnn sleep-776b7bcdcd-z7mc4 1/1 Running 0 18m {{< /text >}} -1. 从 `test-egress` 命名空间的 `sleep` Pod 中向 [https://edition.cnn.com/politics](https://edition.cnn.com/politics) 发送 HTTPS 请求。因为没有任何限制，所以这一请求应该会成功： +1. 从 `test-egress` 命名空间的 `sleep` Pod 中向 [https://edition.cnn.com/politics](https://edition.cnn.com/politics) 发送 HTTPS 请求。因为没有任何限制，所以这一请求应该会成功： {{< text bash >}} $ kubectl exec -it $(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..metadata.name}) -n test-egress -c sleep -- curl -s -o /dev/null -w "%{http_code}\n" https://edition.cnn.com/politics 200 {{< /text >}} -1. 给 Istio 组件（控制平面和 Gateway）所在的命名空间打上标签，例如 `istio-system`： +1. 给 Istio 组件（控制平面和 Gateway）所在的命名空间打上标签，例如 `istio-system`： {{< text bash >}} $ kubectl label namespace istio-system istio=system {{< /text >}} -1. 给 `kube-system` 命名空间打标签： +1. 给 `kube-system` 命名空间打标签： {{< text bash >}} $ kubectl label ns kube-system kube-system=true {{< /text >}} -1. 创建一个 `NetworkPolicy`，来限制 `test-egress` 命名空间的流量，只允许目标为 `kube-system` 的 DNS（端口 53）请求，以及目标为 `istio-system` 命名空间的所有请求： +1. 创建一个 `NetworkPolicy`，来限制 `test-egress` 命名空间的流量，只允许目标为 `kube-system` 的 DNS（端口 53）请求，以及目标为 `istio-system` 命名空间的所有请求： {{< text bash >}} $ cat <}} -1. 重新发送前面的 HTTPS 请求到 [https://edition.cnn.com/politics](https://edition.cnn.com/politics)。这次请求就不会成功了，这是因为流量被网络策略拦截了。测试 Pod 无法越过 `istio-egressgateway`。要访问 `edition.cnn.com`，只能通过 Istio Sidecar 将流量转给 `istio-egressgateway` 才能完成。这一设置演示了即使绕过了 Sidecar，也会被网络策略拦截，而无法访问到外部站点。 +1. 重新发送前面的 HTTPS 请求到 [https://edition.cnn.com/politics](https://edition.cnn.com/politics)。这次请求就不会成功了，这是因为流量被网络策略拦截了。测试 Pod 无法越过 `istio-egressgateway`。要访问 `edition.cnn.com`，只能通过 Istio Sidecar 将流量转给 `istio-egressgateway` 才能完成。这一设置演示了即使绕过了 Sidecar，也会被网络策略拦截，而无法访问到外部站点。 {{< text bash >}} $ kubectl exec -it $(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..metadata.name}) -n test-egress -c sleep -- curl -v https://edition.cnn.com/politics @@ -587,27 +587,27 @@ $ kubectl delete destinationrule egressgateway-for-cnn connect to 151.101.65.67 port 443 failed: Connection timed out {{< /text >}} -1. 接下来在 `test-egress` 命名空间的 `sleep` Pod 上注入 Sidecar，启用 `test-egress` 命名空间的自动注入： +1. 接下来在 `test-egress` 命名空间的 `sleep` Pod 上注入 Sidecar，启用 `test-egress` 命名空间的自动注入： {{< text bash >}} $ kubectl label namespace test-egress istio-injection=enabled {{< /text >}} -1. 重新部署 `sleep`： +1. 重新部署 `sleep`： {{< text bash >}} $ kubectl delete deployment sleep -n test-egress $ kubectl apply -f @samples/sleep/sleep.yaml@ -n test-egress {{< /text >}} -1. 检查生成的 Pod，其中应该有了两个容器，其中包含了注入的 Sidecar（`istio-proxy`）： +1. 检查生成的 Pod，其中应该有了两个容器，其中包含了注入的 Sidecar（`istio-proxy`）： {{< text bash >}} $ kubectl get pod $(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..metadata.name}) -n test-egress -o jsonpath='{.spec.containers[*].name}' sleep istio-proxy {{< /text >}} -1. 为 `default` 命名空间中为 `sleep` pod 创建一个相同的 destination rule 用来引导流量到 Egress gateway： +1. 为 `default` 命名空间中为 `sleep` pod 创建一个相同的 destination rule 用来引导流量到 Egress gateway： 根据在 Istio 中是否启用了[双向 TLS](/zh/docs/tasks/security/authentication/mutual-tls/)，选择相应的说明。 @@ -658,14 +658,14 @@ $ kubectl delete destinationrule egressgateway-for-cnn {{< /tabset >}} -1. 向 [https://edition.cnn.com/politics](https://edition.cnn.com/politics) 发送 HTTP 请求，这次会成功，原因是网络策略允许流量流向 `istio-system` 中的 `istio-egressgateway`，`istio-egressgateway` 最终把流量转发到 `edition.cnn.com`。 +1. 向 [https://edition.cnn.com/politics](https://edition.cnn.com/politics) 发送 HTTP 请求，这次会成功，原因是网络策略允许流量流向 `istio-system` 中的 `istio-egressgateway`，`istio-egressgateway` 最终把流量转发到 `edition.cnn.com`。 {{< text bash >}} $ kubectl exec -it $(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..metadata.name}) -n test-egress -c sleep -- curl -s -o /dev/null -w "%{http_code}\n" https://edition.cnn.com/politics 200 {{< /text >}} -1. 检查 Egress gateway 中的代理统计数据，查看对 `edition.cnn.com` 的请求计数。如果 Istio 部署在 `istio-system` 命名空间，那么打印计数器的命令就是： +1. 检查 Egress gateway 中的代理统计数据，查看对 `edition.cnn.com` 的请求计数。如果 Istio 部署在 `istio-system` 命名空间，那么打印计数器的命令就是： {{< text bash >}} $ kubectl exec $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -n istio-system -- pilot-agent request GET stats | grep edition.cnn.com.upstream_cx_total @@ -674,7 +674,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn ### 清理网络策略{#cleanup-network-policies} -1. 删除本节中建立的资源： +1. 删除本节中建立的资源： {{< text bash >}} $ kubectl delete -f @samples/sleep/sleep.yaml@ -n test-egress @@ -685,13 +685,13 @@ $ kubectl delete destinationrule egressgateway-for-cnn $ kubectl delete namespace test-egress {{< /text >}} -1. 执行[通过 Egress gateway 进行 HTTPS 流量透传](#egress-gateway-for-http-traffic)一节中的[清理工作](#cleanup-http-gateway)。 +1. 执行[通过 Egress gateway 进行 HTTPS 流量透传](#egress-gateway-for-http-traffic)一节中的[清理工作](#cleanup-http-gateway)。 ## 故障排除{#troubleshooting} -1. 检查是否在 Istio 中启用了[双向 TLS 认证](/zh/docs/tasks/security/authentication/mutual-tls/)，然后执行以下步骤：[验证 Istio 的双向 TLS 认证设置](/zh/docs/tasks/security/authentication/mutual-tls/#verify-mutual-TLS-configuration)。如果启用了双向 TLS，请确保创建相应的项目配置（请注意备注**如果您在 Istio 中启用了双向 TLS 认证，则必须创建。**）。 +1. 检查是否在 Istio 中启用了[双向 TLS 认证](/zh/docs/tasks/security/authentication/mutual-tls/)，然后执行以下步骤：[验证 Istio 的双向 TLS 认证设置](/zh/docs/tasks/security/authentication/mutual-tls/#verify-mutual-TLS-configuration)。如果启用了双向 TLS，请确保创建相应的项目配置（请注意备注**如果您在 Istio 中启用了双向 TLS 认证，则必须创建。**）。 -1. 如果[双向 TLS 认证](/zh/docs/tasks/security/authentication/mutual-tls/)启用后，验证 Egress gateway 的证书： +1. 如果[双向 TLS 认证](/zh/docs/tasks/security/authentication/mutual-tls/)启用后，验证 Egress gateway 的证书： {{< text bash >}} $ kubectl exec -i -n istio-system $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -- cat /etc/certs/cert-chain.pem | openssl x509 -text -noout | grep 'Subject Alternative Name' -A 1 @@ -699,7 +699,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn URI:spiffe://cluster.local/ns/istio-system/sa/istio-egressgateway-service-account {{< /text >}} -1. HTTPS 透传流量情况，需要使用 `openssl` 命令测试流量。`openssl` 的 `-servername` 选项可以用来设置 SNI： +1. HTTPS 透传流量情况，需要使用 `openssl` 命令测试流量。`openssl` 的 `-servername` 选项可以用来设置 SNI： {{< text bash >}} $ kubectl exec -it $SOURCE_POD -c sleep -- openssl s_client -connect edition.cnn.com:443 -servername edition.cnn.com diff --git a/content/zh/docs/tasks/traffic-management/egress/egress-kubernetes-services/index.md b/content/zh/docs/tasks/traffic-management/egress/egress-kubernetes-services/index.md index b755152415..a59666bcd1 100644 --- a/content/zh/docs/tasks/traffic-management/egress/egress-kubernetes-services/index.md +++ b/content/zh/docs/tasks/traffic-management/egress/egress-kubernetes-services/index.md @@ -41,7 +41,7 @@ Kubernetes [ExternalName](https://kubernetes.io/docs/concepts/services-networkin ## Kubernetes ExternalName 服务访问外部服务{#ks-external-name-service-to-access-an-external-service} -1. 在默认命名空间中，为 `httpbin.org` 创建一个 Kubernetes [ExternalName](https://kubernetes.io/docs/concepts/services-networking/service/#externalname) 服务： +1. 在默认命名空间中，为 `httpbin.org` 创建一个 Kubernetes [ExternalName](https://kubernetes.io/docs/concepts/services-networking/service/#externalname) 服务： {{< text bash >}} $ kubectl apply -f - <}} -1. 观察您的服务。注意它没有集群 IP。 +1. 观察您的服务。注意它没有集群 IP。 {{< text bash >}} $ kubectl get svc my-httpbin @@ -67,7 +67,7 @@ Kubernetes [ExternalName](https://kubernetes.io/docs/concepts/services-networkin my-httpbin ExternalName httpbin.org 80/TCP 4s {{< /text >}} -1. 从没有 Istio Sidecar 的源 pod 通过 Kubernetes 服务的主机名访问 `httpbin.org`。注意下面的 _curl_ 命令使用 [Kubernetes DNS 格式用于服务](https://v1-13.docs.kubernetes.io/docs/concepts/services-networking/dns-pod-service/#a-records)：`..svc.cluster.local`。 +1. 从没有 Istio Sidecar 的源 pod 通过 Kubernetes 服务的主机名访问 `httpbin.org`。注意下面的 _curl_ 命令使用 [Kubernetes DNS 格式用于服务](https://v1-13.docs.kubernetes.io/docs/concepts/services-networking/dns-pod-service/#a-records)：`..svc.cluster.local`。 {{< text bash >}} $ kubectl exec -it $SOURCE_POD_WITHOUT_ISTIO -n without-istio -c sleep -- curl my-httpbin.default.svc.cluster.local/headers @@ -80,7 +80,7 @@ Kubernetes [ExternalName](https://kubernetes.io/docs/concepts/services-networkin } {{< /text >}} -1. 在这个例子中，未加密的 HTTP 请求被发送到 `httpbin.org`。仅出于示例目的，您禁用 TLS 模式，并允许外部服务的未加密流量。在现实生活中，我们建议 +1. 在这个例子中，未加密的 HTTP 请求被发送到 `httpbin.org`。仅出于示例目的，您禁用 TLS 模式，并允许外部服务的未加密流量。在现实生活中，我们建议 由 Istio 执行 [Egress TLS 起源](/zh/docs/tasks/traffic-management/egress/egress-tls-origination)。 {{< text bash >}} @@ -97,7 +97,7 @@ Kubernetes [ExternalName](https://kubernetes.io/docs/concepts/services-networkin EOF {{< /text >}} -1. 通过带有 Istio Sidecar 的源 pod 通过 Kubernetes 服务的主机名访问 `httpbin.org`。注意 Istio Sidecar 添加的 headers，例如， `X-Istio-Attributes` 和 `X-Envoy-Decorator-Operation`。另请注意 `Host` header 等于您的服务的主机名。 +1. 通过带有 Istio Sidecar 的源 pod 通过 Kubernetes 服务的主机名访问 `httpbin.org`。注意 Istio Sidecar 添加的 headers，例如，`X-Istio-Attributes` 和 `X-Envoy-Decorator-Operation`。另请注意 `Host` header 等于您的服务的主机名。 {{< text bash >}} $ kubectl exec -it $SOURCE_POD -c sleep -- curl my-httpbin.default.svc.cluster.local/headers @@ -124,7 +124,7 @@ $ kubectl delete service my-httpbin ## 使用带 endpoints 的 Kubernetes 服务来访问外部服务{#use-a-ks-service-with-endpoints-to-access-an-external-service} -1. 为 Wikipedia 创建没有 selector 的 Kubernetes 服务： +1. 为 Wikipedia 创建没有 selector 的 Kubernetes 服务： {{< text bash >}} $ kubectl apply -f - <}} -1. 为您的服务创建 endpoints。从 [Wikipedia 范围列表](https://www.mediawiki.org/wiki/Wikipedia_Zero/IP_Addresses)中选择几个 IP。 +1. 为您的服务创建 endpoints。从 [Wikipedia 范围列表](https://www.mediawiki.org/wiki/Wikipedia_Zero/IP_Addresses)中选择几个 IP。 {{< text bash >}} $ kubectl apply -f - <}} -1. 观察您的服务。请注意，它具有一个群集 IP，您可以使用它访问 `wikipedia.org`。 +1. 观察您的服务。请注意，它具有一个群集 IP，您可以使用它访问 `wikipedia.org`。 {{< text bash >}} $ kubectl get svc my-wikipedia @@ -166,14 +166,14 @@ $ kubectl delete service my-httpbin my-wikipedia ClusterIP 172.21.156.230 443/TCP 21h {{< /text >}} -1. 从没有 Istio sidecar 的源 Pod 通过您的向您的 Kubernetes 服务集群 IP 来发送 HTTPS 请求到 `wikipedia.org`。使用 `curl` 的 `--resolve` 选项通过集群 IP 访问 `wikipedia.org`： +1. 从没有 Istio sidecar 的源 Pod 通过您的向您的 Kubernetes 服务集群 IP 来发送 HTTPS 请求到 `wikipedia.org`。使用 `curl` 的 `--resolve` 选项通过集群 IP 访问 `wikipedia.org`： {{< text bash >}} $ kubectl exec -it $SOURCE_POD_WITHOUT_ISTIO -n without-istio -c sleep -- curl -s --resolve en.wikipedia.org:443:$(kubectl get service my-wikipedia -o jsonpath='{.spec.clusterIP}') https://en.wikipedia.org/wiki/Main_Page | grep -o ".*" Wikipedia, the free encyclopedia {{< /text >}} -1. 在这种情况下，工作负载将 HTTPS 请求（开放 TLS 连接）发送到 `wikipedia.org`。流量已经通过工作负载加密，因此您可以安全地禁用 Istio 的双向 TLS： +1. 在这种情况下，工作负载将 HTTPS 请求（开放 TLS 连接）发送到 `wikipedia.org`。流量已经通过工作负载加密，因此您可以安全地禁用 Istio 的双向 TLS： {{< text bash >}} $ kubectl apply -f - <}} -1. 使用 Istio Sidecar 从源 Pod 中通过 Kubernetes 服务的群集 IP 访问 `wikipedia.org`： +1. 使用 Istio Sidecar 从源 Pod 中通过 Kubernetes 服务的群集 IP 访问 `wikipedia.org`： {{< text bash >}} $ kubectl exec -it $SOURCE_POD -c sleep -- curl -s --resolve en.wikipedia.org:443:$(kubectl get service my-wikipedia -o jsonpath='{.spec.clusterIP}') https://en.wikipedia.org/wiki/Main_Page | grep -o ".*" Wikipedia, the free encyclopedia {{< /text >}} -1. 检查访问是否确实由群集 IP 完成。在 `curl -v` 的输出中注意这句话 `Connected to en.wikipedia.org (172.21.156.230)`，其中提到了在您的服务输出中作为群集 IP 打印的 IP。 +1. 检查访问是否确实由群集 IP 完成。在 `curl -v` 的输出中注意这句话 `Connected to en.wikipedia.org (172.21.156.230)`，其中提到了在您的服务输出中作为群集 IP 打印的 IP。 {{< text bash >}} $ kubectl exec -it $SOURCE_POD -c sleep -- curl -v --resolve en.wikipedia.org:443:$(kubectl get service my-wikipedia -o jsonpath='{.spec.clusterIP}') https://en.wikipedia.org/wiki/Main_Page -o /dev/null @@ -218,19 +218,19 @@ $ kubectl delete service my-wikipedia ## 清理{#cleanup} -1. 停止服务 [sleep]({{< github_tree >}}/samples/sleep)： +1. 停止服务 [sleep]({{< github_tree >}}/samples/sleep)： {{< text bash >}} $ kubectl delete -f @samples/sleep/sleep.yaml@ {{< /text >}} -1. 停止命名空间 `without-istio` 中的服务 [sleep]({{< github_tree >}}/samples/sleep)： +1. 停止命名空间 `without-istio` 中的服务 [sleep]({{< github_tree >}}/samples/sleep)： {{< text bash >}} $ kubectl delete -f @samples/sleep/sleep.yaml@ -n without-istio {{< /text >}} -1. 删除命名空间 `without-istio`： +1. 删除命名空间 `without-istio`： {{< text bash >}} $ kubectl delete namespace without-istio diff --git a/content/zh/docs/tasks/traffic-management/egress/egress-tls-origination/index.md b/content/zh/docs/tasks/traffic-management/egress/egress-tls-origination/index.md index caa676e2f4..8be70903c2 100644 --- a/content/zh/docs/tasks/traffic-management/egress/egress-tls-origination/index.md +++ b/content/zh/docs/tasks/traffic-management/egress/egress-tls-origination/index.md @@ -52,7 +52,7 @@ aliases: 首先，使用与 [Egress 流量控制](/zh/docs/tasks/traffic-management/egress/)任务中的相同的技术，配置对外部服务 `edition.cnn.com` 的访问。 但这一次我们将使用单个 `ServiceEntry` 来启用对服务的 HTTP 和 HTTPS 访问。 -1. 创建一个 `ServiceEntry` 和 `VirtualService` 以启用对 `edition.cnn.com` 的访问： +1. 创建一个 `ServiceEntry` 和 `VirtualService` 以启用对 `edition.cnn.com` 的访问： {{< text bash >}} $ kubectl apply -f - <}} -1. 向外部的 HTTP 服务发送请求： +1. 向外部的 HTTP 服务发送请求： {{< text bash >}} $ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - http://edition.cnn.com/politics @@ -126,7 +126,7 @@ aliases: ## 用于 egress 流量的 TLS 发起{#TLS-origination-for-egress-traffic} -1. 重新定义上一节的 `ServiceEntry` 和 `VirtualService` 以重写 HTTP 请求端口，并添加一个 `DestinationRule` 以执行 TLS 发起。 +1. 重新定义上一节的 `ServiceEntry` 和 `VirtualService` 以重写 HTTP 请求端口，并添加一个 `DestinationRule` 以执行 TLS 发起。 {{< text bash >}} $ kubectl apply -f - <}} $ kubectl exec -it $SOURCE_POD -c sleep -- curl -sL -o /dev/null -D - https://edition.cnn.com/politics @@ -228,7 +228,7 @@ _SNI_ 字段在 TLS 握手过程中以未加密的形式发送。 ## 清除{#cleanup} -1. 移除您创建的 Istio 配置项: +1. 移除您创建的 Istio 配置项: {{< text bash >}} $ kubectl delete serviceentry edition-cnn-com @@ -236,7 +236,7 @@ _SNI_ 字段在 TLS 握手过程中以未加密的形式发送。 $ kubectl delete destinationrule edition-cnn-com {{< /text >}} -1. 关闭 [sleep]({{< github_tree >}}/samples/sleep) 服务: +1. 关闭 [sleep]({{< github_tree >}}/samples/sleep) 服务: {{< text bash >}} $ kubectl delete -f @samples/sleep/sleep.yaml@ diff --git a/content/zh/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/index.md b/content/zh/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/index.md index 4ae3723c3c..e330e57a20 100644 --- a/content/zh/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/index.md +++ b/content/zh/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/index.md @@ -28,13 +28,13 @@ aliases: 由于已将出口流量配置为流经 egress 网关，因此可以 **安全地** 对出口流量应用监控和访问策略检查。 本节中，您将为流向 _*.wikipedia.org_ 的出口流量定义日志条目和访问策略。 -1. 创建日志记录配置： +1. 创建日志记录配置： {{< text bash >}} $ kubectl apply -f @samples/sleep/telemetry/sni-logging.yaml@ {{< /text >}} -1. 向 [https://en.wikipedia.org](https://en.wikipedia.org) 和 [https://de.wikipedia.org](https://de.wikipedia.org) +1. 向 [https://en.wikipedia.org](https://en.wikipedia.org) 和 [https://de.wikipedia.org](https://de.wikipedia.org) 发送 HTTPS 请求： {{< text bash >}} @@ -43,19 +43,19 @@ aliases: Wikipedia – Die freie Enzyklopädie {{< /text >}} -1. 检查 Mixer 日志。如果 Istio 部署在 `istio-system` 命名空间中，打印日志的命令为： +1. 检查 Mixer 日志。如果 Istio 部署在 `istio-system` 命名空间中，打印日志的命令为： {{< text bash >}} $ kubectl -n istio-system logs -l istio-mixer-type=telemetry -c mixer | grep 'egress-access' {{< /text >}} -1. 定义一个策略，该策略允许访问除 `en.wikipedia.org` 以外的所有 `*.wikipedia.org` 主机： +1. 定义一个策略，该策略允许访问除 `en.wikipedia.org` 以外的所有 `*.wikipedia.org` 主机： {{< text bash >}} $ kubectl apply -f @samples/sleep/policy/sni-wikipedia.yaml@ {{< /text >}} -1. 向处于黑名单中的 [Wikipedia in English](https://en.wikipedia.org) 发送 https 请求： +1. 向处于黑名单中的 [Wikipedia in English](https://en.wikipedia.org) 发送 https 请求： {{< text bash >}} $ kubectl exec -it $SOURCE_POD -c sleep -- sh -c 'curl -v https://en.wikipedia.org/wiki/Main_Page' @@ -66,7 +66,7 @@ aliases: 根据您定义的策略，对 `en.wikipedia.org` 的访问被禁止了。 -1. 发送 HTTPS 请求到其它语言版本的 Wikipedia 站点，如 [https://es.wikipedia.org](https://es.wikipedia.org) 和 +1. 发送 HTTPS 请求到其它语言版本的 Wikipedia 站点，如 [https://es.wikipedia.org](https://es.wikipedia.org) 和 [https://de.wikipedia.org](https://de.wikipedia.org)： {{< text bash >}} @@ -91,7 +91,7 @@ $ kubectl delete -f @samples/sleep/policy/sni-wikipedia.yaml@ 本小节中，您将在 `sleep-us` 和 `sleep-canada` 服务账户下分别部署 `sleep-us` 和 `sleep-canada` 两个容器。 然后定义一个策略，该策略允许具有 `sleep-us` 标识的应用访问 English 和 Spanish 版本的 Wikipedia 站点，并允许具有 `sleep-canada` 身份标识的应用访问 English 和 French 版本的 Wikipedia 站点。 -1. 在 `sleep-us` 和 `sleep-canada` 服务账户下分别部署 `sleep-us` 和 `sleep-canada` 两个容器： +1. 在 `sleep-us` 和 `sleep-canada` 服务账户下分别部署 `sleep-us` 和 `sleep-canada` 两个容器： {{< text bash >}} $ sed 's/: sleep/: sleep-us/g' @samples/sleep/sleep.yaml@ | kubectl apply -f - @@ -104,13 +104,13 @@ $ kubectl delete -f @samples/sleep/policy/sni-wikipedia.yaml@ deployment "sleep-canada" created {{< /text >}} -1. 创建日志记录配置: +1. 创建日志记录配置: {{< text bash >}} $ kubectl apply -f @samples/sleep/telemetry/sni-logging.yaml@ {{< /text >}} -1. 从 `sleep-us` 发送 HTTPS 请求至 English、German、Spanish 和 French 版本的 Wikipedia 站点： +1. 从 `sleep-us` 发送 HTTPS 请求至 English、German、Spanish 和 French 版本的 Wikipedia 站点： {{< text bash >}} $ kubectl exec -it $(kubectl get pod -l app=sleep-us -o jsonpath='{.items[0].metadata.name}') -c sleep-us -- sh -c 'curl -s https://en.wikipedia.org/wiki/Main_Page | grep -o ".*"; curl -s https://de.wikipedia.org/wiki/Wikipedia:Hauptseite | grep -o ".*"; curl -s https://es.wikipedia.org/wiki/Wikipedia:Portada | grep -o ".*"; curl -s https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal | grep -o ".*"' @@ -120,7 +120,7 @@ $ kubectl delete -f @samples/sleep/policy/sni-wikipedia.yaml@ Wikipédia, l'encyclopédie libre {{< /text >}} -1. 检查 Mixer 日志。如果 Istio 部署在 `istio-system` 命名空间中，打印日志的命令为： +1. 检查 Mixer 日志。如果 Istio 部署在 `istio-system` 命名空间中，打印日志的命令为： {{< text bash >}} $ kubectl -n istio-system logs -l istio-mixer-type=telemetry -c mixer | grep 'egress-access' @@ -132,7 +132,7 @@ $ kubectl delete -f @samples/sleep/policy/sni-wikipedia.yaml@ 注意 `requestedServerName` 属性，并且 `sourcePrincipal` 必须为 `cluster.local/ns/default/sa/sleep-us`。 -1. 定义一个策略，允许使用服务帐户 `sleep-us` 的应用程序访问 English 和 Spanish 版本的 Wikipedia， +1. 定义一个策略，允许使用服务帐户 `sleep-us` 的应用程序访问 English 和 Spanish 版本的 Wikipedia， 允许使用服务帐户 `sleep-canada` 的应用程序访问访问 English 和 French 版本的 Wikipedia。 如果这些应用尝试访问其他语种版本的 Wikipedia，访问将被阻止。 @@ -140,7 +140,7 @@ $ kubectl delete -f @samples/sleep/policy/sni-wikipedia.yaml@ $ kubectl apply -f @samples/sleep/policy/sni-serviceaccount.yaml@ {{< /text >}} -1. 再次从 `sleep-us` 发送 HTTPS 请求到 English、German、Spanish 和 French 版本的 Wikipedia： +1. 再次从 `sleep-us` 发送 HTTPS 请求到 English、German、Spanish 和 French 版本的 Wikipedia： {{< text bash >}} $ kubectl exec -it $(kubectl get pod -l app=sleep-us -o jsonpath='{.items[0].metadata.name}') -c sleep-us -- sh -c 'curl -s https://en.wikipedia.org/wiki/Main_Page | grep -o ".*"; curl -s https://de.wikipedia.org/wiki/Wikipedia:Hauptseite | grep -o ".*"; curl -s https://es.wikipedia.org/wiki/Wikipedia:Portada | grep -o ".*"; curl -s https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal | grep -o ".*";:' @@ -158,7 +158,7 @@ $ kubectl delete -f @samples/sleep/policy/sni-wikipedia.yaml@ $ kubectl delete pod -n istio-system -l istio-mixer-type=policy {{< /text >}} -1. 再次从 `sleep-canada` 发送 HTTPS 请求到 English、German、Spanish 和 French 站点： +1. 再次从 `sleep-canada` 发送 HTTPS 请求到 English、German、Spanish 和 French 站点： {{< text bash >}} $ kubectl exec -it $(kubectl get pod -l app=sleep-canada -o jsonpath='{.items[0].metadata.name}') -c sleep-canada -- sh -c 'curl -s https://en.wikipedia.org/wiki/Main_Page | grep -o ".*"; curl -s https://de.wikipedia.org/wiki/Wikipedia:Hauptseite | grep -o ".*"; curl -s https://es.wikipedia.org/wiki/Wikipedia:Portada | grep -o ".*"; curl -s https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal | grep -o ".*";:' @@ -180,9 +180,9 @@ $ kubectl delete -f @samples/sleep/policy/sni-serviceaccount.yaml@ ## 清除{#cleanup} -1. 执行[使用通配符主机配置 Egress 流量](/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/)任务的[清除步骤](/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/#cleanup-wildcard-configuration-for-arbitrary-domains)。 +1. 执行[使用通配符主机配置 Egress 流量](/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/)任务的[清除步骤](/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/#cleanup-wildcard-configuration-for-arbitrary-domains)。 -1. 关闭 [sleep]({{< github_tree >}}/samples/sleep) 服务: +1. 关闭 [sleep]({{< github_tree >}}/samples/sleep) 服务: {{< text bash >}} $ kubectl delete -f @samples/sleep/sleep.yaml@ diff --git a/content/zh/docs/tasks/traffic-management/egress/http-proxy/index.md b/content/zh/docs/tasks/traffic-management/egress/http-proxy/index.md index 85dc58743c..07f7dcfaca 100644 --- a/content/zh/docs/tasks/traffic-management/egress/http-proxy/index.md +++ b/content/zh/docs/tasks/traffic-management/egress/http-proxy/index.md @@ -24,7 +24,7 @@ aliases: $ kubectl create namespace external {{< /text >}} -1. 为 Squid 代理创建配置文件。 +1. 为 Squid 代理创建配置文件。 {{< text bash >}} $ cat < ./proxy.conf @@ -42,13 +42,13 @@ aliases: EOF {{< /text >}} -1. 创建 Kubernetes [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) 以保存代理的配置： +1. 创建 Kubernetes [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) 以保存代理的配置： {{< text bash >}} $ kubectl create configmap proxy-configmap -n external --from-file=squid.conf=./proxy.conf {{< /text >}} -1. 使用 Squid 部署容器： +1. 使用 Squid 部署容器： {{< text bash >}} $ kubectl apply -f - <}} -1. 在 `external` 命名空间中部署 [sleep]({{< github_tree >}}/samples/sleep) 示例，以测试到代理的通信量，而不进行 Istio 流量控制。 +1. 在 `external` 命名空间中部署 [sleep]({{< github_tree >}}/samples/sleep) 示例，以测试到代理的通信量，而不进行 Istio 流量控制。 {{< text bash >}} $ kubectl apply -n external -f @samples/sleep/sleep.yaml@ {{< /text >}} -1. 获取代理 pod 的 IP 地址并定义 `PROXY_IP` 环境变量来存储它： +1. 获取代理 pod 的 IP 地址并定义 `PROXY_IP` 环境变量来存储它： {{< text bash >}} $ export PROXY_IP=$(kubectl get pod -n external -l app=squid -o jsonpath={.items..podIP}) {{< /text >}} -1. 定义 `PROXY_PORT` 环境变量以存储代理的端口。本例子中 Squid 使用 3128 端口。 +1. 定义 `PROXY_PORT` 环境变量以存储代理的端口。本例子中 Squid 使用 3128 端口。 {{< text bash >}} $ export PROXY_PORT=3128 {{< /text >}} -1. 从 `external` 命名空间中的 sleep pod 通过代理向外部服务发送请求： +1. 从 `external` 命名空间中的 sleep pod 通过代理向外部服务发送请求： {{< text bash >}} $ kubectl exec -it $(kubectl get pod -n external -l app=sleep -o jsonpath={.items..metadata.name}) -n external -- sh -c "HTTPS_PROXY=$PROXY_IP:$PROXY_PORT curl https://en.wikipedia.org/wiki/Main_Page" | grep -o ".*" Wikipedia, the free encyclopedia {{< /text >}} -1. 检查您请求的代理的访问日志： +1. 检查您请求的代理的访问日志： {{< text bash >}} $ kubectl exec -it $(kubectl get pod -n external -l app=squid -o jsonpath={.items..metadata.name}) -n external -- tail -f /var/log/squid/access.log @@ -120,7 +120,7 @@ aliases: ## 配置流量到外部 HTTPS 代理{#configure-traffic-to-external-https-proxy} -1. 为 HTTPS 代理定义 TCP（不是 HTTP！）服务入口。尽管应用程序使用 HTTP CONNECT 方法与 HTTPS 代理建立连接，但必须为 TCP 通信而不是 HTTP 通信配置代理。一旦建立了连接，代理就简单地充当 TCP 隧道。 +1. 为 HTTPS 代理定义 TCP（不是 HTTP！）服务入口。尽管应用程序使用 HTTP CONNECT 方法与 HTTPS 代理建立连接，但必须为 TCP 通信而不是 HTTP 通信配置代理。一旦建立了连接，代理就简单地充当 TCP 隧道。 {{< text bash >}} $ kubectl apply -f - <}} -1. 从 `external` 命名空间中的 sleep pod 发送请求。因为 sleep pod 有 Sidecar，可以让 Istio 控制其流量。 +1. 从 `external` 命名空间中的 sleep pod 发送请求。因为 sleep pod 有 Sidecar，可以让 Istio 控制其流量。 {{< text bash >}} $ kubectl exec -it $SOURCE_POD -c sleep -- sh -c "HTTPS_PROXY=$PROXY_IP:$PROXY_PORT curl https://en.wikipedia.org/wiki/Main_Page" | grep -o ".*" Wikipedia, the free encyclopedia {{< /text >}} -1. 查看您的请求的 Istio SideCar 代理的日志： +1. 查看您的请求的 Istio SideCar 代理的日志： {{< text bash >}} $ kubectl logs $SOURCE_POD -c istio-proxy [2018-12-07T10:38:02.841Z] "- - -" 0 - 702 87599 92 - "-" "-" "-" "-" "172.30.109.95:3128" outbound|3128||my-company-proxy.com 172.30.230.52:44478 172.30.109.95:3128 172.30.230.52:44476 - {{< /text >}} -1. 查看您请求的代理的访问日志： +1. 查看您请求的代理的访问日志： {{< text bash >}} $ kubectl exec -it $(kubectl get pod -n external -l app=squid -o jsonpath={.items..metadata.name}) -n external -- tail -f /var/log/squid/access.log @@ -173,19 +173,19 @@ aliases: ## 清理{#cleanup} -1. 关闭 [sleep]({{< github_tree >}}/samples/sleep) 服务： +1. 关闭 [sleep]({{< github_tree >}}/samples/sleep) 服务： {{< text bash >}} $ kubectl delete -f @samples/sleep/sleep.yaml@ {{< /text >}} -1. 关闭 `external` 命名空间中的 [sleep]({{< github_tree >}}/samples/sleep) 服务： +1. 关闭 `external` 命名空间中的 [sleep]({{< github_tree >}}/samples/sleep) 服务： {{< text bash >}} $ kubectl delete -f @samples/sleep/sleep.yaml@ -n external {{< /text >}} -1. 关闭 Squid 代理，删除 ConfigMap 和配置文件： +1. 关闭 Squid 代理，删除 ConfigMap 和配置文件： {{< text bash >}} $ kubectl delete -n external deployment squid @@ -193,13 +193,13 @@ aliases: $ rm ./proxy.conf {{< /text >}} -1. 删除 `external` 命名空间： +1. 删除 `external` 命名空间： {{< text bash >}} $ kubectl delete namespace external {{< /text >}} -1. 删除 Service Entry： +1. 删除 Service Entry： {{< text bash >}} $ kubectl delete serviceentry proxy diff --git a/content/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/index.md b/content/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/index.md index bf9b1a98da..65a6fa516c 100644 --- a/content/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/index.md +++ b/content/zh/docs/tasks/traffic-management/egress/wildcard-egress-hosts/index.md @@ -24,7 +24,7 @@ aliases: 访问通用域中一组主机的第一个也是最简单的方法，是使用一个 wildcard 主机配置一个简单的 `ServiceEntry`，直接从 sidecar 调用服务。 当直接调用服务时（譬如：不是通过一个 egress 网关），一个 wildcard 主机的配置与任何其他主机（如：全域名主机）没有什么不同，只是当通用域中有许多台主机时，这样比较方便。 -1. 为 `*.wikipedia.org` 定义一个 `ServiceEntry` 以及相应的 `VirtualSevice`： +1. 为 `*.wikipedia.org` 定义一个 `ServiceEntry` 以及相应的 `VirtualSevice`： {{< text bash >}} $ kubectl apply -f - <}} -1. 发送 HTTPS 请求至 +1. 发送 HTTPS 请求至 [https://en.wikipedia.org](https://en.wikipedia.org) and [https://de.wikipedia.org](https://de.wikipedia.org): {{< text bash >}} @@ -87,7 +87,7 @@ $ kubectl delete virtualservice wikipedia 当一台唯一的服务器为所有 wildcard 主机提供服务时，基于 egress 网关访问 wildcard 主机的配置与普通主机类似，除了：配置的路由目标不能与配置的主机相同，如：wildcard 主机，需要配置为通用域集合的唯一服务器主机。 -1. 为 _*.wikipedia.org_ 创建一个 egress `Gateway`、一个目标规则以及一个虚拟服务，来引导请求通过 egress 网关并从 egress 网关访问外部服务。 +1. 为 _*.wikipedia.org_ 创建一个 egress `Gateway`、一个目标规则以及一个虚拟服务，来引导请求通过 egress 网关并从 egress 网关访问外部服务。 {{< text bash >}} $ kubectl apply -f - <}} -1. 为目标服务器 _www.wikipedia.org_ 创建一个 `ServiceEntry`。 +1. 为目标服务器 _www.wikipedia.org_ 创建一个 `ServiceEntry`。 {{< text bash >}} $ kubectl apply -f - <}} -1. 发送请求至 +1. 发送请求至 [https://en.wikipedia.org](https://en.wikipedia.org) 和 [https://de.wikipedia.org](https://de.wikipedia.org)： {{< text bash >}} @@ -223,7 +223,7 @@ $ kubectl delete destinationrule egressgateway-for-wikipedia 本章节，除了标准的 Istio Envoy 代理，您将再部署一个带 SNI 代理的 egress 网关。本示例使用 [Nginx](http://nginx.org) 作为 SNI 代理。任何一个能够根据任意的、非预先配置的 SNI 值路由流量的 SNI 代理均可。 SNI 代理将监听在端口 `8443` 上，您可以绑定任意其它端口，egress `Gateway` 和 `VirtualServices` 中配置的端口除外。SNI 代理将流量转发至端口 `443`。 -1. 创建一个 Nginx SNI 代理的配置文件。您可以按需编辑文件指定附加的 Nginx 设置。注意 `server` 的 `listen` 原语指定端口为 `8443`，其 `proxy_pass` 原语使用 `ssl_preread_server_name` 端口为 `443`，`ssl_preread` 为 `on` 以开启 `SNI` 读。 +1. 创建一个 Nginx SNI 代理的配置文件。您可以按需编辑文件指定附加的 Nginx 设置。注意 `server` 的 `listen` 原语指定端口为 `8443`，其 `proxy_pass` 原语使用 `ssl_preread_server_name` 端口为 `443`，`ssl_preread` 为 `on` 以开启 `SNI` 读。 {{< text bash >}} $ cat < ./sni-proxy.conf @@ -250,14 +250,14 @@ SNI 代理将监听在端口 `8443` 上，您可以绑定任意其它端口，eg EOF {{< /text >}} -1. 创建一个 Kubernetes [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) +1. 创建一个 Kubernetes [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) 来保存 Nginx SNI 代理的配置文件： {{< text bash >}} $ kubectl create configmap egress-sni-proxy-configmap -n istio-system --from-file=nginx.conf=./sni-proxy.conf {{< /text >}} -1. 下面的命令将生成 `istio-egressgateway-with-sni-proxy.yaml`，您可以选择性编辑该配置文件然后部署。 +1. 下面的命令将生成 `istio-egressgateway-with-sni-proxy.yaml`，您可以选择性编辑该配置文件然后部署。 {{< text bash >}} $ cat < ./istio-egressgateway-with-sni-proxy.yaml @@ -302,7 +302,7 @@ SNI 代理将监听在端口 `8443` 上，您可以绑定任意其它端口，eg EOF {{< /text >}} -1. 部署新的 egress 网关： +1. 部署新的 egress 网关： {{< text bash >}} $ kubectl apply -f ./istio-egressgateway-with-sni-proxy.yaml @@ -314,7 +314,7 @@ SNI 代理将监听在端口 `8443` 上，您可以绑定任意其它端口，eg horizontalpodautoscaler "istio-egressgateway-with-sni-proxy" created {{< /text >}} -1. 验证新的 egress 网关正在运行。注意 pod 有两个容器（一个是 Envoy 代理，另一个是 SNI 代理）。 +1. 验证新的 egress 网关正在运行。注意 pod 有两个容器（一个是 Envoy 代理，另一个是 SNI 代理）。 {{< text bash >}} $ kubectl get pod -l istio=egressgateway-with-sni-proxy -n istio-system @@ -322,7 +322,7 @@ SNI 代理将监听在端口 `8443` 上，您可以绑定任意其它端口，eg istio-egressgateway-with-sni-proxy-79f6744569-pf9t2 2/2 Running 0 17s {{< /text >}} -1. 创建一个 service entry，静态地址为 127.0.0.1 (`localhost`)，关闭发送至新 service entry 的双向 TLS 请求。 +1. 创建一个 service entry，静态地址为 127.0.0.1 (`localhost`)，关闭发送至新 service entry 的双向 TLS 请求。 {{< text bash >}} $ kubectl apply -f - <}} $ cat <}} -1. 为 _*.wikipedia.org_ 创建一个 egress `Gateway`，端口 443，协议 TLS，以及一个虚拟服务负责引导目标为 _*.wikipedia.org_ 的流量流经网关。 +1. 为 _*.wikipedia.org_ 创建一个 egress `Gateway`，端口 443，协议 TLS，以及一个虚拟服务负责引导目标为 _*.wikipedia.org_ 的流量流经网关。 根据您是否希望在源 pod 与 egress 网关之间开启 [双向 TLS 认证](/zh/docs/tasks/security/authentication/mutual-tls/)，选择指令。 @@ -571,7 +571,7 @@ SNI 代理将监听在端口 `8443` 上，您可以绑定任意其它端口，eg {{< /tabset >}} -1. 发送 HTTPS 请求至 +1. 发送 HTTPS 请求至 [https://en.wikipedia.org](https://en.wikipedia.org) and [https://de.wikipedia.org](https://de.wikipedia.org): {{< text bash >}} @@ -580,7 +580,7 @@ SNI 代理将监听在端口 `8443` 上，您可以绑定任意其它端口，eg Wikipedia – Die freie Enzyklopädie {{< /text >}} -1. 检查 Egress 网关 Envoy 代理的日志。如果 Istio 被部署在 `istio-system` 命名空间中，打印日志的命令为： +1. 检查 Egress 网关 Envoy 代理的日志。如果 Istio 被部署在 `istio-system` 命名空间中，打印日志的命令为： {{< text bash >}} $ kubectl logs -l istio=egressgateway-with-sni-proxy -c istio-proxy -n istio-system @@ -593,7 +593,7 @@ SNI 代理将监听在端口 `8443` 上，您可以绑定任意其它端口，eg [2019-01-02T16:34:24.079Z] "- - -" 0 - 586 65770 638 - "-" "-" "-" "-" "127.0.0.1:8443" outbound|8443||sni-proxy.local 127.0.0.1:55034 172.30.109.84:443 172.30.109.112:45362 de.wikipedia.org {{< /text >}} -1. 检查 SNI 代理的日志。如果 Istio 被部署在 `istio-system` 命名空间中，打印日志的命令为： +1. 检查 SNI 代理的日志。如果 Istio 被部署在 `istio-system` 命名空间中，打印日志的命令为： {{< text bash >}} $ kubectl logs -l istio=egressgateway-with-sni-proxy -n istio-system -c sni-proxy @@ -601,7 +601,7 @@ SNI 代理将监听在端口 `8443` 上，您可以绑定任意其它端口，eg 127.0.0.1 [01/Aug/2018:15:32:03 +0000] TCP [de.wikipedia.org]200 67745 291 0.659 {{< /text >}} -1. 检查 mixer 日志。如果 Istio 部署在 `istio-system` 命名空间中，打印日志的命令为： +1. 检查 mixer 日志。如果 Istio 部署在 `istio-system` 命名空间中，打印日志的命令为： {{< text bash >}} $ kubectl -n istio-system logs -l istio-mixer-type=telemetry -c mixer | grep '"connectionEvent":"open"' | grep '"sourceName":"istio-egressgateway' | grep 'wikipedia.org' @@ -612,7 +612,7 @@ SNI 代理将监听在端口 `8443` 上，您可以绑定任意其它端口，eg #### 清除任意域的 wildcard 配置{#cleanup-wildcard-configuration-for-arbitrary-domains} -1. 删除 _*.wikipedia.org_ 的配置项： +1. 删除 _*.wikipedia.org_ 的配置项： {{< text bash >}} $ kubectl delete serviceentry wikipedia @@ -622,7 +622,7 @@ SNI 代理将监听在端口 `8443` 上，您可以绑定任意其它端口，eg $ kubectl delete --ignore-not-found=true envoyfilter forward-downstream-sni egress-gateway-sni-verifier {{< /text >}} -1. 删除部署 `egressgateway-with-sni-proxy` 的配置项： +1. 删除部署 `egressgateway-with-sni-proxy` 的配置项： {{< text bash >}} $ kubectl delete serviceentry sni-proxy @@ -631,7 +631,7 @@ SNI 代理将监听在端口 `8443` 上，您可以绑定任意其它端口，eg $ kubectl delete configmap egress-sni-proxy-configmap -n istio-system {{< /text >}} -1. 删除您创建的配置文件： +1. 删除您创建的配置文件： {{< text bash >}} $ rm ./istio-egressgateway-with-sni-proxy.yaml diff --git a/content/zh/docs/tasks/traffic-management/fault-injection/index.md b/content/zh/docs/tasks/traffic-management/fault-injection/index.md index 538fc5b964..2b3961df45 100644 --- a/content/zh/docs/tasks/traffic-management/fault-injection/index.md +++ b/content/zh/docs/tasks/traffic-management/fault-injection/index.md @@ -26,8 +26,8 @@ aliases: {{< /text >}} * 经过上面的配置，下面是请求的流程： - * `productpage` → `reviews:v2` → `ratings` (针对 `jason` 用户) - * `productpage` → `reviews:v1` (其他用户) + * `productpage` → `reviews:v2` → `ratings` (针对 `jason` 用户) + * `productpage` → `reviews:v1` (其他用户) ## 注入 HTTP 延迟故障{#injecting-an-http-delay-fault} diff --git a/content/zh/docs/tasks/traffic-management/ingress/ingress-certmgr/index.md b/content/zh/docs/tasks/traffic-management/ingress/ingress-certmgr/index.md index 83dbcf4f80..a50bf3ef78 100644 --- a/content/zh/docs/tasks/traffic-management/ingress/ingress-certmgr/index.md +++ b/content/zh/docs/tasks/traffic-management/ingress/ingress-certmgr/index.md @@ -24,7 +24,7 @@ aliases: {{< /text >}} {{< tip >}} - 默认情况下， `istio-ingressgateway` 会以 `LoadBalancer` 的服务类型开放出来。您可以根据自己的 Kubernetes 环境把 `gateways.istio-ingressgateway.type` 设置为 `NodePort`。 + 默认情况下，`istio-ingressgateway` 会以 `LoadBalancer` 的服务类型开放出来。您可以根据自己的 Kubernetes 环境把 `gateways.istio-ingressgateway.type` 设置为 `NodePort`。 {{< /tip >}} 1. [安装 cert-manager](https://docs.cert-manager.io/en/latest/getting-started/install/kubernetes.html) 以便实现证书的自动管理。 diff --git a/content/zh/docs/tasks/traffic-management/ingress/ingress-control/index.md b/content/zh/docs/tasks/traffic-management/ingress/ingress-control/index.md index 66c99722d1..c391acdb03 100644 --- a/content/zh/docs/tasks/traffic-management/ingress/ingress-control/index.md +++ b/content/zh/docs/tasks/traffic-management/ingress/ingress-control/index.md @@ -35,7 +35,7 @@ istio-ingressgateway LoadBalancer 172.21.109.129 130.211.10.121 80:31380/ {{< /text >}} 如果 `EXTERNAL-IP` 值已设置，说明环境正在使用外部负载均衡，可以用其为 ingress gateway 提供服务。 -如果 `EXTERNAL-IP` 值为 `` （或持续显示 ``）， 说明环境没有提供外部负载均衡，无法使用 ingress gateway。 +如果 `EXTERNAL-IP` 值为 `` （或持续显示 ``），说明环境没有提供外部负载均衡，无法使用 ingress gateway。 在这种情况下，你可以使用服务的 [node port](https://kubernetes.io/docs/concepts/services-networking/service/#nodeport) 访问网关。 选择符合自身环境的指令执行： @@ -106,7 +106,7 @@ $ export SECURE_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingress $ export INGRESS_HOST=127.0.0.1 {{< /text >}} -1. _其他环境（如：IBM Cloud Private 等）：_ +1. _其他环境（如：IBM Cloud Private 等）：_ {{< text bash >}} $ export INGRESS_HOST=$(kubectl get po -l istio=ingressgateway -n istio-system -o jsonpath='{.items[0].status.hostIP}') @@ -124,7 +124,7 @@ Ingress [Gateway](/zh/docs/reference/config/networking/gateway/) 描述运行在 让我们一起来看如何为 HTTP 流量在 80 端口上配置 `Gateway`。 -1. 创建 Istio `Gateway`： +1. 创建 Istio `Gateway`： {{< text bash >}} $ kubectl apply -f - <}} -1. 为通过 `Gateway` 的入口流量配置路由： +1. 为通过 `Gateway` 的入口流量配置路由： {{< text bash >}} $ kubectl apply -f - <}} 来自网格内部其他服务的内部请求无需遵循这些规则，而是默认遵守轮询调度路由规则。 你可以为 `gateways` 列表添加特定的 `mesh` 值，将这些规则同时应用到内部请求。 - 由于服务的内部主机名可能与外部主机名不一致（譬如： `httpbin.default.svc.cluster.local`），你需要同时将内部主机名添加到 `hosts` 列表中。 + 由于服务的内部主机名可能与外部主机名不一致（譬如：`httpbin.default.svc.cluster.local`），你需要同时将内部主机名添加到 `hosts` 列表中。 详情请参考[操作指南](/zh/docs/ops/common-problems/network-issues#route-rules-have-no-effect-on-ingress-gateway-requests)。 {{< /warning >}} -1. 使用 _curl_ 访问 _httpbin_ 服务： +1. 使用 _curl_ 访问 _httpbin_ 服务： {{< text bash >}} $ curl -I -HHost:httpbin.example.com http://$INGRESS_HOST:$INGRESS_PORT/status/200 @@ -201,7 +201,7 @@ Ingress [Gateway](/zh/docs/reference/config/networking/gateway/) 描述运行在 注意上文命令使用 `-H` 标识将 HTTP 头部参数 _Host_ 设置为 "httpbin.example.com"。 该操作为必须操作，因为 ingress `Gateway` 已被配置用来处理 "httpbin.example.com" 的服务请求，而在测试环境中并没有为该主机绑定 DNS 而是简单直接地向 ingress IP 发送请求。 -1. 访问其他没有被显式暴露的 URL 时，将看到 HTTP 404 错误： +1. 访问其他没有被显式暴露的 URL 时，将看到 HTTP 404 错误： {{< text bash >}} $ curl -I -HHost:httpbin.example.com http://$INGRESS_HOST:$INGRESS_PORT/headers @@ -213,7 +213,7 @@ Ingress [Gateway](/zh/docs/reference/config/networking/gateway/) 描述运行在 ## 通过浏览器访问 ingress 服务{#accessing-ingress-services-using-a-browser} -在浏览器中输入 `httpbin` 服务的 URL 不能获得有效的响应，因为无法像 `curl` 那样，将请求头部参数 _Host_ 传给浏览器。在现实场景中，这并不是问题，因为你需要合理配置被请求的主机及可解析的 DNS，从而在 URL 中使用主机的域名，譬如： `https://httpbin.example.com/status/200`。 +在浏览器中输入 `httpbin` 服务的 URL 不能获得有效的响应，因为无法像 `curl` 那样，将请求头部参数 _Host_ 传给浏览器。在现实场景中，这并不是问题，因为你需要合理配置被请求的主机及可解析的 DNS，从而在 URL 中使用主机的域名，譬如：`https://httpbin.example.com/status/200`。 为了在简单的测试和演示中绕过这个问题，请在 `Gateway` 和 `VirtualService` 配置中使用通配符 `*`。譬如，修改 ingress 配置如下： @@ -265,30 +265,30 @@ EOF ## 问题排查{#troubleshooting} -1. 检查环境变量 `INGRESS_HOST` and `INGRESS_PORT`。确保环境变量的值有效，命令如下： +1. 检查环境变量 `INGRESS_HOST` and `INGRESS_PORT`。确保环境变量的值有效，命令如下： {{< text bash >}} $ kubectl get svc -n istio-system $ echo INGRESS_HOST=$INGRESS_HOST, INGRESS_PORT=$INGRESS_PORT {{< /text >}} -1. 检查没有在相同的端口上定义其它 Istio ingress gateways： +1. 检查没有在相同的端口上定义其它 Istio ingress gateways： {{< text bash >}} $ kubectl get gateway --all-namespaces {{< /text >}} -1. 检查没有在相同的 IP 和端口上定义 Kubernetes Ingress 资源： +1. 检查没有在相同的 IP 和端口上定义 Kubernetes Ingress 资源： {{< text bash >}} $ kubectl get ingress --all-namespaces {{< /text >}} -1. 如果使用了外部负载均衡器，该外部负载均衡器无法正常工作，尝试[通过 node port 访问 gateway](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports)。 +1. 如果使用了外部负载均衡器，该外部负载均衡器无法正常工作，尝试[通过 node port 访问 gateway](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports)。 ## 清除{#cleanup} -删除 `Gateway` 和 `VirtualService` 配置， 并关闭服务 [httpbin]({{< github_tree >}}/samples/httpbin)： +删除 `Gateway` 和 `VirtualService` 配置，并关闭服务 [httpbin]({{< github_tree >}}/samples/httpbin)： {{< text bash >}} $ kubectl delete gateway httpbin-gateway diff --git a/content/zh/docs/tasks/traffic-management/ingress/ingress-sni-passthrough/index.md b/content/zh/docs/tasks/traffic-management/ingress/ingress-sni-passthrough/index.md index 43834e2c39..b0a30b1e97 100644 --- a/content/zh/docs/tasks/traffic-management/ingress/ingress-sni-passthrough/index.md +++ b/content/zh/docs/tasks/traffic-management/ingress/ingress-sni-passthrough/index.md @@ -19,13 +19,13 @@ aliases: 对于此任务，您可以使用自己喜欢的工具来生成证书和密钥。以下命令使用 [openssl](https://man.openbsd.org/openssl.1) -1. 创建根证书和私钥来为您的服务签名证书： +1. 创建根证书和私钥来为您的服务签名证书： {{< text bash >}} $ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -subj '/O=example Inc./CN=example.com' -keyout example.com.key -out example.com.crt {{< /text >}} -1. 为 `nginx.example.com` 创建证书和私钥： +1. 为 `nginx.example.com` 创建证书和私钥： {{< text bash >}} $ openssl req -out nginx.example.com.csr -newkey rsa:2048 -nodes -keyout nginx.example.com.key -subj "/CN=nginx.example.com/O=some organization" @@ -34,13 +34,13 @@ aliases: ## 部署一个 NGINX 服务{#deploy-an-nginx-server} -1. 创建一个 Kubernetes 的 [Secret](https://kubernetes.io/docs/concepts/configuration/secret/) 资源来保存服务的证书： +1. 创建一个 Kubernetes 的 [Secret](https://kubernetes.io/docs/concepts/configuration/secret/) 资源来保存服务的证书： {{< text bash >}} $ kubectl create secret tls nginx-server-certs --key nginx.example.com.key --cert nginx.example.com.crt {{< /text >}} -1. 为 NGINX 服务创建一个配置文件： +1. 为 NGINX 服务创建一个配置文件： {{< text bash >}} $ cat < ./nginx.conf @@ -68,13 +68,13 @@ aliases: EOF {{< /text >}} -1. 创建一个 Kubernetes 的 [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) 资源来保存 NGINX 服务的配置： +1. 创建一个 Kubernetes 的 [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) 资源来保存 NGINX 服务的配置： {{< text bash >}} $ kubectl create configmap nginx-configmap --from-file=nginx.conf=./nginx.conf {{< /text >}} -1. 部署 NGINX 服务 +1. 部署 NGINX 服务 {{< text bash >}} $ cat <}} -1. 要测试 NGINX 服务是否已成功部署，需要从其 sidecar 代理发送请求，并忽略检查服务端的证书（使用 curl 的 -k 选项）。确保正确打印服务端的证书，即 `common name` 等于 `nginx.example.com`。 +1. 要测试 NGINX 服务是否已成功部署，需要从其 sidecar 代理发送请求，并忽略检查服务端的证书（使用 curl 的 -k 选项）。确保正确打印服务端的证书，即 `common name` 等于 `nginx.example.com`。 {{< text bash >}} $ kubectl exec -it $(kubectl get pod -l run=my-nginx -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl -v -k --resolve nginx.example.com:443:127.0.0.1 https://nginx.example.com @@ -162,7 +162,7 @@ aliases: ## 配置 ingress gateway{#configure-an-ingress-gateway} -1. 定义一个 `server` 部分的端口为 443 的 `Gateway`。 注意，`PASSTHROUGH tls mode` 指示 gateway 按原样通过入口流量，而不终止 TLS。 +1. 定义一个 `server` 部分的端口为 443 的 `Gateway`。注意，`PASSTHROUGH tls mode` 指示 gateway 按原样通过入口流量，而不终止 TLS。 {{< text bash >}} $ kubectl apply -f - <}} -1. 配置通过 `Gateway` 进入的流量的路由： +1. 配置通过 `Gateway` 进入的流量的路由： {{< text bash >}} $ kubectl apply -f - <}} -1. 根据[确定 ingress IP 和端口](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports)中的指令来定义环境变量 `SECURE_INGRESS_PORT` 和 `INGRESS_HOST`。 +1. 根据[确定 ingress IP 和端口](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports)中的指令来定义环境变量 `SECURE_INGRESS_PORT` 和 `INGRESS_HOST`。 -1. 从集群外访问 NGINX 服务。注意，服务端返回了正确的证书，并且该证书已成功验证（输出了 _SSL certificate verify ok_ ）。 +1. 从集群外访问 NGINX 服务。注意，服务端返回了正确的证书，并且该证书已成功验证（输出了 _SSL certificate verify ok_ ）。 {{< text bash >}} $ curl -v --resolve nginx.example.com:$SECURE_INGRESS_PORT:$INGRESS_HOST --cacert example.com.crt https://nginx.example.com:$SECURE_INGRESS_PORT @@ -234,7 +234,7 @@ aliases: ## 清除{#cleanup} -1. 删除已创建的 Kubernetes 资源： +1. 删除已创建的 Kubernetes 资源： {{< text bash >}} $ kubectl delete secret nginx-server-certs @@ -245,13 +245,13 @@ aliases: $ kubectl delete virtualservice nginx {{< /text >}} -1. 删除证书和密钥： +1. 删除证书和密钥： {{< text bash >}} $ rm example.com.crt example.com.key nginx.example.com.crt nginx.example.com.key nginx.example.com.csr {{< /text >}} -1. 删除本示例中生成的配置文件： +1. 删除本示例中生成的配置文件： {{< text bash >}} $ rm ./nginx.conf diff --git a/content/zh/docs/tasks/traffic-management/ingress/secure-ingress-sds/index.md b/content/zh/docs/tasks/traffic-management/ingress/secure-ingress-sds/index.md index 3c36df0924..d3582e2284 100644 --- a/content/zh/docs/tasks/traffic-management/ingress/secure-ingress-sds/index.md +++ b/content/zh/docs/tasks/traffic-management/ingress/secure-ingress-sds/index.md @@ -27,7 +27,7 @@ keywords: [traffic-management,ingress,sds-credentials] 如果上面的命令输出了一段 LibreSSL 的版本信息，就说明你的 `curl` 命令可以完成本任务的内容。否则就要想办法换一个不同的 `curl` 了，例如可以换用一台运行 Linux 的工作站。 {{< tip >}} -如果使用[基于文件安装的方法](/zh/docs/tasks/traffic-management/ingress/secure-ingress-mount)配置了 ingress gateway ，并且想要迁移 ingress gateway 使用 SDS 方法。 无需其他步骤。 +如果使用[基于文件安装的方法](/zh/docs/tasks/traffic-management/ingress/secure-ingress-mount)配置了 ingress gateway ，并且想要迁移 ingress gateway 使用 SDS 方法。无需其他步骤。 {{< /tip >}} ## 为服务器和客户端生成证书 {#generate-client-and-server-certificates-and-keys} @@ -96,7 +96,7 @@ keywords: [traffic-management,ingress,sds-credentials] get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}') {{< /text >}} -### 为单一主机配置 TLS Ingress Gateway {#configure-a-TLS-ingress-gateway-for-a-single-host} +### 为单一主机配置 TLS Ingress Gateway {#configure-a-TLS-ingress-gateway-for-a-single-host} 1. 启动 `httpbin` 样例： @@ -152,7 +152,7 @@ keywords: [traffic-management,ingress,sds-credentials] secret name **不能** 以 `istio` 或者 `prometheus`为开头, 且 secret **不能** 包含 `token` 字段。 {{< /warning >}} -1. 创建一个 Gateway ，其 `servers:` 字段的端口为 443，设置 `credentialName` 的值为 `httpbin-credential`。这个值就是 `Secret` 的名字。TLS 模式设置为 `SIMPLE`。 +1. 创建一个 Gateway ，其 `servers:` 字段的端口为 443，设置 `credentialName` 的值为 `httpbin-credential`。这个值就是 `Secret` 的名字。TLS 模式设置为 `SIMPLE`。 {{< text bash >}} $ cat <}} -1. 配置 Gateway 的 Ingress 流量路由，并配置对应的 `VirtualService`：： +1. 配置 Gateway 的 Ingress 流量路由，并配置对应的 `VirtualService`： {{< text bash >}} $ cat <}} -1. 为 Ingress Gateway 创建一个 Secret。如果已经创建了 `httpbin-credential`，就可以创建 `helloworld-credential` Secret 了。 +1. 为 Ingress Gateway 创建一个 Secret。如果已经创建了 `httpbin-credential`，就可以创建 `helloworld-credential` Secret 了。 {{< text bash >}} $ pushd mtls-go-example @@ -422,7 +422,7 @@ keywords: [traffic-management,ingress,sds-credentials] `"""` {{< /text >}} -### 配置双向 TLS Ingress Gateway {#configure-a-mutual-TLS-ingress-gateway} +### 配置双向 TLS Ingress Gateway {#configure-a-mutual-TLS-ingress-gateway} 可以对 Gateway 的定义进行扩展，加入[双向 TLS](https://en.wikipedia.org/wiki/Mutual_authentication) 的支持。要修改 Ingress Gateway 的凭据，就要删除并重建对应的 `Secret`。服务器会使用 CA 证书对客户端进行校验，因此需要使用 `cacert` 字段来保存 CA 证书： @@ -549,7 +549,7 @@ $ kubectl create -n istio-system secret generic httpbin-credential \ -n istio-system -o jsonpath='{.items[0].metadata.name}') -c ingress-sds {{< /text >}} - 正常情况下，日志中应该显示 `httpbin-credential` 已经成功创建。如果使用的是双向 TLS，还应该看到 `httpbin-credential-cacert`。通过对日志的查看，能够验证 Ingress Gateway 代理从 Ingress Gateway 收到了 SDS 请求，资源名称是 `httpbin-credential`，Ingress Gateway 最后得到了应有的密钥/证书对。如果使用的是双向 TLS，日志会显示出密钥/证书对已经发送给 Ingress Gateway ， Gateway 代理接收到了资源名为 `httpbin-credential-cacert` 的 SDS 请求，Ingress Gateway 用这种方式获取根证书。 + 正常情况下，日志中应该显示 `httpbin-credential` 已经成功创建。如果使用的是双向 TLS，还应该看到 `httpbin-credential-cacert`。通过对日志的查看，能够验证 Ingress Gateway 代理从 Ingress Gateway 收到了 SDS 请求，资源名称是 `httpbin-credential`，Ingress Gateway 最后得到了应有的密钥/证书对。如果使用的是双向 TLS，日志会显示出密钥/证书对已经发送给 Ingress Gateway ，Gateway 代理接收到了资源名为 `httpbin-credential-cacert` 的 SDS 请求，Ingress Gateway 用这种方式获取根证书。 ## 清理 {#cleanup} diff --git a/content/zh/docs/tasks/traffic-management/mirroring/index.md b/content/zh/docs/tasks/traffic-management/mirroring/index.md index eb92e9915a..3ae680df53 100644 --- a/content/zh/docs/tasks/traffic-management/mirroring/index.md +++ b/content/zh/docs/tasks/traffic-management/mirroring/index.md @@ -129,7 +129,7 @@ keywords: [traffic-management,mirroring] 默认情况下，Kubernetes 在 `httpbin` 服务的两个版本之间进行负载均衡。在此步骤中会更改该行为，把所有流量都路由到 `v1`。 -1. 创建一个默认路由规则，将所有流量路由到服务的 `v1`： +1. 创建一个默认路由规则，将所有流量路由到服务的 `v1`： {{< warning >}} 如果安装/配置 Istio 的时候开启了 TLS 认证，在应用 `DestinationRule` 之前必须将 TLS 流量策略 `mode: ISTIO_MUTUAL` 添加到 `DestinationRule`。否则，请求将发生 503 错误，如[设置目标规则后出现 503 错误](/zh/docs/ops/common-problems/network-issues/#service-unavailable-errors-after-setting-destination-rule)所述。 @@ -204,7 +204,7 @@ keywords: [traffic-management,mirroring] ## 镜像流量到 v2{#mirroring-traffic-to-v2} -1. 改变流量规则将流量镜像到 v2： +1. 改变流量规则将流量镜像到 v2： {{< text bash >}} $ kubectl apply -f - <}} $ kubectl delete virtualservice httpbin $ kubectl delete destinationrule httpbin {{< /text >}} -1. 关闭 [httpbin]({{< github_tree >}}/samples/httpbin) 服务和客户端： +1. 关闭 [httpbin]({{< github_tree >}}/samples/httpbin) 服务和客户端： {{< text bash >}} $ kubectl delete deploy httpbin-v1 httpbin-v2 sleep diff --git a/content/zh/docs/tasks/traffic-management/request-routing/index.md b/content/zh/docs/tasks/traffic-management/request-routing/index.md index 685dce4a14..41a76395e9 100644 --- a/content/zh/docs/tasks/traffic-management/request-routing/index.md +++ b/content/zh/docs/tasks/traffic-management/request-routing/index.md @@ -120,7 +120,7 @@ Istio [Bookinfo](/zh/docs/examples/bookinfo/) 示例包含四个独立的微服 您可以通过再次刷新 Bookinfo 应用程序的 `/productpage` 轻松测试新配置。 -1. 在浏览器中打开 Bookinfo 站点。 网址为 `http://$GATEWAY_URL/productpage`，其中 `$GATEWAY_URL` 是外部的入口 IP 地址，如 [Bookinfo](/zh/docs/examples/bookinfo/#determine-the-ingress-IP-and-port) 文档中所述。 +1. 在浏览器中打开 Bookinfo 站点。网址为 `http://$GATEWAY_URL/productpage`，其中 `$GATEWAY_URL` 是外部的入口 IP 地址，如 [Bookinfo](/zh/docs/examples/bookinfo/#determine-the-ingress-IP-and-port) 文档中所述。 请注意，无论您刷新多少次，页面的评论部分都不会显示评级星标。这是因为您将 Istio 配置为 将评论服务的所有流量路由到版本 `reviews:v1`，而此版本的服务不访问星级评分服务。 @@ -131,7 +131,7 @@ Istio [Bookinfo](/zh/docs/examples/bookinfo/) 示例包含四个独立的微服 接下来，您将更改路由配置，以便将来自特定用户的所有流量路由到特定服务版本。在这，来自名为 Jason 的用户的所有流量将被路由到服务 `reviews:v2`。 -请注意，Istio 对用户身份没有任何特殊的内置机制。事实上， `productpage` 服务在所有到 `reviews` 服务的 HTTP 请求中都增加了一个自定义的 `end-user` 请求头，从而达到了本例子的效果。 +请注意，Istio 对用户身份没有任何特殊的内置机制。事实上，`productpage` 服务在所有到 `reviews` 服务的 HTTP 请求中都增加了一个自定义的 `end-user` 请求头，从而达到了本例子的效果。 请记住，`reviews:v2` 是包含星级评分功能的版本。 diff --git a/content/zh/docs/tasks/traffic-management/tcp-traffic-shifting/index.md b/content/zh/docs/tasks/traffic-management/tcp-traffic-shifting/index.md index e4956da229..97daf035b9 100644 --- a/content/zh/docs/tasks/traffic-management/tcp-traffic-shifting/index.md +++ b/content/zh/docs/tasks/traffic-management/tcp-traffic-shifting/index.md @@ -21,9 +21,9 @@ aliases: ## 应用基于权重的 TCP 路由{#apply-weight-based-tcp-routing} -1. 首先，部署微服务 `tcp-echo` 的 `v1` 版本。 +1. 首先，部署微服务 `tcp-echo` 的 `v1` 版本。 - * 第一步，为测试 TCP 流量转移创建命名空间 + * 第一步，为测试 TCP 流量转移创建命名空间 {{< text bash >}} $ kubectl create namespace istio-io-tcp-traffic-shifting @@ -50,13 +50,13 @@ aliases: $ kubectl apply -f @samples/tcp-echo/tcp-echo-services.yaml@ -n istio-io-tcp-traffic-shifting {{< /text >}} -1. 接下来, 将目标为微服务 `tcp-echo` 的 TCP 流量全部路由到 `v1` 版本。 +1. 接下来, 将目标为微服务 `tcp-echo` 的 TCP 流量全部路由到 `v1` 版本。 {{< text bash >}} $ kubectl apply -f @samples/tcp-echo/tcp-echo-all-v1.yaml@ -n istio-io-tcp-traffic-shifting {{< /text >}} -1. 确认 `tcp-echo` 服务已启动并开始运行。 +1. 确认 `tcp-echo` 服务已启动并开始运行。 下面的 `$INGRESS_HOST` 变量是 ingress 的外部 IP 地址，可参考 [Ingress Gateways](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports) 文档。要获取 `$INGRESS_PORT` 变量的值，请使用以下命令。 @@ -88,7 +88,7 @@ aliases: 您应该注意到，所有时间戳的前缀都是 _one_ ，这意味着所有流量都被路由到了 `tcp-echo` 服务的 `v1` 版本。 -1. 使用以下命令将 20% 的流量从 `tcp-echo:v1` 转移到 `tcp-echo:v2`： +1. 使用以下命令将 20% 的流量从 `tcp-echo:v1` 转移到 `tcp-echo:v2`： {{< text bash >}} $ kubectl apply -f @samples/tcp-echo/tcp-echo-20-v2.yaml@ -n istio-io-tcp-traffic-shifting @@ -96,7 +96,7 @@ aliases: 等待几秒钟，以使新规则在集群中传播和生效。 -1. 确认规则配置已替换完成： +1. 确认规则配置已替换完成： {{< text bash yaml >}} $ kubectl get virtualservice tcp-echo -o yaml -n istio-io-tcp-traffic-shifting @@ -125,7 +125,7 @@ aliases: weight: 20 {{< /text >}} -1. 向 `tcp-echo` 服务发送更多 TCP 流量。 +1. 向 `tcp-echo` 服务发送更多 TCP 流量。 {{< text bash >}} $ for i in {1..10}; do \ diff --git a/content/zh/events/banners/kubecon-america-2019.md b/content/zh/events/banners/kubecon-america-2019.md index ae9386c65f..f7dadffcf3 100644 --- a/content/zh/events/banners/kubecon-america-2019.md +++ b/content/zh/events/banners/kubecon-america-2019.md @@ -6,4 +6,4 @@ max_impressions: 20 timeout: 20 --- -KubeCon 2019 北美会议， 11 月 18 日至 11 月 21 日，在圣地亚哥举办。 +KubeCon 2019 北美会议，11 月 18 日至 11 月 21 日，在圣地亚哥举办。 diff --git a/content/zh/events/banners/kubecon-europe-2020.md b/content/zh/events/banners/kubecon-europe-2020.md index 4a84a40846..6edb7d2ce9 100644 --- a/content/zh/events/banners/kubecon-europe-2020.md +++ b/content/zh/events/banners/kubecon-europe-2020.md @@ -6,4 +6,4 @@ max_impressions: 20 timeout: 20 --- -KubeCon 2020 欧洲会议， 3 月 30 日至 4 月 2 日，在阿姆斯特丹举办。 +KubeCon 2020 欧洲会议，3 月 30 日至 4 月 2 日，在阿姆斯特丹举办。 diff --git a/content/zh/faq/_index.md b/content/zh/faq/_index.md index 6ccbd568a5..95f9063fe8 100644 --- a/content/zh/faq/_index.md +++ b/content/zh/faq/_index.md @@ -10,4 +10,4 @@ aliases: icon: faq --- -您有问题吗？ 我们有答案！ +您有问题吗？我们有答案！ diff --git a/content/zh/faq/applications/cassandra.md b/content/zh/faq/applications/cassandra.md index d754f4cec9..5ff9e78ed5 100644 --- a/content/zh/faq/applications/cassandra.md +++ b/content/zh/faq/applications/cassandra.md @@ -5,7 +5,7 @@ weight: 50 keywords: [cassandra] --- -默认情况下，Cassandra 广播用于绑定（接受连接）到其他 Cassandra 节点的地址作为其地址。这通常是 Pod IP 地址，无需服务网格即可正常工作。但是，对于服务网格，此配置不起作用。Istio 和其他服务网格需要 `localhost` （`127.0.0.1`） 作为绑定地址。 +默认情况下，Cassandra 广播用于绑定（接受连接）到其他 Cassandra 节点的地址作为其地址。这通常是 Pod IP 地址，无需服务网格即可正常工作。但是，对于服务网格，此配置不起作用。Istio 和其他服务网格需要 `localhost` （`127.0.0.1`）作为绑定地址。 有两个配置参数要注意： [`listen_address`](http://cassandra.apache.org/doc/latest/configuration/cassandra_config_file.html?highlight=listen_address#listen-address) 和 [`broadcast_address`](http://cassandra.apache.org/doc/latest/configuration/cassandra_config_file.html?highlight=listen_address#broadcast-address)。为了在 Istio 网格中运行 Cassandra，应该将 `listen_address` 参数设置为 `127.0.0.1`，将 `broadcast_address` 参数设置为 Pod IP 地址。 diff --git a/content/zh/faq/distributed-tracing/how-distributed-tracing-works.md b/content/zh/faq/distributed-tracing/how-distributed-tracing-works.md index 35c2bac32a..80597f88be 100644 --- a/content/zh/faq/distributed-tracing/how-distributed-tracing-works.md +++ b/content/zh/faq/distributed-tracing/how-distributed-tracing-works.md @@ -3,6 +3,6 @@ title: 如何使用 Istio 实现分布式追踪？ weight: 0 --- -Istio 以两种不同的方式与分布式追踪系统集成: 基于 [Envoy](#how-envoy-based-tracing-works)(#how-mixer-based-tracing-works) 的和基于 [Mixer](#how-mixer-based-tracing-works) 的。 这两种追踪集成方法，都由[应用程序负责为后续传出请求转发追踪的 header 信息](#istio-copy-headers)。 +Istio 以两种不同的方式与分布式追踪系统集成: 基于 [Envoy](#how-envoy-based-tracing-works)(#how-mixer-based-tracing-works) 的和基于 [Mixer](#how-mixer-based-tracing-works) 的。这两种追踪集成方法，都由[应用程序负责为后续传出请求转发追踪的 header 信息](#istio-copy-headers)。 您可以在 Istio 分布式追踪（[Jaeger](/zh/docs/tasks/observability/distributed-tracing/jaeger/), [LightStep](/zh/docs/tasks/observability/distributed-tracing/lightstep/), [Zipkin](/zh/docs/tasks/observability/distributed-tracing/zipkin/)）任务以及 [Envoy 追踪文档](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/tracing)中找到更多信息。 diff --git a/content/zh/faq/distributed-tracing/how-envoy-based-tracing-works.md b/content/zh/faq/distributed-tracing/how-envoy-based-tracing-works.md index 070225d37f..5ed4ab9901 100644 --- a/content/zh/faq/distributed-tracing/how-envoy-based-tracing-works.md +++ b/content/zh/faq/distributed-tracing/how-envoy-based-tracing-works.md @@ -12,4 +12,4 @@ Envoy： - 将生成的跟踪范围发送到跟踪后端 - 将跟踪头转发到代理的应用程序 -Istio 支持基于 Envoy 的 [LightStep](/zh/docs/tasks/observability/distributed-tracing/lightstep/) 和 [Zipkin](/zh/docs/tasks/observability/distributed-tracing/zipkin/) 的集成， 以及所有与 Zipkin API 兼容的后端，包括 [Jaeger](/zh/docs/tasks/observability/distributed-tracing/jaeger/)。 +Istio 支持基于 Envoy 的 [LightStep](/zh/docs/tasks/observability/distributed-tracing/lightstep/) 和 [Zipkin](/zh/docs/tasks/observability/distributed-tracing/zipkin/) 的集成，以及所有与 Zipkin API 兼容的后端，包括 [Jaeger](/zh/docs/tasks/observability/distributed-tracing/jaeger/)。 diff --git a/content/zh/faq/distributed-tracing/how-mixer-based-tracing-works.md b/content/zh/faq/distributed-tracing/how-mixer-based-tracing-works.md index df4bb9aa38..6320d63921 100644 --- a/content/zh/faq/distributed-tracing/how-mixer-based-tracing-works.md +++ b/content/zh/faq/distributed-tracing/how-mixer-based-tracing-works.md @@ -3,7 +3,7 @@ title: 基于 Mixer 的跟踪是如何工作的？ weight: 12 --- -对于基于 Mixer 的跟踪集成，Mixer （通过 `istio-telemetry` 服务解决） 提供了后端跟踪的集成。Mixer 集成允许操作员对分布式跟踪进行更高级别的控制，包括对跟踪范围中包含的数据进行细粒度选择。它还提供将跟踪发送给 Envoy 不直接支持的后端。 +对于基于 Mixer 的跟踪集成，Mixer （通过 `istio-telemetry` 服务解决）提供了后端跟踪的集成。Mixer 集成允许操作员对分布式跟踪进行更高级别的控制，包括对跟踪范围中包含的数据进行细粒度选择。它还提供将跟踪发送给 Envoy 不直接支持的后端。 对于基于 Mixer 的集成，Envoy： diff --git a/content/zh/faq/distributed-tracing/how-to-support-tracing.md b/content/zh/faq/distributed-tracing/how-to-support-tracing.md index 89da6e0dde..e105cffb49 100644 --- a/content/zh/faq/distributed-tracing/how-to-support-tracing.md +++ b/content/zh/faq/distributed-tracing/how-to-support-tracing.md @@ -3,9 +3,9 @@ title: 使用 Istio 进行分布式追踪需要什么？ weight: 10 --- -Istio 允许报告服务网格中工作负载到工作负载间通信的追踪 span。 然而，为了将各种追踪 span 整合在一起以获得完整的流量图，应用程序必须在传入和传出请求之间传播追踪上下文信息。 +Istio 允许报告服务网格中工作负载到工作负载间通信的追踪 span。然而，为了将各种追踪 span 整合在一起以获得完整的流量图，应用程序必须在传入和传出请求之间传播追踪上下文信息。 -特别是，Istio 依赖于应用程序传播 [B3 追踪 headers](https://github.com/openzipkin/b3-propagation) 以及由 Envoy 生成的请求 ID。 这些 header 包括: +特别是，Istio 依赖于应用程序传播 [B3 追踪 headers](https://github.com/openzipkin/b3-propagation) 以及由 Envoy 生成的请求 ID。这些 header 包括: - `x-request-id` - `x-b3-traceid` @@ -19,4 +19,4 @@ Istio 允许报告服务网格中工作负载到工作负载间通信的追踪 s - `x-ot-span-context` -Header 传播可以通过客户端库完成，例如 [Zipkin](https://zipkin.io/pages/tracers_instrumentation.html) 或 [Jaeger](https://github.com/jaegertracing/jaeger-client-java/tree/master/jaeger-core#b3-propagation)。 当然，这也可以手动完成，正如[分布式追踪任务](/zh/docs/tasks/observability/distributed-tracing/overview#trace-context-propagation)中所描述的那样。 +Header 传播可以通过客户端库完成，例如 [Zipkin](https://zipkin.io/pages/tracers_instrumentation.html) 或 [Jaeger](https://github.com/jaegertracing/jaeger-client-java/tree/master/jaeger-core#b3-propagation)。当然，这也可以手动完成，正如[分布式追踪任务](/zh/docs/tasks/observability/distributed-tracing/overview#trace-context-propagation)中所描述的那样。 diff --git a/content/zh/faq/metrics-and-logs/life-of-a-request.md b/content/zh/faq/metrics-and-logs/life-of-a-request.md index bfb0b3b922..5d43d168fb 100644 --- a/content/zh/faq/metrics-and-logs/life-of-a-request.md +++ b/content/zh/faq/metrics-and-logs/life-of-a-request.md @@ -36,10 +36,10 @@ weight: 80 $ kubectl get virtualservices {{< /text >}} -* Mixer 访问日志： Mixer 的访问日志中包含了关于请求的信息。您可以通过这样获取： +* Mixer 访问日志：Mixer 的访问日志中包含了关于请求的信息。您可以通过这样获取： {{< text plain >}} - # 将 处改为您自己的 Istio namespace。 比如： istio-system + # 将 处改为您自己的 Istio namespace。比如：istio-system $ TELEMETRY_POD=`kubectl get po -n | grep istio-telemetry | awk '{print $1;}'` $ kubectl logs $TELEMETRY_POD -c mixer -n istio-system | grep accesslog {{< /text >}} diff --git a/content/zh/faq/mixer/header-rules.md b/content/zh/faq/mixer/header-rules.md index 8e98085392..98c5504718 100644 --- a/content/zh/faq/mixer/header-rules.md +++ b/content/zh/faq/mixer/header-rules.md @@ -8,5 +8,5 @@ Mixer 的规则必须在运行时验证。这意味着匹配条件的必须是[ 并且规则所指向的 handler 和 instance 也必须存在。 在执行规则之前，属性值通常会被标准化。比如，在 `request.headers` 和 `response.headers` 属性中，HTTP 头的键是小写的。 -表达式 `request.headers["X-Forwarded-Proto"] == "http"` 不会匹配任何请求，即使 HTTP 头部是不区分大小写的。 -相反，应该使用这样的表达式 `request.headers["x-forwarded-proto"] == "http"`。 +表达式 `request.headers ["X-Forwarded-Proto"] == "http"` 不会匹配任何请求，即使 HTTP 头部是不区分大小写的。 +相反，应该使用这样的表达式 `request.headers ["x-forwarded-proto"] == "http"`。 diff --git a/content/zh/faq/mixer/writing-custom-adapters.md b/content/zh/faq/mixer/writing-custom-adapters.md index a53b82cca2..103e232c0e 100644 --- a/content/zh/faq/mixer/writing-custom-adapters.md +++ b/content/zh/faq/mixer/writing-custom-adapters.md @@ -8,7 +8,7 @@ weight: 40 了解有关如何为 Mixer 实施新适配器。 {{< idea >}} -Istio 1.0 开始支持进程外适配器。 这是推荐与 Mixer 持续集成的方法。 有关如何开始构建进程外适配器的文档有 +Istio 1.0 开始支持进程外适配器。这是推荐与 Mixer 持续集成的方法。有关如何开始构建进程外适配器的文档有 [进程外适配器开发指南](https://github.com/istio/istio/wiki/Mixer-Out-Of-Process-Adapter-Dev-Guide) 和[进程外适配器概览](https://github.com/istio/istio/wiki/Mixer-Out-Of-Process-Adapter-Walkthrough)。 {{< /idea >}} diff --git a/content/zh/faq/security/accessing-non-istio-services.md b/content/zh/faq/security/accessing-non-istio-services.md index 899bd708c0..36e9404b50 100644 --- a/content/zh/faq/security/accessing-non-istio-services.md +++ b/content/zh/faq/security/accessing-non-istio-services.md @@ -3,7 +3,7 @@ title: 如何让 Istio 服务访问非 Istio 服务？ weight: 40 --- -当启用了全局双向 TLS， *全局* 目标规则会匹配集群中的所有服务，无论这些服务是否具有 Istio sidecar。 +当启用了全局双向 TLS，*全局* 目标规则会匹配集群中的所有服务，无论这些服务是否具有 Istio sidecar。 包括 Kubernetes API 服务器，以及群集中所有的非 Istio 服务。 想要通过具有 Istio sidecar 的服务访问这些非 Istio 服务，你需要设置目标规则，以豁免该服务。例如： diff --git a/content/zh/faq/security/secret-encryption.md b/content/zh/faq/security/secret-encryption.md index 847de34b87..3a9e14c650 100644 --- a/content/zh/faq/security/secret-encryption.md +++ b/content/zh/faq/security/secret-encryption.md @@ -5,4 +5,4 @@ weight: 125 默认情况下，它们是 base64 编码的，但未加密。但是，您可以按照 Kubernetes 中支持的[加密特性](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)来进行操作。 -请注意，在 Google Container Engine (GKE) 中尚未启用此功能。 尽管可能不会在主节点上运行的 etcd 内部对数据进行加密，但主节点本身的内容将被加密，更多相关信息，请参照[此处](https://cloud.google.com/security/encryption-at-rest/default-encryption/#encryption_of_data_at_rest) 。 +请注意，在 Google Container Engine (GKE) 中尚未启用此功能。尽管可能不会在主节点上运行的 etcd 内部对数据进行加密，但主节点本身的内容将被加密，更多相关信息，请参照[此处](https://cloud.google.com/security/encryption-at-rest/default-encryption/#encryption_of_data_at_rest) 。 diff --git a/content/zh/news/releases/0.x/announcing-0.1/index.md b/content/zh/news/releases/0.x/announcing-0.1/index.md index 7cb6be4d7b..5fd78755bf 100644 --- a/content/zh/news/releases/0.x/announcing-0.1/index.md +++ b/content/zh/news/releases/0.x/announcing-0.1/index.md @@ -15,7 +15,7 @@ aliases: - /zh/news/announcing-0.1 --- -Google、 IBM 和 Lyft 骄傲的宣布了 [Istio](/zh) 的首个公开版本。Istio 是一个以统一方式对微服务实施连接、管理、监控以及安全增强的开源项目。当前版本专注于支持 [Kubernetes](https://kubernetes.io/) 环境，我们计划在接下来的几个月添加诸如虚拟机和 Cloud Foundry 等环境的支持。 +Google、IBM 和 Lyft 骄傲的宣布了 [Istio](/zh) 的首个公开版本。Istio 是一个以统一方式对微服务实施连接、管理、监控以及安全增强的开源项目。当前版本专注于支持 [Kubernetes](https://kubernetes.io/) 环境，我们计划在接下来的几个月添加诸如虚拟机和 Cloud Foundry 等环境的支持。 Istio 为微服务添加了流量管理能力，同时为比如安全、监控、路由、连接管理和策略等附加能力打下了基础。此软件构建于来自 Lyft 的经过实战检验的 [Envoy](https://envoyproxy.github.io/envoy/) 代理之上，能在 *无需改动任何应用代码* 的情况下赋予对应用流量的可见性和控制能力。Istio 为 CIO 们提供了一个在企业内加强安全、策略和合规性的强有力的工具。 ## 背景{#background} diff --git a/content/zh/news/releases/0.x/announcing-0.2/index.md b/content/zh/news/releases/0.x/announcing-0.2/index.md index c783e693ec..578627f9c4 100644 --- a/content/zh/news/releases/0.x/announcing-0.2/index.md +++ b/content/zh/news/releases/0.x/announcing-0.2/index.md @@ -16,29 +16,29 @@ aliases: 我在 2017 年 5 月 24 日发布了 Istio ，它是一个用于连接、管理、监控和保护微服务的开放平台。看着饱含浓厚兴趣的开发者、运营商、合作伙伴和不断发展的社区，我们感到十分的欣慰。我们 0.1 版本的重点是展示 Istio 在 Kubernetes 中的所有概念。 -今天我们十分高兴地宣布推出 0.2 版本，它提高了稳定性和性能、允许在 Kubernetes 集群中广泛部署并自动注入 sidecar 、为 TCP 服务添加策略和身份验证、同时保证扩展网格收录那些部署在虚拟机中的服务。此外，Istio 可以利用 Consul/Nomad 或 Eureka 在 Kubernetes 外部运行。 除了核心功能，Istio 的扩展已经准备由第三方公司和开发人员编写。 +今天我们十分高兴地宣布推出 0.2 版本，它提高了稳定性和性能、允许在 Kubernetes 集群中广泛部署并自动注入 sidecar 、为 TCP 服务添加策略和身份验证、同时保证扩展网格收录那些部署在虚拟机中的服务。此外，Istio 可以利用 Consul/Nomad 或 Eureka 在 Kubernetes 外部运行。除了核心功能，Istio 的扩展已经准备由第三方公司和开发人员编写。 ## 0.2 版本的亮点{#highlights-for-the-0.2-release} ### 可用性改进{#usability-improvements} -- _支持多命名空间_: Istio 现在可以跨多个名称空间在集群范围内工作，这也是来自 0.1 版本中社区最强烈的要求之一。 +- _支持多命名空间_: Istio 现在可以跨多个名称空间在集群范围内工作，这也是来自 0.1 版本中社区最强烈的要求之一。 - _TCP 服务的策略与安全_: 除了 HTTP ，我们还为 TCP 服务增加了透明双向 TLS 认证和策略实施。这将让拥有像遥测，策略和安全等 Istio 功能的同时，保护更多 Kubernetes deployment 。 -- _自动注入 sidecar_: 通过利用 Kubernetes 1.7 提供的 alpha [初始化程序](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) ，当您的集群启用了该程序时，envoy sidecar 就可以自动注入到应用的 deployment 里。 这使得你可以使用 `kubectl` 命令部署微服务， 这与您通常在没有 Istio 的情况下部署微服务的命令完全相同。 +- _自动注入 sidecar_: 通过利用 Kubernetes 1.7 提供的 alpha [初始化程序](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) ，当您的集群启用了该程序时，envoy sidecar 就可以自动注入到应用的 deployment 里。这使得你可以使用 `kubectl` 命令部署微服务，这与您通常在没有 Istio 的情况下部署微服务的命令完全相同。 - _扩展 Istio_ : 改进的 Mixer 设计，可以允许供应商编写 Mixer 适配器以实现对其自身系统的支持，例如应用管理或策略实施。该 [Mixer 适配器开发指南](https://github.com/istio/istio/wiki/Mixer-Compiled-In-Adapter-Dev-Guide)可以轻松的帮你将 Istio 集成于你的解决方案。 - _使用您自己的 CA 证书_: 允许用户提供自己的密钥和证书给 Istio CA 和永久 CA 密钥/证书存储，允许在持久化存储中提供签名密钥/证书，以便于 CA 重启。 -- _改进路由和指标_: 支持 WebSocket 、MongoDB 和 Redis 协议。 您可以将弹性功能（如熔断器）应用于第三方服务。除了 Mixer 的指标外，数以百计 Envoy 指标现在已经在 Prometheus 中可见，它们用于监控 Istio 网格中的流量吞吐。 +- _改进路由和指标_: 支持 WebSocket 、MongoDB 和 Redis 协议。您可以将弹性功能（如熔断器）应用于第三方服务。除了 Mixer 的指标外，数以百计 Envoy 指标现在已经在 Prometheus 中可见，它们用于监控 Istio 网格中的流量吞吐。 ### 跨环境支持{#cross-environment-support} -- _网格扩展_: Istio 网格现在可以在 Kubernetes 之外跨服务 —— 就像那些运行在虚拟机中的服务一样，他们同时享受诸如自动双向 TLS 认证、流量管理、遥测和跨网格策略实施带来的好处。 +- _网格扩展_: Istio 网格现在可以在 Kubernetes 之外跨服务 —— 就像那些运行在虚拟机中的服务一样，他们同时享受诸如自动双向 TLS 认证、流量管理、遥测和跨网格策略实施带来的好处。 -- _运行在 Kubernetes 外部_: 我们知道许多客户使用其他的服务注册中心和 orchestration 解决方案（如 Consul/Nomad 和 Eureka）， Istio Pilot 可以在 Kubernetes 外部单独运行，同时从这些系统中获取信息，并在虚拟机或容器中管理 Envoy fleet 。 +- _运行在 Kubernetes 外部_: 我们知道许多客户使用其他的服务注册中心和 orchestration 解决方案（如 Consul/Nomad 和 Eureka），Istio Pilot 可以在 Kubernetes 外部单独运行，同时从这些系统中获取信息，并在虚拟机或容器中管理 Envoy fleet 。 ## 加入到塑造 Istio 未来的队伍中{#get-involved-in-shaping-the-future-of-Istio} @@ -54,43 +54,43 @@ aliases: ### 通用{#general} -- **更新配置模型**。 Istio 现在使用了 Kubernetes 的 [Custom Resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +- **更新配置模型**。Istio 现在使用了 Kubernetes 的 [Custom Resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 来描述和存储其配置。当运行在 Kubernetes 上时，现在可以使用 `kubectl` 命令来管理配置。 -- **多 namespace 的支持**。 Istio 控制平面组件现在位于专用的 `istio-system` namespace 下。 +- **多 namespace 的支持**。Istio 控制平面组件现在位于专用的 `istio-system` namespace 下。 Istio 可以管理其他非系统名称空间中的服务。 -- **Mesh 扩展**。 初步支持将非 Kubernetes 服务（以 VM 和/或 物理机的形式）添加到网格中。 +- **Mesh 扩展**。初步支持将非 Kubernetes 服务（以 VM 和/或 物理机的形式）添加到网格中。 这是此功能的早期版本，存在一些限制（例如，要求在容器和 VM 之间建立扁平网络）。 - **多环境的支持**。初步支持将 Istio 与其他服务注册表（包括 Consul 和 Eureka ）结合使用。 -- **自动注入 Sidecar**。 使用 Kubernetes 中的 [Initializers](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) alpha 功能，可以在部署后将 Istio 边车自动注入到 Pod 中。 +- **自动注入 Sidecar**。使用 Kubernetes 中的 [Initializers](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) alpha 功能，可以在部署后将 Istio 边车自动注入到 Pod 中。 ### 性能及品质{#performance-and-quality} 整个系统在性能和可靠性方面都有许多改进。 我们尚未考虑将 Istio 0.2 用于生产，但我们在这一方面取得了长足的进步。以下是一些注意事项： -- **缓存客户端**。 现在，Envoy 使用的 Mixer 客户端库为 Check 调用提供了缓存，为 Report 调用提供了批处理，从而大大减少了端到端的开销。 +- **缓存客户端**。现在，Envoy 使用的 Mixer 客户端库为 Check 调用提供了缓存，为 Report 调用提供了批处理，从而大大减少了端到端的开销。 -- **避免热重启**。 通过有效使用 LDS/RDS/CDS/EDS，基本上消除了 Envoy 需要热重启的情况。 +- **避免热重启**。通过有效使用 LDS/RDS/CDS/EDS，基本上消除了 Envoy 需要热重启的情况。 -- **减少内存使用**。 大大减少了 Sidecar 辅助代理的大小，从 50Mb 减少到了 7Mb。 +- **减少内存使用**。大大减少了 Sidecar 辅助代理的大小，从 50Mb 减少到了 7Mb。 -- **改善 Mixer 延迟**。 Mixer 现在可以清楚地描述配置时间和请求时间的计算，这样可以避免在请求时针对初始请求进行额外的设置工作，从而提供更平滑的平均延迟。 +- **改善 Mixer 延迟**。Mixer 现在可以清楚地描述配置时间和请求时间的计算，这样可以避免在请求时针对初始请求进行额外的设置工作，从而提供更平滑的平均延迟。 更好的资源缓存还有助于提高端到端性能。 - **减少 Egress 流量的延迟**。现在，我们直接将流量从 sidecar 转发到外部服务。 ### 流量管理{#traffic-management} -- **Egress 规则**。 现在可以为 Egress 流量指定路由规则。 +- **Egress 规则**。现在可以为 Egress 流量指定路由规则。 -- **新协议**。 Mesh-wide 现在支持 WebSocket 链接, MongoDB 代理, +- **新协议**。Mesh-wide 现在支持 WebSocket 链接, MongoDB 代理, 和 Kubernetes [headless 服务](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services)。 -- **其它改进**。 Ingress 正确支持 gRPC 服务，更好的支持健康检查和 Jaeger 追踪。 +- **其它改进**。Ingress 正确支持 gRPC 服务，更好的支持健康检查和 Jaeger 追踪。 ### 策略执行及遥测{#policy-enforcement-telemetry} @@ -108,7 +108,7 @@ Istio 可以管理其他非系统名称空间中的服务。 - **Mixer Adapter 更新**。内置适配器已全部重写以适合新的适配器模型。该版本已添加了 `stackdriver` 适配器。 实验性的 `redisquota` 适配器已从 0.2 版本中删除，但有望在 生产就绪的 0.3 版本中回归。 -- **Mixer 调用追踪**。 现在可以在 Zipkin 仪表板中跟踪和分析 Envoy 和 Mixer 之间的调用。 +- **Mixer 调用追踪**。现在可以在 Zipkin 仪表板中跟踪和分析 Envoy 和 Mixer 之间的调用。 ### 安全{#security} diff --git a/content/zh/news/releases/0.x/announcing-0.5/index.md b/content/zh/news/releases/0.x/announcing-0.5/index.md index 954d33b442..28e883c428 100644 --- a/content/zh/news/releases/0.x/announcing-0.5/index.md +++ b/content/zh/news/releases/0.x/announcing-0.5/index.md @@ -36,7 +36,7 @@ aliases: ## 安全{#security} -- **使用你自己的 CA**。多项针对 ‘使用你自己的 CA’ 特性的改进。[了解更多](/zh/docs/tasks/security/citadel-config/plugin-ca-cert/) +- **使用你自己的 CA**。多项针对 ‘使用你自己的 CA’特性的改进。[了解更多](/zh/docs/tasks/security/citadel-config/plugin-ca-cert/) - **PKCS8**。将 PKCS8 密钥的支持添加到 Istio PKI。 diff --git a/content/zh/news/releases/0.x/announcing-0.8/index.md b/content/zh/news/releases/0.x/announcing-0.8/index.md index be0bcce775..eb523c1e30 100644 --- a/content/zh/news/releases/0.x/announcing-0.8/index.md +++ b/content/zh/news/releases/0.x/announcing-0.8/index.md @@ -18,9 +18,9 @@ aliases: ## 网络{#networking} -- **改良的流量管理模型**。我们终于准备好完成我们的[新流量管理 API](/zh/blog/2018/v1alpha3-routing/) 的总结。 我们相信，在涵盖更多实际部署[用例](/zh/docs/tasks/traffic-management/)的同时，这种新模型更易于理解。 对于从早期发行版升级的人，这儿有一个[迁移指南](/zh/docs/setup/upgrade/)和内置在 `istioctl` 中的转换工具，可帮助您从旧模型转换配置。 +- **改良的流量管理模型**。我们终于准备好完成我们的[新流量管理 API](/zh/blog/2018/v1alpha3-routing/) 的总结。我们相信，在涵盖更多实际部署[用例](/zh/docs/tasks/traffic-management/)的同时，这种新模型更易于理解。对于从早期发行版升级的人，这儿有一个[迁移指南](/zh/docs/setup/upgrade/)和内置在 `istioctl` 中的转换工具，可帮助您从旧模型转换配置。 -- **Envoy 流式配置**。默认情况下，Pilot 现在使用其 [ADS API](https://github.com/envoyproxy/data-plane-api/blob/master/xds_protocol.rst) 将配置流式传输到 Envoy。 这种新方法提高了有效的可伸缩性，减少了推出延迟，应该能消除虚假的 404 错误。 +- **Envoy 流式配置**。默认情况下，Pilot 现在使用其 [ADS API](https://github.com/envoyproxy/data-plane-api/blob/master/xds_protocol.rst) 将配置流式传输到 Envoy。这种新方法提高了有效的可伸缩性，减少了推出延迟，应该能消除虚假的 404 错误。 - **Ingress/Egress 的 Gateway**。我们不再支持将 Kubernetes Ingress 规范与 Istio 路由规则结合使用，因为它导致了许多错误和可靠性问题。Istio 现在支持用于 ingress 和 egress 代理的独立于平台的 [Gateway](/zh/docs/concepts/traffic-management/#gateways) 模型，该模型可跨 Kubernetes 和 Cloud Foundry 使用，并与路由无缝协作。Gateway 支持基于[服务器名称指示](https://en.wikipedia.org/wiki/Server_Name_Indication)的路由，并基于客户端提供的服务器名称提供证书。 diff --git a/content/zh/news/releases/1.0.x/announcing-1.0.7/index.md b/content/zh/news/releases/1.0.x/announcing-1.0.7/index.md index 9c1319ed13..16776d67b5 100644 --- a/content/zh/news/releases/1.0.x/announcing-1.0.7/index.md +++ b/content/zh/news/releases/1.0.x/announcing-1.0.7/index.md @@ -37,7 +37,7 @@ aliases: - 1.0.6 与 1.0.7 是基于相同源码构建的，仅添加了解决 CVE 的 Envoy 补丁。 - 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8 - - 这些发行版不再受支持，也不会进行修补。 请升级到受支持的版本，以获取必要的修复程序。 + - 这些发行版不再受支持，也不会进行修补。请升级到受支持的版本，以获取必要的修复程序。 ## 漏洞影响{#vulnerability-impact} diff --git a/content/zh/news/releases/1.1.x/announcing-1.1.13/index.md b/content/zh/news/releases/1.1.x/announcing-1.1.13/index.md index 7c421c1c73..3cff92408f 100644 --- a/content/zh/news/releases/1.1.x/announcing-1.1.13/index.md +++ b/content/zh/news/releases/1.1.x/announcing-1.1.13/index.md @@ -27,7 +27,7 @@ __ISTIO-SECURITY-2019-004__: Envoy 和之后的 Istio 更容易受到一系列 * __[CVE-2019-9512](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9512)__: 使用 `PING` 帧和响应 `PING` ACK 帧的 HTTP/2 流，会导致无限的内存增长（这可能导致内存不足的原因）。 * __[CVE-2019-9513](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9513)__: 使用 PRIORITY 帧的 HTTP/2 流会导致其他客户端的 CPU 使用率过低。 * __[CVE-2019-9514](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9514)__: 使用具有无效的 HTTP header 的 `HEADERS` 帧和 `RST_STREAM` 帧的 HTTP/2 流，会导致无限的内存增长（这可能导致内存不足的原因）。 - * __[CVE-2019-9515](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9515)__: 使用 `SETTINGS` 帧和 `SETTINGS` ACK 帧的 HTTP/2 流，会导致无限的内存增长（这可能导致内存不足的原因）。 + * __[CVE-2019-9515](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9515)__: 使用 `SETTINGS` 帧和 `SETTINGS` ACK 帧的 HTTP/2 流，会导致无限的内存增长（这可能导致内存不足的原因）。 * __[CVE-2019-9518](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9518)__: 使用具有空负载帧的 HTTP/2 流会导致其他客户端的 CPU 使用率过低。 除上述修复的程序之外，此版本中不包含其他任何内容。 diff --git a/content/zh/news/releases/1.1.x/announcing-1.1.16/index.md b/content/zh/news/releases/1.1.x/announcing-1.1.16/index.md index a10ba9e3ae..d4a2408121 100644 --- a/content/zh/news/releases/1.1.x/announcing-1.1.16/index.md +++ b/content/zh/news/releases/1.1.x/announcing-1.1.16/index.md @@ -18,7 +18,7 @@ aliases: 此版本包含了我们在 [2019 年 10 月 8 日](/zh/news/security/istio-security-2019-005)的新闻中所阐述的修复程序的安全漏洞。特别是： -__ISTIO-SECURITY-2019-005__: `Envoy` 社区发现了一个 `DoS` 漏洞。 +__ISTIO-SECURITY-2019-005__: `Envoy` 社区发现了一个 `DoS` 漏洞。 * __[CVE-2019-15226](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15226)__: 经过调查，`Istio` 团队发现，如果攻击者使用大量非常小的 `header`，则可以利用此问题进行对 `Istio` 的 `DoS` 攻击。 除了对上述程序的安全修复以外，此版本中不包含其他任何内容。 diff --git a/content/zh/news/releases/1.1.x/announcing-1.1.2/index.md b/content/zh/news/releases/1.1.x/announcing-1.1.2/index.md index a14b6c3ba3..aafdd0a38e 100644 --- a/content/zh/news/releases/1.1.x/announcing-1.1.2/index.md +++ b/content/zh/news/releases/1.1.x/announcing-1.1.2/index.md @@ -37,7 +37,7 @@ aliases: - 1.0.6 与 1.0.7 是基于相同源码构建的，仅添加了解决 CVE 的 Envoy 补丁。 - 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8 - - 这些发行版不再受支持，也不会进行修补。 请升级到受支持的版本，以获取必要的修复程序。 + - 这些发行版不再受支持，也不会进行修补。请升级到受支持的版本，以获取必要的修复程序。 ## 漏洞影响{#vulnerability-impact} diff --git a/content/zh/news/releases/1.1.x/announcing-1.1.4/index.md b/content/zh/news/releases/1.1.x/announcing-1.1.4/index.md index 3a35563fa5..12cc4ce477 100644 --- a/content/zh/news/releases/1.1.x/announcing-1.1.4/index.md +++ b/content/zh/news/releases/1.1.x/announcing-1.1.4/index.md @@ -18,7 +18,7 @@ aliases: ## 行为变更 {#behavior-change} -- 更改了 Pilot 的默认行为，以允许流量流向网格外部，即使该流量与内部服务位于同一端口上也是如此，此行为可由 `PILOT_ENABLE_FALLTHROUGH_ROUTE` 环境变量控制。 +- 更改了 Pilot 的默认行为，以允许流量流向网格外部，即使该流量与内部服务位于同一端口上也是如此，此行为可由 `PILOT_ENABLE_FALLTHROUGH_ROUTE` 环境变量控制。 ## Bug 修复 {#bug-fixes} @@ -40,7 +40,7 @@ aliases: - 修复了节点代理中的崩溃错误 ([Issue 13325](https://github.com/istio/istio/issues/13325))。 -- 添加了缺少的验证，以防止网关名称包含点（.） ([Issue 13211](https://github.com/istio/istio/issues/13211))。 +- 添加了缺少的验证，以防止网关名称包含点（.）([Issue 13211](https://github.com/istio/istio/issues/13211))。 - 修复了 [`ConsistentHashLB.minimumRingSize`](/zh/docs/reference/config/networking/destination-rule#LoadBalancerSettings-ConsistentHashLB) 默认为 0 而不是记录的 1024 ([Issue 13261](https://github.com/istio/istio/issues/13261))。 diff --git a/content/zh/news/releases/1.1.x/announcing-1.1.7/index.md b/content/zh/news/releases/1.1.x/announcing-1.1.7/index.md index 2623546768..a2f4444028 100644 --- a/content/zh/news/releases/1.1.x/announcing-1.1.7/index.md +++ b/content/zh/news/releases/1.1.x/announcing-1.1.7/index.md @@ -29,5 +29,5 @@ aliases: ## 小改进{#small-enhancements} -- 新增 `--applicationPorts` 选项到 `ingressgateway` Helm charts。当设置为以逗号分隔的端口列表时，就绪检查将失败，直到所有端口都变为活动状态为止。配置后，流量将不会发送到处于预热状态的 Envoy。 +- 新增 `--applicationPorts` 选项到 `ingressgateway` Helm charts。当设置为以逗号分隔的端口列表时，就绪检查将失败，直到所有端口都变为活动状态为止。配置后，流量将不会发送到处于预热状态的 Envoy。 - 将 `ingressgateway` Helm chart 中的内存限制增加到 1GB，并向 SDS 节点代理容器添加资源 `request` 和 `limits` 以支持 HPA 自动缩放。 diff --git a/content/zh/news/releases/1.1.x/announcing-1.1/change-notes/index.md b/content/zh/news/releases/1.1.x/announcing-1.1/change-notes/index.md index c1454cbfd5..2732847dd7 100644 --- a/content/zh/news/releases/1.1.x/announcing-1.1/change-notes/index.md +++ b/content/zh/news/releases/1.1.x/announcing-1.1/change-notes/index.md @@ -102,7 +102,7 @@ aliases: ### 配置管理{#configuration-management} -- **Galley**。添加 [Galley](/zh/docs/ops/deployment/architecture/#galley) 作为 Istio 主要的配置收集和分发装置。它提供了一个健壮的模型来验证，转换配置状态并将其分配给 Istio 组件，从而将 Istio 组件与 Kubernetes 详细信息隔离开来。Galley 使用[网格配置协议](https://github.com/istio/api/tree/{{}}/mcp) 与组件进行交互。 +- **Galley**。添加 [Galley](/zh/docs/ops/deployment/architecture/#galley) 作为 Istio 主要的配置收集和分发装置。它提供了一个健壮的模型来验证，转换配置状态并将其分配给 Istio 组件，从而将 Istio 组件与 Kubernetes 详细信息隔离开来。Galley 使用[网格配置协议](https://github.com/istio/api/tree/{{}}/mcp)与组件进行交互。 - **监听端口**。将 Galley 的默认监听端口从 9093 修改为 15014。 diff --git a/content/zh/news/releases/1.2.x/announcing-1.2.1/index.md b/content/zh/news/releases/1.2.x/announcing-1.2.1/index.md index 7a49bcea59..7e3d86e513 100644 --- a/content/zh/news/releases/1.2.x/announcing-1.2.1/index.md +++ b/content/zh/news/releases/1.2.x/announcing-1.2.1/index.md @@ -20,7 +20,7 @@ aliases: - 修复在安装中生成重复 CRD 的问题（[Issue 14976](https://github.com/istio/istio/issues/14976)） - 修复禁用 Galley 时无法启动 Mixer 的问题（[Issue 14841](https://github.com/istio/istio/issues/14841)） -- 修复环境变量遮蔽的问题（NAMESPACE 用于监控的命名空间覆盖了 Citadel 的存储命名空间（istio-system）） +- 修复环境变量遮蔽的问题（NAMESPACE 用于监控的命名空间覆盖了 Citadel 的存储命名空间（istio-system） - 修复升级过程中的 'TLS error: Secret is not supplied by SDS' 错误（[Issue 15020](https://github.com/istio/istio/issues/15020)） ## 次要改进{#minor-enhancements} diff --git a/content/zh/news/releases/1.2.x/announcing-1.2.10/index.md b/content/zh/news/releases/1.2.x/announcing-1.2.10/index.md index fd3314ceaa..ea872b4cbc 100644 --- a/content/zh/news/releases/1.2.x/announcing-1.2.10/index.md +++ b/content/zh/news/releases/1.2.x/announcing-1.2.10/index.md @@ -17,7 +17,7 @@ aliases: - **ISTIO-SECURITY-2019-007** 在 Envoy 中发现了堆溢出和不正确的输入验证。 -__[CVE-2019-18801](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18801)__：修复了一个影响 Envoy 处理大型 HTTP/2 请求 header 的漏洞。 成功利用此漏洞可能导致拒绝服务、特权提升或信息泄露。 +__[CVE-2019-18801](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18801)__：修复了一个影响 Envoy 处理大型 HTTP/2 请求 header 的漏洞。成功利用此漏洞可能导致拒绝服务、特权提升或信息泄露。 __[CVE-2019-18802](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18802)__：修复了 HTTP/1 header 值后的空格引起的漏洞，该漏洞可能使攻击者绕过 Istio 的策略检查，从而可能导致信息泄露或特权提升。 diff --git a/content/zh/news/releases/1.2.x/announcing-1.2.4/index.md b/content/zh/news/releases/1.2.x/announcing-1.2.4/index.md index 30e0d7e526..eb14a6ccca 100644 --- a/content/zh/news/releases/1.2.x/announcing-1.2.4/index.md +++ b/content/zh/news/releases/1.2.x/announcing-1.2.4/index.md @@ -27,7 +27,7 @@ __ISTIO-SECURITY-2019-004__: Envoy 和之后的 Istio 更容易受到一系列 * __[CVE-2019-9512](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9512)__: 使用 `PING` 帧和响应 `PING` ACK 帧的 HTTP/2 流，会导致无限的内存增长（这可能导致内存不足的原因）。 * __[CVE-2019-9513](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9513)__: 使用 PRIORITY 帧的 HTTP/2 流会导致其他客户端的 CPU 使用率过低。 * __[CVE-2019-9514](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9514)__: 使用具有无效的 HTTP header 的 `HEADERS` 帧和 `RST_STREAM` 帧的 HTTP/2 流，会导致无限的内存增长（这可能导致内存不足的原因）。 - * __[CVE-2019-9515](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9515)__: 使用 `SETTINGS` 帧和 `SETTINGS` ACK 帧的 HTTP/2 流，会导致无限的内存增长（这可能导致内存不足的原因）。 + * __[CVE-2019-9515](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9515)__: 使用 `SETTINGS` 帧和 `SETTINGS` ACK 帧的 HTTP/2 流，会导致无限的内存增长（这可能导致内存不足的原因）。 * __[CVE-2019-9518](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9518)__: 使用具有空负载帧的 HTTP/2 流会导致其他客户端的 CPU 使用率过低。 除上述修复的程序之外，此版本中不包含其他任何内容。 diff --git a/content/zh/news/releases/1.2.x/announcing-1.2.7/index.md b/content/zh/news/releases/1.2.x/announcing-1.2.7/index.md index 9ab6bc20b3..2c1b484202 100644 --- a/content/zh/news/releases/1.2.x/announcing-1.2.7/index.md +++ b/content/zh/news/releases/1.2.x/announcing-1.2.7/index.md @@ -18,7 +18,7 @@ aliases: 此版本包含我们在 [2019 年 10 月 8 日](/zh/news/security/istio-security-2019-005)的新闻中所阐述的安全漏洞程序的修复。特别是： -__ISTIO-SECURITY-2019-005__: `Envoy` 社区发现的一个 `DoS` 漏洞。 +__ISTIO-SECURITY-2019-005__: `Envoy` 社区发现的一个 `DoS` 漏洞。 * __[CVE-2019-15226](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15226)__: 经过调查，`Istio` 团队发现，如果攻击者使用大量非常小的 `header`，则可以利用此问题在 `Istio` 中进行 `DoS` 攻击。 ## Bug 修复{#bug-fix} diff --git a/content/zh/news/releases/1.2.x/announcing-1.2/_index.md b/content/zh/news/releases/1.2.x/announcing-1.2/_index.md index a13517e30a..4d8af00f9d 100644 --- a/content/zh/news/releases/1.2.x/announcing-1.2/_index.md +++ b/content/zh/news/releases/1.2.x/announcing-1.2/_index.md @@ -13,7 +13,7 @@ aliases: - /zh/news/announcing-1.2 --- -我们很高兴的宣布 Istio 1.2 发布了！ +我们很高兴的宣布 Istio 1.2 发布了！ {{< relnote >}} diff --git a/content/zh/news/releases/1.2.x/announcing-1.2/change-notes/index.md b/content/zh/news/releases/1.2.x/announcing-1.2/change-notes/index.md index 67c75501a9..e66cb628af 100644 --- a/content/zh/news/releases/1.2.x/announcing-1.2/change-notes/index.md +++ b/content/zh/news/releases/1.2.x/announcing-1.2/change-notes/index.md @@ -8,7 +8,7 @@ aliases: ## 通用功能 {#general} -- **增加** `traffic.sidecar.istio.io/includeInboundPorts` 标注可以让服务所有者不需要在 deployment yaml 文件中配置 `containerPort` 字段。 这会是未来版本中的默认做法。 +- **增加** `traffic.sidecar.istio.io/includeInboundPorts` 标注可以让服务所有者不需要在 deployment yaml 文件中配置 `containerPort` 字段。这会是未来版本中的默认做法。 - **增加** 对 Kubernetes 集群的 IPv6 试验性支持。 ## 流量管理 {#traffic-management} @@ -23,8 +23,8 @@ aliases: ## 安全 {#security} - **改进** 将自签名 Citadel 根证书的默认生存期延长到 10 年。 -- **增加** 通过[标注](/zh/docs/ops/configuration/mesh/app-health-check/#use-annotations-on-pod) `PodSpec` 中`sidecar.istio.io/rewriteAppHTTPProbers: "true"` 字段，Kubernetes 的健康检查探测器会重写每个 deployment。 -- **增加** 支持给 Istio 双向 TLS 证书配置密钥路径。 更多信息请看[这里](https://github.com/istio/istio/issues/11984)。 +- **增加** 通过 [标注](/zh/docs/ops/configuration/mesh/app-health-check/#use-annotations-on-pod) `PodSpec` 中`sidecar.istio.io/rewriteAppHTTPProbers: "true"` 字段，Kubernetes 的健康检查探测器会重写每个 deployment。 +- **增加** 支持给 Istio 双向 TLS 证书配置密钥路径。更多信息请看[这里](https://github.com/istio/istio/issues/11984)。 - **增加** 通过启用 Citadel 上的 `pkcs8-keys` 来支持 workload 使用 [PKCS 8](https://en.wikipedia.org/wiki/PKCS_8) 私钥。 - **改进** JWT 公钥获取逻辑在网络失败的时候更可靠。 - **修复** workload 证书中的 [SAN](https://tools.ietf.org/html/rfc5280#section-4.2.1.6) 字段设置为 `critical`。这是修复了一些自定义证书验证服务无法验证 Istio 证书的问题。 @@ -56,7 +56,7 @@ aliases: - **增加** `sidecarInjectorWebhook.neverInjectSelector` 和 `sidecarInjectorWebhook.alwaysInjectSelector` 配置，通过标签选择器让用户可以进一步控制 workload 是否应该自动注入 sidecar。 - **增加** `global.logging.level` 和 `global.proxy.logLevel` 配置，允许用户方便的给控制平面和数据平面组件全局的配置日志。 - **增加** 支持通过设置 [`global.tracer.datadog.address`](/zh/docs/reference/config/installation-options/#global-options) 来配置 Datadog 的地址。 -- **移除** 默认情况下禁止使用早期[被弃用](https://discuss.istio.io/t/deprecation-notice-custom-mixer-adapter-crds/2055) 的适配器和 CRD 模版。可以使用 `mixer.templates.useTemplateCRDs=true` 和 `mixer.adapters.useAdapterCRDs=true` 安装配置项来重新启用这两个功能。 +- **移除** 默认情况下禁止使用早期[被弃用](https://discuss.istio.io/t/deprecation-notice-custom-mixer-adapter-crds/2055)的适配器和 CRD 模版。可以使用 `mixer.templates.useTemplateCRDs=true` 和 `mixer.adapters.useAdapterCRDs=true` 安装配置项来重新启用这两个功能。 要看全部的变动，请参阅[安装选项变动页面](/zh/news/releases/1.2.x/announcing-1.2/helm-changes/)。 diff --git a/content/zh/news/releases/1.3.x/announcing-1.3.1/index.md b/content/zh/news/releases/1.3.x/announcing-1.3.1/index.md index 5a9fe965d1..32f9ef40a1 100644 --- a/content/zh/news/releases/1.3.x/announcing-1.3.1/index.md +++ b/content/zh/news/releases/1.3.x/announcing-1.3.1/index.md @@ -32,4 +32,4 @@ aliases: - **增加** `pilot_xds_push_time` 指标以报告 Pilot xDS 推送时间。 - **增加** `istioctl experimental analyze` 以支持多资源分析和验证。 - **增加** 对在 WebAssembly 沙箱中运行元数据交换和统计信息扩展的支持。请按照[以下](/zh/docs/ops/configuration/telemetry/in-proxy-service-telemetry/)说明进行尝试。 -- **删除** proxy-status 命令中的时间差异信息。 +- **删除** proxy-status 命令中的时间差异信息。 diff --git a/content/zh/news/releases/1.3.x/announcing-1.3.3/index.md b/content/zh/news/releases/1.3.x/announcing-1.3.3/index.md index c8b19394dd..6dcc2ec997 100644 --- a/content/zh/news/releases/1.3.x/announcing-1.3.3/index.md +++ b/content/zh/news/releases/1.3.x/announcing-1.3.3/index.md @@ -17,8 +17,8 @@ aliases: ## Bug 修复{#bug-fixes} - **Fixed** 当使用 `istioctl x manifest apply` 时导致 Prometheus 安装不正确的问题。（[Issue 16970](https://github.com/istio/istio/issues/16970)） -- **Fixed** 本地负载均衡不能从本地节点读取位置信息的错误。 （[Issue 17337](https://github.com/istio/istio/issues/17337)） -- **Fixed** 当侦听器在没有任何用户配置更改的情况下进行重新配置时，Envoy 代理会删除长连接。 （[Issue 17383](https://github.com/istio/istio/issues/17383)，[Issue 17139](https://github.com/istio/istio/issues/17139)） +- **Fixed** 本地负载均衡不能从本地节点读取位置信息的错误。（[Issue 17337](https://github.com/istio/istio/issues/17337)） +- **Fixed** 当侦听器在没有任何用户配置更改的情况下进行重新配置时，Envoy 代理会删除长连接。（[Issue 17383](https://github.com/istio/istio/issues/17383)，[Issue 17139](https://github.com/istio/istio/issues/17139)） - **Fixed** `istioctl x analyze` 命令的崩溃问题。（[Issue 17449](https://github.com/istio/istio/issues/17449)） - **Fixed** `istioctl x manifest diff` 命令中 ConfigMaps 中的差异文本块。（[Issue 16828](https://github.com/istio/istio/issues/16828)） - **Fixed** Envoy proxy 的分段错误崩溃问题。（[Issue 17699](https://github.com/istio/istio/issues/17699)） diff --git a/content/zh/news/releases/1.3.x/announcing-1.3.6/index.md b/content/zh/news/releases/1.3.x/announcing-1.3.6/index.md index 71c699c1cf..551d4383d9 100644 --- a/content/zh/news/releases/1.3.x/announcing-1.3.6/index.md +++ b/content/zh/news/releases/1.3.x/announcing-1.3.6/index.md @@ -17,7 +17,7 @@ aliases: - **ISTIO-SECURITY-2019-007** 在 Envoy 中发现了堆溢出和不正确的输入验证。 -__[CVE-2019-18801](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18801)__：修复了一个影响 Envoy 处理大型 HTTP/2 请求 header 的漏洞。 成功利用此漏洞可能导致拒绝服务、特权提升或信息泄露。 +__[CVE-2019-18801](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18801)__：修复了一个影响 Envoy 处理大型 HTTP/2 请求 header 的漏洞。成功利用此漏洞可能导致拒绝服务、特权提升或信息泄露。 __[CVE-2019-18802](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18802)__：修复了 HTTP/1 header 值后的空格引起的漏洞，该漏洞可能使攻击者绕过 Istio 的策略检查，从而可能导致信息泄露或特权提升。 diff --git a/content/zh/news/releases/1.3.x/announcing-1.3.7/index.md b/content/zh/news/releases/1.3.x/announcing-1.3.7/index.md index e5b21e8d6c..e53ada707d 100644 --- a/content/zh/news/releases/1.3.x/announcing-1.3.7/index.md +++ b/content/zh/news/releases/1.3.x/announcing-1.3.7/index.md @@ -31,4 +31,4 @@ aliases: * [**ISTIO-SECURITY-2020-002**](/zh/news/security/istio-security-2020-002) 由于不正确地接受某些请求 header，导致可绕过 Mixer 策略检查。 -__[CVE-2020-8843](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8843)__：在某些情况下，可以绕过特定配置的 Mixer 策略。Istio-proxy 在 ingress 处接受 `x-istio-attributes` header，当 Mixer 策略有选择地应用至 source 时，等价于应用至 ingress，其可能会影响策略决策。 Istio 1.3 到 1.3.6 容易受到攻击。 +__[CVE-2020-8843](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8843)__：在某些情况下，可以绕过特定配置的 Mixer 策略。Istio-proxy 在 ingress 处接受 `x-istio-attributes` header，当 Mixer 策略有选择地应用至 source 时，等价于应用至 ingress，其可能会影响策略决策。Istio 1.3 到 1.3.6 容易受到攻击。 diff --git a/content/zh/news/releases/1.3.x/announcing-1.3/_index.md b/content/zh/news/releases/1.3.x/announcing-1.3/_index.md index 79c4444144..9e26599890 100644 --- a/content/zh/news/releases/1.3.x/announcing-1.3/_index.md +++ b/content/zh/news/releases/1.3.x/announcing-1.3/_index.md @@ -13,7 +13,7 @@ aliases: - /zh/news/announcing-1.3 --- -我们很高兴的宣布 Istio 1.3 发布了！ +我们很高兴的宣布 Istio 1.3 发布了！ {{< relnote >}} diff --git a/content/zh/news/releases/1.3.x/announcing-1.3/change-notes/index.md b/content/zh/news/releases/1.3.x/announcing-1.3/change-notes/index.md index ebd24f6112..d24bd9e8bb 100644 --- a/content/zh/news/releases/1.3.x/announcing-1.3/change-notes/index.md +++ b/content/zh/news/releases/1.3.x/announcing-1.3/change-notes/index.md @@ -30,7 +30,7 @@ aliases: - **添加**。添加了一些[标签](/zh/docs/ops/configuration/mesh/secret-creation/)，其用于按命名空间控制服务帐户密码的生成。 - **添加**。添加了 SDS 支持，以实现向每个 Istio 控制平面服务传递私钥和证书。 - **添加**。为 Citadel 添加了对[自检](/zh/docs/ops/diagnostic-tools/controlz/)支持。 -- **添加**。为 15014 端口的 Citadel Agent 的 `/metrics` endpoint 添加了指标，用于监控 SDS 服务。 +- **添加**。为 15014 端口的 Citadel Agent 的 `/metrics` endpoint 添加了指标，用于监控 SDS 服务。 - **添加**。使用 8080 端口上的 `/debug/sds/workload` 和 `/debug/sds/gateway` 向 Citadel Agent 添加了诊断程序。 - **改进**。改进了 ingress gateway，以实现使用 SDS 时[从另一个 secret 加载受信任的 CA 证书](/zh/docs/tasks/traffic-management/ingress/secure-ingress-sds/#configure-a-mutual-TLS-ingress-gateway)。 - **改进**。通过强制使用 [Kubernetes Trustworthy JWT](/zh/blog/2019/trustworthy-jwt-sds) 改进了 SDS 的安全性。 diff --git a/content/zh/news/releases/1.3.x/announcing-1.3/upgrade-notes/index.md b/content/zh/news/releases/1.3.x/announcing-1.3/upgrade-notes/index.md index da29d259d6..f41c1d7438 100644 --- a/content/zh/news/releases/1.3.x/announcing-1.3/upgrade-notes/index.md +++ b/content/zh/news/releases/1.3.x/announcing-1.3/upgrade-notes/index.md @@ -35,6 +35,6 @@ Istio 现在默认情况下会捕获所有端口。如果您没有指定容器 在 Istio 1.3 中，我们正在利用 Kubernetes 的改进来更安全地为工作负载实例颁发证书。 Kubernetes 1.12 引入了 `值得信赖的` JWTs 来解决这些问题。 -[Kubernetes 1.13](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.13.md) 引入了将 `aud` 字段的值更改为 API server 以外的值的功能。`aud` 字段代表了 Kubernetes 的 audience 。为了更好地保护网格，Istio 1.3 仅支持 `值得信赖的` JWT，并且当您启用 SDS 后，要求 audience ，也就是 `aud` 字段的值，为 `istio-ca`。 +[Kubernetes 1.13](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.13.md) 引入了将 `aud` 字段的值更改为 API server 以外的值的功能。`aud` 字段代表了 Kubernetes 的 audience 。为了更好地保护网格，Istio 1.3 仅支持 `值得信赖的` JWT，并且当您启用 SDS 后，要求 audience ，也就是 `aud` 字段的值，为 `istio-ca`。 在启用 SDS 的情况下升级到 Istio 1.3 之前，请参阅我们的博客文章[可信赖的 JWT 和 SDS](/zh/blog/2019/trustworthy-jwt-sds/)。 diff --git a/content/zh/news/releases/1.4.x/announcing-1.4.2/index.md b/content/zh/news/releases/1.4.x/announcing-1.4.2/index.md index fcbba26421..4921ed6c94 100644 --- a/content/zh/news/releases/1.4.x/announcing-1.4.2/index.md +++ b/content/zh/news/releases/1.4.x/announcing-1.4.2/index.md @@ -17,6 +17,6 @@ aliases: - **ISTIO-SECURITY-2019-007** 在 Envoy 中发现了堆溢出和不正确的输入验证。 -__[CVE-2019-18801](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18801)__：修复了一个影响 Envoy 处理大型 HTTP/2 请求 header 的漏洞。 成功利用此漏洞可能导致拒绝服务、特权提升或信息泄露。 +__[CVE-2019-18801](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18801)__：修复了一个影响 Envoy 处理大型 HTTP/2 请求 header 的漏洞。成功利用此漏洞可能导致拒绝服务、特权提升或信息泄露。 __[CVE-2019-18802](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18802)__：修复了 HTTP/1 header 值后的空格引起的漏洞，该漏洞可能使攻击者绕过 Istio 的策略检查，从而可能导致信息泄露或特权提升。 diff --git a/content/zh/news/releases/1.4.x/announcing-1.4/_index.md b/content/zh/news/releases/1.4.x/announcing-1.4/_index.md index ead8c6bf1b..602c32a9fb 100644 --- a/content/zh/news/releases/1.4.x/announcing-1.4/_index.md +++ b/content/zh/news/releases/1.4.x/announcing-1.4/_index.md @@ -38,7 +38,7 @@ aliases: ## 更好的 sidecar{#better-sidecar} -我们一直在做大量工作来改善 `Envoy` 的功能和用户使用体验，`Envoy` 在崩溃时可以更正常地退出，它支持更多指标，并且可以将流量映射到一定的比例。它会报告流量的来源，并且可以更好地配置 `stat patterns`。最后，有一个新的[实验命令](/zh/docs/reference/commands/istioctl/#istioctl-experimental-wait) ，可以告诉您将所有代理推送到网格中的时间。 +我们一直在做大量工作来改善 `Envoy` 的功能和用户使用体验，`Envoy` 在崩溃时可以更正常地退出，它支持更多指标，并且可以将流量映射到一定的比例。它会报告流量的来源，并且可以更好地配置 `stat patterns`。最后，有一个新的[实验命令](/zh/docs/reference/commands/istioctl/#istioctl-experimental-wait) ，可以告诉您将所有代理推送到网格中的时间。 ## 其他增强功能{#other-enhancements} diff --git a/content/zh/news/releases/1.4.x/announcing-1.4/change-notes/index.md b/content/zh/news/releases/1.4.x/announcing-1.4/change-notes/index.md index 42438525ec..4cf0b4270c 100644 --- a/content/zh/news/releases/1.4.x/announcing-1.4/change-notes/index.md +++ b/content/zh/news/releases/1.4.x/announcing-1.4/change-notes/index.md @@ -7,7 +7,7 @@ weight: 10 ## 流量管理{#traffic-management} - **新增了** 对 [mirroring](/zh/docs/tasks/traffic-management/mirroring/) 百分比的流量支持。 -- **改进了** `Envoy sidecar`。当 `Envoy sidecar` 崩溃退出时，可以更轻松地查看 `Envoy sidecar` 的状态。 +- **改进了** `Envoy sidecar`。当 `Envoy sidecar` 崩溃退出时，可以更轻松地查看 `Envoy sidecar` 的状态。 - **改进了** `Pilot` 的功能，当无需修改时，即可跳过向 `Envoy` 发送冗余配置的操作。 - **改进了** `headless` 服务，以避免与同一端口上的不同服务发生冲突。 - **禁用了** 默认的 [circuit breakers](/zh/docs/tasks/traffic-management/circuit-breaking/)。 @@ -15,7 +15,7 @@ weight: 10 ## 安全{#security} -- **新增了** [`v1beta1` authorization policy model](/zh/blog/2019/v1beta1-authorization-policy/) 用于执行访问控制。 最终将取代 [`v1alpha1` RBAC policy](/zh/docs/reference/config/security/istio.rbac.v1alpha1/)。 +- **新增了** [`v1beta1` authorization policy model](/zh/blog/2019/v1beta1-authorization-policy/) 用于执行访问控制。最终将取代 [`v1alpha1` RBAC policy](/zh/docs/reference/config/security/istio.rbac.v1alpha1/)。 - **新增了** [automatic mutual TLS](/zh/docs/tasks/security/authentication/auto-mtls/) 的实验性支持，以启用 `mutual TLS`，而无需配置目标规则。 - **新增了** 对 [authorization policy trust domain migration](/zh/docs/tasks/security/authorization/authz-td-migration/) 的实验性支持。 - **新增了** 实验性的 [DNS certificate management](/zh/blog/2019/dns-cert/) 以安全地配置和管理 `Kubernetes CA` 签名的 `DNS` 证书。 diff --git a/content/zh/news/releases/1.5.x/announcing-1.5/_index.md b/content/zh/news/releases/1.5.x/announcing-1.5/_index.md index 04540b1ca7..087ccad9ff 100644 --- a/content/zh/news/releases/1.5.x/announcing-1.5/_index.md +++ b/content/zh/news/releases/1.5.x/announcing-1.5/_index.md @@ -47,7 +47,7 @@ Istio 一直都是可扩展性最好的服务网格，其 Mixer 插件允许自 ## 更安全{#more-secure} -我们一如既往的在努力使每个 Istio 发布版都更加安全。在 1.5 中，所有安全策略（包括 [自动 mTLS](/zh/docs/tasks/security/authentication/auto-mtls/)、[`AuthenticationPolicy`](/zh/docs/reference/config/security/istio.authentication.v1alpha1/)（`PeerAuthentication` 和 `RequestAuthentication`）以及授权现在都处于 Beta 版。SDS 现在是稳定的。授权现在支持 Deny 语义，以强制执行不可覆盖的强制性控件。我们已经将 Node 代理和 Istio 代理整合到一个二进制文件中，这意味着我们不再需要配置 `PodSecurityPolicy`。 +我们一如既往的在努力使每个 Istio 发布版都更加安全。在 1.5 中，所有安全策略（包括[自动 mTLS](/zh/docs/tasks/security/authentication/auto-mtls/)、[`AuthenticationPolicy`](/zh/docs/reference/config/security/istio.authentication.v1alpha1/)（`PeerAuthentication` 和 `RequestAuthentication`）以及授权现在都处于 Beta 版。SDS 现在是稳定的。授权现在支持 Deny 语义，以强制执行不可覆盖的强制性控件。我们已经将 Node 代理和 Istio 代理整合到一个二进制文件中，这意味着我们不再需要配置 `PodSecurityPolicy`。 不仅如此，我们也不再需要在每个 Pod 上安装证书、不必在更换证书时重启 Envoy。证书直接从 Istiod 下发到每个 pod。而且，每个 pod 的证书都是唯一证书。 @@ -55,12 +55,12 @@ Istio 一直都是可扩展性最好的服务网格，其 Mixer 插件允许自 ## 更好的可观察性{#better-observability} -我们将继续努力，使 Istio 成为您分布式应用的最佳选择。Telemetry v2 现在会报告原生 TCP 连接（除了HTTP）的度量标准，并且我们通过在遥测和日志中添加响应状态代码来增强了对 gRPC 工作负载的支持。现在默认使用 Telemetry v2。 +我们将继续努力，使 Istio 成为您分布式应用的最佳选择。Telemetry v2 现在会报告原生 TCP 连接（除了 HTTP）的度量标准，并且我们通过在遥测和日志中添加响应状态代码来增强了对 gRPC 工作负载的支持。现在默认使用 Telemetry v2。 新的遥测系统将等待时间缩短了一半，90％ 的等待时间从 7 毫秒 降低至 3.3 毫秒。不仅如此，移除 Mixer 还使总的 CPU 消耗减少了 50％（0.55 vCPU，1000 个请求/每秒）。 ## 加入 Istio 社区{#join-the-Istio-community} -与往常一样，很多事情都发生在[社区会议](https://github.com/istio/community#community-meeting)；每隔一个星期四的太平洋时间上午 11 点加入我们。我们希望您可以通过 [Istio Discuss](https://discuss.istio.io) 加入对话，此外，也可以加入我们的[Slack频道](https://istio.slack.com)。 +与往常一样，很多事情都发生在[社区会议](https://github.com/istio/community#community-meeting)；每隔一个星期四的太平洋时间上午 11 点加入我们。我们希望您可以通过 [Istio Discuss](https://discuss.istio.io) 加入对话，此外，也可以加入我们的 [Slack 频道](https://istio.slack.com)。 -我们很荣幸成为 GitHub [成长最快](https://octoverse.github.com/#top-and-trending-projects) 的五个开源项目之一。想参与其中吗？加入我们的[工作组](https://github.com/istio/community/blob/master/WORKING-GROUPS.md)之一，帮助我们使 Istio 变得更好。 +我们很荣幸成为 GitHub [成长最快](https://octoverse.github.com/#top-and-trending-projects)的五个开源项目之一。想参与其中吗？加入我们的[工作组](https://github.com/istio/community/blob/master/WORKING-GROUPS.md)之一，帮助我们使 Istio 变得更好。 diff --git a/content/zh/news/releases/1.5.x/announcing-1.5/upgrade-notes/index.md b/content/zh/news/releases/1.5.x/announcing-1.5/upgrade-notes/index.md index f5a850e7b2..d47c6700c8 100644 --- a/content/zh/news/releases/1.5.x/announcing-1.5/upgrade-notes/index.md +++ b/content/zh/news/releases/1.5.x/announcing-1.5/upgrade-notes/index.md @@ -34,7 +34,7 @@ Istio 1.5，会有一个新的 deployment：`istiod`。该组件是控制平面 ### Sidecar -以前，sidecar 可以通过两种方式访问证书：通过作为文件挂载的 secret 或 SDS（通过 `nodeagent`）。在 Istio 1.5 中，已对此进行了简化。所有 secret 信息将通过本地运行的SDS 服务器提供。对于大多数用户而言，这些 secret 将从 `istiod` deployment 中获取。对于具有自定义 CA 的用户，仍可以使用文件挂载的 secret，但是，本地 SDS 服务器仍将提供这些 secret。这意味着证书轮换不再需要重启 Envoy。 +以前，sidecar 可以通过两种方式访问证书：通过作为文件挂载的 secret 或 SDS（通过 `nodeagent`）。在 Istio 1.5 中，已对此进行了简化。所有 secret 信息将通过本地运行的 SDS 服务器提供。对于大多数用户而言，这些 secret 将从 `istiod` deployment 中获取。对于具有自定义 CA 的用户，仍可以使用文件挂载的 secret，但是，本地 SDS 服务器仍将提供这些 secret。这意味着证书轮换不再需要重启 Envoy。 ### CNI @@ -66,7 +66,7 @@ Mixer，即 `istio-telemetry` 和 `istio-policy` deployment 背后的过程， ## 认证策略{#authentication-policy} -Istio 1.5 引入了 [`PeerAuthentication`](/zh/docs/reference/config/security/peer_authentication/) 和 [`RequestAuthentication`](/zh/docs/reference/config/security/request_authentication) （它们取代了 Authentication API 的 Alpha 版本）。有关新 API 的更多信息，请参见[authentication policy](/zh/docs/tasks/security/authentication/authn-policy)教程。 +Istio 1.5 引入了 [`PeerAuthentication`](/zh/docs/reference/config/security/peer_authentication/) 和 [`RequestAuthentication`](/zh/docs/reference/config/security/request_authentication) （它们取代了 Authentication API 的 Alpha 版本）。有关新 API 的更多信息，请参见 [authentication policy](/zh/docs/tasks/security/authentication/authn-policy) 教程。 * 升级 Istio 后，您 Alpha 版的身份验证策略将被保留并继续使用。您可以逐步将它们替换为等效的 `PeerAuthentication` 和 `RequestAuthentication`。新策略将根据定义的范围内接管旧策略。我们建议从 workload（最具体的范围）开始替换，然后是命名空间，最后是整个网格范围。 @@ -86,7 +86,7 @@ $ kubectl delete meshpolicies.authentication.istio.io --all 作为 Istiod 努力的一部分，我们已经更改了代理与控制平面安全通信的方式。在以前的版本中，当配置了 `values.global.controlPlaneSecurityEnabled=true` 设置时，代理将安全地连接到控制平面，这也是 Istio 1.4 的默认设置。每个控制平面组件都运行带有 Citadel 证书的 sidecar，并且代理通过端口 15011 连接到 Pilot。 -在 Istio 1.5中，代理与控制平面连接的推荐或默认方式不再是这样；相反，可以使用由 Kubernetes 或 Istiod 签名的 DNS 证书，通过 15012 端口连接到 Istiod。 +在 Istio 1.5 中，代理与控制平面连接的推荐或默认方式不再是这样；相反，可以使用由 Kubernetes 或 Istiod 签名的 DNS 证书，通过 15012 端口连接到 Istiod。 注意：尽管如此，但在 Istio 1.5 中，将 `controlPlaneSecurityEnabled` 设置为 `false` 时，默认情况下控制平面之间的通信已经是安全的。 @@ -100,4 +100,4 @@ $ kubectl delete meshpolicies.authentication.istio.io --all ## Helm 升级{#helm-upgrade} -如果您使用 `helm upgrade` 将群集更新到较新的 Istio 版本，则建议您使用 [`istioctl upgrade`](/zh/docs/setup/upgrade/istioctl-upgrade/) 或遵循[helm template](/zh/docs/setup/upgrade/cni-helm-upgrade/) 的步骤。 +如果您使用 `helm upgrade` 将群集更新到较新的 Istio 版本，则建议您使用 [`istioctl upgrade`](/zh/docs/setup/upgrade/istioctl-upgrade/) 或遵循 [helm template](/zh/docs/setup/upgrade/cni-helm-upgrade/) 的步骤。 diff --git a/content/zh/news/security/istio-security-2019-001/index.md b/content/zh/news/security/istio-security-2019-001/index.md index 58cbaa3176..9d447e0140 100644 --- a/content/zh/news/security/istio-security-2019-001/index.md +++ b/content/zh/news/security/istio-security-2019-001/index.md @@ -56,6 +56,6 @@ disablePolicyChecks: true ## 致谢{#credit} -Istio 团队非常感谢 `Haim Helman` 报告该缺陷。 +Istio 团队非常感谢 `Haim Helman` 报告该缺陷。 {{< boilerplate "security-vulnerability" >}} diff --git a/content/zh/news/security/istio-security-2019-002/index.md b/content/zh/news/security/istio-security-2019-002/index.md index 7481c5fa5d..714a95f6de 100644 --- a/content/zh/news/security/istio-security-2019-002/index.md +++ b/content/zh/news/security/istio-security-2019-002/index.md @@ -29,7 +29,7 @@ aliases: Epoch 0 terminated with an error: signal: segmentation fault (core dumped) {{< /text >}} -无论 JWT 规范中的 `trigger_rules` 如何设置，Envoy 都可能因为格式错误的 JWT token (没有有效的签名) 崩溃，导致所有 URI 访问不受限制。 因此，这个 BUG 使 Envoy 容易受到潜在的 DoS 攻击。 +无论 JWT 规范中的 `trigger_rules` 如何设置，Envoy 都可能因为格式错误的 JWT token (没有有效的签名) 崩溃，导致所有 URI 访问不受限制。因此，这个 BUG 使 Envoy 容易受到潜在的 DoS 攻击。 ## 影响范围{#impact-and-detection} @@ -39,14 +39,14 @@ Epoch 0 terminated with an error: signal: segmentation fault (core dumped) * 使 JWT issuer(由 `jwksUri` 发行) 使用 RSA 算法进行签名认证。 {{< tip >}} -用于签名认证的 RSA 算法不包含任何已知的安全漏洞。 仅当使用此算法时才触发此 CVE，但与系统的安全性无关。 +用于签名认证的 RSA 算法不包含任何已知的安全漏洞。仅当使用此算法时才触发此 CVE，但与系统的安全性无关。 {{< /tip >}} 如果将 JWT 策略应用于 Istio ingress gateway。请注意，有权访问 Ingress gateway 的任何外部用户都可以通过单个 HTTP 请求导致它崩溃。 -如果仅将 JWT 策略应用 Sidecar， 请记住它仍然可能受到攻击。 例如，Istio ingress gateway 可能会将 JWT token 转发到 Sidecar，这可能是格式错误的 JWT token ，该 token 可能让 Sidecar 崩溃。 +如果仅将 JWT 策略应用 Sidecar，请记住它仍然可能受到攻击。例如，Istio ingress gateway 可能会将 JWT token 转发到 Sidecar，这可能是格式错误的 JWT token ，该 token 可能让 Sidecar 崩溃。 -易受攻击的 Envoy 将在处理 JWT token 格式错误的 HTTP 请求上崩溃。 当 Envoy 崩溃时，所有现有连接将立即断开连接。 `pilot-agent` 将自动重启崩溃的 Envoy，重启可能需要几秒钟到几分钟的时间。 崩溃超过十次后，pilot-agent 将停止重新启动 Envoy。 在这种情况下，Kubernetes 将重新部署 Pod，包括 Envoy 的工作负载。 +易受攻击的 Envoy 将在处理 JWT token 格式错误的 HTTP 请求上崩溃。当 Envoy 崩溃时，所有现有连接将立即断开连接。`pilot-agent` 将自动重启崩溃的 Envoy，重启可能需要几秒钟到几分钟的时间。崩溃超过十次后，pilot-agent 将停止重新启动 Envoy。在这种情况下，Kubernetes 将重新部署 Pod，包括 Envoy 的工作负载。 要检测集群中是否应用了任何 JWT 身份认证策略，请运行以下命令，该命令将显示以下任一输出： @@ -97,7 +97,7 @@ $ cd tools/examples/luacheck/ $ ./setup.sh {{< /text >}} -安装脚本使用 Helm 模板来生成一个 `envoyFilter` 资源，该资源将部署到 Gateway。 您可以将 Listener 类型更改为 `ANY`，以将其也应用到 Sidecar。只有当您在 Sidecar 上强制使用 JWT 身份认证策略，并在直接接收外部的请求，才应该这样做。 +安装脚本使用 Helm 模板来生成一个 `envoyFilter` 资源，该资源将部署到 Gateway。您可以将 Listener 类型更改为 `ANY`，以将其也应用到 Sidecar。只有当您在 Sidecar 上强制使用 JWT 身份认证策略，并在直接接收外部的请求，才应该这样做。 ## 致谢{#credit}