AKS: Quickly switching context between multiple clusters in Azure Kubernetes Services with cmder aliases

If you - like me - sometimes manage multiple Azure Kubernetes Service clusters, then it will comes in handy to know how to conveniently context-switch between them in the same command line.

Last week I was discussing some questions over a coffee around containers in Azure in general, and one question that kept coming up was why you had to run az login, then az aks list and then az aks get-credentials every single time you want to switch between clusters that you've already authenticated with. The short answer is; You don't need to do all of that every time. Woohoo! Since it was a recurring question, I wanted to draft some tips over the weekend. Enjoy!

In this post, we'll take a look at:

• Authenticate with Azure CLI
• Get-credentials for an Azure Kubernetes Services cluster
• Get cluster contexts that your machine has access to
• Change context with kubectl
• Create an alias in my favorite tool, cmder, for easier context-switching

Efficiently manage multiple clusters in Azure Kubernetes Service

Let's set the scene. You have multiple AKS clusters running in the same, or separate Azure subscriptions. This applies to either of those scenarios - you're not bound by the boundaries of any subscription here.

For many, I'm sure you'll recognize the first steps to authenticate and get credentials to your clusters. If you're already handy with that, jump down to #3 below.

1. Authenticate to Azure CLI

First, let's authenticate to the Azure CLI:

az login

Follow the on-screen instructions in the popup-browser window and ensure you authenticate correctly to the subscription you want to target.

2. List and Connect to an AKS cluster using the Azure CLI

Great, we're authenticated with the CLI, now we need to list the clusters.

az aks list -o table

This will give you a nice list of all your clusters in a table-like format:

Next step right after this, is to get the credentials from one of your clusters, which you can also do using the Azure CLI:

az aks get-credentials -n <yourClusterName> -g <yourResourceGroupName>

Great, this ensures you've got access and that the kubectl commands will now target this cluster.

3. Targeting your cluster with config get-contexts and use-context

This is the fun part, as I'm sure most readers are already familiar with the above commands to authenticate to the clusters.

Using kubectl config get-contexts we'll be able to see all the clusters we've authenticated against, regardless what subscription they're in:

kubectl config get-contexts

So here comes the simple context switch part. You can see that the first one in my list is marked with the asterisk *. This is the cluster that is currently selected and that my kubectl commands targets.

Switch cluster:

kubectl config use-context <yourClusterName>

Voila, that's it. Now you're targeting the other cluster.

4. Making it easier with cmder aliases

One of my absolute favorites in my daily tool basket is cmder. I use it regularly for a lot of things. One of the major benefits is the easy use of an alias, that you can set up with a jiffy. Here's what I'm doing to make my context-switching even easier.

alias YOUR_ALIAS=kubectl config use-context <clusterName>

This creates the alias with the name you specify for "YOUR_ALIAS", which then executes the command I specified above. I then did the same for some other clusters I wanted quick access to. And presto - you can use these commands to switch context super quickly, even if your AKS cluster names are complex.

As you can see in the picture, when I type kubeswitch, and then hit TAB, it auto-completes for me so I can see what options I have. So, if you've got many clusters to manage, hooking up aliases can make things a breeze as it will get the job done a lot quicker, and without typos (unless you add a typo in the actual alias, of course).

Some more info on kube config

If you've read this far, you now know how easy it is to set up different cluster contexts using aliases with cmder; and even if you don't use cmder, you can switch between the different clusters easily now using kubectl config use-context.

How does that work? WHY does it work?

Glad you asked, check your local .kube configuration out. On my windows machine, it's here:

C:\Users\<yourUserName>\.kube\config

If you open this file (a YAML file) with your absolute favorite editor (which should definitely be VS Code, right?), then it will list the contexts and clusters, along with auth details. These details are similar to what you would get if you run the following command:

kubectl config view

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://REDACTED.azmk8s.io:443
  name: REDACTED-cluster
- cluster:
    certificate-authority-data: REDACTED
    server: https://REDACTED.azmk8s.io:443
  name: REDACTED-a1v2-cluster
- cluster:
    certificate-authority-data: REDACTED
    server: https://REDACTED.azmk8s.io:443
  name: REDACTED-cluster
- cluster:
    certificate-authority-data: REDACTED
    server: https://REDACTED.azmk8s.io:443
  name: rg-weu-aks-REDACTED-a1v2-cluster
contexts:
- context:
    cluster: REDACTED-cluster
    user: clusterUser_rg-weu-REDACTED-cluster
  name: REDACTED-cluster
- context:
    cluster: REDACTED-a1v2-cluster
    user: clusterUser_REDACTED-a1v2-cluster
  name: REDACTED-a1v2-cluster
- context:
    cluster: REDACTED-cluster
    user: clusterUser_REDACTED-cluster
  name: REDACTED-cluster
- context:
    cluster: rg-weu-aks-REDACTED-a1v2-cluster
    user: clusterUser_rg-weu-aks-REDACTED-a1v2_rg-weu-aks-REDACTED-a1v2-cluster
  name: rg-weu-aks-REDACTED-a1v2-cluster
current-context: REDACTED-cluster
kind: Config
preferences: {}
users:
- name: clusterUser_REDACTED-a1v2-cluster
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
    token: REDACTED
- name: clusterUser_REDACTED-cluster
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
    token: REDACTED
- name: clusterUser_rg-weu-aks-REDACTED-a1v2_rg-weu-aks-REDACTED-a1v2-cluster
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
    token: REDACTED
- name: clusterUser_rg-weu-REDACTED-cluster
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
    token: REDACTED

Where it says "REDACTED", your data of a more sensitive nature would go - which you can see from the actual config file, but it's redacted when you list the information in the kubectl command.

To be fair, you never need to really know anything about the .kube config unless you want to dig deeper. Azure and the kubectl cli handles everything for you, so you can focus on productivity and what matters.

Summary

Great to have you. I would love to get a comment about your thoughts - but generally I'm just happy to share what I'm doing.

Reading that makes sense if you want to dig deeper:

• Kubernetes.io: Organizing Cluster Access Using kubeconfig Files
• Cmder | Console Emulator (scroll to the bottom to see aliases)