Alibaba Cloud Service Mesh:Configure Sidecar proxy

Configuration reference

This configuration item specifies the minimum required and maximum allowable CPU and memory resources for the istio-init container in Pods with injected Sidecar proxy. The istio-init container is an init container executed when the Pod starts, responsible for configuring traffic interception routing rules and other prerequisites for the Sidecar proxy container.

Configuration example

1. On the Sidecar Proxy Setting page, select a configuration level tab, and then click Resource Settings.

2. (Optional) Perform this step if you selected Namespace or workload in step 1. Then, in the Resource Settings section, select Configure Resources for istio-init Container.

3. In the Resource Limits section, set CPU to 1 core and Memory to 512 MiB. In the Required Resources section, set CPU to 0.1 cores and Memory to 128 MiB. Then, click Update Settings.

4. Redeploy the workloads to make the Sidecar proxy configurations take effect.

5. Run the following command to view the resource configurations of the istio-init container:

   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
   ...

   The resources field of the istio-init container in the pod is set to the expected resource values. This indicates that the configurations of Configure Resources for istio-init Container take effect.

Configuration reference

This configuration setting specifies the allocation of ACK dynamically over-allocated resources for the injected Istio proxy and the istio-init container. For more information, see Dynamic resource overcommitment.

The configuration items are configured in the same way as those of Configure resources for Injected Istio proxy and Configure Resources for istio-init Container. After the preceding configurations are complete, resources that can be dynamically overcommitted, instead of regular CPU and memory resources, are allocated to the Sidecar proxy and istio-init containers in a pod if the pod has the koordinator.sh/qosClass label. This label indicates that dynamic overcommitment of ACK resources is enabled.

Configuration example

1. On the Sidecar Proxy Setting page, select a configuration level tab, and then click Resource Settings.

2. Select Set ACK Resources That Can Be Dynamically Overcommitted for Sidecar Proxy, configure the settings, and then click Update Settings.

   Configuration item	Child configuration item	Description
   Configure Resources for Injected Sidecar Proxy (ACK Dynamically Overcommitted Resources)	Resource Limits	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)	Resource Limits	Set CPU to 1000 millicores and Memory to 1024 MiB.
   	Required Resources	Set CPU to 100 millicores and Memory to 128 MiB.

3. Redeploy the workloads to make the Sidecar proxy configurations take effect.

4. Run the following command to view the resource configurations of the istio-init container:

   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
   ...

   Both the istio-proxy container (Sidecar proxy container) and the istio-init container in the pod contain the resources field and have the configured resource values. This indicates that the configurations of Set ACK Resources That Can Be Dynamically Overcommitted for Sidecar Proxy take effect.

Configuration reference

This configuration item specifies the number of worker threads for the Sidecar proxy container. Must be non-negative integer. When set to 0, the number of worker threads is automatically determined based on the requested CPU resources or CPU resource limits configured for the Sidecar proxy. Resource limits take precedence over requested resources.

Configuration example

1. On the Sidecar Proxy Setting page, select a configuration level tab, and then click Resource Settings.

2. (Optional) Perform this step if you selected Namespace or workload in step 1. Set Number of Sidecar Proxy Threads to 3 and click Update Settings.

3. This configuration indicates that the Sidecar proxy container will start three worker threads when it is running.

4. Redeploy the workloads to make the Sidecar proxy configurations take effect.

5. Run the following command to view the configuration of Number of Sidecar Proxy Threads:

   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 configuration of Number of Sidecar Proxy Threads takes effect.

Configuration reference

Configure a list of IP address ranges separated by commas (,), where each IP address range is specified in CIDR notation. When a workload with an injected Sidecar proxy accesses other services, only requests with destination IP addresses within the configured ranges are intercepted by the Sidecar proxy container. Requests outside these ranges will bypass the Sidecar proxy and be sent directly to their destinations. The default configuration is set to *, which means the Sidecar proxy container intercepts all outbound traffic from the workload.

Configuration example

1. On the Sidecar Proxy Setting page, select a configuration level tab, and then expand Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Optional) Perform this step if you selected workload or Namespace in step 1. Select Addresses to Which External Access Is Redirected to Sidecar Proxy.

3. Set Addresses to Which External Access Is Redirected to Sidecar Proxy to 192.168.0.0/16,10.1.0.0/24 and click Update Settings.

   This configuration indicates that the Sidecar proxy container will intercept requests whose destination IP addresses are within the 192.168.0.0/16 and 10.1.0.0/24 CIDR blocks.

4. Redeploy the workloads to make the Sidecar proxy configurations take effect.

5. Run the following command to view the configuration:

   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 parameter -i of the istio-init container is set to 192.168.0.0/16,10.1.0.0/24. This indicates that the configuration of Addresses to Which External Access Is Redirected to Sidecar Proxy takes effect.

Configuration reference

Configuration example

1. On the Sidecar Proxy Setting page, select a configuration level tab, and then expand Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Optional) Perform this step if you selected workload or Namespace in step 1. Select Addresses to Which External Access Is Not Redirected to Sidecar Proxy.

3. Set Addresses to Which External Access Is Not Redirected to Sidecar Proxy to 10.1.0.0/24 and click Update Settings.

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

4. Redeploy the workloads to make the Sidecar proxy configurations take effect.

5. Run the following command to view the configuration:

   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 parameter -x of the istio-init container is set to 192.168.0.1/32,10.1.0.0/24. 192.168.0.1/32 is the CIDR block of hosts configured by default. 10.1.0.0/24 is the same as the IP address range specified in the Sidecar proxy configuration. This indicates that the configuration of Addresses to Which External Access Is Not Redirected to Sidecar Proxy takes effect.

Configuration reference

Configure a list of port numbers that are separated by commas (,). The Sidecar proxy container intercepts inbound traffic whose destination ports are in the list. The default value is *, which indicates that the Sidecar proxy container intercepts all inbound traffic of the workload.

Configuration example

1. On the Sidecar Proxy Setting page, select a configuration level tab, and then click Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Optional) Perform this step if you selected workload or Namespace in step 1. In the Enable/Disable Sidecar Proxy by Ports or IP Addresses section, select Ports on Which Inbound Traffic Redirected to Sidecar Proxy.

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

   This configuration indicates that the Sidecar proxy container will intercept requests destined for ports 80 and 443 of the corresponding workload.

4. Redeploy the workloads to make the Sidecar proxy configurations take effect.

5. Run the following command to view the 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 parameter -b of the istio-init container is set to 80,443, which is the same as the inbound ports set in the Sidecar proxy configuration. This indicates that the configuration of Ports on Which Inbound Traffic Redirected to Sidecar Proxy takes effect.

Configuration reference

Configuration example

1. On the Sidecar Proxy Setting page, select a configuration level tab, and then click Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Optional) Perform this step if you selected workload or Namespace in step 1. Select Ports on Which Outbound Traffic Redirected to Sidecar Proxy.

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

   This configuration indicates that the Sidecar proxy container intercepts requests destined for ports 80 and 443.

4. Redeploy the workloads to make the Sidecar proxy configurations take effect.

5. Run the following command to view the configuration:

   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 parameter -q of the istio-init container is set to 80,443, which is the same as the outbound ports set in the Sidecar proxy configuration. This indicates that the configuration of Ports on Which Outbound Traffic Redirected to Sidecar Proxy takes effect.

Configuration reference

Configuration example

1. On the Sidecar Proxy Setting page, select a configuration level tab, and then click Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Optional) Perform this step if you selected workload or Namespace in step 1. Select Ports on Which Inbound Traffic Not Redirected to Sidecar Proxy.

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

   This configuration indicates that the Sidecar proxy container no longer intercepts requests destined for port 8000 of the workload.

4. Redeploy the workloads to make the Sidecar proxy configurations take effect.

5. Run the following command to view the configuration:

   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 parameter -d of the istio-init container is set to 15090,15021,15081,9191,8000. 15090, 15021, 15081, and 9191 are application ports of Sidecar proxy. By default, the Sidecar proxy container does not intercept inbound traffic destined for these ports. Port 8000 is the same as the inbound port set in the Sidecar proxy configuration. This indicates that the configuration of Ports on Which Inbound Traffic Not Redirected to Sidecar Proxy takes effect.

Configuration reference

Configure a list of ports that are separated by commas (,). Outbound traffic destined for the ports in the list will not be intercepted by the Sidecar proxy, regardless of whether the IP addresses of the destination services are in Addresses to Which External Access Is Redirected to Sidecar Proxy and whether the ports of the destination services are in Ports on Which Outbound Traffic Redirected to Sidecar Proxy.

Configuration example

1. On the Sidecar Proxy Setting page, select a configuration level tab, and then click Enable/Disable Sidecar Proxy by Ports or IP Addresses.

2. (Optional) Perform this step if you selected workload or Namespace in step 1. Select Ports on Which Outbound Traffic Not Redirected to Sidecar Proxy.

3. Set Ports on Which Outbound Traffic Not Redirected to Sidecar Proxy to 8000, and then click Update Settings.

   This configuration indicates that the Sidecar proxy container no longer intercepts service requests destined for port 8000.

4. Redeploy the workloads to make the Sidecar proxy configurations take effect.

5. Run the following command to view the configuration:

   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 parameter -o of the istio-init container is set to 8000, which is the same as the port set in the configuration item Ports on Which Outbound Traffic Not Redirected to Sidecar Proxy. This indicates that the configuration item takes effect.

Configuration reference

If the DNS proxy is enabled, the Sidecar proxy intercepts DNS requests of the workload to improve the performance and availability of ASM. All requests from the workload are redirected to the Sidecar proxy. Since the Sidecar proxy stores the mapping of IP addresses to local domain names, it returns DNS responses to the workload without requesting remote DNS services in most cases, unless the DNS request cannot be resolved by it. For more information, see Use the DNS proxy feature in an ASM instance.

Configuration example

1. On the Sidecar Proxy Setting page, select a configuration level tab, and then click DNS Proxy.

2. (Optional) Perform this step if you selected workload or Namespace in step 1. Select Enable DNS Proxy, turn on the switch, and then click Update Settings.

3. Redeploy the workloads to make the Sidecar proxy configurations take effect.

4. Run the following command to view the configuration:

   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, which indicates that the configuration of DNS Proxy takes effect.

Configuration reference

These configuration items are used to add additional environment variables in the Sidecar proxy container. You can configure the following environment variables for the Sidecar proxy.

Configuration example

1. On the Sidecar Proxy Setting page, select a configuration level tab, and then click Manage Environment Variables for Sidecar Proxy.

2. (Optional) Perform this step if you selected workload or Namespace in step 1. Select Sidecar Graceful Shutdown.

3. Turn on the switch and then click Update Settings.

4. Redeploy the workloads to make the Sidecar proxy configurations take effect.

5. Run the following command to view the configuration:

   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 environment variables of the istio-proxy container in the pod. This indicates that the configuration of Manage Environment Variables for Sidecar Proxy takes effect.

Configuration reference

Sidecar Graceful Startup is used to manage the lifecycle of Sidecar proxy. By default, it is enabled, which indicates that for a pod injected with a Sidecar proxy, has to start up the Sidecar proxy before the application containers. The purpose is to ensure that the traffic destined for the application containers is not lost in the case that the Sidecar proxy is not started.

If this configuration item is disabled, the Sidecar proxy container and the application containers in the pod are started at the same time. When many pods are deployed in a cluster, the Sidecar proxy containers may be started slowly due to the heavy load on the API server. You can disable this configuration item to speed up deployment.

Configuration example

The following example describes how to disable Sidecar Graceful Startup on the global tab.

1. On the Sidecar Proxy Setting page, select the global tab, and then click Lifecycle Management.

2. Turn off the switch next to Sidecar Graceful Startup and click Update Settings.

3. Redeploy the workloads to make the Sidecar proxy configurations take effect.

4. Run the following command to view the configuration:

   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
   ...

   Once Sidecar Graceful Startup is disabled, the istio-proxy container is not required to start before application containers are started, and the default lifecycle field is not declared.

Configuration reference

Sidecar Proxy Drain Duration at Pod Termination is for managing the lifecycle of a Sidecar proxy.

After the pod begins being terminated, services no longer route traffic to the pod. The Sidecar proxy container continues to process existing inbound traffic for a period after receiving an exit signal, but it does not accept new inbound traffic. This period of time is called Sidecar Proxy Drain Duration at Pod Termination. The default value is 5s. This configuration item must be set to a value in seconds, for example, 10s.

If response time of some API provided by a service to be stopped exceeds Sidecar Proxy Drain Duration at Pod Termination, all existing inbound and outbound connections will be terminated even if they are not processed. As a result, some requests are lost. In this case, set it to a greater value so that the processing of inbound and outbound traffic can be completed.

Configuration example

1. On the Sidecar Proxy Setting page, select a configuration level tab, and then click Lifecycle Management.

2. (Optional) Perform this step if you selected workload or Namespace in step 1. Select Sidecar Proxy Drain Duration at Pod Termination.

3. Set it to 10s, and click Update Settings.

4. Redeploy the workloads to make the Sidecar proxy configurations take effect.

5. Run the following command to view the configuration:

   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 an environment variable named TERMINATION_DRAIN_DURATION_SECONDS with the value of 10, and terminationDrainDuration is 10s in the PROXY_CONFIG. This indicates that the configuration of Sidecar Proxy Drain Duration at Pod Termination takes effect.

Configuration reference

To customize the lifecycle hook of the Sidecar proxy container, enter the container lifecycle hook field (lifecycle) in JSON format. This field will replace the default container lifecycle hook field configured for the Sidecar proxy container. For more information, see Container Lifecycle Hooks.

Configuration example

1. On the Sidecar Proxy Setting page, select a configuration level tab, and then click Lifecycle Management.

2. (Optional) Perform this step if you selected workload or Namespace in step 1. Select Lifecycle of Sidecar Proxy.

3. In the edit box under Lifecycle of Sidecar Proxy, configure the following YAML file and then click Update Settings.

   This YAML file configures the postStart and preStop hook parameters.

   • postStart: indicates that the pilot-agent starts to wait for the complete startup of the pilot-agent and Envoy proxy after the Sidecar proxy container is started.

   • preStop: indicates that the Sidecar proxy container sleeps for 13s before it is stopped.

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

4. Redeploy the workloads to make the Sidecar proxy configurations take effect.

5. Run the following command to view the configuration:

   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 lifecycle hook field (lifecycle) of the istio-proxy container in the pod is changed to the expected configuration. This indicates that the configuration of Lifecycle of Sidecar Proxy takes effect.

Configuation reference

This configuration item is used to configure an outbound traffic policy for the Sidecar proxy container. External services indicate services that are not defined in the service registry of ASM. By default, services in the Kubernetes clusters that are managed by ASM are registered services. You can manually register services with ASM by declaring service entry (ServiceEntry) resources.

Configuration example

1. On the global tab of the Sidecar Proxy Setting page, click Outbound Traffic Policy, select REGISTRY_ONLY, and then click Update Settings.

2. Redeploy the workloads to make the Sidecar proxy configurations take effect.

3. Create a sleep.yaml file that contains 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 external services:

   kubectl exec -it {Name of the pod for the sleep service} -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 HTTP status code 502 is returned, indicating that the sleep application for which the Sidecar proxy is injected cannot access the external service www.aliyun.com. This indicates that the configuration of Outbound Traffic Policy takes effect.

Configuration reference

This configuration item sets the inbound traffic interception strategy for the Sidecar proxy. By default, the Sidecar proxy container uses an iptables redirect policy to intercept inbound traffic destined for the application workload. After interception via redirection, the application will only see the Sidecar proxy container's IP as the source IP of the request and will not be able to identify the original client source IP.

By changing the inbound traffic interception strategy to transparent proxy mode (TPROXY), ASM allows the Sidecar proxy container to intercept inbound traffic using iptables' transparent proxy mode. After this configuration, the application will be able to see the original client source IP. For more information, see Preserve the source IP address of a client when the client accesses services in ASM.

Configuration example

1. On the Sidecar Proxy Setting page, select a configuration level tab, and then click Sidecar Traffic Interception Mode.

2. (Optional) Perform this step if you selected workload or Namespace in step 1. Select Sidecar Traffic Interception Mode.

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

4. Redeploy the workloads to make the Sidecar proxy configurations take effect.

5. Run the following command to view the configuration of Sidecar Traffic Interception Mode:

   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
   ...

   "interceptionMode":"TPROXY" is recorded in the environment variable of the istio-proxy container in the pod. The istio-init container also uses the TPROXY setting to run the initialization commands. This indicates that the configuration of Sidecar Traffic Interception Mode takes effect.

Configuration reference

This configuration item is used to set the log level of the Sidecar proxy container. By default, the log level of the Sidecar proxy is info. You can set the log level to one of the seven levels: info, debug, trace, warning, error, critical, and off.

Configuration example

1. On the Sidecar Proxy Setting page, select a configuration level tab, and then click Monitoring Statistics.

2. (Optional) Perform this step if you selected workload or Namespace in step 1. Select Log Level. .

3. Select error from the Log Level drop-down list, and then click Update Settings.

   This configuration indicates that the Sidecar proxy displays logs at the error or higher levels.

4. Redeploy the workloads to make the Sidecar proxy configurations take effect.

5. Run the following command to view the configuration:

   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 parameter --proxyLogLevel of the istio-proxy container is set to error, which indicates that the configuration of Log Level takes effect.

Description of configuration items

This configuration item defines the custom Envoy statistics metrics reported by the Sidecar proxy. Envoy, as the technical implementation of the Sidecar proxy, can collect and report a wide range of metrics. However, ASM defaults to enabling only a subset of these metrics to minimize performance overhead on the Sidecar proxy.

You can use this configuration item to specify additional metrics that the Sidecar proxy should collect and expose by matching prefixes, suffixes, or regular expressions.

Configuration example

1. On the Sidecar Proxy Setting page, select a configuration level tab, and then click Monitoring Statistics.

2. Select proxyStatsMatcher and Regular Expression Match, and set Regular Expression Match to .*outlier_detection.*.

   This configuration indicates that the Sidecar proxy collects the statistics of circuit breaker metrics.

3. Redeploy the workloads to make the Sidecar proxy configurations take effect.

4. Run the following command to view the configuration of proxyStatsMatcher:

   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 metrics are updated in the environment variables of the istio-proxy container in the pod. This indicates that the configuration of proxyStatsMatcher takes effect.