Contact Free trial Login

Provision the Adapter Using a CRD

Before you can start managing your services using Anypoint Service Mesh, you must prepare your namespace by provisioning an 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 acts as a policy enforcement component that 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 set the istio-injection label on the namespace and redeploy all your existing applications in that namespace 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

small

.5

1

25

medium

1

1.5

50

large

2

2

100

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.

Provision the Adapter Using a CRD

To provision the Anypoint Service Mesh adapter using a CRD:

  1. Create your adapter definition file and save it with a '.yaml' file extension:

    apiVersion: servicecatalog.k8s.io/v1beta1
    kind: ServiceInstance
    metadata:
      name: <adapter name> # example: bookinfo-service-mesh-adapter
      namespace: <namespace name> # example: default
      labels:
        service-mesh.mulesoft.com/kind: adapter
    spec:
      clusterServiceClassExternalName: anypoint-service-mesh-adapter
      clusterServicePlanExternalName: <plan size > # example: small.
      parameters:
        clientId: <client id> # example: 4bc55ee4cfc84a2ddddbb2c1109d1123c5c4
        clientSecret: <client secret> # example: 8E5ae17BbB664Eddd9ab32A5fA869874Be7
        platformUri: <platform uri> # example: https://eu1.anypoint.mulesoft.com
        replication:
          replicas: <amount of replicas> # example: 2
  2. Apply the CRD using the following command: kubectl apply -f my-adapter.yaml

  3. Verify the adapter status, using the following command: asmctl adapter list

  4. Set the label for Istio in the namespace: kubectl label ns <namespace> istio-injection=enabled

  5. Redeploy all your existing applications in the namespace.

Reference Kubernetes Secret

Anypoint Service Mesh supports the use of Kubernetes secrets to store and manage sensitive information, such as your user credentials.

Task Prerequisites

You must have the required permission to create the Kubernetes secret.

To store your user credentials in Kubernetes secrets:

  1. In a YAML file, create a secret in which to store the sensitive information, for example, bookinfo-service-mesh-adapter-config.yaml:

    apiVersion: v1
    kind: Secret
    metadata:
      name: <secret name> # example: bookinfo-service-mesh-adapter-config
      namespace: <namespace name> # example: default
    type: Opaque
    stringData:
      config: |
        {
          "clientId": "<replace-with-clientId>",
          "clientSecret": "<replace-with-clientSecret>"
        }
  2. Apply the secret:

    kubectl apply -f bookinfo-service-mesh-adapter-config.yaml

    If the secret is correctly applied, a secret/bookinfo-service-mesh-adapter-config created message is displayed.

  3. Reference the secret in your adapter CRD (instead of the clientId and clientSecret parameters), as illustrated in the following example:

    apiVersion: servicecatalog.k8s.io/v1beta1
    kind: ServiceInstance
    metadata:
      name: <adapter name> # example: bookinfo-service-mesh-adapter
      namespace: <namespace name> # example: default
      labels:
        service-mesh.mulesoft.com/kind: adapter
    spec:
      clusterServiceClassExternalName: anypoint-service-mesh-adapter
      clusterServicePlanExternalName: <plan size > # example: small.
      parameters:
        replication:
          replicas: <amount of replicas> # example: 2
      parametersFrom: # The element specifies the secret name and configuration required for retrieving the parameters
        - secretKeyRef:
            name: <secret name> # example: bookinfo-service-mesh-adapter-config
            key: config

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub