mirror of https://github.com/istio/istio.io.git
fmt for zh content (#6816)
This commit is contained in:
2BFL
GitHub
parent
3721683c21
commit
d6e6e65271
|
|
@ -13,9 +13,9 @@ icon: bugs
|
|||
|
||||
## 产品错误{#product-bugs}
|
||||
|
||||
搜索我们的 [问题数据库](https://github.com/istio/istio/issues/) 来查看是否我们已经知道您的问题，并了解何时可以解决它。如果您在该数据库中没有找到你的问题，请打开一个 [新问题](https://github.com/istio/istio/issues/new/choose) 让我们知道出现了什么错误。
|
||||
搜索我们的[问题数据库](https://github.com/istio/istio/issues/)来查看是否我们已经知道您的问题，并了解何时可以解决它。如果您在该数据库中没有找到你的问题，请打开一个[新问题](https://github.com/istio/istio/issues/new/choose)让我们知道出现了什么错误。
|
||||
|
||||
如果您认为错误实际上是一个安全漏洞，请访问 [报告安全漏洞](/zh/about/security-vulnerabilities/) 了解如何处理。
|
||||
如果您认为错误实际上是一个安全漏洞，请访问[报告安全漏洞](/zh/about/security-vulnerabilities/)了解如何处理。
|
||||
|
||||
### Kubernetes 集群状态档案{#Kubernetes-cluster-state-archives}
|
||||
|
||||
|
|
@ -81,4 +81,4 @@ icon: bugs
|
|||
|
||||
## 文档错误{#documentation-bugs}
|
||||
|
||||
搜索我们的 [文档问题数据库](https://github.com/istio/istio.io/issues/) 以查看是否我们已经知道您的问题，并了解何时可以解决它。如果您在该数据库中找不到问题，请导航到这个问题的页面，然后在页面的右上角选择齿轮菜单，最后选择 *Report a Site Bug*。
|
||||
搜索我们的[文档问题数据库](https://github.com/istio/istio.io/issues/)以查看是否我们已经知道您的问题，并了解何时可以解决它。如果您在该数据库中找不到问题，请导航到这个问题的页面，然后在页面的右上角选择齿轮菜单，最后选择 *Report a Site Bug*。
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Istio 是一个开源项目，拥有一个支持其使用和持续开发的活
|
|||
{{< community_item logo="./slack.svg" alt="Slack" >}}
|
||||
如果您想与我们的社区成员进行实时互动，可以加入
|
||||
[Istio 的 Slack](https://istio.slack.com) 工作区。
|
||||
填写 [这个表格](https://docs.google.com/forms/d/e/1FAIpQLSfdsupDfOWBtNVvVvXED6ULxtR4UIsYGCH_cQcRr0VcG1ZqQQ/viewform)
|
||||
填写[这个表格](https://docs.google.com/forms/d/e/1FAIpQLSfdsupDfOWBtNVvVvXED6ULxtR4UIsYGCH_cQcRr0VcG1ZqQQ/viewform)
|
||||
加入我们。
|
||||
{{< /community_item >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ keywords: [contribute]
|
|||
|
||||
要避免的最重要也是最常见的错误，是简单地向读者提供您拥有的所有信息，因为您不确定他们需要什么信息。
|
||||
|
||||
如果您需要帮助特定内容的受众，我们很乐意在 [文档工作组](https://github.com/istio/community/blob/master/WORKING-GROUPS.md#istio-working-groups) 每两周一次的会议上帮助您并回答您的所有问题。
|
||||
如果您需要帮助特定内容的受众，我们很乐意在[文档工作组](https://github.com/istio/community/blob/master/WORKING-GROUPS.md#istio-working-groups)每两周一次的会议上帮助您并回答您的所有问题。
|
||||
|
||||
## 内容类型{#content-types}
|
||||
|
||||
|
|
@ -87,7 +87,7 @@ keywords: [contribute]
|
|||
<td>
|
||||
着重于完成 Istio 部署所需的安装步骤。安装页面必须包括自动测试，因为它们已经过测试和维护以确保技术准确性。
|
||||
</td>
|
||||
<td>想要完成部署的新旧Istio用户。</td>
|
||||
<td>想要完成部署的新旧 Istio 用户。</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>博客文章</td>
|
||||
|
|
@ -133,7 +133,7 @@ keywords: [contribute]
|
|||
|
||||
## 将您的贡献提交到 GitHub{#submit-your-contribution-to-GitHub}
|
||||
|
||||
如果您不熟悉GitHub，请参阅 [使用 GitHub 参与社区活动](/zh/about/contribute/github)，以了解如何提交文档更改。
|
||||
如果您不熟悉 GitHub，请参阅[使用 GitHub 参与社区活动](/zh/about/contribute/github)，以了解如何提交文档更改。
|
||||
|
||||
如果您想了解有关发表文稿的方式和时间的更多信息，请参阅 [分支策略](/zh/about/contribute/github#branching-strategy)，
|
||||
如果您想了解有关发表文稿的方式和时间的更多信息，请参阅[分支策略](/zh/about/contribute/github#branching-strategy)，
|
||||
以了解我们如何使用分支和 `cherry picking` 来发布我们的内容。
|
||||
|
|
|
|||
|
|
@ -206,7 +206,7 @@ The file has three separate snippets: `SNIP1`, `SNIP2`, and `SNIP3`. The convent
|
|||
|
||||
## 链接 GitHub 上的文件{#link-2-files}
|
||||
|
||||
有些代码块需要引用 [Istio 的 GitHub 仓库](https://github.com/istio/istio) 中的文件。其中最常见的情况就是引用 YAML 配置文件。无需将 YAML 文件的全部内容复制到您的代码块中，您可以使用 `@` 符号将文件的相对路径名括起来。此标记会将路径渲染为指向 GitHub 中当前发行版本分支的文件的链接，例如：
|
||||
有些代码块需要引用 [Istio 的 GitHub 仓库](https://github.com/istio/istio)中的文件。其中最常见的情况就是引用 YAML 配置文件。无需将 YAML 文件的全部内容复制到您的代码块中，您可以使用 `@` 符号将文件的相对路径名括起来。此标记会将路径渲染为指向 GitHub 中当前发行版本分支的文件的链接，例如：
|
||||
|
||||
{{< text markdown >}}
|
||||
{{</* text bash */>}}
|
||||
|
|
@ -265,8 +265,8 @@ $ kubectl -n istio-system logs $(kubectl -n istio-system get pods -l istio-mixer
|
|||
|`url` | 在代码块中显示的文档的 URL。
|
||||
|`syntax` | 代码块的语法。
|
||||
|`outputis` | 当语法为 bash 时，该属性指定命令输出结果的语法。
|
||||
|`downloadas` | 当用户 [下载该代码块时](#download-name) 默认的文件名。
|
||||
|`expandlinks` | 是否在代码块中为 [GitHub 文件引用](#link-2-files) 开启链接扩展。
|
||||
|`downloadas` | 当用户[下载该代码块时](#download-name)默认的文件名。
|
||||
|`expandlinks` | 是否在代码块中为 [GitHub 文件引用](#link-2-files)开启链接扩展。
|
||||
|`snippet` | 要从代码块中提取的内容的 [snippet](#snippets) 名称。
|
||||
|`repo` | The repository to use for [GitHub links](#link-2-files) embedded in preformatted blocks.
|
||||
|`repo` | 嵌入代码块中的仓库的 [GitHub 链接](#link-2-files)。
|
||||
|
|
@ -288,4 +288,4 @@ func HelloWorld() {
|
|||
|
||||
- 对于内联内容，使用的当前页面的标题
|
||||
- 导入代码的源文件的名称
|
||||
- 导入代码的源的URL
|
||||
- 导入代码的源的 URL
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ keywords: [contribute,diagram,documentation,guide]
|
|||
|
||||
欢迎学习 Istio 图表指南！
|
||||
|
||||
本指南通过一个 [SVG 文件](./diagram-guidelines.svg) 或者 [Google Draw 文件](https://docs.google.com/drawings/d/1f3NyutAQIDOA8ojGNyMA5JAJllDShZGQAFfdD01XdSc/edit) 使您可以轻松的复用 shape 和 style。
|
||||
本指南通过一个 [SVG 文件](./diagram-guidelines.svg)或者 [Google Draw 文件](https://docs.google.com/drawings/d/1f3NyutAQIDOA8ojGNyMA5JAJllDShZGQAFfdD01XdSc/edit)使您可以轻松的复用 shape 和 style。
|
||||
通过本指南，您可以使用任何矢量图绘制工具（例如，Google Draw、InkScape、Illustrator）为 Istio 站点创建 SVG 图表。
|
||||
请保持图表中的文本处于可编辑状态。
|
||||
|
||||
|
|
@ -17,11 +17,11 @@ keywords: [contribute,diagram,documentation,guide]
|
|||
|
||||
若要创建您的图表，请参照下面的步骤：
|
||||
|
||||
1. 参考 [指南](./diagram-guidelines.svg)，并根据需要从中复制粘贴。
|
||||
1. 参考[指南](./diagram-guidelines.svg)，并根据需要从中复制粘贴。
|
||||
1. 用适当的线条连接 shape。
|
||||
1. 用简短的描述性文字标记 shape 和线条。
|
||||
1. 为多次应用的标签添加图例。
|
||||
1. 将您的图表 [贡献](/zh/about/contribute/add-content) 给我们的文档。
|
||||
1. 将您的图表[贡献](/zh/about/contribute/add-content)给我们的文档。
|
||||
|
||||
如果您是在 Google Draw 中创建图表，请参照下面的步骤：
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ Istio 文档协作遵循标准的 [GitHub 协作流](https://guides.github.com/i
|
|||
|
||||
1. 创建 [GitHub 帐户](https://github.com)。
|
||||
|
||||
1. 签署 [贡献者许可协议](https://github.com/istio/community/blob/master/CONTRIBUTING.md#contributor-license-agreements)。
|
||||
1. 签署[贡献者许可协议](https://github.com/istio/community/blob/master/CONTRIBUTING.md#contributor-license-agreements)。
|
||||
|
||||
1. 安装 [Docker](https://www.docker.com/get-started)，以预览和测试您的文档更改。
|
||||
|
||||
|
|
@ -61,17 +61,17 @@ Istio 文档存储库使用多个分支发布所有 Istio 版本的文档。每
|
|||
|
||||
这种分支策略允许我们提供以下 Istio 在线资源：
|
||||
|
||||
- [发布站点](/zh/docs/) 提供当前最新发布分支的内容。
|
||||
- [发布站点](/zh/docs/)提供当前最新发布分支的内容。
|
||||
|
||||
- 预备站点 `https://preliminary.istio.io` 发布了当前 Master 分支上的最新内容。
|
||||
|
||||
- [存档站点](https://archive.istio.io) 提供所有已发布分支的内容。
|
||||
- [存档站点](https://archive.istio.io)提供所有已发布分支的内容。
|
||||
|
||||
考虑到分支的工作原理，如果您提交修改到 master 分支，在 Istio 的下一个 major 版本发布前，这些更改都不会被应用到 istio.io。
|
||||
如果您的文档更改和当前 Istio 版本密切相关，也可以将更改应用到当前版本的 Release 分支。您可以通过在文档的 PR 上使用 cherry-pick 标签，自动地执行此操作。
|
||||
例如，如果您在 PR 中向 master 分支引入了更正，则可以通过 `cherrypick/release-1.4` 标签以将此更改合并到 `release-1.4` 分支。
|
||||
|
||||
一旦您的初始PR被合并，将自动在 Release 分支创建一个包含您的更改的 PR。为了使 `CLA` 机器人可以继续工作，您可能需要在 PR 上添加一个内容为 `@googlebot I consent` 的评论。
|
||||
一旦您的初始 PR 被合并，将自动在 Release 分支创建一个包含您的更改的 PR。为了使 `CLA` 机器人可以继续工作，您可能需要在 PR 上添加一个内容为 `@googlebot I consent` 的评论。
|
||||
|
||||
在极少数情况下，cherry picks 功能可能无效。发生这种情况时，自动化程序将在原始 PR 中留下一条注释，表明它已失败。发生这种情况时，您将需要手动创建 cherry pick，并处理阻止该过程自动运行的合并问题。
|
||||
|
||||
|
|
@ -83,4 +83,4 @@ Istio 文档存储库使用多个分支发布所有 Istio 版本的文档。每
|
|||
|
||||
访问我们的[社区角色页面](https://github.com/istio/community/blob/master/ROLES.md#role-summary)，在此页面您可以了解角色、相关的要求和职责以及与角色相关联的特权。
|
||||
|
||||
访问我们的 [社区](https://github.com/istio/community)，您可以全面了解有关 Istio 社区的更多信息。
|
||||
访问我们的[社区](https://github.com/istio/community)，您可以全面了解有关 Istio 社区的更多信息。
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ weight: 6
|
|||
keywords: [contribute,community,github,pr,documentation,review, approval]
|
||||
---
|
||||
|
||||
Istio 文档工作组（Docs WG）的维护者和工作组负责人审批针对 [Istio 网站](/zh/docs/) 的所有更改。
|
||||
Istio 文档工作组（Docs WG）的维护者和工作组负责人审批针对 [Istio 网站](/zh/docs/)的所有更改。
|
||||
|
||||
**文档审阅者** 是一个受信任的贡献者，负责批准符合[审阅标准](#review-criteria)的内容。
|
||||
所有审阅都遵循 [PR 内容审阅](#review-content-prs)中描述的流程。
|
||||
|
|
@ -25,7 +25,7 @@ Istio 文档工作组（Docs WG）的维护者和工作组负责人审批针对
|
|||
1. 如果贡献者尚未加入任何与贡献内相关的技术工作组，则**审阅者**可将其加入到相应工作组。
|
||||
1. **贡献者**和**审阅者**协同工作，直到内容符合所有[绝对验收标准](#required-acceptance-criteria)，且 Issue 得到完全解决。
|
||||
1. 如果内容非常紧急，且满足[补充验收标准](#required-acceptance-criteria)需要大量工作，**审阅者** 可在 istio.io 仓库提交[跟进 Issue](#follow-up-issues)，以在后续处理这些问题。
|
||||
1. **贡献者**根据审阅者和贡献者的意见，处理所有反馈。[跟进 Issue](#follow-up-issues)中提到的问题将在后续解决。
|
||||
1. **贡献者**根据审阅者和贡献者的意见，处理所有反馈。[跟进 Issue](#follow-up-issues) 中提到的问题将在后续解决。
|
||||
1. 当 **技术**工作组负责人或维护者批准 PR 内容，**审阅者** 可以批准 PR。
|
||||
1. 如果 Docs WG 维护者或负责人审阅了内容，则他们不仅会批准内容，还会对其进行合并。否则，维护者和负责人将自动收到**审阅者**的批准通知，并优先批准和合并已审阅的内容。
|
||||
|
||||
|
|
@ -70,4 +70,4 @@ Istio 文档工作组（Docs WG）的维护者和工作组负责人审批针对
|
|||
- 图形附件：遵循 Istio [图形创建指南](/zh/about/contribute/diagrams/)。
|
||||
- 示例代码：提供与内容密切相关且可测试的有效代码示例。
|
||||
- 内容服用：任何可重复的内容都遵循使用样板文本的可重用性策略。
|
||||
- 术语：所有新的术语都已经添加到术语表中，且定义清晰。
|
||||
- 术语：所有新的术语都已经添加到术语表中，且定义清晰。
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ aliases:
|
|||
keywords: [contribute]
|
||||
---
|
||||
|
||||
Istio 文档所有的内容都必须 **清晰明了** 且 **易于理解**。我们根据 Google 开发者风格指南中的 [重点](https://developers.google.com/style/highlights) 和 [通则](https://developers.google.com/style/tone) 定义了标准。关于您贡献的内容是如何被审核、接受的，请参见[审核页面](/zh/about/contribute/review)获取详情。
|
||||
Istio 文档所有的内容都必须 **清晰明了** 且 **易于理解**。我们根据 Google 开发者风格指南中的[重点](https://developers.google.com/style/highlights)和[通则](https://developers.google.com/style/tone)定义了标准。关于您贡献的内容是如何被审核、接受的，请参见[审核页面](/zh/about/contribute/review)获取详情。
|
||||
|
||||
您可以在此通过 Istio 特有的示例，找到 Istio 遵循的基本风格与实践指南的所有场景。
|
||||
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ icon: istio-blue-logo
|
|||
<ul>
|
||||
<li>{{< checkmark_icon >}} 使用 Istio logo 连接到 istio.io</li>
|
||||
<li>{{< checkmark_icon >}} 使用 Istio logo 宣传您的产品支持 Istio</li>
|
||||
<li>{{< checkmark_icon >}} 在有关 Istio 的博客文章或新闻文章中使用Istio logo</li>
|
||||
<li>{{< checkmark_icon >}} 在有关 Istio 的博客文章或新闻文章中使用 Istio logo</li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -33,4 +33,4 @@ LTS 版本的命名模式为：
|
|||
<major>.<minor>-alpha.<sha>
|
||||
{{< /text >}}
|
||||
|
||||
其中 `<major>.<minor>` 代表下一个LTS，`<sha>` 代表此版本构建基于的git提交。
|
||||
其中 `<major>.<minor>` 代表下一个 LTS，`<sha>` 代表此版本构建基于的 git 提交。
|
||||
|
|
|
|||
|
|
@ -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/) 功能配置谁有权访问服务帐户
|
||||
|
||||
|
|
@ -72,7 +72,7 @@ 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}
|
||||
|
||||
|
|
|
|||
|
|
@ -15,13 +15,13 @@ aliases:
|
|||
|
||||
采用 [Istio](/zh/) 项目的一大好处就是为服务金丝雀方式部署提供了控制便利。金丝雀部署（或上线）背后的想法是通过让一小部分用户流量引入的新版本进行测试，如果一切顺利，则可以增加（可能逐渐增加）百分比，逐步替换旧版本。如在过程中出现任何问题，则可以中止并回滚到旧版本。最简单的方式，是随机选择百分比请求到金丝雀版本，但在更复杂的方案下，则可以基于请求的区域，用户或其他属性。
|
||||
|
||||
基于领域的专业水平，您可能想知道为什么需要 Istio 来支持金丝雀部署，因为像 Kubernetes 这样的平台已经提供了进行 [版本上线](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) 和 [金丝雀部署](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments) 的方法。问题解决了吗 ？不完全是。虽然以这种方式进行部署可以在简单的情况下工作，但功能非常有限，特别是在大规模自动缩放的云环境中大流量的情况下。
|
||||
基于领域的专业水平，您可能想知道为什么需要 Istio 来支持金丝雀部署，因为像 Kubernetes 这样的平台已经提供了进行[版本上线](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)和[金丝雀部署](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)的方法。问题解决了吗 ？不完全是。虽然以这种方式进行部署可以在简单的情况下工作，但功能非常有限，特别是在大规模自动缩放的云环境中大流量的情况下。
|
||||
|
||||
## Kubernetes 中的金丝雀部署{#canary-deployment-in-Kubernetes}
|
||||
|
||||
假设我们有一个已部署的 **helloworld** 服务 **v1** 版本，我们想要测试（或简单上线）新版本 **v2**。使用 Kubernetes，您可以通过简单地更新服务的 [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) 中的镜像并自动进行部署来 [上线](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) 新版本的 **helloworld** 服务。如果我们特能够小心保证在启动并且在仅启动一个或两个 v2 副本[暂停](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#pausing-and-resuming-a-deployment)上线时有足够的 **v1** 副本运行，则能够保持金丝雀发布对系统的影响非常小。后续我们可以观察效果，或在必要时进行[回滚](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-back-a-deployment)。最好，我们也能够对 Deployment 设置 [HPA](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#scaling-a-deployment)，在上线过程中减少或增加副本以处理流量负载时，也能够保持副本比例一致。
|
||||
假设我们有一个已部署的 **helloworld** 服务 **v1** 版本，我们想要测试（或简单上线）新版本 **v2**。使用 Kubernetes，您可以通过简单地更新服务的 [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) 中的镜像并自动进行部署来[上线](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)新版本的 **helloworld** 服务。如果我们特能够小心保证在启动并且在仅启动一个或两个 v2 副本[暂停](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#pausing-and-resuming-a-deployment)上线时有足够的 **v1** 副本运行，则能够保持金丝雀发布对系统的影响非常小。后续我们可以观察效果，或在必要时进行[回滚](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-back-a-deployment)。最好，我们也能够对 Deployment 设置 [HPA](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#scaling-a-deployment)，在上线过程中减少或增加副本以处理流量负载时，也能够保持副本比例一致。
|
||||
|
||||
尽管这种机制能够很好工作，但这种方式只适用于部署的经过适当测试的版本，也就是说，更多的是蓝/绿发布，又称红/黑发布，而不是 “蜻蜓点水“ 式的金丝雀部署。实际上，对于后者（例如，并没有完全准备好或者无意对外暴露的版本），Kubernetes 中的金丝雀部署将使用具有 [公共 pod 标签](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively) 的两个 Deployment 来完成。在这种情况下，我们不能再使用自动缩放器，因为是有由两个独立的自动缩放器来进行控制，不同负载情况下，副本比例（百分比）可能与所需的比例不同。
|
||||
尽管这种机制能够很好工作，但这种方式只适用于部署的经过适当测试的版本，也就是说，更多的是蓝/绿发布，又称红/黑发布，而不是 “蜻蜓点水“ 式的金丝雀部署。实际上，对于后者（例如，并没有完全准备好或者无意对外暴露的版本），Kubernetes 中的金丝雀部署将使用具有[公共 pod 标签](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)的两个 Deployment 来完成。在这种情况下，我们不能再使用自动缩放器，因为是有由两个独立的自动缩放器来进行控制，不同负载情况下，副本比例（百分比）可能与所需的比例不同。
|
||||
|
||||
无论我们使用一个或者两个部署，使用 Docker，Mesos/Marathon 或 Kubernetes 等容器编排平台进行的金丝雀发布管理都存在一个根本问题：使用实例扩容来管理流量；版本流量分发和副本部署在上述平台中并独立。所有 pod 副本，无论版本如何，在 `kube-proxy` 循环池中都被一视同仁地对待，因此管理特定版本接收的流量的唯一方法是控制副本比例。以小百分比维持金丝雀流量需要许多副本（例如，1％ 将需要至少 100 个副本）。即使我们可以忽略这个问题，部署方式功能仍然非常有限，因为它只支持简单（随机百分比）金丝雀部署。如果我们想根据某些特定规则将请求路由到金丝雀版本上，我们仍然需要另一种解决方案。
|
||||
|
||||
|
|
@ -29,7 +29,7 @@ aliases:
|
|||
|
||||
使用 Istio，流量路由和副本部署是两个完全独立的功能。服务的 pod 数量可以根据流量负载灵活伸缩，与版本流量路由的控制完全正交。这在自动缩放的情况下能够更加简单地管理金丝雀版本。事实上，自动缩放管理器仍然独立运行，其在响应因流量路由导致的负载变化与其他原因导致负载变化的行为上没有区别。
|
||||
|
||||
Istio 的 [路由规则](/zh/docs/concepts/traffic-management/#routing-rules) 也带来了其他的便利；你可以轻松实现细粒度控制流量百分比（例如，路由 1％ 的流量而不需要 100 个 pod），当然也可以使用其他规则来控制流量（例如，将特定用户的流量路由到金丝雀版本）。作为展示，让我们看一下采用这种方式部署 **helloworld** 服务的简单便捷。
|
||||
Istio 的[路由规则](/zh/docs/concepts/traffic-management/#routing-rules)也带来了其他的便利；你可以轻松实现细粒度控制流量百分比（例如，路由 1％ 的流量而不需要 100 个 pod），当然也可以使用其他规则来控制流量（例如，将特定用户的流量路由到金丝雀版本）。作为展示，让我们看一下采用这种方式部署 **helloworld** 服务的简单便捷。
|
||||
|
||||
首先我们定义 **helloworld** 服务，和普通 **Kubernetes** 服务一样，如下所示：
|
||||
|
||||
|
|
@ -81,9 +81,9 @@ spec:
|
|||
...
|
||||
{{< /text >}}
|
||||
|
||||
需要注意的是，这与使用普通 Kubernetes 进行 [金丝雀部署](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments) 的方式完全相同，但是在 Kubernetes 方式下控制流量分配需要调整每个 Deployment 的副本数目。例如，将 10％ 的流量发送到金丝雀版本（v2），v1 和 v2 的副本可以分别设置为 9 和 1。
|
||||
需要注意的是，这与使用普通 Kubernetes 进行[金丝雀部署](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)的方式完全相同，但是在 Kubernetes 方式下控制流量分配需要调整每个 Deployment 的副本数目。例如，将 10％ 的流量发送到金丝雀版本（v2），v1 和 v2 的副本可以分别设置为 9 和 1。
|
||||
|
||||
但是在 [启用 Istio](/zh/docs/setup/) 的集群中，我们可以通过设置路由规则来控制流量分配。如将 10％ 的流量发送到金丝雀版本本，我们可以使用 `kubectl` 来设置以下的路由规则：
|
||||
但是在[启用 Istio](/zh/docs/setup/) 的集群中，我们可以通过设置路由规则来控制流量分配。如将 10％ 的流量发送到金丝雀版本本，我们可以使用 `kubectl` 来设置以下的路由规则：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
|
|
@ -231,4 +231,4 @@ EOF
|
|||
|
||||
支持金丝雀部署的智能路由只是 Istio 的众多功能之一，它将使基于大型微服务的应用程序的生产部署变得更加简单。查看 [istio.io](/zh/) 了解更多信息。
|
||||
|
||||
可在 [此处]({{< github_tree >}}/samples/helloworld) 查看示例代码。
|
||||
可在[此处]({{<github_tree >}}/samples/helloworld) 查看示例代码。
|
||||
|
|
|
|||
|
|
@ -21,11 +21,11 @@ target_release: 0.1
|
|||
|
||||
## 层级{#layer}
|
||||
|
||||
从 OSI 模型的角度来看7层（应用程序），Istio 策略运行在网络应用程序的“服务”层。但事实上云原生应用程序模型是7层实际上至少包含两层：服务层和内容层。服务层通常是 HTTP ，它封装了实际的应用程序数据（内容层）。Istio 的 Envoy 代理运行的 HTTP 服务层。相比之下，网络策略在 OSI 模型中的第3层（网络）和第4层（传输）运行。
|
||||
从 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}
|
||||
|
||||
|
|
@ -49,7 +49,7 @@ Envoy 代理的策略执行是在 pod 中，作为同一网络命名空间中的
|
|||
|
||||
## 举例{#examples}
|
||||
|
||||
让我们来看一些Istio应用程序使用 Kubernetes 网络策略的示例。 下面我们以 Bookinfo 应用程序为例，介绍网络策略功能的用例：
|
||||
让我们来看一些 Istio 应用程序使用 Kubernetes 网络策略的示例。 下面我们以 Bookinfo 应用程序为例，介绍网络策略功能的用例：
|
||||
|
||||
- 减少应用程序入口的攻击面
|
||||
- 在应用程序中实现细粒度隔离
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Mixer 服务作为 Istio 和一套开放式基础设施之间的抽象层。Isti
|
|||
|
||||
## 设计哲学{#philosophy}
|
||||
|
||||
Mixer 本质上就是一个处理属性和路由的机器。代理将 [属性](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes) 作为预检和遥测报告的一部分发送出来，并且转换为一系列对适配器的调用。运维人员提供了用于描述如何将传入的属性映射为适配器的配置。
|
||||
Mixer 本质上就是一个处理属性和路由的机器。代理将[属性](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes)作为预检和遥测报告的一部分发送出来，并且转换为一系列对适配器的调用。运维人员提供了用于描述如何将传入的属性映射为适配器的配置。
|
||||
|
||||
{{< image width="60%"
|
||||
link="/zh/docs/reference/config/policy-and-telemetry/mixer-overview/machine.svg"
|
||||
|
|
@ -53,7 +53,7 @@ Mixer 使用的每个适配器都需要一些配置才能运行。一般来说
|
|||
|
||||
你可以通过创建 [*instances*](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#instances) 来决定哪些数据被传递给特定的适配器。Instances 决定了 Mixer 如何通过 [attributes](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes) 把来自代理的属性拆分为各种数据然后分发给不同的适配器。
|
||||
|
||||
创建实例通常需要使用 [attribute expressions](/zh/docs/reference/config/policy-and-telemetry/expression-language/) 。这些表达式的功能是使用属性和常量来生成结果数据，用于给instance字段进行赋值。
|
||||
创建实例通常需要使用 [attribute expressions](/zh/docs/reference/config/policy-and-telemetry/expression-language/) 。这些表达式的功能是使用属性和常量来生成结果数据，用于给 instance 字段进行赋值。
|
||||
|
||||
在模板中定义的每个 instance 字段、每个属性、每个表达式都有一个 [type](https://github.com/istio/api/blob/{{< source_branch_name >}}/policy/v1beta1/value_type.proto)，只有兼容的数据类型才能进行赋值。例如不能把整型的表达式赋值给字符串类型。强类型设计的目的就是为了降低配置出错引发的风险。
|
||||
|
||||
|
|
@ -75,4 +75,4 @@ Rule 中包含有匹配断言，这个断言是一个返回布尔值的属性表
|
|||
|
||||
Handler 为各个适配器提供了配置数据，Template 用于在运行时确定不同的适配器所需的数据类型，Instance 让运维人员准备这些数据，Rule 将这些数据提交给一个或多个 Handler 进行处理。
|
||||
|
||||
更多信息可以关注 [这里](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/)。更多关于 templates, handlers,和 rules 的内容可以关注 [这里](/zh/docs/reference/config/policy-and-telemetry/)。你也可以在[这里]({{< github_tree >}}/samples/bookinfo) 找到对应的示例。
|
||||
更多信息可以关注[这里](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/)。更多关于 templates, handlers, 和 rules 的内容可以关注[这里](/zh/docs/reference/config/policy-and-telemetry/)。你也可以在[这里]({{<github_tree >}}/samples/bookinfo) 找到对应的示例。
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: 使用AWS NLB 配置 Istio Ingress
|
||||
description: 描述如何在AWS上使用网络负载均衡器配置 Istio Ingress。
|
||||
title: 使用 AWS NLB 配置 Istio Ingress
|
||||
description: 描述如何在 AWS 上使用网络负载均衡器配置 Istio Ingress。
|
||||
publishdate: 2018-04-20
|
||||
last_update: 2019-01-16
|
||||
subtitle: Ingress AWS 网络负载均衡器
|
||||
|
|
@ -13,9 +13,9 @@ target_release: 1.0
|
|||
本文已于 2019 年 1 月 16 日更新，其中包含一些使用警告。
|
||||
{{< /tip >}}
|
||||
|
||||
本文提供了使用 [AWS 网络负载均衡器](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) 配置 ingress Istio 的说明。
|
||||
本文提供了使用 [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}
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ Sidecar proxy 模式成就了很多奇迹。Sidecar 身处微服务的数据路
|
|||
|
||||
## AppSwitch
|
||||
|
||||
和容器运行时相比，AppSwitch 由客户端和一个守护进程组成，二者通过 HTTP 协议的 REST API 进行通信。客户端和守护进程构建为一个自包含的二进制文件 `ax`。客户端透明的注入s应用程序，并追踪网络相关的系统调用，随后通知守护进程。例如一个应用进行了 `connect(2)` 系统调用，目标是一个 Kubernetes 服务的 IP。AppSwitch 客户端拦截这一调用并令其失效，然后把这一事件及其参数和上下文环境告知守护进程。守护进程会处理系统调用，例如代表应用程序直接连接到上游服务器的 Pod IP。
|
||||
和容器运行时相比，AppSwitch 由客户端和一个守护进程组成，二者通过 HTTP 协议的 REST API 进行通信。客户端和守护进程构建为一个自包含的二进制文件 `ax`。客户端透明的注入 s 应用程序，并追踪网络相关的系统调用，随后通知守护进程。例如一个应用进行了 `connect(2)` 系统调用，目标是一个 Kubernetes 服务的 IP。AppSwitch 客户端拦截这一调用并令其失效，然后把这一事件及其参数和上下文环境告知守护进程。守护进程会处理系统调用，例如代表应用程序直接连接到上游服务器的 Pod IP。
|
||||
|
||||
值得注意的一点是，AppSwitch 的客户端和服务器之间不做任何数据转发。它们中间会通过 Unix socket 交换文件描述符，从而避免数据拷贝。另外客户端也不是独立进程，而是运行在应用本身的上下文之中的，因此应用和 AppSwitch 之间也不存在数据拷贝的操作。
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ target_release: 1.1
|
|||
但是在迁移这些系统之前，必须让服务网格内的应用程序能访问它们。还有其他情况，
|
||||
应用程序使用外部组织提供的 Web 服务，通常是通过万维网提供的服务。
|
||||
|
||||
在这篇博客文章中，我修改了[Istio Bookinfo 示例应用程序](/zh/docs/examples/bookinfo/)让它可以
|
||||
在这篇博客文章中，我修改了 [Istio Bookinfo 示例应用程序](/zh/docs/examples/bookinfo/)让它可以
|
||||
从外部 Web 服务（[Google Books APIs](https://developers.google.com/books/docs/v1/getting_started) ）获取图书详细信息。
|
||||
我将展示如何使用 _mesh-external service entries_ 在 Istio 中启用外部 HTTPS 流量。最后，
|
||||
我解释了当前与 Istio 出口流量控制相关的问题。
|
||||
|
|
@ -41,7 +41,7 @@ target_release: 1.1
|
|||
|
||||
### Bookinfo 使用 HTTPS 访问 Google 图书网络服务{#Bookinfo-with-https-access-to-a-google-books-web-service}
|
||||
|
||||
让我们添加一个新版本的 _details_ 微服务，_v2_，从[Google Books APIs](https://developers.google.com/books/docs/v1/getting_started)中获取图书详细信息。
|
||||
让我们添加一个新版本的 _details_ 微服务，_v2_，从 [Google Books APIs](https://developers.google.com/books/docs/v1/getting_started) 中获取图书详细信息。
|
||||
它设定了服务容器的 `DO_NOT_ENCRYPT` 环境变量为 `false`。此设置将指示已部署服务使用 HTTPS（而不是 HTTP ）来访问外部服务。
|
||||
|
||||
{{< text bash >}}
|
||||
|
|
@ -68,7 +68,7 @@ $ kubectl apply -f @samples/bookinfo/networking/virtual-service-details-v2.yaml@
|
|||
在[确定 ingress 的 IP 和端口](/zh/docs/examples/bookinfo/#determine-the-ingress-IP-and-port)之后，
|
||||
让我们访问应用程序的网页。
|
||||
|
||||
糟糕...页面显示 _Error fetching product details_，而不是书籍详细信息：
|
||||
糟糕... 页面显示 _Error fetching product details_，而不是书籍详细信息：
|
||||
|
||||
{{< image width="80%" link="errorFetchingBookDetails.png" caption="获取产品详细信息的错误消息" >}}
|
||||
|
||||
|
|
@ -77,14 +77,14 @@ $ 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/)。
|
||||
**阻止到集群外目的地的所有流量**, 要启用此类流量，我们必须定义 [mesh-external service entry](/zh/docs/reference/config/networking/service-entry/)。
|
||||
|
||||
### 启用对 Google Books 网络服务的 HTTPS 访问{#enable-https-access-to-a-google-books-web-service}
|
||||
|
||||
不用担心，让我们定义**网格外部 `ServiceEntry`** 并修复我们的应用程序。您还必须定义 _virtual
|
||||
service_ 使用 [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication)对外部服务执行路由。
|
||||
service_ 使用 [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication) 对外部服务执行路由。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
|
|
@ -161,7 +161,7 @@ $ kubectl delete -f @samples/bookinfo/platform/kube/bookinfo-details-v2.yaml@
|
|||
|
||||
这个故事有一个警告。假设您要监视您的微服务使用 [Google API](https://developers.google.com/apis-explorer/) 的哪个特定集
|
||||
（[书籍](https://developers.google.com/books/docs/v1/getting_started)，[日历](https://developers.google.com/calendar/)，[任务](https://developers.google.com/tasks/)等）
|
||||
假设您要强制执行仅允许使用[图书 API](https://developers.google.com/books/docs/v1/getting_started)的策略。
|
||||
假设您要强制执行仅允许使用[图书 API](https://developers.google.com/books/docs/v1/getting_started) 的策略。
|
||||
假设您要监控您的微服务访问的标识符。对于这些监视和策略任务，您需要知道 URL 路径。
|
||||
考虑例如 URL [`www.googleapis.com/books/v1/volumes?q=isbn:0486424618`](https://www.googleapis.com/books/v1/volumes?q=isbn:0486424618)。
|
||||
在该网址中，路径段指定了[图书 API](https://developers.google.com/books/docs/v1/getting_started)
|
||||
|
|
@ -304,7 +304,7 @@ $ kubectl delete -f @samples/bookinfo/platform/kube/bookinfo-details-v2.yaml@
|
|||
|
||||
### Istio 双向 TLS 的关系{#relation-to-Istio-mutual-TLS}
|
||||
|
||||
请注意，在这种情况下，TLS 的源与 Istio 应用的 [双向 TLS](/zh/docs/concepts/security/#mutual-TLS-authentication) 无关,
|
||||
请注意，在这种情况下，TLS 的源与 Istio 应用的[双向 TLS](/zh/docs/concepts/security/#mutual-TLS-authentication) 无关,
|
||||
无论 Istio 双向 TLS 是否启用，外部服务的 TLS 源都将起作用 , 保证服务网**内**的服务到服务通信，
|
||||
并为每个服务提供强大的身份认证, 在此博客文章中的 **外部服务**的情况下，我们有**单向** TLS，
|
||||
这是用于保护 Web 浏览器和 Web 服务器之间通信的相同机制 , TLS 应用于与外部服务的通信，
|
||||
|
|
@ -313,7 +313,7 @@ $ kubectl delete -f @samples/bookinfo/platform/kube/bookinfo-details-v2.yaml@
|
|||
## 结论{#conclusion}
|
||||
|
||||
在这篇博文中，我演示了 Istio 服务网格中的微服务如何通过 HTTPS 使用外部 Web 服务, 默认情况下，
|
||||
Istio 会阻止集群外主机的所有流量, 要启用此类流量，请使用 mesh-external,必须为服务网格创建 `ServiceEntry` ,
|
||||
Istio 会阻止集群外主机的所有流量, 要启用此类流量，请使用 mesh-external, 必须为服务网格创建 `ServiceEntry` ,
|
||||
可以通过 HTTPS 访问外部站点，当微服务发出 HTTPS 请求时，流量是端到端加密的，但是 Istio 无法监视 HTTP 详细信息，
|
||||
例如请求的 URL 路径。当微服务发出 HTTP 请求时，Istio 可以监视请求的 HTTP 详细信息并强制执行基于 HTTP 的访问策略。
|
||||
但是，在这种情况下，微服务和 sidecar 代理之间的流量是未加密的。在具有非常严格的安全要求的组织中，
|
||||
|
|
|
|||
|
|
@ -86,20 +86,20 @@ 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 数据库的版本。
|
||||
|
||||
本博文中的示例命令适用于 Istio 1.0。
|
||||
|
||||
作为提醒，这是 [Bookinfo 示例应用程序](/zh/docs/examples/bookinfo/) 的端到端架构。
|
||||
作为提醒，这是 [Bookinfo 示例应用程序](/zh/docs/examples/bookinfo/)的端到端架构。
|
||||
|
||||
{{< image width="80%" link="/zh/docs/examples/bookinfo/withistio.svg" caption="The original Bookinfo application" >}}
|
||||
|
||||
### 在 Bookinfo 应用程序中使用外部数据库{#use-the-external-database-in-Bookinfo-application}
|
||||
|
||||
1.部署使用 MongoDB 数据库的 _ratings_ 微服务（_ratings v2_）：
|
||||
1. 部署使用 MongoDB 数据库的 _ratings_ 微服务（_ratings v2_）：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo-ratings-v2.yaml@
|
||||
|
|
@ -199,7 +199,7 @@ $ export MONGODB_IP=$(host $MONGODB_HOST | grep " has address " | cut -d" " -f4)
|
|||
|
||||
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. 如果您未执行[上一节](#control-TCP-egress-traffic-without-a-gateway)中的步骤，则立即执行这些步骤。
|
||||
|
||||
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) 小节
|
||||
|
|
@ -434,7 +434,7 @@ $ export MONGODB_IP=$(host $MONGODB_HOST | grep " has address " | cut -d" " -f4)
|
|||
|
||||
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 的命令为：
|
||||
|
||||
|
|
@ -877,7 +877,7 @@ $ kubectl delete destinationrule egressgateway-for-mongo
|
|||
{{< /text >}}
|
||||
|
||||
1. 为 *.com 创建一个 egress Gateway，使用 443 端口和 TLS 协议。创建一个 destination rule 来为 gateway 设置 [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication)。
|
||||
以及为 Envoy 过滤器，以防止恶意应用程序篡改SNI (过滤器验证这个应用程序发布的 SNI与报告给 Mixer 的 SNI是否相同)
|
||||
以及为 Envoy 过滤器，以防止恶意应用程序篡改 SNI (过滤器验证这个应用程序发布的 SNI 与报告给 Mixer 的 SNI 是否相同)
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
|
|
|
|||
|
|
@ -8,13 +8,13 @@ keywords: [egress,traffic-management,access-control,monitoring]
|
|||
target_release: 1.1
|
||||
---
|
||||
|
||||
虽然 Istio 的主要关注点是管理服务网格内微服务之间的流量，但它也可以管理 ingress (从外部进入网格)和 egress (从网格向外)的流量。Istio 可以统一执行访问策略，并为网格内部、ingress 和 egress 流量聚合遥测数据。
|
||||
虽然 Istio 的主要关注点是管理服务网格内微服务之间的流量，但它也可以管理 ingress (从外部进入网格) 和 egress (从网格向外) 的流量。Istio 可以统一执行访问策略，并为网格内部、ingress 和 egress 流量聚合遥测数据。
|
||||
|
||||
在这篇博客文章中，将向您展示如何使用 Istio 进行 HTTP Egress 流量监控和访问策略。
|
||||
|
||||
## 用例{#use-case}
|
||||
|
||||
考虑一个运行处理 _cnn.com_ 内容的应用程序的组织。应用程序被解耦为部署在 Istio 服务网格中的微服务。应用程序访问 _cnn.com_ 的各种话题页面：[edition.cnn.com/politics](https://edition.cnn.com/politics)， [edition.cnn.com/sport](https://edition.cnn.com/sport) 和 [edition.cnn.com/health](https://edition.cnn.com/health)。该组织[配置了访问 edition.cnn.com 的权限](/zh/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/)，一切都正常运行。然而，在某一时刻，本组织决定移除政治话题。实际上，这意味着禁止访问 [edition.cnn.com/politics](https://edition.cnn.com/politics) ，只允许访问 [edition.cnn.com/sport](https://edition.cnn.com/sport)和[edition.cnn.com/health](https://edition.cnn.com/health) 。该组织将根据具体情况，向个别应用程序和特定用户授予访问 [edition.cnn.com/politics](https://edition.cnn.com/politics) 的权限。
|
||||
考虑一个运行处理 _cnn.com_ 内容的应用程序的组织。应用程序被解耦为部署在 Istio 服务网格中的微服务。应用程序访问 _cnn.com_ 的各种话题页面：[edition.cnn.com/politics](https://edition.cnn.com/politics)， [edition.cnn.com/sport](https://edition.cnn.com/sport) 和 [edition.cnn.com/health](https://edition.cnn.com/health)。该组织[配置了访问 edition.cnn.com 的权限](/zh/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/)，一切都正常运行。然而，在某一时刻，本组织决定移除政治话题。实际上，这意味着禁止访问 [edition.cnn.com/politics](https://edition.cnn.com/politics) ，只允许访问 [edition.cnn.com/sport](https://edition.cnn.com/sport) 和 [edition.cnn.com/health](https://edition.cnn.com/health) 。该组织将根据具体情况，向个别应用程序和特定用户授予访问 [edition.cnn.com/politics](https://edition.cnn.com/politics) 的权限。
|
||||
|
||||
为了实现这一目标，组织的运维人员监控对外部服务的访问，并分析 Istio 日志，以验证没有向 [edition.cnn.com/politics](https://edition.cnn.com/politics) 发送未经授权的请求。他们还配置了 Istio 来防止自动访问 [edition.cnn.com/politics](https://edition.cnn.com/politics) 。
|
||||
|
||||
|
|
@ -24,7 +24,7 @@ target_release: 1.1
|
|||
|
||||
* [Control Egress 流量](/zh/docs/tasks/traffic-management/egress/)任务演示了网格内的应用程序如何访问外部(Kubernetes 集群之外) HTTP 和 HTTPS 服务。
|
||||
* [配置 Egress 网关](/zh/docs/tasks/traffic-management/egress/egress-gateway/)示例描述了如何配置 Istio 来通过一个称为 _出口网关_ 的专用网关服务来引导出口流量。
|
||||
* [带 TLS 发起的 Egress 网关](/zh/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/) 示例演示了如何允许应用程序向需要 HTTPS 的外部服务器发送 HTTP 请求，同时通过 Egress Gateway 引导流量。
|
||||
* [带 TLS 发起的 Egress 网关](/zh/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/)示例演示了如何允许应用程序向需要 HTTPS 的外部服务器发送 HTTP 请求，同时通过 Egress Gateway 引导流量。
|
||||
* [收集指标](/zh/docs/tasks/observability/metrics/collecting-metrics/)任务描述如何为网格中的服务配置指标。
|
||||
* [Grafana 的可视化指标](/zh/docs/tasks/observability/metrics/using-istio-dashboard/)描述了用于监控网格流量的 Istio 仪表板。
|
||||
* [基本访问控制](/zh/docs/tasks/policy-enforcement/denial-and-list/)任务显示如何控制对网格内服务的访问。
|
||||
|
|
@ -44,7 +44,7 @@ target_release: 1.1
|
|||
|
||||
### 日志{#logging}
|
||||
|
||||
配置 Istio 以记录对 _*.cnn.com_ 的访问。创建一个 `logentry` 和两个 [stdio](/zh/docs/reference/config/policy-and-telemetry/adapters/stdio/) `handlers`，一个用于记录禁止访问(_error_ 日志级别)，另一个用于记录对 _*.cnn.com_ 的所有访问(_info_ 日志级别)。然后创建规则将 `logentry` 实例定向到 `handlers`。一个规则指导访问 _*.cnn.com/politics_ 为日志禁止访问处理程序,另一个规则指导日志条目的处理程序，输出每个访问 _*.cnn.com_ 作为 _info_ 的日志级别。要了解 Istio `logentries`、`rules` 和 `handlers`，请参见 [Istio 适配器模型](/zh/blog/2017/adapter-model/)。下图显示了涉及的实体和它们之间的依赖关系：
|
||||
配置 Istio 以记录对 _*.cnn.com_ 的访问。创建一个 `logentry` 和两个 [stdio](/zh/docs/reference/config/policy-and-telemetry/adapters/stdio/) `handlers`，一个用于记录禁止访问(_error_ 日志级别)，另一个用于记录对 _*.cnn.com_ 的所有访问(_info_ 日志级别)。然后创建规则将 `logentry` 实例定向到 `handlers`。一个规则指导访问 _*.cnn.com/politics_ 为日志禁止访问处理程序, 另一个规则指导日志条目的处理程序，输出每个访问 _*.cnn.com_ 作为 _info_ 的日志级别。要了解 Istio `logentries`、`rules` 和 `handlers`，请参见 [Istio 适配器模型](/zh/blog/2017/adapter-model/)。下图显示了涉及的实体和它们之间的依赖关系：
|
||||
|
||||
{{< image width="80%"
|
||||
link="egress-adapters-monitoring.svg"
|
||||
|
|
@ -225,9 +225,9 @@ target_release: 1.1
|
|||
{"level":"error","time":"2019-01-29T07:55:59.686082Z","instance":"egress-access.logentry.istio-system","destination":"edition.cnn.com","path":"/politics","reporterUID":"kubernetes://istio-egressgateway-747b6764b8-44rrh.istio-system","responseCode":404,"responseSize":0,"sourcePrincipal":"cluster.local/ns/default/sa/sleep"}
|
||||
{{< /text >}}
|
||||
|
||||
你依然会得到关于访问[edition.cnn.com/politics](https://edition.cnn.com/politics)的信息和错误消息，然而这次 `responseCode` 会像我们预想的那样返回 `404` 。
|
||||
你依然会得到关于访问 [edition.cnn.com/politics](https://edition.cnn.com/politics) 的信息和错误消息，然而这次 `responseCode` 会像我们预想的那样返回 `404` 。
|
||||
|
||||
虽然在这个简单的例子中使用 Istio 路由实现访问控制是可行的，但是在更复杂的例子中就不够了。例如，组织可能希望在某些条件下允许访问[edition.cnn.com/politics](https://edition.cnn.com/politics)，因此需要比仅通过 URL 路径过滤更复杂的策略逻辑。您可能想要应用 Istio Mixer 适配器，例如允许/禁止 URL 路径的[白名单或黑名单](/zh/docs/tasks/policy-enforcement/denial-and-list/#attribute-based-whitelists-or-blacklists)。策略规则允许指定复杂的条件，用丰富的表达式语言指定，其中包括与和或逻辑运算符。这些规则可用于日志记录和策略检查。更高级的用户可能希望应用基于 [Istio 角色访问控制](/zh/docs/concepts/security/#authorization)。
|
||||
虽然在这个简单的例子中使用 Istio 路由实现访问控制是可行的，但是在更复杂的例子中就不够了。例如，组织可能希望在某些条件下允许访问 [edition.cnn.com/politics](https://edition.cnn.com/politics)，因此需要比仅通过 URL 路径过滤更复杂的策略逻辑。您可能想要应用 Istio Mixer 适配器，例如允许/禁止 URL 路径的[白名单或黑名单](/zh/docs/tasks/policy-enforcement/denial-and-list/#attribute-based-whitelists-or-blacklists)。策略规则允许指定复杂的条件，用丰富的表达式语言指定，其中包括与和或逻辑运算符。这些规则可用于日志记录和策略检查。更高级的用户可能希望应用基于 [Istio 角色访问控制](/zh/docs/concepts/security/#authorization)。
|
||||
|
||||
另一方面是与远程访问策略系统的集成。如果在我们的用例中组织操作一些[标识和访问管理](https://en.wikipedia.org/wiki/Identity_management)系统，您可能希望配置 Istio 来使用来自这样一个系统的访问策略信息。您可以通过应用 [Istio Mixer 适配器](/zh/blog/2017/adapter-model/)来实现这种集成。
|
||||
|
||||
|
|
@ -339,7 +339,7 @@ target_release: 1.1
|
|||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
1. 执行常规测试，将 HTTP 请求发送到[edition.cnn.com/politics](https://edition.cnn.com/politics)， [edition.cnn.com/sport](https://edition.cnn.com/sport) 和 [edition.cnn.com/health](https://edition.cnn.com/health)。正如所料，对 [edition.cnn.com/politics](https://edition.cnn.com/politics) 的请求返回 _403_ （禁止）。
|
||||
1. 执行常规测试，将 HTTP 请求发送到 [edition.cnn.com/politics](https://edition.cnn.com/politics)， [edition.cnn.com/sport](https://edition.cnn.com/sport) 和 [edition.cnn.com/health](https://edition.cnn.com/health)。正如所料，对 [edition.cnn.com/politics](https://edition.cnn.com/politics) 的请求返回 _403_ （禁止）。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl exec -it $SOURCE_POD -c sleep -- sh -c 'curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/politics; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/sport; curl -sL -o /dev/null -w "%{http_code}\n" http://edition.cnn.com/health'
|
||||
|
|
@ -352,7 +352,7 @@ target_release: 1.1
|
|||
|
||||
在我们用例中的组织设法配置日志和访问控制之后，它决定扩展它的访问策略，允许具有特殊[服务帐户](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)的应用程序访问 _cnn.com_ 的任何主题，而不受监控。您将看到如何在 Istio 中配置此需求。
|
||||
|
||||
1. 使用 `politics` 服务账户开启[sleep]({{< github_tree >}}/samples/sleep) 示例程序。
|
||||
1. 使用 `politics` 服务账户开启 [sleep]({{< github_tree >}}/samples/sleep) 示例程序。
|
||||
|
||||
{{< text bash >}}
|
||||
$ sed 's/: sleep/: politics/g' samples/sleep/sleep.yaml | kubectl create -f -
|
||||
|
|
@ -432,7 +432,7 @@ target_release: 1.1
|
|||
200
|
||||
{{< /text >}}
|
||||
|
||||
由于 `SOURCE_POD` 没有 `politics` 服务帐户，所以像以前一样访问[edition.cnn.com/politics](https://edition.cnn.com/politics) 会被禁止。
|
||||
由于 `SOURCE_POD` 没有 `politics` 服务帐户，所以像以前一样访问 [edition.cnn.com/politics](https://edition.cnn.com/politics) 会被禁止。
|
||||
|
||||
1. 从 `SOURCE_POD_POLITICS` 中执行之前的测试：
|
||||
|
||||
|
|
@ -471,7 +471,7 @@ link="https-to-gateway.svg"
|
|||
caption="HTTPS egress 流量通过 egress 网关"
|
||||
>}}
|
||||
|
||||
从安全的角度来看，端到端 HTTPS 被认为是一种更好的方法。然而，由于流量是加密的，Istio 代理和出口网关只能看到源和目标 IP 以及目标的 [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication)。由于您将 Istio 配置为在 sidecar 代理和 egress 网关之间使用相互的 TLS ，所以[源标识](/zh/docs/concepts/security/#istio-identity)也是已知的。网关无法检查 URL 路径、HTTP 方法和请求的头，因此无法基于 HTTP 信息进行监控和策略。在我们的用例中，组织将能够允许访问 _edition.cnn.com_ 并指定允许哪些应用程序访问 _edition.cnn.com_ 。但是，将不可能允许或阻止对 _edition.cnn.com_ 的特定URL路径的访问。使用HTTPS方法既不能阻止对 [edition.cnn.com/politics](https://edition.cnn.com/politics) 的访问，也不能监控此类访问。
|
||||
从安全的角度来看，端到端 HTTPS 被认为是一种更好的方法。然而，由于流量是加密的，Istio 代理和出口网关只能看到源和目标 IP 以及目标的 [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication)。由于您将 Istio 配置为在 sidecar 代理和 egress 网关之间使用相互的 TLS ，所以[源标识](/zh/docs/concepts/security/#istio-identity)也是已知的。网关无法检查 URL 路径、HTTP 方法和请求的头，因此无法基于 HTTP 信息进行监控和策略。在我们的用例中，组织将能够允许访问 _edition.cnn.com_ 并指定允许哪些应用程序访问 _edition.cnn.com_ 。但是，将不可能允许或阻止对 _edition.cnn.com_ 的特定 URL 路径的访问。使用 HTTPS 方法既不能阻止对 [edition.cnn.com/politics](https://edition.cnn.com/politics) 的访问，也不能监控此类访问。
|
||||
|
||||
我们认为，每个组织都应充分考虑这两种方法的优缺点，并选择最适合其需要的方法。
|
||||
|
||||
|
|
|
|||
|
|
@ -132,7 +132,7 @@ target_release: 1.0
|
|||
|
||||
为了演示使用外部数据库的场景，你首先使用安装了 [Istio](/zh/docs/setup/getting-started/) 的 Kubernetes 集群，然后部署 [Istio Bookinfo 示例应用程序](/zh/docs/examples/bookinfo/)、[应用默认的 destination rule](/zh/docs/examples/bookinfo/#apply-default-destination-rules) 并[将 Istio 默认策略修改为禁止 Egress](/zh/docs/tasks/traffic-management/egress/egress-control/#change-to-the-blocking-by-default-policy)。
|
||||
|
||||
此应用程序使用 `ratings` 微服务来获取书籍评级，评分在1到5之间。评级显示为每个评论的星号，有几个版本的 `ratings` 微服务。有些人使用 [MongoDB](https://www.mongodb.com)，有些使用 [MySQL](https://www.mysql.com) 作为他们的数据库。
|
||||
此应用程序使用 `ratings` 微服务来获取书籍评级，评分在 1 到 5 之间。评级显示为每个评论的星号，有几个版本的 `ratings` 微服务。有些人使用 [MongoDB](https://www.mongodb.com)，有些使用 [MySQL](https://www.mysql.com) 作为他们的数据库。
|
||||
|
||||
这篇博客例子里的命令是以 Istio 0.8 以上版本为基础的，无论启用或不启用[双向 TLS](/zh/docs/concepts/security/#mutual-TLS-authentication)。
|
||||
|
||||
|
|
@ -145,7 +145,7 @@ target_release: 1.0
|
|||
|
||||
### 将数据库用于 Bookinfo 应用程序中的评级数据{#use-the-database-for-ratings-data-in-Bookinfo-application}
|
||||
|
||||
1. 修改使用 MySQL 数据库的 _ratings_ 服务版本的 `deployment spec`，以使用你的数据库实例。该 `spec` 位于 Istio 发行档案的[`samples/bookinfo/platform/kube/bookinfo-ratings-v2-mysql.yaml`]({{<github_blob>}}/samples/bookinfo/platform/kube/bookinfo-ratings-v2-mysql.yaml)中。编辑以下几行：
|
||||
1. 修改使用 MySQL 数据库的 _ratings_ 服务版本的 `deployment spec`，以使用你的数据库实例。该 `spec` 位于 Istio 发行档案的 [`samples/bookinfo/platform/kube/bookinfo-ratings-v2-mysql.yaml`]({{<github_blob>}}/samples/bookinfo/platform/kube/bookinfo-ratings-v2-mysql.yaml) 中。编辑以下几行：
|
||||
|
||||
{{< text yaml >}}
|
||||
- name: MYSQL_DB_HOST
|
||||
|
|
@ -260,9 +260,9 @@ target_release: 1.0
|
|||
|
||||
## TCP 流量的服务入口{#service-entries-for-tcp-traffic}
|
||||
|
||||
启用到特定端口的 TCP 流量的服务入口必须指定 `TCP` 作为端口的协议，此外，对于 [MongoDB Wire协议](https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/)，协议可以指定为 `MONGO`，而不是 `TCP`。
|
||||
启用到特定端口的 TCP 流量的服务入口必须指定 `TCP` 作为端口的协议，此外，对于 [MongoDB Wire 协议](https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/)，协议可以指定为 `MONGO`，而不是 `TCP`。
|
||||
|
||||
对于服务入口配置的 `addresses` 字段，必须使用 [CIDR](https://tools.ietf.org/html/rfc2317)表示法中的 IP 块。注意在 TCP 服务入口配置中，`host` 字段会被忽略。
|
||||
对于服务入口配置的 `addresses` 字段，必须使用 [CIDR](https://tools.ietf.org/html/rfc2317) 表示法中的 IP 块。注意在 TCP 服务入口配置中，`host` 字段会被忽略。
|
||||
|
||||
要通过其主机名启用到外部服务的 TCP 流量，必须指定主机名的所有 IP，每个 IP 必须由 CIDR 块指定。
|
||||
|
||||
|
|
|
|||
|
|
@ -13,11 +13,11 @@ target_release: 0.8
|
|||
|
||||
## 开始之前{#before-you-begin}
|
||||
|
||||
在集群中[`安装 Istio`](/zh/docs/setup/) 并部署应用程序。
|
||||
在集群中 [`安装 Istio`](/zh/docs/setup/) 并部署应用程序。
|
||||
|
||||
## 配置 Istio 导出日志{#configuring-Istio-to-export-logs}
|
||||
|
||||
Istio 使用 `logentry` [`模板`](/zh/docs/reference/config/policy-and-telemetry/templates/logentry)导出日志。这里指定了可用于分析的所有变量。它包含源服务、目标服务、`auth` 指标（即将实现......）等信息。以下是示意图：
|
||||
Istio 使用 `logentry` [`模板`](/zh/docs/reference/config/policy-and-telemetry/templates/logentry) 导出日志。这里指定了可用于分析的所有变量。它包含源服务、目标服务、`auth` 指标（即将实现......）等信息。以下是示意图：
|
||||
|
||||
{{< image width="75%" link="./istio-analytics-using-stackdriver.png" caption="导出日志到 Stackdriver 进行分析的图释" >}}
|
||||
|
||||
|
|
@ -29,33 +29,33 @@ Istio 支持将日志导出到 Stackdriver，而 Stackdriver 又可以配置为
|
|||
|
||||
1. 为项目启用 [`Stackdriver Monitoring API`](https://cloud.google.com/monitoring/api/enable-api) 。
|
||||
1. 确保配置的接收器的 `principalEmail` 具有对项目写入的权限和日志管理员角色的权限。
|
||||
1. 确保已设置 `GOOGLE_APPLICATION_CREDENTIALS` 环境变量。请按照[`此处`](https://cloud.google.com/docs/authentication/getting-started)的说明进行设置。
|
||||
1. 确保已设置 `GOOGLE_APPLICATION_CREDENTIALS` 环境变量。请按照 [`此处`](https://cloud.google.com/docs/authentication/getting-started) 的说明进行设置。
|
||||
|
||||
#### BigQuery{#big-query}
|
||||
|
||||
1. [`创建 BigQuery 数据集`](https://cloud.google.com/bigquery/docs/datasets)作为日志导出的目标。
|
||||
1. [`创建 BigQuery 数据集`](https://cloud.google.com/bigquery/docs/datasets) 作为日志导出的目标。
|
||||
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. 给 [`接收器授权`](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)。
|
||||
|
||||
#### Google Cloud Storage (GCS){#google-cloud-storage}
|
||||
|
||||
1. [`创建 GCS 存储桶`](https://cloud.google.com/storage/docs/creating-buckets)，希望导出日志到 GCS 中。
|
||||
1. 记录存储桶的 ID。这里需要配置 Stackdriver。它的形式为 `storage.googleapis.com/[BUCKET_ID]`。
|
||||
1. 给[`接收器授权`](https://cloud.google.com/logging/docs/api/tasks/exporting-logs#writing_to_the_destination)：`cloud-logs @ system.gserviceaccount.com`。它具有 IAM 中的 Storage Object Creator 的角色。
|
||||
1. 给 [`接收器授权`](https://cloud.google.com/logging/docs/api/tasks/exporting-logs#writing_to_the_destination)：`cloud-logs @ system.gserviceaccount.com`。它具有 IAM 中的 Storage Object Creator 的角色。
|
||||
|
||||
#### Google Cloud Pub/Sub{#google-cloud-pub-sub}
|
||||
|
||||
1. [`创建主题`](https://cloud.google.com/pubsub/docs/admin)，希望导出日志到Google Cloud Pub/Sub 中。
|
||||
1. [`创建主题`](https://cloud.google.com/pubsub/docs/admin)，希望导出日志到 Google Cloud Pub/Sub 中。
|
||||
1. 记录主题的 ID。这里需要配置 Stackdriver。它的形式为`pubsub.googleapis.com/projects/[PROJECT_ID]/topics/[TOPIC_ID]`。
|
||||
1. 给[`接收器授权`](https://cloud.google.com/logging/docs/api/tasks/exporting-logs#writing_to_the_destination)：`cloud-logs @ system.gserviceaccount.com`。它具有 IAM 中的 Pub/Sub Publisher 角色。
|
||||
1. 给 [`接收器授权`](https://cloud.google.com/logging/docs/api/tasks/exporting-logs#writing_to_the_destination)：`cloud-logs @ system.gserviceaccount.com`。它具有 IAM 中的 Pub/Sub Publisher 角色。
|
||||
1. 如果使用 [`Google Kubernetes Engine`](/zh/docs/setup/platform-setup/gke/)，请确保在集群中启动了 `pubsub` [`Scope`](https://cloud.google.com/sdk/gcloud/reference/container/clusters/create)。
|
||||
|
||||
### 设置 Stackdriver{#setting-up-stack-driver}
|
||||
|
||||
必须创建 Stackdriver 处理程序，将数据导出到 Stackdriver。Stackdriver 处理程序的配置在[`此处`](/zh/docs/reference/config/policy-and-telemetry/adapters/stackdriver/)描述。
|
||||
必须创建 Stackdriver 处理程序，将数据导出到 Stackdriver。Stackdriver 处理程序的配置在 [`此处`](/zh/docs/reference/config/policy-and-telemetry/adapters/stackdriver/) 描述。
|
||||
|
||||
1. 保存如下的yaml文件为 `stackdriver.yaml` 。并替换 `<project_id>,
|
||||
1. 保存如下的 yaml 文件为 `stackdriver.yaml` 。并替换 `<project_id>,
|
||||
<sink_id>, <sink_destination>, <log_filter>` 为相应的值。
|
||||
|
||||
{{< text yaml >}}
|
||||
|
|
@ -189,7 +189,7 @@ Istio 支持将日志导出到 Stackdriver，而 Stackdriver 又可以配置为
|
|||
filter: '<log_filter>'
|
||||
{{< /text >}}
|
||||
|
||||
在上面的配置中，sinkInfo 包含有关日志导出到所需接收器的信息。有关如何填写不同接收器的更多信息，请参阅[`此处`](https://cloud.google.com/logging/docs/export/#sink-terms)。
|
||||
在上面的配置中，sinkInfo 包含有关日志导出到所需接收器的信息。有关如何填写不同接收器的更多信息，请参阅 [`此处`](https://cloud.google.com/logging/docs/export/#sink-terms)。
|
||||
|
||||
1. 为 Stackdriver 添加规则
|
||||
|
||||
|
|
@ -218,4 +218,4 @@ Istio 支持将日志导出到 Stackdriver，而 Stackdriver 又可以配置为
|
|||
|
||||
## 日志导出的可用性{#availability-of-logs-in-export-sinks}
|
||||
|
||||
导出到 BigQuery 只需几分钟（可以认为是瞬间完成的），不过GCS要延迟2 至 12 小时，而Pub/Sub 则几乎没有延迟。
|
||||
导出到 BigQuery 只需几分钟（可以认为是瞬间完成的），不过 GCS 要延迟 2 至 12 小时，而 Pub/Sub 则几乎没有延迟。
|
||||
|
|
|
|||
|
|
@ -29,8 +29,8 @@ Micro-Segmentation 是一种安全技术，可在云部署中创建安全区域
|
|||
|
||||
### 具有条件的基于角色的访问控制{#role-based-access-control-with-conditions}
|
||||
|
||||
授权是[基于角色的访问控制（RBAC）](https://en.wikipedia.org/wiki/Role-based_access_control)系统，
|
||||
将此与[基于属性的访问控制（ABAC）](https://en.wikipedia.org/wiki/Attribute-based_access_control)系统对比。
|
||||
授权是[基于角色的访问控制（RBAC）](https://en.wikipedia.org/wiki/Role-based_access_control) 系统，
|
||||
将此与[基于属性的访问控制（ABAC）](https://en.wikipedia.org/wiki/Attribute-based_access_control) 系统对比。
|
||||
与 ABAC 相比，RBAC 具有以下优势：
|
||||
|
||||
* **角色允许对属性进行分组。** 角色是权限组，用于指定允许的操作在系统上执行。用户根据组织内的角色进行分组。
|
||||
|
|
@ -56,13 +56,13 @@ Micro-Segmentation 是一种安全技术，可在云部署中创建安全区域
|
|||
除主要标识外，您还可以自己定义标识。例如，您可以将客户端标识指定为“用户 `Alice` 从 `Bookstore` 前端服务调用”，在这种情况下，
|
||||
你有一个调用服务（`Bookstore frontend`）和最终用户（`Alice`）的组合身份。
|
||||
|
||||
要提高安全性，您应该启用[认证功能](/zh/docs/concepts/security/#authentication),并在授权策略中使用经过验证的身份。但是，
|
||||
要提高安全性，您应该启用[认证功能](/zh/docs/concepts/security/#authentication), 并在授权策略中使用经过验证的身份。但是，
|
||||
使用授权不强迫一定要有身份验证。Istio 授权可以使用或不使用身份。如果您正在使用遗留系统，您可能没有网格的双向 TLS 或 JWT 身份验证
|
||||
设置。在这种情况下，识别客户端的唯一方法是，例如，通过 IP。您仍然可以使用 Istio 授权来控制允许哪些 IP 地址或 IP 范围访问您的服务。
|
||||
|
||||
## 示例{#examples}
|
||||
|
||||
[授权任务](/zh/docs/tasks/security/authorization/authz-http)通过 [Bookinfo 应用](/zh/docs/examples/bookinfo) 向您展示如何使用 Istio 的授权功能来控制命名空间级别
|
||||
[授权任务](/zh/docs/tasks/security/authorization/authz-http)通过 [Bookinfo 应用](/zh/docs/examples/bookinfo)向您展示如何使用 Istio 的授权功能来控制命名空间级别
|
||||
和服务级别的访问。在本节中，您将看到更多使用 Istio 授权进行权限细分的示例。
|
||||
|
||||
### 通过 RBAC + 条件进行命名空间级别细分{#namespace-level-segmentation-via-rbac-conditions}
|
||||
|
|
@ -124,7 +124,7 @@ spec:
|
|||
#### 使用经过身份验证的客户端身份{#using-authenticated-client-identities}
|
||||
|
||||
假设你想把这个 `book-reader` 角色授予你的 `bookstore-frontend` 服务。如果您已启用
|
||||
您的网格的[双向 TLS 身份验证](/zh/docs/concepts/security/#mutual-TLS-authentication),您可以使用服务帐户，以识别您的 `bookstore-frontend` 服务。授予 `book-reader` 角色到 `bookstore-frontend` 服务可以通过创建一个 `ServiceRoleBinding` 来完成，如下所示：
|
||||
您的网格的[双向 TLS 身份验证](/zh/docs/concepts/security/#mutual-TLS-authentication), 您可以使用服务帐户，以识别您的 `bookstore-frontend` 服务。授予 `book-reader` 角色到 `bookstore-frontend` 服务可以通过创建一个 `ServiceRoleBinding` 来完成，如下所示：
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "rbac.istio.io/v1alpha1"
|
||||
|
|
@ -179,4 +179,4 @@ spec:
|
|||
|
||||
## 概要{#summary}
|
||||
|
||||
Istio 在命名空间级别，服务级别和方法级别粒度上提供授权功能。它采用“ RBAC + 条件”模型，使其成为易于使用和理解的 RBAC 系统，同时提供 ABAC 系统级别的灵活性。由于 Istio 授权在 Envoy 上本地运行，它有很高的性能。Istio 授权既可以与 [Istio 认证功能](/zh/docs/concepts/security/#authentication) 一起提供最佳的安全性，也可以用于为没有身份验证的旧系统提供访问控制。
|
||||
Istio 在命名空间级别，服务级别和方法级别粒度上提供授权功能。它采用“ RBAC + 条件”模型，使其成为易于使用和理解的 RBAC 系统，同时提供 ABAC 系统级别的灵活性。由于 Istio 授权在 Envoy 上本地运行，它有很高的性能。Istio 授权既可以与 [Istio 认证功能](/zh/docs/concepts/security/#authentication)一起提供最佳的安全性，也可以用于为没有身份验证的旧系统提供访问控制。
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ attribution: Spencer Krum, IBM
|
|||
target_release: 1.0
|
||||
---
|
||||
|
||||
为了庆祝 Istio 1.0 版本的发布并向更广泛的受众推广该软件，8月17日 Istio 社区在 Twitch 举办了一天的实况直播。
|
||||
为了庆祝 Istio 1.0 版本的发布并向更广泛的受众推广该软件，8 月 17 日 Istio 社区在 Twitch 举办了一天的实况直播。
|
||||
|
||||
## Twitch 是什么？{#what-is-twitch}
|
||||
|
||||
|
|
@ -15,11 +15,11 @@ target_release: 1.0
|
|||
|
||||
## 它用 Istio 做了什么？{#what-does-this-have-to-do-with-Istio}
|
||||
|
||||
Istio 在平台上发布的全天的内容，希望可以给观众讲解如何将深度技术内容、初级内容和业务线内容做良好融合。我们有开发人员、用户和布道者来分享示例和故事。期待现场编码，QA 和一些惊喜。我们有来自 IBM、Google、Datadog、Pivotal和更多的明星嘉宾。
|
||||
Istio 在平台上发布的全天的内容，希望可以给观众讲解如何将深度技术内容、初级内容和业务线内容做良好融合。我们有开发人员、用户和布道者来分享示例和故事。期待现场编码，QA 和一些惊喜。我们有来自 IBM、Google、Datadog、Pivotal 和更多的明星嘉宾。
|
||||
|
||||
## 如何观看{#recordings}
|
||||
|
||||
很简单！只要在8月17日上午10点导航到[这里](https://twitch.tv/ibmcode)。
|
||||
很简单！只要在 8 月 17 日上午 10 点导航到[这里](https://twitch.tv/ibmcode)。
|
||||
|
||||
## 安排{#schedule}
|
||||
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ istio-system1 istio-pilot-5bb6b7669c-779vb 2/2 Running 0
|
|||
|
||||
### 区分通用资源和命名空间资源{#split-common-and-namespace-specific-resources}
|
||||
|
||||
Istio 仓库中的清单文件中会创建两种资源，一种是能够被所有 Istio 控制面访问的通用资源，另一种是每个控制平面一份的专属资源。上面所说的在 yaml 文件中替换 `istio-system` 命名空间的方法自然是很简单的，更好的一种方法就是把 yaml 文件拆分为两块，一块是所有租户共享的通用部分；另一块就是租户自有的部分。根据 [CRD 资源定义（Custom Resource Definitions）](https://kubernetes.io/docs/concepts/api-extension/custom-resources/#customresourcedefinitions)中的说法，角色和角色绑定资源需要从 Istio 文件中进行剥离。另外，清单文件中提供的角色和角色绑定的定义可能不适合多租户环境，还需要进一步的细化和定制。
|
||||
Istio 仓库中的清单文件中会创建两种资源，一种是能够被所有 Istio 控制面访问的通用资源，另一种是每个控制平面一份的专属资源。上面所说的在 yaml 文件中替换 `istio-system` 命名空间的方法自然是很简单的，更好的一种方法就是把 yaml 文件拆分为两块，一块是所有租户共享的通用部分；另一块就是租户自有的部分。根据 [CRD 资源定义（Custom Resource Definitions）](https://kubernetes.io/docs/concepts/api-extension/custom-resources/#customresourcedefinitions) 中的说法，角色和角色绑定资源需要从 Istio 文件中进行剥离。另外，清单文件中提供的角色和角色绑定的定义可能不适合多租户环境，还需要进一步的细化和定制。
|
||||
|
||||
### Istio 控制面的 Kubernetes RBAC 设置{#Kubernetes-rbac-for-Istio-control-plane-resources}
|
||||
|
||||
|
|
@ -259,7 +259,7 @@ Error from server (Forbidden): pods is forbidden: User "dev-admin" cannot list p
|
|||
|
||||
* 视频：[用 RBAC 和命名空间支持的多租户功能及安全模型](https://www.youtube.com/watch?v=ahwCkJGItkU), [幻灯片](https://schd.ws/hosted_files/kccncna17/21/Multi-tenancy%20Support%20%26%20Security%20Modeling%20with%20RBAC%20and%20Namespaces.pdf).
|
||||
* `Kubecon` 讨论，关于对“协同软性多租户”的支持 [Building for Trust: How to Secure Your Kubernetes](https://www.youtube.com/watch?v=YRR-kZub0cA).
|
||||
* Kubernetes [RBAC 文档](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) 以及 [命名空间文档](https://kubernetes.io/docs/tasks/administer-cluster/namespaces-walkthrough/).
|
||||
* Kubernetes [RBAC 文档](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)以及[命名空间文档](https://kubernetes.io/docs/tasks/administer-cluster/namespaces-walkthrough/).
|
||||
* `Kubecon` 幻灯片 [Multi-tenancy Deep Dive](https://schd.ws/hosted_files/kccncna17/a9/kubecon-multitenancy.pdf).
|
||||
* Google 文档 [Multi-tenancy models for Kubernetes](https://docs.google.com/document/d/15w1_fesSUZHv-vwjiYa9vN_uyc--PySRoLKTuDhimjc). (需要授权)
|
||||
* Cloud Foundry 提出的文档：[Multi-cloud and Multi-tenancy](https://docs.google.com/document/d/14Hb07gSrfVt5KX9qNi7FzzGwB_6WBpAnDpPG6QEEd9Q)
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ target_release: 0.5
|
|||
|
||||
在非生产/测试环境中，尝试穷举一个服务所有可能的测试用例组合是个令人望而生畏的任务, 在某些情况下，您会发现编写这些用例的所有工作都与实际生产用例不匹配, 理想情况下，我们可以使用实时生产用例和流量来帮助说明我们可能在更人为的测试环境中错过的所测试服务的所有功能区域。
|
||||
|
||||
Istio 可以在这里提供帮助, 随着[Istio 0.5.0](/zh/news/releases/0.x/announcing-0.5)的发布，Istio 可以镜像流量来帮助测试您的服务, 您可以编写类似于以下内容的路由规则来启用流量镜像：
|
||||
Istio 可以在这里提供帮助, 随着 [Istio 0.5.0](/zh/news/releases/0.x/announcing-0.5) 的发布，Istio 可以镜像流量来帮助测试您的服务, 您可以编写类似于以下内容的路由规则来启用流量镜像：
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: config.istio.io/v1alpha2
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Istio v1aplha3 路由 API 介绍
|
||||
description: Istio v1alpha3 路由 API 介绍,动机及其设计原则。
|
||||
description: Istio v1alpha3 路由 API 介绍, 动机及其设计原则。
|
||||
publishdate: 2018-04-25
|
||||
subtitle:
|
||||
attribution: Frank Budinsky (IBM) and Shriram Rajagopalan (VMware)
|
||||
|
|
@ -8,13 +8,13 @@ keywords: [traffic-management]
|
|||
target_release: 0.7
|
||||
---
|
||||
|
||||
到目前为止，Istio 提供了一个简单的API来进行流量管理，该API包括了四种资源：`RouteRule`，`DestinationPolicy`，`EgressRule` 和 （Kubernetes 的）`Ingress`。借助此 API，用户可以轻松管理 Istio 服务网格中的流量。该 API 允许用户将请求路由到特定版本的服务，为弹性测试注入延迟和失败，添加超时和断路器等，所有这些功能都不必更改应用程序本身的代码。
|
||||
到目前为止，Istio 提供了一个简单的 API 来进行流量管理，该 API 包括了四种资源：`RouteRule`，`DestinationPolicy`，`EgressRule` 和 （Kubernetes 的）`Ingress`。借助此 API，用户可以轻松管理 Istio 服务网格中的流量。该 API 允许用户将请求路由到特定版本的服务，为弹性测试注入延迟和失败，添加超时和断路器等，所有这些功能都不必更改应用程序本身的代码。
|
||||
|
||||
虽然目前 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}
|
||||
|
||||
|
|
@ -31,7 +31,7 @@ target_release: 0.7
|
|||
{{< image width="80%"
|
||||
link="gateways.svg"
|
||||
alt="Role of gateways in the mesh"
|
||||
caption="Istio服务网格中的网关"
|
||||
caption="Istio 服务网格中的网关"
|
||||
>}}
|
||||
|
||||
考虑到上述因素，`v1alpha3`引入了以下这些新的配置资源来控制进入网格，网格内部和离开网格的流量路由。
|
||||
|
|
@ -47,7 +47,7 @@ target_release: 0.7
|
|||
|
||||
{{< image width="80%"
|
||||
link="virtualservices-destrules.svg"
|
||||
caption="不同v1alpha3元素之间的关系"
|
||||
caption="不同 v1alpha3 元素之间的关系"
|
||||
>}}
|
||||
|
||||
### `Gateway`
|
||||
|
|
@ -56,7 +56,7 @@ target_release: 0.7
|
|||
|
||||
对于入口流量管理，您可能会问： _为什么不直接使用 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 外部流量进入网格中：
|
||||
|
||||
|
|
@ -198,7 +198,7 @@ spec:
|
|||
...
|
||||
{{< /text >}}
|
||||
|
||||
实际上在 `VirtualService` 中 hosts 部分设置只是虚拟的目的地,因此不一定是已在网格中注册的服务。这允许用户为在网格内没有可路由条目的虚拟主机的流量进行建模。 通过将 `VirtualService` 绑定到同一 Host 的 `Gateway` 配置（如前一节所述 ），可向网格外部暴露这些 Host。
|
||||
实际上在 `VirtualService` 中 hosts 部分设置只是虚拟的目的地, 因此不一定是已在网格中注册的服务。这允许用户为在网格内没有可路由条目的虚拟主机的流量进行建模。 通过将 `VirtualService` 绑定到同一 Host 的 `Gateway` 配置（如前一节所述 ），可向网格外部暴露这些 Host。
|
||||
|
||||
除了这个重大的重构之外， `VirtualService` 还包括其他一些重要的改变：
|
||||
|
||||
|
|
@ -206,7 +206,7 @@ spec:
|
|||
|
||||
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`
|
||||
|
||||
|
|
@ -267,7 +267,7 @@ spec:
|
|||
|
||||
也就是说，`ServiceEntry` 比它的前身具有更多的功能。首先，`ServiceEntry` 不限于外部服务配置，它可以有两种类型：网格内部或网格外部。网格内部条目只是用于向网格显式添加服务，添加的服务与其他内部服务一样。采用网格内部条目，可以把原本未被网格管理的基础设施也纳入到网格中（例如，把虚机中的服务添加到基于 Kubernetes 的服务网格中）。网格外部条目则代表了网格外部的服务。对于这些外部服务来说，双向 TLS 身份验证是禁用的，并且策略是在客户端执行的，而不是在像内部服务请求一样在服务器端执行策略。
|
||||
|
||||
由于 `ServiceEntry` 配置只是将服务添加到网格内部的服务注册表中，因此它可以像注册表中的任何其他服务一样,与 `VirtualService` 和/或 `DestinationRule` 一起使用。例如，以下 `DestinationRule` 可用于启动外部服务的 双向 TLS 连接：
|
||||
由于 `ServiceEntry` 配置只是将服务添加到网格内部的服务注册表中，因此它可以像注册表中的任何其他服务一样, 与 `VirtualService` 和/或 `DestinationRule` 一起使用。例如，以下 `DestinationRule` 可用于启动外部服务的 双向 TLS 连接：
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
|
|
@ -312,7 +312,7 @@ $ kubectl apply -f my-updated-rules-for-destination-abc.yaml
|
|||
|
||||
## 总结{#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}
|
||||
|
||||
|
|
|
|||
|
|
@ -67,14 +67,14 @@ func main() {
|
|||
}
|
||||
{{< /text >}}
|
||||
|
||||
您可以在 [这里](https://github.com/istio/client-go/blob/{{< source_branch_name >}}/cmd/example/client.go) 找到更详尽的示例。
|
||||
您可以在[这里](https://github.com/istio/client-go/blob/{{<source_branch_name >}}/cmd/example/client.go) 找到更详尽的示例。
|
||||
|
||||
## 为生成 Istio client go 而创建的工具{#useful-tools-created-for-generating-Istio-client-go}
|
||||
|
||||
如果您想知道为什么花费大量时间也很难生成此客户端，本小节将对此进行说明。在 `Istio` 中，我们使用[protobuf](https://developers.google.com/protocol-buffers) 规范编写 `API`，然后使用 `protobuf` 工具链将其转换为 `Go` 定义。如果尝试从 `protobuf` 的 `API` 生成 `Kubernetes` 客户端，可能会面临三个主要的挑战：
|
||||
如果您想知道为什么花费大量时间也很难生成此客户端，本小节将对此进行说明。在 `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
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ Istio 使用 [Envoy sidecar 代理] 来调整服务网格中所有 Pod 的入站
|
|||
|
||||
APP 身份和访问适配器通过分析针对服务网格上各种访问控制策略的遥测数据（属性）扩展 Mixer 的功能。访问控制策略可以关联到具体的 Kubernetes 服务，并且可以微调到特定的服务端点。关于策略和遥测信息的详情请看 Istio 的文档。
|
||||
|
||||
当 [App 身份和访问适配器](https://github.com/ibm-cloud-security/app-identity-and-access-adapter) 结合到 Istio 中后，为多云架构提供可扩展的、集成身份和访问解决方案，而且不需要修改任何应用程序代码。
|
||||
当 [App 身份和访问适配器](https://github.com/ibm-cloud-security/app-identity-and-access-adapter)结合到 Istio 中后，为多云架构提供可扩展的、集成身份和访问解决方案，而且不需要修改任何应用程序代码。
|
||||
|
||||
## 安装 {#installation}
|
||||
|
||||
|
|
|
|||
|
|
@ -49,12 +49,12 @@ Istio 本身受依赖性排序问题版本的影响。由于在 Istio 下运行
|
|||
AppSwitch 的核心能够使用 BSD Socket API 及其相关的其它调用（例如 `fcntl` 和 ioctl）来完成对 Socket 的处理。它的实现细节很有意思，但是为了防止偏离本文的主题，这里仅对其独特的关键属性进行一个总结。
|
||||
（1）速度很快。它使用 `seccomp` 过滤和二进制检测的组合来积极地限制应用程序正常执行的干预。AppSwitch 特别适用于服务网格和应用程序网络用例，因为它实现了这些功能，而无需实际触摸数据。相反，网络级方法会导致每个数据包的成本。看看这个[博客](/zh/blog/2018/delayering-istio/)进行一些性能测量。
|
||||
（2）它不需要任何内核支持，内核模块或补丁，可以在标准的发行版内核上运行
|
||||
（3）它可以作为普通用户运行（非 root）。事实上，该机制甚至可以通过删除对网络容器的根要求来运行 [非 root 的 Docker 守护进程](https://linuxpiter.com/en/materials/2478)
|
||||
（3）它可以作为普通用户运行（非 root）。事实上，该机制甚至可以通过删除对网络容器的根要求来运行[非 root 的 Docker 守护进程](https://linuxpiter.com/en/materials/2478)
|
||||
（4）它可以不加更改的用于任何类型的应用程序上，适用于任何类型的应用程序 - 从 WebSphere ND 和 SAP 到自定义 C 应用程序，再到静态链接的 `Golang` 应用程序。Linux/x86 是仅有的运行需求。
|
||||
|
||||
### 将服务与其引用分离{#decoupling-services-from-their-references}
|
||||
|
||||
AppSwitch 建立在应用程序应与其引用分离的基本前提之上。传统上，应用程序的标识源自它们运行的主机的标识。但是，应用程序和主机是需要独立引用的非常不同的对象。本 [主题](https://arxiv.org/abs/1711.02294)介绍了围绕此主题的详细讨论以及 AppSwitch 的概念基础。
|
||||
AppSwitch 建立在应用程序应与其引用分离的基本前提之上。传统上，应用程序的标识源自它们运行的 主机的标识。但是，应用程序和主机是需要独立引用的非常不同的对象。本[主题](https://arxiv.org/abs/1711.02294)介绍了围绕此主题的详细讨论以及 AppSwitch 的概念基础。
|
||||
|
||||
实现服务对象及其身份之间解耦的中央 AppSwitch 构造是 _service reference_（简称 _reference_ ）。AppSwitch 基于上面概述的 API 检测机制实现服务引用。服务引用由 IP：端口对（以及可选的 DNS 名称）和标签选择器组成，标签选择器选择引用所代表的服务以及此引用所适用的客户端。引用支持一些关键属性。（1）它的名称可以独立于它所引用的对象的名称。也就是说，服务可能正在侦听 IP 和端口，但是引用允许在用户选择的任何其他 IP 和端口上达到该服务。这使 AppSwitch 能够运行从源环境中捕获的传统应用程序，通过静态 IP 配置在 Kubernetes 上运行，为其提供必要的 IP 地址和端口，而不管目标网络环境如何。（2）即使目标服务的位置发生变化，它也保持不变。引用自动重定向自身，因为其标签选择器现在解析为新的服务实例（3）对于此讨论最重要的是，在目标服务的启动过程中，引用就已经生效了。
|
||||
|
||||
|
|
@ -72,9 +72,9 @@ AppSwitch 利用 BSD Socket API 的语义，确保服务引用从客户的角度
|
|||
|
||||
### 为 Sidecar 提供服务引用的通配符支持{#wildcard-service-references-for-sidecar-dependency}
|
||||
|
||||
服务引用可用于解决前面提到的 Istio sidecar 依赖性问题。AppSwitch 用 IP：端口的方式来描述对服务的引用，这种描述中是可以使用通配符的。也就是说，服务引用描述中可以用IP 掩码的形式来表达要捕捉的 IP 地址的范围。如果服务引用的标签选择器指向 sidecar 服务，则应用此服务引用的任何应用程序的所有传出连接将被透明地重定向到 sidecar。当然，在 Sidecar 启动过程中，服务引用仍然是有效的。
|
||||
服务引用可用于解决前面提到的 Istio sidecar 依赖性问题。AppSwitch 用 IP：端口的方式来描述对服务的引用，这种描述中是可以使用通配符的。也就是说，服务引用描述中可以用 IP 掩码的形式来表达要捕捉的 IP 地址的范围。如果服务引用的标签选择器指向 sidecar 服务，则应用此服务引用的任何应用程序的所有传出连接将被透明地重定向到 sidecar。当然，在 Sidecar 启动过程中，服务引用仍然是有效的。
|
||||
|
||||
使用 sidecar 依赖性排序的服务引用也隐式地将应用程序的连接重定向到 sidecar ，而不需要 iptables 和随之而来的权限问题。基本上它就像应用程序直接连接到 sidecar 而不是目标目的地一样工作，让 sidecar 负责做什么。AppSwitch 将使用 sidecar 可以在将连接传递到应用程序之前解码的代理协议将关于原始目的地等的元数据插入到连接的数据流中。其中一些细节已在 [此处](/zh/blog/2018/delayering-istio/) 进行了讨论。出站连接是这样处理的，那么入站连接呢？由于所有服务及其 sidecar 都在 AppSwitch 下运行，因此来自远程节点的任何传入连接都将被重定向到各自的远程 sidecar 。所以传入连接没有什么特别处理。
|
||||
使用 sidecar 依赖性排序的服务引用也隐式地将应用程序的连接重定向到 sidecar ，而不需要 iptables 和随之而来的权限问题。基本上它就像应用程序直接连接到 sidecar 而不是目标目的地一样工作，让 sidecar 负责做什么。AppSwitch 将使用 sidecar 可以在将连接传递到应用程序之前解码的代理协议将关于原始目的地等的元数据插入到连接的数据流中。其中一些细节已在[此处](/zh/blog/2018/delayering-istio/)进行了讨论。出站连接是这样处理的，那么入站连接呢？由于所有服务及其 sidecar 都在 AppSwitch 下运行，因此来自远程节点的任何传入连接都将被重定向到各自的远程 sidecar 。所以传入连接没有什么特别处理。
|
||||
|
||||
## 总结{#summary}
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ target_release: 1.0
|
|||
|
||||
## 开始之前{#before-you-begin}
|
||||
|
||||
* 根据 [安装指南](/zh/docs/setup/) 完成 Istio 的部署。
|
||||
* 根据[安装指南](/zh/docs/setup/)完成 Istio 的部署。
|
||||
* 用 Helm [Chart](https://github.com/helm/charts/tree/master/stable/cert-manager#installing-the-chart) 部署 `cert-manager`。
|
||||
* 我们会使用 `demo.mydemo.com` 进行演示，因此你的 DNS 解析要能够解析这个域名。
|
||||
|
||||
|
|
@ -37,7 +37,7 @@ target_release: 1.0
|
|||
1. 要创建集群的证书签发者，可以使用如下的配置：
|
||||
|
||||
{{< tip >}}
|
||||
用自己的配置修改集群的 [证书签发者](https://cert-manager.readthedocs.io/en/latest/reference/issuers.html)。例子中使用的是 `route53`。
|
||||
用自己的配置修改集群的[证书签发者](https://cert-manager.readthedocs.io/en/latest/reference/issuers.html)。例子中使用的是 `route53`。
|
||||
{{< /tip >}}
|
||||
|
||||
{{< text yaml >}}
|
||||
|
|
@ -127,7 +127,7 @@ target_release: 1.0
|
|||
desiredReplicas: 1
|
||||
{{< /text >}}
|
||||
|
||||
1. 使用 [附件 YAML 中的定义](/zh/blog/2019/custom-ingress-gateway/deployment-custom-ingress.yaml)进行部署。
|
||||
1. 使用[附件 YAML 中的定义](/zh/blog/2019/custom-ingress-gateway/deployment-custom-ingress.yaml)进行部署。
|
||||
|
||||
{{< tip >}}
|
||||
其中类似 `aws-load-balancer-type` 这样的注解，只对 AWS 生效。
|
||||
|
|
@ -229,4 +229,4 @@ target_release: 1.0
|
|||
SSL certificate verify ok.
|
||||
{{< /text >}}
|
||||
|
||||
**恭喜你！** 现在你可以使用自定义的 `istio-custom-gateway` [网关](/zh/docs/reference/config/networking/gateway/) 对象了。
|
||||
**恭喜你！** 现在你可以使用自定义的 `istio-custom-gateway` [网关](/zh/docs/reference/config/networking/gateway/)对象了。
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ target_release: 1.0
|
|||
---
|
||||
Istio 服务网格体系结构的简单概述总是从控制平面和数据平面开始。
|
||||
|
||||
从 [Istio 的文档](/zh/docs/ops/deployment/architecture/):
|
||||
从 [Istio 的文档](/zh/docs/ops/deployment/architecture/) :
|
||||
|
||||
{{< quote >}}
|
||||
Istio 服务网格在逻辑上分为数据平面和控制平面。
|
||||
|
|
@ -33,7 +33,7 @@ Istio 服务网格在逻辑上分为数据平面和控制平面。
|
|||
简单来说，Sidecar 注入会将额外容器的配置添加到 Pod 模板中。Istio 服务网格目前所需的容器有：
|
||||
|
||||
`istio-init`
|
||||
[init 容器](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) 用于设置 iptables 规则，以便将入站/出站流量通过 sidecar 代理。初始化容器与应用程序容器在以下方面有所不同：
|
||||
[init 容器](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/)用于设置 iptables 规则，以便将入站/出站流量通过 sidecar 代理。初始化容器与应用程序容器在以下方面有所不同：
|
||||
|
||||
- 它在启动应用容器之前运行，并一直运行直至完成。
|
||||
- 如果有多个初始化容器，则每个容器都应在启动下一个容器之前成功完成。
|
||||
|
|
@ -41,7 +41,7 @@ Istio 服务网格在逻辑上分为数据平面和控制平面。
|
|||
因此，您可以看到，对于不需要成为实际应用容器一部分的设置或初始化作业来说，这种容器是多么的完美。在这种情况下，`istio-init` 就是这样做并设置了 `iptables` 规则。
|
||||
|
||||
`istio-proxy`
|
||||
这个容器是真正的 sidecar 代理（基于Envoy）。
|
||||
这个容器是真正的 sidecar 代理（基于 Envoy）。
|
||||
|
||||
### 手动注入{#manual-injection}
|
||||
|
||||
|
|
@ -306,7 +306,7 @@ spec:
|
|||
- 默认策略（在 ConfigMap `istio-sidecar-injector` 中配置）
|
||||
- 每个 pod 的重载注解（`sidecar.istio.io/inject`）
|
||||
|
||||
[注入状态表](/zh/docs/ops/common-problems/injection/) 根据上述变量的值清晰显示了最终注入状态。
|
||||
[注入状态表](/zh/docs/ops/common-problems/injection/)根据上述变量的值清晰显示了最终注入状态。
|
||||
|
||||
## 从应用容器到 Sidecar 代理的流量{#traffic-flow-from-application-container-to-sidecar-proxy}
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ keywords: [performance,traffic-management,egress,mongo]
|
|||
target_release: 1.0
|
||||
---
|
||||
|
||||
为了从网格中访问外部服务（本例中使用的是 MongoDB），需要加入 Egress gateway，本次测试的主要目的就是调查这一行为对性能和资源使用造成的影响。在博客 [使用外部 MongoDB 服务](/zh/blog/2018/egress-mongo/) 中介绍了为外部 MongoDB 配置 Egress gateway 的具体步骤。
|
||||
为了从网格中访问外部服务（本例中使用的是 MongoDB），需要加入 Egress gateway，本次测试的主要目的就是调查这一行为对性能和资源使用造成的影响。在博客[使用外部 MongoDB 服务](/zh/blog/2018/egress-mongo/)中介绍了为外部 MongoDB 配置 Egress gateway 的具体步骤。
|
||||
|
||||
本次测试中使用的应用是 Acmeair 的 Java 版，这个应用会模拟一个航空订票系统。在 Istio 的每日构建中会使用该应用来进行性能的回归测试，但是在回归测试过程中，这些应用会使用自己的 Sidecar 来访问外部的 MongoDB，而不是 Egress gateway。
|
||||
|
||||
|
|
@ -118,4 +118,4 @@ target_release: 1.0
|
|||
|
||||
## 结论{#conclusion}
|
||||
|
||||
在这一系列的测试之中，我们用不同的方式来访问一个启用了 TLS 的 MongoDB 来进行性能对比。Egress gateway 的引用没有对性能和 CPU 消耗的显著影响。但是启用了 Sidecar 和 Egress gateway 之间的双向 TLS 或者为通配符域名使用了额外的 SNI 代理之后，会看到性能降级的现象。
|
||||
在这一系列的测试之中，我们用不同的方式来访问一个启用了 TLS 的 MongoDB 来进行性能对比。Egress gateway 的引用没有对性能和 CPU 消耗的显著影响。但是启用了 Sidecar 和 Egress gateway 之间的双向 TLS 或者为通配符域名使用了额外的 SNI 代理之后，会看到性能降级的现象。
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ _1.3.4 不允许持卡人数据环境没有授权的出站流量进入互联网
|
|||
|
||||
出口流量安全管控的意思是监控出口流量并且针对出口流量应用所有的安全策略。
|
||||
监控出口流量，可以对它进行分析（可能是离线的），即便你无法实时阻止攻击，也要检测攻击事件。
|
||||
另外一个减少攻击可能性的方法是遵循[需要知道](https://en.wikipedia.org/wiki/Need_to_know#In_computer_technology]) 的原则进行指定限制访问策略。
|
||||
另外一个减少攻击可能性的方法是遵循[需要知道](https://en.wikipedia.org/wiki/Need_to_know#In_computer_technology])的原则进行指定限制访问策略。
|
||||
|
||||
现在来看看已经收集到的出口流量管控要求。
|
||||
|
||||
|
|
@ -82,7 +82,7 @@ Istio 1.1 满足所有的收集要求：
|
|||
|
||||
第三个要求指出：Istio 运维人员必须能为整个集群所有的出口流量定规策略。策略指出集群中的 pod 可能会访问哪些外部服务。外部服务可以通过服务的[全域名](https://en.wikipedia.org/wiki/Fully_qualified_domain_name) （比如 `www.ibm.com`）或者泛域名（比如：`*.ibm.com`）进行标示。只有指定的外部服务可以访问，其它所有的出口流量都要被阻止。
|
||||
|
||||
这个要求是为了阻止攻击者访问恶意站点而提出的，比如下载更新/操作他们的恶意软件。同样也想去限制攻击者可以访问和攻击的外部站点的数量。只允许集群内应用程序需要访问的外部站点并且阻止其它所拥有的服务访问，这样减少了[攻击面](https://en.wikipedia.org/wiki/Attack_surface)。当外部服务有了它们自己的安全机制，你想使用[纵深防御](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) 并且使用多个安全层：除了外部系统的安全层外，集群内还有一个安全层。
|
||||
这个要求是为了阻止攻击者访问恶意站点而提出的，比如下载更新/操作他们的恶意软件。同样也想去限制攻击者可以访问和攻击的外部站点的数量。只允许集群内应用程序需要访问的外部站点并且阻止其它所拥有的服务访问，这样减少了[攻击面](https://en.wikipedia.org/wiki/Attack_surface)。当外部服务有了它们自己的安全机制，你想使用[纵深防御](https://en.wikipedia.org/wiki/Defense_in_depth_(computing))并且使用多个安全层：除了外部系统的安全层外，集群内还有一个安全层。
|
||||
|
||||
这个要求意味着外部服务必须能用域名来标示。我们把出口管控系统的这个特性叫做 DNS 感知。如果系统不是 DNS 可感知的，外部服务必须用 IP 地址标示。
|
||||
使用 IP 地址不方便而且经常不灵活，因为服务的 IP 地址会变的。有时候服务的所有 IP 地址甚至都不知道，比如：[CDN](https://en.wikipedia.org/wiki/Content_delivery_network)。
|
||||
|
|
@ -98,4 +98,4 @@ Istio 1.1 满足所有的收集要求：
|
|||
|
||||
## 总结 {#summary}
|
||||
|
||||
希望您确信对于集群安全来说出口流量管控是非常重要的。在[这个系列文章的第二部分](/zh/blog/2019/egress-traffic-control-in-istio-part-2/) 我讲述了使用 Istio 实现出口流量安全管控的方法。在[这个系列文章的第三部分](/zh/blog/2019/egress-traffic-control-in-istio-part-3/) 我和其它方案进行了对比，比如 [Kubernetes 网络策略](https://kubernetes.io/docs/concepts/services-networking/network-policies/)以及已有的其它出口代理/防火墙方案。
|
||||
希望您确信对于集群安全来说出口流量管控是非常重要的。在[这个系列文章的第二部分](/zh/blog/2019/egress-traffic-control-in-istio-part-2/)我讲述了使用 Istio 实现出口流量安全管控的方法。在[这个系列文章的第三部分](/zh/blog/2019/egress-traffic-control-in-istio-part-3/)我和其它方案进行了对比，比如 [Kubernetes 网络策略](https://kubernetes.io/docs/concepts/services-networking/network-policies/)以及已有的其它出口代理/防火墙方案。
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ target_release: 1.2
|
|||
---
|
||||
|
||||
欢迎来看 Istio 对出口流量进行安全管控系列文章的第 2 部分。
|
||||
在[这个系列文章的第一部分](/zh/blog/2019/egress-traffic-control-in-istio-part-1/),我提出了出口流量相关攻击和针对出口流量进行安全管控我们收集的要求点。
|
||||
在[这个系列文章的第一部分](/zh/blog/2019/egress-traffic-control-in-istio-part-1/), 我提出了出口流量相关攻击和针对出口流量进行安全管控我们收集的要求点。
|
||||
在这一期中，我会讲述对出口流量进行安全管控的 Istio 方式，并且展示 Istio 如何帮你阻止攻击。
|
||||
|
||||
## Istio 中的出口流量安全管控 {#secure-control-of-egress-traffic-in-Istio}
|
||||
|
|
@ -23,7 +23,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)的例子。
|
||||
根据[纵深防御](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) 的概念，为同一个目标使用的安全机制越多越安全。
|
||||
根据[纵深防御](https://en.wikipedia.org/wiki/Defense_in_depth_(computing))的概念，为同一个目标使用的安全机制越多越安全。
|
||||
|
||||
你也必需也要确保 Istio 控制平面和出口网关不能被破坏。你的集群里面可能有成百上千的应用程序 pod，而只有十几个 Istio 控制平面 pod 和网关。
|
||||
你可以也应该聚焦在保护控制平面 pod 和网关，因为这比较容易（需要保护的 pod 数量很少），并且这对集群的安全性是最关键的。
|
||||
|
|
|
|||
|
|
@ -101,4 +101,4 @@ Istio 是我所知的唯一解决方案，它可以让你：
|
|||
以我之见，如果你在寻找你的第一个 Istio 应用场景，安全管控出口流量是一个非常好的选择。在这个场景中，Istio 甚至在你使用它所有其它功能之前就已经为你提供了一些优势：
|
||||
[流量管理](/zh/docs/tasks/traffic-management/)，[安全性](/zh/docs/tasks/security/)，[策略](/zh/docs/tasks/policy-enforcement/)和[可观测性](/zh/docs/tasks/observability/)，上面的功能都可以用在在集群内的微服务之间的流量上。
|
||||
|
||||
所以，如果你还没有机会使用 Istio，那就在你集群上[安装 Istio](/zh/docs/setup/install/) 并且检查[出口流量管控任务](/zh/docs/tasks/traffic-management/egress/) 再执行其它 [Istio 特性](/zh/docs/tasks/)的任务。我们也想收到你的反馈，请在[discuss.istio.io](https://discuss.istio.io)加入我们。
|
||||
所以，如果你还没有机会使用 Istio，那就在你集群上[安装 Istio](/zh/docs/setup/install/) 并且检查[出口流量管控任务](/zh/docs/tasks/traffic-management/egress/)再执行其它 [Istio 特性](/zh/docs/tasks/)的任务。我们也想收到你的反馈，请在 [discuss.istio.io](https://discuss.istio.io) 加入我们。
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Istio API 进化的下一步重心是在 Istio 用户的角色上。一个安全
|
|||
1. Istio API 应该寻求：
|
||||
- 正确地表示他们映射到的基础资源
|
||||
- 不应该隐藏任何基础资源的有用功能
|
||||
1. Istio API 也应该是 [可组合的](https://en.wikipedia.org/wiki/Composability)，因此终端用户能以适合其自身需求的方式组合基础 API。
|
||||
1. Istio API 也应该是[可组合的](https://en.wikipedia.org/wiki/Composability)，因此终端用户能以适合其自身需求的方式组合基础 API。
|
||||
1. Istio API 也应该是灵活的：在一个组织内部，应该有可能对基础资源有不同的表现形式，并且对每个团队都有意义。
|
||||
|
||||
在接下来的几个版本中，我们将分享我们的进展，我们将加强 Istio API 与 Istio 用户角色之间的一致性。
|
||||
|
|
@ -35,11 +35,11 @@ Kubernetes 可组合性的一个具体示例是部署应用时有一系列的对
|
|||
|
||||
可以在 [Google Cloud HTTP(S) Load Balancer](https://cloud.google.com/load-balancing/docs/https/) (GCLB) 找到网络空间可组合性的另一个例子。要正确使用 GCLB 的一个实例，需要创建和配置 6 个不同的基础对象。这样的设计是我们操作分布式系统 20 年经验的一个结果，并且[为什么每一个对象和其他对象相互独立是有原因的](https://www.youtube.com/watch?v=J5HJ1y6PeyE)。但你通过 Google Cloud 控制台创建一个实例的步骤是被简化过的。我们提供越多的通用的面向终端用户/以角色为中心的配置，以后你们配置的通用设置越少。最终，基础 API 的目标是在不牺牲功能的情况下提供最大的灵活性。
|
||||
|
||||
[Knative](http://knative.dev) 是一个创建、运行并且操作无服务器工作负载的平台，它提供了一个以角色为中心的现实世界绝佳的示例，更高层次的 API。[Knative Serving](https://knative.dev/docs/serving/)，Knative 的一个组件，基于 Kubernetes 和 Istio 服务于无服务器应用和功能，为应用开发人员管理服务的路由和修订提供了一个稳定的工作流。由于采用这种稳定的方式，Knative Serving 将 Istio 的 [`VirtualService`](/zh/docs/reference/config/networking/virtual-service/) 和 [`DestinationRule`](/zh/docs/reference/config/networking/destination-rule/) 资源，抽象成一个简化的支持修订和流量路由的 [路由](https://github.com/knative/docs/blob/master/docs/serving/spec/knative-api-specification-1.0.md#route) 对象，将与应用开发人员最紧密相关的 Istio 网络 API 的一个子集暴露出来。
|
||||
[Knative](http://knative.dev) 是一个创建、运行并且操作无服务器工作负载的平台，它提供了一个以角色为中心的现实世界绝佳的示例，更高层次的 API。[Knative Serving](https://knative.dev/docs/serving/)，Knative 的一个组件，基于 Kubernetes 和 Istio 服务于无服务器应用和功能，为应用开发人员管理服务的路由和修订提供了一个稳定的工作流。由于采用这种稳定的方式，Knative Serving 将 Istio 的 [`VirtualService`](/zh/docs/reference/config/networking/virtual-service/) 和 [`DestinationRule`](/zh/docs/reference/config/networking/destination-rule/) 资源，抽象成一个简化的支持修订和流量路由的[路由](https://github.com/knative/docs/blob/master/docs/serving/spec/knative-api-specification-1.0.md#route)对象，将与应用开发人员最紧密相关的 Istio 网络 API 的一个子集暴露出来。
|
||||
|
||||
随着 Istio 的成熟，我们还看到生产用户在 Istio 的基础 API 之上开发了针对特定工作负载和组织的抽象层。
|
||||
|
||||
AutoTrader UK 提供了一个基于 Istio 定制平台的我们最喜欢的例子。在 [来自 Google 的 Kubernetes Podcast 的一个采访](https://kubernetespodcast.com/episode/052-autotrader/) 中，Russel Warman 和 Karl Stoney 描述了他们基于 Kubernetes 的交付平台，和 [用 Prometheus 和 Grafana 搭建的成本 Dashboard](https://karlstoney.com/2018/07/07/managing-your-costs-on-kubernetes/)。他们毫不费力地添加了配置项使网络达到他们的开发人员希望配置成的样子，并且现在它管理着的 Istio 的对象让这一切成为可能。在企业和云原生公司中构建了无数其他的平台：一些旨在替换公司特定的自定义脚本的网络，而另一些旨在成为通用的公共工具。随着越来越多的公司开始公开谈论他们的工具，我们将把他们的故事带到此博客。
|
||||
AutoTrader UK 提供了一个基于 Istio 定制平台的我们最喜欢的例子。在[来自 Google 的 Kubernetes Podcast 的一个采访](https://kubernetespodcast.com/episode/052-autotrader/)中，Russel Warman 和 Karl Stoney 描述了他们基于 Kubernetes 的交付平台，和[用 Prometheus 和 Grafana 搭建的成本 Dashboard](https://karlstoney.com/2018/07/07/managing-your-costs-on-kubernetes/)。他们毫不费力地添加了配置项使网络达到他们的开发人员希望配置成的样子，并且现在它管理着的 Istio 的对象让这一切成为可能。在企业和云原生公司中构建了无数其他的平台：一些旨在替换公司特定的自定义脚本的网络，而另一些旨在成为通用的公共工具。随着越来越多的公司开始公开谈论他们的工具，我们将把他们的故事带到此博客。
|
||||
|
||||
## 接下来会发生什么{#what’s-coming-next}
|
||||
|
||||
|
|
|
|||
|
|
@ -17,13 +17,13 @@ Kubernetes [operator](https://kubernetes.io/docs/concepts/extend-kubernetes/oper
|
|||
- 不在 API 中的小型定制不需要更改 chart 或 API
|
||||
- 版本特定的升级 hook 可以很容易和稳健地实现
|
||||
|
||||
[Helm 安装](/zh/docs/setup/install/helm/)方法正在弃用中。从 Istio 1.4 升级到一个默认没有安装 Helm 的版本也会被一个新的[{{< istioctl >}} 升级特性](/zh/docs/setup/upgrade/istioctl-upgrade/)所取代。
|
||||
[Helm 安装](/zh/docs/setup/install/helm/)方法正在弃用中。从 Istio 1.4 升级到一个默认没有安装 Helm 的版本也会被一个新的 [{{< istioctl >}} 升级特性](/zh/docs/setup/upgrade/istioctl-upgrade/)所取代。
|
||||
|
||||
新的 `istioctl` 安装命令使用一个[自定义资源](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)来配置安装。自定义资源是新的 Istio operator 实现的一部分，该实现旨在简化安装、升级和复杂的 Istio 配置更改等常见管理任务。安装和升级的验证和检查与工具紧密集成，以防止常见错误并简化故障排除。
|
||||
|
||||
## Operator API{#the-Operator-API}
|
||||
|
||||
每个 operator 实现都需要一个[自定义资源定义（CRD）](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions) 来定义它的自定义资源，即它的API。Istio 的 operator API 由 [`IstioControlPlane` CRD](/zh/docs/reference/config/istio.operator.v1alpha12.pb/) 定义，它是由一个 [`IstioControlPlane` 原型](https://github.com/istio/operator/blob/release-1.4/pkg/apis/istio/v1alpha2/istiocontrolplane_types.proto)生成的。API 支持所有 Istio 当前的[配置文件](/zh/docs/setup/additional-setup/config-profiles/) ，通过使用一个字段来选择 profile。例如，下面的 `IstioControlPlane` 资源使用 `demo` profile 配置 Istio：
|
||||
每个 operator 实现都需要一个[自定义资源定义（CRD）](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions) 来定义它的自定义资源，即它的 API。Istio 的 operator API 由 [`IstioControlPlane` CRD](/zh/docs/reference/config/istio.operator.v1alpha12.pb/) 定义，它是由一个 [`IstioControlPlane` 原型](https://github.com/istio/operator/blob/release-1.4/pkg/apis/istio/v1alpha2/istiocontrolplane_types.proto)生成的。API 支持所有 Istio 当前的[配置文件](/zh/docs/setup/additional-setup/config-profiles/) ，通过使用一个字段来选择 profile。例如，下面的 `IstioControlPlane` 资源使用 `demo` profile 配置 Istio：
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: install.istio.io/v1alpha2
|
||||
|
|
@ -114,7 +114,7 @@ $ istioctl manifest generate ... --set values.global.mtls.enabled=true
|
|||
|
||||
你也可以在一个 `IstioControlPlane` 自定义资源中设置 Helm 配置值。参见[使用 Helm 自定义 Istio 设置](/zh/docs/setup/install/istioctl/#customize-Istio-settings-using-the-helm-API)。
|
||||
|
||||
另一个可以帮助从 Helm 迁移的特性是这个 alpha 命令：[{{< istioctl >}} manifest migrate](/zh/docs/reference/commands/istioctl/#istioctl-manifest-migrate)。此命令可用于将Helm `values.yaml` 文件自动转换为相应的 `IstioControlPlane` 配置。
|
||||
另一个可以帮助从 Helm 迁移的特性是这个 alpha 命令：[{{< istioctl >}} manifest migrate](/zh/docs/reference/commands/istioctl/#istioctl-manifest-migrate)。此命令可用于将 Helm `values.yaml` 文件自动转换为相应的 `IstioControlPlane` 配置。
|
||||
|
||||
## 实现{#implementation}
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ target_release: 1.3
|
|||
|
||||
## 隔离和边界保护{#isolation-and-boundary-protection}
|
||||
|
||||
隔离和边界保护机制在 [NIST 特殊出版物 800-53，修订4，联邦信息系统和组织的安全和隐私控制](http://dx.doi.org/10.6028/NIST.SP.800-53r4)，_附录 F，安全控制目录，SC-7 边界保护中进行了说明_。
|
||||
隔离和边界保护机制在 [NIST 特殊出版物 800-53，修订 4，联邦信息系统和组织的安全和隐私控制](http://dx.doi.org/10.6028/NIST.SP.800-53r4)，_附录 F，安全控制目录，SC-7 边界保护中进行了说明_。
|
||||
|
||||
特别是 _边界保护，隔离信息系统组件_ 控制增强：
|
||||
|
||||
|
|
@ -37,7 +37,7 @@ target_release: 1.3
|
|||
组织可以隔离执行不同任务和/或业务功能的信息系统组件。这种隔离限制了系统组件之间未经授权的信息流，并且还提供了为所选组件部署更高级别的保护的机会。使用边界保护机制将系统组件分开提供了增强对单个组件的保护并更有效地控制这些组件之间的信息流的能力。这种类型的增强保护可限制网络攻击和错误带来的潜在危害。提供的分离程度取决于所选的机制。边界保护机制包括，路由器、网关和防火墙等，将系统组件分离为物理上分离的网络或子网；跨域设备将子网分离；虚拟化技术；以及使用不同的加密密钥对系统组件之间的信息流进行加密。
|
||||
{{< /quote >}}
|
||||
|
||||
各种合规性标准隔离建议，用于处理组织其余部分的敏感数据的环境。[支付卡行业（PCI）数据安全标准](https://www.pcisecuritystandards.org/pci_security/)建议为 _持卡人数据_ 环境实现网络隔离，并要求将此环境与 [DMZ](https://en.wikipedia.org/wiki/DMZ_(computing)) 隔离。[FedRAMP 边界授权指南](https://www.fedramp.gov/assets/resources/documents/CSP_A_FedRAMP_Authorization_Boundary_Guidance.pdf) 描述了联邦信息和数据的 _授权边界_，而 [NIST 特别出版物 800-37，修订版 2，信息系统和组织的风险管理框架：用于安全性和隐私的系统生命周期方法](https://doi.org/10.6028/NIST.SP.800-37r2) _附录 G，授权边界注意事项_ 建议保护这样的边界：
|
||||
各种合规性标准隔离建议，用于处理组织其余部分的敏感数据的环境。[支付卡行业（PCI）数据安全标准](https://www.pcisecuritystandards.org/pci_security/)建议为 _持卡人数据_ 环境实现网络隔离，并要求将此环境与 [DMZ](https://en.wikipedia.org/wiki/DMZ_(computing)) 隔离。[FedRAMP 边界授权指南](https://www.fedramp.gov/assets/resources/documents/CSP_A_FedRAMP_Authorization_Boundary_Guidance.pdf)描述了联邦信息和数据的 _授权边界_，而 [NIST 特别出版物 800-37，修订版 2，信息系统和组织的风险管理框架：用于安全性和隐私的系统生命周期方法](https://doi.org/10.6028/NIST.SP.800-37r2) _附录 G，授权边界注意事项_ 建议保护这样的边界：
|
||||
|
||||
{{< quote >}}
|
||||
将系统划分为子系统（即分而治之）有助于针对性地应用控制措施，以实现足够的安全性，保护个人隐私和具有成本效益的风险管理流程。将复杂的系统划分为子系统也支持域分离和网络分段的重要安全概念，这在处理高价值资产时可能非常重要。将系统划分为子系统时，组织可以选择制定单独的子系统安全和隐私计划，也可以选择在相同的安全和隐私计划中处理系统和子系统。
|
||||
|
|
|
|||
|
|
@ -25,9 +25,9 @@ Istio 控制平面使用了预定义集群 BlackHoleCluster 和 Passthrough 来
|
|||
例如，在 Kubernetes 集群中，Istio 会为所有 Kubernetes 服务配置 sidecar，以保留所有能够与其他服务通信的服务的默认 Kubernetes 行为。
|
||||
|
||||
外部服务是不属于平台的服务，即不在网格内的服务。
|
||||
对于外部服务，Istio提供了两个选项，一个是阻止所有外部服务访问（通过将 `global.outboundTrafficPolicy.mode` 设置
|
||||
为 `REGISTRY_ONLY` 启用）,另一个是允许所有对外部服务的访问（通过将 `global.outboundTrafficPolicy.mode` 设置为 `ALLOW_ANY` 启用）。
|
||||
从Istio 1.3开始，此设置的默认选项是允许所有外部服务访问。此选项可以通过[网格配置](/zh/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-OutboundTrafficPolicy-Mode)进行配置。
|
||||
对于外部服务，Istio 提供了两个选项，一个是阻止所有外部服务访问（通过将 `global.outboundTrafficPolicy.mode` 设置
|
||||
为 `REGISTRY_ONLY` 启用）, 另一个是允许所有对外部服务的访问（通过将 `global.outboundTrafficPolicy.mode` 设置为 `ALLOW_ANY` 启用）。
|
||||
从 Istio 1.3 开始，此设置的默认选项是允许所有外部服务访问。此选项可以通过[网格配置](/zh/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-OutboundTrafficPolicy-Mode)进行配置。
|
||||
|
||||
这就是使用 BlackHole 和 Passthrough 集群的地方。
|
||||
|
||||
|
|
@ -71,7 +71,7 @@ Istio 控制平面使用了预定义集群 BlackHoleCluster 和 Passthrough 来
|
|||
}
|
||||
{{< /text >}}
|
||||
|
||||
该路由被设置为响应码是 502 的 [直接响应](https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/route/route_components.proto#envoy-api-field-route-route-direct-response)，这意味着如果没有其他路由匹配，则 Envoy 代理将直接返回 502 HTTP 状态代码。
|
||||
该路由被设置为响应码是 502 的[直接响应](https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/route/route_components.proto#envoy-api-field-route-route-direct-response)，这意味着如果没有其他路由匹配，则 Envoy 代理将直接返回 502 HTTP 状态代码。
|
||||
|
||||
* **PassthroughCluster** - 当将 `global.outboundTrafficPolicy.mode` 设置为 `ALLOW_ANY` 时，
|
||||
PassthroughCluster 是在 Envoy 配置中创建的虚拟集群。在此模式下，允许流向外部服务的所有流量。
|
||||
|
|
|
|||
|
|
@ -8,11 +8,11 @@ keywords: [traffic-management,multicluster]
|
|||
target_release: 1.0
|
||||
---
|
||||
|
||||
如果花一点时间对 Istio 进行了解，你可能会注意到，大量的功能都可以在单一的 Kubernetes 集群中，用简单的 [任务](/zh/docs/tasks) 和 [示例](/zh/docs/examples/) 所表达的方式来运行。但是真实世界中的云计算和基于微服务的应用往往不是这么简单的，会需要在不止一个地点分布运行，用户难免会产生怀疑，生产环境中是否还能这样运行？
|
||||
如果花一点时间对 Istio 进行了解，你可能会注意到，大量的功能都可以在单一的 Kubernetes 集群中，用简单的[任务](/zh/docs/tasks)和[示例](/zh/docs/examples/)所表达的方式来运行。但是真实世界中的云计算和基于微服务的应用往往不是这么简单的，会需要在不止一个地点分布运行，用户难免会产生怀疑，生产环境中是否还能这样运行？
|
||||
|
||||
幸运的是，Istio 提供了多种服务网格的配置方式，应用能够用近乎透明的方式加入一个跨越多个集群运行的服务网格之中，也就是 [多集群服务网格](/zh/docs/ops/deployment/deployment-models/#multiple-clusters) 。最简单的设置多集群网格的方式，就是使用 [多控制平面拓扑](/zh/docs/ops/deployment/deployment-models/#control-plane-models) ，这种方式不需要特别的网络依赖。在这种条件下，每个 Kubernetes 集群都有自己的控制平面，但是每个控制平面都是同步的，并接受统一的管理。
|
||||
幸运的是，Istio 提供了多种服务网格的配置方式，应用能够用近乎透明的方式加入一个跨越多个集群运行的服务网格之中，也就是[多集群服务网格](/zh/docs/ops/deployment/deployment-models/#multiple-clusters) 。最简单的设置多集群网格的方式，就是使用[多控制平面拓扑](/zh/docs/ops/deployment/deployment-models/#control-plane-models) ，这种方式不需要特别的网络依赖。在这种条件下，每个 Kubernetes 集群都有自己的控制平面，但是每个控制平面都是同步的，并接受统一的管理。
|
||||
|
||||
本文中，我们会在多控制平面拓扑形式的多集群网格中尝试一下 Istio 的 [流量管理](/zh/docs/concepts/traffic-management/) 功能。我们会展示如何配置 Istio 路由规则，在多集群服务网格中部署 [Bookinfo 示例]({{<github_tree>}}/samples/bookinfo)，`reviews` 服务的 `v1` 版本运行在一个集群上，而 `v2` 和 `v3` 运行在另一个集群上，并完成远程服务调用。
|
||||
本文中，我们会在多控制平面拓扑形式的多集群网格中尝试一下 Istio 的[流量管理](/zh/docs/concepts/traffic-management/)功能。我们会展示如何配置 Istio 路由规则，在多集群服务网格中部署 [Bookinfo 示例]({{<github_tree>}}/samples/bookinfo)，`reviews` 服务的 `v1` 版本运行在一个集群上，而 `v2` 和 `v3` 运行在另一个集群上，并完成远程服务调用。
|
||||
|
||||
## 集群部署 {#setup-clusters}
|
||||
|
||||
|
|
@ -250,7 +250,7 @@ EOF
|
|||
|
||||
## 在 `cluster1` 上为远端的 `reviews` 服务创建 `ServiceEntry` 以及 `DestinationRule`
|
||||
|
||||
根据 [配置指南](/zh/docs/setup/install/multicluster/gateways/#setup-DNS) 中的介绍，远程服务可以用一个 `.global` 的 DNS 名称进行访问。在我们的案例中，就是 `reviews.default.global`，所以我们需要为这个主机创建 `ServiceEntry` 和 `DestinationRule`。`ServiceEntry` 会使用 `cluster2` 网关作为端点地址来访问服务。可以使用网关的 DNS 名称或者公共 IP：
|
||||
根据[配置指南](/zh/docs/setup/install/multicluster/gateways/#setup-DNS)中的介绍，远程服务可以用一个 `.global` 的 DNS 名称进行访问。在我们的案例中，就是 `reviews.default.global`，所以我们需要为这个主机创建 `ServiceEntry` 和 `DestinationRule`。`ServiceEntry` 会使用 `cluster2` 网关作为端点地址来访问服务。可以使用网关的 DNS 名称或者公共 IP：
|
||||
|
||||
{{< text bash >}}
|
||||
$ export CLUSTER2_GW_ADDR=$(kubectl get --context=$CTX_CLUSTER2 svc --selector=app=istio-ingressgateway \
|
||||
|
|
@ -302,7 +302,7 @@ spec:
|
|||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
`ServiceEntry` 的地址 `240.0.0.3` 可以是任意的未分配 IP。在 `240.0.0.0/4` 的范围里面进行选择是个不错的主意。阅读 [通过网关进行连接的多集群](/zh/docs/setup/install/multicluster/gateways/#configure-the-example-services) 一文，能够获得更多相关信息。
|
||||
`ServiceEntry` 的地址 `240.0.0.3` 可以是任意的未分配 IP。在 `240.0.0.0/4` 的范围里面进行选择是个不错的主意。阅读[通过网关进行连接的多集群](/zh/docs/setup/install/multicluster/gateways/#configure-the-example-services)一文，能够获得更多相关信息。
|
||||
|
||||
注意 `DestinationRule` 中的 `subset` 的标签，`cluster: cluster2` 对应的是 `cluster2` 网关。一旦流量到达目标集群，就会由本地目的 `DestinationRule` 来鉴别实际的 Pod 标签（`version: v1` 或者 `version: v2`）
|
||||
|
||||
|
|
|
|||
|
|
@ -10,19 +10,19 @@ keywords: [performance,scalability,scale,benchmarks]
|
|||
|
||||
服务网格为应用部署增加了很多功能，包括[流量策略](/zh/docs/concepts/what-is-istio/#traffic-management)、[可观察性](/zh/docs/concepts/what-is-istio/#observability)和[安全通信](/zh/docs/concepts/what-is-istio/#security)。但是，无论是时间（增加的延迟）还是资源（CPU 周期），向环境中添加服务网格都是有代价的。要就服务网格是否适合您的情况做出明智的决定，评估应用与服务网格一起部署时的性能非常重要。
|
||||
|
||||
今年早些时候，我们发布了关于 Istio 1.1 性能改进的 [博客](/zh/blog/2019/istio1.1_perf/)。在发布 [Istio 1.2](/zh/news/releases/1.2.x/announcing-1.2) 之后，我们希望提供指导和工具，以帮助您在可用于生产的 Kubernetes 环境中对 Istio 的数据平面性能进行基准测试。
|
||||
今年早些时候，我们发布了关于 Istio 1.1 性能改进的[博客](/zh/blog/2019/istio1.1_perf/)。在发布 [Istio 1.2](/zh/news/releases/1.2.x/announcing-1.2) 之后，我们希望提供指导和工具，以帮助您在可用于生产的 Kubernetes 环境中对 Istio 的数据平面性能进行基准测试。
|
||||
|
||||
总体而言，我们发现 Istio [sidecar 代理](/zh/docs/ops/deployment/architecture/#envoy) 的延迟取决于并发连接数。以每秒 1000 个请求（RPS）的速度，通过 16 个连接，Istio 延迟在 50% 时增加 **3 毫秒**，在 99% 时增加 **10 毫秒**。
|
||||
总体而言，我们发现 Istio [sidecar 代理](/zh/docs/ops/deployment/architecture/#envoy)的延迟取决于并发连接数。以每秒 1000 个请求（RPS）的速度，通过 16 个连接，Istio 延迟在 50% 时增加 **3 毫秒**，在 99% 时增加 **10 毫秒**。
|
||||
|
||||
在[Istio Tools 仓库](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark) 中，您将找到用于测量 Istio 数据平面性能的脚本和说明，以及有关如何使用另一服务网格实现 [Linkerd](https://linkerd.io) 运行脚本的其他说明。在我们详细介绍性能测试框架的每个步骤的一些最佳实践时，请[遵循](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark#setup)。
|
||||
在 [Istio Tools 仓库](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark)中，您将找到用于测量 Istio 数据平面性能的脚本和说明，以及有关如何使用另一服务网格实现 [Linkerd](https://linkerd.io) 运行脚本的其他说明。在我们详细介绍性能测试框架的每个步骤的一些最佳实践时，请[遵循](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark#setup)。
|
||||
|
||||
## 1. 使用生产就绪的 Istio 安装{#1-use-a-production-ready-Istio-installation}
|
||||
|
||||
为了准确地大规模度量服务网格的性能，使用 [适当大小的](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/istio-install#istio-setup) Kubernetes 集群很重要。我们使用三个工作节点进行测试，每个工作节点至少具有 4 vCPU 和 15 GB 的内存。
|
||||
为了准确地大规模度量服务网格的性能，使用[适当大小的](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/istio-install#istio-setup) Kubernetes 集群很重要。我们使用三个工作节点进行测试，每个工作节点至少具有 4 vCPU 和 15 GB 的内存。
|
||||
|
||||
然后，在该群集上使用可用于生产的 Istio **安装配置文件** 很重要。这使我们能够实现面向性能的设置，例如控制平面 pod 自动伸缩，并确保资源限制适用于繁重的流量负荷。[默认](/zh/docs/setup/install/helm/#option-1-install-with-helm-via-helm-template) Istio 安装适用于大多数基准测试用例。为了进行广泛的性能基准测试，并提供数千种注入代理的服务，我们还提供了 [调整后的 Istio 安装](https://github.com/istio/tools/blob/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/istio-install/values.yaml)，可为 Istio 控制平面分配额外的内存和 CPU。
|
||||
然后，在该群集上使用可用于生产的 Istio **安装配置文件** 很重要。这使我们能够实现面向性能的设置，例如控制平面 pod 自动伸缩，并确保资源限制适用于繁重的流量负荷。[默认](/zh/docs/setup/install/helm/#option-1-install-with-helm-via-helm-template) Istio 安装适用于大多数基准测试用例。为了进行广泛的性能基准测试，并提供数千种注入代理的服务，我们还提供了[调整后的 Istio 安装](https://github.com/istio/tools/blob/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/istio-install/values.yaml)，可为 Istio 控制平面分配额外的内存和 CPU。
|
||||
|
||||
{{< warning_icon >}} Istio 的 [demo 安装](/zh/docs/setup/getting-started/) 不适合进行性能测试，因为它被设计为部署在小型试用群集中，并且具有完整的跟踪和访问日志，可显示 Istio 的功能。
|
||||
{{< warning_icon >}} Istio 的 [demo 安装](/zh/docs/setup/getting-started/)不适合进行性能测试，因为它被设计为部署在小型试用群集中，并且具有完整的跟踪和访问日志，可显示 Istio 的功能。
|
||||
|
||||
## 2. 专注于数据平面{#2-focus-on-the-data-plane}
|
||||
|
||||
|
|
@ -37,7 +37,7 @@ keywords: [performance,scalability,scale,benchmarks]
|
|||
|
||||
当 [Mixer V2](https://docs.google.com/document/d/1QKmtem5jU_2F3Lh5SqLp0IuPb80_70J7aJEYu4_gS-s) 将所有策略和遥测功能直接移到代理中时，这两个例外都会在将来的 Istio 版本中消失。
|
||||
|
||||
接下来，在大规模测试 Istio 的数据平面性能时，不仅要以每秒递增的请求进行测试，而且还要以越来越多的 **并发** 连接进行测试，这一点很重要。这是因为现实世界中的高吞吐量流量来自多个客户端。我们 [提供了脚本](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark#run-performance-tests) 允许您以递增的 RPS 对任意数量的并发连接执行相同的负载测试。
|
||||
接下来，在大规模测试 Istio 的数据平面性能时，不仅要以每秒递增的请求进行测试，而且还要以越来越多的 **并发** 连接进行测试，这一点很重要。这是因为现实世界中的高吞吐量流量来自多个客户端。我们[提供了脚本](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark#run-performance-tests)允许您以递增的 RPS 对任意数量的并发连接执行相同的负载测试。
|
||||
|
||||
最后，我们的测试环境可以测量两个 pod 之间少量的请求。客户端 pod 是 [Fortio](http://fortio.org/)，它将流量发送到服务端 pod。
|
||||
|
||||
|
|
@ -45,7 +45,7 @@ keywords: [performance,scalability,scale,benchmarks]
|
|||
|
||||
## 3. 有/无 度量的代理{#3-measure-with-and-without-proxies}
|
||||
|
||||
尽管 Istio 的许多特性，例如 [双向 TLS 身份验证](/zh/docs/concepts/security/#mutual-TLS-authentication)，都依赖于应用 pod 的 Envoy 代理，但是您可以[选择性地禁用](/zh/docs/setup/additional-setup/sidecar-injection/#disabling-or-updating-the-webhook)一些网格服务的 sidecar 代理注入。在扩展 Istio 以进行生产时，您可能需要将 sidecar 代理增量添加到工作负载中。
|
||||
尽管 Istio 的许多特性，例如[双向 TLS 身份验证](/zh/docs/concepts/security/#mutual-TLS-authentication)，都依赖于应用 pod 的 Envoy 代理，但是您可以[选择性地禁用](/zh/docs/setup/additional-setup/sidecar-injection/#disabling-or-updating-the-webhook)一些网格服务的 sidecar 代理注入。在扩展 Istio 以进行生产时，您可能需要将 sidecar 代理增量添加到工作负载中。
|
||||
|
||||
为此，测试脚本提供了[三种不同模式](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark#run-performance-tests)。当请求同时通过客户端和服务器代理（`both`）、仅通过服务器代理（`serveronly`）和都不通过代理（`baseline`）时，这些模式将分析 Istio 的性能。
|
||||
|
||||
|
|
@ -108,4 +108,4 @@ keywords: [performance,scalability,scale,benchmarks]
|
|||
Istio 的性能取决于您的具体设置和流量负载情况。由于存在这种差异，请确保您的测试设置能够准确反映您的生产工作负载。要试用基准测试脚本，请转到 [Istio Tools 库](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark)。
|
||||
{{< /tip >}}
|
||||
|
||||
另外，请查阅 [Istio 性能和可伸缩性指南](/zh/docs/ops/deployment/performance-and-scalability) 获取最新的性能数据。感谢您的阅读，祝您基准测试愉快！
|
||||
另外，请查阅 [Istio 性能和可伸缩性指南](/zh/docs/ops/deployment/performance-and-scalability)获取最新的性能数据。感谢您的阅读，祝您基准测试愉快！
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ target_release: 1.2
|
|||
在 Kubernetes 1.12 之前，Kubernetes API 服务器的 JWT 存在以下问题：
|
||||
|
||||
1. 令牌没有重要字段来限制其使用范围，例如 `aud` 或 `exp`。有关更多信息，请参见[绑定服务令牌](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/auth/bound-service-account-tokens.md)。
|
||||
1.令牌安装在所有 pod 上，无法退出。请参见[服务帐户令牌数量](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/svcacct-token-volume-source.md)了解其机制。
|
||||
1. 令牌安装在所有 pod 上，无法退出。请参见[服务帐户令牌数量](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/svcacct-token-volume-source.md)了解其机制。
|
||||
|
||||
Kubernetes 1.12 引入了 `可信任` JWT 来解决这些问题。但是，直到 [Kubernetes 1.13](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.13.md) 才支持 `aud` 字段与 API 服务器受众具有不同的值。为了更好地保护网格，Istio 1.3 仅支持 `可信任` JWT，并且在启用 SDS 时要求 `aud` 字段的值为 `istio-ca`。在启用 SDS 的情况下将 Istio 部署升级到 1.3 之前，请验证您是否使用了 Kubernetes 1.13 或更高版本。
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ keywords: [traffic-management,automation,configuration,multicluster,multi-mesh,g
|
|||
target_release: 1.5
|
||||
---
|
||||
|
||||
在 Intuit 公司，我们看到了博客 [用于隔离和边界保护的多网格部署](/zh/blog/2019/isolated-clusters/)，其中提到的某些问题与我们有关系。我们意识到，即使我们想要配置单网格多集群，而不是博客中描述的多个网格联邦，也会在我们的环境中遇到相同的非统一命名问题。这篇博客介绍了我们如何使用 [Admiral](https://github.com/istio-ecosystem/admiral) 解决这些问题，该项目是 GitHub 组织 `istio-ecosystem` 下的一个开源项目。
|
||||
在 Intuit 公司，我们看到了博客[用于隔离和边界保护的多网格部署](/zh/blog/2019/isolated-clusters/)，其中提到的某些问题与我们有关系。我们意识到，即使我们想要配置单网格多集群，而不是博客中描述的多个网格联邦，也会在我们的环境中遇到相同的非统一命名问题。这篇博客介绍了我们如何使用 [Admiral](https://github.com/istio-ecosystem/admiral) 解决这些问题，该项目是 GitHub 组织 `istio-ecosystem` 下的一个开源项目。
|
||||
|
||||
## 背景{#background}
|
||||
|
||||
|
|
@ -26,7 +26,7 @@ target_release: 1.5
|
|||
|
||||
经过进一步的调查，很明显，配置需要根据上下文来确定：每个集群都需要根据其场景定制配置。
|
||||
|
||||
例如，我们有一个被订单和报告消费的支付服务。支付服务在 `us-east`（集群 3）和 `us-west`（集群 2）之间进行了 HA/DR 部署。支付服务部署在两个区域不同名的命名空间中。订单服务作为支付方式，部署在 `us-west` 另一个集群中（集群 1）。报告服务与 `us-west` 中的支付服务部署在同一群集中（群集2）。
|
||||
例如，我们有一个被订单和报告消费的支付服务。支付服务在 `us-east`（集群 3）和 `us-west`（集群 2）之间进行了 HA/DR 部署。支付服务部署在两个区域不同名的命名空间中。订单服务作为支付方式，部署在 `us-west` 另一个集群中（集群 1）。报告服务与 `us-west` 中的支付服务部署在同一群集中（群集 2）。
|
||||
|
||||
{{< image width="75%"
|
||||
link="./Istio_mesh_example.svg"
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ Istio 的[认证](/zh/docs/concepts/security/#authentication-policies)和[授权
|
|||
|
||||
通过 `preview` 配置文件安装 Istio 1.5 不会再安装 Mixer。安全起见，如果您是从以前的版本升级，或通过 `default` 配置文件安装，我们仍会保留 Mixer。当使用 Prometheus 或 Stackdriver 进行度量时，建议您尝试新模式并查看性能提高了多少。
|
||||
|
||||
如果有需要，您可以保持安装并启用 Mixer。最终，Mixer 将成为 Istio 单独的发行组件，成为 [istio-ecosystem](https://github.com/istio-ecosystem/)的一部分。
|
||||
如果有需要，您可以保持安装并启用 Mixer。最终，Mixer 将成为 Istio 单独的发行组件，成为 [istio-ecosystem](https://github.com/istio-ecosystem/) 的一部分。
|
||||
|
||||
## 减少移动部分{#fewer-moving-parts}
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ Istio 的[认证](/zh/docs/concepts/security/#authentication-policies)和[授权
|
|||
caption="Istio 2020 年的架构"
|
||||
>}}
|
||||
|
||||
2020年，我们将继续专注于普及，实现默认 `零配置` 的目标，该默认设置不需要您更改应用程序的任何配置即可使用 Istio 的大多数功能。
|
||||
2020 年，我们将继续专注于普及，实现默认 `零配置` 的目标，该默认设置不需要您更改应用程序的任何配置即可使用 Istio 的大多数功能。
|
||||
|
||||
## 改进生命周期管理{#improved-lifecycle-management}
|
||||
|
||||
|
|
@ -92,4 +92,4 @@ Istio 已经为强大的服务安全性提供了基础：可靠的 workload 身
|
|||
- [增强存储库](https://github.com/istio/enhancements/)，以便开发追踪功能。
|
||||
- 让没有 Kubernetes 的 Istio 可以更轻松地运行！
|
||||
|
||||
从大海到[天空](https://www.youtube.com/watch?v=YjZ4AZ7hRM0)，Istio 期待您的加入！
|
||||
从大海到[天空](https://www.youtube.com/watch?v=YjZ4AZ7hRM0)，Istio 期待您的加入！
|
||||
|
|
|
|||
|
|
@ -25,4 +25,4 @@
|
|||
|
||||
{{< text bash >}}
|
||||
$ export SOURCE_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
|
||||
{{< /text >}}
|
||||
{{< /text >}}
|
||||
|
|
|
|||
|
|
@ -2,4 +2,4 @@
|
|||
---
|
||||
{{< warning >}}
|
||||
以下信息描述了一个实验性功能，仅用于评估。
|
||||
{{< /warning >}}
|
||||
{{< /warning >}}
|
||||
|
|
|
|||
|
|
@ -3,4 +3,4 @@
|
|||
{{< warning >}}
|
||||
本文档中介绍如何使用带 Tiller 的 Helm 不使用安全默认值。
|
||||
有关基于 Tiller 安全安装的进一步步骤请参考[安全安装 Helm](https://helm.sh/docs/intro/install/)。
|
||||
{{< /warning >}}
|
||||
{{< /warning >}}
|
||||
|
|
|
|||
|
|
@ -2,4 +2,4 @@
|
|||
headless: true
|
||||
---
|
||||
|
||||
这个文件告诉 Hugo 引擎，在生成页面时，当前目录树下的所有文件都不应该在站点中被渲染为普通页面。
|
||||
这个文件告诉 Hugo 引擎，在生成页面时，当前目录树下的所有文件都不应该在站点中被渲染为普通页面。
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
---
|
||||
要查看追踪数据，必须向服务发送请求。请求的数量取决于 Istio 的采样率。
|
||||
采样率在安装 Istio 时设置，默认采样速率为 1%。在第一个跟踪可见之前，您需要发送至少100个请求。
|
||||
采样率在安装 Istio 时设置，默认采样速率为 1%。在第一个跟踪可见之前，您需要发送至少 100 个请求。
|
||||
使用以下命令向 `productpage` 服务发送 100 个请求：
|
||||
|
||||
{{< text bash >}}
|
||||
$ for i in `seq 1 100`; do curl -s -o /dev/null http://$GATEWAY_URL/productpage; done
|
||||
{{< /text >}}
|
||||
{{< /text >}}
|
||||
|
|
|
|||
|
|
@ -11,4 +11,4 @@ icon: docs
|
|||
|
||||
- [FAQ](/zh/faq)
|
||||
- [词汇表](/zh/docs/reference/glossary)。
|
||||
- [文档归档](https://archive.istio.io/)中包括了历史版本的快照。
|
||||
- [文档归档](https://archive.istio.io/)中包括了历史版本的快照。
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Istio 生成以下类型的遥测数据，以提供对整个服务网格的可
|
|||
|
||||
- [**指标**](#metrics)。Istio 基于 4 个监控的黄金标识（延迟、流量、错误、饱和）生成了一系列服务指标。Istio 还为[网格控制平面](/zh/docs/ops/deployment/architecture/)提供了更详细的指标。除此以外还提供了一组默认的基于这些指标的网格监控仪表板。
|
||||
- [**分布式追踪**](#distributed-traces)。Istio 为每个服务生成分布式追踪 span，运维人员可以理解网格内服务的依赖和调用流程。
|
||||
- [**访问日志**](#access-logs)。当流量流入网格中的服务时，Istio 可以生成每个请求的完整记录，包括源和目标的元数据。此信息使运维人员能够将服务行为的审查控制到单个[工作负载实例](/zh/docs/reference/glossary/#workload-instance) 的级别。
|
||||
- [**访问日志**](#access-logs)。当流量流入网格中的服务时，Istio 可以生成每个请求的完整记录，包括源和目标的元数据。此信息使运维人员能够将服务行为的审查控制到单个[工作负载实例](/zh/docs/reference/glossary/#workload-instance)的级别。
|
||||
|
||||
## 指标 {#metrics}
|
||||
|
||||
|
|
|
|||
|
|
@ -13,4 +13,4 @@ Istio 允许您为应用程序自定义策略，用以在运行时强制执行
|
|||
|
||||
Istio 还允许您创建自己的[策略适配器](/zh/docs/tasks/policy-enforcement/control-headers)，比如，您自定义的授权行为。
|
||||
|
||||
您必须为您的服务网格[启用策略实施](/zh/docs/tasks/policy-enforcement/enabling-policy) 以后才能使用此功能。
|
||||
您必须为您的服务网格[启用策略实施](/zh/docs/tasks/policy-enforcement/enabling-policy)以后才能使用此功能。
|
||||
|
|
|
|||
|
|
@ -140,7 +140,7 @@ Istio 提供了在 Kubernetes 中使用节点代理进行证书和密钥分配
|
|||
Istio 提供两种类型的身份验证：
|
||||
|
||||
- **传输身份验证**，也称为**服务间身份验证**：验证建立连接的直接客户端。
|
||||
Istio 提供 [双向 TLS](https://en.wikipedia.org/wiki/Mutual_authentication) 作为传输身份验证的完整堆栈解决方案。
|
||||
Istio 提供[双向 TLS](https://en.wikipedia.org/wiki/Mutual_authentication) 作为传输身份验证的完整堆栈解决方案。
|
||||
您可以轻松打开此功能，而无需更改服务代码。这个解决方案：
|
||||
|
||||
- 为每个服务提供强大的身份，表示其角色，以实现跨群集和云的互操作性。
|
||||
|
|
@ -185,7 +185,7 @@ Istio 双向 TLS 具有一个宽容模式（permissive mode），允许 service
|
|||
|
||||
您可以使用身份认证策略为在 Istio 网格中接收请求的服务指定身份验证要求。网格操作者使用 `.yaml` 文件来指定策略。部署后，策略将保存在 Istio 配置存储中。Pilot、Istio 控制器监视配置存储。一有任何的策略变更，Pilot 会将新策略转换为适当的配置，告知 Envoy sidecar 代理如何执行所需的身份验证机制。Pilot 可以获取公钥并将其附加到 JWT 验证配置。或者，Pilot 提供 Istio 系统管理的密钥和证书的路径，并将它们挂载到应用程序 pod 以进行双向 TLS。您可以在 [PKI 部分](/zh/docs/concepts/security/#PKI)中找到更多信息。Istio 异步发送配置到目标端点。代理收到配置后，新的身份验证要求会立即生效。
|
||||
|
||||
发送请求的客户端服务负责遵循必要的身份验证机制。对于源身份验证（JWT），应用程序负责获取 JWT 凭据并将其附加到请求。对于双向 TLS，Istio 提供[目标规则](/zh/docs/concepts/traffic-management/#destination-rules)。运维人员可以使用目标规则来指示客户端代理使用 TLS 与服务器端预期的证书进行初始连接。您可以在 [双向 TLS 认证](/zh/docs/concepts/security/#mutual-TLS-authentication)中找到有关双向 TLS 如何在 Istio 中工作的更多信息。
|
||||
发送请求的客户端服务负责遵循必要的身份验证机制。对于源身份验证（JWT），应用程序负责获取 JWT 凭据并将其附加到请求。对于双向 TLS，Istio 提供[目标规则](/zh/docs/concepts/traffic-management/#destination-rules)。运维人员可以使用目标规则来指示客户端代理使用 TLS 与服务器端预期的证书进行初始连接。您可以在[双向 TLS 认证](/zh/docs/concepts/security/#mutual-TLS-authentication)中找到有关双向 TLS 如何在 Istio 中工作的更多信息。
|
||||
|
||||
{{< image width="60%" link="./auth.svg" caption="认证架构" >}}
|
||||
|
||||
|
|
@ -493,8 +493,8 @@ spec:
|
|||
#### 自定义条件{#custom-conditions}
|
||||
|
||||
您还可以使用 `when` 部分指定其他条件。
|
||||
例如，下面的 `AuthorizationPolicy` 定义包括以下条件：`request.headers[version]` 是 `v1` 或 `v2`。
|
||||
在这种情况下，key 是 `request.headers[version]`，它是 Istio 属性 `request.headers`（是个字典）中的一项。
|
||||
例如，下面的 `AuthorizationPolicy` 定义包括以下条件：`request.headers [version]` 是 `v1` 或 `v2`。
|
||||
在这种情况下，key 是 `request.headers [version]`，它是 Istio 属性 `request.headers`（是个字典）中的一项。
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: security.istio.io/v1beta1
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ Istio 基本的服务发现和负载均衡能力为您提供了一个可用的
|
|||
|
||||
## 虚拟服务 {#virtual-services}
|
||||
|
||||
[虚拟服务（Virtual Service）](/zh/docs/reference/config/networking/virtual-service/#VirtualService)和[目标规则（Destination Rule）](#destination-rules)是 Istio 流量路由功能的关键拼图。虚拟服务让您配置如何在服务网格内将请求路由到服务，这基于 Istio 和平台提供的基本的连通性和服务发现能力。每个虚拟服务包含一组路由规则，Istio 按顺序评估它们，Istio 将每个给定的请求匹配到虚拟服务指定的实际目标地址。您的网格可以有多个虚拟服务，也可以没有，取决于您的使用场景。
|
||||
[虚拟服务（Virtual Service）](/zh/docs/reference/config/networking/virtual-service/#VirtualService) 和[目标规则（Destination Rule）](#destination-rules) 是 Istio 流量路由功能的关键拼图。虚拟服务让您配置如何在服务网格内将请求路由到服务，这基于 Istio 和平台提供的基本的连通性和服务发现能力。每个虚拟服务包含一组路由规则，Istio 按顺序评估它们，Istio 将每个给定的请求匹配到虚拟服务指定的实际目标地址。您的网格可以有多个虚拟服务，也可以没有，取决于您的使用场景。
|
||||
|
||||
### 为什么使用虚拟服务？{#why-use-virtual-services}
|
||||
|
||||
|
|
@ -51,7 +51,7 @@ Istio 基本的服务发现和负载均衡能力为您提供了一个可用的
|
|||
|
||||
使用虚拟服务，您可以为一个或多个主机名指定流量行为。在虚拟服务中使用路由规则，告诉 Envoy 如何发送虚拟服务的流量到适当的目标。路由目标地址可以是同一服务的不同版本，也可以是完全不同的服务。
|
||||
|
||||
一个典型的用例是将流量发送到被指定为服务子集的服务的不同版本。客户端将虚拟服务视为一个单一实体，将请求发送至虚拟服务主机，然后 Envoy 根据虚拟服务规则把流量路由到不同的版本。例如，“20%的调用转到新版本”或“将这些用户的调用转到版本 2”。这允许您创建一个金丝雀发布，逐步增加发送到新版本服务的流量百分比。流量路由完全独立于实例部署，这意味着实现新版本服务的实例可以根据流量的负载来伸缩，完全不影响流量路由。相比之下，像 Kubernetes 这样的容器编排平台只支持基于实例缩放的流量分发，这会让情况变得复杂。您可以在[使用 Istio 进行金丝雀部署](/zh/blog/2017/0.1-canary/)的文章里阅读到更多用虚拟服务实现金丝雀部署的内容。
|
||||
一个典型的用例是将流量发送到被指定为服务子集的服务的不同版本。客户端将虚拟服务视为一个单一实体，将请求发送至虚拟服务主机，然后 Envoy 根据虚拟服务规则把流量路由到不同的版本。例如，“20% 的调用转到新版本”或“将这些用户的调用转到版本 2”。这允许您创建一个金丝雀发布，逐步增加发送到新版本服务的流量百分比。流量路由完全独立于实例部署，这意味着实现新版本服务的实例可以根据流量的负载来伸缩，完全不影响流量路由。相比之下，像 Kubernetes 这样的容器编排平台只支持基于实例缩放的流量分发，这会让情况变得复杂。您可以在[使用 Istio 进行金丝雀部署](/zh/blog/2017/0.1-canary/)的文章里阅读到更多用虚拟服务实现金丝雀部署的内容。
|
||||
|
||||
虚拟服务可以让您：
|
||||
|
||||
|
|
@ -314,7 +314,7 @@ spec:
|
|||
|
||||
## 服务入口 {#service-entries}
|
||||
|
||||
使用[服务入口（Service Entry）](/zh/docs/reference/config/networking/service-entry/#ServiceEntry)来添加一个入口到 Istio 内部维护的服务注册中心。添加了服务入口后，Envoy 代理可以向服务发送流量，就好像它是网格内部的服务一样。配置服务入口允许您管理运行在网格外的服务的流量，它包括以下几种能力：
|
||||
使用[服务入口（Service Entry）](/zh/docs/reference/config/networking/service-entry/#ServiceEntry) 来添加一个入口到 Istio 内部维护的服务注册中心。添加了服务入口后，Envoy 代理可以向服务发送流量，就好像它是网格内部的服务一样。配置服务入口允许您管理运行在网格外的服务的流量，它包括以下几种能力：
|
||||
|
||||
- 为外部目标 redirect 和转发请求，例如来自 web 端的 API 调用，或者流向遗留老系统的服务。
|
||||
- 为外部目标定义[重试](#retries)、[超时](#timeouts)和[故障注入](#fault-injection)策略。
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ Bookinfo 应用中的几个微服务是由不同的语言编写的。
|
|||
{{< /text >}}
|
||||
|
||||
{{< warning >}}
|
||||
如果您在安装过程中禁用了 Sidecar 自动注入功能而选择[手动注入 Sidecar](/zh/docs/setup/additional-setup/sidecar-injection/#manual-sidecar-injection)，请在部署应用之前使用 [`istioctl kube-inject`](/zh/docs/reference/commands/istioctl/#istioctl-kube-inject)命令修改 `bookinfo.yaml` 文件。
|
||||
如果您在安装过程中禁用了 Sidecar 自动注入功能而选择[手动注入 Sidecar](/zh/docs/setup/additional-setup/sidecar-injection/#manual-sidecar-injection)，请在部署应用之前使用 [`istioctl kube-inject`](/zh/docs/reference/commands/istioctl/#istioctl-kube-inject) 命令修改 `bookinfo.yaml` 文件。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f <(istioctl kube-inject -f @samples/bookinfo/platform/kube/bookinfo.yaml@)
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ weight: 10
|
|||
|
||||
请按照下列步骤下载应用程序的代码，安装其依赖项，然后在本地运行它：
|
||||
|
||||
1. 将 [服务代码]({{< github_blob >}}/samples/bookinfo/src/ratings/ratings.js) 和
|
||||
1. 将[服务代码]({{<github_blob >}}/samples/bookinfo/src/ratings/ratings.js) 和
|
||||
[其 package 文件]({{< github_blob >}}/samples/bookinfo/src/ratings/package.json)
|
||||
下载到一个单独的目录中：
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ https://docs.google.com/drawings/d/1G1592HlOVgtbsIqxJnmMzvy6ejIdhajCosxF1LbvspI/
|
|||
|
||||
## 开始之前{#before-you-begin}
|
||||
|
||||
- 按照[安装指南](/zh/docs/setup/getting-started/) 中的说明安装 Istio。
|
||||
- 按照[安装指南](/zh/docs/setup/getting-started/)中的说明安装 Istio。
|
||||
|
||||
- 部署 [Bookinfo](/zh/docs/examples/bookinfo/) 示例应用程序（在 `bookinfo` 命名空间中）。
|
||||
|
||||
|
|
|
|||
|
|
@ -121,7 +121,7 @@ aliases:
|
|||
$ sudo dpkg -i istio-sidecar.deb
|
||||
{{< /text >}}
|
||||
|
||||
1. 添加 Istio gateway 的 IP 地址到 `/etc/hosts` 中。重新查看 [集群上定制化安装 Istio](#customized-installation-of-Istio-on-the-cluster) 部分学习怎样获取 IP 地址。
|
||||
1. 添加 Istio gateway 的 IP 地址到 `/etc/hosts` 中。重新查看[集群上定制化安装 Istio](#customized-installation-of-Istio-on-the-cluster) 部分学习怎样获取 IP 地址。
|
||||
下面的示例演示更新 `/etc/hosts` 文件中的 Istio gateway 地址：
|
||||
|
||||
{{< text bash >}}
|
||||
|
|
@ -322,4 +322,4 @@ $ curl -v httpbin.bar.global:8000
|
|||
$ istioctl experimental remove-from-mesh -n ${SERVICE_NAMESPACE} vmhttp
|
||||
Kubernetes Service "vmhttp.vm" has been deleted for external service "vmhttp"
|
||||
Service Entry "mesh-expansion-vmhttp" has been deleted for external service "vmhttp"
|
||||
{{< /text >}}
|
||||
{{< /text >}}
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ aliases:
|
|||
## 准备环境{#prerequisites}
|
||||
|
||||
- 您已经在 Kubernetes 上部署了 Istio。如果尚未这样做，
|
||||
则可以在[安装指南](/zh/docs/setup/getting-started/) 中找到方法。
|
||||
则可以在[安装指南](/zh/docs/setup/getting-started/)中找到方法。
|
||||
|
||||
- 虚拟机（VM）必须具有网格中 endpoint 的 IP 连接。
|
||||
这通常需要 VPC 或者 VPN，以及需要提供直接（没有 NAT 或者防火墙拒绝访问）
|
||||
|
|
@ -39,7 +39,7 @@ aliases:
|
|||
|
||||
当将非 Kubernetes 服务添加到 Istio 网格中时，首先配置 Istio 它自己的设施，并生成配置文件使 VM 连接网格。在具有集群管理员特权的计算机上，使用以下命令为 VM 准备集群：
|
||||
|
||||
1. 使用类似于以下的命令，为生成的 CA 证书创建 Kubernetes secret。请参阅[证书办法机构 (CA) 证书](/zh/docs/tasks/security/citadel-config/plugin-ca-cert/#plugging-in-the-existing-certificate-and-key) 获取更多的详细信息。
|
||||
1. 使用类似于以下的命令，为生成的 CA 证书创建 Kubernetes secret。请参阅[证书办法机构 (CA) 证书](/zh/docs/tasks/security/citadel-config/plugin-ca-cert/#plugging-in-the-existing-certificate-and-key)获取更多的详细信息。
|
||||
|
||||
{{< warning >}}
|
||||
样本目录中的 root 证书和中间证书已经大范围分发并被识别。
|
||||
|
|
@ -99,7 +99,7 @@ aliases:
|
|||
ISTIO_SERVICE_CIDR=10.55.240.0/20
|
||||
{{< /text >}}
|
||||
|
||||
1. 如果 VM 仅在网格中调用服务，您可以跳过这2一步骤。否则，使用以下命令为 VM 新增公开端口到 `cluster.env` 文件下。
|
||||
1. 如果 VM 仅在网格中调用服务，您可以跳过这 2 一步骤。否则，使用以下命令为 VM 新增公开端口到 `cluster.env` 文件下。
|
||||
如有必要，您可以稍后更改端口。
|
||||
|
||||
{{< text bash >}}
|
||||
|
|
@ -136,7 +136,7 @@ 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 >}}
|
||||
|
|
@ -182,7 +182,7 @@ aliases:
|
|||
设置完后，机器可以访问运行在 Kubernetes 集群上的服务，或者其他的 VM。
|
||||
|
||||
以下示例展示了使用 `/etc/hosts/` 如何从 VM 中访问 Kubernetes 集群上运行的服务，
|
||||
这里使用 [Bookinfo 示例](/zh/docs/examples/bookinfo/) 中的服务。
|
||||
这里使用 [Bookinfo 示例](/zh/docs/examples/bookinfo/)中的服务。
|
||||
|
||||
1. 首先，在集群管理机器上获取服务的虚拟 IP 地址（`clusterIP`）：
|
||||
|
||||
|
|
|
|||
|
|
@ -219,7 +219,7 @@ metadata:
|
|||
当为现有主机应用第二个及更多的 `VirtualService`时，`istio-pilot` 会将附加的路由规则合并到主机的现有配置中。但是，在使用此功能时，有一些注意事项。
|
||||
|
||||
1. 尽管会保留任何给定源 `VirtualService` 中规则的评估顺序，但跨资源的顺序是 UNDEFINED。换句话说，无法保证片段配置中规则的评估顺序，因此，只有在片段规则之间没有冲突的规则或者顺序依赖性时，它才具有可预测的行为。
|
||||
1.片段中应该只有一个“catch-all”规则（即与任何请求路径或 header 都匹配的规则）。所有这些“catch-all”规则将在合并配置中移至列表的末尾，但是由于它们捕获了所有请求，因此，首先应用的那个规则，实际上会覆盖并禁用其它的规则。
|
||||
1. 片段中应该只有一个“catch-all”规则（即与任何请求路径或 header 都匹配的规则）。所有这些“catch-all”规则将在合并配置中移至列表的末尾，但是由于它们捕获了所有请求，因此，首先应用的那个规则，实际上会覆盖并禁用其它的规则。
|
||||
1. 如果想将 `VirtualService` 绑定到网关，则只能以这种方式进行分段。sidecar 不支持主机合并。
|
||||
|
||||
也可以使用类似的合并语义和限制将 `DestinationRule` 分段。
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ aliases:
|
|||
$ kubectl logs PODNAME -c istio-proxy -n NAMESPACE
|
||||
{{< /text >}}
|
||||
|
||||
在默认的访问日志输出格式中，Envoy 响应标志和 Mixer 策略状态位于响应状态码之后，如果你使用自定义日志输出格式，请确保包含 `%RESPONSE_FLAGS%` 和 `%DYNAMIC_METADATA(istio.mixer:status)%`。
|
||||
在默认的访问日志输出格式中，Envoy 响应标志和 Mixer 策略状态位于响应状态码之后，如果你使用自定义日志输出格式，请确保包含 `%RESPONSE_FLAGS%` 和 `%DYNAMIC_METADATA(istio.mixer:status) %`。
|
||||
|
||||
参考 [Envoy 响应标志](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log#config-access-log-format-response-flags)查看更多有关响应标志的细节。
|
||||
|
||||
|
|
@ -254,7 +254,7 @@ server {
|
|||
- `VirtualService` 将 `vs1` 配置为主机 `service1.test.com` 并且 gateway 配置为 `gw`
|
||||
- `VirtualService` 将 `vs2` 配置为主机 `service2.test.com` 并且 gateway 配置为 `gw`
|
||||
|
||||
## 在网关中配置多个TLS主机时端口冲突{#port-conflict-when-configuring-multiple-TLS-hosts-in-a-gateway}
|
||||
## 在网关中配置多个 TLS 主机时端口冲突{#port-conflict-when-configuring-multiple-TLS-hosts-in-a-gateway}
|
||||
|
||||
如果您应用的 `Gateway` 配置与另一个现有的 `Gateway` 具有相同的 `selector` 标签，如果它们都暴露了相同的 HTTPS 端口，那您必须确保它们具有唯一的端口名。
|
||||
否则，该配置在应用时不会立即显示错误指示，但在运行时网关配置中将忽略该配置。
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ istio-system tcpkubeattrgenrulerule 4h
|
|||
|
||||
1. 与`istio-telemetry` 自监控端点建立连接，按照上文[确认 Mixer 可以收到指标报告的调用](#verify-mixer-is-receiving-report-calls)的描述设置一个到 `istio-telemetry` 自监控端口的转发。
|
||||
|
||||
1. 确认以下的指标的最新的值是0：
|
||||
1. 确认以下的指标的最新的值是 0：
|
||||
|
||||
* `mixer_config_adapter_info_config_errors_total`
|
||||
|
||||
|
|
@ -142,7 +142,7 @@ istio-system tcpkubeattrgenrulerule 4h
|
|||
|
||||
在显示 Mixer 自监控 endpoint 的页面上，搜索上面列出的每个指标。如果所有配置正确，您应该不能找的那些指标值。
|
||||
|
||||
如果存在某个指标值，请确认该指标值的最大配置 ID 是0。这可以验证 Mixer 在处理最近提供配置过程中没有发生任何错误。
|
||||
如果存在某个指标值，请确认该指标值的最大配置 ID 是 0。这可以验证 Mixer 在处理最近提供配置过程中没有发生任何错误。
|
||||
|
||||
### 验证 Mixer 可以将指标实例发送到 Prometheus 适配器{#verify-Mixer-is-sending-Metric-instances-to-the-Prometheus-adapter}
|
||||
|
||||
|
|
|
|||
|
|
@ -504,7 +504,7 @@ Citadel 不支持多个实例运行，否则会造成竞争状态并导致系统
|
|||
在 Citadel 维护禁用期间，带有新 ServiceAccount 的负载不能够启动，因为它不能从 Citadel 获取生成的证书。
|
||||
{{< /warning >}}
|
||||
|
||||
Citadel 不是关键的数据平面组件。默认的工作负载证书有效期是3个月。证书在过期前会被 Citadel 轮换。如果在 Citadel 短暂的维护期间内，已经存在的 双向 TLS 不会受影响。
|
||||
Citadel 不是关键的数据平面组件。默认的工作负载证书有效期是 3 个月。证书在过期前会被 Citadel 轮换。如果在 Citadel 短暂的维护期间内，已经存在的 双向 TLS 不会受影响。
|
||||
|
||||
如果您怀疑 Citadel 无法正常工作，请验证 `istio-citadel` pod 的状态：
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ aliases:
|
|||
|
||||
## 看似有效的配置不生效 {#valid-configuration-is-rejected}
|
||||
|
||||
手动验证您的配置是否正确，当有必要的时候请参照[Istio API 文档](/zh/docs/reference/config) 。
|
||||
手动验证您的配置是否正确，当有必要的时候请参照 [Istio API 文档](/zh/docs/reference/config) 。
|
||||
|
||||
## 接受无效配置 {#invalid-configuration-is-accepted}
|
||||
|
||||
|
|
@ -126,7 +126,7 @@ webhooks:
|
|||
|
||||
## 创建配置失败报错： x509 certificate errors {#x509-certificate-errors}
|
||||
|
||||
`x509: certificate signed by unknown authority` 错误通常和 webhook 配置中的空 `caBundle` 有关，所以要确认它不为空 (请查阅 [验证 webhook 配置](#invalid-configuration-is-accepted))。Istio 有意识的使用 `istio-validation` `configmap` 和根证书，调整了 webhook 配置。
|
||||
`x509: certificate signed by unknown authority` 错误通常和 webhook 配置中的空 `caBundle` 有关，所以要确认它不为空 (请查阅[验证 webhook 配置](#invalid-configuration-is-accepted))。Istio 有意识的使用 `istio-validation` `configmap` 和根证书，调整了 webhook 配置。
|
||||
|
||||
1. 验证 `istio-pilot` pod 是否在运行：
|
||||
|
||||
|
|
|
|||
|
|
@ -20,11 +20,11 @@ keywords: [security,health-check]
|
|||
|
||||
本节将阐述如何在启用了双向 TLS 的 Istio 中使用这三种方式。
|
||||
|
||||
注意，无论是否启用了双向 TLS 认证，命令和 TCP 请求方式都可以与 Istio 一起使用。HTTP请求方式则要求启用了 TLS 的 Istio 使用不同的配置。
|
||||
注意，无论是否启用了双向 TLS 认证，命令和 TCP 请求方式都可以与 Istio 一起使用。HTTP 请求方式则要求启用了 TLS 的 Istio 使用不同的配置。
|
||||
|
||||
## 在学习本节之前{#before-you-begin}
|
||||
|
||||
* 理解 Kubernetes 的 [Liveness 和 Readiness 探针](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)，Istio 的 [认证策略](/zh/docs/concepts/security/#authentication-policies) 和 [双向 TLS 认证](/zh/docs/concepts/security/#mutual-TLS-authentication) 概念。
|
||||
* 理解 Kubernetes 的 [Liveness 和 Readiness 探针](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)，Istio 的[认证策略](/zh/docs/concepts/security/#authentication-policies)和[双向 TLS 认证](/zh/docs/concepts/security/#mutual-TLS-authentication)概念。
|
||||
|
||||
* 有一个安装了 Istio 的 Kubernetes 集群，并且未开启全局双向 TLS 认证。
|
||||
|
||||
|
|
@ -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}
|
||||
|
|
@ -194,7 +194,7 @@ NAME READY STATUS RESTARTS AGE
|
|||
liveness-http-67d5db65f5-765bb 2/2 Running 0 1m
|
||||
{{< /text >}}
|
||||
|
||||
请注意，[liveness-http]({{< github_file >}}/samples/health-check/liveness-http.yaml) 的镜像公开了两个端口：8001 和 8002 ([源码]({{< github_file >}}/samples/health-check/server.go))。在这个部署方式里面，端口8001用于常规流量，而端口8002给 Liveness 探针使用。
|
||||
请注意，[liveness-http]({{< github_file >}}/samples/health-check/liveness-http.yaml) 的镜像公开了两个端口：8001 和 8002 ([源码]({{< github_file >}}/samples/health-check/server.go))。在这个部署方式里面，端口 8001 用于常规流量，而端口 8002 给 Liveness 探针使用。
|
||||
|
||||
### 清除{#cleanup}
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Sidecar 是否会被自动注入取决于下面 3 条配置和 2 条安全规则
|
|||
安全规则:
|
||||
|
||||
- sidecar 默认不能被注入到 `kube-system` 和 `kube-public` 这两个 namespace
|
||||
- sidecar 不能被注入到使用 `host network` 网络的pod里
|
||||
- sidecar 不能被注入到使用 `host network` 网络的 pod 里
|
||||
|
||||
下面的表格展示了基于上述三个配置条件的最终注入状态。上述的安全规则不会被覆盖。
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Webhook 设置过程需要了解 Kubernetes 动态准入 Webhook 相关的知识
|
|||
|
||||
## 验证动态准入 Webhook 前置条件
|
||||
|
||||
请参阅 [平台设置说明](/zh/docs/setup/platform-setup/)。如果集群配置错误，Webhook 将无法正常工作。集群配置后，当动态 Webhook 和相关特性不能正常工作时，你可以通过以下步骤进行检查。
|
||||
请参阅[平台设置说明](/zh/docs/setup/platform-setup/)。如果集群配置错误，Webhook 将无法正常工作。集群配置后，当动态 Webhook 和相关特性不能正常工作时，你可以通过以下步骤进行检查。
|
||||
|
||||
1. 验证当前是否使用正确版本的 [`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl/) 和 Kubernetes 服务
|
||||
|
||||
|
|
@ -38,4 +38,4 @@ Webhook 设置过程需要了解 Kubernetes 动态准入 Webhook 相关的知识
|
|||
|
||||
1. 验证 `kube-apiserver --enable-admission-plugins` 配置中插件 `MutatingAdmissionWebhook` 和 `ValidatingAdmissionWebhook` 是否被启用。通过检查[指定规范](/zh/docs/setup/platform-setup/)中的标志（`--enable-admission-plugins`）。
|
||||
|
||||
1. 验证 Kubernetes api-server 与 Webhook 所在 Pod 的网络连通是否正常。例如错误配置 `http_proxy` 可能干扰 api-server 正常运行（详细信息请参阅[pr](https://github.com/kubernetes/kubernetes/pull/58698#discussion_r163879443)和[issue](https://github.com/kubernetes/kubeadm/issues/666))。
|
||||
1. 验证 Kubernetes api-server 与 Webhook 所在 Pod 的网络连通是否正常。例如错误配置 `http_proxy` 可能干扰 api-server 正常运行（详细信息请参阅 [pr](https://github.com/kubernetes/kubernetes/pull/58698#discussion_r163879443) 和 [issue](https://github.com/kubernetes/kubeadm/issues/666))。
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ aliases:
|
|||
- 攻击面减小了。包括尽可能少的漏洞。
|
||||
- 镜像更小了，启动更快。
|
||||
|
||||
请参考官方非发行版 README 的[为何我选择非发行版镜像？](https://github.com/GoogleContainerTools/distroless#why-should-i-use-distroless-images)章节。
|
||||
请参考官方非发行版 README 的[为何我选择非发行版镜像？](https://github.com/GoogleContainerTools/distroless#why-should-i-use-distroless-images) 章节。
|
||||
|
||||
{{< warning >}}
|
||||
请注意，通常的调试工具如 `bash`、`curl`、`netcat`、`tcpdump` 等在非发行版镜像中是不可用的。
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ aliases:
|
|||
|
||||
Envoy 代理收集保留了关于网络流量的详细统计信息。
|
||||
|
||||
Envoy 的统计信息只覆盖了特定 Envoy 实例的流量。参考 [可观测性](/zh/docs/tasks/observability/)
|
||||
Envoy 的统计信息只覆盖了特定 Envoy 实例的流量。参考[可观测性](/zh/docs/tasks/observability/)
|
||||
了解关于服务级别的 Istio 遥测方面的内容。这些由 Envoy 代理产生的统计数据记录能够提供更多关于 pod 实例的具体信息。
|
||||
|
||||
查看某个 pod 的统计信息：
|
||||
|
|
@ -32,7 +32,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) 更加深入的了解相关的配置。
|
||||
[深入研究 Envoy 配置](/zh/docs/ops/diagnostic-tools/proxy-cmd/#deep-dive-into-envoy-configuration)更加深入的了解相关的配置。
|
||||
需要注意的是, 只有那些 `stats_matcher` JSON 字段能匹配上 `inclusion_list` 的元件，Envoy 才会去收集他们的统计数据。
|
||||
|
||||
要想让 Envoy 去收集出站和入站流量的统计信息，只需将 `sidecar.istio.io/statsInclusionPrefixes` 注解加到 Kubernetes `Deployment` 的 pod 模板里去。
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ Istio 1.4 对直接在 Envoy 代理中生成服务级别的 HTTP 指标添加了
|
|||
|
||||
我们不考虑将这个特性提升到 **Beta** 或者 **Stable** [状态](/zh/about/feature-stages/#feature-phase-definitions)，直到我们完成性能和可扩展性的提升以及评估。
|
||||
|
||||
你的网格的性能依赖于你的配置。要了解更多，请看我们的 [性能最佳实践帖](/zh/blog/2019/performance-best-practices/)。
|
||||
你的网格的性能依赖于你的配置。要了解更多，请看我们的[性能最佳实践帖](/zh/blog/2019/performance-best-practices/)。
|
||||
|
||||
{{< /warning >}}
|
||||
|
||||
|
|
@ -52,7 +52,7 @@ Istio 1.4 对直接在 Envoy 代理中生成服务级别的 HTTP 指标添加了
|
|||
- 在 `istio-proxy` 容器中所有的过滤器一起使用比运行 Mixer 过滤器减少了 10% 的 CPU 资源。
|
||||
- 和不配置遥测过滤器的 Envoy 代理相比，新增加的过滤器会导致在 1000 rps 时增加约 5ms P90 的时延。
|
||||
- 如果你只使用 `istio-telemetry` 服务来生成服务级别的指标，你可以关闭 `istio-telemetry` 服务。
|
||||
这样网格中每 1000 rps 流量可以为你节省约 0.5 vCPU，并且可以在收集 [标准指标](/zh/docs/reference/config/policy-and-telemetry/metrics/) 时将 Istio 消耗的 CPU 减半。
|
||||
这样网格中每 1000 rps 流量可以为你节省约 0.5 vCPU，并且可以在收集[标准指标](/zh/docs/reference/config/policy-and-telemetry/metrics/)时将 Istio 消耗的 CPU 减半。
|
||||
|
||||
## 已知的限制{#known-limitations}
|
||||
|
||||
|
|
|
|||
|
|
@ -9,4 +9,4 @@ keywords:
|
|||
- requirements
|
||||
- installation
|
||||
- configuration
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ Istio 的数据平面组件 Envoy 代理用来处理通过系统的数据流。
|
|||
- 通过代理的 QPS 有 1000 时，Envoy 使用了 **0.5 vCPU** 和 **50 MB 内存**。
|
||||
- 网格总的 QPS 为 1000 时，`istio-telemetry` 服务使用了 **0.6 vCPU**。
|
||||
- Pilot 使用了 **1 vCPU** 和 1.5 GB 内存。
|
||||
- 90%的情况 Envoy 代理只增加了 6.3 ms 的延迟。
|
||||
- 90% 的情况 Envoy 代理只增加了 6.3 ms 的延迟。
|
||||
|
||||
## 控制平面性能 {#control-plane-performance}
|
||||
|
||||
|
|
@ -43,7 +43,7 @@ Pilot 根据用户编写的配置文件和系统当前状态来配置 sidecar
|
|||
- 配置改变的频率。
|
||||
- 连接到 Pilot 的代理数量。
|
||||
|
||||
这部分本身是水平可伸缩的。当 [命名空间隔离](/zh/docs/reference/config/networking/sidecar/) 选项被打开，一个单一的 Pilot 实例仅用 1 vCPU 和 1.5 GB 的内存就可以支持 1000 个服务和 2000 个 sidecar。你可以增加 Pilot 实例的数量来降低它花在推送配置到所有代理的耗时。
|
||||
这部分本身是水平可伸缩的。当[命名空间隔离](/zh/docs/reference/config/networking/sidecar/)选项被打开，一个单一的 Pilot 实例仅用 1 vCPU 和 1.5 GB 的内存就可以支持 1000 个服务和 2000 个 sidecar。你可以增加 Pilot 实例的数量来降低它花在推送配置到所有代理的耗时。
|
||||
|
||||
## 数据平面性能 {#data-plane-performance}
|
||||
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ Istio 使用了如下的端口和协议。请确保没有 TCP Headless Service
|
|||
|
||||
## 所需的 Pod 功能{#required-pod-capabilities}
|
||||
|
||||
如果集群中的 [Pod 安全策略](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) 被[强制执行](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#enabling-pod-security-policies)，并且除非您使用 Istio CNI 插件，否则您的 Pod 必须具有允许的 `NET_ADMIN` 功能。Envoy 代理的初始化容器需要此功能。
|
||||
如果集群中的 [Pod 安全策略](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)被[强制执行](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#enabling-pod-security-policies)，并且除非您使用 Istio CNI 插件，否则您的 Pod 必须具有允许的 `NET_ADMIN` 功能。Envoy 代理的初始化容器需要此功能。
|
||||
|
||||
要检查您的 Pod 是否支持 `NET_ADMIN` 功能，您需要检查其 [service account(服务账户)](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) 是否可以使用允许 `NET_ADMIN` 功能的 Pod 安全策略。如果尚未在 Pod 的部署中指定服务帐户，则 Pod 将在其部署的命名空间中使用 `默认` 服务帐户运行。
|
||||
|
||||
|
|
@ -85,4 +85,4 @@ $ for psp in $(kubectl get psp -o jsonpath="{range .items[*]}{@.metadata.name}{'
|
|||
$ for psp in $(kubectl get psp -o jsonpath="{range .items[*]}{@.metadata.name}{'\n'}{end}"); do if [ $(kubectl auth can-i use psp/$psp --as=system:serviceaccount:default:default) = yes ]; then kubectl get psp/$psp --no-headers -o=custom-columns=NAME:.metadata.name,CAPS:.spec.allowedCapabilities; fi; done
|
||||
{{< /text >}}
|
||||
|
||||
如果您在服务帐户允许的策略的功能列表中看到 `NET_ADMIN` 或者 `*`，则您的 Pod 有权利运行 Istio 初始化容器。否则，您将需要[提供许可认证](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#authorizing-policies)。
|
||||
如果您在服务帐户允许的策略的功能列表中看到 `NET_ADMIN` 或者 `*`，则您的 Pod 有权利运行 Istio 初始化容器。否则，您将需要[提供许可认证](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#authorizing-policies)。
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Istio 组件使用一个灵活的日志框架来构建，该框架提供了许
|
|||
|
||||
组件输出的日志信息按 `作用域` 分类，一个作用域代表可以被控制的相关日志信息的整体。根据组件提供的功能，不同的组件具有不同的作用域。所有组件都有 `default` 作用域，该作用域用于未分类的日志信息。
|
||||
|
||||
例如，在撰写本文时，Mixer 有5个作用域，代表了 Mixer 中的不同功能区域：
|
||||
例如，在撰写本文时，Mixer 有 5 个作用域，代表了 Mixer 中的不同功能区域：
|
||||
|
||||
- `adapters`
|
||||
- `api`
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ $ istioctl analyze *.yaml
|
|||
如果您发现了一些 Istio 配置 “陷阱”，一些导致您的使用出现问题的棘手情况，请提出问题并告知我们。
|
||||
我们也许可以自动标记此问题，以便其他人可以提前发现并避免该问题。
|
||||
|
||||
为此，请您 [开启一个 issue](https://github.com/istio/istio/issues) 来描述您的情况。例如：
|
||||
为此，请您[开启一个 issue](https://github.com/istio/istio/issues) 来描述您的情况。例如：
|
||||
|
||||
- 查看所有 virtual services
|
||||
- 循环查看 virtual services 的 gateways 列表
|
||||
|
|
@ -73,7 +73,7 @@ $ istioctl analyze *.yaml
|
|||
|
||||
- **现在支持哪些分析器？**
|
||||
|
||||
我们仍在努力编写分析器文档。目前，您可以在 [Istio 源代码]({{<github_blob>}}/galley/pkg/config/analysis/analyzers) 中看到所有分析器。
|
||||
我们仍在努力编写分析器文档。目前，您可以在 [Istio 源代码]({{<github_blob>}}/galley/pkg/config/analysis/analyzers)中看到所有分析器。
|
||||
|
||||
你还可以了解一下目前支持哪些[配置分析消息](/zh/docs/reference/config/analysis/)。
|
||||
|
||||
|
|
@ -157,7 +157,7 @@ status:
|
|||
`enableAnalysis` 在后台运行，并将使资源的状态字段保持其当前验证状态的最新状态。请注意，这不能代替 `istioctl analyze`：
|
||||
|
||||
- 并非所有资源都有自定义状态字段 (例如 Kubernetes `namespace` 资源)，因此附加到这些资源的消息将不会显示验证消息。
|
||||
- `enableAnalysis` 仅适用于从1.4开始的 Istio 版本，而 `istioctl analysis` 可以用于较早的版本。
|
||||
- `enableAnalysis` 仅适用于从 1.4 开始的 Istio 版本，而 `istioctl analysis` 可以用于较早的版本。
|
||||
- 尽管可以轻松查看特定资源的问题所在，但要在网格中全面了解验证状态更加困难。
|
||||
|
||||
您可以通过以下方式启用此功能：
|
||||
|
|
@ -203,4 +203,4 @@ $ kubectl annotate deployment my-deployment galley.istio.io/analyze-suppress=IST
|
|||
|
||||
{{< text bash >}}
|
||||
$ kubectl annotate deployment my-deployment galley.istio.io/analyze-suppress=IST0107,IST0002
|
||||
{{< /text >}}
|
||||
{{< /text >}}
|
||||
|
|
|
|||
|
|
@ -161,7 +161,7 @@ $ kubectl apply -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
|
|||
## 验证流量路由{#verifying-traffic-routes}
|
||||
|
||||
`istioctl describe` 命令还可以展示流量的分隔权重。
|
||||
例如，运行如下命令将 90% 的流量路由到 `revis` 服务的 `v1` 子集，将10% 路由到 `v2` 子集：
|
||||
例如，运行如下命令将 90% 的流量路由到 `revis` 服务的 `v1` 子集，将 10% 路由到 `v2` 子集：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-90-10.yaml@
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ $ istioctl proxy-config endpoints <pod-name> [flags]
|
|||
|
||||
{{< tab name="macOS" category-value="macos" >}}
|
||||
|
||||
如果您使用的是 macOS 操作系统的Bash终端，确认已安装 `bash-completion` 包。使用 macOS 下 [brew](https://brew.sh) 包管理器，您可以通过以下命令检查 `bash-completion` 包是否已经安装：
|
||||
如果您使用的是 macOS 操作系统的 Bash 终端，确认已安装 `bash-completion` 包。使用 macOS 下 [brew](https://brew.sh) 包管理器，您可以通过以下命令检查 `bash-completion` 包是否已经安装：
|
||||
|
||||
{{< text bash >}}
|
||||
$ brew info bash-completion
|
||||
|
|
@ -140,7 +140,7 @@ $ brew install bash-completion
|
|||
|
||||
安装 bash 自动补全文件
|
||||
|
||||
如果您使用 bash，`istioctl` 自动补全的文件位于 `tools` 目录。通过复制 `istioctl.bash` 文件到您的 home 目录，然后添加下行内容到您的 `.bashrc` 文件执行 `istioctl` tab补全文件：
|
||||
如果您使用 bash，`istioctl` 自动补全的文件位于 `tools` 目录。通过复制 `istioctl.bash` 文件到您的 home 目录，然后添加下行内容到您的 `.bashrc` 文件执行 `istioctl` tab 补全文件：
|
||||
|
||||
{{< text bash >}}
|
||||
$ source ~/istioctl.bash
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Istio 提供了两个非常有价值的命令来帮助诊断流量管理配置
|
|||
如果您想尝试以下的命令，需要：
|
||||
|
||||
* 有一个安装了 Istio 和 Bookinfo 应用的 Kubernetes 集群（正如在
|
||||
[安装步骤](/zh/docs/setup/getting-started/) 和
|
||||
[安装步骤](/zh/docs/setup/getting-started/)和
|
||||
[Bookinfo 安装步骤](/zh/docs/examples/bookinfo/#deploying-the-application)所描述的那样）。
|
||||
|
||||
或者
|
||||
|
|
|
|||
|
|
@ -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 配置状态的丰富分析，以便标识无效或次优的配置。这是此分析可能产生的错误或警告消息的列表。
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ object "my-namespace/my-policy" specifies Plaintext.
|
|||
|
||||
* 修改策略资源 `my-namespace/my-policy` 以将双向 TLS 作为身份验证模式。
|
||||
通常，可以通过在资源中添加一个 `peer` 属性来实现，其子属性为 `mtls`。您可以在
|
||||
[策略对象参考](/zh/docs/reference/config/security/istio.authentication.v1alpha1/#Policy) 中阅读有关策略对象的更多信息。
|
||||
[策略对象参考](/zh/docs/reference/config/security/istio.authentication.v1alpha1/#Policy)中阅读有关策略对象的更多信息。
|
||||
* 修改目标规则 `istio-system/default-rule`，删除 `ISTIO_MUTUAL` 以不使用双向 TLS。
|
||||
请注意，`default-rule` 在 `istio-system` 命名空间中，
|
||||
默认情况下 `istio-system` 命名空间被认为是配置的根命名空间（尽管可以通过资源中的 `rootNamespace` 属性来覆盖它）。
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: PortNameIsNotUnderNamingConvention
|
|||
layout: analysis-message
|
||||
---
|
||||
|
||||
当端口不遵循 [Istio 服务端口命名约定](/zh/docs/ops/deployment/requirements/) 或端口未命名时，会出现此消息。
|
||||
当端口不遵循 [Istio 服务端口命名约定](/zh/docs/ops/deployment/requirements/)或端口未命名时，会出现此消息。
|
||||
|
||||
## 示例{#example}
|
||||
|
||||
|
|
|
|||
|
|
@ -20,4 +20,4 @@ title: Analyzer Message Format
|
|||
Error [IST0101] (VirtualService httpbin.default) Referenced gateway not found: "httpbin-gateway-bogus"
|
||||
{{< /text >}}
|
||||
|
||||
包含详细描述的 `<message-details>` 字段也许可以帮你进一步解决问题,对于集群范围的资源，例如 `namespace`，将省略其后缀。
|
||||
包含详细描述的 `<message-details>` 字段也许可以帮你进一步解决问题, 对于集群范围的资源，例如 `namespace`，将省略其后缀。
|
||||
|
|
|
|||
|
|
@ -218,9 +218,9 @@ $ istioctl manifest generate ... --set values.global.mtls.enabled=true
|
|||
| `global.proxy.logLevel` | `""` | `代理的日志级别，应用于网关和 sidecars。如果为空，则使用 "warning"。期望值是：trace\|debug\|info\|warning\|error\|critical\|off` |
|
||||
| `global.proxy.componentLogLevel` | `""` | `每个组件的代理日志级别，应用于网关和 sidecars。如果组件级别没设置，全局的 "logLevel" 将启用。如果为空，"misc:error" 将启用` |
|
||||
| `global.proxy.dnsRefreshRate` | `300s` | `配置类型为 STRICT_DNS 的 Envoy 集群的 DNS 刷新率，必须以秒为单位。例如：300s 是合法的但 5m 不合法。` |
|
||||
| `global.proxy.protocolDetectionTimeout` | `10ms` | `自动协议检测使用一组试探法来确定连接是否使用TLS（服务端），以及正在使用的应用程序协议（例如 http 和 tcp）。 试探法依赖于客户端发送的第一个数据位。对于像 Mysql，MongoDB 这样的服务器的第一协议来说，在指定的时间段之后，Envoy 将对协议检测超时，默认为非 mTLS 的 TCP 流量。设置此字段以调整 Envoy 将等待客户端发送第一个数据位的时间。（必须 >=1ms）` |
|
||||
| `global.proxy.protocolDetectionTimeout` | `10ms` | `自动协议检测使用一组试探法来确定连接是否使用 TLS（服务端），以及正在使用的应用程序协议（例如 http 和 tcp）。 试探法依赖于客户端发送的第一个数据位。对于像 Mysql，MongoDB 这样的服务器的第一协议来说，在指定的时间段之后，Envoy 将对协议检测超时，默认为非 mTLS 的 TCP 流量。设置此字段以调整 Envoy 将等待客户端发送第一个数据位的时间。（必须 >=1ms）` |
|
||||
| `global.proxy.privileged` | `false` | `如果设置为 true，istio-proxy 容器将享有 securityContext 的权限。` |
|
||||
| `global.proxy.enableCoreDump` | `false` | `如果设置，新注入的sidecars将启用 core dumps。` |
|
||||
| `global.proxy.enableCoreDump` | `false` | `如果设置，新注入的 sidecars 将启用 core dumps。` |
|
||||
| `global.proxy.enableCoreDumpImage` | `ubuntu:xenial` | `镜像用于开启 core dumps。仅在 "enableCoreDump" 设置为 true 时使用。` |
|
||||
| `global.proxy.statusPort` | `15020` | `Pilot 代理健康检查的默认端口。值为 0 将关闭健康检查。` |
|
||||
| `global.proxy.readinessInitialDelaySeconds` | `1` | `readiness 探针的初始延迟秒数。` |
|
||||
|
|
@ -240,7 +240,7 @@ $ istioctl manifest generate ... --set values.global.mtls.enabled=true
|
|||
| `global.proxy.envoyMetricsService.host` | `` | `例：metrics-service.istio-system` |
|
||||
| `global.proxy.envoyMetricsService.port` | `` | `例：15000` |
|
||||
| `global.proxy.tracer` | `"zipkin"` | `指定使用以下哪一个追踪器：zipkin，lightstep， datadog，stackdriver。 如果使用外部 GCP 的 stackdriver 追踪器，设置环境变量 GOOGLE_APPLICATION_CREDENTIALS 为 GCP 的凭证文件。` |
|
||||
| `global.proxy_init.image` | `proxy_init` | `proxy_init 容器的基本名称，用于配置iptables。` |
|
||||
| `global.proxy_init.image` | `proxy_init` | `proxy_init 容器的基本名称，用于配置 iptables。` |
|
||||
| `global.imagePullPolicy` | `IfNotPresent` | |
|
||||
| `global.controlPlaneSecurityEnabled` | `false` | `启用 controlPlaneSecurityEnabled enabled。当密钥被传输时，将导致启动 pod 的延迟，不建议用于测试。` |
|
||||
| `global.disablePolicyChecks` | `true` | `disablePolicyChecks 关闭 mixer 策略检查。如果 mixer.policy.enabled==true 那么 disablePolicyChecks 生效。当在 istio config map 中设置此值时 —— pilot 需要重启才能生效。` |
|
||||
|
|
@ -271,7 +271,7 @@ $ istioctl manifest generate ... --set values.global.mtls.enabled=true
|
|||
| `global.trustDomain` | `""` | |
|
||||
| `global.meshID` | `""` | `Mesh ID 意为 Mesh 标识符。在网格相互作用的范围内，它应该是唯一的，但不要求它是全局/普遍唯一的。例如，如果下面条件任意一个为真，那么两个网格必须有不同的 Mesh ID：—— 网格将遥测聚合在一个地方 —— 网格将连接在一起 —— 如果管理员期望这些条件中的任何一个在将来可能成为现实，那么策略将被从一个网格写入到另一个引用它的网格，他们需要保证这些网格被指定了不同的 Mesh ID。在一个多集群网格下，每一个集群必须（手动或自动）配置相同的 Mesh ID。如果一个存在的集群“加入”多集群网格，它需要被迁移到新的 mesh ID。详细的迁移还在制定中，在安装后更改 Mesh ID 可能会造成混乱。如果这个网格没有指定一个特定值，Istio 将使用该网格信任域的值。最佳实践是选择适当的信任域值。` |
|
||||
| `global.outboundTrafficPolicy.mode` | `ALLOW_ANY` | |
|
||||
| `global.sds.enabled` | `false` | `启用 SDS。如果设置为 true，sidecars 的 mTLS 证书将通过 SecretDiscoveryService 分发，而不是使用 K8S secret来挂载。` |
|
||||
| `global.sds.enabled` | `false` | `启用 SDS。如果设置为 true，sidecars 的 mTLS 证书将通过 SecretDiscoveryService 分发，而不是使用 K8S secret 来挂载。` |
|
||||
| `global.sds.udsPath` | `""` | |
|
||||
| `global.meshNetworks` | `{}` | |
|
||||
| `global.localityLbSetting.enabled` | `true` | |
|
||||
|
|
@ -345,7 +345,7 @@ $ istioctl manifest generate ... --set values.global.mtls.enabled=true
|
|||
|
||||
| 关键字 | 默认值 | 描述 |
|
||||
| --- | --- | --- |
|
||||
| `kiali.enabled` | `false` | `注意当通过 Helm 安装，使用 demo yaml时，默认值为 true。` |
|
||||
| `kiali.enabled` | `false` | `注意当通过 Helm 安装，使用 demo yaml 时，默认值为 true。` |
|
||||
| `kiali.replicaCount` | `1` | |
|
||||
| `kiali.hub` | `quay.io/kiali` | |
|
||||
| `kiali.image` | `kiali` | |
|
||||
|
|
@ -393,7 +393,7 @@ $ istioctl manifest generate ... --set values.global.mtls.enabled=true
|
|||
| `mixer.telemetry.rollingMaxUnavailable` | `25%` | |
|
||||
| `mixer.telemetry.sessionAffinityEnabled` | `false` | |
|
||||
| `mixer.telemetry.loadshedding.mode` | `enforce` | `disabled，logonly 或 enforce` |
|
||||
| `mixer.telemetry.loadshedding.latencyThreshold` | `100ms` | `根据测量值把100ms p50 转换成 1s 以下的 p99。这对于本质上是异步的遥测来说是可以接受的。` |
|
||||
| `mixer.telemetry.loadshedding.latencyThreshold` | `100ms` | `根据测量值把 100ms p50 转换成 1s 以下的 p99。这对于本质上是异步的遥测来说是可以接受的。` |
|
||||
| `mixer.telemetry.resources.requests.cpu` | `1000m` | |
|
||||
| `mixer.telemetry.resources.requests.memory` | `1G` | |
|
||||
| `mixer.telemetry.resources.limits.cpu` | `4800m` | `最好使用适当的 cpu 分配来实现 Mixer 的水平扩展。我们已经通过实验发现这些数值工作的很好。` |
|
||||
|
|
@ -482,7 +482,7 @@ $ istioctl manifest generate ... --set values.global.mtls.enabled=true
|
|||
| `security.replicaCount` | `1` | |
|
||||
| `security.rollingMaxSurge` | `100%` | |
|
||||
| `security.rollingMaxUnavailable` | `25%` | |
|
||||
| `security.enableNamespacesByDefault` | `true` | `确定名称空间没有被密钥创建的 Citadel 标记 ca.istio.io/env 和ca.istio.io/override 标签。` |
|
||||
| `security.enableNamespacesByDefault` | `true` | `确定名称空间没有被密钥创建的 Citadel 标记 ca.istio.io/env 和 ca.istio.io/override 标签。` |
|
||||
| `security.image` | `citadel` | |
|
||||
| `security.selfSigned` | `true` | `表明自签名 CA 是否使用。` |
|
||||
| `security.createMeshPolicy` | `true` | |
|
||||
|
|
@ -490,7 +490,7 @@ $ istioctl manifest generate ... --set values.global.mtls.enabled=true
|
|||
| `security.tolerations` | `[]` | |
|
||||
| `security.citadelHealthCheck` | `false` | |
|
||||
| `security.workloadCertTtl` | `2160h` | `90*24 小时 = 2160h` |
|
||||
| `security.enableNamespacesByDefault` | `true` | `指定 Citadel 的默认行为，如果ca.istio.io/env 或 ca.istio.io/override 标签没有在给定的命名空间发现。例如：考虑一个叫 "target" 的命名空间，既没有 "ca.istio.io/env" 也没有 "ca.istio.io/override" 标签。决定是否为这个 “target” 命名空间的服务账号创建密钥，Citadel 讲参考这一选项。在这个例子中如果值为 "true"，密钥将为 "target" 命名空间生成。如果值是 "false"，Citadel 不会在创建服务账户时产生密钥。` |
|
||||
| `security.enableNamespacesByDefault` | `true` | `指定 Citadel 的默认行为，如果 ca.istio.io/env 或 ca.istio.io/override 标签没有在给定的命名空间发现。例如：考虑一个叫 "target" 的命名空间，既没有 "ca.istio.io/env" 也没有 "ca.istio.io/override" 标签。决定是否为这个 “target” 命名空间的服务账号创建密钥，Citadel 讲参考这一选项。在这个例子中如果值为 "true"，密钥将为 "target" 命名空间生成。如果值是 "false"，Citadel 不会在创建服务账户时产生密钥。` |
|
||||
| `security.podAntiAffinityLabelSelector` | `[]` | |
|
||||
| `security.podAntiAffinityTermLabelSelector` | `[]` | |
|
||||
|
||||
|
|
@ -546,4 +546,4 @@ $ istioctl manifest generate ... --set values.global.mtls.enabled=true
|
|||
| `tracing.service.name` | `http` | |
|
||||
| `tracing.service.type` | `ClusterIP` | |
|
||||
| `tracing.service.externalPort` | `9411` | |
|
||||
| `tracing.ingress.enabled` | `false` | |
|
||||
| `tracing.ingress.enabled` | `false` | |
|
||||
|
|
|
|||
|
|
@ -15,4 +15,4 @@ aliases:
|
|||
|
||||
下表显示了由每个支持的适配器实现的[模板](/zh/docs/reference/config/policy-and-telemetry/templates)。
|
||||
|
||||
{{< adapter_table >}}
|
||||
{{< adapter_table >}}
|
||||
|
|
|
|||
|
|
@ -10,8 +10,8 @@ aliases:
|
|||
|
||||
## 底层{#background}
|
||||
|
||||
Mixer 配置使用了一种表达式语言(CEXL)去描述 match expressions 以及 [mapping expressions](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#attribute-expressions)。
|
||||
CEXL 表达式为有类型的[值](https://github.com/istio/api/blob/{{< source_branch_name >}}/policy/v1beta1/value_type.proto)映射了一组带类型的[属性](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes)和常量。
|
||||
Mixer 配置使用了一种表达式语言(CEXL) 去描述 match expressions 以及 [mapping expressions](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#attribute-expressions)。
|
||||
CEXL 表达式为有类型的[值](https://github.com/istio/api/blob/{{<source_branch_name >}}/policy/v1beta1/value_type.proto) 映射了一组带类型的[属性](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes)和常量。
|
||||
|
||||
## 语法{#syntax}
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ description: 通过 Mixer 从 Istio 导出的默认监控指标。
|
|||
weight: 50
|
||||
---
|
||||
|
||||
此页面展示使用初始配置时，Istio 收集的监控指标（metrics）的详细信息。这些指标是内置的，但您可以随时通过更改配置来添加和删除它们。您可以在[这个文件]({{< github_file >}}/manifests/UPDATING-CHARTS.md)的 "kind: metric” 小节中找到它们。它使用了 [metric 模板](/zh/docs/reference/config/policy-and-telemetry/templates/metric/)来定义指标。
|
||||
此页面展示使用初始配置时，Istio 收集的监控指标（metrics）的详细信息。这些指标是内置的，但您可以随时通过更改配置来添加和删除它们。您可以在[这个文件]({{<github_file >}}/manifests/UPDATING-CHARTS.md) 的 "kind: metric” 小节中找到它们。它使用了 [metric 模板](/zh/docs/reference/config/policy-and-telemetry/templates/metric/)来定义指标。
|
||||
|
||||
我们将首先描述监控指标，然后描述每个指标的标签。
|
||||
|
||||
|
|
@ -134,7 +134,7 @@ Istio 为 HTTP、HTTP/2 和 GRPC 流量创建了下列指标：
|
|||
connection_security_policy: conditional((context.reporter.kind | "inbound") == "outbound", "unknown", conditional(connection.mtls | false, "mutual_tls", "none"))
|
||||
{{< /text >}}
|
||||
|
||||
* **Response Flags**: 来自代理服务器，包含了响应或者连接的额外细节。如果是 Envoy 代理，可以参考 [Envoy 访问日志](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log#configuration) 中的 `%RESPONSE_FLAGS%` 相关说明。
|
||||
* **Response Flags**: 来自代理服务器，包含了响应或者连接的额外细节。如果是 Envoy 代理，可以参考 [Envoy 访问日志](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log#configuration)中的 `%RESPONSE_FLAGS%` 相关说明。
|
||||
|
||||
{{< text yaml >}}
|
||||
response_flags: context.proxy_error_code | "-"
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ Mixer 处理不同基础架构后端的灵活性来自其通用插件模型。
|
|||
caption="Mixer and its Adapters"
|
||||
>}}
|
||||
|
||||
了解有关[适配器支持](/zh/docs/reference/config/policy-and-telemetry/adapters/) 的更多信息。
|
||||
了解有关[适配器支持](/zh/docs/reference/config/policy-and-telemetry/adapters/)的更多信息。
|
||||
|
||||
## 属性{#attributes}
|
||||
|
||||
|
|
@ -72,11 +72,11 @@ Mixer 本质上是一种属性处理器。Envoy sidecar 为每个请求调用 Mi
|
|||
|
||||
给定的 Istio deployment 具有它了解的固定属性词汇表。该特定词汇表由 deployment 中使用的一组属性生成器确定。尽管专用的 Mixer 适配器也可以生成属性，但 Istio 中主要的属性生成器是 Envoy。
|
||||
|
||||
了解有关 [Istio 中大多数部署可用的通用基准属性集](/zh/docs/reference/config/policy-and-telemetry/attribute-vocabulary/) 的更多信息。
|
||||
了解有关 [Istio 中大多数部署可用的通用基准属性集](/zh/docs/reference/config/policy-and-telemetry/attribute-vocabulary/)的更多信息。
|
||||
|
||||
### 属性表达式{#attribute-expressions}
|
||||
|
||||
当配置[实例](#instances) 时需要使用使用属性表达式。
|
||||
当配置[实例](#instances)时需要使用使用属性表达式。
|
||||
这是一个使用表达式的示例：
|
||||
|
||||
{{< text yaml >}}
|
||||
|
|
@ -95,7 +95,7 @@ destination_version: destination.labels["version"] | "unknown"
|
|||
|
||||
通过上述操作，`destination_version` 标签被分配的值为 `destination.labels["version"]`。 但是，如果属性不存在，将使用 `"unknown"` 值。
|
||||
|
||||
有关更多信息，请参阅[属性表达式](/zh/docs/reference/config/policy-and-telemetry/expression-language/) 页面。
|
||||
有关更多信息，请参阅[属性表达式](/zh/docs/reference/config/policy-and-telemetry/expression-language/)页面。
|
||||
|
||||
## 配置模型{#configuration-model}
|
||||
|
||||
|
|
@ -121,7 +121,7 @@ Rules 由 *match* 表达式和 *actions* 组成。该匹配表达式控制何时
|
|||
### Handlers{#handlers}
|
||||
|
||||
适配器封装了 Mixer 与特定的外部基础结构后端例如 [Prometheus](https://prometheus.io) 或 [Stackdriver](https://cloud.google.com/logging) 交互所需的逻辑。
|
||||
_handler_ 是负责保存适配器所需的配置状态的资源。例如，一个日志适配器可能需要日志收集后端的IP地址和端口。
|
||||
_handler_ 是负责保存适配器所需的配置状态的资源。例如，一个日志适配器可能需要日志收集后端的 IP 地址和端口。
|
||||
|
||||
这是一个示例，显示了如何为适配器创建 handler。`listchecker` 适配器对照列表检查输入值。
|
||||
如果将适配器配置为白名单，则在列表中找到输入值时，它将返回成功。
|
||||
|
|
@ -173,7 +173,7 @@ spec:
|
|||
bounds: [0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10]
|
||||
{{< /text >}}
|
||||
|
||||
每个适配器定义自己的特定格式的配置数据。了解更多有关[全部适配器及其特定的配置格式](/zh/docs/reference/config/policy-and-telemetry/adapters/) 的信息。
|
||||
每个适配器定义自己的特定格式的配置数据。了解更多有关[全部适配器及其特定的配置格式](/zh/docs/reference/config/policy-and-telemetry/adapters/)的信息。
|
||||
|
||||
### Instances{#instances}
|
||||
|
||||
|
|
@ -198,7 +198,7 @@ spec:
|
|||
{{< /text >}}
|
||||
|
||||
请注意，需要在映射中指定了处理程序配置中期望的所有情况。
|
||||
模板定义了各个实例的特定必需内容。了解更多关于[模板及其特定的配置格式](/zh/docs/reference/config/policy-and-telemetry/templates/) 的信息。
|
||||
模板定义了各个实例的特定必需内容。了解更多关于[模板及其特定的配置格式](/zh/docs/reference/config/policy-and-telemetry/templates/)的信息。
|
||||
|
||||
### Rules{#rules}
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ RBAC 策略中的约束和属性已经被 `AuthorizationPolicy` 中的条件取
|
|||
不支持的键和值将被忽略。
|
||||
{{< /warning >}}
|
||||
|
||||
有关更多信息，请参阅 [授权概念页面](/zh/docs/concepts/security/#authorization)。
|
||||
有关更多信息，请参阅[授权概念页面](/zh/docs/concepts/security/#authorization)。
|
||||
|
||||
## 支持的约束{#supported-constraints}
|
||||
|
||||
|
|
|
|||
|
|
@ -13,4 +13,4 @@ source.ip: 192.168.0.1
|
|||
destination.workload.name: example
|
||||
{{< /text >}}
|
||||
|
||||
属性被 Istio 的 [策略和遥测](/zh/docs/reference/config/policy-and-telemetry/) 功能所使用。
|
||||
属性被 Istio 的[策略和遥测](/zh/docs/reference/config/policy-and-telemetry/)功能所使用。
|
||||
|
|
|
|||
|
|
@ -25,4 +25,4 @@ Istio 在不同的平台上支持以下服务身份：
|
|||
- 本地 （非 Kubernetes）：用户账户、客户服务账户、服务名称、Istio 服务账户，或者 GCP 服务账户。
|
||||
客户服务账户指现有的服务账户，就像客户身份目录中管理的身份。
|
||||
|
||||
通常，[信任域](/zh/docs/reference/glossary/#trust-domain) 指定身份所属的网格。
|
||||
通常，[信任域](/zh/docs/reference/glossary/#trust-domain)指定身份所属的网格。
|
||||
|
|
|
|||
|
|
@ -2,5 +2,5 @@
|
|||
title: Managed Control Plane
|
||||
---
|
||||
|
||||
托管控制平面是一个为客户提供管理的 [控制平面](/zh/docs/reference/glossary/#control-plane)。
|
||||
托管控制平面是一个为客户提供管理的[控制平面](/zh/docs/reference/glossary/#control-plane)。
|
||||
托管控制平面降低了用户部署的复杂性，并通常保证一定水平的性能和可用性。
|
||||
|
|
|
|||
|
|
@ -3,4 +3,4 @@ title: Mesh Federation
|
|||
---
|
||||
|
||||
网格联邦是在网格之间公开服务的一种行为，并且能跨越网格边界进行通信。每一个网格或许会公开其一部分的服务，使一个或多个其他网格使用此公开的服务。
|
||||
您可以使用网格联邦来启用网格之间的通信，可参阅 [多个网格部署](/zh/docs/ops/deployment/deployment-models/#multiple-meshes)。
|
||||
您可以使用网格联邦来启用网格之间的通信，可参阅[多个网格部署](/zh/docs/ops/deployment/deployment-models/#multiple-meshes)。
|
||||
|
|
|
|||
|
|
@ -4,4 +4,4 @@ title: Multi-Mesh
|
|||
|
||||
Multi-mesh 是由两个或多个[服务网格](/zh/docs/reference/glossary/#service-mesh)组成的部署模型。
|
||||
每个网格都有独立的命名管理和身份管理，但是您可以通过[网格联邦](/zh/docs/reference/glossary/#mesh-federation)来暴露
|
||||
网格之间的服务,最终构成一个多网格部署。
|
||||
网格之间的服务, 最终构成一个多网格部署。
|
||||
|
|
|
|||
|
|
@ -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)组成。
|
||||
|
|
|
|||
|
|
@ -3,4 +3,4 @@ title: Pod
|
|||
---
|
||||
Pod 中包含了一个或多个共享存储和网络的容器 （例如 [Docker](https://www.docker.com/) 容器），
|
||||
以及如何运行容器的规范。
|
||||
Pod 是 Istio 的 [Kubernetes](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) 部署中的一个 [工作负载实例](#workload-instance)。
|
||||
Pod 是 Istio 的 [Kubernetes](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) 部署中的一个[工作负载实例](#workload-instance)。
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Routing Rules
|
||||
---
|
||||
您在 [虚拟服务](/zh/docs/concepts/traffic-management/#virtual-services) 中配置的路由规则，遵循服务网格定义了请求的路径。
|
||||
您在[虚拟服务](/zh/docs/concepts/traffic-management/#virtual-services)中配置的路由规则，遵循服务网格定义了请求的路径。
|
||||
使用路由规则，您可以定义将寻址到虚拟服务主机的流量路由到指定目标的工作负载。
|
||||
路由规则使您可以控制流量，以实现如 A/B 测试、金丝雀发布以及按百分比分配流量的分阶段发布等任务。
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
---
|
||||
title: Service Endpoint
|
||||
---
|
||||
Service Endpoint 是一个 [service](#service) 的网络可达表现形式。Service endpoint 由 [工作负载实例](#workload-instance) 暴露，但并不是所有的服务都有 service endpoint。
|
||||
Service Endpoint 是一个 [service](#service) 的网络可达表现形式。Service endpoint 由[工作负载实例](#workload-instance)暴露，但并不是所有的服务都有 service endpoint。
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
---
|
||||
title: Service Producer
|
||||
---
|
||||
创建[服务](#service)的 pilot-agent。
|
||||
创建[服务](#service)的 pilot-agent。
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
---
|
||||
title: Service Version
|
||||
---
|
||||
区分一系列[服务](#service)，通常通过 [工作负载](#workload) 二进制文件的不同版本来帮助确定。在一些场景多服务版本是需要的，比如 A/B 测试和金丝雀发布。
|
||||
区分一系列[服务](#service)，通常通过[工作负载](#workload)二进制文件的不同版本来帮助确定。在一些场景多服务版本是需要的，比如 A/B 测试和金丝雀发布。
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: Service
|
||||
---
|
||||
使用 [服务名称](#service-name)标识一组具有关联行为的服务 [服务网格](#service-mesh)，
|
||||
使用[服务名称](#service-name)标识一组具有关联行为的服务[服务网格](#service-mesh)，
|
||||
并使用这些名称应用 Istio 策略（例如负载均衡和路由）。
|
||||
服务通常由一个或多个 [服务 Endpoint](#service-endpoint)实现，并且或许包含多个
|
||||
服务通常由一个或多个[服务 Endpoint](#service-endpoint) 实现，并且或许包含多个
|
||||
[服务版本](#service-version)。
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue