mirror of https://github.com/istio/istio.io.git
fix additional broken in-doc header links (#15640)
* fix additional broken in-doc header links Signed-off-by: Faseela K <faseela.k@est.tech> * fix lint Signed-off-by: Faseela K <faseela.k@est.tech> * fix lint Signed-off-by: Faseela K <faseela.k@est.tech> --------- Signed-off-by: Faseela K <faseela.k@est.tech>
This commit is contained in:
Faseela K
GitHub
parent
efea7576fe
commit
7c2892d97f
|
|
@ -108,7 +108,7 @@ An exception to this is for protocols declared as HTTP, which will match traffic
|
|||
|
||||
{{< warning >}}
|
||||
Without Istio, the `ports` field of a headless service is not strictly required because requests go directly to pod IPs, which can accept traffic on all ports.
|
||||
However, with Istio the port must be declared in the Service, or it will [not be matched](#unmatched-traffic).
|
||||
However, with Istio the port must be declared in the Service, or it will [not be matched](/docs/ops/configuration/traffic-management/traffic-routing/#unmatched-traffic).
|
||||
{{< /warning >}}
|
||||
|
||||
### ExternalName Services
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ To make debugging easier, the CNI plugin also sends its log to the `istio-cni-no
|
|||
The default log level for the CNI plugin is `info`. To get more detailed log output, you can change the level by editing the `values.cni.logLevel` installation option and restarting the CNI DaemonSet pod.
|
||||
|
||||
The Istio CNI DaemonSet pod log also provides information about CNI plugin installation,
|
||||
and [race condition repairing](/docs/setup/additional-setup/cni/#race-condition-mitigation).
|
||||
and [race condition repairing](/docs/setup/additional-setup/cni/#race-condition--mitigation).
|
||||
|
||||
## Monitoring
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ You can also track CNI installation readiness via the `istio_cni_install_ready`
|
|||
|
||||
## Race condition repair
|
||||
|
||||
By default, the Istio CNI DaemonSet has [race condition mitigation](/docs/setup/additional-setup/cni/#race-condition-mitigation) enabled,
|
||||
By default, the Istio CNI DaemonSet has [race condition mitigation](/docs/setup/additional-setup/cni/#race-condition--mitigation) enabled,
|
||||
which will evict a pod that was started before the CNI plugin was ready.
|
||||
To understand which pods were evicted, look for log lines like the following:
|
||||
|
||||
|
|
@ -79,5 +79,5 @@ search the `istio-cni-node` for the pod ID.
|
|||
|
||||
Another symptom of a malfunctioned CNI plugin is that the application pod is continuously evicted at start-up time.
|
||||
This is typically because the plugin is not properly installed, thus pod traffic redirection cannot be set up.
|
||||
CNI [race repair logic](/docs/setup/additional-setup/cni/#race-condition-mitigation) considers the pod is broken due to the race condition and evicts the pod continuously.
|
||||
CNI [race repair logic](/docs/setup/additional-setup/cni/#race-condition--mitigation) considers the pod is broken due to the race condition and evicts the pod continuously.
|
||||
When running into this issue, check the CNI DaemonSet log for information on why the plugin could not be properly installed.
|
||||
|
|
|
|||
|
|
@ -130,7 +130,7 @@ There is a time gap between a node becomes schedulable and the Istio CNI plugin
|
|||
If an application pod starts up during this time, it is possible that traffic redirection is not properly set up and traffic would be able to bypass the Istio sidecar.
|
||||
|
||||
This race condition is mitigated for the sidecar data plane mode by a "detect and repair" method.
|
||||
Please take a look at [race condition & mitigation](#race-condition--mitigation) section to understand the implication of this mitigation, and for configuration instructions.
|
||||
Please take a look at [race condition & mitigation](/docs/setup/additional-setup/cni/#race-condition--mitigation) section to understand the implication of this mitigation, and for configuration instructions.
|
||||
{{< /tip >}}
|
||||
|
||||
### Handling init container injection for revisions
|
||||
|
|
|
|||
|
|
@ -45,10 +45,10 @@ $ istioctl install --set values.pilot.traceSampling=0.1
|
|||
{{< /text >}}
|
||||
|
||||
Helm values can also be set in an `IstioOperator` CR (YAML file) as described in
|
||||
[Customize Istio settings using the Helm API](#customize-istio-settings-using-the-helm-api), below.
|
||||
[Customize Istio settings using the Helm API](/docs/setup/additional-setup/customize-installation/#customize-istio-settings-using-the-helm-api), below.
|
||||
|
||||
If you want to set Kubernetes resource settings, use the `IstioOperator` API as described in
|
||||
[Customize Kubernetes settings](#customize-kubernetes-settings).
|
||||
[Customize Kubernetes settings](/docs/setup/additional-setup/customize-installation/#customize-kubernetes-settings).
|
||||
{{< /tip >}}
|
||||
|
||||
### Identify an Istio component
|
||||
|
|
|
|||
|
|
@ -379,7 +379,7 @@ After updating the `istio-sidecar-injector` configuration, it affects all
|
|||
future application pod deployments.
|
||||
|
||||
{{< warning >}}
|
||||
Unlike [Envoy passthrough to external services](#envoy-passthrough-to-external-services),
|
||||
Unlike [Envoy passthrough to external services](/docs/tasks/traffic-management/egress/egress-control/#envoy-passthrough-to-external-services),
|
||||
which uses the `ALLOW_ANY` traffic policy to instruct the Istio sidecar proxy to
|
||||
passthrough calls to unknown services,
|
||||
this approach completely bypasses the sidecar, essentially disabling all of Istio's features
|
||||
|
|
|
|||
|
|
@ -129,7 +129,7 @@ Istio 支持这些服务类型，并且与标准的 `ClusterIP` 服务具有完
|
|||
{{< warning >}}
|
||||
在没有 Istio 的情况下，无头服务的 `ports` 字段不是严格必需的，
|
||||
因为请求直接发送到 Pod IP，该 IP 可以在所有端口上接受流量。
|
||||
但是，在使用 Istio 时，必须在服务中声明端口，否则将[不会被匹配](#unmatched-traffic)。
|
||||
但是，在使用 Istio 时，必须在服务中声明端口，否则将[不会被匹配](/zh/docs/ops/configuration/traffic-management/traffic-routing/#unmatched-traffic)。
|
||||
{{< /warning >}}
|
||||
|
||||
### ExternalName 服务 {#externalname-services}
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ CNI 插件的默认日志级别是 `info`。要获得更详细的日志输出，
|
|||
`values.cni.logLevel` 安装选项并重新启动 CNI DaemonSet Pod 来更改级别。
|
||||
|
||||
Istio CNI DaemonSet Pod 日志还提供了有关 CNI
|
||||
插件安装的信息以及[竞争条件和缓解措施](/zh/docs/setup/additional-setup/cni/#race-condition-mitigation)。
|
||||
插件安装的信息以及[竞争条件和缓解措施](/zh/docs/setup/additional-setup/cni/#race-condition--mitigation)。
|
||||
|
||||
## 监控 {#monitoring}
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ CNI DaemonSet 的就绪表明 Istio CNI 插件已被正确安装和配置。
|
|||
|
||||
## 竞争条件和缓解措施 {#race-condition-repair}
|
||||
|
||||
Istio CNI DaemonSet 默认启用[竞争条件和缓解措施](/zh/docs/setup/additional-setup/cni/#race-condition-mitigation)，
|
||||
Istio CNI DaemonSet 默认启用[竞争条件和缓解措施](/zh/docs/setup/additional-setup/cni/#race-condition--mitigation)，
|
||||
这将驱逐在 CNI 插件准备就绪之前启动的 Pod。要了解哪些 Pod 被驱逐，请查找如下所示的日志行：
|
||||
|
||||
{{< text plain >}}
|
||||
|
|
@ -77,6 +77,6 @@ $ kubectl logs POD_NAME -n POD_NAMESPACE -c istio-validation
|
|||
|
||||
CNI 插件出现故障的另一个症状是，应用程序 Pod 在启动时不断被逐出。
|
||||
这通常是因为插件没有被正确安装，因此无法设置 Pod 流量重定向。
|
||||
CNI 的[竞争条件和缓解措施逻辑](/zh/docs/setup/additional-setup/cni/#race-condition-mitigation)
|
||||
CNI 的[竞争条件和缓解措施逻辑](/zh/docs/setup/additional-setup/cni/#race-condition--mitigation)
|
||||
认为由于竞争条件引起的问题导致 Pod 损坏，并连续逐出 Pod。遇到此问题时，请检查 CNI DaemonSet 日志，
|
||||
以获取为什么插件未被正确安装的信息。
|
||||
|
|
|
|||
|
|
@ -151,7 +151,7 @@ $ helm install istiod istio/istiod -n istio-system --set pilot.cni.enabled=true
|
|||
则可能未正确设置流量重定向，流量将能够绕过 Istio Sidecar。
|
||||
|
||||
对于 Sidecar 数据平面模式，此竞争条件可通过“检测和修复”方法缓解。
|
||||
请参阅[竞争条件和缓解](#race-condition-mitigation)部分以了解此缓解措施的含义以及配置说明。
|
||||
请参阅[竞争条件和缓解](/zh/docs/setup/additional-setup/cni/#race-condition--mitigation)部分以了解此缓解措施的含义以及配置说明。
|
||||
{{< /tip >}}
|
||||
|
||||
### 处理修订的 Init 容器注入 {#handling-init-container-injection-for-revisions}
|
||||
|
|
|
|||
Loading…
Reference in New Issue