By default, every sidecar proxy in a mesh receives the full configuration for all services on the data plane. This increases memory usage on each proxy and generates unnecessary control plane pushes whenever the control plane or data plane is modified -- even for services a workload never calls.
Service Mesh (ASM) solves this by analyzing the access logs generated by sidecar proxies to discover which services each workload actually calls. ASM then recommends a scoped Sidecar resource for each workload. After you apply a scoped sidecar:
The proxy only holds configuration for services the workload depends on.
The control plane skips pushing updates when unrelated services or their associated resources (such as virtual services) change.
Prerequisites
Before you begin, make sure you have:
An ASM instance. See Create an ASM instance
A Container Service for Kubernetes (ACK) managed cluster. See Create an ACK managed cluster
The ACK cluster added to the ASM instance. See Add a cluster to an ASM instance
An ingress gateway deployed. See Create an ingress gateway
An application deployed in the ASM instance. See Deploy an application in an ASM instance
Log Service configured to collect data plane access logs. See Use Log Service to collect access logs on the data plane
Usage notes
| Note | Details |
|---|---|
| Log Service project selection | If you selected Use Default for the Log Service project when enabling access log collection, ASM uses the Log Service project of the first cluster added to the ASM instance to generate recommendations. |
| Per-workload scope | Recommendations are generated per workload. This simplifies the sidecar configuration of the data plane to the maximum extent. Configure each workload individually. |
| Incomplete call data | If a workload has no call records in the access logs, the recommended sidecar may be inaccurate. Verify it manually before applying. |
Step 1: Generate access logs
Open a browser and go to http://{IP address of the ingress gateway service}/productpage. Refresh the Bookinfo application page several times until it alternates between black and red star ratings. This generates the access log data that ASM uses to analyze service dependencies.
Step 2: Generate and apply a sidecar recommendation
Log on to the ASM console.
In the left-side navigation pane, choose Service Mesh > Mesh Management.
On the Mesh Management page, click the name of your ASM instance.
In the left-side navigation pane of the instance, choose Mesh Optimization Center > Inbound and Outbound Traffic Configuration (Sidecar Object).
Find the target workload and click Recommend in the Actions column. Wait until the Recommendation status column shows Recommendation complete.
Click View in the Actions column to open the Recommended Sidecar panel.
In the Recommended Sidecar panel, verify that the hosts field in the Sidecar YAML includes every service the workload calls. If a required service is missing from hosts, add it to the YAML before proceeding.
Click OK to apply the sidecar configuration.
(Optional) Re-recommend after dependency changes
As applications evolve, service dependencies change and previously recommended sidecars may no longer reflect actual call patterns. To update a sidecar recommendation, collect fresh access logs and generate a new recommendation:
Log on to the ASM console.
In the left-side navigation pane, choose Service Mesh > Mesh Management.
Click the name of your ASM instance, then choose Mesh Optimization Center > Inbound and Outbound Traffic Configuration (Sidecar Object).
Find the target workload and click Recollecting Access Logs in the Actions column.
In the Recollecting Access Logs message, click OK. The existing sidecar is deleted, and the Recommendation status column changes to Recollecting access logs.
Generate new access logs by repeating Step 1.
Generate a new recommendation by repeating Step 2.