An introduction to Kubernetes

Introduction

Technology moves faster, to achieve and deliver the best results to the demands of the market. Nothing stops, and eagerness consumes the need for faster, reliable and stable results. Thus, in all different areas new discoveries and tools are being developed to attend costumer needs. In IT field, a new framework or tool born each seconds, in a velocity that whether you decide to keep isolated from the work and society for only three months, and you get back, you will realize so much changes in a short timeframe, impacting directly our lives, which means that a person who is not keeping her knowledge up to date, are in risk of being out of the market.

In IT field, the cloud revolution brought so many advantages and effectiveness to systems, although many companies still reluctant from moving their infrastructure to the cloud, besides offering new possibilities for establishing and deploying your applications.

Containerization is one of the trending topics, which still causes many doubts regarding its definition, one good way of detailing it can be:

Eliza wrote a program on her Windows PC to streamline workflow between her department, a second department within the company, and a third outside agency. She carefully configured the software to eliminate unnecessary steps and enable low-friction sharing of documents, files, and other assets. When she proudly demoed her program on her manager’s desktop Mac, however, it crashed within seconds — despite working perfectly on her own machine.

The last history still very common nowadays, and for sake of simplicity, what is a container? It’s a separated environment which has its own characteristics and configurations, where the developers prepare, with everything need for running an application in a natural workflow, without any issue. Because, if you guarantee that the application is running properly inside the container, this can be run in any other computer, avoid Eliza’s problem.

So, basically containers allow us to create an environment ready to run our applications, and unlike virtual machines (VMs), do not require the overhead of an entire operating system (OS). That means containerization is less demanding in the hardware department and needs fewer computing resources than what you’d need to run the same applications on virtual machines.

This article goal is to introduce Kubernetes and give some examples of how it can be used, so after this you will be ready to create a Kubernetes cluster locally or in the cloud. Further, in the next articles, we will delve in more detailed and complex subjects.

Orchestration

So, now that we know what is a containerization, orchestration will be another easy topic to cover. But before, let’s get back to containers and imagine the following situation.

Jimmy has been learning a lot about containers, and he has been pushing hard to deploy all the applications of his current company. After some time, all the applications were running in containers, but Jimmy noticed that the number of containers were increasing day by day, making it difficult to maintain, keep up to date and manage them. Jimmy was managing them manually, with the risk of making mistakes, demanding an extra time from him and his team to keep their eyes in each container.

With the short history, we can learn that deploying your applications into containers brings a lot of advantages, but at the same time, with a persistent increase in container numbers, you need to find a way that will manage everything to you hastily, and that is exactly what orchestration is.

So, basically in container orchestration you will have a cluster, and all the containers deployed in those instances of the cluster will be managed by an orchestrator platform. It has the capability of:

• Redundancy and availability of containers
• Provisioning and deployment of containers
• Scaling up or removing containers to spread application load evenly across host infrastructure
• Allocation of resources between containers
• Load balancing of service discovery between containers
• Health monitoring of containers and hosts
• Configuration and secrets management

So, orchestration offers to us the capability of managing with effectiveness our containers, therefore there is no doubt in all the gains that this can bring to a company. Besides, many stable and reliable tools are available in the market:

With so many tools in hand, which one of them I choose? Because your choice will impact dramatically and directly the usage of the resources of a team, in this case, developers, architects and others. Perhaps, the most important choice that will impact how all your applications are deployed and containarized, which consequently are associated with costs.

Choosing the Orchestrator

Choosing the orchestra conductor comes with a heavy responsibility regarding its definition, and with so many tools we will make a comparison between AWS Fargate and Kubernetes to explain why is so important to select with caution, and that one choice for a company, can not be a good choice to another, because each of them has their costumers and business.

Kubernetes is far away one of the best orchestrators, more customizable and complex, which mean that using that may ensure to you the best results and effectiveness of the tools in the market, although the need for skilled people, considering that its learning curve is higher than another tools, and people to manage the cluster. Summarizing, Kubernetes gives freedom to the engineers and architects to go deep into security, infrastructure, scalability, stable network, but all those configurations has to be managed by a team, which increases the cost.

Ergo, the AWS Fargate all the cluster, security, network even that customizable are still managed by AWS, which leaves the responsibility to Amazon, reducing the cost to your company.

This was one of the examples of how he can face each tool, and check each one is better for our case, you might find another examples, after all, everything relays on achieving the best results with less budget.

Our Two Examples

In this article, we want not only to give the user a tutorial of how to create a Kubernetes cluster locally for development purposes, but also for production creating a cluster in the cloud. Then, our first example will cover the usage of Minikube, a Kubernetes cluster that you can run locally in your machine, and the second one we will use Amazon EKS for deploying our cluster.

But, what is a Kubernetes cluster and its components?

How Kubernetes works, and Its Structure

It is easy to get lost in the details of Kubernetes, but at the end of the day, what Kubernetes is doing is pretty simple. Cheryl Hung of the CNCF describes Kubernetes as a control loop. Declare how you want your system to look (3 copies of container image a and 2 copies of container image b) and Kubernetes makes that happen. Kubernetes compares the desired state to the actual state, and if they aren’t the same, it takes steps to correct it.

Related to architecture, all the Kubernetes components talk with each other through the API server, besides the architecture can be summarized into the next image:

We can break down the components into three main parts.

1. The Control Plane — The Master.
2. Nodes — Where pods get scheduled.
3. Pods — Holds containers.

Master

The control plane is the orchestrator on its own, responsible for making the communication between the another components through API Server, storage within the ETCD, the Scheduler that is responsible for managing all the pods that have been created, and find the best node for putting them to run, besides Scheduler also checks with everything is ok with each pod.

Node

Node is a simply instance of the cluster, or a part of a machine. We can say it roughly that a Node is a “machine” running on the cloud. For example, if you launch a Kubernetes cluster in Amazon EKS with two nodes, 2 EC2 instances will be created to represent that nodes, the same behavior will happen with GCP and GKE.

In the Node, we have the Kubelet, an agent that runs on each node in the cluster. It makes sure that containers are running in a pod. Also, works in group with Scheduler and API Server. For not making confusions into this point, the Scheduler manages more the overall health of pods checking if they are running in a proper Node when they are launched. After the pod is launched properly in a Node, the Kubelet will take the responsibility of that to check if all the containers is running in the pod.

Then, we have the kube-proxy which is a network proxy that runs on each node in your cluster, implementing part of the Kubernetes Service concept.

Pod

Accordingly to Kubernetes official description, A Pod (as in a pod of whales or pea pod) is a group of one or more containers (such as Docker containers), with shared storage/network, and a specification for how to run the containers. A Pod’s contents are always co-located and co-scheduled, and run in a shared context.

Finally! The First Example

So, now that we are familiarized with containers and orchestration, we can start to create our “orchestra” locally. We are going to use Minikube, which is an emulated Kubernetes cluster that runs on your machine. For this example, we will need both minikube and kubectl installed and running. As the setups for each operational system are different, you can following the Kubernetes official guide to install those two tools.

Install Minikube

Make sure that your minikube is up and running after the installation, by typing:

$ kubectl cluster-info

If everything goes well, you are going to see the following result:

You can also verify the cluster by checking the nodes. Use the following command to list the connected nodes:

$ kubectl get nodes

Finally, you can gather information about your cluster with the command:

$ kubectl describe node

Which means, that we are ready to go to deploy an example container. Thus, in Kubernetes there are so many ways of deploying containers, imagine that you have a Dockerfile for one application, and you have already built that image and pushed to docker.hub or another container registry. For deploying this docker image inside a pod, you can use Kubernetes definitions files, that are basically YAML files, where you define the container you want to run, the specifications of the pod, and many other configurations. You can provision the following with Kubernetes and its YAML configuration files:

• Deployments — In this configuration file you can specify your image, number of replicas and many other configurations, that the Kubernetes Scheduler will provision automatically pods based on this configuration.
• Pods — You can create a configuration YAML file to deploy a single pod.
• Service — Services are very important, and it’s the way that your applications running inside the container will be exposed to each other, or to external clients.
• StatefulSet — It’s another way of provisioning pods with a specified image, but the StatefulSet is more for pods and containers that must have a stable and reliable network, with a high redundancy. For example, databases, service discovery tools must be deployed as a StatefulSet.

With all this information, the things are starting to get more complicated, and as that tutorial that is aimed to a superficial contact and basics of k8s(Kubernetes abbreviation), using YAML configuration files may be a little bit difficult for a first contact. So, we are going to use the Helm, which helps you manage Kubernetes applications — Helm Charts help you define, install, and upgrade even the most complex Kubernetes application.

Therefore, Helm is a tool that makes an abstraction from the Kubernetes configure files and commands, making easier to run and update containers in the cluster. So, let’s install Helm and start using that.

Installing Helm

Helm is basically a repository of pre-configured images ready to run in a k8s cluster. Also, you can create your own repository and Helm files, or update and change the way you want some file. Today, we are going to deploy NGINX in our local cluster. So, to check if your Helm is running correctly, do the following command:

$ helm version

You should see the helm installed version, take note if you are using the 3.x client or the 2.x client, because they have some differences in the commands, that we will show further.

Now, let’s add the NGINX repository and update that:

$ helm repo add nginx-stable https://helm.nginx.com/stable
$ helm repo update

• Using Helm 3.x client:

$ helm install my-release nginx-stable/nginx-ingress

• Using Helm 2.x client:

$ helm install --name my-release nginx-stable/nginx-ingress

If everything runs well, you will be able to see:

Now if you type the following commands, you are going to check that Helm has created a deployment, service and pod for NGINX.

$ kubectl get deployments
$ kubectl get svc
$ kubectl get pods

Now let’s test if it’s running, do the following command, and copy the name of the pod that is running NGINX:

$ kubectl get pods

After getting the pod name, do the following command:

kubectl port-forward <nginx-pod-name> 8080:8080

There are several ways of checking if your application is running, one of them is getting the minikube ip and access the NGINX with the minikube ip + port, and another way is the command that we just have done, which will port forward to 8080 to our local host, the current pod. So if you go to http://localhost:8080 you should get the 404 error page from NGINX, because it’s not configured yet, and in this article we are only showing how to run.

Second Example

This example compromises and contains a lot of steps from the first example, so in order to start this one, make sure that the following tools are installed in your machine:

• kubectl
• helm

With the tools installed, let’s create an EKS cluster, but first you need some basic stuff like an AWS account and the AWS CLI installed. Also, for creating the EKS cluster, we will use the eksctl tool, which will help us in creating the cluster in a faster way.

In the case you have an AWS account, but haven’t installed and configured the AWS CLI yet, you can go to that link to make it work.

https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html

https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html

If you have already done those steps, you can now install the eksctl, which is a command line tool developed by AWS, which helps us in creating the EKS cluster in a more easier and fast way. If you are using macOS, you can install eksctl with Homebrew:

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
$ brew tap weaveworks/tap
$ brew install weaveworks/tap/eksctl

For linux users, do the following:

$ curl --silent --location "https://github.com/weaveworks/eksctl/releases/download/latest_release/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
$ sudo mv /tmp/eksctl /usr/local/bin

For Windows, using Chocolatey, do the following:

chocolatey install -y eksctl aws-iam-authenticator

For more details about the installation, you can consult and query the following page:

https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html

With eksctl installed, let’s create a simple cluster with some default configs, please do the following command changing the parameters:

eksctl create cluster \
--name <environment-name> \
--version 1.14 \
--region <aws-region-to-create-cluster>

This command will create everything that is needed for the cluster, like instances, IAM roles, VPC. That’s why using eksctl is pretty straightforward, and gives us better results. It will take up to 15 minutes until everything is ready.

The kubectl as we have already discussed, is the Kubernetes command line interface for managing your clusters, and if you did the local Minikube example, your Kubernetes context in kubectl will be pointing to that cluster, we have to change that to point to the new EKS cluster.

Do the following command, and you will see that you have more than one context:

kubectl config get-contexts

Copy the name of the EKS context, and do the following command:

kubectl config use-context <eks-context-name>

Now your kubectl should point to the newly created EKS cluster, which means that we are able to start deploying containers.

Now, let’s add the NGINX repository and update that:

$ helm repo add nginx-stable https://helm.nginx.com/stable
$ helm repo update

• Using Helm 3.x client:

$ helm install my-release nginx-stable/nginx-ingress

• Using Helm 2.x client:

$ helm install --name my-release nginx-stable/nginx-ingress

If everything runs well, you will be able to see:

Different from the Minikube example, the EKS is a real cluster environment, and in the last example, it created a pod running a NGINX container inside that, where it’s only accessible locally, and if we do the command kubectl get svc in the Minikube example, we will see that a Load Balancer service for NGINX will be forever pending, but in EKS example we can check that will provide us a DNS. So, the following command will show your services, and under the EXTERNAL-IP column you can check the DNS of the created Load Balancer.

kubectl get svc

If you copy and paste the DNS value for the NGINX created Load Balancer in your browser, you will check that it’s working perfectly.

So, isn’t that wonderful? Everything was provisioned for us automatically, we haven’t have to go through AWS console and create a Load Balancer manually.

Conclusion

In this article, so many things about Orchestration was discussed, and the two examples were given in order to introduce an initiative practice with that tool. It is as superficial as possible to introduce the topic, but as we can see, Kubernetes is a robust container orchestrator that can give you many benefits when you are deploying your application as containers.

Feedback is the best thing that we can receive to keep improving, it’s your time now! What can be improved on that article, or what should I have covered? Please comment if this helped you, or if you have a feedback! Following is my GitHub and contacts.

felipemeriga - Overview