DEV Community: Ashirwad Pradhan

Getting started with Kubernetes on Minikube

Ashirwad Pradhan — Thu, 12 May 2022 19:32:38 +0000

Kubernetes is a container orchestrator which helps to manage and scale application running on containers.
Setting up a production grade Kubernetes cluster is a hassle when it comes to provision different kind of nodes which manages a Kubernetes workload. In a Kubernetes cluster, there are two kinds of nodes

Master Nodes (control plane) : These nodes manage and control how the application are "orchestrated". This simply means master nodes keeps track of current application state, does the current state of the deployment matches the desired state and so on. To sum it up, this is the brain of the Kubernetes cluster.
- Worker Nodes: These are the actual nodes where the containers are provisioned and run. These are the nodes that actually handle the workload.

Note: There are other components to a Kubernetes cluster like Controller Manager, etcd etc. but that is beyond the scope of this post

For starters, knowing the above information is just right to get started with some hands-on on Kubernetes. While we can set up our own VM's as control nodes and worker nodes, but it is too much hassle to install all the components required to run a Kubernetes cluster.

Therefore, we will take use Minikube that comes with all the bells and whistles that are required to run a Kubernetes cluster with just few commands. Let us get started with some hands-on now. Fire up that terminal of your choice and start following

Assumption: You must have docker-desktop installed on your machine to follow along. Check if docker is installed on your system by running the following command in your terminal

docker -v

If you see something like this, then you are good to go 😄

~ ➜ docker -v
Docker version 20.10.12, build e91ed57

Installing Minikube

For macOS,

brew install minikube

For Windows,

choco install minikube

For Linux,

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

If you do not have brew installed on macOS or chocolatey installed on Windows, you can alternatively run:

For macOS,

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64
sudo install minikube-darwin-amd64 /usr/local/bin/minikube

For Windows,
Follow instructions on Minikube for Windows

Start Minikube cluster

On your terminal, run the following command,

minikube start --vm-driver=docker

You should now see Minikube spinning up Kubernetes cluster for you. If you get output something like this, then you are good to go.

~ ➜ minikube start --vm-driver=docker
😄  minikube v1.25.2 on Darwin 12.3.1
🆕  Kubernetes 1.23.3 is now available. If you would like to upgrade, specify: --kubernetes-version=v1.23.3
✨  Using the docker driver based on existing profile
👍  Starting control plane node minikube in cluster minikube
🚜  Pulling base image ...
🐳  Preparing Kubernetes v1.23.1 on Docker 20.10.12 ...
    ▪ kubelet.housekeeping-interval=5m
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

You can now view the nodes created by Minikube by running kubectl get nodes command

~ ➜ kubectl get nodes                                                                                                                                                                                                
NAME       STATUS   ROLES                  AGE   VERSION
minikube   Ready    control-plane,master   23d   v1.23.1

As you can see, you now have a single node Minikube cluster running on your local machine. In the output you can see something interesting. There is only one node, which is the master node.

Now, you might be wondering where is the worker node that I told you at the beginning of this post. Well, Minikube creates a single node cluster by default, meaning that a single node act as both master and worker node.

This setup is fine since we are using this for our local development purpose. In actual production grade setup, the setup has multiple master and multiple worker node for high availability and to make the system fault-tolerant.

Note: Minikube also supports multi-node setup but that is a discussion meant for some other post. We will just work with single node cluster for this tutorial.

Now that we have the setup ready, we can now run our applications on this setup.
For the purpose of this tutorial we will use an echo-server by Google Cloud which when sent an HTTP request will echo out details about the HTTP request and client who sent that request.

Key Concepts

Before getting into the deployment, let us understand three basics concepts when it comes to Kubernetes.

Pods: The smallest compute unit in a Kubernetes setup. The pods are the place where containers run (where the application code runs). Although a pod can run multiple containers, usually we see pods running one or two containers. For horizontal scaling, Kubernetes spawns multiple pods in a node so that the underlying application can scale.
Deployment: This is a way we define a pod configuration. A pod configuration consists of what image to run, the number of replicas a pod can have, resource configuration etc. In short, a deployment is a way to run pods running containers at scale.
Service: A service helps us to expose the underlying ports in the containers that we want to send network requests to. So services are tied to pods, making it a means to communicate with our application. No matter how many pods are running in the background we cannot connect to the service and in turn the Kubernetes service can help us communicate with the application. Kubernetes' service also act as a load balancer for the pods.

Now that we have enough background, let us deploy our first pod in the Kubernetes cluster on Minikube.

Your First Deployment

Run the following command in your terminal

kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.4

So we have now created a deployment with a bare minimum specification which is a name for the deployment, and we have specified the container image to run.
Here hello-minikube is the name of the deployment and the image is specified using --image argument.

Now, let us verify if the pod is actually running. To see the pods running, run the following command kubectl get pods

~ ➜ kubectl get pods                                                                                                                                                                                                 
NAME                              READY   STATUS    RESTARTS   AGE
hello-minikube-7bc9d7884c-cb2fs   1/1     Running   0          78m

The pods are in RUNNING status and 1 replica is running. The 1/1 means that we have 1 replica running, currently out of 1 desired replica.

Exposing through a Service

Now that our echo server is running, How can we access the server ? If you now try to access localhost:8080 you will see Unable to connect error.

As I already mentioned, to access/communicate with pods, we need to expose the pods with a service. Let us create a service and expose port 8080 of the hello-minikube deployment. To create a service, run the following command

kubectl expose deployment hello-minikube --type=NodePort --port=8080

This command tells Kubernetes to expose the port 8080 of the pods of hello-minikube deployment. The service of type NodePort. Kubernetes has different types of services namely NodePort, ClusterIP, LoadBalancer etc.
We will dive deeper into the types of services in some other post, but for now let us just assume that using NodePort we can direct external traffic (HTTP request from host machine) to the Kubernetes cluster.

Now let us run kubectl get service command to see the details of the service that is created

~ ➜ kubectl get service                                                                                                                                                                                              
NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
hello-minikube   NodePort    10.103.34.250   <none>        8080:32262/TCP   78m
kubernetes       ClusterIP   10.96.0.1       <none>        443/TCP          21d

From the output, we see that a NodePort service named hello-minikube is created. So now let us hit localhost:8080. Uhhh Oh! We still cannot reach the echo-server.

Port Forwarding

There is one missing piece of the puzzle still left so that we can access the echo-server. So let us understand why is this not working even after exposing the deployment using the hello-minikube service?
The Minikube setup basically runs a VM where the application pods are running. We are trying to access the port that is exposed on the Minikube VM from our host machine. That is the reason the communication is not happening. Basically, the network does not know how to route traffic from host machine to Minikube VM.

To enable the routing of traffic from host machine, run kubectl port-forward service/hello-minikube 8080:8080

~ ➜ kubectl port-forward service/hello-minikube 8080:8080                                                                                                                                                            
Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080

Now, let us try to access our echo-server localhost:8080. Viola!! We are able to access our echo-server and it give us the see the following output. Here we can see the details of our request sent to the echo-server.

CLIENT VALUES:
client_address=127.0.0.1
command=GET
real path=/
query=nil
request_version=1.1
request_uri=http://localhost:8080/

SERVER VALUES:
server_version=nginx: 1.10.0 - lua: 10001

HEADERS RECEIVED:
accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
accept-encoding=gzip, deflate, br
accept-language=en-US,en;q=0.5
connection=keep-alive
host=localhost:8080
sec-fetch-dest=document
sec-fetch-mode=navigate
sec-fetch-site=none
sec-fetch-user=?1
upgrade-insecure-requests=1
user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:100.0) Gecko/20100101 Firefox/100.0
BODY:
-no body in request-

This command kubectl port-forward service/hello-minikube 8080:8080 allow us to port forward our request from our host machine at port 8080 to the pods port 8080.

Conclusion

So to wrap up we have successfully

Set up a Kubernetes cluster
Run pods and deployment
Expose deployment using Kubernetes service
Port-forwarded traffic from host machine to the Minikube VM

I hope now you are a little more comfortable in starting your own journey in Kubernetes. Feel free to share your journey with me!!

If you liked what you read, please share and leave a like! 😄

All about Serverless vs Containers

Ashirwad Pradhan — Thu, 12 May 2022 08:18:59 +0000

Let us try to understand what the term Serverless and Containers mean:

Serverless

For an application to be termed as serverless, the application and all of its components should satisfy these four characteristics.

There are no servers to provision or manage
The serverless environment should be able to scale out or scale in the application as the load (traffic) increases or decreases
The environment should enable our application to be highly available
Highly cost optimized, i.e. you do not pay when your application is idle

If a service fulfills all the above criteria, then it is essentially a serverless service. Some well known serverless offerings by AWS are Lambda (compute environment), DynamoDB (NoSQL database), API gateway (reverse proxy).

But for the sake of this discussion, let us just focus on compute service, which is AWS Lambda.

AWS Lambda

To explain briefly, AWS Lambda is a compute service offered by AWS which enables you to run code without provisioning or managing any servers. We will learn about other characteristics of Lambda later in this post.

Now let us see what containers are:

Containers

Containers are a single cohesive unit which packages code and all of it dependencies together in a unit. When provided with an appropriate container runtime environment, each instance of the container behaves exactly the same. The applications run reliably when deployed on multiple computing environments.

For example: A container packaged on Windows when run on Linux with the same container runtime will run exactly the same way. This helps us to deploy and run our application on any environment, as long as it supports the appropriate container runtime.

Container runtime: A set of programs or process required for packaged unit of code and its dependencies (called container images) to run.

But simply running a single container is not enough. Most of the time, our applications are too complex just to run on single containers. A typical application may have a frontend container talking to a backend container, which might be storing data in some database container. When we think about these kinds of applications, there are multiple considerations that we need to make.

For example: The group of containers should be able to talk to each other over a network. They should be able to scale up and down depending on traffic to each.

So to manage these aspects, we use container orchestrators to help us easily manage the application running on the containers for us.
Some popular container orchestrators are:

Docker Swarm
Kubernetes
AWS EKS
AWS ECS

Now that we have some idea of what each term means, let us do some comparisons between Serverless and Containers based on some factors:

Runtime Environments

For Serverless (AWS Lambda),

Infrastructure is completely managed by cloud provider
- Scales in and out automatically
- We do not need to worry about OS patching, software upgrades of the underlying infrastructure
Cannot install any custom application (e.g. web server like Apache or reverse proxy like Nginx)
- Can install libraries/code dependencies
Memory in AWS Lambda is limited to a max of 10 GB
Compute time for AWS Lambda is also limited to 15 minutes or 900 seconds. If the workload exceeds this time limit, we get an Exception and the Lambda instance stops the computation immediately.

Aims to solve a particular problem without the hassle of installing softwares or managing infrastructure. Just start writing business logic and focus on solving the problem.

For Containers (AWS EKS),

Infrastructure is managed by the user
- It is user's responsibility to manage the control plane (master) nodes on EC2. All the components related to EC2 like AMI rehydration, EC2 Scaling and making it highly available is up to the user to configure
- The user decides on VM size, Memory size and other aspects of the node
Can use container to package any custom/third-party application (e.g. MongoDB, MySQL, Nginx etc.)
Memory is managed similar to configuration of EC2 instance
Can choose between different classes of EC2 instance (t, c, m etc.)

Gives users a plethora of choices ranging from customizing the hardware and use any software/application

Where they fit ?

For Serverless (AWS Lambda),

The main use case where AWS Lambda shows it true power in event driven architectures. It has built in integration with lots of AWS services e.g. AWS S3, AWS SNS, AWS SQS etc.

For example: If we want to process a file as soon as it is put into S3, we can set a PutEvent notification from AWS S3 to SNS topic, where an AWS Lambda has its trigger set to that SNS topic. As soon as a file is uploaded onto AWS S3 it triggers the SNS topic which in triggers the AWS Lambda. Now the AWS Lambda can pick up the file path from the notification and process it

It is better suited when traffic is sporadic and unpredictable. Since AWS Lambda automatically scales in and out based on traffic, therefore it is cost-effective. During the times when there is no traffic we pay almost nil since our lambda is not invoked at all
AWS Lambda is suited for microservices as long as it does not depend on third party software. However, code dependencies can be installed

For Containers (AWS EKS),

The main use case where container is better when compared to AWS Lambda is when we want a faster migration to cloud. Since we can have any third party applications running on containers, we can easily spin up our choice of web server or database on the cloud. This is not possible with AWS Lambda
It is better suited for continuous and predictable workload. Since we will always have some minimum amount of pods on the worker nodes always running along with the control plane (master) we will incur costs even when there is no traffic
Containers is very well suited for microservices as it can package and run any kind of third party application or software

Now let us look at how they scale in presence of traffic.

Scaling

For Serverless (AWS Lambda),

For every request to AWS Lambda, it spawns a new instance to process concurrent requests. After an AWS Lambda instance has finished processing one request, it becomes available to process the next one
- A major disadvantage of AWS Lambda is the cold start time which is incurred when an AWS Lambda instance is spawned for the first time. The cold start time can be significant for a high performance or critical application
- To eliminate this disadvantage, we can set up provisioned capacity for AWS Lambda so that every time we have some instance of Lambda in a warm state
- Lambda scaling is limited to 1000 instances of lambda per region per account, by default. Therefore, theoretically, it can support only up to 1000 concurrent requests. However, this can be increased to several thousand of instance by requesting a quota increase
- AWS Lambda is not suited for long-running workloads because it has an execution time limit of 15 minutes or 900 seconds.

For Containers (AWS EKS),

A pod in the container is able to handle multiple requests before having the need to spun up another pod to service more requests
- When the traffic further increases, a new worker node is spawned and a new pod is deployed on the new worker node
- Here also whenever a new pod or worker node is spun up we do experience a cold start delay but still it is better than the cold start delay to process every concurrent requests
- Here we incur more costs for under-utilized resources. Suppose our worker node is capable of running 3 pods and the traffic is just enough that it requires 4 pods to satisfy the SLA. So in that case we require one more worker node running 1 pod. But since a worker node is spawned which is basically an EC2 instance, we have to pay for the whole EC2 instance even if we are utilizing 1 pod worth of resources.

Conclusion

After learning about all those points about serverless and containers, we can conclude that one is not better than the other. It basically depends on the use case.
Think Serverless

When traffic is spordic and unpredictable and when we have run a short lived job. It is cost optimized but compromises on flexibility on the kinds of applications it can run.

Think Containers

When traffic is spread out and predictable. Even though it may costs more in some cases but it provides a complete flexibilty on the kind of hardware and software/applications we want to run.

AWS EKS vs AWS ECS... Confused ?

Ashirwad Pradhan — Thu, 12 May 2022 06:51:24 +0000

Let us start with a simple introduction of all the three offerings from AWS.

AWS EKS (Elastic Kubernetes Service)

This is a standard Kubernetes offering from AWS which helps you to manage your Kubernetes application on the cloud. Using this service, you can deploy and scale your Kubernetes service as you would do with an on-premise solution.

On-premise - It is a term used for services (web server, database, kubernetes cluster etc.) that is self-hosted and self managed on your own private hardware.

AWS ECS (Elastic Container Service)

This is a fully managed container orchestration service created and managed by AWS. You can think of this as AWS' own implementation of Kubernetes like service.

Now that we have seen what each service means on a high level, let's dive more deep into it.

How AWS EKS and AWS ECS are similar ?

The goal of both these services is to run and scale your application containers.
In EKS the container run within a pod, while in ECS the container runs within a task. In both the AWS services, the worker nodes where pods/tasks run are essentially an EC2 instance which is managed by you. You are responsible for creating and managing the EC2 cluster.

Difference between EKS and ECS ? When to prefer one over the other ?

When it comes to EKS, it is an open source implementation of Kubernetes on AWS, but ECS is an AWS proprietary technology. So if you want multi-cloud support or if you already have a Kubernetes cluster running elsewhere (on-premise or other cloud vendors) then choosing EKS over ECS makes more sense because you can easily move over your existing application over to EKS with very minimal spec change.
If you want to optimize the cost and your application was not deployed on any container orchestration service before, then you may want to prefer ECS. With ECS, you do not have to pay for control plane (master) nodes, and you only pay for worker nodes that your cluster has. In contrast with EKS you pay for control plane (master) nodes as well as worker nodes.
If your application uses a lot of AWS services, the ECS might be a better option because it provides out of the box integration with a lot of AWS services like IAM (Identity Access and Management), ELB (Elastic Load Balancer) etc. With EKS the integration is not as rich as ECS, but it is not too bad either. You may have to manage your own middleware (integration with other AWS Services) in some cases.
If you have a very specific use-case where you want to manage your own control plane nodes, then you can do that with EKS. AWS has a provision to allow you to manage your own control plane nodes by spinning up your own control plane in an AWS EC2 instance.

Conclusion

Choose ECS,

If you want to run on less cost and your application was not using any container orchestration service earlier. You will get better integration with other AWS services. The downside is once you move your application to ECS you will loose the flexibility to move to other cloud vendors or move to an on-prem solution if need be.

Choose EKS,

If you already have an Kubernetes based application running elsewhere(either on-premise or on some other cloud vendor) and you want to move into AWS. Though it is more costly than ECS but you can provision and manage your own control plane nodes exactly as you like. With that said you do have to manage some of the middleware to other AWS services using your own code.