Before the arrival of containers, deployment compatibility problems were faced by software developers. This could happen when software works as intended during the development stage but malfunctions in the productioen environment owing to dependency problems. However, all of the software requirements utilized for development may now be delivered and used in the production environment due to containers. After building your container image and running an instance of it, you might need a connection to the container for debugging purposes or to apply a hotfix, both of which require access to the container environment. You must enter the shell of any running container to interact with it in any way. You will learn in this article how to access a running Docker container or Kubernetes pod through ssh.
What is ssh?
The Secure Shell protocol (commonly known as SSH) provides a way to log in remotely from one computer to another securely. Strong encryption is used to safeguard the security and integrity of communications and offers several additional alternatives for strong authentication. It is a safe substitute for unsafe file transfer protocols and unsecured login protocols (like telnet and rlogin) (such as FTP). Additionally, it works well with Kubernetes.
Useful Shell Commands & Examples for Kubectl Exec
With kubectl exec, you can start a shell session to containers operating in your Kubernetes cluster. It is SSH-like functionality for Kubernetes. The information you need, along with the scenarios in which it makes the most sense, is provided below so that you may use this command as part of your cluster management processes.
A container orchestrator called Kubernetes enables automated deployments across numerous physical computers. Secure Shell on a physical server is different from starting a shell session to a container in a Kubernetes cluster. Even though containers should be stateless and able to operate without supervision, you can occasionally need a shell to troubleshoot problems or retrieve data.
You can connect to containers inside your cluster using kubectl exec. It is a component of the kubectl CLI tool for communicating with Kubernetes installations. Similar to ssh or docker exec, the exec command feeds a shell session into your terminal.
The simplest invocation to access the “demo-pod” pod is as follows:
Kubectl will connect to your cluster, launch /bin/sh in the demo-pod pod’s first container, and pass the input and output streams from your terminal to the container’s process. This post will look at the situations in which kubectl exec is helpful, what each portion of the command accomplishes and how the shell connection can be customized.
When to Use Kubectl Exec?
Different techniques are needed for managing containerized workloads in a Kubernetes cluster than for managing applications on a conventional bare-metal server. You must dig down from the cluster host to the container instances that deploy your system, adding another layer between you and your program.
The ability of Kubernetes to deploy replicas across physical computers is one of its strong points (nodes). Even if you could administer over SSH, you would still need to keep track of which node oversaw each container. Without caring about the Kubernetes node, the container is on. You can specify the container to connect to using kubectl exec.
The most frequent usage of starting a shell inside a container is when troubleshooting an issue. You can be left with no choice but to examine the container from the inside after exhausting all other options, such as looking at the container’s logs.
You can view the complete file system of the container and confirm that the environment is as you anticipated by executing the shell commands. Additionally, it can assists you in finding instances of incorrectly defined environment variables and determining whether a crucial file is locked or missing.
Kubectl Exec Substitutes
The most effective method for connecting to a Kubernetes container’s shell is kubectl exec. It is made for this use and solves all the problems of choosing the right physical node to connect to.
Consider running an SSH daemon inside your container if you genuinely need a different option because you need to connect from a system without kubectl. Be aware that doing so raises your vulnerability to security threats and contradicts the premise that each container should serve a single purpose.
How to Access my Worker Node Through SSH?
Use a Kubernetes Daemon Set or tasks for one-time actions to run on each worker node.
Review the following options to gain host access to worker nodes for purposes of debugging and troubleshooting.
Using Kubectl Debug for Debugging
Use the kubectl debug node command to deploy a pod with a privileged security Context to a worker node that you want to debug. To provide access to the worker node as soon as the debug pod is formed, an interactive shell is deployed with it.
Debugging by Using Kubectl Exec
You can build an Alpine pod with a privileged security context and employ the kubectl exec command to execute debug commands from the interactive shell of the pod if you are unable to execute the kubectl debug node command.
Building a Pod with Root SSH Access for Debugging
If you are unable to use the kubectl debug node or kubectl exec commands, such as if the VPN connection between the cluster master and worker nodes is down. You can create a pod that enables root SSH access and copies a public SSH key to the worker node for SSH access.
Cleaning Up After Debugging
After you finish debugging, clean up resources to disable SSH access.
What are the Advantages of SSH Access?
The advantages are listed below:
- Fewer keys to keeping track of
- Reduced attack surface by removing all common, interactive Linux utilities in addition to ssh
- Reduced patching requirements as a result of this reduction
- More effective setup control (changes are only possible through automated deployments)
Conclusion
Using the kubectl exec command, you may launch a shell session inside any currently active container in your Kubernetes cluster. When logs alone are insufficient, you can use this command to explore the container’s file system, evaluate the environment, and run sophisticated debugging tools. As a last option, you should manage your containers manually using shell commands.
