A preliminary study of Istio 1.7 (1.7.4)

1. Installation

# 默认使用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

Three, Istio sidecar priority start

Since pod content containers are started in sequence according to the declaration order in spec.containers, and initContainers will be executed before all containers are started, the start order of containers is as follows:

That is, istio-init modifies the iptables in the pod so that istio-proxy takes over all traffic in the pod (all network requests in the app need to go through istio-proxy), and if a network request is initiated during the app startup, istio-proxy has The startup may not be completed yet, causing network abnormalities.
It is announced in the change notes of istio 1.7 that the values.global.proxy.holdApplicationUntilProxyStarts configuration option is supported to support setting the sidecar priority start,
values.global.proxy.holdApplicationUntilProxyStarts is closed by default and can be turned on by --set values.global.proxy.holdApplicationUntilProxyStarts=true. The impact of this feature is as follows:
(1) Put the sidecar istio-proxy container in the first position in pod containers (that is, start first);
Insert picture description here

(2) has been arranged to ensure istio-proxy lifecycle sidecar container promoter has been blocked (blocking other containers start the POD) prior successful;
Insert picture description here
on Istio sidecar prioritized startup, refer to:
1. The order of execution within the control pod container several posture
2.Github -issues-App container unable to connect to network before sidecar is fully running #11130
3. How does Istio 1.7 ensure the startup sequence of sidecar?
There are mainly the following implementation methods:

Use postStart in K8s lifecycle to block other containers from starting;
(1) Block sidecar until it starts successfully, same as Istio implementation

(2) Block the app container so that the app container listens to the sidecar startup port. If the sidecar startup port cannot be monitored, restart the app container (until the sidecar is ready to start)
Insert picture description here

Use lifecycle -> type: Sidecar in K8s 1.18

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