Shout out to my friend Drew for this one – I had something similar (but nowhere near as cool) previously!

In my work environment, we have several different kubernetes clusters that my team manages. It’s relatively common to have to switch between them several times a day because of various work items that need completed. Aside from that, there are different namespaces within each environment as well, also which need to be specified. This usually comes in the form of one or two commands:

kubectl config use-context dev-env
kubectl config set-context --current --namespace mynamespace

(You can condense these down into one command, but I’m leaving it as two for simplicity.)

In any event, these commands need to be executed every time you switch from test to dev, from dev to prod, or whatever your environments are, along with the namespaces as well. Each cluster requires a yaml file downloaded from the cluster that contains all of the information kubectl needs to know what cluster to connect to, along with your credentials. This .bashrc function is a very elegant and simple way to be able to switch environments and/or namespaces with a single command:

clus() {
    if [ $# != 2 ]; then
    echo "usage: clus <environment> <namespace>" 1>&2
    return 1
fi
environment=$1
namespace=$2
if ! [[ "${environment}" =~ ^(dev(1|2)|test(1|2)|prod(1|2))$ ]]; then
    echo "error: invalid environment \"${environment}\"" 1>&2
    return 1
fi
if ! [[ "${namespace}" =~ ^(name1|name2|name3) ]]; then  
    echo "error: invalid namespace \"${namespace}\"" 1>&2
    return 1
fi
export KUBECONFIG=${HOME}/workspace/kubeconfigs/${environment}.yaml
kubectl config use-context "${environment}"-fqdn
kubectl config set-context --current --namespace "${namespace}"
}
export -f clus

So needless to say, I’ve obscured some of the company-specific details about our namespace and cluster names, but you get the idea. So now any time I’ve got an active terminal, all I have to do is type:

clus dev2 name3

And I’m configured for the dev2 environment and the name3 namespace. Messages are displayed on the screen to indicate success.

Just remember! You need to have downloaded your cluster yaml files into a directory (here mine is /home/username/workspace/kubeconfigs) for this to work!

For work, I often have to connect to a Kubernetes cluster to manage resources, and anyone who’s done that via CLI before knows about the kubectl command. To use it locally, you must first download a yaml configuration file to identify the cluster, namespace, etc., then the commands should work. Notice I said “should” work.

So enter the following error message when attempting to run kubectl get pods:

Unable to connect to the server: dial tcp 127.0.0.1:8080: connectex: No connection could be made because the target machine actively refused it.

Obviously I wasn’t wanting to connect to 127.0.0.1 (aka localhost), I was trying to connect to an enterprise Kubernetes cluster. Then later on after re-downloading the target cluster yaml file, I received this error while running kubectl commands:

Unable to connect to the server: EOF

Searching for this error online led me down a multitude of rabbit holes, each as unhelpful as the last, until I found a reference to Docker Desktop. I know that we (the company I work for) used to use it, but we don’t anymore. (At least I don’t in my current role.)

I raised my eyebrow at that one — I had a relatively new laptop, but one of the corporate-loaded tools on it for someone in my role was Docker Desktop. I checked the running services to see if it was running, and it was not, which is expected. I don’t need to run it.

I forgot to mention that I am using WSL2 (Fedora remix) as my VS Code terminal shell, and so far I’m nothing but happy with it. Sensing something off with my local installation of kubectl I ran which kubectl, which gives me the location of the binary currently in my path. (For the record if it appears more than once in your path, it only returns the first one it comes across, in order of your PATH paths.)

Sure enough, it pointed to /usr/local/bin/kubectl, which was unexpected. I wouldn’t think that an enterprise tool would be installed to /usr/local, and I was right. Performing a long listing of that directory showed me the following:

lrwxrwxrwx  1 root root   55 Jul 21 09:43 kubectl -> /mnt/wsl/docker-desktop/cli-tools/usr/local/bin/kubectl

So sure enough, I had been running the Docker desktop version of kubectl and not the one I had installed with yum officially (which existed in /usr/bin, but was after /usr/local in my PATH.)

So I removed the link, and now which kubectl immediately started showing the correct one, installed via the package manager, and it starting working, connecting to the correct cluster, and everything. While this may have been a simple fix for some, not being fully aware of what may be pre-installed on a work laptop did give me some surprises.