istio中的实现
今天在测试istio新功能时注意到istio中添加了values.global.proxy.holdApplicationUntilProxyStarts，使sidecar注入器在pod容器列表的开始处注入sidecar，并将其配置为阻止所有其他容器的开始，直到代理就绪为止。
在查看代码后发现对istio-proxy容器注入了以下内容。
lifecycle:
postStart:
exec:
command:
- pilot-agent
- wait
熟悉k8s人可能会记得，poststart 不能保证在调用Container的入口点之前先调用postStart处理程序，那这样怎么通过postStart保证业务容器的延迟启动。
这里就来到了一个误区，大家可能都认为pod的初始化容器完成后，将并行启动pod的常规容器，事实上并不是。
容器启动代码
可以看到pod中的容器时顺序启动的，按照pod spec.containers 中容器的顺序进行启动。
https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kuberuntime/kuberuntime_manager.go#L835
https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kuberuntime/kuberuntime_container.go#L174
虽然是顺序启动，但是并不能保证当一个容器依赖于另外一个容器时，在依赖的容器启动完成后再进行启动，istio proxy sidecar 就是一个常见问题，经常出现503问题。
需要将Proxy指定为中的第一个容器spec.containers，但这只是解决方案的一部分，因为它只能确保首先启动代理容器，而不必等待它准备就绪。其他容器立即启动，从而导致容器之间的竞争状态。我们需要防止Kubelet在代理准备好之前启动其他容器。
为第一个容器注入PostStart 生命周期钩子
这样就实现了，如果sidecar容器提供了一个等待该sidecar就绪的可执行文件，则可以在容器的启动后挂钩中调用该文件，以阻止pod中其余容器的启动。
以下方式通过/bin/wait-until-ready.sh保证sidecar container早于application容器启动。
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
tekton中的实现
1.tekton中依赖于entrypoint初始化容器初始化脚本，生成各个容器需要执行的entrypoint，通过挂载目录共享到各个容器，共享entrypoint命令，
2.当所有容器ready时，通过downward-api将ready信息反馈给初始化容器
3.初始化容器开始进行初始化操作
4.初始完成后在共享目录完成后，创建一个文件
5.task容器在执行时会监听文件变化，当需要的文件创建完成，开始执行具体的逻辑
tekton 代码： https://github.com/tektoncd/pipeline/tree/master/cmd/entrypoint
