check InfraP

To check and debug the component creation of the Infrastructure Provider in the Cluster API Provider for Tinkerbell (CAPT), you can follow these steps. These steps help verify that the infrastructure provider is functioning correctly and provide methods to troubleshoot issues if something goes wrong.

1. Check the Infrastructure Provider Deployment

First, ensure that the CAPT Infrastructure Provider has been deployed correctly in your management Kubernetes cluster.

Verify Deployment Status:

Use kubectl to check the deployment status:

kubectl get deployments -n capt-system

This command lists all deployments in the capt-system namespace, including the infrastructure provider.

  • Expected Output: You should see a deployment related to the infrastructure provider, such as capt-controller-manager. Ensure the READY, UP-TO-DATE, and AVAILABLE columns indicate that the deployment is running correctly (e.g., 1/1 for all).

2. Check the Infrastructure Provider Pods

Check the pods running for the infrastructure provider:

kubectl get pods -n capt-system

This command shows all pods in the capt-system namespace.

  • Expected Output: The pods related to capt-controller-manager should be in the Running state with no restarts (indicating they haven’t crashed).

3. View Logs from the Infrastructure Provider

If the deployment and pods are running but you suspect an issue, view the logs of the pods to investigate further.

kubectl logs -n capt-system <pod-name>

Replace <pod-name> with the actual pod name of the infrastructure provider.

  • Expected Output: Logs should provide detailed information on the operation of the CAPT Infrastructure Provider, including any errors, warnings, or events during the creation of infrastructure components.

4. Check Custom Resource Definitions (CRDs)

Ensure that the necessary CRDs for the Tinkerbell infrastructure are present and correctly registered.

kubectl get crds | grep tinkerbell
  • Expected Output: You should see CRDs related to Tinkerbell, such as tinkerbellclusters.infrastructure.cluster.x-k8s.io, tinkerbellmachines.infrastructure.cluster.x-k8s.io, and tinkerbellmachinetemplates.infrastructure.cluster.x-k8s.io.

5. Verify Infrastructure Resource Creation

Check the status of infrastructure resources like TinkerbellCluster, TinkerbellMachine, and TinkerbellMachineTemplate:

kubectl get tinkerbellclusters -A
kubectl get tinkerbellmachines -A
kubectl get tinkerbellmachinetemplates -A
  • Expected Output: These commands should list the infrastructure resources. Ensure they are in a Ready or expected state.

6. Describe the Infrastructure Resources

If an infrastructure resource is not behaving as expected, describe the resource to get more detailed information:

kubectl describe tinkerbellcluster <cluster-name> -n <namespace>
kubectl describe tinkerbellmachine <machine-name> -n <namespace>
  • Expected Output: The describe command should give you details about the resource, including events, status, and any error messages.

7. Check Events in the Namespace

Sometimes issues may not be directly evident from the logs or resource descriptions. Checking for events in the namespace can provide insights into what might be going wrong:

kubectl get events -n capt-system --sort-by='.metadata.creationTimestamp'
  • Expected Output: Look for warning or error events that might indicate issues during the creation or management of infrastructure resources.

8. Enable and Check Debug Logs (Advanced)

If you need more detailed debugging information, you can increase the verbosity of the CAPT controller by modifying the deployment manifest to add a --v=5 flag (or higher, up to --v=10) to the controller manager’s command.

  1. Edit the Deployment:
kubectl edit deployment capt-controller-manager -n capt-system
  1. Modify the Command Section:

Look for the command section and add the verbosity flag:

command:
- /manager
- --v=5
  1. Save and Exit: This change will restart the controller with more detailed logging enabled.
  2. Check Logs Again:
kubectl logs -n capt-system <pod-name>
  • Expected Output: The logs should now contain more detailed debugging information, which can help diagnose complex issues.

9. Interact with CAPT Resources via Tink CLI (Optional)

If you have direct access to the Tink CLI, you can interact with Tinkerbell resources directly to see if they are being created as expected:

tink hardware list
tink workflow list

These commands allow you to see the underlying hardware and workflows that CAPT is interacting with. If resources are not being created in Tinkerbell, this could indicate an issue with the CAPT infrastructure provider.

10. Cross-Check with Cluster API Resources

Finally, ensure that the Cluster, Machine, MachineDeployment, and related CAPI resources are correctly reconciled:

kubectl get clusters -A
kubectl get machines -A
kubectl get machinedeployments -A
kubectl get machinetemplates -A
  • Expected Output: These resources should show the expected states (Provisioned, Running, etc.). If not, it could indicate an issue with how the Infrastructure Provider is interacting with CAPI.

Conclusion

By following these steps, you can effectively check and debug the CAPT Infrastructure Provider’s creation and operation within your Kubernetes management cluster. These tools and methods provide comprehensive insights into the state and behavior of the infrastructure provider, helping to identify and resolve issues that may arise during the provisioning and management of bare-metal resources.