The Kubernetes Book by Nigel Poulton & Pushkar Joglekar, chapter name Installing Kubernetes

Installing Kubernetes

Installing Kubernetes

In this chapter, we’ll look at a few quick ways to install Kubernetes.

There are three typical ways of getting a Kubernetes:

1. Test playground

2. Hosted Kubernetes

3. DIY installation

Kubernetes playgrounds

Test playgrounds are the simplest ways to get Kubernetes, but they’re not intended for production. Common examples include Magic Sandbox (, Play with Kubernetes (, and Docker Desktop.

With Magic Sandbox, you register for an account and login. That’s it, you’ve instantly got a fully working multi-node private cluster that’s ready to go. You also get curated lessons and hands-on labs.

Play with Kubernetes requires you to login with a GitHub or Docker Hub account and follow a few simple steps to build a cluster that lasts for 4 hours.

Docker Desktop is a free desktop application from Docker, Inc. You download and run the installer, and after a few clicks you’ve got a single-node development cluster on your laptop.

Hosted Kubernetes

Most of the major cloud platforms now offer their own hosted Kubernetes services. In this model, control plane (masters) components are managed by your cloud platform. For example, your cloud provider makes sure the control plane is highly available, performant, and handles all control plane upgrades. On the flipside, you have less control over versions and have limited options to customise.

Irrespective of pros and cons, hosted Kubernetes services are as close to zero-effort production-grade Kubernetes as you will get. In fact, the Google Kubernetes Engine (GKE) lets you deploy a production-grade Kubernetes cluster and the Istio service mesh with just a few simple clicks. Other clouds offer similar services:

• AWS: Elastic Kubernetes Service (EKS)

• Azure: Azure Kubernetes Service (AKS)

• Linode: Linode Kubernetes Engine (LKE)

• DigitalOcean: DigitalOcean Kubernetes

• IBM Cloud: IBM Cloud Kubernetes Service

• Google Cloud Platform: Google Kubernetes Engine (GKE)

With these offerings in mind, ask yourself the following question before building your own Kubernetes cluster: Is building and managing your own Kubernetes cluster the best use of your time and other resources? If the answer isn’t “Hell yes” , I strongly suggest you consider a hosted service.


DIY Kubernetes clusters

By far the hardest way to get a Kubernetes cluster is to build one yourself.

Yes, DIY installations are a lot easier than they used to be, but they’re still hard. However, they provide the most flexibility and give you ultimate control over your configuration – which can be a good thing and a bad thing.

Installing Kubernetes

There are a ridiculous number of different ways to get a Kubernetes cluster and we’re not trying to show them all (there are probably hundreds). The methods shown here are simple and I’ve chosen them because they’re quick and easy ways to get a Kubernetes cluster that you can follow to most of the examples with.

All of the examples will work on Magic Sandbox and GKE, and most of them will work on other installations.

Ingress examples and volumes may not work on platforms like Docker Desktop and Play with Kubernetes.

We’ll look at the following:

• Play with Kubernetes (PWK)

• Docker Desktop: local development cluster on your laptop

• Google Kubernetes Engine (GKE): production-grade hosted cluster Play with Kubernetes

Play with Kubernetes (PWK) is a quick and simple way to get your hands on a development Kubernetes cluster.

All you need is a computer, an internet connection, and an account on Docker Hub or GitHub.

However, it has a few of limitations to be aware of.

• It’s time-limited – you get a cluster that lasts for 4 hours

• It lacks some integrations with external services such as cloud-based load-balancers and volumes

• It often suffers from capacity issues (it’s offered as a free service) Let’s see what it looks like (the commands may be slightly different).

1. Point your browser at https://

2. Login with your GitHub or Docker Hub account and click Start 3. Click + ADD NEW INSTANCE from the navigation pane on the left of your browser You will be presented with a terminal window in the right of your browser. This is a Kubernetes node (node1).

4. Run a few commands to see some of the components pre-installed on the node.

$ docker version

Docker version 19.03.11-ce...

$ kubectl version --output=yaml



major: "1"

minor: "18"

As the output shows, the node already has Docker and kubectl (the Kubernetes client) pre-installed. Other tools, including kubeadm, are also pre-installed. More on these tools later.

It’s also worth noting that although the command prompt is a $, you’re actually running as root. You can confirm this by running whoami or id.

5. Run the provided kubeadm init command to initialize a new cluster When you added a new instance in step 3, PWK gave you a short list of commands to initialize a new Kubernetes cluster. One of these was kubeadm init.... Running this command will initialize a new cluster and configure the API server to listen on the correct IP interface.

You may be able to specify the version of Kubernetes to install by adding the --kubernetes-version flag to the command. The latest versions can be seen at Not all versions work with PWK.

$ kubeadm init --apiserver-advertise-address $(hostname -i) --pod-network-cidr...

[kubeadm] WARNING: kubeadm is in beta, do not use it for prod...

[init] Using Kubernetes version: v1.18.8

[init] Using Authorization modes: [Node RBAC]


Your Kubernetes master has initialized successfully!


Congratulations! You have a brand new single-node Kubernetes cluster. The node that you executed the command from (node1) is initialized as the master.

The output of the kubeadm init gives you a short list of commands it wants you to run. These will copy the Kubernetes config file and set permissions. You can ignore these, as PWK has already configured them for you. Feel free to poke around inside of $HOME/.kube.

6. Verify the cluster with the following kubectl command.

$ kubectl get nodes











The output shows a single-node Kubernetes cluster. However, the status of the node is NotReady. This is because you haven’t configured the Pod network yet. When you first logged on to the PWK node, you were given three commands to configure the cluster. So far, you’ve only executed the first one (kubeadm init...).

7. Initialize the Pod network (cluster networking).

Copy the second command from the list of three commands that were printed on the screen when you first created node1 (it will be a kubectl apply command). Paste it onto a new line in the terminal. In the book, the command may wrap over multiple lines and insert backslashes (\).


$ kubectl apply -f

configmap/kube-router-cfg created

daemonset.apps/kube-router created

serviceaccount/kube-router created created created 8. Verify the cluster again to see if node1 has changed to Ready (it may take a few seconds to transition to ready).

$ kubectl get nodes











Now that the Pod network has been initialized and the control plane is Ready, you’re ready to add some worker nodes.

9. Copy the long kubeadm join that was displayed as part of the output from the kubeadm init command.

When you initialized the new cluster with kubeadm init, the final output of the command listed a kubeadm join command to use when adding nodes. This command includes the cluster join-token, the IP socket that the API server is listening on, and other bits required to join a new node to the cluster. Copy this command and be ready to paste it into the terminal of a new node (node2).

10. Click the + ADD NEW INSTANCE button in the left pane of the PWK window.

You’ll be given a new node called node2.

1. Paste the kubeadm join command into the terminal of node2.

The join-token and IP address will be different in your environment.

$ kubeadm join --token 948f32.79bd6c8e951cf122

Initializing machine ID from random generator.

[preflight] Skipping pre-flight checks


Node join complete:

* Certificate signing request sent to master and response received.

* Kubelet informed of new secure connection details.

1. Switch back to node1 and run another kubectl get nodes

$ kubectl get nodes
















Your Kubernetes cluster now has two nodes – one master and one worker node.

Feel free to add more nodes.

Congratulations! You have a fully working Kubernetes cluster that you can use as a test lab.

It’s worth pointing out that node1 was initialized as the Kubernetes master and additional nodes will join the cluster as * worker nodes . PWK usually puts a blue icon next to *masters and a transparent one next to nodes.

This helps you identify which is which.

Finally, PWK sessions only last for 4 hours and are obviously not intended for production use.

Have fun!

Docker Desktop

Docker Desktop is a great way to get a local development cluster on your Mac or Windows laptop. With a few easy steps, you get a single-node Kubernetes cluster that you can develop and test with.

It works by creating a virtual machine (VM) on your laptop and starting a single-node Kubernetes cluster inside that VM. It also configures a kubectl client with a context that allows it to talk to the cluster. Finally, you get a simple GUI that lets you perform basic operations such as switching between all of your kubectl contexts.

Note: A kubectl context is a bunch of settings that kubectl which cluster to send commands to and which credentials to authenticate with.

1. Point your web browser to and choose Products > Desktop.

2. Follow the links to download for either Mac or Windows.

You may need to login to the Docker Store. Accounts are free, and so is the product.

3. Open the installer and follow the simple installation instructions.

Once the installer is complete, you’ll get a whale icon on the Windows task bar, or the menu bar on a Mac.

4. Click the whale icon (you may need to right-click it), go to Settings and enable Kubernetes from the Kubernetes tab.

You can open a terminal window and see your cluster:

$ kubectl get nodes











Congratulations, you now have a local development cluster.

Google Kubernetes Engine (GKE)

Google Kubernetes Engine is a hosted Kubernetes service that runs on the Google Cloud Platform (GCP). Like most hosted Kubernetes services, it provides:

• A fast and easy way to get a production-grade Kubernetes cluster

• A managed control plane (you do not manage the masters)

• Itemized billing

Warning: GKE and other hosted Kubernetes services are not free. Some services might provide a free tier or an amount of initial free credit. However, generally speaking, you have to pay to use them.

Configuring GKE

To work with GKE you’ll need an account on the Google Cloud with billing configured and a blank project.

These are all simple to setup, so we won’t spend time explaining them here – for the remainder of this section we’ll be assuming you have these.

The following steps will walk you through configuring GKE via a web browser. Some of the details might change in the future, but the overall flow will be the same.

1. From within the Console of your Google Cloud Platform (GCP) project, open the navigation pane on the left-hand side and select Kubernetes Engine > Clusters. You may have to click the three horizontals bars (hamburger) at the top left of the Console to make the navigation pane visible.

2. Click the Create cluster button.

This will start the wizard to create a new Kubernetes cluster.

3. Give the cluster a meaningful name and description.

4. Choose whether you want a Regional or Zonal cluster. Regional is newer and potentially more resilient –

your masters and nodes will be distributed across multiple zones but still accessible via a single highly-available endpoint.

5. Choose the Region or Zone for your cluster.

6. Select the Master version. This is the version of Kubernetes that will run on your master and nodes. You are limited to the versions available in the drop-down lists. Choose an up-to-date version.

An alternative to setting the Master version is to choose a release channel that influences the way your cluster will be upgraded to new releases.

7. At this point you can specify more advanced options available in the left pane. These include things such as whether Nodes will run Docker or containrd, and whether or not to enable the Istio service mesh. It’s worth exploring these options, but you can leve all them all as defaults.

8. Once you’re happy with your options, click Create.



Your cluster will now be created.

The clusters page shows a high-level overview of the Kubernetes clusters you have in your project. Figure 3.1

shows a single 3-node cluster called gke.

Figure 3.1

You can click the cluster name to drill into more detail.

Clicking the > CONNECT icon towards the top of the web UI gives you a command you can run on your laptop to configure kubectl to talk to your cluster. Copy this command to your clipboard.

The following step will only work if you have the gcloud and kubectl downloaded and installed. They can both be installed from here

Once you have gcloud installed and configured, open a terminal and paste the long gcloud command into it. This will configure your kubectl client to talk to your new GKE cluster.

Run a kubectl get nodes command to list the nodes in the cluster.

$ kubectl get nodes

















Congratulations! You know how to create a production-grade Kubernetes cluster using Google Kubernetes Engine (GKE). You also know how to inspect it and connect to it.

You can use this cluster to follow along with the examples in the book. However, be sure to delete your GKE

cluster as soon as you are finished using it. GKE, and other hosted K8s platforms, may incur costs even when they are not in use.

Other installation methods

As previously stated, there are lots of ways to install Kubernetes. These include:

• kops

• kubeadm

kops is an opinionated tool for installing Kubernetes on AWS. The term opinionated means that it wants to configure Kubernetes in a particular way and doesn’t let you customise very much. If you need more freedom with your installation you might want to consider kubeadm.

Previous versions of the book dedicated multiple tens of pages to each method. However, the material was extremely dry and difficult to follow. In this version I recommend readers follow online guides to build Kubernetes with either kops or kubeadm.


kubectl is the main Kubernetes command-line tool and is what you will use for your day-to-day Kubernetes management activities. It might be useful to think of kubectl as SSH for Kubernetes. It’s available for Linux, Mac and Windows.

As it’s the main command-line tool, it’s important that you use a version that is no more than one minor version higher or lower than your cluster. For example, if your cluster is running Kubernetes 1.18.x, your kubectl should be between 1.17.x and 1.19.x.

At a high-level, kubectl converts user-friendly commands into the JSON payload required by the API server. It uses a configuration file to know which cluster and API server endpoint to POST commands to.

The kubectl configuration file is called config and lives in $HOME/.kube. It contains definitions for:

• Clusters

• Users (credentials)

• Contexts

Clusters is a list of clusters that kubectl knows about and is ideal if you plan on using a single workstation to manage multiple clusters. Each cluster definition has a name, certificate info, and API server endpoint.

Users let you define different users that might have different levels of permissions on each cluster. For example, you might have a dev user and an ops user, each with different permissions. Each user definition has a friendly name, a username, and a set of credentials.

Contexts bring together clusters and users under a friendly name. For example, you might have a context called deploy-prod that combines the deploy user credentials with the prod cluster definition. If you use kubectl with this context you will be POSTing commands to the API server of the prod cluster as the deploy user.

The following is a simple kubectl config file with a single cluster called minikube, a single user called minikube, and a single context called minikube. The minikube context combines the minikube user and cluster, and is also set as the default context.

apiVersion: v1


- cluster:

certificate-authority: C:\Users\nigel\.minikube\ca.crt


name: minikube


- context:

cluster: minikube

user: minikube

name: minikube

current-context: minikube

kind: Config

preferences: {}


- name: minikube


client-certificate: C:\Users\nigel\.minikube\client.crt

client-key: C:\Users\nigel\.minikube\client.key

You can view your kubectl config using the kubectl config view command. Sensitive data will be redacted from the output.

You can use kubectl config current-context to see your current context. The following example shows a system where kubectl is configured to issue commands to a cluster that is called eks-k8sbook.

$ kubectl config current-context


You can change the current/active context with kubectl config use-context. The following command will set the current context to docker-desktop so that future commands will be sent to the cluster defined in the docker-desktop context. It obviously requires that a context called docker-desktop exists in the kubectl config file.

$ kubectl config use-context docker-desktop

Switched to context "docker-desktop".

$ kubectl config current-context


Chapter summary

In this chapter, you saw a few ways to get a Kubernetes cluster.

You saw how fast and simple it is to setup a Kubernetes cluster on Play with Kubernetes (PWK) where you get a 4-hour playground without having to install anything on your laptop or in your cloud.

You saw how to setup Docker Desktop for a great single-node developer experience on our laptops.

You learned how to spin up a managed/hosted Kubernetes cluster in the Google Cloud using Google Kubernetes Engine (GKE).

The chapter finished up with an overview of kubectl, then Kubernetes command-line tool.