mirror of https://github.com/istio/istio.io.git
* Sync #13719 * Fix typo and improve * Some improve * Update content/zh/boilerplates/ambient-alpha-warning.md Co-authored-by: Michael <haifeng.yao@daocloud.io> * Update content/zh/boilerplates/ambient-alpha-warning.md Co-authored-by: Michael <haifeng.yao@daocloud.io> * Update content/zh/boilerplates/ambient-alpha-warning.md Co-authored-by: Michael <haifeng.yao@daocloud.io> * Update content/zh/boilerplates/ambient-alpha-warning.md Co-authored-by: Michael <haifeng.yao@daocloud.io> * Fix all translation for 'sample' --------- Co-authored-by: Michael <haifeng.yao@daocloud.io>
This commit is contained in:
Wilson Wu
GitHub
parent
b31d47adf2
commit
a5b0ac0577
|
|
@ -0,0 +1,11 @@
|
|||
---
|
||||
---
|
||||
{{< warning >}}
|
||||
Ambient 目前处于 [Alpha 状态](/zh/docs/releases/feature-stages/#feature-phase-definitions)。
|
||||
|
||||
**请勿在生产环境中使用 Ambient 模式**，
|
||||
务必先行斟酌[特性阶段定义](/zh/docs/releases/feature-stages/#feature-phase-definitions)再行使用 Ambient。
|
||||
具体而言，`alpha` 版本意味着存在已知的性能、稳定性和安全性问题，
|
||||
还存在一些计划中的破坏性变更，其中某些变更可能会令升级失败。
|
||||
这些是进阶至 `beta` 之前需要解决的问题。
|
||||
{{< /warning >}}
|
||||
|
|
@ -17,7 +17,7 @@ test: n/a
|
|||
1. **Uncaptured:** 这是一个未启用任何网格特性的标准 Pod。
|
||||
1. **Captured:** 这是流量已被 {{< gloss >}}Ztunnel{{< /gloss >}} 截取的 Pod。
|
||||
通过在命名空间上设置 `istio.io/dataplane-mode=ambient` 标签可以捕获 Pod。
|
||||
1. **Waypoint enabled:** 这是 一个被"捕获" **且** 部署了
|
||||
1. **Waypoint enabled:** 这是一个被“捕获”**且**部署了
|
||||
{{< gloss "waypoint" >}}waypoint 代理{{< /gloss >}}的 Pod。
|
||||
waypoint 默认将应用到同一命名空间中的所有 Pod。
|
||||
通过在 `Gateway` 上使用 `istio.io/for-service-account` 注解，
|
||||
|
|
@ -30,7 +30,7 @@ test: n/a
|
|||
|
||||
#### 出站 {#outbound}
|
||||
|
||||
当被捕获的 Pod 发出出站请求时，它将被透明地重定向到 Ztunnel，由Ztunnel 来决定如何转发请求以及转发到哪儿。
|
||||
当被捕获的 Pod 发出出站请求时，它将被透明地重定向到 Ztunnel，由 Ztunnel 来决定如何转发请求以及转发到哪儿。
|
||||
总之，流量路由行为就像 Kubernetes 默认的流量路由一样；
|
||||
到 `Service` 的请求将被发送到 `Service` 内的一个端点，
|
||||
而直接发送到 `Pod` IP 的请求则将直接转到该 IP。
|
||||
|
|
@ -41,12 +41,12 @@ test: n/a
|
|||
如果目的地有一个 waypoint 代理，除了升级到 HBONE 之外，请求将被转发到该 waypoint。
|
||||
|
||||
请注意，对于到 `Service` 的请求，将选择特定的端点来决定其是否具有 waypoint。
|
||||
然而，如果请求 **具有** waypoint，请求将随着 `Service` 的目标目的地而不是所选的端点被发送。
|
||||
然而，如果请求**具有** waypoint，请求将随着 `Service` 的目标目的地而不是所选的端点被发送。
|
||||
这就允许 waypoint 将面向服务的策略应用到流量。
|
||||
在极少情况下，`Service` 会混合使用启用/未启用 waypoint 的端点，
|
||||
某些请求将被发送到 waypoint，而到相同服务的其他请求不会被发送到 waypoint。
|
||||
|
||||
#### 入站{#inbound}
|
||||
#### 入站 {#inbound}
|
||||
|
||||
当被捕获的 Pod 收到一个入站请求时，它将被透明地重定向到 Ztunnel。
|
||||
当 Ztunnel 收到请求时，它将应用鉴权策略并仅在请求与策略匹配时转发请求。
|
||||
|
|
@ -54,15 +54,15 @@ test: n/a
|
|||
Pod 可以接收 HBONE 流量或纯文本流量。
|
||||
这两种流量默认都可以被 Ztunnel 接受。
|
||||
因为纯文本请求在评估鉴权策略时没有对等身份，
|
||||
所以用户可以设置一个策略，要求进行身份验证（可以是 **任何** 身份验证或特定身份验证），以阻止所有纯文本流量。
|
||||
所以用户可以设置一个策略，要求进行身份验证（可以是**任何**身份验证或特定身份验证），以阻止所有纯文本流量。
|
||||
|
||||
当目的地启用 waypoint 时，所有请求 **必须** 通过 waypoint 来执行策略。
|
||||
当目的地启用 waypoint 时，所有请求**必须**通过 waypoint 来执行策略。
|
||||
Ztunnel 将确保达成这种行为。
|
||||
然而，存在一些边缘场景：一个行为良好的 HBONE 客户端（例如另一个 Ztunnel 或 Istio Sidecar）
|
||||
知道发送到 waypoint，但其他客户端（例如网格外的工作负载）可能不知道 waypoint 代理的任何信息并直接发送请求。
|
||||
当进行这些直接调用时，Ztunnel 将使请求"红头文件"调整到其自身 waypoint 的请求，以确保这些策略被正确执行。
|
||||
|
||||
### Waypoint 路由{#waypoint-routing}
|
||||
### Waypoint 路由 {#waypoint-routing}
|
||||
|
||||
waypoint 以独占方式接收 HBONE 请求。
|
||||
在收到一个请求时，waypoint 将确保此请求指向其管理的 `Pod` 或包含所管理 `Pod` 的 `Service`。
|
||||
|
|
|
|||
|
|
@ -6,15 +6,7 @@ owner: istio/wg-networking-maintainers
|
|||
test: yes
|
||||
---
|
||||
|
||||
{{< warning >}}
|
||||
Ambient 目前处于 [Alpha 状态](/zh/docs/releases/feature-stages/#feature-phase-definitions).
|
||||
|
||||
请勿在生产环境中使用 Ambient，
|
||||
务必先行斟酌[特性阶段定义](/zh/docs/releases/feature-stages/#feature-phase-definitions)再行使用 Ambient。
|
||||
具体而言，`alpha` 版本意味着存在已知的性能、稳定性和安全性问题。
|
||||
还存在一些计划中的破坏性变更，其中某些变更可能会令升级失败。
|
||||
这些是进阶至 `beta` 之前需要解决的问题。
|
||||
{{< /warning >}}
|
||||
{{< boilerplate ambient-alpha-warning >}}
|
||||
|
||||
本指南有助于您快速评估 Istio {{< gloss "ambient" >}}ambient service mesh{{< /gloss >}}。
|
||||
以下操作步骤需要您有一个 {{< gloss >}}cluster{{< /gloss >}} 运行了 Kubernetes ({{< supported_kubernetes_versions >}})
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Cosign 是作为 [sigstore](https://www.sigstore.dev) 项目的一部分开发
|
|||
|
||||
此过程适用于手动执行或与构建/部署管道集成，以自动验证镜像制品。
|
||||
|
||||
## 先决条件{#prerequisites}
|
||||
## 先决条件 {#prerequisites}
|
||||
|
||||
在开始之前，请执行以下操作：
|
||||
|
||||
|
|
@ -34,7 +34,7 @@ $ openssl dgst -sha256 \
|
|||
|
||||
1. 使二进制文件可执行（`chmod +x`），并移动到 `PATH` 上的一个位置。
|
||||
|
||||
## 验证镜像{#validating-image}
|
||||
## 验证镜像 {#validating-image}
|
||||
|
||||
要验证容器镜像，请执行以下操作：
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ owner: istio/wg-policies-and-telemetry-maintainers
|
|||
test: n/a
|
||||
---
|
||||
|
||||
## 使用 Prometheus 进行生产规模的监控{#using-Prometheus-for-production-scale-monitoring}
|
||||
## 使用 Prometheus 进行生产规模的监控 {#using-Prometheus-for-production-scale-monitoring}
|
||||
|
||||
使用 Istio 以及 Prometheus 进行生产规模的监控时推荐的方式是使用[分层联邦](https://prometheus.io/docs/prometheus/latest/federation/#hierarchical-federation)并且结合一组[记录规则](https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/)。
|
||||
|
||||
|
|
@ -22,7 +22,7 @@ test: n/a
|
|||
caption="生产规模 Istio 监控"
|
||||
>}}
|
||||
|
||||
### 通过记录规则进行负载等级的聚合{#workload-level-aggregation-via-recording-rules}
|
||||
### 通过记录规则进行负载等级的聚合 {#workload-level-aggregation-via-recording-rules}
|
||||
|
||||
为了聚合统计实例以及 Pod 级别的指标，需要用以下的记录规则更新默认 Prometheus 配置：
|
||||
|
||||
|
|
@ -154,7 +154,7 @@ spec:
|
|||
如需要更多关于如何配置您的记录规则。请参考[使用记录规则优化指标收集](#optimizing-metrics-collection-with-recording-rules)。
|
||||
{{< /tip >}}
|
||||
|
||||
### 使用负载级别的聚合指标进行联邦{#federation-using-workload-level-aggregated-metrics}
|
||||
### 使用负载级别的聚合指标进行联邦 {#federation-using-workload-level-aggregated-metrics}
|
||||
|
||||
为了建立 Prometheus 联邦，请修改您的 Prometheus 生产部署配置来抓取 Istio Prometheus 联邦终端的指标数据。
|
||||
|
||||
|
|
@ -214,7 +214,7 @@ spec:
|
|||
|
||||
{{< tip >}}
|
||||
联邦配置的关键是首先匹配通过 Istio 部署的 Prometheus 中收集 [Istio 标准指标](/zh/docs/reference/config/metrics/)的
|
||||
job。并且将收集到的指标重命名，方法为去除负载等级记录规则命名前缀 (`workload:`)。
|
||||
Job。并且将收集到的指标重命名，方法为去除负载等级记录规则命名前缀 (`workload:`)。
|
||||
这使得现有的仪表盘以及引用能够无缝地针对生产用 Prometheus 继续工作（并且不在指向 Istio 实例）。
|
||||
|
||||
您可以在设置联邦时包含额外的指标（例如 envoy、go 等）。
|
||||
|
|
@ -287,7 +287,7 @@ Prometheus 生产实例可以从 Istio 实例那里得到的信息更新联邦
|
|||
|
||||
* 匹配字句 `{__name__=~"istio:(.*)"}`
|
||||
|
||||
* 重新将指标标签为： `regex: "istio:(.*)"`
|
||||
* 重新将指标标签为：`regex: "istio:(.*)"`
|
||||
|
||||
原始引用被替代为：
|
||||
|
||||
|
|
|
|||
|
|
@ -9,12 +9,16 @@ owner: istio/wg-environments-maintainers
|
|||
test: n/a
|
||||
---
|
||||
|
||||
本页面描述了在[安装 Istio](/zh/docs/setup/install/istioctl/) 时所能够使用的内置配置文件。这些配置文件提供了对 Istio 控制平面和 Istio 数据平面 Sidecar 的定制内容。
|
||||
本页面描述了在[安装 Istio](/zh/docs/setup/install/istioctl/) 时所能够使用的内置配置文件。
|
||||
这些配置文件提供了对 Istio 控制平面和 Istio 数据平面 Sidecar 的定制内容。
|
||||
|
||||
您可以从 Istio 内置配置文件的其中一个开始入手，然后根据您的特定需求进一步[自定义配置文件](/zh/docs/setup/additional-setup/customize-installation/)。当前提供以下几种内置配置文件：
|
||||
您可以从其中一个 Istio 内置配置文件开始入手，
|
||||
然后根据您的特定需求进一步[自定义配置文件](/zh/docs/setup/additional-setup/customize-installation/)。
|
||||
当前提供以下几种内置配置文件：
|
||||
|
||||
1. **default**：根据 [`IstioOperator` API](/zh/docs/reference/config/istio.operator.v1alpha1/) 的默认设置启动组件。
|
||||
建议用于生产部署和 [Multicluster Mesh](/zh/docs/ops/deployment/deployment-models/#multiple-clusters) 中的 {{< gloss "primary cluster" >}}Primary Cluster{{< /gloss >}}。
|
||||
建议用于生产部署和 [Multicluster Mesh](/zh/docs/ops/deployment/deployment-models/#multiple-clusters)
|
||||
中的 {{< gloss "primary cluster" >}}Primary Cluster{{< /gloss >}}。
|
||||
|
||||
您可以运行 `istioctl profile dump` 命令来查看默认设置。
|
||||
|
||||
|
|
@ -27,28 +31,37 @@ test: n/a
|
|||
{{< /warning >}}
|
||||
|
||||
1. **minimal**：与默认配置文件相同，但只安装了控制平面组件。
|
||||
它允许您使用 [Separate Profile](/zh/docs/setup/additional-setup/gateway/#deploying-a-gateway) 配置控制平面和数据平面组件(例如 Gateway)。
|
||||
它允许您使用 [Separate Profile](/zh/docs/setup/additional-setup/gateway/#deploying-a-gateway)
|
||||
配置控制平面和数据平面组件（例如 Gateway）。
|
||||
|
||||
1. **remote**：用于配置一个 {{< gloss >}}Remote Cluster{{< /gloss >}}，
|
||||
这个从集群由 {{< gloss >}}External Control Plane{{< /gloss >}} 管理，
|
||||
或者由 [multicluster mesh](/zh/docs/ops/deployment/deployment-models/#multiple-clusters) 的
|
||||
或者由 [Multicluster Mesh](/zh/docs/ops/deployment/deployment-models/#multiple-clusters) 的
|
||||
{{< gloss >}}Primary Cluster{{< /gloss >}} 中的控制平面管理。
|
||||
|
||||
1. **empty**：不部署任何东西。可以作为自定义配置的基本配置文件。
|
||||
1. **empty**：不部署任何内容。可以作为自定义配置的基本配置文件。
|
||||
|
||||
1. **preview**：预览文件包含的功能都是实验性。这是为了探索 Istio 的新功能。不确保稳定性、安全性和性能（使用风险需自负）。
|
||||
1. **preview**：预览文件包含的功能都属于实验性阶段。该配置文件是为了探索 Istio 的新功能。
|
||||
确保稳定性、安全性和性能（使用风险需自负）。
|
||||
|
||||
1. **ambient**：Ambient 配置文件旨在帮助您开始使用[Ambient Mesh](/zh/docs/ops/ambient)。
|
||||
|
||||
{{< boilerplate ambient-alpha-warning >}}
|
||||
|
||||
{{< tip >}}
|
||||
此外，还提供了一些其他特定的配置文件。更多相关信息，请参阅平台的 [平台安装](/zh/docs/setup/platform-setup)。
|
||||
此外，还提供了一些其他特定的配置文件。更多相关信息，
|
||||
请参阅[平台安装](/zh/docs/setup/platform-setup)。
|
||||
{{< /tip >}}
|
||||
|
||||
标注 ✔ 的组件安装在每个配置文件中：
|
||||
|
||||
| | default | demo | minimal | remote | empty | preview |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| 核心组件 | | | | | | | |
|
||||
| `istio-egressgateway` | | ✔ | | | | | | |
|
||||
| `istio-ingressgateway` | ✔ | ✔ | | | | ✔ |
|
||||
| `istiod` | ✔ | ✔ | ✔ | | | ✔ |
|
||||
| | default | demo | minimal | remote | empty | preview | ambient |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| 核心组件 | | | | | | | | |
|
||||
| `istio-egressgateway` | | ✔ | | | | | | | |
|
||||
| `istio-ingressgateway` | ✔ | ✔ | | | | ✔ | |
|
||||
| `istiod` | ✔ | ✔ | ✔ | | | ✔ | ✔ |
|
||||
| `CNI` | | | | | | | ✔ |
|
||||
| `Ztunnel` | | | | | | | ✔ |
|
||||
|
||||
为了进一步自定义 Istio，还可以安装一些附加组件。详情请参阅 [集成](/zh/docs/ops/integrations)。
|
||||
为了进一步自定义 Istio，还可以安装一些附加组件。详情请参阅[集成](/zh/docs/ops/integrations)。
|
||||
|
|
|
|||
|
|
@ -145,7 +145,8 @@ spec:
|
|||
{{< /text >}}
|
||||
|
||||
诸如 Kubernetes 资源、命名空间和开关设置等参数暂时并存在 Helm 和 `IstioOperator` API 中。
|
||||
Istio 社区推荐使用 `IstioOperator` API ，因为它更一致、更有效、且遵循[社区毕业流程](https://github.com/istio/community/blob/master/FEATURE-LIFECYCLE-CHECKLIST.md#feature-lifecycle-checklist).
|
||||
Istio 社区推荐使用 `IstioOperator` API，因为它更一致、更有效、
|
||||
且遵循[社区毕业流程](https://github.com/istio/community/blob/master/FEATURE-LIFECYCLE-CHECKLIST.md#feature-lifecycle-checklist)。
|
||||
|
||||
### 配置网关 {#configure-gateways}
|
||||
|
||||
|
|
|
|||
|
|
@ -56,9 +56,9 @@ Istio 默认会将 Init 容器 `istio-init` 注入到网格中部署的 Pod 内
|
|||
✔ Installation complete
|
||||
{{< /text >}}
|
||||
|
||||
## 部署样例应用{#deploy-sample-app}
|
||||
## 部署示例应用 {#deploy-sample-app}
|
||||
|
||||
1. 添加命名空间标签，以便为将要运行 demo 应用的 `default` 命名空间执行 `baseline` 策略：
|
||||
1. 添加命名空间标签，以便为将要运行 demo 应用的 `default` 命名空间执行 `baseline` 策略：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl label --overwrite ns default \
|
||||
|
|
@ -67,7 +67,7 @@ Istio 默认会将 Init 容器 `istio-init` 注入到网格中部署的 Pod 内
|
|||
namespace/default labeled
|
||||
{{< /text >}}
|
||||
|
||||
1. 使用启用 PSA 的配置资源来部署样例应用：
|
||||
1. 使用启用 PSA 的配置资源来部署示例应用：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo-psa.yaml@
|
||||
|
|
@ -94,9 +94,9 @@ Istio 默认会将 Init 容器 `istio-init` 注入到网格中部署的 Pod 内
|
|||
<title>Simple Bookstore App</title>
|
||||
{{< /text >}}
|
||||
|
||||
## 卸载{#uninstall}
|
||||
## 卸载 {#uninstall}
|
||||
|
||||
1. 删除样例应用
|
||||
1. 删除示例应用
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl delete -f samples/bookinfo/platform/kube/bookinfo-psa.yaml
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ test: no
|
|||
|
||||
下面的章节描述了向 Pod 中注入 Istio Sidecar 的两种方法：使用
|
||||
[`istioctl`](/zh/docs/reference/commands/istioctl) 手动注入或启用
|
||||
Pod 所属命名空间的 Istio sidecar 注入器自动注入。
|
||||
Pod 所属命名空间的 Istio Sidecar 注入器自动注入。
|
||||
|
||||
当 Pod 所属命名空间启用自动注入后，自动注入器会使用准入控制器在创建 Pod 时自动注入代理配置。
|
||||
|
||||
|
|
@ -223,8 +223,8 @@ spec:
|
|||
来覆盖默认的 `image` 配置，但建议将 `image` 设置为 `auto`，可使 Sidecar
|
||||
注入自动选择要使用的 Image。
|
||||
|
||||
* `Pod` 中一些字段取决于相关设置。例如，CPU 请求必须小于 CPU 限制。如果两个字段没有一起配置，
|
||||
Pod 可能会无法启动。
|
||||
* `Pod` 中一些字段取决于相关设置。例如，CPU 请求必须小于 CPU 限制。
|
||||
如果两个字段没有一起配置，Pod 可能会无法启动。
|
||||
|
||||
另外，某些字段可通过在 Pod 上的[注解](/zh/docs/reference/config/annotations/)进行配置，
|
||||
但是不建议使用上述方法进行自定义设置。必须特别注意某些注解：
|
||||
|
|
|
|||
Loading…
Reference in New Issue