在K8S部署中，有时候容器启动顺序因为我们业务需要是有要求的，比如业务服务可能需要在 配置中心、注册的中心 启动后才启动，那么该如何呢？
1. 方法一container 直接sleep 2. 方法二initcontainer 里面until curl ==200;do sleep 2;done
3。 普通容器放前面加 poststart until curl ==200;do sleep 2;done 或者 - pilot-agent wait命令检查
4. istio 插件 补丁功能
一个Pod中容器的启动是有顺序的，排在前面容器的先启动。同时第一个容器执行完ENTRYPOINT和PostStart之后（异步执行，无法确定顺序），k8s才会创建第二个容器（这样的话就可以保证第一个容器创建多长时间后再启动第二个容器）
如果我们PostStart阶段去检测容器是否ready，那么只有在ready后才去执行下一个容器
在K8S部署中，有时候容器启动顺序因为我们业务需要是有要求的，比如业务服务可能需要在 配置中心、注册的中心 启动后才启动，那么该如何呢？
我们通过 initContainer 来阻塞启动，如下以业务服务需要在apollo配置中心启动后才启动需求为例：
initContainers:
- command:
- sh
- -c
- until curl -m5 -s apollo-configservice-fat.my-namespace.svc.cluster.local:6166/info; do echo waiting for config; sleep 5; done;
image: harbor.shanhy.com:443/dockerhub_proxy/yauritux/busybox-curl:latest
name: wait-for-config
apiVersion: v1
kind: Podmetadata:
name: sidecar-starts-firstspec:
containers: - name: istio-proxy
image: lifecycle:
postStart:
exec:
command:
- pilot-agent
- wait
- name: application
image: my-application
背景
一些服务在往 istio 上迁移过渡的过程中，有时可能会遇到 Pod 启动失败，然后一直重启，排查原因是业务启动时需要调用其它服务(比如从配置中心拉取配置)，如果失败就退出，没有重试逻辑。调用失败的原因是 envoy 还没就绪(envoy也需要从控制面拉取配置，需要一点时间)，导致业务发出的流量无法被处理，从而调用失败(参考 k8s issue #65502 )。
最佳实践
目前这类问题的最佳实践是让应用更加健壮一点，增加一下重试逻辑，不要一上来调用失败就立马退出，如果嫌改动麻烦，也可以在启动命令前加下 sleep，等待几秒 (可能不太优雅)。
如果不想对应用做任何改动，也可以参考下面的规避方案。
规避方案: 调整 sidecar 注入顺序
在 istio 1.7，社区通过给 istio-injector 注入逻辑增加一个叫 HoldApplicationUntilProxyStarts 的开关来解决了该问题，开关打开后，proxy 将会注入到第一个 container。
查看 istio-injector 自动注入使用的 template，可以知道如果打开了 HoldApplicationUntilProxyStarts 就会为 sidecar 添加一个 postStart hook:
它的目的是为了阻塞后面的业务容器启动，要等到 sidecar 完全启动了才开始启动后面的业务容器。
这个开关配置分为全局和局部两种，以下是启用方法。
全局配置:
修改 istio 的 configmap 全局配置:
kubectl -n istio-system edit cm istio
在 defaultConfig 下加入 holdApplicationUntilProxyStarts: true
apiVersion: v1
data:
mesh: |-
defaultConfig:
holdApplicationUntilProxyStarts: true
meshNetworks: 'networks: {}'
kind: ConfigMap
若使用 IstioOperator，defaultConfig 修改 CR 字段 meshConfig:
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
namespace: istio-system
name: example-istiocontrolplane
spec:
meshConfig:
defaultConfig:
holdApplicationUntilProxyStarts: true
局部配置:
如果使用 istio 1.8 及其以上的版本，可以为需要打开此开关的 Pod 加上 proxy.istio.io/config 注解，将 holdApplicationUntilProxyStarts 置为 true，示例:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
annotations:
proxy.istio.io/config: |
holdApplicationUntilProxyStarts: true
labels:
app: nginx
spec:
containers:
- name: nginx
image: "nginx"
需要注意的是，打开这个开关后，意味着业务容器需要等 sidecar 完全 ready 后才能启动，会让 Pod 启动速度变慢一些。在需要快速扩容应对突发流量场景可能会显得吃力，所以建议是自行评估业务场景，利用局部配置的方法，只给需要的业务打开此开关。
