Troubleshoot Confluent for Kubernetes Blueprints¶
This topic provides general information about troubleshooting your Confluent for Kubernetes (CFK) Blueprints deployment.
Logs are sent directly to STDOUT for each pod. Use the command below to view the logs for a CFK Blueprints pod:
kubectl logs <pod-name> -n <namespace>
There are several types of problems that can go wrong while using CFK Blueprints:
A problem happens while deploying CFK Blueprints.
A problem exists at the infrastructure level.
Something has gone wrong at the Kubernetes layer.
A problem exists at the application level.
The infrastructure is fine but something has gone wrong with Confluent Platform itself. Typically, this is caused by how CFK Blueprints components were configured in the Blueprints CR.
To debug deployment problems, run the Helm install command (
--install) with the following debugging flags to enable verbose outputs:
To enable Orchestrator DEBUG logging:
helm upgrade --install confluent-orchestrator confluentinc/cfk-blueprint \ --set orchestrator.enabled=true \ --set orchestrator.debug=true \ --namespace cpc-system
To enable CFK Operator DEBUG logging:
helm upgrade --install confluent-operator confluentinc/cfk-blueprint \ --set operator.enabled=true \ --set operator.debug=true \ --namespace cpc-system
To enable Agent DEBUG logging:
helm upgrade --install confluent-agent confluentinc/cfk-blueprint \ --set agent.mode=Local \ --set agent.enabled=true \ --set agent.debug=true \ --namespace cpc-system
Look for Kubernetes issues first, then debug CFK Blueprints.
Check for potential Kubernetes errors by entering the following command:
kubectl get events -n <namespace>
Check for a specific resource issue, enter the following command (using the resource type example pods):
kubectl describe pods <podname> -n <namespace>
If everything looks okay after running the commands above, check the individual pod logs using the following command:
kubectl logs <pod name> -n <namespace>
CFK Blueprints containers are configured so application logs are printed to STDOUT. The logs can be read directly with this command. If there is anything wrong at the application level, like an invalid configuration, this will be evident in the logs.
If a pod has been replaced because it crashed and you want to check the previous pod’s logs, add
--previousto the end of the command above.
Troubleshooting problems caused by the datacenter infrastructure, such as virtual machine (VM) firewall rules, DNS configuration, etc., should be resolved by your infrastructure system administrator.