unless that is how we would execute it normally (i.e., do ls -t /usr, not “ls -t /usr”). Also note, do not surround our command and its flags/arguments with quotes. We must use two dashes (–) to separate our command’s flags/arguments. If the command we want to execute in the pod has any flags in common (e.g. List contents of /usr from the first container of pod mypod and sort by modification time. Switch to raw terminal mode, sends stdin to ‘bash’ in ruby-container from pod mypod and sends stdout/stderr from ‘bash’ back to the client kubectl exec mypod -i -t - ls -t /usr Get output from running ‘date’ command in ruby-container from pod mypod kubectl exec mypod -c ruby-container -i -t - bash -il Kubectl exec mypod -c ruby-container - date Get output from running ‘date’ command from pod mypod, using the first container by default we don’t have to start a shell in the container. Whereas SSH automatically starts a shell process and binds our terminal’s input and output streams, kubectl makes each of these aspects customizable. Without these flags, we’d see a read-only output stream. This sets up an interactive session where we can supply input to the process inside the container. These instruct kubectl to route our terminal’s stdin input stream to the container (-i) and treat it as a TTY (-t). The -it is equivalent to using the –stdin (-i) and –tty (-t) flags. Anything after the - will be passed to the container, as opposed to kubectl. The - separates the command to run from the kubectl arguments.
This specifies that we want to run the /bin/sh command in the first container within our demo-pod pod. Let’s break down the command shown above: Unlike a simple ssh command, kubectl exec requires a few extra arguments to set up an interactive shell session.
0 kommentar(er)
