Kubernetes workflow in short

·

3 min read

Introduction

Peace to you all , Here is the Link to my previous blogs, Where I have posted about Docker, Containers and DevOps.

This blog focuses on Kubernetes and its workflow.

Getting Started

Kubernetes being a container orchestration tool and has lots of features which needs a separate series of articles. Here I am focusing on simple things on how you can host something on Kubernetes.

Containers

Before starting to get into Kubernetes it is important that you know a bit about containers. You can either find it in my previous blogs ,

or

Think of containers as a running instance of an entire application with all the required dependencies. Containers don’t necessarily need to be the entire application and they can be of different micro services, Services, etc.

So simply deploying a container would be enough instead of installing the whole application and its dependencies.

Cluster vs Node vs Pod

Clusters are as the name suggests, a cluster but here it denotes cluster of nodes. A cluster can have multiple node, running on them.

A node is a virtual machine to be precise. It will have CPUs, RAM, ROM etc. A node can have multiple pods running on them.

A pod is usually a container running but not necessarily a single container. It is the basic deployable object in Kubernetes.

Services and Ingress

A container which is deployed in a pod can be accessed by exposing it using a service. A service helps in internal routing ( communication within and between clusters ) and exposing something externally using an IP.

For example, A pod which runs the front-end can be accessed only through exposing the pod through a service.

Ingress is a type of load balancer which is mainly used for domain based routing ( there are many other features in Ingress) .

For example, You own a domain called xyz.com and you need to create subdomains or domains based on the paths like “xyz.com/about”, “abc.xyz.com”, etc. These can be handled with the help of Ingress.

An Ingress controller would be required to handle the Ingress. Nginx is the most common Ingress and Ingress controller, but there are several other Ingress controllers.

Secrets and configs

Config files have values which can be public, Secret files have values which are public. These are values which are required in the working of the application. They are mainly used in AppSettings which is ignored during the containerization of the application and therefore these files are essential as config and secret if AppSettings has values left in them for the application to work.

A basic workflow

You have an application ready to be deployed.

The first step is to containerize the application and get the image. The image can be used for building using any pipelines ( which we will focus on the upcoming blogs) , or straight away hosted in K8s.

A deployment file written in YAML can be used to create pods. If required, the secret, config files and service are also written in YAML.

The service file if required, exposes the application to access externally using any IP.

This is the basic workflow of a K8s Application.

Summary

This blog explains about how a minimal file is hosted in Kubernetes without getting into cloud or pipeline concepts. The following blog will focus on cloud and pipeline concepts which accompany K8s.

See you around later...

Okay . So hold on, stay with me as we get to know Kubernetes more and DevOps even more.

Peace be upon you!

Did you find this article valuable?

Support Shajith by becoming a sponsor. Any amount is appreciated!