Pods as the unit of scaling Pods are also the minimum unit of scheduling in Kubernetes.
If you need
to scale an app, you add or remove Pods. You do not scale by adding more containers to existing
Pods. Multi-container Pods are only for situations where two different, but complimentary,
containers need to share resources. Figure 2.10 shows how to scale the nginx front-end of an app
using Pods as the unit of scaling.
Multi-container Pods are ideal when you have requirements for tightly coupled containers that may
need to share memory and storage. However, if you don’t need to tightly couple containers, you
should put them in their own Pods and loosely couple them over the network. This keeps things
clean by having each Pod dedicated to a single task. However, it creates a lot of potentially un-
encrypted network traffic. You should seriously consider using a service mesh to secure traffic
between Pods and application services.
Pod lifecycle Pods are mortal. They’re created, they live, and they die. If they die unexpectedly, you
don’t bring them back to life. Instead, Kubernetes starts a new one in its place. However, even
though the new Pod looks, smells, and feels like the old one, it isn’t. It’s a shiny new Pod with a shiny
new ID and IP address. This has implications on how you design your applications. Don’t design them
to be tightly coupled to a particular instance of a Pod. Instead, design them so that when Pods fail, a
totally new one (with a new ID and IP address) can pop up somewhere else in the cluster and
seamlessly take its place.
Pod immutability Pods are also immutable – this means you don’t change them once they’re
running. Once a Pod is running, you never change its configuration. If you need to change or update
it, you replace it with a new one running the new configuration. When we’ve talked about updating
Pods, we’ve really meant delete the old one and replace it with a new one
Pod immutability Pods are also immutable – this means you don’t change them once they’re
running. Once a Pod is running, you never change its configuration. If you need to change or update
it, you replace it with a new one running the new configuration. When we’ve talked about updating
Pods, we’ve really meant delete the old one and replace it with a new one
In the following diagram, you can see cube-like structures they are called containers each of the
containers will have one container. The cylinder-like structure is called volume where the data of the
containers will be stored and the circles are called pods. The pods are the smallest unit in
recognizable unit in Kubernetes that is the reason where Kubernetes will take care of the pods and
pods will take care of the containers.
Introduction to Kubernetes Pods: The Building Blocks of
Your Microservices
A pod in a Kubernetes cluster indicates a process that is currently operating, and a pod may
contain one or more containers. All of those containers share a single IP address, as well as
the pod’s storage, network, and any other requirements. A pod is a collection of one or more
running containers, allowing for simple container movement within a cluster.
The creation of a pod is due to a workload resource called controller, which means rollout,
replicate, and health of the pods present in a cluster. If we consider that a node in a cluster
fails then a controller detects that the pod on the mode is unresponsive and then replicates a
pod or pods on other nodes to carry out the same function. The three mostly used controllers
used are Jobs, Deployments, and Stateful Sets. Jobs are used for batch-type jobs that are
mostly ephemeral and will run a task to completion. Deployments are used for applications
that are stateless and persistent, for example, web services. StatefulSets is used for
applications that are both stateful and Persistent like a database.
If any pod has any/multiple containers then all those are scheduled together on the same
server in the cluster either a physical server or VM. All the containers present in the pods will
share their resources and dependencies. All these clusters can coordinate their termination
and execution. For instance, if a pod contains an init container then it runs before the
application container runs leveling or setting up the required environment for applications to
follow. Generally, pods are created by controllers that can automatically manage the pod
lifecycle. The pod life cycle included replacing failed pods, replicating the pods when
necessary, and eliminating the pod once the purpose was completed. Controllers use the
information present in the pod templates to create the pods.
How do Kubernetes Pods Communicate With Each
Other?
The creation of a pod has made it easy for communication between various components. If a
pod contains multiple containers then they can communicate with each other by using a local
host. Communication with outside pods can be made by exposing a pod. Communication
within the clusters of the same pod is easy because Kubernetes assign a cluster private IP
address to each pod in a cluster.
What is Nginx?
It is open-source software designed for maximum performance and stability. Let’s see
basically why we need it basically see how we can benefit from this.
What is Nginx (Web Server)
Using Kubernets Pods
Let’s create a YAML file for an example image (Nginx) so that it can be deployed as a
container.
apiVersion: v1
Kind: pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image:
nginx:latest
ports:
- containers: 80
After creating the yaml file run the below command to deploy it as a container.
kubectl apply -f <name of yaml file>
[Link] Networking
Pod-to-pod communication
ClusterIP: It is the default service and its visibility is cluster internal which means it’s not
possible to use clusterIP service to reach a micro-service from the internet from outside the
[Link] can establish the connection inside the cluster between two pods.
2. Service Discovery
Kubernetes provide built in DNS for the service discovery. The particular service will
assigned to particular DNS based on their service names for example as shown below.
# Accessing a service from within a pod
curl [Link]
3. Ingress
Ingress controller will acts as an load balancer to the kubernetes cluster and also it will also
mange the external access to services within the cluster. Following the sample yaml file for
the ingress.
apiVersion: [Link]/v1
kind: Ingress
metadata:
name: <Name of the Ingress>
spec:
rules:
- host: [Link]
http:
paths:
- path: /path
pathType: Prefix
backend:
service:
name: <Name Of The Service>
port:
number: 80
Create Pod
$ kubectl create -f [FILENAME]
To Delete Kubernetes Pod
$ kubectl delete -f FILENAME