How to K8s: Exec into a Running Kubernetes Pod

One of the true power features of MacStadium’s Orka is the Sandbox functionality, which allows you to deploy your own containerized applications. As more teams adopt Orka, we’re often asked about team-specific solutions for complex workflows. For instance, having a configuration management (CM) server and repo standing up as a Kubernetes pod in a Orka-driven, CI workflow. Of course, that is only one of the limitless use cases.

Once you have a server running in Kubernetes, you may need to log in to Kubernetes for several reasons. Maybe you’re getting fishy errors that you would like to check out directly. Whatever the case, it's helpful to know how to look under the hood.

You'll need a running service of type NodePort or LoadBalancer to interact with the service from outside the cluster, as these are the only service types that expose an external IP. To do so, we’ll use the Kubernetes CLI tool kubectl, which exposes Kubernetes functionality via the command line. You can find download and set up instructions for kubectl in the Kubernetes docs. We also mention in the Orka set-up instructions and walkthroughs on the subject.

To gain access to a Kubernetes pod, we'll have to get a pod’s name to target. To do so, we have to call kubectl get pods. As you can see in the Terminal screenshot, I’ve included the --kubeconfig flag explicitly for clarity, but chances are you’ve already set that as an environment variable. If so, you can disregard it.

kubectl get pods

Let’s say that we need to gain access to the code running in chef-server1. We will need to get the name of one of the pods (if multiple pods are running the same code for high availability). So, for our purposes, we will hit the namespace chef-server1-5d5c5c4dd8-4fvdr, which has been assigned dynamically by Kubernetes.

But first, we’ll need a mechanism to make that connection. Thankfully kubectl makes that pretty simple with exec. We'll need to run the following:

kubectl exec -it <pod_name> -- /bin/bash</pod_name>

Let’s take a second and break that command down. We have called kubectl and passed it our --kubeconfig; now it gets interesting. We call exec -it on our running pod chef-server1-5d5c5c4dd8-4fvdr. The -it is saying that we would like to change the default -i (stdin) and -t (tty) values of False to True. This is what will allow us to interact with the pod we named in our call. Finally, the -- is necessary to tell Kubernetes that any commands following are to be executed at the pod level. Of course, we have passed the command /bin/bash so that we can use it in the pod.

Also note that we have root access, which should allow us to make any configuration changes needed. For reference, chef-server1 is a Kubernetes Pod, which is running a container with Ubuntu image with Chef installed. Calling ls shows us the file structure of the current directory inside the container.

Takeaways:

Kubernetes is a complex system, and sometimes executing commands directly on a running pod is the simplest and most straightforward way to identify a bug. Thankfully, kubectl, the Kubernetes command-line tool, includes a built-in exec method just for this purpose.