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啟動就緒）

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