How to connect to a Azure Kubernetes Service

This article is about how to connect to a Azure Kubernetes Service (AKS) cluster. We will look at the steps from installing the required tools to logging in to Azure using the terminal to exploring the AKS cluster to get information using a few simple command line commands.

This article is aimed at Linux based systems.


Please have an Azure account ready to follow along with. We also need to be able to access this account from the system we run the commands from.

We are also assuming that there is an existing AKS cluster we want to connect to.

Installing the tools

To be able to work with the an AKS cluster we need two command line tools, the Azure CLI and Kubectl. The AzureCLI is the command line tool for Azure in general and Kubectl is the command line tool for managing Kubernetes clusters in general. Kubectl also works with an AKS cluster, as it’s just a Microsoft managed Kubernetes cluster.

Installing the Azure CLI

First let’s install the Azure CLI. The link to the download can be found here. For Ubuntu or Debian there are two options using an install script or using apt-get.

The command to use the install script is listed below:

curl -sL | sudo bash

The step-by-step instructions using apt-get can be found here.

If the Azure CLI is already present on the system we can upgrade it using this command:

az upgrade

Installing Kubectl

We can install Kubectl using the Azure CLI:

az aks install-cli

Logging in to the Azure account

Now it is time to log in to our Azure account. We can log in with a simple command:

az login

After executing this command a page will open in your default browser and show the log in page for the Azure Portal. There it is important to select the account that has access to the AKS cluster. In some cases you first need to fill in a code that’s printed on the command line.

There are also scenarios where we are not allowed to log in with our own device but have to log in to a virtual machine first to access the AKS cluster. This is a so called jump server or jump box. So, if the browser doesn’t open or isn’t available we can use this command:

az login --use-device-code

After we select an account and log in, we can close the browser window or tab. The command line will show a message like:

You have logged in. Now let us find all the subscriptions to which you have access...

And then all the command line will list all available subscriptions a JSON format. We should make sure the correct subscription is selected for our terminal session. The following command lists the current default subscription:

az account list --query "[?isDefault]"

We can also list the other non-default subscriptions:

az account list --query "[?isDefault == \`false\`]"

We can switch to a different subscription using either the name or the id:

    "cloudName": "AzureCloud",
    "homeTenantId": "xxxxx",
    "id": "yyyy",
    "isDefault": false,
    "managedByTenants": [
        "tenantId": "bbbbb"
    "name": "Azure subscription 1",
    "state": "Enabled",
    "tenantId": "xxxxx",
    "user": {
      "name": "",
      "type": "user"

In this case the id is yyyy and the name is Azure subscription 1. The following command sets the active subscription using the name:

az account set --subscription "Azure subscription 1"

or the id:

az account set --subscription "yyyy"

Now that we have logged in and selected the correct account and subscription we can connect with the AKS cluster.

Connect to a Azure Kubernetes Service cluster

In this section we will connect to a Azure Kubernetes Service cluster.

We simply get the credentials from the cluster:

az aks get-credentials --resource-group AKSResourceGroupName --name AKSClusterName

If we want to get admin credentials (if you have rights):

az aks get-credentials --resource-group AKSResourceGroupName --name AKSClusterName --admin

To check what the current connection context is for the kubernetes command line tool (kubectl):

kubectl config current-context

We are likely to be working on multiple Kubernetes clusters at some point. In that case we have to switch between contexts. The following command can be used to see all the contexts registered with our Kubectl:

kubectl config get-contexts

This will result in a list like:

CURRENT   NAME                           CLUSTER                AUTHINFO                                        NAMESPACE
          aks1                           aks1                   clusterUser_rg-xxxx_xxxx                             
*         aks2                           aks2                   clusterUser_rg-yyyy_yyyy                        development   

Where NAME indicates the name of the context. The CLUSTER the cluster name, AUTHINFO the type of user and resource group and cluster name. Finally, NAMESPACE indicates the default namespace for the context.

Switching context can be done with the following command:

kubectl config use-context aks1

Here you should replace aks1 with the name of your desired context.

Exploring the Azure Kubernetes Service cluster

There are many different types of objects that exist on a Kubernetes cluster and different ways to view information about them from the terminal.

Kubernetes objects and concepts

Here is a list of important objects and what they represent:

  • nodes: Kubernetes runs your workload by placing containers into Pods to run on Nodes. A node may be a virtual or physical machine, depending on the cluster.
  • pods: A Pod (as in a pod of whales or pea pod) is a group of one or more containers, with shared storage and network resources, and a specification for how to run the containers.
  • services: An abstract way to expose an application running on a set of Pods as a network service.
  • namespaces: In Kubernetes, namespaces provides a mechanism for isolating groups of resources within a single cluster. Names of resources need to be unique within a namespace, but not across namespaces.
  • deployments: A Deployment provides declarative updates for Pods and ReplicaSets. You describe a desired state in a Deployment, and the Deployment Controller changes the actual state to the desired state at a controlled rate.
  • ingresses: An API object that manages external access to the services in a cluster, typically HTTP. Ingress may provide load balancing, SSL termination and name-based virtual hosting.

There are more but these are essential.

How to get information about Kubernetes objects

There are several ways to get information about Kubernetes objects. A commonly used one is to list all the objects of that type using kubectl get. For example: kubectl get pods gets all the pods in the namespace.

What is important here is the namespace. If there are no pods in our current namespace we will see nothing. To see pods from a specific namespace use:

kubectl get pods --namespace=development

Resulting in:

NAME                                          READY   STATUS             RESTARTS   AGE
chabot-backend-5549f67777-tlfgm               1/1     Running            0          327d
chabot-frontend-5bb9f8744b-4xfmr              1/1     Running            0          327d

If we want to see services:

kubectl get services --namespace=development

And so on. However, it becomes very annoying to keep typing the --namespace= part of the command. So, what we can do is set the default namespace, so that all of our commands use that particular namespace:

kubectl config set-context --current --namespace=development

In the above case, all of our following commands will take place within the development namespace context.

We can view more information about objects by changing the output mode:

kubectl get pods -o wide

This shows output like this:

NAME                             READY   STATUS    RESTARTS   AGE    IP            NODE                              NOMINATED NODE   READINESS GATES
chabot-backend-5549f67777-tlfgm  1/1     Running   0          327d   aks-exppool-39668990-vmss000000   <none>           <none>
chabot-frontend-5bb9f8744b-4xfmr 1/1     Running   0          327d   aks-exppool-39668990-vmss000000   <none>           <none>

Often we will want to look at the logging from our containers or pods we can do that using the logs command:

kubectl logs chabot-backend-5549f67777-tlfgm

It is important to use the exact name of the pod we want to see the logs from.

Finally, another way to view even more information about an object is to use the describe command:

kubectl describe service chatbot-backend

Resulting in something like the following:

Name:                     chatbot-backend
Namespace:                development
Labels:                   service=backend
Selector:                 app=chatbot-backend
Type:                     LoadBalancer
LoadBalancer Ingress:
Port:                     <unset>  80/TCP
TargetPort:               5005/TCP
NodePort:                 <unset>  32610/TCP
Session Affinity:         None
External Traffic Policy:  Cluster
  Type     Reason                Age                   From                  Message
  ----     ------                ----                  ----                  -------
  Normal   EnsuringLoadBalancer  2m (x785 over 2d16h)  service-controller    Ensuring load balancer

This is often used to see pod level errors. For example, for when the entire pod fails to come online for some reason. Or node level issues with resource allocation and whatnot.


We have learned how to connect to an Azure Kubernetes Service cluster and how to get information from Kubernetes objects. All this with just a few simple commands.

If you’re interested in learning more about Docker and containers. The objects where our applications run, that are managed by Kubernetes. Please check out my primer on Docker: What is Docker and why is it used: quick primer.

Please follow me on Twitter to keep up to date with upcoming software development related articles:

Leave a Reply

Your email address will not be published. Required fields are marked *