Istio 1.7初探（1.7.4）

一、安装

# 默认使用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的启动顺序的
主要有以下几种实现方式：

1. 利用K8s lifecycle中postStart阻塞其他容器启动；
   （1）阻塞sidecar直到其启动成功，同Istio实现
   
   

（2）阻塞app容器，使app容器监听sidecar启动端口，若监听sidecar启动端口不通，则重启app容器（直到sidecar启动就绪）

2. 利用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