1

I have managed to deploy Asterisk to Google Container Engine (GKE) currently to the extent that a VoIP softphone can register. I'd now like to attach to Asterisk's container.

kubectl attach -it <pod-id>

however leads fast repetitions of Asterisk's CLI prompt (*CLI> *CLI> *CLI ...) without a chance for me to type in anything. It looks as if there is an endless cycle of attach/detach happening. How can I resolve this situation so that I can obtain clean access to the CLI (with a single *CLI> prompt)?

UPDATE The same repetitions happen when to try to attach in two steps:

gcloud compute ssh <instance-id>
<instance># sudo docker attach <image-id>
Drux
  • 646
  • 1
  • 8
  • 23
  • If you see the same behavior using docker attach, then it seems unrelated to kubectl attach. Once you determine why docker attach isn't working and fix that, kubectl attach should work as well. – Robert Bailey Jul 22 '16 at 07:16
  • @RobertBailey If I `docker run -d -it` and `docker attach` to the Docker image from Google Cloud Shell (after `docker build`ing it also there) the problem does not occur. Could it be that the equivalent of option `-it` is missing with respect to GKE? – Drux Jul 22 '16 at 16:55
  • @RobertBailey Probably the solution lies in the container's spec in my `Deployment.yaml`with `stdin: true` and `tty: true`. I'll try that a bit later. Thx for your comment which put he on the (hopefully) right track. – Drux Jul 22 '16 at 18:05
  • Let me (and everyone else) know if setting stdin/tty helps, since if so that's likely to help someone else (and could be made clearer in the docs). – Robert Bailey Jul 23 '16 at 05:46
  • @RobertBailey It did not help yet. Now `kubectl attach` now longer leads into the cycle, instead there is no `*CLI>` prompt at all. Strangely (or not) `kubectl describe pod` does not report `stdin` and `tty` to be set, as I would have expected. For now, I am using another workaround (`kubectl exec bash` and then `asterisk -r`), but of course I'll post an answer if I shall be able to solve the problem. (And I'd still be interested if somebody else can.) – Drux Jul 23 '16 at 06:16
  • I'm glad you at least found a workaround. – Robert Bailey Jul 30 '16 at 04:53

1 Answers1

1

The cycle of prompts is characteristic of a program which is reading from /dev/null in the belief that it's a tty. The Kubernetes documentation for the stdin field in v1.Container warns about it:

Whether this container should allocate a buffer for stdin in the container runtime. If this is not set, reads from stdin in the container will always result in EOF. Default is false.

By the way, the -t flag for kubectl attach does not change whether the container has a tty or not. Except for error messages in some conditions, it's a no-op.

It seems clear that, as kubectl describe is admitting to you, the asterisk container is being started without stdin and tty. There's no open bug for this. Unless there's a typo (or you're running rktnetes), you might consider opening one for this.

aecolley
  • 943
  • 4
  • 15