If a case where spawn failes, or a server crashes unepectedly, its good if we log recent k8s Events.
spawner.stop() is called even if start() has failed. Min suggests we look there for anything but exit status 0 and status Running, in that case we provide additional logs about the situation using information in k8s Event resources associated with the pod.
It may be relevant to get the logs from the container as well.
Two reasons for crashing:
k8s level, OOMKilled, someone else deleted the pod etc
server process crashed
Motivation
It requires knowhow about kubectl get events or kubectl describe pod to get info about k8s Events.
k8s Events are often cleared after ~60 minutes
k8s pod logs are gone from k8s after the pod is removed
even if a cloud provider can provide logs etc, its often requires additional cloud provider specific know-how
If a case where spawn failes, or a server crashes unepectedly, its good if we log recent k8s Events.
spawner.stop() is called even if start() has failed. Min suggests we look there for anything but exit status 0 and status Running, in that case we provide additional logs about the situation using information in k8s Event resources associated with the pod.
It may be relevant to get the logs from the container as well.
Two reasons for crashing:
Motivation
kubectl get eventsorkubectl describe podto get info about k8s Events.