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 中容器的顺序进行启动。

虽然是顺序启动,但是并不能保证当一个容器依赖于另外一个容器时,在依赖的容器启动完成后再进行启动,istio proxy sidecar 就是一个常见问题,经常出现503问题。

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

2. 为第一个容器注入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