GETTING STARTED WITH KUBERNETES
WHAT IS KUBERNETES?
Before we jump into what is Kubernetes and its usefulness, it’s essential to familiarize ourselves with two concepts: immutable infrastructure and containers.
IMMUTABLE INFRASTRUCTURE is a practice where servers, once deployed, are never modified. If changes are needed, you never do so directly on the server. Instead, you’ll build a new server from a base image, that have all your needed changes baked in. This way we can simply replace the old server with the new one without any additional modification.
CONTAINER offer a way to package code, runtime, system tools, system libraries, and configs altogether. This shipment is a lightweight, standalone executable. This way, your application will behave the same every time no matter where it runs (e.g, Ubuntu, Windows, etc.). Containerization is not a new concept, but it has gained immense popularity with the rise of microservices and Docker.
Armed with those concepts, we would now be able to characterize Kubernetes as a container or microservice platform that orchestrates computing, networking, and storage infrastructure workloads. you can define how your applications should run and the manners in which they ought to interact with other applications or the outside world. You can scale your services up or down, perform smooth rolling updates, and switch traffic between different versions of your applications to test features or rollback problematic deployments. Kubernetes provides interfaces and composable platform primitives that allow you to define and manage your applications with high degrees of flexibility, power, and reliability.
OBJECTIVE
Some time ago I worked on Docker Swarm which is a great tool that exponentially increase the power of Docker by creating a cluster of Docker hosts. Similarly, Kubernetes is an open-source platform created by Google for container deployment operations, scaling up and down, and automation across the clusters of hosts.
Though both the open-source orchestration platforms provide much of the same functionalities, there are some fundamental differences between how these two operate.
So, I am consolidating or discuss steps to create and deploy services using Kubernetes over here for the ease of access to other Geeks out there just like me. You can check my other blog where I have discussed Docker Swarm.
STEP 1: Installing kubenetes
There are many methods for installing Kubernetes. Kubeadm, which is used in this exercise is the general method for installing Kubernetes. It can be used on various public and private Clouds. However, it can also be used on bare metal. Minikube is a virtualized approach for installing Kubernetes. Kops is the utility for installing Kubernetes on Amazon Web Services. The kops utility enforces many of the enterprise standards for Kubernetes. Things like processor, instance size. So, we can’t take advantage of the free tier with kops. Kops takes advantage of other AWS resources as well, and Kubernetes for the Google Cloud Platform. So, there is a utility for installing Kubernetes on the Google Cloud.
In this blog, we’ll look at installing Kubernetes on Amazon Web Services, not with Kops. Therefore, we are able to use the AWS free tier. Of these steps, work on every environment, AWS, Azure, Google Cloud, bare metal, and more.
So, we’re going to start here at our AWS console and we’re going to, Launch Instance. We will create two instances, one called Kube-Master and Kube-Worker. We’re going to select, Ubuntu server 18.04 LTS, 64-bit and select the t2.micro instance, which is not really within the requirements of Kubernetes, but it can be used.
As you can see, our instances are now in place!
Now when we’re ready to connect, we are going to select each instance, click, “Connect,” and we’ll get an opportunity to connect.
There are various ways to connect to the instance. We are going to connect using Git Bash. So please consult the documentation, but there are other ways to connect as well. What I did is, I just changed the hostname of the master node and the worker node. This way, we can easily tell them apart.
/etc/hostname is the directory that stores the name of the node. Use,
vim /etc/hostname
to make changes to the directory. We will now install kubeadm.
Follow these commands and execute them on both Master as well as Worker, If you have logged in using another user, then we can switch to root user using the following command: sudo su
sudo apt-get update
sudo apt-get install docker.io
sudo apt-get install -y apt-transport-https ca-certificates curl
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
echo “deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main” | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
STEP 2: Initializing the cluster
Now, we’re going to initialize the cluster, and then we’ll run most of everything on the master node.
One thing that’s important, we’ve got to go back to our console and fetch private IP address for our master node. So, we’ll select our master node and under the description and we will get the private IP.
Here is the command we’re going to use for initialization:
Kubeadm init — -apiserver-advertise-address= <PRIVATE_INSTANCE_IP> — -pod-network-cidr=<CIDR_BLOCK>
you can see the parameters that we’re passing in. Because of the network plugin that we’re going to be using, we have certain parameters.
Since we are using the free tier, we will not pass the preflight checks, the preflight status. So, what we’re going to do is, suppress those errors and those warnings. We’re going to pass in this flag to suppress the number of CPUs and Memory constraints errors by using,
- -ignore-preflight-errors= <PARAMETERS>
If cluster initialization has succeeded, then we will see a cluster join command. This command will be used by the worker nodes to join the Kubernetes cluster, so copy this command and save it for the future use. To start using the cluster, we have to set the environment variable on the master node.
To temporarily set the environment variables on the master node, run the following commands:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
Alternatively, if you are the root user, you can run:
export KUBECONFIG=/etc/kubernetes/admin.conf
STEP 3: Join worker node to the kubernetes cluster
SSH into the Worker node and run the command generated by kubeadm init on this node.
After creating the cluster and joining worker nodes, we have to make sure that everything is working properly. To see and verify the cluster status, we can use kubectl command on the master node using
Kubectl get nodes to see the status of our Nodes (master and worker) whether they are ready or not.
we get this “NotReady” status. The reason why we’re getting this not ready status is because we have not yet installed our network plugin.
There are a variety of Networking interfaces that could be deployed. For this simple example I’ve used calico. Simply apply this manifest from one of your nodes.
kubectl apply -f https://docs.projectcalico.org/v3.9/manifests/calico.yaml
run kubectl get nodes again.
And then we can see that the pods are now “Ready”.
STEP 4: Testing the kubernetes cluster
Now that we have a cluster in place, lets look at some of the features provided by Kubernetes.
let’s deploy an application. Nginx is one of the applications that is a learning application for Kubernetes. For this exercise, it will be fine. The nginx is one of the test applications and it is a web server. So, what we’re going to do is create a deployment for nginx.
We’re going to call the deployment base-nginx using
create deployment — — image <>
The image name, in this case, is nginx, and our deployment name is base-nginx. Then a deployment is created.
run a command to get pods: kubectl get pods, and we can see that so far we have one pod running.
We can also describe the pods to list the details, including the node on which the pods are running. So, when we run this command, we’re going to select one of the pods that were listed. We can actually see that the pod is running on the worker node, because we’ll see the worker nodes private IP address.
In order to access the application, we need a service. A service is an additional level of abstraction between the user and the running ports. So, we’re going to expose the deployment using a service, and in this case, it’s of type NodePort. So, we’re going to need to type
kubectl create service NodePort
that’s the type of a service. This is the most basic option of exposing your service to be accessible outside of your cluster, on a specific port (called the NodePort) on every node in the cluster.
It’s a good practice to have the service name the same name as your deployment, and we’ll say — TCP, the exposed port, and then the execution port because nginx has a port 80, and it also runs on port 80. So, we want to expose 80, and this application runs on port 80.
we can see here kubectl creates service of type NodePort. The service name is base-nginx, and we can see here — TCP exposed port and execution port. You can see here, get deployments, we see the deployment name and we want the service to be the same name, so we can see here we run the command here.
Again here, what we want to do is we want to also get the port that our application was mapped to. if we run command kubectl get services, that we ran earlier, we can find our service, and we can go over and see our port mapping.
Now, we want to build a URL. The URL will be the node’s public IP address or public DNS name, colon, and the port, the service port that we just saw, the mapped port. In this case, the port is 30462.
We put the URL in a browser, and we can see the homepage for nginx. So, this is running out of our worker node. You can do the same thing with the worker nodes public DNS name, same port we can see the ngnix on page.
One of the big benefits of Kubernetes is the fact that it will self-repair or self-heal. If we delete a pod or a replica, it will simulate the loss of a pod or a replica failure. So, we will run command, get pods, again. Then, we’re going to run kubectl delete pod and pass in that full pod name.
If we run kubectl get pods, we will see the listing here and notice that we have a new pod name in there. So, we lost our one pod but now we have a new replica. It was brought up automatically.
CONCLUSION
With that, we successfully provisioned and deployed NGINX on single master Kubernetes cluster on AWS. We also looked at one of the main features of kubernetes, i.e., Self-healing ability.
Kubeadm is an alternative approach, but kops is still recommended on AWS. Kubeadm sets up a minimal viable cluster but cannot provision your infrastructure which is one of the main differences to kops. Another differentiator is that Kubeadm can be used not only as an installer but also as a building block.
Give your valuable feedback for the scope of improvement and enhancement.
