mirror of https://github.com/istio/istio.io.git
[zh] Update overview/dataplane-modes/index.md (#16005)
This commit is contained in:
Michael Yao
GitHub
parent
c17f3c192a
commit
924e683f01
|
|
@ -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>
|
||||
|
|
@ -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>
|
||||
|
|
@ -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>
|
||||
|
|
@ -126,7 +129,7 @@ Ambient 网格允许这些用户在不需要时完全绕过 L7 处理的成本
|
|||
<td>强：每个节点代理仅具有该节点上工作负载的密钥</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>被入侵的应用程序 Pod<br>可访问网格密钥</th>
|
||||
<th>被入侵的应用 Pod<br>可访问网格密钥</th>
|
||||
<td>可以</td>
|
||||
<td>不可以</td>
|
||||
</tr>
|
||||
|
|
@ -146,7 +149,7 @@ Ambient 网格允许这些用户在不需要时完全绕过 L7 处理的成本
|
|||
## 四层与七层功能 {#layer-4-vs-layer-7-features}
|
||||
|
||||
在七层处理协议的开销远远高于在四层处理网络数据包的开销。
|
||||
对于给定的服务，如果您的要求可以在 L4 满足，则可以以更低的成本提供服务网格。
|
||||
对于给定的服务，如果您的要求可以在 L4 被满足，则可以以明显更低的成本交付服务网格。
|
||||
|
||||
### 安全 {#security}
|
||||
|
||||
|
|
@ -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>
|
||||
|
|
@ -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>
|
||||
|
|
@ -220,7 +223,7 @@ Ambient 网格允许这些用户在不需要时完全绕过 L7 处理的成本
|
|||
<tr>
|
||||
<th>指标</th>
|
||||
<td>仅 TCP（发送/接收的字节数、数据包数量等）。</td>
|
||||
<td>L7 RED 指标：请求率、错误率、请求持续时间（延迟）。</td>
|
||||
<td>L7 RED 指标：请求率、错误率、请求时间（延迟）。</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
|
@ -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>
|
||||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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)以及几乎所有其他服务网格平台的代理。
|
||||
|
||||
|
|
@ -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}
|
||||
|
|
@ -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 一样复杂的程序，
|
||||
但这是一个科学项目，不太可能具有现实世界的实用性。
|
||||
|
||||
|
|
@ -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 代理就永远不会是多租户的。
|
||||
|
||||
|
|
@ -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)。
|
||||
|
|
|
|||
Loading…
Reference in New Issue