Sidecar Management

Injecting a Sidecar

You can view the namespace and cluster that the injected sidecar belongs to. If no sidecar has been injected or you need to inject sidecars for more namespaces, perform the following operations:

1. Log in to the ASM console and click the name of the target service mesh to go to its details page.
2. In the navigation pane, choose Mesh Configuration. Then, click the Sidecar Management tab.
3. Click Sidecar Management, select a namespace, determine whether enable Restart Existing Services, and click OK.

   Parameter description:

   • Namespace: Select one or more namespaces. The system will add automatic injection labels to namespaces based on Istio versions.
     • istio-injection=enabled can be used in Istio 1.13.9-r3 and earlier versions, as well as Istio 1.15.5-r2 and earlier versions.
     • istio.io/rev=<revision> can be used in Istio later than 1.13.9-r3, Istio later than 1.15.5-r2, and all Istio 1.18 versions.
   • Restart Existing Services: Whether the pods associated with existing services in a namespace are automatically restarted.

     : The pods are restarted. New pods will have sidecars automatically injected or removed. The restart will interrupt services temporarily.

     : The pods are not restarted. New pods will have sidecars automatically injected or removed based on the automatic injection label status of the namespace.

     Table 1 Namespace management and sidecar injection configuration

     Namespace	Label Operation	Restart Existing Services	Pod Restart Behavior	Sidecar Injection Result
     Newly selected	Adding an automatic injection label	Yes	All pods of the Deployment in the namespace are automatically restarted.	Sidecars are automatically injected into new pods.
     		No	No automatic restart	Sidecars are not injected into existing pods but are automatically injected into new pods.
     Deselected	Removing an automatic injection label	Yes	All pods of the Deployment in the namespace are automatically restarted.	Sidecars are automatically removed from new pods.
     		No	No automatic restart	Sidecars are not removed from existing pods. Sidecars are not automatically injected into new pods.
     Selected	Remaining the label unchanged	Yes	If there are pods that are not injected with sidecars, all pods running the workload will be automatically restarted. If all pods have sidecars injected, the pods will not be restarted.	If there are pods that are not injected with sidecars, the sidecars will be injected after the pods are automatically restarted. If all pods have sidecars injected, the status remains unchanged.
     		No	If there are pods that are not injected with sidecars, the pods will not be automatically restarted. If all pods have sidecars injected, the pods will not be restarted.	If there are pods that are not injected with sidecars, the status remains unchanged. If all pods have sidecars injected, the status remains unchanged.
     Not selected	Remaining the label unchanged (no automatic injection label)	Yes	No automatic restart	The status remains unchanged.
     		No	No automatic restart	The status remains unchanged.

     

     • After the istio-injection=enabled or istio.io/rev=<revision> label is set, sidecars are automatically injected into new pods in the namespace.
     • After the istio-injection=enabled or istio.io/rev=<revision> label is removed, sidecars are automatically removed from new pods in the namespace.
     • This module does not provide the function of restarting services in a specific namespace. If a namespace is deselected, the automatic injection label will be removed from the namespace. After the workload in the namespace is restarted, sidecars will not be automatically injected. You can refer to the sidecar injection result when you deselect the namespace and enable Restart Existing Services.
     • To inject sidecars into a workload in a specified namespace, ensure that the namespace is selected and enabled. Then, go to the Workloads page of the CCE cluster console, select the workload, and choose More > Redeploy. After the workload is restarted, the sidecars are automatically injected.
   • Traffic Interception Settings
     

     By default, sidecars intercept all inbound and outbound traffic of pods. You can modify the default traffic rules in Traffic Interception Settings.

     Inbound Ports: Inbound ports separated by commas (,). You can use this field to specify the ports that will be included or excluded for inbound traffic redirection.

     • Include only specified ports means that the traffic to services in a service mesh over specified ports will be redirected to the sidecar.
     • Exclude only specified ports means that the traffic to services in a service mesh over the ports except the specified ports will be redirected to the sidecar.

     Outbound Ports: Outbound ports separated by commas (,). You can use this field to specify the ports that will be included or excluded for outbound traffic redirection.

     • Include only specified ports means that the traffic from services in a service mesh over specified ports will be redirected to the sidecar.
     • Exclude only specified ports means that the traffic from services in a service mesh over the ports except the specified ports will be redirected to the sidecar.

     Outbound IP Ranges: IP address ranges separated by commas (,) in CIDR format. You can use this field to specify the IP ranges that will be included or excluded for outbound traffic redirection.

     • Include only specified IP ranges means that the traffic from specified IP ranges will be redirected to the sidecar.
     • Exclude only specified IP ranges means that the traffic from IP ranges except the specified IP ranges will be redirected to the sidecar.
   

   • For details about why sidecar injection failed, see .

   • If ASM displays a message indicating that modification of namespace injection is not enabled in the following clusters, you need to run the kubectl command to enable namespace injection. For details, see How Do I Enable Namespace Injection for a Cluster?
   • After sidecar injection is enabled for a namespace of a cluster, sidecars are automatically injected for pods of all workloads in the namespace. If you do not want to inject sidecars for some workloads, see How Do I Disable Sidecar Injection for Workloads?
   • For service meshes 1.8.4-r1 and earlier versions (including all 1.3 and 1.6 versions), you are advised to check whether the workload contains the annotation sidecar.istio.io/inject: 'true'. If not, add the annotation to the spec.template.metadata.annotations field:

           annotations:
             sidecar.istio.io/inject: 'true'

Viewing Workload Details

The list displays all workloads created in the clusters managed by a mesh. You can view the workload name, cluster to which the workload belongs, service, and sidecar information of the workload, including the sidecar name, version, status, CPU usage, and memory usage. The procedure is as follows:

Configuring Sidecar Resource Limits

You can configure the upper and lower limits of CPU and memory resources for sidecars (istio-proxy container). If the upper and lower resource limits are not set for a workload, a resource leak of this workload will make resources unavailable for other workloads deployed on the same node. In addition, workloads that do not have upper and lower resource limits cannot be accurately monitored.

The default upper and lower limits of sidecar resources are as follows:

• CPU (core): 0.1 to 2 (included)
• MEM (MiB): 128 to 1,024 (included)

To change the value, perform the following operations:

1. Click Set Resource Limit in the Operation column of the target workload. You can also select multiple workloads and click Set Resource Limit in the upper left corner of the workload list to configure sidecar resource limits in batches.
   • Minimum CPU: CPU request, the minimum number of CPU cores required by a container. Resources are scheduled for the container based on this value. The container can be scheduled to a node only when the total available CPU on the node is greater than or equal to the number of CPU cores applied for the container.
   • Maximum CPU: CPU limit, the maximum number of CPU cores required by a container.
   • Minimum memory: memory request, the minimum amount of memory required by a container. Resources are scheduled for the container based on this value. The container can be scheduled to this node only when the total available memory on the node is greater than or equal to the requested container memory.
   • Maximum memory: memory limit, the maximum amount of memory required by a container. When the memory usage exceeds the specified memory limit, the pod may be restarted, which affects the normal use of the workload.

Configuring Memory Alarms for Sidecar Resources

When the memory usage exceeds the specified memory limit, the pod may be restarted, which affects the normal use of the workload. Therefore, you are advised to configure memory alarms for all sidecar resources. After the alarms are triggered, you can increase the maximum memory size of the corresponding sidecar resource in a timely manner to reduce the impact on services.

1. Log in to the AOM console.
2. In the navigation pane, choose Alarm Center > Alarm Rules. In the upper right corner, click Create Alarm Rule.
3. Set an alarm rule.
   • Rule Name: Enter a rule name, for example, istio-proxy.
   • Rule Type: Select Threshold rule.
   • Monitored Object: Click Select resource objects, set Add by to Dimension, and select Cloud Service Metrics > CCE > Container > Physical memory usage for Metric Name.

     In the Dimension drop-down list, select Cluster ID, the ID of the cluster for which the alarm is enabled, Container name, and istio-proxy by sequence. Click Confirm.

   • Alarm Condition: Set information such as statistical periods, consecutive periods, and threshold condition.
   • Alarm Mode: Select Direct Alarm Reporting.

4. Click Create Now.

   If the following information is displayed in the rule list, the rule is created successfully.

5. You can view the latest active alarm information and load details in the alarm list.

   When the alarm is triggered, one or more records are added to the active alarm list. Click the alarm name. On the Alarm Object tab, view parameters such as deploymentName and nameSpace to determine the sidecar resource from which the alarm is generated. For details about how to modify the sidecar resource limits on the service plane, see Configuring Sidecar Resource Limits. The limits on the sidecar resources on the control plane, such as istio-ingressgateway, istio-egressgateway, and istio-eastwestgateway, need to be modified in upgrade mode on the Workloads page of the CCE console.