<p>I have been readying here and there online but the answer does not come thoroughly explained. I hope this question here if answered, can provide an updated and thorough explanation of the matter.</p>
<p>Why would someone define a container with the following parameters:</p>
<pre><code>stdin: true
tty: true
</code></pre>
<p>Also if</p>
<pre><code>`docker run -it`
</code></pre>
<p>bind the executed container process to the calling client stdin and tty, what would setting those flag on a container bind its executed process it to ?</p>
<p>I could only envision one scenario, which is, if the command is let say bash, then you can <strong>attach</strong> to it (i.e. that bash running instance) later after the container is running.</p>
<p>But again one could just run <code>docker run it</code> when necessary. I mean one launch a new bash and do whatever needs to be done. No need to attach to a running one</p>
<p>So the first part of the question is:</p>
<p>a) What is happening under the hood ?</p>
<p>b) Why and when to use it, what difference does it make and what is the added value ?</p>

<p>AFAIK, setting <code>stdin: true</code> in container spec will simply keep container process stdin open waiting for somebody to attach to it with <code>kubectl attach</code>.</p>
<p>As for <code>tty: true</code> - this simply tells Kubernetes that stdin should be also a terminal. Some applications may change their behavior based on the fact that stdin is a terminal, e.g. add some interactivity, command completion, colored output and so on. But in most cases you generally don't need it.</p>
<p>Btw <code>kubectl exec -it POD bash</code> also contains flags <code>-it</code> but in this case this really needed because you're spawning shell process in container's namespace which expects both stdin and terminal from user.</p>
