1. Documentation
×

Executing remote commands in an OKD container

You can use the oc exec command to execute remote commands in OKD containers from your local machine.

Executing remote commands in containers

You can use the OpenShift CLI (oc) to execute remote commands in OKD containers. By running commands in a container, you can perform troubleshooting, inspect logs, run scripts, and other tasks.

Procedure

  • Use a command similar to the following to run a command in a container:

    $ oc exec <pod> [-c <container>] -- <command> [<arg_1> ... <arg_n>]

    For example:

    $ oc exec mypod date
    Example output
    Thu Apr  9 02:21:53 UTC 2015

    For security purposes, the oc exec command does not work when accessing privileged containers except when the command is executed by a cluster-admin user.

Protocol for initiating a remote command from a client

A client resource in your cluster can initiate the execution of a remote command in a container by issuing a request to the Kubernetes API server.

The following example is the format for a typical request to a Kubernetes API server:

/proxy/nodes/<node_name>/exec/<namespace>/<pod>/<container>?command=<command>

where:

<node_name>

Specifies the FQDN of the node.

<namespace>

Specifies the project of the target pod.

<pod>

Specifies the name of the target pod.

<container>

Specifies the name of the target container.

<command>

Specifies the desired command to be executed.

Example request
/proxy/nodes/node123.openshift.com/exec/myns/mypod/mycontainer?command=date

Additionally, the client can add parameters to the request to indicate any of the following conditions:

  • The client should send input to the remote container’s command (stdin).

  • The client’s terminal is a TTY.

  • The remote container’s command should send output from stdout to the client.

  • The remote container’s command should send output from stderr to the client.

After sending an exec request to the API server, the client upgrades the connection to one that supports multiplexed streams; the current implementation uses HTTP/2.

The client creates one stream each for stdin, stdout, and stderr. To distinguish among the streams, the client sets the streamType header on the stream to one of stdin, stdout, or stderr.

The client closes all streams, the upgraded connection, and the underlying connection when it is finished with the remote command execution request.