Kubernetes Deployment(controller) is your buddy if you want to deploy, update , maintain your hosted application on the production server without any downtime with utmost efficiency and with the required scalability and availability

Many times while working on your production server, you may encounter an instance where you would like to push a new update of your web application, while doing so it is desired not to break the running web app and to avoid any downtime. …

It is not only sufficient to have skilled individuals who know their job better, how these talented individuals communicate and help each other out as a team player which makes productive work happen, is what matters the most.

In a similar fashion, deploying different types of front-end and backend applications on the server is not sufficient, it is how these applications will exchange data with each other is what makes the client server-based ecosystem function effectively. …

Welcome to this brand new piece of working with Kubernetes series,

In the previous piece:

we discussed,

How one can allow any particular pod with a certain type of workload to be specifically scheduled on the particular Node, using the simplicity and power of nodeSelector.

Let’s revisit the example we discussed in the last piece:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: staging
spec:
  containers:
  - name: nginx
    image: nginx
    
  nodeSelector:
    size: large

Here we are trying to place our Pod, using nodeSelector key-value pair

size:large

In such a case, one thing which limits the node selector approach…

“If you stretch beyond your capacity without putting your wisdom into practice, you are bound to break ”

The same applies to our Kubernetes worker nodes. If you will try to schedule a heavy workload to the worker node of low capacity, there is a higher probability of this node filling fast and create inefficiency in the cluster. So as a Kubernetes administrator or developer what you should do?

To understand this scenario let me paint a visual picture of a hypothetical situation below:

In general life, we often develop an affinity with people whom we like and want to engage very often, similarly, in Kubernetes, we can establish a close affinity between nodes and pods.

If you want to ensure that only a few types of pods get accommodated in any given worker Node and repelling the other pods which you don’t want to be a part of the worker Node, you can use the concept of

“Taints & Tolerations ”

Let’s Understand with mosquito & human analogy:

Suppose you don’t want the mosquito to bite you, in that case, what do you do? …

“Choose your resources wisely else you will be thrown out ”

This is true for Kubernetes clusters with multiple nodes too. In our part 1 of handling resources and limits in Kubernetes:

We learned

• How to manage resource provisioning of the container in Kubernetes?
• How to define resource requests?
• How to define resource limits?
• How does the scheduler handle the resource provisioning?
• What happens if some pods or containers try to go beyond the specified resource limit defined in the pod definition?

So today we will go further to understand the few resource management scenarios given below :

• What happens…

Plant Analogy :

Any product and its management is somewhat similar to any growing plants which bear fruits. The fruit is a product and the person who grows it is a product manager.

It starts with finding fertile land(Finding the right market/target audience), adopting best seeding practices, planting seeds, nurturing it with the right kind of water and fertilizer, monitoring the growth, trimming the unwanted branches & leaves to keep it in the right shape(Improving product based on customer feedback), plucking the fruits as it comes on the way. Continuing the discipline of caring to help it bear new fruits. …

When it comes to architecting your system infrastructure requirements as a cloud architect or system architect, you need an efficient orchestrating tool to help you achieve the required flexibility and scalability. Kubernetes orchestration platform gives you this ability and simplifies your resource management process hassle-free.

What are the Node level resources in a Kubernetes cluster?

In any given cluster with multiple nodes, there are a defined set of resources in the form of

• CPU
• Memory
• Disk Spaces

CPU and memory are collectively referred to as compute resources, or just resources. These resources are measurable quantities that can be requested, allocated, and consumed.

Unit Of Resources Type:

Each of the above resource types has a…