Sidecar Management

On the Sidecar Management page, you can view information about all workloads injected with sidecars, perform sidecar injection, and configure sidecar resource limits.

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:

Log in to the ASM console and click the name of the target service mesh to go to its details page.
In the navigation pane, choose Mesh Configuration. Then click the Sidecar Management tab.
Click Sidecar Management, select a namespace, determine whether to restart the existing services, and click OK.

Figure 1 Injecting a sidecar
- 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.
- 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:

In the drop-down list and search box in the upper right corner of the workload list, select a cluster and namespace, and enter the target workload name.
Click in front of the workload to view the sidecar information of the workload.
If the system displays a message indicating that there is no sidecar in the workload, no sidecar has been injected into the namespace to which the workload belongs. In this case, you can inject one into the namespace. For details, see Injecting a Sidecar.

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:

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.