Part 2 | RTF Primer | Kubernetes Basics

Estimated read time: 1:20

Summary

In this second part of the Kubernetes primer, Vishwas Pawar explains the need for Kubernetes in managing and scaling containerized applications in the cloud environment. Kubernetes acts as an orchestrator that dynamically manages container scaling through its control and runtime planes. The video dives into the architecture of Kubernetes, discussing clusters, nodes, and the various services including Pods, and network services like Node Port, Cluster IP, and Load Balancer. The segment ends with the introduction of Ingress, which offers smarter load balancing and routing by reading traffic at a deeper level.

Highlights

Discover how Kubernetes automates scaling and management of containers, vital for modern cloud apps ☁️.
Learn the roles of Pods and why they are crucial in encapsulating containers within Kubernetes 🛡️.
Node Port and Cluster IP services are essential for facilitating communication within and outside the cluster 📞.
Load Balancers are essential but using too many can be costly for businesses 💰.
Ingress is introduced as a robust solution for smarter load balancing and traffic routing 💡.

Key Takeaways

Kubernetes simplifies container management and scaling in cloud environments 🚀.
Pods encapsulate Docker containers to be managed within Kubernetes 🐳.
Node Port Service facilitates external communications by port forwarding 🌐.
Load Balancer Service manages external traffic but can be cost-inefficient 🔄.
Ingress provides smart routing and TLS termination for better traffic management 📡.

Overview

In this enlightening session, Vishwas Pawar unpacks the basics of Kubernetes, a pivotal tool in today’s cloud-based application environment. The discussion begins by highlighting the challenges faced without Kubernetes and how it acts as an orchestrator to solve these by managing the lifecycle and scaling of containers within a cloud infrastructure.

As we delve deeper, the structure of Kubernetes clusters is laid out with roles defined for nodes, pods, and services. Each component plays a unique role: from the Control Plane managing Kubernetes state to runtime planes executing applications. Special emphasis is placed on understanding critical terms like Pods and the networking setups like Node Port and Cluster IP services.

Finally, viewers are introduced to Ingress, a smart layer-7 load balancer that reshapes how traffic is handled. By providing efficiencies beyond traditional load balancers, Ingress supports TLS termination and URL routing, making it a superior choice for managing external traffic. This section underscores the significance of understanding Kubernetes for any tech professional working with cloud-native solutions.

Chapters

00:00 - 03:00: Introduction to Containers and Kubernetes In the introduction to Containers and Kubernetes chapter, the importance of containerization in enabling multiple applications to run on a single machine is discussed. By using containers, each app operates in its own isolated environment, avoiding interference with one another. The session highlights the ease of creating images and running containers using Docker commands. Furthermore, as the digital landscape increasingly shifts towards cloud adoption, it is emphasized that applications must be cloud-native, scalable, and highly available to meet future demands.
03:00 - 07:00: Cloud Migration and Scaling with Kubernetes As application loads increase during peak business hours, a single Docker container may become slow or even crash. To address this, additional containers can be deployed to distribute the load. In cases where this isn’t sufficient, further containers may be added. Conversely, when the load decreases, the extra containers can be terminated to optimize resource usage.
07:00 - 10:00: Kubernetes Architecture Overview This chapter discusses the limitations of manually scaling containers using Docker commands and the need for an automated solution. It highlights the importance of an application or service that can dynamically scale containers up or down based on predefined parameters, providing a more practical approach to container management.
10:00 - 13:00: Components of Kubernetes Control Plane The chapter introduces Kubernetes as a service crucial for managing containers. It emphasizes the importance of Kubernetes in handling a cluster of physical or virtual machines. The chapter delineates the roles within the cluster, highlighting that some machines act as leaders or masters, while others function as followers or workers. It promises to elaborate further on the distinction and roles of leaders and followers in the Kubernetes infrastructure.
13:00 - 19:00: Pods and Nodes in Kubernetes This chapter discusses different ways to create Kubernetes clusters. One option is to create a cluster from scratch by provisioning your own servers and installing all necessary Kubernetes components. Alternatively, managed services can be used to simplify the process, avoiding the need to manually provision servers and install components.
19:00 - 30:00: Networking in Kubernetes This chapter discusses various cloud providers that offer Kubernetes services. It mentions popular providers like Amazon Elastic Kubernetes Service, Google Kubernetes Engine, and Azure Kubernetes Services. Additionally, it explains that there are many other providers available in the market. For those planning to have an on-premise Kubernetes cluster, it is possible to provision the servers and use package services to install all necessary components.
30:00 - 39:00: Kubernetes Services: Node Port and Cluster IP The chapter discusses Kubernetes services, specifically Node Port and Cluster IP. It mentions tools like Rancher, gravity, and Minicube, noting that Minicube is only for demo purposes and not suitable for production. The chapter then shifts focus to the leader (also known as the controller or master node) within a Kubernetes cluster. It explains that there can be one or multiple controller nodes, which consist of various components responsible for handling cluster operations.
39:00 - 51:00: Load Balancer Service in Kubernetes This chapter delves into the structure and function of the control plane in Kubernetes, focusing particularly on the components that form the controller node. Key emphasis is placed on the role of the etcd cluster, a key-value database crucial for storing vital Kubernetes data such as details about pods, replicas, configurations, and nodes. Changes to the cluster, such as starting or stopping containers or modifying nodes, are handled by this database.
51:00 - 64:00: Introduction to Ingress in Kubernetes This chapter introduces the concept of an 'Ingress' in Kubernetes. Ingress refers to the way users and service requests gain access to the resources within a Kubernetes cluster. The chapter touches upon key components such as the 'hcd cluster' and 'node controller'. It explains that a cluster is deemed complete when all changes are successfully recorded in the 'hcd cluster'. The role of the 'node controller' is also discussed, highlighting its function in managing the addition or removal of nodes, which are either physical or virtual machines that make up the cluster.
64:00 - 75:00: Ingress vs Load Balancer Service This chapter explains the responsibilities of the node controller, replication controller, controller manager, and the cube scheduler. It discusses how the node controller checks the health of nodes and tracks resource utilization, while the replication controller handles the management of container replicas. These components are collectively overseen by the controller manager, concluding with the role of the cube scheduler.
75:00 - 90:00: Summary and Conclusion This chapter discusses the role of the Kubernetes (K8s) scheduler in deploying containers on worker nodes. The K8s scheduler is responsible for tracking taints and tolerations on a worker node, which are critical in determining where containers are deployed. By understanding the attributes of the worker nodes, the K8s scheduler efficiently manages and schedules the containers to ensure they are running on the appropriate nodes. This process underscores the symbiotic operation of Kubernetes components to achieve optimal deployment and management of containers within a distributed environment.

Part 2 | RTF Primer | Kubernetes Basics Transcription

00:00 - 00:30 so in the last video we saw how containers help us to run multiple apps on a single physical or virtual machine in their own isolated space without interfering with each other with a couple of Docker commands we were able to create images and run containers since the world is slowly moving to the cloud our apps also need to be native to Cloud they need to be scalable and highly available for example I have a web app deployed in
00:30 - 01:00 the docker container now the load on the app increases during Peak business hours as a result the container becomes slow and even crashes sometimes to solve this issue I would have to spin up a new container and balancer load across the two container sometimes this won't be sufficient so we would have to spin up even more containers and when the load goes down we can spin down the extra
01:00 - 01:30 containers and claim the resources but how do we scale this containers dynamically based on certain thresholds well we can run a Docker commands and spin up containers but that isn't practical we want a an application or a service that can automate this spinning up and spinning down the containers based on certain defined parameters
01:30 - 02:00 and kubernetes is one such service that helps us manage the containers and that is why we need kubernetes when we talk about kubernetes we are dealing with cluster of physical or virtual machines in this cluster some machine behave As Leaders also known as controllers or Masters and some behave as followers also known as workers or slaves more about leaders and followers
02:00 - 02:30 in the next slides now there are multiple flavors of kubernetes available we can choose to create kubernetes cluster from scratch so basically you provision all the required servers which can behave as controllers and workers and then install all the components of kubernetes on your own otherwise if you do not want to go through the hassle of provisioning servers and doing all this stuff you can basically use managed services from
02:30 - 03:00 popular Cloud providers like Amazon's elastic kubernetes service Google's Google kubernetes engine and Azure kubernetes services and there could be many others in the market as well but if you want your kubernetes cluster to be on premise you can provision the servers but you want someone to install all the components for you in that case you can go with a package services like
03:00 - 03:30 gravity Rancher Etc and minicube is a good example of such packet service that can be deployed on-premise but remember minicube is only for demo purpose not from production purpose so let's talk about the leader also known as controller or Master node there can be one or multiple controller nodes in a kubernetes cluster there are multiple components that form the controller node since the job of this components is to
03:30 - 04:00 control other nodes they are said to be the part of the control plane so what are the different components that create the controller node let's start with the hcd cluster this is a key value based database that stores details about pods replicas configuration nodes Etc any change to the kubernetes cluster like spinning up a new container stopping a container adding new nodes to
04:00 - 04:30 the cluster is considered complete only if the details related to this changes are persisted are persisted to the hcd cluster successfully next up is the node controller a node is basically a physical or a virtual machine that is part of the cluster the job of the node controller is to manage the addition or removal of the node to or from the cluster
04:30 - 05:00 checking the health of the nodes keeping track of the resources being utilized are also the activities performed by the node controller next is the replication controller this is quite similar to the node controller it's just that its job is to manage the replicas of a particular container now both the components together get clubbed and are managed by the help of a controller manager and the last one is the cube scheduler
05:00 - 05:30 so whenever the containers are supposed to be deployed on the worker nodes in such cases this task is taken up by the cube scheduler so Cube scheduler basically tracks uh the chains and tolerations on a worker node and based on those details it will schedule the containers to run on a particular worker now all of this component together are
05:30 - 06:00 managed by the cube API server and this API server exposes a set of apis using which we can manage the kubernetes cluster so basically whenever we run any Cube CTL commands all are facilitated facilitated by the help of the cube API server now let's move our Focus towards the follower also known as worker or the slave nodes the job of this node is to run our
06:00 - 06:30 containerized applications since this node performs activities required to run our application it's considered to be a part of the runtime plane the worker nodes have two main components that is the cubelet and the Q proxy cubelet is basically an agent that gets command from the control plane components for example if the cube scheduler wants to spin up a container on the worker
06:30 - 07:00 node it would root its requests through the cube API server and then a cubelet on a specific worker node would deploy the container similarly metrics related to Containers running on the worker nodes are also sent via the cube API to the cube API server via the cubelet now this cubelet can also be present on the controller node because all other components of the control node
07:00 - 07:30 controller nodes like hcd node controller replication controller are can be deployed in the form of containers and to manage them a cubelet is also required so a cubelet can also be present on the controller node the next component is Q proxy if an app on Node 1 wants to communicate with app on node 2.
07:30 - 08:00 this communication has to be facilitated by the cube proxy service so that's the high level overview of the kubernetes cluster now let's understand the basic terminologies used in kubernetes let's start with pod so if you're familiar with Java you might have observed that all the methods and member variables are encapsulated within a class it's only using a class an object can be
08:00 - 08:30 created and the methods can be executed same is the case with kubernetes a Docker container cannot be managed directly in the kubernetes cluster it has to be encapsulated within a pod so that it can be managed by kubernetes pod is the smallest possible object that can be created in kubernetes a container a in the kubernetes cluster cannot exist without pod so this is the final representation a
08:30 - 09:00 container is encapsulated in a pod and a pod is encapsulated in a node now this node can be controller or the worker node normally a pod always has only one containers but exceptions are already there so in some cases there could be situations when a pod will have multiple containers and this additional container could be a helper container let's take
09:00 - 09:30 an example of the mule applications that are deployed to RTF so a single pod for a mule application will have at least two containers one for the app and the other one is for monitoring there's another third one but it doesn't stay long it just initializes the Pod and then disappears away so the monitoring container's job is to collect all the logs and relevant metrics and push them
09:30 - 10:00 to the any point control plane so basically it acts as a sidecar or you can say it is a helper container so in such scenarios you can have multiple containers in a single pot but usually if if we see uh normal applications they will go by one pod one container per board now the other way around is also possible a node can have multiple pods
10:00 - 10:30 as well the way a pod can have multiple containers a node may also have multiple ports now a pod on node a might want to communicate with the pod on node B or maybe two parts on the same node might want to communicate with each other or there could be an external agent who wants to communicate with the
10:30 - 11:00 pods when it's external what I mean to say it's outside the kubernetes cluster so how do we facilitate this communication now this in kubernetes is done with the help of services so let's explore services so the first service is the list is the node Port service but before we try to understand this node Port service we need to understand a few basic things about networking in kubernetes
11:00 - 11:30 now we all know that node is a physical or maybe a virtual machine Let's assume it is a physical machine for the sake of simplicity so if the machines need to talk to each other they need to be a part of network and only then they can form a cluster right so they have to be part of a network so how can they form a network they basically connect to each other via routers or switches so let's introduce
11:30 - 12:00 one router now this router has an IP address of 192 168 0.1 and it connects this node and the other node now both the node have been leased an IP from the router now let's add one more participant which is an external machine and that's not part of this cluster now you might be thinking that as all
12:00 - 12:30 both the nodes are part of the same network can't they be part of the cluster now cluster and network is a bit different thing you can have all the machines in one network but it's not necessary that all at the machines could be part of a single cluster right so when I talk about cluster these two nodes are aware of each other and they both together are
12:30 - 13:00 orchestrating some functionality for example we know right that there is a leader and a follower mechanism so the leader is orchestrating with the worker nodes in case if the reader goes down then the nodes are capable of gathering over a consensus and deciding upon a new leader so basically these nodes are aware of each other and they can take actions accordingly but this
13:00 - 13:30 machine on the other end it's part of the same network but it doesn't deal with this nodes on time to time basis only if you try to send a request on this particular IP address only then will it try to connect with uh the the node but as such it's not at all aware of this nodes in the network okay so that's about the node network but a
13:30 - 14:00 node also has powered in it and the Pod has container okay so now we know that the container was brought to have its own isolated set of resources like disk RAM and even Network right so the container will basically have its own network but since in kubernetes the container is wrapped inside a pod the container has to share the network
14:00 - 14:30 of pod so always remember if a pod has multiple containers in it it always shares the network of pod so if you put two containers in one part listening on port 8080 there will definitely be a port conflict despite the fact that we know a container has isolated resources but in Cuba matters if a container is inside a pod it shares a network of pod so basically a pods IP address is assigned to
14:30 - 15:00 container so if a pod has two containers listening on the same port there will be Port conflict now let's see how the network for pod is there in kubernetes now same thing the Pod will have its own network and in kubernetes uh the networking is a plug-in you can install a plugin so there are multiple vendors out there like like Calico flannel Etc and they
15:00 - 15:30 will help to provide the container networking interface using which uh the com pods can talk to each other so I'm not going to go into the details but just a basic overview of that so this pods will have their own virtual Network they won't be using the network of this physical router but instead they'll have their own virtual Network so assume this to be a Virtual Router
15:30 - 16:00 and it's leasing out two IP address 10.0.0.2 and 10.0.0.3 to the other node okay other pod so both the pods have different IP addresses so what we observe that the Pod network is different than the node Network and this part scan easily communicate to each other using this IP
16:00 - 16:30 address now assume that we have apis hosted in both the pods on the first and the second node and someone outside the cluster for example this machine wants to access the apis now since pods are creating their own network this machine cannot directly access those pod because
16:30 - 17:00 despite the fact that this machine is on the same network as of both the nodes it still cannot access the pods the reason is that the virtual Network that has been created for the pods it has it is a part of kubernetes the container networking interface which has provisioned this network which is this router for demonstration purpose now that
17:00 - 17:30 container network interface has been given by kubernetes or we have installed that plugin now since both of these nodes are part of the kubernetes cluster they can easily access the pods using that IP address because the this virtual network is part of the cluster and this machine is not a part of the cluster hence it cannot directly access
17:30 - 18:00 the pods using the Pod IP address for example 10.0.0.2 if this agent or this machine tries to access this IP it will definitely fail so how does this agent get access now one of the option would be that to log into this node where we are do a remote desktop maybe do an SSH into one
18:00 - 18:30 of the nodes basically get inside the cluster and then run a coil command or choose any agent to call but that's not what you want right we want this agent to directly access using some IP address or something not by logging into one of the nodes so this is where the node Port service comes into picture so let's understand that so here's how the node Port service
18:30 - 19:00 works I have simplified the diagram a bit just to clear the Clutter so that we understand it better so the idea here is to forward a port on the Node to the pod or eventually the docker container now why do we do this it's simple because the node and the agent which is the laptop in this case are both on the
19:00 - 19:30 same network which means that this laptop can easily access the node but cannot access the container so what we basically do is we forward the port so here in this case the port 30 0008 is being forwarded to the containers Port container or the pods Port 80. so basically uh the agent will
19:30 - 20:00 call the IP address of the node and call on Port 30008 because that is what we configured now that Port will be specifically being listened by the service which is the node Port service and then the node Port service will realize okay there is a mapping I need to forward this traffic to the Pod with IP address 10.0.0.2 on Port 80 and that is how it works so this is what you can see
20:00 - 20:30 192.168.0.5 with 3008 gets converted to 10.0.0.2 colon 80. so this is how the port forwarding works now the same concept can be applied in case of multiple pods so there could be scenarios where one single node will have multiple pods on it so even in that case the service will
20:30 - 21:00 basically this node Port service can also behave as a load balancer because it can call any of the Pod right randomly because there are two pods with which have the same so basically this pod has a replica and the notebook service can easily balance or randomly assign the request to any of the replicas and this also can be extended
21:00 - 21:30 to multiple nodes so there could be situation when there could be more than one node and the container which is having the same app so replicas can be scattered across multiple nodes even in that case this single service is always extended across all the nodes in the cluster so node Port service can also do some sort of load balancing across the
21:30 - 22:00 different pods next up is the cluster IP service now take this example Here app one wants to communicate with app2 there is an API hosted on app2 which needs to be called so to make a call app one needs to use the IP address of app2 right this is the Pod IP address and same is the case with app one if app
22:00 - 22:30 2 has to communicate with app one it has to use iPod IP address of app one now that looks fine we can use this IP addresses to call the other parts but what if the Pod crashes so in that case uh that pod is gone so the app2 is no not anymore but since uh
22:30 - 23:00 kubernetes has the replication controller it will always try to maintain the desired number of pots for a given application so it will spin up a new container but the problem is that once the new container comes up was a new pod comes up it will have a different IP address a different pod IP address so if you have used a quad IP address of 10.0.0.3 it's not working anymore right
23:00 - 23:30 because now it's 10.0.0.5 so to solve this problem there is a component called as cluster IP service now the cluster IP service will be per pod so if you see in this diagram app 1 has its own cluster IP service and app2 has its own cluster IP service now the idea behind this cluster IP
23:30 - 24:00 service is to have a static IP assigned so the Pod will always have a static IP assigned like 10.0.0.8 and pod with app2 will have 10.0.0.9 so in the event the Pod crashes for sure the IP address with the Pod IP address will change but the cluster IP address would always remain the same
24:00 - 24:30 so in that case now if app one has to call app2 it can use the cluster IP address which is 10.0.0.9 and we rest assured that the call will be successful even in case uh the Pod crashes so that's the idea of the cluster IP service now let's look at a different slightly different flavor
24:30 - 25:00 so here is an app one uh again there are four replicas of app one which are scaled across multiple nodes so it's in node this node one has two replicas and node two has two replicas so like I said each app has each app or each pod has a cluster IP service but if the Pod has multiple replica if it's the same pod with multiple replica the
25:00 - 25:30 cluster IP service would be shared among them as is in this case so pod with app one has four replicas but cluster IP service Remains the Same and the cluster IP service can again load balance among all the pods similarly the second example the app 2 is scaled uh across two nodes with four replicas and it also has a cluster IP of 10.0.0.12.
25:30 - 26:00 so to sum it up cluster IP service basically provides us with a static IP so that even if the replica of a particular pod goes down we still have an IP which can root the request properly now there's there is a problem in this case it's that you cannot Define the IP address or the
26:00 - 26:30 IP addresses are just not good to remember right so assume that you are trying to deploy an application and in the property file you're not going to write the IP but you'd rather like to use a fully qualified domain name to access the applications right so that also can be done and there is a format using which you can access so here is the format so it's like app name now this is a
26:30 - 27:00 particularly specific to runtime fabric so this has appname dot namespace dot SVC dot cluster.local now cluster.local is the root domain SVC stands for service now there are multiple options available you can also you uh there is an option of pod default but that's beyond the scope of this video what we can use or what is being used in
27:00 - 27:30 RTF we mainly used svc.cluster.local and then the app name and the namespace so this fqdn will basically help us to the DNS resolver will resolve it into the cluster IP service which is a static IP and we can use it directly but what is this name space in here let's try to understand what exactly is namespace so namespace is basically a
27:30 - 28:00 logical grouping of pods take this example we have our API alert connectivity model so we have experienced process system now there could be multiple apis but they can be grouped under a certain criteria right like certain set of apis belong to the system layer so it makes sense to group them into a namespace so that kubernetes can manage
28:00 - 28:30 them or if there is a kubernetes administrator he can do all sorts of manipulations or modifications whatever is required so for easier management it makes sense to logically group The pods so the same is the case here we group the pot so this spots now this could be completely different uh apis but since they belong to the experience layer they are added in the experience namespace
28:30 - 29:00 similarly for process and system it's not necessary that we go by this convention there could be other options also like some some could be back end right some could be database so you can add database namespace so this namespace or incubernetes ideally can be configured but coming to RTF uh this is the format uh which I have
29:00 - 29:30 which we have seen in the last slide where we saw the fully qualified domain name was appname Dot namespace dot svc.cluster.local so that namespace is basically the org ID so any applications that we deploy uh will fall under a namespace of your org ID and using that we can segregate the pods and kubernetes can manage them accordingly but if it's a plain cuber
29:30 - 30:00 that is uh if you remove that RTF part this namespace is configurable we can configure on our own and things work accordingly so that's about name spaces now let's move to the load balancer service to understand this service let me bring up the node Port service diagram so here is the diagram now we have seen that in node Port service if some
30:00 - 30:30 person wants to access the service and he is outside the cluster he can basically leverage the node Port service so it opens a port on the Node in which the Pod is running right and that was quite a good option but there are certain drawbacks of this approach first drawback is that assume someone outside your network let alone the
30:30 - 31:00 kubernetes cluster now these machines are inside one network but you ideally want to expose this as front-end application maybe web uis so you would basically like to expose this over the Internet so that anyone across the globe can access your service so you cannot leave such ports open like thirty thousand eight and because this is basically a loophole you are loving this uh which is not a
31:00 - 31:30 standard port and you are directly exposing your kubernetes cluster node which has pods in it so basically it's a security risk to open up a node which has multiple pods and containers and even getting hold of this port can try to attack and maybe bring the whole note down which is a very critical part of the kubernetes cluster the another problem is that uh anyone over the Internet or any external
31:30 - 32:00 consumer might not want to add the port right so whenever you try to access a web page or an API usually don't add a port because for HTTP it's 80 and for https it's 443 that's implied that gets automatically added even if you don't add it so no one's going to add the port all the user wants is uh some name right fully qualified domain name to access it so no one's going to write the IP
32:00 - 32:30 address or the port number so there is yet another drawback that we don't want to go with the IP address or the port number so basically we want some element that can take care of both the things right so the IP address can be handled by a DNS server it could be a public DNS or your internal DNS if you want to access within your own network then an internal DNS might work but if not then you get a
32:30 - 33:00 public IP add a DNS entry on the public DNS servers and Port only Port 80 and 443 should be exposed no other ports because even if you see at a production scenarios your kubernetes cluster or any cluster or any network which is internal the firewall is there and the firewall only exposes a limited set of ports for example 80 443 or 23 for
33:00 - 33:30 SSH access right so we would want to only expose certain ports and not ports like thirty thousand eight now here the port that I've used 3008 it's because the node Port surface uh has a range and it starts from 30 000. all right so now we are aware of the problem that we need to fix and load balancer is one such component that can help us to achieve the same thing okay so let's see how it works so now we introduce a new service
33:30 - 34:00 which is called as a load balancer service so the load balancer service would basically spin up a virtual machine if it's uh we are on frame cluster which you manage on your own in that case you have to provision a VM and you have to introduce a load balancer into the cluster and that will take care of so this load balancer can have a public IP address and it can open a port ATN 443
34:00 - 34:30 and then it will do translation to the node Port service so node Port service will still be there it's just that a load balancer service acts as a proxy between the two so now we have the load balancer service now if you are using managed services like uh Amazon's elastic kubernetes service or azure's kubernetes service or Google's or gke in that case uh they will use their native load balancer and
34:30 - 35:00 you will be charged accordingly so native load balancers will be the layer for load balancer basically working on the TCP and IP layer they they just forward the raw traffic they cannot read anything they just blindly forward that traffic so all the forwarding thing would be done by this lb service so now what we have done we have got a rid of exposing this unwanted Port externally now we can
35:00 - 35:30 only expose Port 80 or Port 443 that we want and additionally this load balancer service can have a public IP and that public IP can get a DNS resolved name okay so now the flow becomes like this the request from any external machine which is outside the cluster or it could be even outside your network uh can use this fully qualified domain name
35:30 - 36:00 and then the request reaches out to the lb service and then from the lb service it goes to the node Port service and from the note Port service the original flow Remains the Same now we know about the note Port service so if You observe this lb service is nothing but an extension of a node Port service so if you create an lb service behind the scenes there would be a node Port service supporting it and same is the case of cluster IP service this node
36:00 - 36:30 Port service will internally use cluster IP service so the flow is like cluster IP then the node port and the load balancer service so here's the extended version of the previous slide now I have clubbed all the concepts of services that we have learned so far cluster IP node port and load balancer service so in this diagram I have an app which is scaled across two parts so basically these are two replicas of the same
36:30 - 37:00 application and we are trying to expose them externally so as we have seen we can create a load balancer service which sits outside the nodes so depending on what you what cloud provider you use uh it would be native to that cloud provider or if it is on-prem you have to spin up a new uh instance for a load balancer and install it so if it is eks then it's Amazon's Network load balancer and so on for other providers
37:00 - 37:30 so we see that this load balancer now depending on your requirement it can have a public IP or a private IP if if it's expected to expose to some uh over the Internet it needs to have a public IP address so a client tries to access that service so it will basically use the fully qualified domain name go to the DNS get the IP address uh now the IP address is retrieved and since it is HTTP it will
37:30 - 38:00 root a request on Port 80 of the load balancer service request comes to the load balancer now obviously load balancer has to reach the node now it will have both the nodes registered so it will based on the algorithm it has it will choose one of the node and we need to access this node right so it will reach out to the node Port service now we have seen that a node Port service will expose a port on the
38:00 - 38:30 Node uh from the range 30 000. so here we can see it's thirty thousand eight Port which is exposed on both the node by the node Port service observe that node Port service is available on the nodes and it's scaled across both the nodes so the request comes to the node Port so this is the IP address of the node that has been selected and the port so it comes to this node now the node Port will route forward to the cluster IP
38:30 - 39:00 because it eventually has to reach the Pod and this is the IP address of the Pod so again it uh it sees if there are multiple nodes on it on on this if there are multiple pods on the Node then it based on its logic algorithm balancing it will select any of one of them but in this case we just have one pod so it it takes that IP 10.0.0.2 port 80 and eventually forwards that traffic to this particular
39:00 - 39:30 pod so this is how the overall flow of the load balancer service Works So eventually cluster IP is the main thing it gives static IPS for the pods to communicate and that static IP would be the cluster IP will have its own IP and cluster IP will forward that uh to the changing IP addresses of the pods so basically this 10.0.2 I've shown is for demonstration
39:30 - 40:00 purpose it eventually goes to here but this cluster IP might have some different IP address so it could be like 10.0.0.4 and that would convert to 10.0.0.2 so cluster IP then node port and load balancer service so all these three components together enable communication between the pods in a kubernetes cluster now there are a couple of limitations to
40:00 - 40:30 this approach let's try to understand them in the next slide so in this slide I have tried to simplify the diagram and have made some modifications let's try to understand it so here are uh ports I have total four replicas of the order let's call it as an order microservice okay which it has uh four replicas and this is this is basically a pod so four replicas of the orders
40:30 - 41:00 microservice and I have another application which is the accounts microservice again it has four pods which is four replicas now if I create services for accounts and order so basically I'll have a two Services right for each of them so I can create a note Port service I can create a cluster IV first of all I'll have to create a cluster IP service so that I get a static IP address for
41:00 - 41:30 orders and accounts so we have a node port for external access cluster IP for internal access now let's move to the load balancer so we create a load balancer now observe that there is some change here now this load balancer is for orders and the other one is for accounts now I ended up creating two load balances but why do I have to create two
41:30 - 42:00 load balancers so the problem here is that when you create a load balancer uh in as a service on any managed service like Google kubernetes engine or maybe AWS eks right in that case uh the cloud provider will facilitate a network load balancer which is native to their platform so this network load balancer is a layer
42:00 - 42:30 4 load balancer which means that it works only with the TCP packets it it it's not smart enough to understand the contents of the request and Route it to a particular endpoint so basically it will get your request and forward to a particular IP address so it will have for example it has two nodes registered to itself right so it it based on the IP address of that node
42:30 - 43:00 it will choose any one of them and forward it it cannot read the contents of your request so owing to those reasons we we cannot have any routing rules written in this particular load balancer it can only root packets based on the IP addresses so that is why for each type of microservice which has multiple replicas we end up creating one single load balancer
43:00 - 43:30 now this load balancer have cost associated with it right so if you use on a AWS eks they'll provide you an Network load balancer and you will be charged for it so if there are hundreds of microservice you end up creating 100 Network load balancer which in no way is an efficient solution right so basically uh we don't want this option but now if
43:30 - 44:00 we go with this option how will be the flow same as area right we we now create a load balancer specifically for order so I'll just change the url lb service orders and then I get the IP and the same old flow similarly for accounts I have the same flow and then it's the request is served or the access is granted okay but as we realize that this approach is not good because we end up creating multiple
44:00 - 44:30 Network load balancer so it would be a better approach if we could condense this two load balancer into one which means that we want a load balancer to be smart and rather than creating one specific UI domain we can have something like this so so this is an approach right we have the same domain but the resources changes for example if the resources orders
44:30 - 45:00 we move or we rooted to the order spots if the resource is accounts we move it to the account spots so to cater to this requirement we have something called as Ingress now Ingress can behave as a layer 7 load balancer which is a smart load balancer you can basically read your request do TLS termination and also it gives you an ability to do URL mapping
45:00 - 45:30 so that is what helps us to overcome the lower balancer service limitations so now the idea behind having an Ingress is that we want the layer 7 load balancer which basically is smart enough to understand the traffic it can basically and it can read about uh the TCP packets it can basically understand a protocol it can do PLS
45:30 - 46:00 termination and it can also do load balancing and URL routing based on the resources that have been used so we want this feature the layer 4 load balancer which is being created using the service it doesn't fulfill this requirement due to which we have to create multiple load balancer for each microservice so to do that we would basically need to
46:00 - 46:30 deploy an application right so it could be an nginx load balancer ha proxy and traffic so this uh they provide Solutions we can basically take that solution and deploy it so now this particular part in the Ingress is known as Ingress controller because it it usually does all the task of controlling but alone the controller is not enough it needs to have some configuration like
46:30 - 47:00 uh right like having rules how to root based on the path right so that can be done at the resource so where we have rules uh defined like if it is forward slash accounts push it to the note Port three listening on three two zero zero eight if it's order push it on service notebook service on three two double zero nine so this is handled by Ingress resource so any configuration is done on
47:00 - 47:30 the Ingress resource and it's then implemented by the controller think of it as this is an interface which defines the rules and controller is how you implement the rule by default kubernetes doesn't come with a controller you have to deploy your own controller solution or in case if you are using a managed kubernetes service there are many Native options available out of the box in that
47:30 - 48:00 case and both of this resource together create an increase so Ingress is basically Ingress controller along with Ingress resource now this would uh certainly help us get rid of the first problem that we don't need to create multiple load balancer for uh for multiple micro Services we can just have one layer 7 load balancer and it can root based on the resource right accounts and orders plus we have a
48:00 - 48:30 single point where we can configure the TLs termination which means that we don't need to have TLS configured on each application right that helps uh enormously from maintenance perspective because the admin would not want a developer to implement TLS on all its application right there could be there there are two reasons one is that it would unnecessarily uh make things
48:30 - 49:00 complicated because each app will have TLS termination and first of all you cannot have a load balancer you would not have want to have a load balancer will out TLS so if you implement a TLS at load balancer and the developer also implements TLS in his application there are two TLS termination happening which makes the which would increase the latency and you would want to have only one TLS or assigned certificate so it
49:00 - 49:30 would be useful it would be helpful to have only one TLS termination at a load balancer level so that any kubernetes administrator can just change it based on the requirement so it can get expired or whatever reasons maybe there's a single point where it can change rather than going to each application and the other thing is that since it's nginx such a proxy and traffic these are load balancing products so it gives you load
49:30 - 50:00 balancing ability so that is how an increase in kubernetes is created so it's basically controller and resource now back in the lb service limitations diagram we can replace the network load balancer or the load balancer service with our application load balancer which is ingress so here we replace both the load balancer service using an Ingress now this Ingress can help us support TLS
50:00 - 50:30 as well as load balancing and the important thing it's smart enough to root the request to a particular service and eventually to a pod so now what would happen is we will change this domain now this would be a generic domain so it's lb service devnet and then the resource where we want to root so in this case it's order same thing we will get the IP address and then the request should be this is the DNS
50:30 - 51:00 translation of domain and this is how the request would eventually make it to the Ingress same applies to the accounts so now accounts is a path part of the URI pattern and then same would happen to the DNS resolution we get the IP now both of them are basically calling the same public IP address we got rid of two load balancer it's just one load balancer so that is how Ingress helps us
51:00 - 51:30 to overcome the limitation of load balancer service and it's quite effective when compared to its counterpart so now let's sum things up so we have three service ignore this this is not a service but I didn't have any option to place it so I just added in this table but we have three main services and cluster IP is the root first of all
51:30 - 52:00 when you will deploy a pod a cluster IP service has to be created and its job is to give a static IP interface for pods so this service will have one IP address and that IP address can be routed to multiple pods so it gives you a static IP and the access type for this is internal so any communication which has to happen from one part to the other irrespective of the fact that it is on node a or node B as long as it's in the
52:00 - 52:30 same kubernetes cluster it can use cluster IP to access next is node Port service so it's it does basically port forwarding forward support on the Node basically exposing a port on the Node so that someone outside the cluster can call and that node uh sport will call this node Port service note Port service will call cluster IP because it has to call a certain IP and
52:30 - 53:00 that's cluster IP will redirect it to a particular pod so node Port again is an extension of cluster IP and it caters to any external traffic now the problem with node Port was that you are directly exposing the port on a node where and you don't want your clients to specifically specify a port if it is a rest API all they have to just uh give is maybe an IP address or if not that
53:00 - 53:30 then give a fully qualified domain name and then they should have a page or any pay response ready so to get away with all those complexity we have a load balancer service and it's basically a network load balancer which works on layer 4 isn't smart enough to root traffic based on the URL mappings and it caters to only external access now in Grace it's not a service
53:30 - 54:00 it's basically a different component that has that doesn't come by default on kubernetes you need to deploy an Ingress controller so that your Ingress resources can be implemented in that controller so Ingress again overcomes a limitation of a load balancer type service and it's a layer 7 application load balancer which is smart enough to do TLS termination it can do routing
54:00 - 54:30 based on the URL specified and also load balancing again its job is to cater any external communication so any external traffic that wants to uh leverage the resources which are present in cluster or get a response from them in that case we use increase so that completes our cuber and it is Basics now I have only covered the basic level now you won't be working on all
54:30 - 55:00 these Concepts on a day-to-day basis if you're working on RTF you you won't get a direct Hands-On on this but yes it's quite important to understand these things because eventually behind the scene this is all what takes place so if you understand this concept clearly you would be able to figure out the communication that's happening in the pots all of these components have configurations which are
55:00 - 55:30 automatically done by runtime fabric we don't have to do it but it's just that having a basic idea or understanding is great because that helps you troubleshoot issues and also for Ingress if it's a self-managed kubernetes so if you are deploying uh your kubernet RTF on eks gke or Azure kubernetes service in that case Ingress has to be configured separately but if it is an
55:30 - 56:00 appliance in that case you don't need to do much of a configuration basically you don't need to write any yaml file you can just do it do that configuration on the UI by just uploading the certificate so that's all for this video I hope you found the video useful thanks for watching