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>