Finally clarified with PODs in Kubernetes
- What is POD?
- How PODs are deployed in Kubernetes?
- What instances we will use in multiple containers in single POD?
- How does POD networking works?
- Inter-POD networking and Intra-POD networking?
- POD Life Cycle.
1.What is POD?
- Atomic unit of scheduling in Kubernetes world.
- So, when we get into the watch vitalization world the atomic unit of scheduling is virtual machine.
- If you want to deploy any app then you need to put your code and related config in so the virtual machine and then deployed.
- Next, when it comes to the containerization world generally we use containers and in the same way we use POD in Kubernetes.
- So, at a high-level POD is a basic unit of scheduling in Kubernetes.
To deploy the part, we generally write the POD manifest file which consists of container images that we can deploy and submit to the API sever on the master node.
After that API server and scheduler components in the master node besides and deploys this PODs on appropriate worker nodes.
As you can see inside each POD there is one container in our deployment.
Our ultimate aim is to deploy our app in the form of containers that are distributed across a set of worker nodes instead the Kubernetes cluster however Kubernetes does not deploy containers directly on the worker nodes.
Instead containers are encapsulated inside a POD, as you can see there are three instances of the same app running on work nodes.
As the time passes users accessing the web app increases and then we need to scale the app as a demand goes up.
Now you need to add additional instances of your web app to share the load.
So, the question here is how do you scale this app now?
If you are thinking adding new container within the same POD, then answer is No. That's not how we do it.
We create new POD all together with the same app instance as you can see we just deployed five new instances of our web app running on five separate PODs on same Kubernetes system.
The second question is what if the number of users accessing the web app further increases and your current Node has no enough capacity.
Well then, it's time to spin up a new VM and join that new worker node to the cluster.
Once it is ready Kubernetes will start deploying PODs onto this new node from this.
There are two takeaway points.
- Typically, there will be minimum one container per POD.
- To scale up the app we need to create more POD instances.
3. Multi-Container POD:
We talked about having one to one relationship between PODs and containers, but it is possible to have two or more containers inside a single POD and which is a rare scenario. And this is called multi container POD.
If not, then what?
Sometimes you'll come across a scenario where you have a helper container that might be doing some kind of a supporting test for our main web app.
such as processing a user enter data or processing your file uploaded by user or etc. You want this helper container to live along the side of app container so in that case you can have both of these containers part of same POD.
so that when a new app container is created the helper continues also created in the same case when the app container dies then the help container also dies because they are POD of same POD. So. these two containers can also communicate with each other directly by referencing using a local host because they share the same network namespace.
Plus, they can also easily share the storage space as well. However multiple containers are a real use case.
Pod Networking:
Now let's discuss about the POD networking.
As you can see in this diagram we are having two PODs. POD 1 and POD 2.
If you are running worker node inside the cluster. POD 1 has two containers and POD 2 has just one container for simplicity purpose.
if you observe this diagram you will notice something new in this diagram if your answer is PODs IP address then you're right.
Every nodes inside Kubernetes cluster has it's unique IP Address. Which is called as node IP address. But in Kubernetes there is one additional IP address of each POD which is called as POD IP address.
So, if you look at the example we got here we got two PODs.
Two IP addresses and we have one IP per POD so how are these containers inside POD communicate with outside world and there is something called as network namespace.
All these containers inside of POD operate within that same network namespace as a POD which means all these containers inside the POD will have the same IP address but this should be one distinct thing which will make the unique way to identify the each of this container.
That's where the ports come in as you can see the main container in the POD 1 has a port 8080.
So, it can be access using the POD IP and the port number 8080.
Similarly supporting container in POD 1 can access using the same POD IP and the port number 3000 since these two containers are part of POD 1. So, the IPs are same.
Now to access the container inside POD 2 we use a POD 2 IP address and the port number of the container.
So that's how we access the applications deployed inside the containers and PODs are access to from the outside world in Kubernetes.
One last thing to clarify,
The containers within same POD not only just shared the same IP address but it will also share the access to the same volumes, same C group limits and even same IPC names and that is something very important to note.
Inter-Pod Communication:
We will see how one POD talks to another POD which is called as Inter POD communication.
Inter-POD communication is simple.
That's because all the POD IP addresses are fully routable on the POD network inside the Kubernetes cluster.
We have seen installing port network plug in which is called as a flannel and we have used the sider IP ranges to create POD network.
once we done with that step every PODs gets its own IP address that's routable within that cluster this means every POD can directly talk with every other POD and there is no need to mess with any port mapping or anything.
Intra-POD Communication:
How to more container can communicate within the same POD as called as Intra-POD Communications.
We have already discussed where we have two and more container within the same POD and how do they talk to outside world. But we have not yet discussed how do they communicate within the same POD.
Inside POD if you got multiple container in there they all talk over with help of shared local host. So, all container can directly communicate with each other's ports via local host.
Within POD they all share same IP address and the network name space.
Obesely if you got two containers inside a POD then both can not choose the same port number.
POD Life Cycle:
First, we defined POD configuration inside the POD manifest file in YAML or JSON format. Mostly we use YAML file. After we submit manifest file at the API server on Kubernetes master. Once it will be done. it will get schedule out on the worker node inside the Kubernetes cluster.
Once that will schedule it goes in to the Pending State. So, During the Pending state node will download all container images and starts running the containers. It stays in Pending state until all containers are up and running. Once it done it goes in Running State.
One more stage where the POD gets in failed state. That happen when POD is in Pending state.
If for some reasons it is not getting state, the POD will be moved in Failed State.
One Last thing, when POD dies it dies we can't bring back from dead. If it dies replace with new POD. Old one is gone and new will be same configurations, but it has different ID and different IP.
How to write POD manifest file?
POD configuration inside the POD manifest file in YAML or JSON format. Mostly we use YAML file because it easy to understand. So, we will use YAML file for reference.
Most of the Kubernetes objects consists of for top level required fields.
They are apiVersion, kind, metadata, spec.
API Version:
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
labels:
app: nginx
tier: dev
spec:
containers:
- name: nginx-container
image: nginx
POD – Create & Display:
# Create POD from YAML file
$ kubectl create -f nginx-pod_sample.yaml
pod/nginx-pod created
# To get list of running POD with status
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-pod 1/1 Running 0 94s
# To get list of running POD with IP addresses along with running node
$ kubectl get pod nginx-pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-pod 1/1 Running 0 4m45s 172.18.0.4 minikube <none> <none>
# Display information's YAML format
$ kubectl get pod -o nginx-pod yaml
apiVersion: v1
items:
- apiVersion: v1
kind: Pod
metadata:
………………………………
POD Describe:
# Display all details and events of a pod
$ kubectl describe pod nginx-pod
Name: nginx-pod
Namespace: default
Priority: 0
Node: minikube/172.17.0.74
Start Time: Thu, 14 Nov 2019 07:40:43 +0000
Labels: app=nginx
tier=dev
Annotations: <none>
Status: Running
IP: 172.18.0.4
Containers:
………………………….
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 12m default-scheduler Successfully assigned default/nginx-pod to minikube
Normal Pulling 12m kubelet, minikube Pulling image "nginx"
Normal Pulled 12m kubelet, minikube Successfully pulled image "nginx"
Normal Created 12m kubelet, minikube Created container nginx-container
Normal Started 12m kubelet, minikube Started container nginx-container
POD – Testing:
#Pinging Container IP from master.
#Get IP of POD using command (kubectl get pod nginx-pod -o wide)
$ kubectl get pod nginx-pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-pod 1/1 Running 0 17m 172.18.0.4 minikube <none> <none>
$ ping 172.18.0.4
PING 172.18.0.4 (172.18.0.4) 56(84) bytes of data.
64 bytes from 172.18.0.4: icmp_seq=1 ttl=64 time=0.124 ms
64 bytes from 172.18.0.4: icmp_seq=2 ttl=64 time=0.070 ms
64 bytes from 172.18.0.4: icmp_seq=3 ttl=64 time=0.070 ms
64 bytes from 172.18.0.4: icmp_seq=4 ttl=64 time=0.060 ms
^C
--- 172.18.0.4 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3060ms
rtt min/avg/max/mdev = 0.060/0.081/0.124/0.025 ms
Login inside the container which is running inside POD:
$ kubectl exec -it nginx-pod /bin/sh
# hostname
nginx-pod
# exit
command terminated with exit code 127
Delete POD:
$ kubectl delete pod nginx-pod
pod "nginx-pod" deleted
Comments
Post a Comment