一、安装
# 默认使用default profile(可通过--set profile=default|demo|...调整)
istioctl install
# enable access logs(启用isito-proxy访问日志)
--set meshConfig.accessLogFile=/dev/stdout
# 设置sidecar优先启动(且sidecar启动成功后再启动其他应用容器) - 1.7新特性
--set values.global.proxy.holdApplicationUntilProxyStarts=true
二、Istio profile
三、Istio sidecar优先启动
由于pod内容器按照spec.containers中的声明顺序依次启动,而initContainers会在所有容器启动前执行,故容器的启动顺序如下:
即istio-init修改pod内iptables令istio-proxy接管pod内所有流量(令app内的所有网络请求都需要经过istio-proxy),而app启动的过程中若发起网络请求,此时istio-proxy有可能还没有启动完成,导致网络异常。
在istio 1.7的change notes中宣布支持values.global.proxy.holdApplicationUntilProxyStarts配置选项以支持设置sidecar优先启动,
values.global.proxy.holdApplicationUntilProxyStarts默认关闭,可通过–set values.global.proxy.holdApplicationUntilProxyStarts=true开启,该特性影响如下:
(1)将sidecar istio-proxy容器放到pod containers中的第一位(即最先启动);
(2)设置istio-proxy lifecycle已保证sidecar容器启动成功前一直阻塞(阻塞pod内其他容器启动);
关于Istio sidecar优先启动,可参考:
1.控制pod内container执行顺序的几种姿势
2.Github - issues - App container unable to connect to network before sidecar is fully running #11130
3.Istio 1.7 是如何保证sidecar的启动顺序的
主要有以下几种实现方式:
-
利用K8s lifecycle中postStart阻塞其他容器启动;
(1)阻塞sidecar直到其启动成功,同Istio实现
(2)阻塞app容器,使app容器监听sidecar启动端口,若监听sidecar启动端口不通,则重启app容器(直到sidecar启动就绪)
- 利用K8s 1.18中的 lifecycle -> type: 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