Troubleshooting an instant3Dhub Instance#
Introduction#
Note
For troubleshooting we focus on Kubernetes as it is our recommended deploy format.
The following cases contain frequent issues encountered during the rollout of instant3Dhub. This content serves as an addition to the other integration guides and will be extended over time. In case you need support it is vital that you look into the following topics first.
License Server#
The startup of all instant3Dhub components is independent of the license server
setup. All pods will show Running
even if the address to the license server
is wrong or the license is expired. Errors will only become visible during
transcoding or other transactions which require a license checkout.
Container Stuck in ContainerCreating
#
This behavior can have many causes. Its is likely that the root cause is not an instant3Dhub issue. Possible sources of this behavior:
Volume mounts not setup correctly.
Special capability nodes are all claimed by other pods.
Refer to debugging steps below, especially kubecl describe
to determine exact failure causes.
Pods shows unusual amount of CrashLoopBackOff
#
As instant3Dhub does not feature init containers yet, it is normal to see at least a few restarts of pods until the system is fully operational. Should this count exceed 10 it is likely that something else went wrong. Usually the container logs provide a hint of the problem.
Several pods are required for the system to work, and containers which depend on
these will be in a CrashLoopBackOff
:
i3dhub-postgres
i3dhub-rabbitmq
i3dhub-consul
i3dhub-keystore
Once these have started succesfully the rest of the containers should start. If any containers are not starting, it is worth trying the debugging steps below to determine the root cause.
kubectl
troubleshooting#
If you prefer other tools to monitor or manage your cluster feel free to use
them. As kubectl
should be available anywhere, we use it as a baseline tool
to explain our way of troubleshooting instant3Dhub. For extensive information
use the official kubernetes documentation. The following commands should be
enough to figure out most errorcases:
Determine pod states:
kubectl describe pod <name> -n <namespace>
Print logs of running or failed pods:
kubectl logs <podname> -n <namespace>