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:
-
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
-
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:
-
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
-
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:
-
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
-
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
.
Content feedback and comments