Troubleshooting¶

Find more information about how to deal with common errors related to Bitnami’s Helm charts in this troubleshooting guide.

Setting Security for Your Namespace¶

If the log indicates an error accessing the secret, you may need to grant security to your namespace. The error may look something like this:

Error accessing license secret: kube-system/ls-k8s-webadc: secrets "ls-k8s-webadc" is forbidden: User "system:serviceaccount:default:ls-k8s-webadc" cannot get resource "secrets" in API group "" in the namespace "NAMESPACE"

Typically granting security is done as follows:

$ kubectl create clusterrolebinding default-admin --clusterrole cluster-admin --serviceaccount=default:default -n NAMESPACE

Getting the Pod Name¶

To do any troubleshooting you'll need the full name of the pod. This is obtained by running:

kubectl get pods -n NAMESPACE -o wide

Note that we recommend running the wide version of the command so that you can see not only the names, but also the nodes and addresses of the pods.

The name of the LiteSpeed Ingress Controller pod is of the format ls-k8s-webadc-SUFFIX. For example: ls-k8s-webadc-5b6cb78b89-qdhjx

Pod Status¶

Sometimes the problems are described in a simple pod description. For example:

kubectl describe pod ls-k8s-webadc-5b6cb78b89-qdhjx >desc.log

You can examine desc.log at your lieisure or it may be requested by LiteSpeed tech support.

Logs¶

There is a pod log which describes issues related to the management of the load balancer, and there's the load balancer's log itself.

Pod Log¶

As with most Kubernetes processes, the best troubleshooting technique is to examine the log. This is done by getting the pod name.

For example, to get the log for the pod named ls-k8s-webadc-5b6cb78b89-qdhjxls-k8s-webadc-5b6cb78b89-qdhjx and saved to pod.log you would specify:

kubectl logs ls-k8s-webadc-5b6cb78b89-qdhjx -n NAMESPACE > pod.log

You can then examine pod.log at your leisure or it may be requested by LiteSpeed tech support.

If you have issues with the task restarting and old logs disappearing, there are commands to see old logs in kubectl. For example to see the immediate previous one for this pod:

kubectl logs ls-k8s-webadc-5b6cb78b89-qdhjx -n NAMESPACE --previous > pod.log

Please don't forget to verify that the pod terminates in a reasonable amount of time, otherwise you will fill up your disk or information will be lost.

Load Balancer Log¶

The load balancer log is the log from the WebADC program itself and the current one can be found at /usr/local/lslb/logs/error.log. Older ones are stored there too with date suffixes. Using the name of the pod from the example above you can copy the most recent log to your drive:

kubectl cp -n NAMESPACE ls-k8s-webadc-5b6cb78b89-qdhjx:usr/local/lslb/logs/error.log error.log

Errors accessing after deletion¶

You may see errors accessing service nodes if you just delete the service and attempt to re-create it right away. You should delete all services and pods, wait until they have terminated and are gone, and then re-create them.