Istio Sidecar启动顺序 - 导致的应用容器网络不通

一、问题

线上应用集成了Spring Cloud K8S Config模块，在应用启动时会读取K8S ConfigMap作为配置，最近观察到线上应用在启动时报如下异常日志（偶发，并不是一直出现），提示应用无法获取K8S ConfigMap配置，并且K8s ConfigMap中的配置也没有实际生效。

2023-02-28 11:18:16.950+0800 [main] WARN  o.s.c.k.f.c.Fabric8ConfigMapPropertySource - 
`Can't read configMap with name: [my-app] in namespace: [my-app-ns]. Ignoring.`
io.fabric8.kubernetes.client.KubernetesClientException: 
`Operation: [get]  for kind: [ConfigMap]  with name: [my-app]  in namespace: [my-app-ns]  failed`.
...
Caused by: java.net.ConnectException: `Failed to connect to /10.96.0.1:443`at okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.kt:297)
...
Caused by: java.net.ConnectException: `Connection refused (Connection refused)`at java.base/java.net.PlainSocketImpl.socketConnect(Native Method)at java.base/java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)	
...

在排除了K8S RBAC权限配置问题、K8S集群网络问题后，最终注意到该后端应用部署时集成了Istio，也即自动注入了Istio Sidecar。
由于pod内容器按照spec.containers中的声明顺序依次启动，而initContainers会在所有容器启动前执行，故容器的启动顺序如下：

即istio-init修改pod内iptables令istio-proxy接管pod内所有流量（令app内的所有网络请求都需要经过istio-proxy），而app启动的过程中若发起网络请求，此时istio-proxy有可能还没有启动完成，导致网络异常。
也即是应用读取K8S ConfigMap时，istio-proxy还没启动完成导致网络连接被拒绝。
以上问题的解决方案就是使应用容器在istio-proxy启动成功后再启动，如此便可避免网络异常问题。

二、Istio 1.7及其之后版本的解决方案

在istio 1.7的change notes中宣布支持values.global.proxy.holdApplicationUntilProxyStarts配置选项以支持设置sidecar优先启动，
values.global.proxy.holdApplicationUntilProxyStarts默认关闭，可通过如下设置开启：

--set values.global.proxy.holdApplicationUntilProxyStarts=true

2.1 方式1：安装Istio时全局设置

# 默认使用default profile（可通过--set profile=default|demo|...调整）
istioctl install
# 设置sidecar优先启动（且sidecar启动成功后再启动其他应用容器） - 1.7新特性
--set values.global.proxy.holdApplicationUntilProxyStarts=true

2.2 方式2：在应用Deployment通过annotation设置

注：
此种方式暂未实际测试，暂无Istio 1.7+环境，根据Istio官方文档整理而来，
具体Istio官方文档说明参见：
https://istio.io/latest/docs/reference/config/istio.mesh.v1alpha1/#ProxyConfig

核心annotations如下：

annotations:# 重点：配置proxy - 设置proxy启动成功后再启动其他应用proxy.istio.io/config: |holdApplicationUntilProxyStarts: true

具体设置如下：

apiVersion: apps/v1
kind: Deployment
metadata:name: my-applabels:app: my-appversion: v1
spec:selector:matchLabels:app: my-appversion: v1replicas: 1template:metadata:labels:app: my-appversion: v1annotations:# 开启Istio Sidecar自动注入sidecar.istio.io/inject: true# 重点：配置proxy - 设置proxy启动成功后再启动其他应用proxy.istio.io/config: |holdApplicationUntilProxyStarts: truespec:containers:- name: appimage: registry/app:latestports:- name: http-portcontainerPort: 8080protocol: TCP       

2.3 holdApplicationUntilProxyStarts启用效果

启用holdApplicationUntilProxyStarts为true，实际效果如下：
（1）将sidecar istio-proxy容器放到pod containers中的第一位（即最先启动）；

（2）设置istio-proxy lifecycle已保证sidecar容器启动成功前一直阻塞（阻塞pod内其他容器启动）；

三、Istio 1.7之前的解决方案

Istio 1.7之前的版本并未提供holdApplicationUntilProxyStarts配置，可结合K8S lifecycle达到同样目的，
即阻塞应用容器，使应用容器监听istio-proxy启动端口，若监听istio-proxy启动端口不通，则重启应用容器（直到istio-proxy启动就绪）。
具体说明可参见：https://github.com/istio/istio/issues/11130#issuecomment-506659562

核心配置如下：

# 注：此处配置需结合Istio Sidecar注入一起使用，若未开启Istio Sidecar，则移除此配置
lifecycle:postStart:httpGet:path: /healthz/readyport: 15020scheme: HTTP

具体设置如下：

apiVersion: apps/v1
kind: Deployment
metadata:name: my-applabels:app: my-appversion: v1
spec:selector:matchLabels:app: my-appversion: v1replicas: 1template:metadata:labels:app: my-appversion: v1annotations:# 开启Istio Sidecar自动注入sidecar.istio.io/inject: truespec:containers:- name: appimage: registry/app:latestports:- name: http-portcontainerPort: 8080protocol: TCP# 阻塞app容器，使app容器监听sidecar启动端口，若监听sidecar启动端口不通，则重启app容器（直到sidecar启动就绪）lifecycle:postStart:httpGet:path: /healthz/readyport: 15020

实际部署时，可以观察到之前无法读取K8S ConfigMap的日志也会出现，出现此日志则说明Istio Sidecar还未启动成功（网络不通），之后K8S会重启应用容器，再次观察日志则读取K8S ConfigMap成功（无报错日志）。如此通过让应用容器监听Istio Sidecar Readiness Probe，以迫使应用容器在Istio Sidecar未启动成功前反复重启应用容器自身，以保证最终应用容器启动后Istio Sidecar已经启动完成。

---

参考：
控制pod内container执行顺序的几种姿势
Istio 1.7 是如何保证sidecar的启动顺序的
Github - issues - App container unable to connect to network before sidecar is fully running #11130