Troubleshoot Confluent for Kubernetes Blueprints

This topic provides general information about troubleshooting your Confluent for Kubernetes (CFK) Blueprints deployment.

Logs

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>

Debug

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 (helm upgrade --install) with the following debugging flags to enable verbose outputs:

• To enable Orchestrator DEBUG logging: --set orchestrator.debug=true

  For example:

  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: --set operator.debug=true

  For example:

  helm upgrade --install confluent-operator confluentinc/cfk-blueprint \
    --set operator.enabled=true \
    --set operator.debug=true \
    --namespace cpc-system
  

• To enable Agent DEBUG logging: --set agent.debug=true

  For example:

  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.

1. Check for potential Kubernetes errors by entering the following command:

   kubectl get events -n <namespace>
   

2. Check for a specific resource issue, enter the following command (using the resource type example pods):

   kubectl describe pods <podname> -n <namespace>
   

3. 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.

   Tip

   If a pod has been replaced because it crashed and you want to check the previous pod’s logs, add --previous to 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.