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.
Prerequisites
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 https://aka.ms/InstallAzureCLIDeb | sudo bashThe 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 upgradeInstalling Kubectl
We can install Kubectl using the Azure CLI:
az aks install-cliLogging 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 loginAfter 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-codeAfter 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": "test@testing.com",
"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 AKSClusterNameIf we want to get admin credentials (if you have rights):
az aks get-credentials --resource-group AKSResourceGroupName --name AKSClusterName --adminTo check what the current connection context is for the kubernetes command line tool (kubectl):
kubectl config current-contextWe 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-contextsThis 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 aks1Here 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=developmentResulting 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=developmentAnd 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=developmentIn 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 wideThis shows output like this:
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES chabot-backend-5549f67777-tlfgm 1/1 Running 0 327d 10.240.0.15 aks-exppool-39668990-vmss000000 <none> <none> chabot-frontend-5bb9f8744b-4xfmr 1/1 Running 0 327d 10.240.0.12 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-tlfgmIt 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-backendResulting in something like the following:
Name: chatbot-backend
Namespace: development
Labels: service=backend
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"service":"backend"},"name":"chatbot-backend","namespace":"development"
Selector: app=chatbot-backend
Type: LoadBalancer
IP: 10.0.97.118
LoadBalancer Ingress: 20.55.212.32
Port: <unset> 80/TCP
TargetPort: 5005/TCP
NodePort: <unset> 32610/TCP
Endpoints: 10.240.0.7:5005
Session Affinity: None
External Traffic Policy: Cluster
Events:
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.
Conclusion
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:
Follow @tmdev82