Mind Matters Natural and Artificial Intelligence News and Analysis

# Getting Started with Kubernetes: A Cluster Setup Walkthrough

Setting up a Kubernetes cluster in Linode is incredibly simple

This series will give you an overview of Kubernetes, the popular open-source cloud computing platform developed by Google. Kubernetes allows for the development of cloud-based platforms using entirely open specifications, so you are never tied down to a specific vendor. Many cloud vendors, such as AWS, have proprietary ways of developing scalable web applications (such as their Lambda system). The problem is that this ties your application to their system, and, as we have seen with Parler, Amazon gives and Amazon takes away. Therefore, it is wise to not tie your infrastructure too tightly to a single vendor. Kubernetes allows you to build large-scale scalable applications in the cloud in a way that is transferable to a variety of vendors.

This tutorial will walk you through setting up a real Kubernetes cluster that is accessible over the Internet. We are going to use Linode to create the cluster, because Linode’s Kubernetes service is easy, low-cost, and reliable. You will need to sign up for an account on Linode.com to get started. You will probably also want to have read the Mind Matters series on Docker before starting this walkthrough.

## Setting Up Your First Cluster

Setting up a Kubernetes cluster in Linode is incredibly simple. From the Linode dashboard, click on the “Create” button and choose Kubernetes from the drop-down menu. This will bring up a screen that will ask you a few basic configuration questions to get your Kubernetes cluster running:

Cluster Label
This is the name of the cluster, but can only take certain characters. I called mine my-test-cluster.

Region
This is the physical datacenter that you want your cluster running in. You can choose wherever you wish, but I used “Dallas, TX” for mine.

Kubernetes Version
We will be using version 1.22.

The next section is about the machines which will be running your cluster. These are organized into “Node Pools.” We are only going to make a single node pool. You can find the lowest-cost machines under the “Shared CPU” tab. For this demo, I recommend adding 3 of the lowest cost machines available. At the time of writing, this was a “Linode 2 GB” which cost $10 per month (each) or$0.015 per hour (each). Click on the “Add” button to add those machines to your cluster.

At the bottom of your page it will give you a monthly total and a button that says, “Create Cluster.” Click that button and Linode will begin creating your cluster!

Linode Kubernetes clusters comes pre-equipped with a Kubernetes application called the Kubernetes dashboard, which gives you a web-based interface for managing your Kubernetes cluster. To access this, just click the “Kubernetes Dashboard” link shown in the image above. This will ask you for an authentication method. Choose “Kubeconfig,” and then, in the box below, upload the Kubeconfig file you previously downloaded to your computer. Then, click “Sign In.”

The starting dashboard is shown in the image below. On the left are the different types of resources (called “objects” in Kubernetes terms) that Kubernetes can manage. At the top is a “namespace” selector, which is currently set to default. The main part of the screen says, “There is nothing to display here” because we haven’t deployed anything yet.

To see the machines that are included in your cluster, on the left-hand menu, go down to the “Cluster” section and click on “Nodes.” This should give you a list of three entries, representing the machines that we originally added to the cluster. With Kubernetes, however, we don’t care too much about the physical hardware, as long as there is enough available for everything we want to do. How the applications are distributed on that hardware is managed by Kubernetes itself. Nonetheless, this section will show you Kubernetes’ view of your hardware.

Normally in Kubernetes, deployments are managed by YAML files which can themselves be under source control. However, to get started the Kubernetes dashboard provides a web interface to deploy a simple application.

To get started, click on the “+” icon on the top right of the screen. That will bring a new screen which gives you three options: “Create from input,” “Create from file,” or “Create from form.” Choose “Create from form.”

We are going to set the following.

App name
We will set this to my-test-app.

Container image
We will set this to johnnyb61820/simple-web-server. This is the container image that will be used on the cluster.

Number of pods
We will set this to 4. Note that this number can be bigger than the number of instances we have assigned to this cluster.

Service
Set this to External. This will allow the service to be reached from outside the cluster.

Port
Set this to 80. This is the port that will be exposed to the external world.

TargetPort
Set this to 8070. This is the port that our containers are listening on. The container specified here listens on port 8070.

Protocol
Set this to TCP.

The screenshot below shows what this looks like when it is filled out.

Once all of that is set, click on the “Deploy” button. At the time of this writing, there was a bug in the dashboard which says you have unsaved changes, and asks if you really want to leave. Just click “Yes.”

That’s all there is to it! You now have a (small) web application deployed to Kubernetes. To access your web application, click on the “Services” tab on the left-hand side. One of the services listed should be your my-test-app service, and to the right there should be a column titled “External Endpoints” which has a link to where your application was deployed. Click on that link, and it should say, “Hello from Docker!”

## Looking Around the Kubernetes Dashboard

Now that you have an application deployed on Kubernetes, it’s time to take a short tour of the Kubernetes dashboard. All of this information can be accessed from the command line, but the visual dashboard helps to guide you about what is available.

Our deployment in the previous section essentially created three types of objects: Services, Deployments, ReplicaSets, and Pods. The figure below shows how they relate to each other.

At the top of the chart we have a “Deployment.” Deployments have one basic job – controlling “ReplicaSets.” A ReplicaSet is essentially an image which the cluster wants multiple identical instances of. When we specified our container image, that is what the ReplicaSet replicates. It will create many containers from this image. The deployed containers are called “Pods.” We asked for 4 Pods, which are created and managed by the ReplicaSet. Note that a Pod can technically have more than one container, but for right now we can view them as roughly the same thing.

You might be wondering why we need both Deployments and ReplicaSets. The reason is that if we change versions of our application, then the Deployment will manage creating the new ReplicaSet (we will need a new one since it will be a different container image), and then turning off the old ReplicaSet once the new one is up and running. In general, we directly interact with Deployments in Kubernetes, and the Deployments then creates, manages, and removes ReplicaSets as needed.

So all of this manages the container instances (Pods) themselves. A “Service” is a named endpoint (internal or external) in your cluster. Services can load balance between multiple Pods that implement the same service. Therefore, if someone requests a Service endpoint, the service then routes that request to an appropriate Pod for processing.

So how does the Service know which Pods can handle which requests? Imagine if you had multiple different Deployments running, each doing different things. How would the Service know which one to point to? Most objects in Kubernetes have “Labels” attached to them. Labels are essentially arbitrary key/value pairs attached to objects. While they can be arbitrary, there are some standard ones as well. The Service implements a “selector” which finds Pods based on their labels. The labels for the Pods are initially defined in the Deployment, copied to the ReplicaSet, and then copied to the Pod. The Service then uses the label to know which Pods can service requests.

Now that you know what was deployed, you can look around the Kubernetes dashboard and find these things. You can find Deployments, ReplicaSets, and Pods in the “Workloads” section, and Services under the “Service” section. Feel free to click around these different areas.

As you click around, notice that nearly everything has a name and a set of labels. The name only has to be unique to the object type. Note that in our current deployment, both the Service and the Deployment are named my-test-app. Personally, I don’t like giving things the same name, but that is what the form-created service deployments do automatically.

Each object in Kubernetes can be modified through a YAML file. To the right of each object is a button with three dots. Clicking on that button will give you the option of editing the object. If you click the “Edit” button, you can see what the YAML for that object looks like. In a later installment, we will look at some of these files in more depth.

In case you missed it:

Getting Started With Kubernetes: A Brief History of Cloud Hosting. A history lesson for a better understanding of why web infrastructure hosting is the way it is. Way back in the early days of the Internet, web applications were hosted on specific server machines. Much has changed since then. (Jonathan Bartlett)