Photo by Joseph Barrientos on Unsplash.

This article gives an overview of the managed Kubernetes services of the major cloud providers and explains how to use them.

Manual vs. Managed Kubernetes

Kubernetes is a software that can be installed on an existing computing infrastructure, typically, on a set of interconnected physical machines.

Before there were managed Kubernetes services, you would typically provision machines (either on premises or in the cloud), install Kubernetes on these machines, tie them together to a cluster, and then start using the cluster with kubectl .

In particular, you would need to choose one of the machines as the master node, install Kubernetes on this master node, then install Kubernetes on all the other machines, which will be the worker nodes, and then join the worker nodes to the master node to form a cluster.

With managed Kubernetes services this gets easier. These services provide a simple command for creating an entire Kubernetes cluster. This includes the provisioning of machines, installation of Kubernetes, and forming of a cluster. All this is done automatically behind the scenes. After executing this single command, the Kubernetes cluster is ready to use. You just need to provide the address of the cluster to kubectl on your local machine, and then you can start using the cluster with kubectl .

So, the typical workflow for using a managed Kubernetes service is as follows:

Spin up a Kubernetes cluster with a command provided by the managed Kubernetes service. Point kubectl on your local machine to this cluster. Start using the cluster with kubectl .

Existing Managed Kubernetes Services

All the major cloud providers, Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, and IBM Cloud, currently provide managed Kubernetes services. In particular, these are the following:

Existing since the beginnings of Kubernetes in 2014 (as you may know, Kubernetes was born out of the Borg project by Google).

Introduced in autumn 2017. Currently (spring 2018) in preview, but generally available.

Currently (spring 2018) in preview, but not yet generally available.

EDIT: EKS has been publicly released in June 2018 (see here), but it is currently (August 2018) only available in the regions us-east-1 and us-west-2.

Introduced in spring 2017.

Managed Kubernetes Services Commands

Below are some useful commands for using the managed Kubernetes services of AKS and GKE, that is, the managed Kubernetes services of Microsoft Azure and Google Cloud Platform, respectively.

Note: I might add the equivalent commands for the Kubernetes services of AWS and IBM Cloud in the future.

The best way to dig deeper into these commands is to look at the built-in help messages, which you can display by adding the -h option to any command.

Create a cluster

az aks create -n my-cluster

[--node-count n]

[--node-vm-size type] gcloud container clusters create my-cluster

[--num-nodes n]

[--machine-type type]

The default number of nodes of the cluster for both AKS and GKE is 3. The available compute instance types are listed here for Azure and here for GCP.

List all clusters

az aks list gcloud container clusters list

List compute instances

az vm list gcloud compute instances list

This includes the computing instances that have been created by the create cluster command.

Delete a cluster

az aks delete -n my-cluster gcloud container clusters delete my-cluster

This also deletes all the computing instances associated with the cluster.

Point kubectl to a cluster

az aks get-credentials -n my-cluster gcloud container clusters get-credentials my-cluster

This edits $HOME/.kube/config .

Enjoy Your Cluster

After executing the last command above (pointing kubectl to the cluster), you have a functioning cluster and you can use it with kubectl .

Using kubectl from this point on works always the same way, regardless of whether you created the cluster with AKS, GKE, or even manually.

The managed Kubernetes service just helped you creating the cluster, but once this is done, you don’t have to deal with it anymore.

You are now in the pure Kubernetes world.

Test it with kubectl cluster-info or kubectl get nodes .

Appendix: Customising the Azure CLI

Photo by Tim Foster on Unsplash.

Below are some commands for customising the Azure CLI.

In particular, setting a default resource group and location can be very handy, because it frees you from having to specify the resource group and location for each command with the -g and -l options, respectively.

A resource group is a group of resources that can be managed (for example, deleted) as a whole. For each resource (for example, a computing instance) that you create, you have to define to which resource group it belongs.

A resource provider is just an Azure service that provides resources (for example Microsoft.Compute providing computing instances).

Check the official documentation about resource groups and related concepts.

Set default location

az configure --defaults location=CanadaEast

Create a resource group

az group create -n my-resource-group

You have to create a resource group when you just start using Azure.

Set default resource group

az configure --defaults group=my-resource-group

Register a resource provider

az provider register -n Microsoft.Compute

This may be necessary for several resource providers when you use AKS for the first time.

Set default output format to “table” (default is “json”)

az configure -o table

This sets the default output format of all commands to a human-readable format.