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.