Sidecar Management

Injecting a Sidecar

You can view the namespace and cluster to which the injected sidecar belongs. If no sidecar has been injected or you need to inject sidecar 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 to restart the existing services, and click OK.
   • Namespace: Select one or more namespaces. The system labels the namespaces with istio-injection=enabled.
   • Restart Existing Services

     : Pods of the existing services in the namespace will be restarted, which will temporarily interrupt your services. The istio-proxy sidecar is automatically injected into the pods of the existing services.

     : The istio-proxy sidecar cannot be automatically injected into the pods of the existing services. You need to manually restart the workloads on the CCE console to inject the sidecar. Whether to restart existing services affects only existing services. If the namespaces are labeled with istio-injection=enabled, sidecars will be automatically injected into new pods.

   • 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 excluded from redirection to the sidecar.

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

   • If the system 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 meshes of 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 Alarm 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 alarm for all sidecar resources. After the alarm is 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 on the left, choose Alarm Center > Alarm Rules, and click Add Alarm in the upper right corner.
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 page, view parameters such as deploymentName and nameSpace to determine which sidecar resource is the alarm source. 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.