Provision the Adapter Using the CLI

Before you can start managing your services using Anypoint Service Mesh, you must prepare your namespace by provisioning a Anypoint Service Mesh adapter. Provisioning prepares the namespace for the Anypoint Service Mesh configuration. As a best practice, you must create one namespace per adapter.

The adapter behaves as the policy enforcement component, which fetches policies from Anypoint platform, checks whether the policies have been met, and then reports the analytics data back to Anypoint Platform.

After you provision the adapter, you must redeploy all your existing applications to ensure that the Envoy sidecar is injected within each pod in the Kubernetes Cluster.

Adapter Plan

When you provision the adapter, you must specify the size of the adapter based on the number of CPUs and memory of the system that will be managed using Anypoint Service Mesh. The following adapter plans are currently supported:

Plan CPU (cores) Memory (GiB) API Limit













You can also modify the size of an adapter after it has been provisioned. If you update the plan size, the adapter deployment is updated appropriately. Kubernetes then creates a pod with the new information. However, the old adapter continues handling requests until the new pod is ready.

After the new adapter is ready, the old pod is terminated and all requests are routed to the new adapter. If the update fails to start up a new pod due to insufficient space, or if the pod is not ready, an error message is recorded in a Kubernetes event. In such a scenario, the old adapter continues to handle requests because the new pod is not yet available.

You can delete an adapter if it is no longer required. However, you must delete all existing bindings for the adapter before you delete the adapter itself.

Adapter Status

When you provision an adapter, or bind the adapter to an application, a message is displayed after you run an adapter command. The message indicates whether the adapter was created, deleted, or modified successfully.

Additionally, you can verify the adapter status, which provides further details about the adapter. To view the adapter status, type the following command:

asmctl adapter list

The status values include:

  • Ready: The adapter is now ready to be used.

  • Failed: The adapter was not created successfully. An error occurred.

  • Provisioning: The adapter is in the process of being provisioned.

  • DeprovisionBlockedByExisingCredentials: The adapter has existing bindings, which are in use.

    Note that you must delete all associated bindings before you delete the adapter.

CLI Help for Adapter Commands

After you install Anypoint Service Mesh, you can use the command line interface (CLI) help to learn about the Anypoint Service Mesh commands and their parameters:

asmctl adapter help

CLI help for adapter commands

Provision the Adapter Using the CLI

Before you provision the adapter, complete the task prerequisites.

Task Prerequisites

Note that all object names, such as adapter name, binding name, and service name, must be in lowercase letters, for example, test_adapter_name. An error is thrown if you do not follow Kubernetes naming conventions.

To provision the Anypoint Service Mesh adapter using the CLI:

  1. Determine the adapter size based on the plan.

  2. From the API Manager main page, click Environment Information to obtain the client ID and client secret credentials for your environment.

  3. From the Anypoint Service Mesh installer download location in the Command window, type the following command to create the adapter:

    asmctl adapter create \
    --name=<adapter name> \
    --namespace=<adapter namespace> \
    --size=<adapter plan size> \
    --replicas=<amount of replicas for the adapter> \
    --clientId=<clientId of the environment or organization> \
    --clientSecret=<client secret of the environment or organization>
    Parameter Name Description Required or Optional Default Value


    The name of the adapter that you want to create, for example, “service-mesh-test-adapter”.


    Not applicable


    The namespace in which you want to create the adapter, for example, “mulesoft-apps”.




    The size of the adapter based on the number of CPUs and memory to use




    The number of replicas you want to spin for the mule adapter. For high availability it is recommended not to have less than two.




    The client ID of the environment (recommended) or the organization. Use the client ID that you obtained as part of the permission and roles prerequisites as explained in this document.


    Not applicable


    The client secret of the environment (recommended) or the organization. Use the client secret that you obtained as part of the permission and roles prerequisites as explained in this document.


    Not applicable


    The URL of the host where Anypoint Platform is installed


  4. Verify the adapter Status:

    asmctl adapter list

    Example output
  5. Review adapter logs to see detailed information about Kubernetes events and adapter transactions:

    asmctl adapter logs --name=<adapter_name> --namespace=<namespace>

  6. Run the following commands, one-by-one, for each of your applications that were already running in the namespace before starting the Anypoint Service Mesh installation:

    1. Determine the deployment name for the patch:

      kubectl get deployments -n <namespace>

    2. Using the deployment name from the previous command, restart all your services that need to be managed by Anypoint Service Mesh to inject the sidecar in the pod:

      kubectl -n <adapter-namespace> patch deploy <deployname> --type=json -p='[{"op": "replace", "path": "/spec/template/metadata/labels/","value":"enable"}]'

  7. To verify that the the applications are redeployed, run the following command:

    kubectl get pods -n <namespace>.

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub
Give us your feedback!
We want to build the best documentation experience for you!
Help us improve with your feedback.
Take the survey!