1.需要将Proxy指定为中的第一个容器spec.containers，但这只是解决方案的一部分，因为它只能确保首先启动代理容器，而不必等待它准备就绪。其他容器立即启动，从而导致容器之间的竞争状态。我们需要防止Kubelet在代理准备好之前启动其他容器。

2.为第一个容器注入PostStart 生命周期钩子
这样就实现了，如果sidecar容器提供了一个等待该sidecar就绪的可执行文件，则可以在容器的启动后挂钩中调用该文件，以阻止pod中其余容器的启动。 kubelet必须等postStart执行完了之后，再开始启动下一个容器。也就是说，假如容器的 PostStart hook 没有返回，kubelet 便不会去创建下一个容器。 （如果poststart失败了，会kill container）

apiVersion: v1
kind: Pod
metadata:
  name: sidecar-starts-first
spec:
  containers:
  - name: sidecar
    image: my-sidecar
    lifecycle:
      postStart:
        exec:
          command:
          - /bin/wait-until-ready.sh
  - name: application
    image: my-application

k8s自有的Sidecar container

从Kubernetes 1.18可以将容器标记为sidecar，以便它们在正常容器之前启动，而在所有其他容器终止后关闭。因此它们仍然像普通容器一样工作，唯一的区别在于它们的生命周期。目前istio并未使用该方式保证istio-proxy容器的启动顺序，可能是基于版本考虑，并且Sidecar container。

但是sidecar 容器只能保证sidecar早于业务容器启动，不能保证业务容器的启动先后顺序。有什么方式保证么？

apiVersion: v1
kind: Pod
metadata:
  name: bookings-v1-b54bc7c9c-v42f6
  labels:
    app: demoapp
spec:
  containers:
  - name: bookings
    image: banzaicloud/allspark:0.1.1
    ...
  - name: istio-proxy
    image: docker.io/istio/proxyv2:1.4.3
    lifecycle:
      type: Sidecar