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