Automating SSH access to Kubernetes nodes using Fabric and CoreOS integration

Although Kubernetes represents a world in which SSH is not so necessary in everyday use for deploying and managing applications, there are still cases where SSH is useful for collecting statistics, debugging, and fixing configurations. Suppose that after a few years SSH and the launch of one-time debugging sessions may no longer be needed, the tools described below can be useful now for a quick SSH connection to machines from the Kubernetes cluster.


Kubernetes stores the cluster node database, which can be viewed with the command kubectl get nodes . It is a powerful foundation for automation and integration with existing tools. One such tool is the SSH utility Fabric , also known as fabfile.py .

Note trans. : Fabric is a Python-written library and command utility that simplifies SSH access for application deployment and system administration. It provides both the simplest execution of shell commands and more complex operations: upload / download files, request user input, interrupt process execution. A typical use of fabfile is to create a module in Python that implements one or more functions, after which they are invoked via the console utility fab . More information about the capabilities of Fabric can be found in the official documentation .

Beginning of work

Install Fabric SSH utility and check its availability:

 $ fab --version Fabric 1.13.1 

Note trans. : In the case of Ubuntu, simply install the fabric package, which is available in the main repositories.

Clone this Git repository and go to the directory with it:
')

 git clone https://github.com/coreos/fabric-kubernetes-nodes cd fabric-kubernetes-nodes 

Fabric will use fabfile.py from the root of this directory. Therefore, Kubernetes nodes and labels are now available in Fabric. Here is an example session using this integration:

 $ kubectl get nodes NAME STATUS AGE ip-10-0-0-50.us-west-2.compute.internal Ready 22d ip-10-0-60-201.us-west-2.compute.internal Ready 22d ip-10-0-95-156.us-west-2.compute.internal Ready 22d $ kubectl label node ip-10-0-0-50.us-west-2.compute.internal fab-admin=true node "ip-10-0-0-50.us-west-2.compute.internal" labeled $ fab -u core -R fab-admin=true -- date [52.26.54.211] Executing task '<remainder>' [52.26.54.211] run: date [52.26.54.211] out: Wed Feb 15 22:42:47 UTC 2017 [52.26.54.211] out: Done. Disconnecting from 52.26.54.211... done. 

Bastion node or gateway

Many Kubernetes configurations, such as CoreOS Tectonic, do not include direct SSH access to the machines in the cluster — instead, users must first connect to the gateway or bastion host. If the Kubernetes cluster is configured this way, add the --gateway flag to the --gateway and change the address type to InternalIP .

 $ export FAB_KUBE_NODE_ADDRESS_TYPE=InternalIP $ fab --gateway=WXYZ -u core -R failure-domain.beta.kubernetes.io/zone=us-west-2a -- date [10.0.3.24] Executing task '<remainder>' [10.0.3.24] run: date [10.0.3.24] out: Mon May 1 02:50:13 UTC 2017 [10.0.3.24] out:</remainder> [10.0.60.15] Executing task '<remainder>' [10.0.60.15] run: date [10.0.60.15] out: Mon May 1 02:50:16 UTC 2017 [10.0.60.15] out:</remainder> Done. Disconnect 

By default, fabfile will use external IP ( ExternalIP ) nodes. However, it can be configured to any IP addresses that the node has. The example above uses the general InternalIP field, and to change it to an arbitrary SpecialIP , export the variable to the environment accordingly ( FAB_KUBE_NODE_ADDRESS_TYPE=SpecialIP ).

More information on integrating Fabric with Kubernetes can be found in the GitHub repository .

Afterword of the translator : in the repository, this tutorial is actually just duplicated, so you will not find any additional information (at least as of now). But you can learn a very concise fabfile.py , which is easy to expand to fit your needs (especially since it is distributed under the terms of the free Apache License 2.0).