mirror of https://github.com/istio/istio.io.git
* Sync #15443 prepare for 1.23 update into Chinese * fix
This commit is contained in:
Wilson Wu
GitHub
parent
6e15bbfd9d
commit
10a8b3c7a1
|
|
@ -1,52 +0,0 @@
|
|||
---
|
||||
title: 等待应用的配置资源状态就绪
|
||||
description: 如何等待资源达到给定的就绪状态。
|
||||
weight: 15
|
||||
owner: istio/wg-user-experience-maintainers
|
||||
test: yes
|
||||
---
|
||||
|
||||
{{< warning >}}
|
||||
该功能还处于 `Alpha` 阶段，参考 [Istio 功能状态](/zh/about/feature-stages/)。
|
||||
欢迎在 [Istio 用户经验探讨区](https://discuss.istio.io/c/UX/23)提出您的反馈。
|
||||
目前这些功能仅在单控制平面低容量存储版本的集群中进行了测试。
|
||||
{{< /warning >}}
|
||||
|
||||
Istio 的网格配置是声明式的，意味着您声明或修改一个配置信息不会立即生效而是随着时间慢慢应用到网格中。
|
||||
因此您的命令很可能在相关资源就绪之前就开始使用了网格服务。
|
||||
|
||||
在 Istio 1.6 及之后的版本，您可以使用 `kubectl wait` 命令对
|
||||
Istio 应用配置更改到网格中的方式实行更好的掌控。为了实现该目的，
|
||||
`kubectl wait` 命令监控资源状态的 [`status`](/zh/docs/reference/config/config-status/)
|
||||
字段，该字段在 Istio 完成配置更改时会被更新。
|
||||
|
||||
## 开始之前 {#before-you-begin}
|
||||
|
||||
该功能在默认情况下是关闭的。在安装的过程中使用以下命令设置 `status`
|
||||
的相关配置参数开启该功能，此外您还必须启用 `config_distribution_tracking`
|
||||
参数。
|
||||
|
||||
{{< text syntax=bash snip_id=install_with_enable_status >}}
|
||||
$ istioctl install --set values.pilot.env.PILOT_ENABLE_STATUS=true --set values.pilot.env.PILOT_ENABLE_CONFIG_DISTRIBUTION_TRACKING=true --set values.global.istiod.enableAnalysis=true
|
||||
{{< /text >}}
|
||||
|
||||
## 等待资源就绪 {#wait-for-resource-readiness}
|
||||
|
||||
您可以先 `apply` 更改的内容，然后等待完成。例如，等待下面的
|
||||
`virtual service`，可以使用以下命令：
|
||||
|
||||
{{< text syntax=bash snip_id=apply_and_wait_for_httpbin_vs >}}
|
||||
$ kubectl apply -f @samples/httpbin/httpbin.yaml@
|
||||
$ kubectl apply -f @samples/httpbin/httpbin-gateway.yaml@
|
||||
$ kubectl wait --for=condition=Reconciled virtualservice/httpbin
|
||||
virtualservice.networking.istio.io/httpbin condition met
|
||||
{{< /text >}}
|
||||
|
||||
该命令会一直保持阻塞状态，直到 `virtual service` 被成功下发到网格内所有的代理中，
|
||||
或者命令执行超时。
|
||||
|
||||
当您在脚本中使用 `kubectl wait` 命令时，返回码 `0` 代表成功，非 `0` 代表超时状态。
|
||||
|
||||
关于更多用法和语法信息请参考
|
||||
[kubectl wait](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#wait)
|
||||
命令。
|
||||
|
|
@ -5,17 +5,17 @@ weight: 21
|
|||
---
|
||||
|
||||
{{< warning >}}
|
||||
此功能处于 Alpha 阶段，请参见 [Istio功能状态](/zh/about/feature-stages/)。
|
||||
欢迎您的反馈意见 [Istio用户体验讨论](https://discuss.istio.io/c/UX/23)。
|
||||
此功能处于 Alpha 阶段，请参见 [Istio 功能状态](/zh/about/feature-stages/)。
|
||||
欢迎您的反馈意见 [Istio 用户体验讨论](https://discuss.istio.io/c/UX/23)。
|
||||
当前，此功能仅针对具有单个控制平面版本的单个小规模集群进行了测试。
|
||||
|
||||
{{< /warning >}}
|
||||
|
||||
Istio 1.6及更高版本使用资源的 `status` 字段提供有关配置更改在网格中传播的信息。
|
||||
Istio 1.6 及更高版本使用资源的 `status` 字段提供有关配置更改在网格中传播的信息。
|
||||
默认情况下，状态为禁用，可以在安装过程中使用以下命令启用状态：
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl install --set values.pilot.env.PILOT_ENABLE_STATUS=true --set values.pilot.env.PILOT_ENABLE_CONFIG_DISTRIBUTION_TRACKING=true --set values.global.istiod.enableAnalysis=true
|
||||
$ istioctl install --set values.pilot.env.PILOT_ENABLE_STATUS=true --set values.global.istiod.enableAnalysis=true
|
||||
{{< /text >}}
|
||||
|
||||
`status` 字段包含资源配置的状态，其中包含各种信息性消息，包括：
|
||||
|
|
@ -24,30 +24,19 @@ $ istioctl install --set values.pilot.env.PILOT_ENABLE_STATUS=true --set values.
|
|||
* 有多少个数据平面实例与之关联。
|
||||
* 工具输出信息，例如 `istioctl analyze`。
|
||||
|
||||
例如，`kubectl wait` 命令监视 `status` 字段以确定是否取消阻止配置并继续。
|
||||
有关更多信息，请参见[等待资源状态以应用配置](/zh/docs/ops/configuration/mesh/config-resource-ready/)。
|
||||
|
||||
## 查看 `status` 字段 {#view-the-status-field}
|
||||
|
||||
您可以使用 `kubectl get` 查看资源中 `status` 字段的内容。
|
||||
例如，要查看虚拟服务的状态，请使用以下命令：
|
||||
您可以使用 `kubectl get` 查看资源中 `status` 字段的内容。例如，要查看虚拟服务的状态，请使用以下命令：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get virtualservice <service-name> -o yaml
|
||||
{{< /text >}}
|
||||
|
||||
在输出结果中，`status` 字段包含多个嵌套字段，
|
||||
其中包含详细信息关于通过网格传播配置更改的过程。
|
||||
在输出结果中，`status` 字段包含多个嵌套字段，其中包含详细信息关于通过网格传播配置更改的过程。
|
||||
|
||||
{{< text yaml >}}
|
||||
status:
|
||||
conditions:
|
||||
- lastProbeTime: null
|
||||
lastTransitionTime: "2019-12-26T22:06:34Z"
|
||||
message: "61/122 complete"
|
||||
reason: "stillPropagating"
|
||||
status: "False"
|
||||
type: Reconciled
|
||||
- lastProbeTime: null
|
||||
lastTransitionTime: "2019-12-26T22:06:56Z"
|
||||
message: "1 Error and 1 Warning found. See validationMessages field for details"
|
||||
|
|
@ -65,36 +54,25 @@ status:
|
|||
|
||||
## `conditions` 字段 {#the-conditions-field}
|
||||
|
||||
conditions 字段代表资源的可能状态。
|
||||
一个 condition 的 `type` 字段可以具有以下值：
|
||||
conditions 字段代表资源的可能状态。一个 condition 的 `type` 字段可以具有以下值：
|
||||
|
||||
* `PassedAnalysis`
|
||||
* `Reconciled`
|
||||
|
||||
当您应用配置时，每种类型的条件都会添加到 `conditions` 字段中。
|
||||
|
||||
`Reconciled` 类型条件的 `status` 字段被初始化为 `False`，
|
||||
以表明资源仍在分配给所有代理的过程中。
|
||||
|
||||
当协调完成后，状态将变为 `True`。
|
||||
根据集群的速度，`status` 字段可能会立即转换为 `True`。
|
||||
|
||||
`PassedAnalysis` 类型条件的 `status` 字段的值为 `True` 或 `False`，
|
||||
取决于 Istio 的后台分析器是否检测到您的配置有问题。
|
||||
如果为 `False`，则将在 `validationMessages` 字段中详细说明问题。
|
||||
|
||||
`PassedAnalysis` 类型条件仅是一个信息字段。
|
||||
它不会阻止应用无效的配置。该状态可能表示验证失败，但是应用配置成功。
|
||||
`PassedAnalysis` 类型条件仅是一个信息字段。它不会阻止应用无效的配置。该状态可能表示验证失败，但是应用配置成功。
|
||||
这意味着 Istio 能够设置新配置，但是该配置无效，可能是由于语法错误或类似问题。
|
||||
|
||||
## `validationMessages` 字段 {#the-validation-messages-field}
|
||||
|
||||
如果验证失败，请检查 `validationMessages` 字段以了解更多信息。
|
||||
`validationMessages` 字段包含有关验证过程的详细信息，
|
||||
如果验证失败，请检查 `validationMessages` 字段以了解更多信息。`validationMessages` 字段包含有关验证过程的详细信息，
|
||||
例如指示 Istio 无法应用配置的错误消息，以及未导致错误的警告或参考消息。
|
||||
|
||||
如果类型为 `PassedValidation` 的条件的状态为 `False`，
|
||||
则会有 `validationMessages` 字段来解释该问题。
|
||||
如果类型为 `PassedValidation` 的条件的状态为 `False`，则会有 `validationMessages` 字段来解释该问题。
|
||||
当 `PassedValidation` 状态为 `True` 时，可能会出现消息，因为这些消息是信息性消息。
|
||||
|
||||
有关验证消息的示例，请参见[配置分析消息](/zh/docs/reference/config/analysis/)。
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ istio-sidecar-injector-canary 2 114s
|
|||
您可以通过运行以下命令来验证 `istio-ingress` Gateway 是否正在使用 `canary` 修订版本：
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl proxy-status | grep "$(kubectl -n istio-system get pod -l app=istio-ingressgateway -o jsonpath='{.items..metadata.name}')" | awk '{print $10}'
|
||||
$ istioctl proxy-status | grep "$(kubectl -n istio-system get pod -l app=istio-ingressgateway -o jsonpath='{.items..metadata.name}')" | awk -F '[[:space:]][[:space:]]+' '{print $8}'
|
||||
istiod-canary-6956db645c-vwhsk
|
||||
{{< /text >}}
|
||||
|
||||
|
|
@ -111,13 +111,15 @@ istiod-canary-6956db645c-vwhsk
|
|||
$ kubectl label namespace test-ns istio-injection- istio.io/rev=canary
|
||||
{{< /text >}}
|
||||
|
||||
命名空间更新后，您需要重新启动 Pod 才能触发重新注入。一种重启命名空间 `test-ns` 中所有 Pod 的方法是：
|
||||
命名空间更新后，您需要重新启动 Pod 才能触发重新注入。
|
||||
一种重启命名空间 `test-ns` 中所有 Pod 的方法是：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl rollout restart deployment -n test-ns
|
||||
{{< /text >}}
|
||||
|
||||
当 Pod 被重新注入时，它们将被配置为指向 `istiod-canary` 控制平面。您可以使用 `istioctl proxy-status` 来验证。
|
||||
当 Pod 被重新注入时，它们将被配置为指向 `istiod-canary`
|
||||
控制平面。您可以使用 `istioctl proxy-status` 来验证。
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl proxy-status | grep "\.test-ns "
|
||||
|
|
@ -215,8 +217,8 @@ $ istioctl tag set default --revision {{< istio_full_version_revision >}}
|
|||
|
||||
## 卸载旧的控制平面 {#uninstall-old-control-plane}
|
||||
|
||||
升级控制平面和数据平面之后，您可以卸载旧的控制平面。例如，
|
||||
以下命令卸载修订版本的控制平面 `{{< istio_previous_version_revision >}}-1`：
|
||||
升级控制平面和数据平面之后，您可以卸载旧的控制平面。
|
||||
例如，以下命令卸载修订版本的控制平面 `{{< istio_previous_version_revision >}}-1`：
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl uninstall --revision {{< istio_previous_version_revision >}}-1 -y
|
||||
|
|
@ -241,7 +243,7 @@ istiod-canary-55887f699c-t8bh8 1/1 Running 0 27m
|
|||
|
||||
## 卸载金丝雀控制平面 {#uninstall-canary-control-plane}
|
||||
|
||||
如果您决定回滚到旧的控制平面，而不是完成 Canary 升级，则可以使用以下命令卸载 Canary 修订版：
|
||||
如果您决定回滚到旧的控制平面，而不是完成金丝雀升级，则可以使用以下命令卸载金丝雀修订版：
|
||||
|
||||
{{< text bash >}}
|
||||
$ istioctl uninstall --revision=canary -y
|
||||
|
|
|
|||
|
|
@ -247,13 +247,13 @@ test: yes
|
|||
|
||||
{{< text bash >}}
|
||||
$ kubectl exec "$FORTIO_POD" -c istio-proxy -- pilot-agent request GET stats | grep httpbin | grep pending
|
||||
cluster.outbound|8000||httpbin.default.svc.cluster.local.circuit_breakers.default.remaining_pending: 1
|
||||
cluster.outbound|8000||httpbin.default.svc.cluster.local.circuit_breakers.default.rq_pending_open: 0
|
||||
cluster.outbound|8000||httpbin.default.svc.cluster.local.circuit_breakers.high.rq_pending_open: 0
|
||||
cluster.outbound|8000||httpbin.default.svc.cluster.local.upstream_rq_pending_active: 0
|
||||
cluster.outbound|8000||httpbin.default.svc.cluster.local.upstream_rq_pending_failure_eject: 0
|
||||
cluster.outbound|8000||httpbin.default.svc.cluster.local.upstream_rq_pending_overflow: 21
|
||||
cluster.outbound|8000||httpbin.default.svc.cluster.local.upstream_rq_pending_total: 29
|
||||
cluster.outbound|8000||httpbin.default.svc.cluster.local;.circuit_breakers.default.remaining_pending: 1
|
||||
cluster.outbound|8000||httpbin.default.svc.cluster.local;.circuit_breakers.default.rq_pending_open: 0
|
||||
cluster.outbound|8000||httpbin.default.svc.cluster.local;.circuit_breakers.high.rq_pending_open: 0
|
||||
cluster.outbound|8000||httpbin.default.svc.cluster.local;.upstream_rq_pending_active: 0
|
||||
cluster.outbound|8000||httpbin.default.svc.cluster.local;.upstream_rq_pending_failure_eject: 0
|
||||
cluster.outbound|8000||httpbin.default.svc.cluster.local;.upstream_rq_pending_overflow: 21
|
||||
cluster.outbound|8000||httpbin.default.svc.cluster.local;.upstream_rq_pending_total: 29
|
||||
{{< /text >}}
|
||||
|
||||
可以看到 `upstream_rq_pending_overflow` 值 `21`，这意味着，目前为止已有 21 个调用被标记为熔断。
|
||||
|
|
|
|||
Loading…
Reference in New Issue