Contact Us 1-800-596-4880
  1. Homepage
  2. Service Mesh (1.2)
  3. Troubleshoot Service Mesh

  4. Adapter Provisioning Issues

Troubleshoot Adapter Provisioning Issues

When you provision the adapter, you might encounter issues such as insufficient resources or an image that cannot be accessed. The following section provides possible causes and solutions for your deployment and service issues:

Insufficient Resource Allocation

When you attempt to provision the adapter, your adapter pod will not be able to start.

Cause

If your adapter pod does not have sufficient CPU space allocated, your adapter fails.

Diagnose

To diagnose the issue:

  1. Check the adapter status:

    $ asmctl adapter list

    The status is displayed in a few minutes.

  2. If the adapter displays a Failed status, run the following command: $ kubectl -n service-mesh get pods

  3. Check the status of the adapter pod:

    $ kubectl -n service-mesh get pods | grep grpcmule

    If the status is Pending, describe the pod:

    $ kubectl -n service-mesh describe pods -l namespace=namespace

  4. If you do not see the grpcmule-namespace pod, run the same command immediately after creating the adapter, while it is being provisioned but before it has failed:

    $ kubectl -n service-mesh describe pods -l namespace=namespace

  5. Perform one of the following actions:

    • In the Events section, verify that you have an “Insufficient CPU” or other resource listing:

Events:
Type     Reason            Age                 From               Message
----     ------            ----                ----               -------
Warning  FailedScheduling  46s (x5 over 3m7s)  default-scheduler  0/3 nodes are available: 3 Insufficient cpu.

  • Describe the nodes to check the resource allocation:

    $ kubectl describe nodes The allocated resources are displayed:

Insufficient resources available for adapter provisioning

Solution

To resolve this issue:

  1. Delete the existing adapter.

  2. Assign additional resources to your Kubernetes Cluster, as required.

  3. Provision your adapter again.

Image Cannot Be Pulled

After provisioning the adapter, it fails to start with the following error:

Cause

This issue can occur due to either invalid credentials specified in the adapter or issues with the registry-credentials-rotator pod.

Diagnosis

To diagnose the issue, verify the status of the affected pods:

$ kubectl -n service-mesh get pods Your pod might appear in either a ErrImagePull or a ImagePullBackOff state.

Solution

To resolve this issue:

  1. Ensure that the registry-credentials-rotator pod is running:

    $ kubectl -n service-mesh get pod -l app=service-mesh-registry-credentials-rotator

  2. Review the logs of the pod to ensure that no client ID and client secret, entitlement, or permissions issues occurred:

    $ kubectl -n service-mesh logs $(kubectl -n service-mesh get pod -l app=service-mesh-registry-credentials-rotator -oname)

  3. Verify that the pull secret was created:

    $ kubectl -n service-mesh get secret service-mesh-pull-secret

  4. Verify that the correct platform URL and credentials are provided:

    $ kubectl -n service-mesh get secret service-mesh-registry-credentials-rotator-env -ogo-template='CLIENT_ID:{{.data.CLIENT_ID|base64decode}} CLIENT_SECRET:{{.data.CLIENT_SECRET|base64decode}}'

    $ kubectl -n service-mesh get cm service-mesh-registry-credentials-rotator-env -ogo-template='PLATFORM_URI:{{.data.PLATFORM_URI}}'

Mule Runtime Engine Fails to Start Due to License Issues

When you attempt to list your adapters, you might receive a Failed status.

Cause

If you did not provide a valid Mule runtime engine (Mule) license, with the required entitlements, your Mule adapter does not start.

Diagnosis

To diagnose the issue:

  1. Verify the adapter status:

    $ asmctl adapter list

  2. If the adapter status is Failed, verify the status of the (grpcmule-<namespace>) adapter pod:

    $ kubectl -n service-mesh get pods In this case, your pod status might be displayed as CrashLoopBackOff.

Solution

To resolve this issue, update the adapter with a valid license:

$ asmctl management config license --license=/path/to/license.lic

Catalog Content Initialization Failed

When you attempt to provision an adapter, it might fail because the catalog content did not correctly initialize.

Cause

The Anypoint Service Mesh Catalog component is required to provision adapters, create bindings, and create APIs. If the catalog is not initialized correctly, the adapter fails.

Diagnosis

To diagnose the issue:

  1. Review the adapter logs:

    $ asmctl adapter logs --namespace=adapter_namespace --name=adapter_name

    Output similar to the following is displayed:

    2019-11-26T20:46:35Z Error provisioning ServiceInstance of ClusterServiceClass (K8S: "4f6e6cf6-ffdd-425f-a2c7-3c9258ad246a" ExternalName: "anypoint-service-mesh-adapter") at ClusterServiceBroker "service-mesh-incluster-broker": Status: 500; ErrorMessage: <nil>; Description: Catalog content init failed; ResponseError: <nil>

Solution

To resolve this issue, run the following command to force catalog initialization:

$ kubectl -n service-mesh patch clusterservicebrokers/service-mesh-incluster-broker --type=json -p='[{"op": "replace", "path": "/spec/relistRequests","value":1}]'

Adapter Failed to Delete

When you attempt to delete an adapter that you previously created, you might encounter issues.

Cause

If the adapter that you want to delete has service bindings associated with it, you cannot delete that adapter.

Diagnosis

To diagnose the issue, verify adapter status:

$ asmctl adapter list

If there are bindings associated with the adapter or the service instance, the status is displayed as DeprovisionBlockedByExistingCredentials.

Solution

To resolve this issue, delete all the bindings associated with the adapter. When every binding is successfully deleted, the adapter is also deleted.