Configure sidecar proxies

Parameter description

This parameter specifies the minimum CPU and memory resources that the istio-init container requires at runtime and the maximum CPU and memory resources that the container can request in Pods into which sidecar proxies are injected. The istio-init container is an init container that runs when a Pod with an injected sidecar proxy starts. It configures traffic interception routing rules for the sidecar proxy container.

Configuration example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the target sidecar proxy configuration level, and then click Resource Settings.

2. (Optional) In the Resource Settings section, select Configure Resources for istio-init Container.

   This step is required on the Namespace and workload tabs. You can skip this step on the global tab.

3. For Limits on Resources, set CPU to 1 core and Memory to 512 MiB. For Required Resources, set CPU to 0.1 cores and Memory to 128 MiB. Then, click Update Settings at the bottom of the page.

4. Redeploy the workload to make the sidecar proxy configuration take effect.

5. View the istio-init init container resources that you configured.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Expected output:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
   ...
         name: istio-init
         resources:
           limits:
             cpu: '1'
             memory: 512Mi
           requests:
             cpu: 100m
             memory: 128Mi
   ...

   If the resources field of the init container named istio-init in the Pod is set to the target resource values, the Configure Resources for istio-init Container configuration has taken effect.

Parameter description

This parameter specifies the ACK dynamic oversold resources allocated to the injected Istio proxy and the istio-init init container. For more information about dynamic oversold resources, see Enable dynamic resource overcommitment.

This parameter is configured in the same way as the Resource settings for injected Istio proxies and the Resource settings for the istio-init init container. After the configuration, if a Pod has the ACK dynamic resource overselling label koordinator.sh/qosClass, ACK dynamic oversold resources are allocated to the Istio proxy and the istio-init init container in the Pod, instead of regular Kubernetes CPU and memory resources.

Configuration example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the target sidecar proxy configuration level, click Resource Settings, select Set ACK Resources That Can Be Dynamically Overcommitted for Sidecar Proxy, configure the related parameters, and then click Update Settings at the bottom of the page.

   Parameter	Sub-parameter	Description
   Configure Resources for Injected Sidecar Proxy (ACK Dynamically Overcommitted Resources)	Limits on Resources	Set CPU to 2000 millicores and Memory to 2048 MiB.
   	Required Resources	Set CPU to 200 millicores and Memory to 256 MiB.
   istio-init container resource (ACK dynamic oversold resource)	Limits on Resources	Set CPU to 1000 millicores and Memory to 1024 MiB.
   	Required Resources	Set CPU to 100 millicores and Memory to 128 MiB.

2. Redeploy the workload to make the sidecar proxy configuration take effect.

3. Run the following command to view the istio-init init container resources that you configured.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Expected output:

   apiVersion: v1
   kind: Pod
   metadata:
   ...
     labels:
       koordinator.sh/qosClass: BE
   spec:
     containers:
       - args:
   ...
         name: istio-proxy
   ...
         resources:
           limits:
             kubernetes.io/batch-cpu: 2k
             kubernetes.io/batch-memory: 2Gi
           requests:
             kubernetes.io/batch-cpu: '200'
             kubernetes.io/batch-memory: 256Mi
   ...
     initContainers:
       - args:
   ...
         name: istio-init
         resources:
           limits:
             kubernetes.io/batch-cpu: 1k
             kubernetes.io/batch-memory: 1Gi
           requests:
             kubernetes.io/batch-cpu: '100'
             kubernetes.io/batch-memory: 128Mi
   ...

   The istio-proxy container (Istio proxy container) and the istio-init init container in the Pod both contain the resources field set to the target resource values. This indicates that the Set ACK Resources That Can Be Dynamically Overcommitted for Sidecar Proxy configuration has taken effect.

Parameter description

This parameter specifies the number of worker threads of the sidecar proxy container. You must specify a non-negative integer as the number of worker threads. If you set this parameter to 0, the number of worker threads is automatically determined based on the requested CPU resources or the CPU resource limit configured for the sidecar proxy. The resource limit takes precedence over the requested resources.

Configuration example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the target sidecar proxy configuration level, and then click Resource Settings.

2. (Optional) In the Resource Settings section, select Number of Sidecar Proxy Threads.

   This step is required on the Namespace and workload tabs. You can skip this step on the global tab.

3. Set Number of Sidecar Proxy Threads to 3, and then click Update Settings at the bottom of the page.

   This configuration indicates that the sidecar proxy container runs three worker threads at runtime.

4. Redeploy the workload to make the sidecar proxy configuration take effect.

5. Run the following command to view the Istio-Proxy concurrency that you configured.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Expected output:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
       - args:
           - proxy
           - sidecar
           - '--domain'
           - $(POD_NAMESPACE).svc.cluster.local
           - '--proxyLogLevel=warning'
           - '--proxyComponentLogLevel=misc:error'
           - '--log_output_level=default:info'
           - '--concurrency'
           - '3'
   ...
         name: istio-proxy
   ...

   The concurrency parameter of the istio-proxy container is set to 3. This indicates that the Number of Sidecar Proxy Threads configuration has taken effect.

Parameter description

You must specify a list of IP address ranges separated by commas (,). Each IP address range is in CIDR notation. When a workload with an injected sidecar proxy accesses other services, only the requests whose destination IP addresses fall within the configured address ranges are intercepted by the sidecar proxy container. Other requests are sent directly to the destinations without going through the sidecar proxy. By default, this parameter is set to *, which indicates that the sidecar proxy container intercepts all outbound traffic of the workload.

Configuration example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the target sidecar proxy configuration level, and then click Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Optional) In the Enable/Disable Sidecar Proxy by Ports or IP Addresses section, select Addresses to Which External Access Is Redirected to Sidecar Proxy.

   This step is required on the Namespace and workload tabs. You can skip this step on the global tab.

3. Set Addresses to Which External Access Is Redirected to Sidecar Proxy to 192.168.0.0/16,10.1.0.0/24, and then click Update Settings at the bottom of the page.

   This configuration indicates that the sidecar proxy container intercepts requests whose destination IP addresses fall within the two CIDR blocks 192.168.0.0/16 and 10.1.0.0/24.

4. Redeploy the workload to make the sidecar proxy configuration take effect.

5. Run the following command to view the address ranges for intercepting outbound traffic that you configured.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Expected output:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '192.168.0.0/16,10.1.0.0/24'
           - '-x'
           - 192.168.0.1/32
           - '-b'
           - '*'
           - '-d'
           - '15090,15021,15081,9191,15020'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...

   The runtime parameters of the istio-init container include -i 192.168.0.0/16,10.1.0.0/24. This indicates that the Addresses to Which External Access Is Redirected to Sidecar Proxy configuration has taken effect.

Parameter description

Configuration example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the target sidecar proxy configuration level, and then click Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Optional) In the Enable/Disable Sidecar Proxy by Ports or IP Addresses section, select Addresses to Which External Access Is Not Redirected to Sidecar Proxy.

   This step is required on the Namespace and workload tabs. You can skip this step on the global tab.

3. Set Addresses to Which External Access Is Not Redirected to Sidecar Proxy to 10.1.0.0/24, and then click Update Settings at the bottom of the page.

   This configuration indicates that the sidecar proxy container does not intercept requests whose destination IP addresses fall within the CIDR block 10.1.0.0/24.

4. Redeploy the workload to make the sidecar proxy configuration take effect.

5. Run the following command to view the address ranges excluded from outbound traffic interception that you configured.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Expected output:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '*'
           - '-x'
           - '192.168.0.1/32,10.1.0.0/24'
           - '-b'
           - '*'
           - '-d'
           - '15090,15021,15081,9191,15020'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...

   The runtime parameters of the istio-init container include -x 192.168.0.1/32,10.1.0.0/24. 192.168.0.1/32 is the default host address CIDR block. 10.1.0.0/24 matches the IP address range configured for the sidecar proxy. This indicates that the Addresses to Which External Access Is Not Redirected to Sidecar Proxy configuration has taken effect.

Parameter description

You must specify a list of ports separated by commas (,). Traffic destined for the ports in the list is intercepted by the sidecar proxy container. By default, this parameter is set to *, which indicates that the sidecar proxy container intercepts all inbound traffic of the workload.

Configuration example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the target sidecar proxy configuration level, and then click Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Optional) In the Enable/Disable Sidecar Proxy by Ports or IP Addresses section, select Ports on Which Inbound Traffic Redirected to Sidecar Proxy.

   This step is required on the Namespace and workload tabs. You can skip this step on the global tab.

3. Set Ports on Which Inbound Traffic Redirected to Sidecar Proxy to 80,443, and then click Update Settings.

   This configuration indicates that the sidecar proxy container intercepts only the requests sent to port 80 and port 443 of the workload.

4. Redeploy the workload to make the sidecar proxy configuration take effect.

5. Run the following command to view the inbound traffic interception ports that you configured.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Expected output:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '*'
           - '-x'
           - 192.168.0.1/32
           - '-b'
           - '80,443'
           - '-d'
           - '15090,15021,15081,9191,15020'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...
                               

   The runtime parameters of the istio-init container include -b 80,443, which matches the inbound ports configured for the sidecar proxy. This indicates that the Ports on Which Inbound Traffic Redirected to Sidecar Proxy configuration has taken effect.

Parameter description

Configuration example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the target sidecar proxy configuration level, and then click Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Optional) In the Enable/Disable Sidecar Proxy by Ports or IP Addresses section, select Ports on Which Outbound Traffic Redirected to Sidecar Proxy.

   This step is required on the Namespace and workload tabs. You can skip this step on the global tab.

3. Set Ports on Which Outbound Traffic Redirected to Sidecar Proxy to 80,443, and then click Update Settings at the bottom of the page.

   This configuration indicates that the sidecar proxy container intercepts requests sent to services on port 80 and port 443.

4. Redeploy the workload to make the sidecar proxy configuration take effect.

5. Run the following command to view the outbound traffic interception ports that you configured.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Expected output:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '*'
           - '-x'
           - 192.168.0.1/32
           - '-b'
           - '*'
           - '-d'
           - '15090,15021,15081,9191,15020'
           - '--log_output_level=default:info'
           - '-q'
           - '80,443'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...
                               

   The runtime parameters of the istio-init container include -q 80,443, which matches the outbound ports configured for the sidecar proxy. This indicates that the Ports on Which Outbound Traffic Redirected to Sidecar Proxy configuration has taken effect.

Parameter description

Configuration example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the target sidecar proxy configuration level, and then click Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Optional) In the Enable/Disable Sidecar Proxy by Ports or IP Addresses section, select Ports on Which Inbound Traffic Not Redirected to Sidecar Proxy.

   This step is required on the Namespace and workload tabs. You can skip this step on the global tab.

3. Set Ports on Which Inbound Traffic Not Redirected to Sidecar Proxy to 8000, and then click Update Settings at the bottom of the page.

   This configuration indicates that the sidecar proxy container no longer intercepts requests sent to port 8000 of the workload.

4. Redeploy the workload to make the sidecar proxy configuration take effect.

5. Run the following command to view the inbound traffic bypass ports that you configured.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Expected output:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '*'
           - '-x'
           - 192.168.0.1/32
           - '-b'
           - '*'
           - '-d'
           - '15090,15021,15081,9191,15020,8000'
           - '--log_output_level=default:info'
   ...
         name: istio-init
   ...
                               

   The runtime parameters of the istio-init container include -d 15090,15021,15081,9191,8000. The ports 15090,15021,15081,9191 are the application ports of the sidecar proxy and are excluded from interception by default. The port 8000 matches the inbound ports configured for the sidecar proxy. This indicates that the Ports on Which Inbound Traffic Not Redirected to Sidecar Proxy configuration has taken effect.

Parameter description

You must specify a list of ports separated by commas (,), which represents the destination service ports of all outbound traffic. Requests whose destination service ports are in the list are not intercepted by the sidecar proxy container, regardless of whether the destination IP address falls within the intercepted outbound address ranges or whether the destination port is in the intercepted outbound port list.

Configuration example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the target sidecar proxy configuration level, and then click Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Optional) In the Enable/Disable Sidecar Proxy by Ports or IP Addresses section, select Ports on Which Outbound Traffic Not Redirected to Sidecar Proxy.

   This step is required on the Namespace and workload tabs. You can skip this step on the global tab.

3. Set Ports on Which Outbound Traffic Not Redirected to Sidecar Proxy to 8000, and then click Update Configurations at the bottom of the page.

   This configuration indicates that the sidecar proxy container no longer intercepts requests sent to services on port 8000.

4. Redeploy the workload to make the sidecar proxy configuration take effect.

5. Run the following command to view the outbound traffic bypass ports that you configured.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Expected output:

   apiVersion: v1
   kind: Pod
   ...
   spec:
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - REDIRECT
           - '-i'
           - '*'
           - '-x'
           - 192.168.0.1/32
           - '-b'
           - '*'
           - '-d'
           - '15090,15021,15081,9191,15020'
           - '--log_output_level=default:info'
           - '-o'
           - '8000'
   ...
         name: istio-init
   ...
                               

   The runtime parameters of the istio-init container include -o 8000, which matches the outbound ports configured for the sidecar proxy. This indicates that the Ports on Which Outbound Traffic Not Redirected to Sidecar Proxy configuration has taken effect.

Parameter description

You can enable or disable the DNS proxy feature for sidecar proxy containers. After the DNS proxy feature is enabled, sidecar proxy containers intercept the DNS requests of workloads to improve the performance and availability of Service Mesh. All requests from workloads are redirected to the sidecar proxy container. Because sidecar proxy containers store the mappings between IP addresses and local domain names locally, they can directly return DNS responses to workloads without sending requests to remote DNS services. If a DNS request cannot be handled by the sidecar proxy container, the sidecar directly forwards the DNS request. For more information, see Use DNS proxy in ASM.

Configuration example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the target sidecar proxy configuration level, and then click DNS Proxy.

2. (Optional) In the DNS Proxy section, select Enable DNS Proxy, turn on the switch on the right, and then click Update Settings.

   This step is required on the Namespace and workload tabs. You can skip this step on the global tab. Turning on the switch enables the DNS proxy feature for the sidecar proxy.

3. Redeploy the workload to make the sidecar proxy configuration take effect.

4. Run the following command to view the DNS proxy feature that you configured.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Expected output:

   apiVersion: v1
   kind: Pod
   spec:
     containers:
       - args:
           - proxy
           - sidecar
           - '--domain'
           - $(POD_NAMESPACE).svc.cluster.local
           - '--proxyLogLevel=warning'
           - '--proxyComponentLogLevel=misc:error'
           - '--log_output_level=default:info'
           - '--concurrency'
           - '3'
         env:
   ...
           - name: ISTIO_META_DNS_AUTO_ALLOCATE
             value: 'true'
           - name: ISTIO_META_DNS_CAPTURE
             value: 'true'
   ...
         name: istio-proxy
                               

   The ISTIO_META_DNS_AUTO_ALLOCATE and ISTIO_META_DNS_CAPTURE environment variables of the istio-proxy container are set to true. This indicates that the DNS Proxy configuration has taken effect.

Parameter description

This parameter specifies additional environment variables added to sidecar proxy containers. You can configure the following two types of sidecar proxy environment variables.

Configuration example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the target sidecar proxy configuration level, and then click Manage Environment Variables for Sidecar Proxy.

2. (Optional) In the Manage Environment Variables for Sidecar Proxy section, select Sidecar Graceful Shutdown (EXIT_ON_ZERO_ACTIVE_CONNECTIONS).

   This step is required on the Namespace and workload tabs. You can skip this step on the global tab.

3. Turn on the switch on the right of Sidecar Graceful Shutdown (EXIT_ON_ZERO_ACTIVE_CONNECTIONS), and then click Update Configurations.

4. Redeploy the workload to make the sidecar proxy configuration take effect.

5. Run the following command to view the environment variables of the sidecar proxy that you configured.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Expected output:

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
   ...
         env:
           - name: EXIT_ON_ZERO_ACTIVE_CONNECTIONS
             value: 'true'
         name: istio-proxy
   ...

   The EXIT_ON_ZERO_ACTIVE_CONNECTIONS environment variable is added to the sidecar environment variables of the istio-proxy container in the Pod. This indicates that the Manage Environment Variables for Sidecar Proxy configuration has taken effect.

Parameter description

HoldApplicationUntilProxyStarts is a lifecycle management parameter for sidecar proxies. HoldApplicationUntilProxyStarts is enabled by default, which means that for a Pod with an injected sidecar proxy, the sidecar proxy container must start successfully before the application containers in the Pod start. This ensures that traffic sent to the application containers is not lost because the sidecar proxy has not finished starting.

If this parameter is disabled, the sidecar proxy container and the application containers in the Pod start at the same time. When a large number of Pods are deployed in a cluster, sidecar proxy containers may start slowly due to heavy load on the APIServer. You can disable HoldApplicationUntilProxyStarts to speed up the deployment.

Configuration example

The following example shows how to disable HoldApplicationUntilProxyStarts on the global tab.

1. On the Configure the agent parameters of the injected Sidecar page, click the global tab, and then click Lifecycle Management.

2. Turn off the switch on the right of Sidecar Graceful Startup (HoldApplicationUntilProxyStarts), and then click Update Settings.

   This configuration indicates that the HoldApplicationUntilProxyStarts capability is disabled.

3. Redeploy the workload to make the sidecar proxy configuration take effect.

4. Run the following command to view the HoldApplicationUntilProxyStarts setting.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Expected output:

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - command:
   ...
         name: sleep
   ...
         env:
           - name: PROXY_CONFIG
             value: >-
               {..."holdApplicationUntilProxyStarts":false,...}
   ...
         name: istio-proxy
   ...

   After the holdApplicationUntilProxyStarts capability is disabled, the istio-proxy container is no longer forcibly declared before the application containers, and the default lifecycle field is no longer declared. In this case, Service Mesh no longer ensures that the sidecar proxy container starts successfully before the application containers start.

Parameter description

The sidecar proxy termination drain duration is a lifecycle management parameter for sidecar proxies. After a sidecar proxy is injected into a Pod, the traffic of the application Pod is intercepted by the sidecar proxy container.

When a Pod starts to stop, the corresponding Service no longer forwards traffic to the Pod. After the sidecar proxy container receives the exit signal, it waits for a period of time. During this period, the container stops accepting new inbound traffic but continues to process existing inbound traffic. Outbound traffic is not affected and can still be sent normally. This period is called the sidecar proxy termination drain duration. The default termination drain duration of sidecar proxy containers is 5s. You can configure a duration in s, such as 10s.

If the interface calls provided by the stopped service take a long time and exceed the termination drain duration of the sidecar proxy container, existing inbound and outbound connections are terminated even if they have not been fully processed, which may cause some requests to be lost. In this case, you can use this parameter to extend the sidecar proxy termination drain duration so that inbound and outbound traffic can be fully processed.

The sidecar proxy termination drain duration must be specified in seconds with the unit s, such as 10s.

Configuration example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the target sidecar proxy configuration level, and then click Lifecycle Management.

2. (Optional) In the Lifecycle Management section, select Sidecar Proxy Drain Duration at Pod Termination.

   This step is required on the Namespace and workload tabs. You can skip this step on the global tab.

3. Set Sidecar Proxy Drain Duration at Pod Termination to 10s, and then click Update Settings.

   This configuration indicates that the sidecar proxy waits 10 seconds to process existing connections during termination.

4. Redeploy the workload to make the sidecar proxy configuration take effect.

5. Run the following command to view the sidecar proxy termination drain duration that you configured.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Expected output:

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
   ...
         env:
           - name: TERMINATION_DRAIN_DURATION_SECONDS
             value: '10'
   ...
           - name: PROXY_CONFIG
             value: >-
               {..."terminationDrainDuration":"10s"}
   ...
         name: istio-proxy
   ...

   The istio-proxy container in the Pod is configured with the TERMINATION_DRAIN_DURATION_SECONDS environment variable set to 10, and the PROXY_CONFIG environment variable records terminationDrainDuration as 10s. This indicates that the Sidecar Proxy Drain Duration at Pod Termination configuration has taken effect.

Parameter description

The sidecar proxy lifecycle parameter allows you to fully customize the container lifecycle hooks of sidecar proxy containers. For this parameter, you must enter a container lifecycle hook field (lifecycle) declared in JSON format. This field replaces the default container lifecycle hook field of the sidecar proxy container. For more information, see Container lifecycle hooks.

Configuration example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the target sidecar proxy configuration level, and then click Lifecycle Management.

2. (Optional) In the Lifecycle Management section, select Lifecycle of Sidecar Proxy.

   This step is required on the Namespace and workload tabs. You can skip this step on the global tab.

3. Under Lifecycle of Sidecar Proxy, enter the following YAML content, and then click Update Settings.

   This YAML content configures the postStart and preStop hook parameters.

   • postStart: waits for pilot-agent to start after the sidecar container starts.

   • preStop: sleeps for 13 seconds before the sidecar container stops.

   {
     "postStart": {
       "exec": {
         "command": [
           "pilot-agent",
           "wait"
         ]
       }
     },
     "preStop": {
       "exec": {
         "command": [
           "/bin/sh",
           "-c",
           "sleep 13"
         ]
       }
     }
   }

4. Redeploy the workload to make the sidecar proxy configuration take effect.

5. Run the following command to view the sidecar proxy lifecycle that you configured.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Expected output:

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
   ...
   ...
           lifecycle:
           postStart:
             exec:
               command:
               - pilot-agent
               - wait
           preStop:
             exec:
               command:
               - /bin/sh
               - -c
               - sleep 13
         name: istio-proxy
   ...

   The container lifecycle hook field (lifecycle) of the istio-proxy container in the Pod is changed to the target configuration. This indicates that the Lifecycle of Sidecar Proxy configuration has taken effect.

Parameter description

This parameter specifies the access policy of sidecar proxy containers for external services. External services are services outside the mesh that are not registered with Service Mesh. By default, all services in the Kubernetes clusters managed by Service Mesh are registered services. You can manually register services with Service Mesh by declaring ServiceEntry resources. Services that are not registered are considered external services.

Configuration example

1. On the global tab of the Configure the agent parameters of the injected Sidecar page, click Outbound Traffic Policy, select REGISTRY_ONLY on the right of Outbound Traffic Policy, and then click Update Settings.

   This configuration restricts services in the mesh from accessing external services.

2. Redeploy the workload to make the sidecar proxy configuration take effect.

3. Create sleep.yaml with the following content.

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: sleep
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: sleep
     labels:
       app: sleep
       service: sleep
   spec:
     ports:
     - port: 80
       name: http
     selector:
       app: sleep
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: sleep
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: sleep
     template:
       metadata:
         labels:
           app: sleep
       spec:
         terminationGracePeriodSeconds: 0
         serviceAccountName: sleep
         containers:
         - name: sleep
           image: curlimages/curl
           command: ["/bin/sleep", "3650d"]
           imagePullPolicy: IfNotPresent
           volumeMounts:
           - mountPath: /etc/sleep/tls
             name: secret-volume
         volumes:
         - name: secret-volume
           secret:
             secretName: sleep-secret
             optional: true
   ---

4. Run the following command to deploy the sleep application.

   kubectl apply -f sleep.yaml -n default

5. Run the following command to use the sleep application to access an external service.

   kubectl exec -it {sleep-pod-name} -c sleep -- curl www.aliyun.com -v

   Expected output:

   *   Trying *********...
   * Connected to www.aliyun.com (********) port 80 (#0)
   > GET / HTTP/1.1
   > Host: www.aliyun.com
   > User-Agent: curl/7.87.0-DEV
   > Accept: */*
   >
   * Mark bundle as not supporting multiuse
   < HTTP/1.1 502 Bad Gateway
   < date: Mon,********* 03:25:00 GMT
   < server: envoy
   < content-length: 0
   <
   * Connection #0 to host www.aliyun.com left intact

   The 502 response indicates that the sleep application with an injected sidecar proxy cannot access the external service www.aliyun.com. This indicates that the Outbound Traffic Policy configuration has taken effect.

Parameter description

This parameter specifies the interception policy of sidecar proxies for inbound traffic. By default, sidecar proxy containers use the iptables REDIRECT policy to intercept inbound traffic sent to application workloads. After inbound traffic is intercepted by redirection, the application can only see the IP address of the sidecar proxy container as the source IP address of requests and cannot see the original IP address of the client.

If you change the inbound traffic interception policy to the transparent proxy (TPROXY) policy, Service Mesh allows sidecar proxy containers to intercept inbound traffic in the iptables transparent proxy mode. After this parameter is configured, the application can see the original IP address of the client. For more information, see Obtain client source IP in Service Mesh.

Configuration example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the target sidecar proxy configuration level, and then click Sidecar Traffic Interception Mode.

2. (Optional) In the Sidecar Traffic Interception Mode section, select Sidecar Traffic Interception Mode.

   This step is required on the Namespace and workload tabs. You can skip this step on the global tab.

3. On the right of Sidecar Traffic Interception Mode, select TPROXY, and then click Update Settings.

4. Redeploy the workload to make the sidecar proxy configuration take effect.

5. Run the following command to view the sidecar inbound traffic interception policy that you configured.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Expected output:

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
   ...
           - name: PROXY_CONFIG
             value: >-
               {..."interceptionMode":"TPROXY",...}
           - name: ISTIO_META_POD_PORTS
             value: |-
               [
               ]
   ...
         name: istio-proxy
   ...
     initContainers:
       - args:
           - istio-iptables
           - '-p'
           - '15001'
           - '-z'
           - '15006'
           - '-u'
           - '1337'
           - '-m'
           - TPROXY
   ...
         name: istio-init
   ...

   The sidecar environment variables of the istio-proxy container in the Pod record "interceptionMode":"TPROXY", and the istio-init container also runs the initialization command with the TPROXY parameter. This indicates that the Sidecar Traffic Interception Mode configuration has taken effect.

Parameter description

This parameter specifies the log level of sidecar proxy containers. By default, sidecar proxies use the info log level. You can change the log level of sidecar proxies to any of the seven levels info, debug, trace, warning, error, critical, and off to obtain more or less log information from sidecar proxies.

Configuration example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the target sidecar proxy configuration level, and then click Monitoring Statistics.

2. (Optional) In the Monitoring Statistics section, select Log Level.

   This step is required on the Namespace and workload tabs. You can skip this step on the global tab.

3. On the right of Log Level, select error, and then click Update Settings.

   This configuration indicates that the sidecar proxy outputs logs at the error level, and only logs at the error level or higher are output.

4. Redeploy the workload to make the sidecar proxy configuration take effect.

5. Run the following command to view the sidecar proxy log level that you configured.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Expected output:

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
           - proxy
           - sidecar
           - '--domain'
           - $(POD_NAMESPACE).svc.cluster.local
           - '--proxyLogLevel=error'
   ...
         name: istio-proxy
   ...

   The runtime parameters of the istio-proxy container are set to --proxyLogLevel=error. This indicates that the Log Level configuration has taken effect.

Parameter description

This parameter defines the custom Envoy statistics reported by sidecar proxies. Envoy is the technical implementation of sidecar proxies and can collect and report a series of metrics. However, Service Mesh enables the collection and exposure of only some metrics by default to reduce the performance overhead on sidecar proxies. You can use this parameter to specify additional metrics that sidecar proxies need to collect and report by prefix matching, suffix matching, or regular expression matching.

Configuration example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the target sidecar proxy configuration level, and then click Monitoring Statistics.

2. In the Monitoring Statistics section, select proxyStatsMatcher, select Regular Expression Match, and then set it to .*outlier_detection.*.

   This configuration adds the collection of circuit breaking metrics for the sidecar proxy.

3. Redeploy the workload to make the sidecar proxy configuration take effect.

4. Run the following command to view the custom statistics of the sidecar proxy that you configured.

   kubectl get pod -n <namespace> <pod-name> -o yaml

   Expected output:

   apiVersion: v1
   kind: Pod
   ...
   spec:
     containers:
       - args:
    ...
           - name: PROXY_CONFIG
             value: >-
               {..."proxyStatsMatcher":{"inclusionRegexps":[".*outlier_detection.*"]},...}
   ...

   The custom statistics in the sidecar environment variables of the istio-proxy container in the Pod have been updated. This indicates that the proxyStatsMatcher configuration has taken effect.