Tanzu Platform SaaS

Troubleshoot failing services

Last Updated February 19, 2025

This topic explains how to troubleshoot failing services in Kubernetes Spaces in Tanzu Platform.

Claim is waiting for composite resource to become Ready

Problem:

You encounter the error message:

Claim is waiting for composite resource to become Ready

Explanation:

It is likely that your Kubernetes cluster lacks a default storage class.

Solution:

  1. Retrieve the Kubernetes cluster kubeconfig and list storage classes by running:

    kubectl get storageclass
    

    Example output:

    NAME                 PROVISIONER               AGE
    standard             kubernetes.io/gce-pd      1d
    
  2. Set a storage class as the default by running:

    kubectl patch storageclass STORAGE-CLASS-NAME -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
    

    Where STORAGE-CLASS-NAME is the name a storage class from the output of the previous step.

    Example output:

    storageclass.storage.k8s.io/standard patched
    

General Troubleshooting

Failures in Bitnami service installations can have various causes. Follow these steps to identify and resolve the issue.

Step 1: Identify the app instance

To identify the app instance:

  1. List apps and locate the one associated with your service instance:

    kubectl get apps
    

    Example output:

    NAME                                    DESCRIPTION           SINCE-DEPLOY   AGE
    postgres-b4pq7-pkgi                     Reconciling                          3s
    
  2. If the app is stuck in the Reconciling state, inspect it further:

    kubectl get apps APP-NAME -o yaml
    

    Where APP-NAME is the name of the app to inspect, for example, postgres-b4pq7-pkgi.

Step 2: Verify pod status

To verify the pod status:

  1. Verify that the pods are up and running:

    kubectl get pods
    

    Example output:

    NAME                READY   STATUS             RESTARTS   AGE
    postgres-whd27-0   0/1     ImagePullBackOff   0          170m
    
  2. Inspect a specific pod for more details:

    kubectl describe pod POD-NAME
    

    Where POD-NAME is the name of the pod to inspect, for example, postgres-whd27-0.

Step 3: Examine pod logs

If the service becomes unavailable, examine the pod logs:

kubectl logs POD-NAME

Where POD-NAME is the name of the pod to view the logs for, for example, postgres-whd27-0.