What Can I Do If A Pod Cannot Be Started Due to Unready Sidecar

Description

Pods of services managed by a mesh may fail to be started and keep restarting. When the service container communicates with external systems, the traffic passes through the istio-proxy container. However, the service container is started earlier than the istio-proxy container. As a result, the communication with external systems fails and the pod keeps restarting.

Solution

In Istio 1.7 and later versions, the community adds a switch named HoldApplicationUntilProxyStarts to the istio-injector injection logic. After the switch is enabled, the proxy is injected to the first container and the istio-proxy container is started earlier than the service container.

The switch can be configured globally or locally. The following describes two ways to enable the switch.

After this switch is enabled, the service container cannot be started until the sidecar is fully ready, which slows down pod startup and reduces scalability for burst traffic. You are advised to evaluate service scenarios and enable this switch only for required services.