Starting with Kubernetes AKS on Azure

It’s like a cloud withing a cloud!

Vladimir Akopyan
Quickbird

--

Tools Needed on your PC:

  • Azure CLI to be installed
  • KubeCTL to be installed
  • Docker to be installed

Before this Guide

You have created a Managed Azure Container service cluster. There is no point of replicating that documentation here, as Microsoft will change things around. Currently instructions can be found here. Return once you have a cluster deployed:

A managed Kubernetes cluster in Azure

Step 1 — setup KubeCTL

KubeCTL is a command-line utility for connecting to and controlling Kubernetes clusters. It’s written in Golang and on Windows it just looks as a single kubectl.exe, the smug linux bastards didn’t bother making an installer.

This will be doing most of the grunt-work, but first we need to set it up. Put it in some folder, for example just make on on C drive. Make sure there are no issues with Admin write permissions to that folder, as you see in screenshot above it will need to create and read files in the folder.

Then add that folder to your path environmental variable

The key end result is for KubeCTL to be avaliable form command line:

Step 2 — configure access from Azure CLI

Usually we don’t interact with Azure Command Line Interface — we use the azure portal. It’s the local system used by pros to do operations in azure quickly, without a ton of button clicking. As it’s a CLI tool, it can also be used for automation.

The only purpose of Azure CLI here is to provide the KubeCTL with all the config information for controlling the Kubernetes cluster. After installing Azure CLI run the Azure command prompt and use following commands

Windows Azure SDK ShellC:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.9>az interactive  

The above command will give you code completion, it’s optional. Now you can login.

az>> az login
To sign in, use a web browser to open the page https://aka.ms/devicelogin and enter the code ********* to authenticate.
[
{
“cloudName”: “AzureCloud”,
“id”: “****-****–****-****–*********”,
“isDefault”: false,
“name”: “Visual Studio Enterprise: BizSpark”,
“state”: “Enabled”,
“tenantId”: “*******–****-***–***–**********”,
“user”: {
“name”: “vladimir.akopyan@*************”,
“type”: “user”
}
}
]

If there is more than one account

This is a potential trap

  • az account show — this will display the account currently being used by Azure CLI. It’s not the account with which you login, azure subscription. Each resource, from database to the Kubernetes cluster, lives on a subscription. If you have several subscribtions and the wrong one is selected in the Aure CLI you won’t be able to access the resources.
  • az account List — will display all of your accounts
az account set --subscription "Microsoft Azure Sponsorship"

Selects a specific subscription by name. What if several subscriptions have the same name? I don’t know, but I believe you can rename them.

Moving on

  • az group list — Lists all resource groups.
az>>    az aks get-credentials --resource-group InternalStuff --name InternalCluster
Merged “InternalCluster” as current context in C:\Kubernetes\.kube\config

This is the most important part — it creates config file that will allow KubeCTL to access the managed Azure Cluster. The config file is JSON and looks something like this:

{apiVersion: v1, clusters: [{cluster: {certificate-authority-data: *********VERYLONG*******************
server: ‘https://internalcluster-******.hcp.westeurope.azmk8s.io:443'},
name: InternalCluster}], contexts: [{context: {cluster: InternalCluster, user: clusterUser_InternalStuff_InternalCluster},
name: InternalCluster}], current-context: InternalCluster, kind: Config, preferences: {},
users: [{name: clusterUser_InternalStuff_InternalCluster, user: {client-certificate-data: *******VERY**LONG***************,
token: ***********************************}}]}

Step 3 — Use KubeCTL and checkout WebUI

Now open command line and check that KubeCTL can connect to the cloud cluster.

  • kubectl get nodes
  • kubectl cluster-info
C:\Users\vladi>kubectl get nodes
NAME STATUS ROLES AGE VERSION
aks-agentpool-11508787-0 Ready agent 2d v1.8.1
aks-agentpool-11508787-1 Ready agent 2d v1.8.1
aks-agentpool-11508787-2 Ready agent 2d v1.8.1
C:\Users\vladi>kubectl cluster-info
Kubernetes master is running at https://internalcluster-eeb4bf79.hcp.westeurope.azmk8s.io:443
Heapster is running at https://internalcluster-eeb4bf79.hcp.westeurope.azmk8s.io:443/api/v1/namespaces/kube-system/services/heapster/proxy
KubeDNS is running at https://internalcluster-eeb4bf79.hcp.westeurope.azmk8s.io:443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
kubernetes-dashboard is running at https://internalcluster-eeb4bf79.hcp.westeurope.azmk8s.io:443/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

Now you know you have a working connection to the cluster. If you see localhost, that means something different is going on.

The following command will deploy the dashboard Web-UI as a service withing kubernetes. In my Azure AKS the dashboard was already deployed

kubectl create -f https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml

You can check services currently running

kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP
azure-vote-back ClusterIP 10.0.66.219 <none>
azure-vote-front LoadBalancer 10.0.34.81 52.232.84.58
kubernetes ClusterIP 10.0.0.1 <none>

Kubernetes WebUI a kubernetes service like any other. It requires secure login, which in turn requires SSL/TLS. That’s a bit of work to setup, but would be accessible form anywhere without prior setup.
Alternatively you can use KubeCTL to run local proxy, but you have to go through all of the above-mentioned setup.

kubectl proxy
Starting to serve on 127.0.0.1:8001

Dashboard becomes accessible on http://localhost:8001/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/

--

--

Making Internets great again. Slicing crystal balls with Occam's razor.