Kubernetes : Pod Communications, Deployments and ReplicaSets

Lets start with the second blog on K8s where I will discuss on basics of pod communications and Deployments. You can read the previous blog to get an idea about K8s basics and details on pod.

Pod Communications

pod communication

Here, in the above diagram, you can see two pods - 

  • Pod A (IP - 10.0.1.16) with two containers - Con1 ( port - 8000) and Con2 ( port - 6000 ).
  • Pod B (IP - 10.2.2.100) with container - Con1 ( port - 8087).

Inter Pod Communication

For a moment, consider Pod B container Con1 is trying to access both the containers of Pod A.This has to be done accessing the host and port - 10.0.1.16:8000 and 10.0.1.16:6000 to access Con1 and Con2 respectively in Pod A. Likewise, in order to access Con1 in Pod B, host and port - 10.2.2.100:8087 needs to accessed. This is how Inter Pod Communication occurs.

Intra Pod Communication

Now consider the scenario where in Pod A, Con1 tries to communicate with Con2.This can be done using the hostname as localhost and port as corresponding container port exposed.

Usage of Multi-Container pods

The primary purpose is to co-locate and co-manage helper process for another primary application.
  • Sidecar Containers - They assist the main application container. Log watcher and shippers, monitoring agents, etc. are typical Sidecar containers.

  • Bridges, Adapters, Proxies - They connect the main container with the outside world. Examples - Apache HTTP server, NodeJS server, Nginx server, etc.

Deployments and ReplicaSet

Deployment and ReplicaSet are used to manage and run specific configuration related to Pod. Lets discuss in details.

Deployment

As per Kubernetes documentation,

"A Deployment provides declarative updates for Pods and ReplicaSets."

What does it actually mean ?

Well, Deployment is a way of deploying a pod or sets of identical pods ( ReplicaSets ) where their desired states are mentioned in a configuration/manifest file. The Deployment Controller, that resides inside Control Plane, takes control and tries to change from actual state to the desired state in a controlled fashion and tries to maintain it.

deployment

Let us consider the below Deployment manifest file named deployment.yaml - 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx

spec:
# modify replicas according to your case 
  replicas: 3 

  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
         - containerPort: 80

Once we execute -  kubectl apply -f deployment.yaml



There will be a set of 3 pods created with each containing an nginx container exposed at port 80. If a pod dies or get deleted accidently, the Deployment Controller will bring up another pod to maintain the total number of pods as 3. You can also achieve this with ReplicaSet object.


ReplicaSet

A ReplicaSet ensures that a specified number of pod replicas are running at any given time. However, a Deployment is a higher-level concept that manages ReplicaSets and provides declarative updates to Pods along with a lot of other useful features.

Let us consider the below ReplicaSet manifest file named rs.yaml - 

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

Once we execute -  kubectl apply -f rs.yaml , a set of 3 pods with single containers in each is created.

Therefore, a ReplicaSet, like Deployment, ensures that a specified number of pod replicas are running at any given time. However, a Deployment is a higher-level concept that manages ReplicaSets and provides declarative updates to Pods along with a lot of other useful features. Hence, Deployment is preffered over ReplicaSet.



I would be concluding this blog over here, will continue my discussion on Kubernetes components in further blogs.



Comments

Popular posts from this blog

Kubernetes: A Synopsis and Introduction

Handle errors in Amazon API Gateway from integrated Lambda functions