Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[zh] Update overview/dataplane-modes/index.md #16005

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

[zh] Update overview/dataplane-modes/index.md #16005

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
65 changes: 34 additions & 31 deletions content/zh/docs/overview/dataplane-modes/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,36 +10,39 @@ test: n/a
Istio 服务网格在逻辑上分为数据平面和控制平面。

{{< gloss "data plane" >}}数据平面{{< /gloss >}}是一组代理，用于调解和控制微服务之间的所有网络通信。
它们还收集和报告所有网格流量的可观测数据。
这些代理还可以收集和报告所有网格流量的可观测数据。

{{< gloss "control plane" >}}控制平面{{< /gloss >}}管理和配置数据平面中的代理。
{{< gloss "control plane" >}}控制平面{{< /gloss >}}管理和配置数据平面中的这些代理。

Istio 支持两种主要的{{< gloss "data plane mode">}}数据平面模式{{< /gloss >}}：

* **Sidecar 模式**，它会与您在集群中启动的每个 Pod 一起部署一个 Envoy 代理，或者与在虚拟机上运行的服务一同运行。
* **Ambient 模式**，使用每个节点的四层代理，并且可选地使用每个命名空间的 Envoy 代理来实现七层功能。
* **Sidecar 模式**，此模式会为集群中启动的每个 Pod 都部署一个 Envoy 代理，
或者与在虚拟机上运行的服务并行运行一个 Envoy 代理。
* **Ambient 模式**，此模式在每个节点上使用四层代理，
另外可以选择为每个命名空间使用一个 Envoy 代理来实现七层功能。

您可以选择将某些命名空间或工作负载纳入任意模式。
您可以选择将某些命名空间或工作负载纳入任一模式。

## Sidecar 模式 {#sidecar=mode}

Istio 自 2017 年首次发布以来就基于 Sidecar 模式构建。
Sidecar 模式易于理解且经过彻底的实战测试，但需要花费资源成本和运营开销。

* 您部署的每个应用程序都有一个 Envoy 代理{{< gloss "injection" >}}被注入{{< /gloss >}}作为 Sidecar
* 您部署的每个应用都有一个 Envoy 代理{{< gloss "injection" >}}被注入{{< /gloss >}}作为 Sidecar
* 所有代理都可以处理四层和七层流量

## Ambient 模式 {#ambient-mode}

Ambient 模式于 2022 年推出，旨在解决 Sidecar 模式用户报告的缺点。从 Istio 1.22 开始，它已准备好用于单集群用例的生产环境。
Ambient 模式于 2022 年推出，旨在解决 Sidecar 模式用户报告的缺点。
从 Istio 1.22 开始，它在单集群使用场景就达到生产就绪状态。

* 所有流量都通过仅支持四层的节点代理进行代理
* 应用程序可以选择通过 Envoy 代理进行路由，以获得七层功能
* 应用可以选择通过 Envoy 代理进行路由，以获得七层功能

## 在 Sidecar 和 Ambient 之间进行选择 {#choosing-between-sidecar-and-ambient}
## 在 Sidecar 和 Ambient 之间做出选择 {#choosing-between-sidecar-and-ambient}

用户通常首先部署网格以实现零信任安全态势，然后根据需要选择性地启用 L7 功能。
Ambient 网格允许这些用户在不需要时完全绕过 L7 处理的成本。
Ambient 网格允许这些用户在不需要 L7 功能时完全绕过 L7 处理的成本。

<table>
<thead>
Expand All @@ -63,7 +66,7 @@ Ambient 网格允许这些用户在不需要时完全绕过 L7 处理的成本
<tr>
<th>可观测性</th>
<td>完整的 Istio 功能集</td>
<td>完整的 Istio 功能集：Ambient 模式下具备 L4 可观测；使用 waypoint 实现 L7 可观察性</td>
<td>完整的 Istio 功能集：Ambient 模式下具备 L4 遥测；使用 waypoint 实现 L7 可观测性</td>
</tr>
<tr>
<th>可扩展性</th>
Expand All @@ -72,23 +75,23 @@ Ambient 网格允许这些用户在不需要时完全绕过 L7 处理的成本
</tr>
<tr>
<th>向网格添加工作负载</th>
<td>标记命名空间并重新启动所有 Pod 以添加 Sidecar</td>
<td>标记命名空间 - 无需重启 Pod</td>
<td>为命名空间添加标签并重启所有 Pod 以添加 Sidecar</td>
<td>为命名空间添加标签 - 无需重启 Pod</td>
</tr>
<tr>
<th>增量部署</th>
<th>递增式部署</th>
<td>二进制：Sidecar 是否已被注入</td>
<td>渐进式：L4 始终开启，L7 可通过配置添加</td>
</tr>
<tr>
<th>生命周期管理</th>
<td>代理由应用程序开发人员管理</td>
<td>代理由应用开发人员管理</td>
<td>平台管理员</td>
</tr>
<tr>
<th>资源利用</th>
<td>浪费；必须为每个单独的 Pod 的最坏情况配置 CPU 和内存资源</td>
<td>waypoint 代理可以像任何其他 Kubernetes 部署一样自动扩展。<br>具有多个副本的工作负载可以使用同一个 waypoint，而不是每个副本都有自己的边车。</td>
<th>资源利用率</th>
<td>浪费；必须考虑到每个单独 Pod 的最糟情况并配置最大的 CPU 和内存资源</td>
<td>waypoint 代理可以像任何其他 Kubernetes Deployment 一样自动扩缩容。<br>有多个副本的工作负载可以使用同一个 waypoint，而不是每个副本都有自己的 Sidecar。</td>
</tr>
<tr>
<th>平均资源成本</th>
Expand Down Expand Up @@ -126,7 +129,7 @@ Ambient 网格允许这些用户在不需要时完全绕过 L7 处理的成本
<td>强：每个节点代理仅具有该节点上工作负载的密钥</td>
</tr>
<tr>
<th>被入侵的应用程序 Pod<br>可访问网格密钥</th>
<th>被入侵的应用 Pod<br>可访问网格密钥</th>
<td>可以</td>
<td>不可以</td>
</tr>
Expand All @@ -146,7 +149,7 @@ Ambient 网格允许这些用户在不需要时完全绕过 L7 处理的成本
## 四层与七层功能 {#layer-4-vs-layer-7-features}

在七层处理协议的开销远远高于在四层处理网络数据包的开销。
对于给定的服务，如果您的要求可以在 L4 满足，则可以以更低的成本提供服务网格。
对于给定的服务，如果您的要求可以在 L4 被满足，则可以以明显更低的成本交付服务网格。

### 安全 {#security}

Expand All @@ -161,25 +164,25 @@ Ambient 网格允许这些用户在不需要时完全绕过 L7 处理的成本
<tbody>
<tr>
<th>加密</th>
<td>所有 Pod 之间的流量都使用 {{< gloss "mutual tls authentication" >}}mTLS{{< /gloss >}} 加密.</td>
<td>所有 Pod 之间的流量都使用 {{< gloss "mutual tls authentication" >}}mTLS{{< /gloss >}} 加密。</td>
<td>不适用；Istio 中的服务身份基于 TLS。</td>
</tr>
<tr>
<th>服务到服务的身份验证</th>
<td>{{< gloss >}}SPIFFE{{< /gloss >}}，通过 mTLS 证书。Istio 颁发一个短期 X.509 证书，该证书对 Pod 的服务帐户身份进行编码。</td>
<td>通过 mTLS 证书执行 {{< gloss >}}SPIFFE{{< /gloss >}}。Istio 颁发一个短期 X.509 证书，对 Pod 的服务帐户身份进行编码。</td>
<td>不适用；Istio 中的服务身份基于 TLS。</td>
</tr>
<tr>
<th>服务到服务的鉴权</th>
<td>基于网络的鉴权，加上基于身份的策略，例如：
<ul>
<li>A 只能接受来自“10.2.0.0/16”的入站呼叫；</li>
<li>A 只能接受来自“10.2.0.0/16”的入站调用；</li>
<li>A 可以调用 B。</li>
</ul>
</td>
<td>完整政策，例如：
<ul>
<li>只有使用包含 READ 范围的有效最终用户凭据，A 才能在 B 上执行 GET /foo 操作。</li>
<li>只有使用包含 READ 范围的有效最终用户凭证，A 才能在 B 上执行 GET /foo 操作。</li>
</ul>
</td>
</tr>
Expand All @@ -191,7 +194,7 @@ Ambient 网格允许这些用户在不需要时完全绕过 L7 处理的成本
<tr>
<th>最终用户鉴权</th>
<td>不适用；同上</td>
<td>可以扩展服务到服务的策略，以要求<a href="/zh/docs/reference/config/security/conditions/">具有特定范围、发行者、主体、受众等的最终用户凭证</a><br />可以使用外部鉴权实现完整的用户到资源访问，允许根据外部服务的决策制定每个请求的策略，例如 OPA。</td>
<td>可以扩展服务到服务的策略，以要求<a href="/zh/docs/reference/config/security/conditions/">具有特定范围、发行者、主体、受众等的最终用户凭证</a>。<br />可以使用外部鉴权，实现完整的用户到资源的访问，允许根据外部服务的决策来制定每个请求的策略，例如 OPA。</td>
</tr>
</tbody>
</table>
Expand Down Expand Up @@ -220,7 +223,7 @@ Ambient 网格允许这些用户在不需要时完全绕过 L7 处理的成本
<tr>
<th>指标</th>
<td>仅 TCP（发送/接收的字节数、数据包数量等）。</td>
<td>L7 RED 指标：请求率、错误率、请求持续时间（延迟）。</td>
<td>L7 RED 指标：请求率、错误率、请求时间（延迟）。</td>
</tr>
</tbody>
</table>
Expand All @@ -247,19 +250,19 @@ Ambient 网格允许这些用户在不需要时完全绕过 L7 处理的成本
<td>除了 TCP 之外，<a href="/zh/docs/reference/config/networking/destination-rule/#ConnectionPoolSettings-HTTPSettings">还有 HTTP 设置</a>。</td>
</tr>
<tr>
<th>异常值检测</th>
<th>离群值检测</th>
<td>当连接建立/失败时。</td>
<td>请求成功/失败。</td>
</tr>
<tr>
<th>限流</th>
<td><a href="https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/network_filters/rate_limit_filter#config-network-filters-rate-limit">仅在建立连接时对 L4 连接数据进行限流</a>，具有全局和本地限流选项。</td>
<td>使用全局限流选项和本地限流选项，<a href="https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/network_filters/rate_limit_filter#config-network-filters-rate-limit">仅在建立连接时对 L4 连接数据进行限流</a>。</td>
<td>根据每个请求，<a href="https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/rate_limit_filter#config-http-filters-rate-limit">L7 请求元数据的限流</a>。</td>
</tr>
<tr>
<th>超时</th>
<td>仅建立连接（通过断路设置来配置连接保持）。</td>
<td>根据要求。</td>
<td>仅建立连接（通过熔断设置来配置保持活跃的连接）。</td>
<td>按请求。</td>
</tr>
<tr>
<th>重试</th>
Expand All @@ -269,7 +272,7 @@ Ambient 网格允许这些用户在不需要时完全绕过 L7 处理的成本
<tr>
<th>故障注入</th>
<td>不适用；无法在 TCP 连接上配置故障注入。</td>
<td>完整的应用程序和连接级故障（<a href="/zh/docs/tasks/traffic-management/fault-injection/">超时、延迟、特定响应码</a>）。</td>
<td>完整的应用和连接级故障（<a href="/zh/docs/tasks/traffic-management/fault-injection/">超时、延迟、特定响应码</a>）。</td>
</tr>
<tr>
<th>流量镜像</th>
Expand Down
39 changes: 21 additions & 18 deletions content/zh/docs/overview/why-choose-istio/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,28 +9,29 @@ test: n/a

Istio 在 2017 年推出时率先提出了基于 Sidecar 的服务网格概念。
该项目从一开始就包含了定义服务网格的功能，包括用于零信任网络的基于标准的双向 TLS、
智能流量路由以及通过指标、日志和链路追踪实现的可观察性。
智能流量路由以及通过指标、日志和链路追踪实现的可观测性。

从那时起，该项目推动了网格领域的进步，
包括[多集群和多网络拓扑](/zh/docs/ops/deployment/deployment-models/)、
[通过 WebAssembly 实现可扩展性](/zh/docs/concepts/wasm/)、
[Kubernetes Gateway API 的开发](/zh/blog/2022/gateway-api-beta/)，
以及使用 [Ambient 模式](/zh/docs/ambient/overview/)将网格基础设施从应用程序开发人员手中移开。
以及使用 [Ambient 模式](/zh/docs/ambient/overview/)让应用开发者无需过多关注网格基础设施。

以下是我们认为您应该使用 Istio 作为服务网格的几个原因。

## 简单而强大 {#simple-and-powerful}

Kubernetes 有数百种功能和数十种 API，但您只需一个命令即可开始使用它。
Kubernetes 有数百种功能和数十种 API，但您只需一条命令即可开始使用这些。
我们构建 Istio 的方式也一样。渐进式公开意味着您可以使用一小部分 API，
并且仅在需要时才使用更强大的功能。其他“简单”服务网格花了数年时间才赶上 Istio 在第一天就拥有的功能集。
并且仅在需要时才使用更强大的功能。
其他“简单”服务网格花了数年时间才赶上 Istio 在第一天就拥有的这些功能集。

拥有一个功能而不需要它比需要而没有这项功能更加美好！
所谓有备无患，说的是有一个暂时不需要的功能，总好过需要时却没有。

## Envoy 代理 {#envoy}

从一开始，Istio 就由 {{< gloss >}}Envoy{{< /gloss >}} 代理提供支持，
这是一个最初由 Lyft 构建的高性能服务代理。Istio 是第一个采用 Envoy 的项目，
Envoy 是一个最初由 Lyft 构建的高性能服务代理。Istio 是第一个采用 Envoy 的项目，
[Istio 团队是第一批外部提交者](https://eng.lyft.com/envoy-7-months-later-41986c2fd443)。
Envoy 后来成为[为 Google Cloud 提供支持的负载均衡器](https://cloud.google.com/load-balancing/docs/https?hl=zh-cn)以及几乎所有其他服务网格平台的代理。

Expand All @@ -40,16 +41,16 @@ Istio 继承了 Envoy 的所有功能和灵活性，包括使用
## 社区 {#community}

Istio 是一个真正的社区项目。2023 年，
有 10 家公司为 Istio 做出了超过 1,000 项贡献，并没有一家公司的贡献超过 25%。
（[在此处查看数字](https://istio.devstats.cncf.io/d/5/companies-table?var-period_name=Last%20year&var-metric=contributions&orgId=1)）。
有 10 家公司为 Istio 做出了超过 1,000 项贡献，没有一家公司的贡献超过 25%。
（[在此处查看统计数据](https://istio.devstats.cncf.io/d/5/companies-table?var-period_name=Last%20year&var-metric=contributions&orgId=1)）。

没有其他服务网格项目像 Istio 一样获得业界如此广泛的支持。

## 软件包 {#packages}

我们每次发布时都会向所有人提供稳定的二进制版本，并承诺继续这样做。
我们为[我们的最新版本和许多先前版本](/zh/docs/releases/supported-releases/)发布免费且定期的安全补丁。
我们的许多供应商都会支持旧版本，但我们认为，在稳定的开源项目中，
我们为[最新版本和部分旧版本](/zh/docs/releases/supported-releases/)定期发布免费的安全补丁。
我们的许多供应商会支持更旧的版本，但我们认为，在稳定的开源项目中，
与供应商合作不应该成为确保安全的必要条件。

## 曾被考虑的替代方案 {#alternatives-considered}
Expand All @@ -62,12 +63,12 @@ Istio 是一个真正的社区项目。2023 年，
[将流量从 Pod 路由到代理](/zh/blog/2022/merbridge/)。
与使用 `iptables` 相比，这显示出了轻微的性能提升。

为什么不把它用在一切事情上呢？没有人这么做，因为没有人真正能做到。
为什么不把 eBPF 用在所有功能上呢？没有人这么做，因为没有人真正能做到。

eBPF 是一个在 Linux 内核中运行的虚拟机。它专为保证在有限的计算范围内完成的功能而设计，
以避免破坏内核行为，例如执行简单的 L3 流量路由或应用程序可观察性的功能。
以避免破坏内核行为，例如执行简单的 L3 流量路由或应用可观测性的功能。
它不是为像 Envoy 中那样的长期运行或复杂功能而设计的：
这就是为什么操作系统有[用户空间](https://en.wikipedia.org/wiki/User_space_and_kernel_space)！
这就是为什么操作系统有[用户空间](https://zh.wikipedia.org/wiki/%E4%BD%BF%E7%94%A8%E8%80%85%E7%A9%BA%E9%96%93)！
eBPF 维护者认为它最终可以扩展以支持运行像 Envoy 一样复杂的程序，
但这是一个科学项目，不太可能具有现实世界的实用性。

Expand All @@ -79,7 +80,8 @@ Envoy 本身并不是多租户的。因此，我们在共享实例中混合来
存在严重的安全性和稳定性问题。由于 Kubernetes 默认可以将任何命名空间中的 Pod 调度到任何节点上，
因此该节点不是合适的租户边界。预算和成本归因也是主要问题，因为 L7 处理的成本比 L4 高得多。

在 Ambient 模式下，我们严格限制 ztunnel 代理进行 L4 处理 - [就像 Linux 内核一样](https://blog.howardjohn.info/posts/ambient-spof/)。
在 Ambient 模式下，我们严格限制 ztunnel 代理进行 L4 处理 -
[就像 Linux 内核一样](https://blog.howardjohn.info/posts/ambient-spof/)。
这大大减少了漏洞的暴露面，并允许我们安全地操作共享组件。
然后，流量被转发到按命名空间运行的 Envoy 代理，这样 Envoy 代理就永远不会是多租户的。

Expand All @@ -95,7 +97,8 @@ Envoy 本身并不是多租户的。因此，我们在共享实例中混合来
为此，Istio 实现了零信任隧道（ztunnel）组件，该组件使用成熟的行业标准加密协议透明高效地提供此功能。
[了解有关 ztunnel 的更多信息](/zh/docs/ambient/overview)。

Istio 旨在成为一个服务网格，它提供一致、高度安全、高效且符合标准的服务网格实现，
提供[一组强大的 L7 策略](/zh/docs/concepts/security/#authorization)、
[与平台无关的工作负载身份](/zh/docs/concepts/security/#istio-identity)，
使用[业界验证的 mTLS 协议](/zh/docs/concepts/security/#mutual-tls-authentication) - 在任何环境、任何 CNI，甚至跨具有不同 CNI 的集群。
Istio 设计为一个服务网格，Istio 可以在任何环境、任何 CNI、甚至跨不同 CNI 的多个集群，
使用[业界验证的 mTLS 协议](/zh/docs/concepts/security/#mutual-tls-authetication)，
提供一致、高度安全、高效且合规的服务网格实现，
提供了[一组强大的 L7 策略](/zh/docs/concepts/security/#authorization)、
[与平台无关的工作负载身份](/zh/docs/concepts/security/#istio-identity)。