Forem: Krishnamohan Yerrabilli

Getting started with Kubernetes Namespaces

Krishnamohan Yerrabilli — Fri, 21 Oct 2022 03:25:48 +0000

It's crucial to understand that Kubernetes namespaces are not the
same as Linux kernel namespaces.

Kernel and Namespaces divide operating systems into virtual operating
systems called containers.

Kubernetes Namespaces Divide Kubernetes cluster into virtual clusters,
which you might call Namespaces.

Before we dive into Namespaces, First, let's understand some terms.

Terminologies

Container

A container is nothing but a ready-made software package
that contains everything needed to run an app from code to application

system libraries, default values for required settings, and any runtime it needs a containerholds everything.

Cluster

Each container runs on a cluster. It consists of a
Control plane and computer machine nodes.

The control plane

Takes care of the applications running on
the cluster and the resources they use, while the nodes are the
machines on which the clusters run.

Orchestration

Ever seen an orchestra? The orchestra conductor decides what
sound he wants, how many violins, how many trumpets, what octave and everything else.

Similarly, orchestration determines which container to use,
which resources to use, which application to run, etc.

Kubernetes comes from the Greek word meaning

sailing master or pilot. Simply put, it means a

person who has substantial control over operations.

This is what Kubernetes does.

It manages clusters, their deployment, scaling, etc.

Now let's dig into “Kubernetes Namespaces”

Kubernetes Namespaces 'N'

So What is Kubernetes Namespace?

With the help of Namespaces, each cluster is divided into virtual sub-clusters.

Each team can work in a Namespace without disturbing others.
An application and its dependencies are stored in Namespaces in a cluster.

These Namespaces are separate from each other
but are allowed to communicate with each other.

It's Namespaces that allow projects and team members to share a cluster.

Let us understand this by comparing how things have changed
and how these technologies are evolving

The process by which application development takes place.

Earlier resource allocation was a problem. An application consumes a lot of resources

This causes other applications to underperform. Organizations cannot afford to deploy multiple physical servers.

Virtualization and Containers

This is where the concept of virtualization came into the picture and
provided a viable solution to the above problem.

With the help of virtualization software, it is possible to run multiple virtual machines on a single CPU.

This has saved organizations from the additional costs of purchasing and maintaining additional hardware.

Virtualization also provides scalability as resources can be added or removed at any time without disturbing other VMs.

It also demonstrated improved security as the VM was not accessed by other VMs.

This is the age of Kubernetes, where containers simplify application development and make the whole process much simpler.

These containers are similar to virtual machines but are lighter.

They relax discrete features as they can be shared across multiple os, have their own CPU space, memory, etc.,
and they are isolated from their respective infrastructure.

Types of Kubernetes Namespaces

While writing this blog (Oct 3/ 2022) Kubernetes has four Namespaces, this may change in future

default

it has a default Namespace for objects that have no other Namespace.

Pod
Services
Deployment...

kube-system

Namespace for Kubernetes system-derived objects.

Kube-DNS
Holds master process
kubectl process

kube-public

This Namespace is used for resources that should be publicly available to all users.

Cluster-info
ConfigMap

kube-nodelease

Used to track the health of the node

Allocated to each node(object)

Default Namespace

This is a Namespace automatically created by Kubernetes.
This Namespace includes pods, services, and deployment
Can be accessed by every user (even unauthenticated ones).

Viewing Namespaces

You can see your current Namespaces using the following command:

kubectl get namespaces

This lists your current Namespaces, their status, etc.

Command to get more info about a particular Namespace

Get Kubectl Namespaces

We can also get a detailed description of a specific Namespace by using the following command:

Kubectl describes the Namespace

Description Shows resource quota (if specified) and resource range, a resource quota shows the total resources a Namespace can use, and the resource range shows the minimum or maximum resources that can be consumed.

It also shows whether the Namespace is active or terminating. These are the two designations of any Namespace.

The active Namespace is in current use, while the terminating Namespace is being dropped and is no longer in use.

Creating a New Namespace

We can create a new Namespace in two ways:

Imperative way

Simply run the command:

kubectl create Namespace

Declarative way

We can also create a YAML file with the following contents:

Newspace.yaml:

kind: Namespace
apiVersion: v1
metadata:
name: newspace
labels:
name: newspace

kubectl apply-f newspace.yaml

It is easy to create a new Namespace.

How to share a cluster with Namespaces?

A Namespace allows teams to share a Kubernetes cluster
it allows you to create Virtual cluster's inside the existing cluster

Although your current environment is not changed to your new namespace it's time-consuming and also not efficient to type --namespace with kubectl command

Let's see a simple hack, how you can switch your current default Namespace to your preferred Namespace

Hack to switch between Namespaces

The command to view Namespaces

kubens

To switch Namespaces

kubens newspace

That's it, now all your commands only work within your newspace Namespace

How to switch back, it's so simple

kubens default

Deleting a Namespace

Delete any particular Namespace by using this command:

Kubectl delete Namespace

After the command is executed, Namespace will pop up a “Terminating” status for a while.

Congratulations Now, you can create, view, or delete Namespaces.

Why Should You Use Kubernetes Namespaces?

it's time to understand why Kubernetes Namespaces are crucial and what are their advantages:

A Namespace is used by a specific team, which increases the sense of accountability through better role-based access control.

Namespaces allow teams to work in their respective bubbles without interfering with and disrupting others.

With Namespaces, it is possible to carry out the development, testing, and production of applications in different containers.

A resource quota divides the number of resources that users and teams can use.

Using multiple Namespaces

In smaller organizations, where development, testing, and production teams work side by side, the default Namespace is sufficient.

Development and testing do not require isolation and, therefore, can work with a single default Namespace.

But if the team is large or expanding day by day, multiple Namespaces will be required.

Use-case of multiple Namespaces

Development and testing can be clustered as one team, and production can be isolated so that any changes made by development and testing do not affect production.

Throughout the entire lifecycle of the application, both teams can work in their respective Namespaces.

Thank you for reading my blog. If you like my work feel free to connect me on LinkedIn or Twitter, see you with another one guys.

Understanding Kubernetes Deployments

Krishnamohan Yerrabilli — Sun, 16 Oct 2022 04:08:56 +0000

Kubernetes deployments:

Kubernetes deployments provide information about the characteristics of a particular application or server to the orchestration operating system. Kubernetes deployments serve as pointers to how Kubernetes servers should deploy and develop pods.

Why should we use Kubernetes deployments?

Developing applications is very risky when you are not using a stable and compatible platform. With a stable orchestration platform like Kubernetes, application development becomes more effortless.

In Kubernetes applications, small changes and transformations are required to improve customer satisfaction. Implementing small and less important changes repeatedly can be a challenge for developers. Through Kubernetes deployments, you can make small and simple changes to your Kubernetes applications.

Once you start using Kubernetes deployments, you will rarely experience connectivity failures and server downtimes. With Kubernetes deployments, it is possible to consistently and effectively monitor server health. Kubernetes deployments make scaling and running containerized applications seamless and effortless.

Most of the Kubernetes functions are automated, k8s automated tasks depend on the Kubernetes deployment. Deploying pods into Kubernetes clusters can also be automated and you don't have to worry about deploying pods on time.

Manual deployments are often time-consuming and tedious, while automated deployments are more error-free and faster.

On top of all of the above, Kubernetes deployments ensure that your pods are running successfully. Furthermore, Kubernetes deployments ensure that your pods and deployments are running on Kubernetes nodes.

These are the advantages you can get when you use Kubernetes deployments to manage application development.

Use cases:

Kubernetes extensions are often used by developers to expose new states of Kubernetes pods. Updating

PodTemplateSec allows you to update the new states of your existing pods with Kubernetes deployments.

This process revolves around transferring pods from an existing replicaset to the created replicaset. Each time you create a new ReplicaSet, the ReplicaSet comes with updated versions of the pods.

Kubernetes deployments are used for new replicaset roles. Pods are generated as background tasks when a new replicaset is created.

Many Kubernetes deployments handle redundant workloads in Kubernetes clusters. Furthermore, Kubernetes deployments allow you to switch back to previous versions whenever you want.

You can also delete replicasets using Kubernetes deployments.

Additionally, PodTemplateSec issues that arise when you pause deployment in your Kubernetes cluster can be easily resolved with the help of Kubernetes Deployment.

You have the opportunity to track the progress of the application development process that you started with deployments.

In short, Kubernetes deployments can greatly improve your user experience and help you use your pods and containers efficiently.

A recreated strategy

This deployment method involves replacing existing pods with new pods. In this strategy, you must delete the old pods in your Kubernetes cluster before deploying the new ones.

You can deploy new pods and run them immediately after deleting old pods. When you choose this deployment strategy, you cannot run old pods and new pods simultaneously in your Kubernetes cluster.

Blue/green strategy

This deployment strategy is the exact opposite of the reinvented deployment strategy. In this manner, you can deploy new pods into your cluster when your cluster has old and outdated pods. Due to this unique feature, this deployment strategy is friendly to switch back to old pods if you face any discomfort with the newly deployed pods.

These Kubernetes deployment strategies are widely used to deploy, monitor, or customize Kubernetes pods. Apart from these, Canary deployment and A/B testing deployment strategies are also practiced.

Canary strategy

Canary deployment is used to allow a subset of users to test a new version of an application or when you are not completely confident in the new version's functionality.

This involves running the new version of the application alongside the old version with the old version of the application serving a large number of users and the new version serving a small group of test users. If the new strategy is successful it will be rolled out to more users.

That's it, if you want to learn more about deployments, you can check out here

Thank you for reading my blog. If you like my work feel free to connect me on LinkedIn or Twitter, see you with another one guys, have a great day.

Blue/Green Deployments

Krishnamohan Yerrabilli — Wed, 05 Oct 2022 02:30:41 +0000

Introduction

A blue/green deployment involves deploying the new application version (green) alongside the old (blue).

A load balancer in the form of a Service Selector object is used to test and redirect traffic to
the new application (green) instead of the old one when verified.

Blue/Green deployments can prove costly due to the need to sustain twice the amount of application resources for the duration of the deployment.

To start this, we set up a service that sits in front of deployments.

For example, the service selector section of the manifest file for a blue deployment for an app called web-app with v1.0.0 looks like this:

Type: Service
Metadata:
 Name: web-app-01
 Labels:
   App: Web-app
Selector:
   App: Web-app
   Version: v1.0.0

And the deployment for Blue Web App:

Type: Expansion
Metadata:
  Name: web-app-01
Specification:
  Template:
        Metadata:
           Labels:
             App: Web-app
             Version: "v1.0.0"

When we want to redirect traffic to the new (green) version of the app,

we update the deployment file to point to the new version v2.0.0.

Type: Service
Metadata:
 Name: web-app-02
 Labels:
   App: Web-app
Selector:
   App: Web-app
   Version: v2.0.0

Expansion for Green App:

Type: Expansion
Metadata:
  Name: web-app-02
Specification:
  Template:
        Metadata:
           Labels:
             App: Web-app
             Version: "v2.0.0"

Thank you for reading my blog. If you like my work feel free to connect me on LinkedIn or Twitter, see you with another one guys.

Kubernetes Networking for beginners (part 1)

Krishnamohan Yerrabilli — Tue, 27 Sep 2022 02:33:33 +0000

Introduction

Networking is one of the most important topics in kubernetes and it was was created to run distributed systems over a cluster of machines. Distributed systems make networking a central and necessary component of implementation, because of this it's crusial to understand how kubernetes facilitates communication inside of the cluster and how external traffic interact with k8s eco-system, I'll make you understand how this things possible with 11-indepth diagrams, before we dive in we want to have a good understanding of networking terminologies.

Basic terminologies

IP address

It is an 4 decimals number separated by periods, for example it's look this 142.250.192.132/24, it is by default whatever device or any other network capable system will be assigned an Ip address from the network provider such as ISP(Internet service provider(jio/airtel/ACT fiber)), the ip is used to find out a particular device in the network either it's a LAN/WAN

Port number

Ok we got the information we needed from the internet to the device we are using, but how the device(kernel) knows which application is requesting this particular information, this is were PORT numbers comes into play, there are set of port numbers are designated to each and every application, for example you're google chrome has a different port number, your database has different port number, whatsapp has a different port and so on, and that's how kernel knows what is the right application is requesting this info and sends it, one quick note you maybe heard about sockets, so what are those, its is your ( IP + port number ) called as socket.

MAC address

Technically called as Media Access Control its a 12 digit hexa-decimal number, and it is tied to the Network Interface Controller (NIC) and it is a sub component of larger device called as NIC(Network Interface Card) this were you connect the internet from like you plugin a ethernet cable, wifi or any other interface, it is fixed to your physical machine, and it is unique to every device in the world.

Router

A router is a mediator between a intranet(inner network) such as organisational network and a outer network such as internet(collection of inter-connected computers), router seats between this two of those
while taking the user request and forward to the appropriate DNS server and get the response back to the client to serve the request

ARP server

Imagine you have 10 devices connected to your network from the help of your router, whenever a packet comes from outer network(WAN) to LAN, how the router knows what's is the appropriate device to send this packet, this is where ARP (Address resoultion protocol ) comes into picture it is a procedure which powers the internet from the early 1980's, it is basically a translator which maps your IP address to MAC address of your machine

It stores all mac address of its Network such as LAN or you're home network, whenever the router needs MAC address the router makes a request to the ARP server to get the MAC address, and the ARP gives the response back to the router, and then the router knows which device is requesting the information.

DNS Server

Computers doesn't understand human languages they only knows numbers, in a high level context Domain name system is a server that maintains all domain address and their IP address, for example domain name is (www.google.com) and it's assigned a IP address (142.250.205.228) this two are stored in the DNS server, Whenever a user or a host requsts a service from a domain, this requests forward to DNS so it can find the right IP address which is then the request goes to the right server, try to paste the above ip address in search bar and see the magic

Kubernetes ReplicaSet

Krishnamohan Yerrabilli — Sat, 24 Sep 2022 10:09:09 +0000

Table of contents

What is a Replicaset?
Which problem it solves?
What is an object?
What is a resource?
The Anatomy of a ReplicaSet Manifest
How to scale up/down?
- Scaling down
- Scaling up
How to delete replicaset?
How to delete replicaset without deleting pods

😃 In the journey of learning Kubernetes you come up to Replicasets, what does it mean? why we're using it? and where do we use it? I'll try to clear some of the doubts that come up to you as a newbie, Let's see what it is all about, and what's the role it plays inthe world of Kubernetes

A Replicaset simply means, it replicates pods, like you can have an n number of pods,1 replica means it controls one pod, under the hood of a replicaset there is a central important concept called labels, let's see in detail what it is all about and explore what exactly replicaset means, and its use cases...

which problem it solves?

It automatically replicates and it makes sure a certain number of pods run all the time as you mentioned in your manifest file.

Before we dive in we want to understand some terms

What is an object?

simply an object is a design model only we use for a specific purpose there are many objects in Kubernetes

What is a resource?

In simple terms, a resource is a collection of objects for that specific resource

(pod) -> this is an object
(pods) -> this is an endpoint, in this case, it stores the collection of pods

Let's see what are the different resources available, there is a command for this

kubectl api-resources

NAME                              SHORTNAMES   APIVERSION                             NAMESPACED   KIND
bindings                                       v1                                     true         Binding
componentstatuses                 cs           v1                                     false        ComponentStatus
configmaps                        cm           v1                                     true         ConfigMap
endpoints                         ep           v1                                     true         Endpoints
events                            ev           v1                                     true         Event
limitranges                       limits       v1                                     true         LimitRange
namespaces                        ns           v1                                     false        Namespace
nodes                             no           v1                                     false        Node
persistentvolumeclaims            pvc          v1                                     true         PersistentVolumeClaim
persistentvolumes                 pv           v1                                     false        PersistentVolume
pods                              po           v1                                     true         Pod
podtemplates                                   v1                                     true         PodTemplate
replicationcontrollers            rc           v1                                     true         ReplicationController
resourcequotas                    quota        v1                                     true         ResourceQuota
secrets                                        v1                                     true         Secret
serviceaccounts                   sa           v1                                     true         ServiceAccount
services                          svc          v1                                     true         Service
mutatingwebhookconfigurations                  admissionregistration.k8s.io/v1        false        MutatingWebhookConfiguration
validatingwebhookconfigurations                admissionregistration.k8s.io/v1        false        ValidatingWebhookConfiguration
customresourcedefinitions         crd,crds     apiextensions.k8s.io/v1                false        CustomResourceDefinition
apiservices                                    apiregistration.k8s.io/v1              false        APIService
controllerrevisions                            apps/v1                                true         ControllerRevision
daemonsets                        ds           apps/v1                                true         DaemonSet
deployments                       deploy       apps/v1                                true         Deployment
replicasets                       rs           apps/v1                                true         ReplicaSet
statefulsets                      sts          apps/v1                                true         StatefulSet
tokenreviews                                   authentication.k8s.io/v1               false        TokenReview
localsubjectaccessreviews                      authorization.k8s.io/v1                true         LocalSubjectAccessReview
selfsubjectaccessreviews                       authorization.k8s.io/v1                false        SelfSubjectAccessReview
selfsubjectrulesreviews                        authorization.k8s.io/v1                false        SelfSubjectRulesReview
subjectaccessreviews                           authorization.k8s.io/v1                false        SubjectAccessReview
horizontalpodautoscalers          hpa          autoscaling/v2                         true         HorizontalPodAutoscaler
cronjobs                          cj           batch/v1                               true         CronJob
jobs                                           batch/v1                               true         Job
certificatesigningrequests        csr          certificates.k8s.io/v1                 false        CertificateSigningRequest
leases                                         coordination.k8s.io/v1                 true         Lease
bgpconfigurations                              crd.projectcalico.org/v1               false        BGPConfiguration
bgppeers                                       crd.projectcalico.org/v1               false        BGPPeer
blockaffinities                                crd.projectcalico.org/v1               false        BlockAffinity
caliconodestatuses                             crd.projectcalico.org/v1               false        CalicoNodeStatus
clusterinformations                            crd.projectcalico.org/v1               false        ClusterInformation
felixconfigurations

These are some of the resources and types of objects you can see

Now let's understand the replica set with an example

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # modify replicas according to your case
  replicas: 4
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend  
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

The Anatomy of a ReplicaSet Manifest

Let's understand what is going inside (step by step)

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend

There are some resources you want to mention always in you're manifest file such as apiVersion, kind, metadata, spec

apiVersion: this simply means which API version you're using to create the object

kind: This just means, what kind of object you're creating, in this case, it is Replicaset

plz note: what you're providing as an object, that is the desired state and that is what you're workload is going to be

metadata: this is a piece of additional information to identify you're workload, in this case, your workload is a replica set

metadata.name(name: frontend) -> you object name in the cluster
metadata.labels(labels app: guestbook tier: frontend) -> this is like a tag to the replicaset we can see details of the replicaset by using those labels

labels are most important in Replicaset more info coming below

spec:
  # modify replicas according to your case
  replicas: 4
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend

spec: refers to specs of replicaset

replicas: how many pods(Instances) want to be created by the replica set

selector: here selector is the thing, the replicaset takes it, and checks the same label to identify what are the pods it wants to control.

you want to make sure (selector.matchLabels.tier: frontend)-> this tier: frontend
taken as a reference by replicaset to check the pod == (template.metadata.labels.tier: frontend)

-> this tag is attached to each pod, this just wants to be the same, then only rs knows what
are the pods it wants to checkout.

template: above we mentioned 4 replicas which means the same number of pods are created by the replica set, when pods are made this is taken as reference by the replica set to create new pods

don't think replicaset means just creating replicas, that's not the main view, it replicates or re-create pods if anyone one of them dies, but how replicaset is identifying its designated pods

just by matching the selector.tier tag to the template.tier tag

How to scale up/down?

There are 2 ways to scale up or scale down the pods, one is modifying the manifest another is just by giving a command:

Scaling down this is how you do it

$ kubectl get rs
NAME       DESIRED   CURRENT   READY   AGE
frontend   4         4         4       19s
$ kubectl scale --replicas=2 rs frontend
replicaset.apps/frontend scaled
$ kubectl get rs
NAME       DESIRED   CURRENT   READY   AGE
frontend   2         2         2       23s

Scaling up this is how you do it

$ kubectl get rs
NAME       DESIRED   CURRENT   READY   AGE
frontend   2         2         0       32s
$ kubectl scale --replicas=6 rs frontend
replicaset.apps/frontend scaled
$ kubectl get rs
NAME       DESIRED   CURRENT   READY   AGE
frontend   6         6         6       45s

Removing replicaset from the cluster

How to delete replicaset?

kubectl delete rs frontend

How to delete replicaset without deleting pods?

kubectl delete rs frontend --cascade=orphan

I hope you find this helpful for your journey, Thank you for reading my blog. If you like my work feel free to connect on LinkedIn or Twitter, see you with another one guys. 😀

An overview of kubernetes pods

Krishnamohan Yerrabilli — Thu, 22 Sep 2022 06:22:21 +0000

what is a pod?

A pod is like a smallest cookie_box in the kubernetes world
A container is like a cookie which is stored inside the cookie_box(pod)
It is the foundational concept in the k8's all other objects(cookie_box) models are based on the pod

what is pod deployment?

when we intially setup a pod, we give this specifications from a file called (manifest(a set of desired state which is wanted by the user))
step1: file handed from kubectl API to the Masternode(control plane) API server
step2: file stored to etcd
step3: schedular find nodes which are this pods suitable to fit in
step4: schedular assign a pod to the node
step5: the status of schedular assigned node will give back to the (Master node)API server from the schedular
step6: now kubectl hand the instructions to over to the CRI(container runtime interface)
step7: image is pulled from the registry(OCI image spec) only if OCI req fulfilled
step8: this transportaion of image will from the registry has also a OCI called (Open Container Intiative
distribution spec)
step9: the pod is hosted inside worker node which holds (runtime+pod+container)
step10: now runc(main runtime (OCI runtime spec)) holds 2 things one is image repo(collection of image
layers) and second one is directory, which holds the image
step 11: after a clone() system call has been performed by the runc that forward to the linux kernel
kernel creates all new_name_spaces(they are 7 of them still counting) to form an individual isolated container(don't confuse with docker containers) all this container engines like (rkt,docker,crio) they just perform operations required to forward the manifest spec and other details to the kernel, real containers are created by only, only from linux
This is just an overview of the whole container creation process, as you go forward I will state each detail on
what's happening internally

Multi container

A pod consists can consists of many contianers, if we do that then we're violating one process(container) for one pod, but we want to use in some cases like (what if we want to store logs, the second (helper)container is responsible to perform file synchronization, logging, and watcher capabilities and it also called as sidecar), we can deploy two containers from the manifest file

Pod Networking

Pod networking is happens, where when two pods want to talk to each other, this done by pod Networking, this is performed by individual pod IP, the pod networking takes place using this IP(back&forth) communication takes place

intra-pod networking

intially when pod was created the first container in the pod is called as pause container(which holds the
cluster IP) for expose traffic to outside world
When helper container and main container want to talk to each other they use IPC(inter process communication
(name space) by through a message Queue) each containers communicate locally, they share same IP from the pod IP but
with different ports

pod-lifecycle

as all objects on this earth has lifecycle, pod also has a lifecyle, If we see this from high level POV
it has 3 stages
pending, running, succeesful
there also we have a stage called falied, when pod was at (pending, running) it has a chance it may also
fails to create pod because of the invalid format, invalid image, maybe it doesn't full filling CRI runtime spec, and other reasons...