Sidecar未就绪导致Pod启动失败

加入网格的服务有时可能遇到Pod启动失败，且一直重启。排查原因发现业务容器与外部通信时流量会经过istio-proxy容器，但业务容器比istio-proxy容器先启动，在istio-proxy容器没启动成功时，业务容器已经启动，与外部通信将会失败，Pod一直重启。

在Istio 1.7及以后版本，社区通过给istio-injector注入逻辑增加一个叫HoldApplicationUntilProxyStarts的开关来解决了该问题，开关打开后，Proxy将会注入到第一个Container，istio-proxy容器先于业务容器启动。

开关配置分为全局和局部两种，下面介绍两种启用方法。

需要注意的是，打开开关后，意味着业务容器需要等Sidecar完全Ready后才能启动，会让Pod启动速度变慢一些。在需要快速扩容应对突发流量场景可能会显得吃力，所以建议您自行评估业务场景，利用局部配置的方法，只给需要的业务打开此开关。

全局配置
1. 执行以下命令，编辑IOP CR资源。
  kubectl edit iop private-data-plane -n istio-system
  
  在spec.values.global.proxy字段下添加以下配置：
```
holdApplicationUntilProxyStarts: true
```
2. 执行以下命令，确认最新日志无报错。
  kubectl logs -n istio-operator $(kubectl get po -n istio-operator | awk '{print $1}' | grep -v NAME)
3. 执行以下命令，确认IOP CR是正常状态。
  kubectl get iop -n istio-system
4. 执行以下命令，滚动升级已添加到网格的服务。
  kubectl rollout restart deployment nginx -n default
  
  其中，nginx为示例服务，default为命名空间，请替换为实际取值。
5. 执行以下命令，确认Pod重启成功。
  kubectl get pod -n default | grep nginx
6. 执行以下命令，确认Pod正常添加了postStart lifecycle，并且istio-proxy容器放在了第一个位置。
  kubectl edit pod nginx-7bc96f87b9-l4dbl
局部配置
如果使用Istio 1.8及其以上的版本，可以为需要打开此开关的Pod加上proxy.istio.io/config注解，将holdApplicationUntilProxyStarts置为true。

以default命名空间下nginx服务为例，用户其他服务操作类似。

kubectl edit deploy nginx -n default

在spec.template.metadata.annotations字段下添加以下配置：
```
proxy.istio.io/config: |
  holdApplicationUntilProxyStarts: true
```