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. For every namespace in which you want to protect your APIs with Anypoint Service Mesh, you must provision an 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.
If you have installed Anypoint Service Mesh with Red Hat OpenShift, you must set the istio-cni network-attachment-definition in the namespace where you are running the applications.
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:
-
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 replication: replicas: <amount of replicas> # example: 2 -
Apply the CRD using the following command:
kubectl apply -f my-adapter.yaml -
Verify the adapter status, using the following command:
asmctl adapter list -
Set the label for Istio in the namespace:
kubectl label ns <namespace> istio-injection=enabled -
If have installed Anypoint Service Mesh with Red Hat OpenShift, run the following command in the namespace where your applications are running:
kubectl -n <namespace> apply -f - <<EOF apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: istio-cni EOFThis command creates the resources that enable the Istio CNI plugin in the namespace.
-
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 client credentials in Kubernetes secrets:
-
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>" } -
Apply the secret:
kubectl apply -f bookinfo-service-mesh-adapter-config.yamlIf the secret is correctly applied, a
secret/bookinfo-service-mesh-adapter-config createdmessage is displayed. -
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