kubernetes: kubectl exec -i exits prematurely

This is usually the load balancer timeout in front of an apiserver. Check the timeout from the ELB

Having the same problem here. Running v1.5.1 Connections do not get interrupted when data is being sent. So when I launch an interactive container session, with a script that outputs something every now and then, it seems to work.

Based on that, I created a nasty workaround to keep my container sessions going, without my interaction. It is really annoying that these sessions terminate prematurely. They leave garbage behind, that needs to cleaned up in case you are attaching to a running production container.

The workaround (print a space-character to STDERR every 59 seconds as a background process):

# within your container session
$ while :; do sleep 59; echo -n ' ' >&2; done &

See the following output, when I do not launch such a script. It demonstrates that an interactive session terminates prematurely within ~ X minutes.

This is really annoying if you are leveraging this functionality to debug running applications and container installations.

$ time kubectl run -i --tty busybox --image=busybox --restart=Never -- sh
Waiting for pod default/busybox to be running, status is Pending, pod ready: false
If you don't see a command prompt, try pressing enter.
/ # Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
Waiting for pod default/busybox to terminate, status is Running
error: timed out waiting for the condition

real	2m4.657s

I’m seeing something similar. kubernetes running in AWS EC2. If I kubectl exec <pod-name> -i -t -- ash, I get booted after about 60 seconds of no activity. Which is annoyingly short for an interactive session. Is this configurable?

Some message on disconnect might be nice as well. The only visible indication is that my shell prompt changes, and it can be easy to not realize that I’m now back at my local host, and not on the kube pod.

I also noticed another downside to this:

Whatever we are doing using exec at the time of the disconnect keeps running in the background: meaning we sometimes use a console program to enter our production code, which consumes some amount of memory inside the pod. After a day of disconnects, we have 20 to 30 running unused consoles , and a pod that has reached is memory limit, degrading performance of the actual application running inside the pod.

A good old kill -9 after exec’ing as sh solves this problem, but it’s annoying nonetheless.