Configure sidecar proxies

Description

Use this setting to configure resource requests (minimum CPU and memory) and resource limits (maximum CPU and memory) for the istio-init container in pods with an injected sidecar proxy. The istio-init container is an init container that runs at pod startup to set traffic interception rules for the sidecar proxy.

Configuration example

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

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

   This step is required on the Namespace and workload tabs, but not on the global tab.

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

4. Redeploy the workload to apply the sidecar proxy configuration.

5. Verify the configured resources for the istio-init container.

   kubectl get pod -n <namespace-name> <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 init container in the Pod is set to the target resource value, which indicates that the Configure Resources for istio-init Container configuration has taken effect.

Description

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

The configuration method is the same as for Resource settings for an injected Istio proxy and Resource settings for an istio-init init container. After you apply this configuration, Pods with the ACK dynamic overcommitment label koordinator.sh/qosClass use ACK dynamic overcommitment resources for their Istio proxy and istio-init init containers instead of standard Kubernetes CPU and memory resources.

Configuration example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the desired configuration level, click Resource Settings, select Set ACK Resources That Can Be Dynamically Overcommitted for Sidecar Proxy, configure the parameters as described in the following table, and then click Update Settings at the bottom of the page.

   Parameter	Subparameter	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 apply the sidecar proxy configuration.

3. Run the following command to check the configured resources:

   kubectl get pod -n <namespace-name> <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 output shows that both the istio-proxy container and the istio-init init container have a resources field with the specified values. This confirms that the Set ACK Resources That Can Be Dynamically Overcommitted for Sidecar Proxy settings have taken effect.

Description

This setting specifies the number of worker threads for the sidecar proxy container. You must set this to a non-negative integer. If you set the value to 0, the system automatically determines the number of worker threads based on the CPU requests or limits of the sidecar proxy container. Limits take precedence over requests.

Configuration example

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

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

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

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

   This configures the sidecar proxy container to run with 3 worker threads.

4. Redeploy the workload to apply the sidecar proxy configuration.

5. Run the following command to check the configured Istio-Proxy concurrency.

   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 istio-proxy container's --concurrency argument is set to 3, confirming that the Number of Sidecar Proxy Threads setting has been applied.

Parameter

Specify a comma-separated list of IP address ranges in CIDR notation. When a workload with an injected sidecar proxy accesses other services, the sidecar proxy container intercepts only requests to destination IP addresses within these ranges. All other requests bypass the sidecar proxy and go directly to their destination. By default, this setting is *, which means the sidecar proxy container intercepts all outbound traffic from the workload.

Example

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

2. 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 for the Namespace and workload tabs but is optional for 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 at the bottom of the page, click Update Settings.

   This configures the sidecar proxy container to intercept requests to IP addresses in the 192.168.0.0/16 and 10.1.0.0/24 CIDR blocks.

4. Redeploy the workload to apply the sidecar proxy configuration.

5. Run the following command to check the configured outbound traffic interception IP ranges.

   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 istio-init container confirms that the -i 192.168.0.0/16,10.1.0.0/24 argument for the Addresses to Which External Access Is Redirected to Sidecar Proxy configuration is in effect.

Description

Configuration example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the desired 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 for the Namespace and workload tabs. You can skip this step for the global tab.

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

   This configuration ensures that the sidecar proxy container will not intercept requests destined for IP addresses within the 10.1.0.0/24 CIDR block.

4. Redeploy the workload to apply the sidecar proxy configuration.

5. Run the following command to verify the outbound IP range exclusion:

   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 arguments for the istio-init container now include -x 192.168.0.1/32,10.1.0.0/24. The 192.168.0.1/32 is the default host address CIDR. The presence of 10.1.0.0/24 confirms that the Addresses to Which External Access Is Not Redirected to Sidecar Proxy setting is in effect.

Description

Specify a comma-separated list of port numbers. The sidecar proxy container intercepts traffic destined for a port in this list. By default, this is set to *, which means the sidecar proxy container intercepts all inbound traffic to the workload.

Example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the target 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 applies to 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 setting means the sidecar proxy container intercepts only requests sent to ports 80 and 443 of this workload.

4. Redeploy the workload to apply the sidecar proxy configuration.

5. Run the following command to check the configured inbound interception ports:

   kubectl get pod -n <namespace-name> <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 arguments for the istio-init container now include -b 80,443, which matches the inbound ports you configured. This confirms that the Ports on Which Inbound Traffic Redirected to Sidecar Proxy setting is in effect.

Parameter

Configuration example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the target 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 for the Namespace and workload tabs. You can skip this step for the global tab.

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

   This configuration directs the sidecar proxy container to intercept requests sent to services on ports 80 and 443.

4. Redeploy the workload to apply the sidecar proxy configuration.

5. Run the following command to verify the configured interception ports.

   kubectl get pod -n <namespace-name> <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 arguments for the istio-init container now include -q 80,443, which matches the outbound ports you configured. This confirms that the Ports on Which Outbound Traffic Redirected to Sidecar Proxy setting has taken effect.

Parameter

Example

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the target 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.

   Perform this step on the Namespace and workload tabs. You can skip this step for the global tab.

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

   This setting prevents the sidecar proxy container from intercepting requests sent to port 8000 of this workload.

4. Redeploy the workload to apply the sidecar proxy configuration.

5. Run the following command to check the inbound ports excluded from interception:

   kubectl get pod -n <namespace-name> <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 arguments for the istio-init container now include -d 15090,15021,15081,9191,15020,8000. Ports 15090,15021,15081,9191,15020 are application ports for the sidecar proxy and are excluded from interception by default. The presence of port 8000 confirms that the Ports on Which Inbound Traffic Not Redirected to Sidecar Proxy setting has taken effect.

Description

Specify a comma-separated list of destination port numbers for all outbound traffic. The sidecar proxy container will not intercept requests to any port in this list. This exclusion applies regardless of whether the destination service's IP address or port is included in any interception rules.

Example

1. On the Configure the agent parameters of the injected Sidecar page, click the target sidecar proxy configuration level tab, 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 it on the global tab.

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

   This configuration prevents the sidecar proxy container from intercepting requests to services on port 8000.

4. Redeploy the workload to apply the sidecar proxy configuration.

5. Run the following command to check the configured outbound ports that are excluded from interception:

   kubectl get pod -n <namespace-name> <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 arguments for the istio-init container include -o 8000, matching the outbound port you configured. This confirms the Ports on Which Outbound Traffic Not Redirected to Sidecar Proxy setting is active.

Description

You can enable or disable the DNS proxy for the sidecar proxy. When enabled, the sidecar proxy intercepts DNS requests from the workload to improve Service Mesh performance and availability. All DNS requests from the workload are redirected to the sidecar proxy. The sidecar proxy stores a local map of IP addresses to domain names, allowing it to return DNS responses directly to the workload without querying upstream DNS servers. If the sidecar proxy cannot resolve a DNS request, it forwards the 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 configuration level, and then click DNS Proxy.

2. In the DNS Proxy section, turn on the Enable DNS Proxy switch, and then click Update Settings.

   This step is required on the Namespace and workload tabs but is optional on the global tab. Turning on the switch enables the DNS proxy for the sidecar proxy.

3. Redeploy the workload to apply the sidecar proxy configuration.

4. Run the following command to check the DNS proxy settings:

   kubectl get pod -n <namespace-name> <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 for the istio-proxy container are set to true. This confirms that the DNS Proxy configuration is active.

Parameters

This setting adds environment variables to the sidecar proxy container.

Example configuration

1. On the Configure the agent parameters of the injected Sidecar page, click the tab for the target 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 for the Namespace and workload tabs. You can skip this step for the global tab.

3. Enable the Sidecar Graceful Shutdown (EXIT_ON_ZERO_ACTIVE_CONNECTIONS) option, and then click Update Configurations.

4. Redeploy the workload to apply the sidecar proxy configuration.

5. Run the following command to verify the configured environment variables for the sidecar proxy.

   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 istio-proxy container in the Pod. This confirms that the Manage Environment Variables for Sidecar Proxy configuration is in effect.

Description

HoldApplicationUntilProxyStarts is a lifecycle setting for the sidecar proxy. Enabled by default, it ensures that in pods with an injected sidecar, the sidecar proxy container starts successfully before the application containers. This prevents traffic loss that can occur if an application container starts before its sidecar proxy is ready.

If this option is disabled, the sidecar proxy container and application containers start concurrently. When deploying a large number of pods in a cluster, the sidecar proxy container might start slowly if the API server is under heavy load. You can disable the HoldApplicationUntilProxyStarts setting to improve deployment speed.

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 for Sidecar Graceful Startup (HoldApplicationUntilProxyStarts), and then click Update Settings.

   This disables the HoldApplicationUntilProxyStarts feature.

3. Redeploy the workload to apply the sidecar proxy configuration.

4. Run the following command to verify 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
   ...

   When the holdApplicationUntilProxyStarts feature is disabled, the istio-proxy container is no longer required to be declared before the application container, and the default lifecycle field is no longer declared. In this case, the Service Mesh no longer ensures that the sidecar proxy container starts successfully before the application container starts.

Description

Termination drain duration is a lifecycle management setting for the sidecar proxy. After you inject a sidecar proxy into a Pod, the sidecar proxy container intercepts traffic to the application Pod.

When a Pod starts to terminate, the corresponding Service stops forwarding traffic to the Pod. After the sidecar proxy container receives a termination signal, it waits for a period of time. This period is called the termination drain duration. During this time, the proxy stops accepting new inbound traffic but continues to process existing inbound traffic. Outbound traffic is not affected and can be initiated normally. The default termination drain duration for the sidecar proxy container is 5s. You can configure this value in seconds by using the unit s, for example, 10s.

If your application handles long-running requests that exceed the termination drain duration, existing inbound and outbound connections might be terminated before they are complete, resulting in dropped requests. In such cases, you can extend the termination drain duration to allow these connections to finish processing.

The termination drain duration must be configured in seconds, for example, 10s.

Example

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

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

   Perform this step on the Namespace and workload tabs. You can skip this step for the global tab.

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

   This configures the sidecar proxy to wait for 10 seconds to process in-flight connections during termination.

4. Redeploy the workload to apply the sidecar proxy configuration.

5. Run the following command to verify the configured termination drain duration:

   kubectl get pod -n <namespace-name> <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 shows a terminationDrainDuration of 10s. This confirms that the Sidecar Proxy Drain Duration at Pod Termination setting has been applied.

Description

The Sidecar proxy lifecycle setting lets you customize the container lifecycle hooks for the sidecar proxy container. The lifecycle field accepts a JSON object that overrides the default container lifecycle hook configuration. For more information, see Container lifecycle hooks.

Example

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

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

   This step is required for the Namespace and workload tabs but can be skipped for the global tab.

3. Under Lifecycle of Sidecar Proxy, enter the following JSON and click Update Settings.

   This JSON configures the postStart and preStop hook handlers.

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

   • preStop: Sleeps for 13 seconds before the container is terminated.

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

4. Redeploy the workload to apply the sidecar proxy configuration.

5. Run the following command to check the configured sidecar proxy lifecycle:

   kubectl get pod -n <namespace-name> <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 change to the lifecycle field of the istio-proxy container in the Pod confirms that the Lifecycle of Sidecar Proxy configuration was applied.

Parameters

This setting configures the policy for the sidecar proxy to access external services. An external service is any service that is not registered in the Service Mesh. By default, all services within a Kubernetes cluster managed by the Service Mesh are registered services. You can also manually add services to the mesh registry by creating a Service Mesh resource. Any service not in the registry is an external service.

Configuration example

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

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

2. Redeploy the workload to apply the sidecar proxy configuration.

3. Create a file named 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 access an external service from the sleep application:

   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 confirms that the sleep application, with its injected sidecar proxy, is blocked from accessing the external service www.aliyun.com. This verifies that the Outbound Traffic Policy has taken effect.

Description

This setting controls how the sidecar proxy intercepts inbound traffic. By default, the sidecar proxy uses an iptables redirect policy to intercept inbound traffic to the application workload. When traffic is redirected, the application sees the sidecar proxy's IP as the request's source IP, not the original client IP.

Changing the inbound traffic interception policy to the transparent proxy policy (TPROXY) enables the Service Mesh sidecar proxy to use the TPROXY mode of iptables for inbound traffic. This configuration lets the application see the original client IP. For more information, see How server-side applications obtain client source IPs in a service mesh.

Configuration example

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

2. (Optional) In the Sidecar Traffic Interception Mode area, enable the Sidecar Traffic Interception Mode option.

   This step is required for the Namespace and workload tabs but can be skipped for the global tab.

3. For Sidecar Traffic Interception Mode, select TPROXY, and then click Update Settings.

4. Redeploy the workload to apply the sidecar proxy configuration.

5. To verify the configured sidecar inbound traffic interception policy, run the following command.

   kubectl get pod -n <namespace-name> <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 PROXY_CONFIG environment variable for the istio-proxy container in the pod includes "interceptionMode":"TPROXY", and the istio-init container uses the TPROXY parameter during initialization. These settings confirm that the Sidecar Traffic Interception Mode is in effect.

Description

This setting configures the log level for the sidecar proxy container. By default, the sidecar proxy uses the info log level. To control log verbosity, set the log level to one of the following values: info, debug, trace, warning, error, critical, or off.

Configuration example

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

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

   This step is required for the Namespace and workload tabs but can be skipped for the global tab.

3. Next to Log Level, select error, and then click Update Settings.

   This configuration sets the sidecar proxy to output logs at the error level. Only logs at the error level or higher are logged.

4. Redeploy the workload to apply the sidecar proxy configuration.

5. Run the following command to check the configured sidecar proxy log level.

   kubectl get pod -n <namespace-name> <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 arguments for the istio-proxy container now include --proxyLogLevel=error, which confirms that the Log Level configuration has taken effect.

Parameter

The Sidecar proxy, implemented with Envoy, can report a wide range of metrics. By default, the Service Mesh enables only a subset of these metrics to reduce performance overhead. Use this parameter to specify additional metrics to report, using prefix match, suffix match, or regex match.

Example

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

2. In the Monitoring Statistics area, for proxyStatsMatcher, select Regular Expression Match and set the value to .*outlier_detection.*.

   This configuration enables circuit breaking metrics for the Sidecar proxy.

3. Redeploy the workload to apply the sidecar proxy configuration.

4. Run the following command to verify the custom metrics configured for the Sidecar proxy.

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

   Expected output:

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

   The PROXY_CONFIG environment variable for the istio-proxy container in the Pod is updated with the custom metrics configuration. This confirms that the proxyStatsMatcher configuration has taken effect.