[zh] Update text from ist0001 to ist0118 (#14376)

* [zh] Update ist0001 to ist0113

* Apply suggestions from hanxiaop

* sync with #14380
This commit is contained in:
Michael 2023-12-28 15:13:29 +08:00 committed by GitHub
parent 334258e712
commit 89e397fbb4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
15 changed files with 76 additions and 57 deletions

View File

@ -7,4 +7,5 @@ test: n/a
这个错误很可能是由 Istio 的内部问题引起的,而不是用户错误。
要解决此问题,请检查此问题是否是已知问题,或使用 [Istio issue 页面](https://github.com/istio/istio/issues)将其报告为新问题。
要解决此问题,请检查此问题是否是已知问题,或使用
[Istio issue 页面](https://github.com/istio/istio/issues)将其报告为新问题。

View File

@ -5,6 +5,6 @@ owner: istio/wg-user-experience-maintainers
test: n/a
---
当您使用了计划在将来的版本中删除的功能时,会出现此消息。
当您使用了计划在后续版本中移除的某功能时,会出现此消息。
要解决此问题,请在 Istio 的[版本说明](/zh/news/releases/)中检查目标功能的替代解决方案。
要解决此问题,请在 Istio 的[版本说明](/zh/news/releases/)中查看已弃用功能的替代方案。

View File

@ -5,15 +5,16 @@ owner: istio/wg-user-experience-maintainers
test: no
---
当一个 Istio 资源引用另一个不存在的资源时,会触发此消息。当 Istio 试图查找引用的资源,但是找不到它时,这将导致错误。
当 Istio 资源引用另一个不存在的资源时,会出现此消息。
这会导致 Istio 尝试查找引用的资源但找不到这类的错误。
例如,您收到这个错误:
例如,您会收到这个错误提示:
{{< text plain >}}
Error [IST0101] (VirtualService httpbin.default) Referenced gateway not found: "httpbin-gateway-bogus"
{{< /text >}}
这个例子中, `VirtualService` 指向一个不存在的网关:
以下例子中,`VirtualService` 指向了一个不存在的网关:
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
@ -39,7 +40,7 @@ spec:
hosts:
- "*"
gateways:
- httpbin-gateway-bogus # Should have been "httpbin-gateway"
- httpbin-gateway-bogus # 应该是 "httpbin-gateway"
http:
- route:
- destination:

View File

@ -5,7 +5,10 @@ owner: istio/wg-user-experience-maintainers
test: no
---
当命名空间缺少[注解](/zh/docs/reference/config/annotations/)来标记命名空间是否自动注入时会出现此错误,例如 `sidecar.istio.io/inject`
当命名空间缺少 `istio-injection` 标签(用于启用/禁用 Sidecar 注入)或
`istio.io/rev` 标签用于指定sidecar的Istio控制平面修订版或者
`.values.sidecarInjectorWebhook.enableNamespacesByDefault`
未被启用时,会出现此消息。
例如,您可能看到以下错误:
@ -16,10 +19,10 @@ enable it, or 'kubectl label namespace default istio-injection=disabled' to
explicitly mark it as not needing injection Error: Analyzer found issues.
{{< /text >}}
要解决此问题,请您使用注解明确声明您是否希望命名空间被自动注入。例如:
要解决此问题,请您使用标签明确声明您是否希望命名空间被自动注入。例如:
{{< text bash >}}
$ kubectl label namespace <namespace-name> istio-injection=enabled
{{< /text >}}
强烈建议您明确定义需要的注入行为。忘记对命名空间标记注解是导致错误的常见原因。
强烈建议您明确定义需要的注入行为。忘记对命名空间打标签是导致错误的常见原因。

View File

@ -5,13 +5,13 @@ owner: istio/wg-user-experience-maintainers
test: no
---
sidecar 不存在或不能正常工作时,将触发此消息。
Sidecar 不存在或不能正常工作时,将出现此消息。
最常见的情况是,您开启了自动注入,但之后没有重新启动您的 pod导致 sidecar 丢失
最常见的情况是,您开启了自动注入,但之后没有重新启动您的 Pod导致还未被注入 Sidecar
为了解决这个问题,重新启动您的 pod然后重试一次
为了解决这个问题,请重新启动您的 Pod 以便进行注入
例如,要重新启动 pod可以使用以下命令:
例如,可以使用以下命令重新启动 Pod
{{< text bash >}}
$ kubectl rollout restart deployment

View File

@ -5,7 +5,7 @@ owner: istio/wg-user-experience-maintainers
test: no
---
当您的 Istio 配置没有成功通过架构验证时,会出现此消息。
当您的 Istio 配置没有成功通过模式验证时,会出现此消息。
例如,您将会看到以下错误:
@ -13,7 +13,7 @@ test: no
Error [IST0106] (VirtualService ratings-bogus-weight-default.default) Schema validation error: percentage 888 is not in range 0..100
{{< /text >}}
并且您的 Istio 中包含以下配置
并且您的 Istio 配置包含以下参数值:
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
@ -36,8 +36,9 @@ spec:
weight: 888
{{< /text >}}
在这个示例中,错误信息是指 `weight` 属性被检查出值错误或无效。
在这个示例中,错误消息是指在模式检查时发现 `weight` 属性的取值错误或无效。
要解决此问题, 参考[消息详情](/zh/docs/reference/config/analysis/message-format/)的字段来了解哪些属性无效或错误,更正所有错误后,重新尝试。
要解决此问题,参考[消息详情](/zh/docs/reference/config/analysis/message-format/)
的字段来了解哪些属性无效或错误,更正所有错误后重试。
有关 Istio 资源架构设计的更详细信息,请看[配置参考](/zh/docs/reference/config/).
有关 Istio 资源的预期模式详情,请查看[配置参考](/zh/docs/reference/config/)。

View File

@ -5,8 +5,10 @@ owner: istio/wg-user-experience-maintainers
test: n/a
---
此消息发生在当 Istio {{< gloss >}}annotation{{< /gloss >}} 被添加到无效的资源上或资源的错误位置时。
当 Istio {{< gloss >}}annotation{{< /gloss >}}
被添加到无效的资源上或目标资源的位置错误时,将出现此错误消息。
比如,当您创建一个 deployment 并且把 annotation 添加 deployment 上而不是它创建的 pod 上时就会发生。
比如,当您创建一个 Deployment 并且把注解添加 Deployment
上而不是它创建的 Pod 上时就会出现此消息。
为了解决此问题,检查您的 annotation 是否被放在了正确的地方然后重试。
为了解决此问题,请检查您的注解是否被放在了正确的地方,然后重试。

View File

@ -5,8 +5,8 @@ owner: istio/wg-user-experience-maintainers
test: n/a
---
当您为某个命名空间使用了格式为 `*.istio.io`注解时会出现该错误信息。
当您为某个命名空间使用了格式为 `*.istio.io`、未识别的注解时会出现此错误消息。
Istio 仅能识别一些[注解名称](/zh/docs/reference/config/annotations/)。
要解决这个问题,检查您的注解名称后重新尝试。
要解决这个问题,检查注解名称后重试。

View File

@ -5,22 +5,24 @@ owner: istio/wg-user-experience-maintainers
test: no
---
当 Istio 检测到因[Virtual Service](/zh/docs/reference/config/networking/virtual-service)资源重复而导致冲突时,会出现该信息。比如,多个 Virtual Service 使用相同的主机名且连接 Gateway会出现错误信息。需要注意的是Istio 支持 Virtual Service 合并来连接入口网关。
当 Istio 检测到因 [VirtualService](/zh/docs/reference/config/networking/virtual-service)
资源重复而导致冲突时,会出现此消息。比如,多个 VirtualService 使用相同的主机名且连接网格 Gateway 时,
会出现一条错误消息。需要注意的是Istio 支持合并挂接到入口网关的 VirtualService。
## 解决方案{#resolution}
## 解决方案 {#resolution}
解决该问题,有如下几个方法:
* 将冲突的 Virtual Service 合并为一个
* 连接 Gateway 的 Virtual Service 使用唯一的主机名
* 将冲突的 VirtualService 合并为一个
* 连接 Gateway 的 VirtualService 使用唯一的主机名
* 通过设置 `exportTo` 字段,将资源范围限定到指定的命名空间。
## 示例{#examples}
## 示例 {#examples}
命名空间 `team1`虚拟服务 `productpage` 与命名空间 `team2` 的 Virtual Service `custom` 存在冲突的原因如下:
命名空间 `team1` VirtualService `productpage` 与命名空间 `team2` 的 VirtualService `custom` 存在冲突的原因如下:
* 因为没有指定自定义 Gateway它们被连接默认的 Gateway。
* 它们都定义了相同的主机 `productpage.default.svc.cluster.local`
* 因为自定义 Gateway 未被指定,所以 VirtualService 挂接到了默认的 "mesh" Gateway。
* VirtualService 都定义了相同的主机 `productpage.default.svc.cluster.local`
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3
@ -51,7 +53,7 @@ spec:
---
{{< /text >}}
您可以通过设置 `exportTo` 字段为 `.` 来解决该问题,让每个 Virtual Service 都只限定在自己的命名空间:
您可以通过设置 `exportTo` 字段为 `.` 来解决此问题,让每个 VirtualService 都只限定在自己的命名空间:
{{< text yaml >}}
apiVersion: networking.istio.io/v1alpha3

View File

@ -5,6 +5,7 @@ owner: istio/wg-user-experience-maintainers
test: n/a
---
当一个命名空间中,多个 Sidecar 资源选择相同的工作负载实例时会出现此问题。这可能导致未知问题。查看 [Sidecar](/zh/docs/reference/config/networking/sidecar/) 了解更多信息。
当一个命名空间中有多个 Sidecar 资源选择相同的工作负载实例时会出现此消息。这可能导致未知的行为。
查看 [Sidecar](/zh/docs/reference/config/networking/sidecar/) 了解更多信息。
要解决此问题,请确保同一个命名空间中的 Sidecar 的负载选择器选择的工作负载实例(例如 Pod不会重复。
要解决此问题,请确保同一个命名空间中每个 Sidecar 工作负载选择器选择的工作负载实例(例如 Pod不会重复。

View File

@ -5,6 +5,7 @@ owner: istio/wg-user-experience-maintainers
test: n/a
---
当一个命名空间中超过一个 Sidecar 资源没有定义任何工作负载选择器时,会出现此信息。这种情况会导致行为未被定义。更多信息详见 [Sidecar](/zh/docs/reference/config/networking/sidecar/) 资源参考资料。
当一个命名空间中有多个 Sidecar 资源没有定义任何工作负载选择器时,会出现此消息。
这种情况会造成未定义的行为。更多信息详见 [Sidecar](/zh/docs/reference/config/networking/sidecar/) 资源参考资料。
解决该问题,需确保每个命名空间有且仅有一个没有定义工作负载选择器的 Sidecar 资源。
要解决此问题,请确保每个命名空间有且仅有一个没有定义工作负载选择器的 Sidecar 资源。

View File

@ -5,6 +5,8 @@ owner: istio/wg-user-experience-maintainers
test: n/a
---
当一个 Virtual Service 连接到一个有多个端口的 Service但是并未指定使用哪一个端口时会出现此信息。这种情况会导致行为未被定义。
当 Virtual Service 连接到暴露了多个端口的 Service 但并未指定使用哪一个端口时会出现此消息。
这种情况会造成未定义的行为。
要解决这个问题,需在 Virtual Service [Destination](/zh/docs/reference/config/networking/virtual-service/#Destination)中添加一个`port`用于指定使用的端口。
要解决此问题,需在 Virtual Service [Destination](/zh/docs/reference/config/networking/virtual-service/#Destination)
中添加一个 `port` 用于指定要使用的端口。

View File

@ -9,9 +9,10 @@ test: no
如果这两个资源各自指定的双向 TLS 模式不兼容,则它们会冲突。
此冲突意味着与目标规则匹配的到达指定主机的流量将被拒绝。
此消息仅会在不使用[自动双向 TLS](/zh/docs/tasks/security/authentication/auto-mtls/) 的服务网格上发生。
此消息仅会在不使用[自动双向 TLS](/zh/docs/tasks/security/authentication/auto-mtls/)
的服务网格上发生。
## 示例{#an-example}
## 示例 {#an-example}
考虑使用以下 `MeshPolicy` 的 Istio 网格:
@ -45,7 +46,7 @@ spec:
mode: ISTIO_MUTUAL
{{< /text >}}
## 哪些目标规则和策略与服务有关{#which-destination-rules-and-policies-are-relevant-to-a-service}
## 哪些目标规则和策略与服务有关 {#which-destination-rules-and-policies-are-relevant-to-a-service}
为了有效解决双向 TLS 冲突,加深对目标规则和策略是如何影响到达服务的流量的理解会很有帮助。
考虑一个在 `my-namespace` 命名空间中的 `my-service` 示例服务。
@ -68,9 +69,9 @@ spec:
最后请注意遵循这些规则时Istio 不会应用任何继承概念。第一个符合匹配条件的资源将被使用。
## 如何处理{#how-to-resolve}
## 如何处理 {#how-to-resolve}
检查输出信息,您将看到类似下面的信息:
检查输出的消息,您将看到类似下面的消息:
{{< text plain >}}
Error [IST0113] (DestinationRule default-rule.istio-system) A DestinationRule

View File

@ -5,11 +5,12 @@ owner: istio/wg-user-experience-maintainers
test: no
---
当一个 Deployment 的 Pod 对应的多个 Service 在相同端口上定义了不同的协议会出现此消息。
当 Deployment 的 Pod 被关联到多个使用相同端口但使用不同协议的 Service 时,
会出现此消息。
## 示例 {#example}
例如包含以下 Service
例如包含以下 Service 的 Istio 网格
{{< text yaml >}}
apiVersion: v1
@ -37,6 +38,6 @@ spec:
app: productpage
{{< /text >}}
这个示例展示了使用 HTTP 和 TCP 协议同时关联 9080 端口。
这个示例展示了使用 HTTP 和 TCP 协议同时关联到了 9080 端口。
不可以存在两个 Service 在同一个端口上使用不同协议。

View File

@ -5,9 +5,10 @@ owner: istio/wg-user-experience-maintainers
test: no
---
当端口不遵循 [Istio 服务端口命名约定](/zh/docs/ops/configuration/traffic-management/protocol-selection/)或端口未命名时,会出现此消息。
当端口不遵循 [Istio 服务端口命名约定](/zh/docs/ops/configuration/traffic-management/protocol-selection/)或端口未命名时,
会出现此消息。
## 示例{#example}
## 示例 {#example}
您将收到这条消息:
@ -15,7 +16,7 @@ test: no
Info [IST0118] (Service httpbin.default) Port name foo-http (port: 80, targetPort: 80) doesn't follow the naming convention of Istio port.
{{< /text >}}
当您的集群有以下 service 时:
当您的集群有以下 Service 时:
{{< text yaml >}}
apiVersion: v1
@ -33,13 +34,15 @@ spec:
app: httpbin
{{< /text >}}
在这个示例中,端口 `foo-http` 并未遵循这个语法:`name: <protocol>[-<suffix>]`。
在这个示例中,端口`foo-http` 不符合命名语法:`name: <protocol>[-<suffix>]`。
## 如何修复{#how-to-resolve}
## 如何修复 {#how-to-resolve}
- 如果您知道 service 端口的协议,将端口重命名为 `<protocol>[-<suffix>]` 格式就行;
- 如果您不知道 service 端口的协议,您需要[从 Prometheus 查询指标](/zh/docs/tasks/observability/metrics/querying-metrics/)
- 查询 `istio_requests_total{reporter="destination",destination_service_name="SERVICE_NAME",response_code="200"}[TIME_RANGE]`。如果您使用 Mixer v2 版本,
也可以查询 `istio_requests_total{reporter="destination",destination_service_name="SERVICE_NAME",response_code="200",destination_port="TARGET_PORT"}[TIME_RANGE]`
- 如果有输出,您可以从记录中找到 `request_protocol`。例如,如果 `request_protocol``http`,则将端口重命名为 `http-foo`
- 如果您知道 Service 端口的协议,将端口重命名为 `<protocol>[-<suffix>]` 格式就行;
- 如果您不知道 Service 端口的协议,您需要[从 Prometheus 查询指标](/zh/docs/tasks/observability/metrics/querying-metrics/)
- 查询 `istio_requests_total{reporter="destination",destination_service_name="SERVICE_NAME",response_code="200"}[TIME_RANGE]`
如果您使用遥测指标覆盖,也可以查询
`istio_requests_total{reporter="destination",destination_service_name="SERVICE_NAME",response_code="200",destination_port="TARGET_PORT"}[TIME_RANGE]`
- 如果有输出,您可以从记录中找到 `request_protocol`。例如,
如果 `request_protocol``http`,则将端口重命名为 `http-foo`
- 如果没有输出,您可以将端口保持原样。