Pods and Containers - Kubernetes Networking | Container Communication inside the Pod

in kubernetes the smallest unit or component is a pot and not a container and considering that pot always contains one main container for example you might have a pot with post Chris container or elasticsearch container or your own application some people may be asking why the need for abstracting the container with a pot if there is any way it's just one main application running inside so in this video I'm gonna explain to you why having a pot is an abstraction over container is such an important concept in kubernetes I'm gonna give you a comparison between pod and container and I will show you in which cases you would need to have multiple containers inside one pot and how these containers then will communicate with each other and its core kubernetes networking has one important fundamental concept which is that every pot has a unique IP address and that IP address is reachable from all the other pots in the cluster so that's the main concept now why is it important and valuable to have this pod component with its own IP address you see one main challenge on distributed infrastructure with multiple servers is how to allocate ports to services and applications running on servers without getting conflicts since obviously you can only allocate one port once on a single host with containers you would soon face this challenge because this is how container port mapping works let's say for example a PostgreSQL container where inside the container the Postgres application starts at port 5 4 3 2 now when you start containers directly on your machine what you do is you bind your host port to the application port in the container and you see that in practice we can start post-race docker container so this is the part where we map or we bind the port on the host to the port of the application running inside the docker container so it doesn't have to be the same port I can also give it a completely different one so let's write 5,000 and if I execute this command Postgres container started and if we check here with dr. PS I will see that port 5000 on the host machine is mapped to this one here so now the application is reachable by the host port now that I have one Postgres already running I could start another post-course container that will also run at the same port but bind it on a different port on my host so this will work as well so if I go here now and say dr. PS I will see two possible applications bound to different ports on the host and this is how containers work the problem with this is when you have hundreds of containers running on your servers how can you keep track of what ports are still free on the host to bind them so soon enough with this type of port allocation it will become difficult to have an overview and the way kubernetes solves this problem is by abstracting the containers using pots where pot is like its own small machine with its own IP address usually with one main container running inside for example you might have a pot where Postgres container is running when a pot is created on a node it gets its own network namespace and a virtual Ethernet connection to connect it to the underlying infrastructure network so a pot is a host just like your laptop both have IP addresses and a range of ports they can allocate to its containers this means you don't have to worry about port mappings on the server where pot is running and all inside the pot itself but since you anyways usually have just one main container or sometimes maybe maximum up to six containers inside a pot you won't get conflicts there because you have a pretty good overview of what containers are running inside this means that on one server you can have for example 10 micro service applications that all run on port 8080 inside 10 different pots and you won't have any conflicts because they all run on self-contained isolated machines which are pots so to also see that in practice I have a mini Q cluster running so I'm gonna create a pod that's gonna run a Postgres container inside so this is the pods yamo file that I'm gonna execute this is the same image the same environmental variable and this is the port here so I'm just defining the container port which is where the application inside the container is gonna start it so I'm gonna go and execute this file and by the way if you want to learn how to setup and use mini Cube on your laptop I have a separate video about that where I explain all the details of how to set it up together with the cube CTL command lines so you can check that out and the pod was created and the Postgres is running so now if I wanted to run multiple Postgres pots on one node I can I can do that too so I'm gonna change name here so I'm gonna say Postgres to this and we'll leave the container name we're just going to change the pod name and everything else stays the same so I'm gonna apply that again and Postgres to was created so now I'll have two pots running the same application and I can create tens of those and this is a normal case for example we have a multiple replicas of the same application running on your server and there's no problem of port mapping here another reason why pod abstraction over container is useful is that you can easily replace the container runtime in kubernetes so for example if you replace docker run time with another container runtime like vagrant for example kubernetes configuration will stay the same because it's all on the pod level it means that kubernetes isn't tied up to any particular container runtime implementation now as I mentioned at the beginning sometimes pod might have two or more containers inside this is a case when you need to run a helper or side application to your main application like for example for synchronizing when you have multiple database pots or for baking up your application it certain intervals so would have this back up side car container within your application container or it could be a scheduler or maybe authentication gateway so there are many use cases where you might end up having more than one containers inside a pod now the question is how do these containers communicate with each other inside the pot remember pod is an isolated virtual host with its own network namespace and containers inside all run in this network namespace this means that containers can talk to each other via localhost and a port number just like when you're running multiple applications on your own laptop so let's also see that in practice so I'm gonna head over to my mini cube cluster and create a pod with two containers so I'm gonna take nginx for that so that we can curl the endpoint so I'm gonna have one nginx container and inside that in the containers part I'm gonna add another container and this is going to be just a simple curl image because this one has curl inside and also netstat because most of the images do not come with curl or netstat and these kind of tools to keep them as lightweight as possible and this is just gonna print out something and then wait for 300 seconds so that we have enough time to check the endpoint so I'm gonna save that you can find the link to the yellow file in the description so that you can try it out yourself and let's create that pod Phoenix well and pod gets created so let's check that and both of the containers are running and now I'm going to enter into curl container so I'm gonna do that pod name and now because I have two containers I have to specify the container name where I want to enter so it's gonna be sidecar container so I'm inside the curl container so what I'm gonna do here is I'm gonna check first with net stud and this is the port where nginx is running so this is the 80 port and I can also curl localhost 80 and I'll get this welcome to nginx index.html page and if I check the nginx logs I'm gonna see the those curl requests coming also from localhost from the curl container also having notice that in the kubernetes cluster when you run docker containers there is this post container always per each pot these are called send box containers whose only job is to reserve and hold the pots network namespace that's shared by all the containers in a pot so post container makes it possible for the containers to communicate with each other and also if a container dies and a new one gets created pot will stay and keep its IP address but know that if the pot itself dies it gets recreated and a new pot will get assigned a different IP address so to see that pulse container let's go back to the mini cube cluster however note that mini cube runs in a virtual machine so if I do docker PS here I won't see any containers running inside the mini cube cluster because it's not on my hosts it's running in its own virtual host so in order to connect to it from my hosts what I have to do is tell my daugher to execute docker commands on a remote host which is gonna be my mini cube and for that there is this compact comments so if I echo this which is mini cube docker and you see that I set a docker host which basically sets a remote host address for my daugher client and this is the IP address of the mini cube you can check that address by the way if you for example describe a pod here you see in this meta information note is set mini cube and this is the IP address that I have here and it also sets a certificate so that you can access that so now if I do this and then dr. PS I will be able to see all the docker containers that are running in the mini cube so here even though I just created one engine X pod with two containers in it I get a whole list of containers so where this come from is basically in my mini cube I have this default namespaces as well that have their own containers running if you want to learn about namespaces I have a separate video about that so you can check that out so let's go back here notice they're a bunch of post containers here and if I grab that based using these prefix I see the list of post containers and in the name they all have pod name that they belong to so let's let's clear this up and let's check for nginx pod and here it is this is our nginx pot this is nginx ingress controller that is also running in a different namespace so this is our pod right here and it has its pause container so every pod has its own pause container now this video just showed one part of the whole kubernetes networking which is a much broader topic so for example other concepts would include things like how pots themselves communicate with each other across hundreds of servers regardless of which nodes they are on also the concept of how the outside world communicates with communities cluster as well as how kubernetes plugs into the underlying infrastructure network which can be a cloud platform or a bare-metal infrastructure and in addition to that I believe that learning about docker container networking will really help in understanding how kubernetes networking works because then you have a good comparison so because there are so many concepts there I'm creating a complete kubernetes networking course where I explain all these concepts with real-life example demos and once I release that course I will announce it on my channel so stay tuned for that if you liked this video and got some valuable information out of it then please like and subscribe for more videos like this and also click the notification bell if you don't want to miss new video uploads thanks for watching and see you in the next video

Channel: TechWorld with Nana

Views: 73,570

Rating: 4.9730053 out of 5

Keywords: kubernetes networking, kubernetes container networking, kubernetes container communication, networking with kubernetes, kubernetes pods and containers, kubernetes networking deep dive, kubernetes pods, kubernetes networking tutorial, pods and containers in kubernetes, kubernetes networking basics, kubernetes networking explained, networking for kubernetes, kubernetes container port, kubernetes pods containers, kubernetes pod vs container, techworld with nana

Id: 5cNrTU6o3Fw

Length: 13min 39sec (819 seconds)

Published: Sat May 09 2020