Networking Concepts Every DevOps Engineer Must Know

In this video, we're going to explore the evolution of networking in modern infrastructure from physical servers to virtual machines to containers to container orchestration tools and all the core networking concepts underneath. And knowing these networking concepts is important whether you are a software engineer, DevOps engineer or cloud engineer. So, let's dive into a practical scenario to see how networking has evolved and what you need to know today. And we created a full breakdown of this in a beginner friendly handout to accompany this specific video. So, grab it from below and let's dive in. Imagine we have built Shop Easy, an e-commerce platform that has grown dramatically over the years or decades. Now let's trace its networking journey from the early days to today's modern architecture.

architecture. When shop easy first launched, everything ran on a single physical server. One powerful machine in a data center running our web application, database and all the services using a single public IP address. So customers needed to access our shop easy website. So our physical server that runs the website needed to be identified on the network somehow and that's where IP addresses come in. Think of an IP address like a physical street address. Just as your home has a unique address for mail delivery to uniquely identify that specific house, our server also needs a unique address where clients can send it requests. So IP address is like a street address for your server on the network. It's a special number that looks like this that tells other computers exactly where to send data or requests so that it can reach your server. And every device on a network including your shop easy server needs to have its own unique IP address for the communication. Just like every house on a street needs its own address to get mail. But wait, what even is a network? Think of a network as a group of devices that can talk directly to each other, like all houses in the same neighborhood. And going back to the IP addresses, if we have an IP address like 203. 0. 13. 10, 10. The IP address looks this way because it's based on the IPv4 standard which uses four sets of numbers. So each section between the dots ranging from 0 to 255 separated by dots. So the first three parts of the devices IP address identify the specific network or the neighborhood. And the last part, the fourth section points to a particular device in that network or to use our analogy, a specific house in the neighborhood. But then how does one device in one network talk to another device on another network? That's the role of special devices called routers. When a computer wants to send data to another device outside its own network, it sends the data to its network's router, also called a default gateway. The router then forwards the data toward the destination network, passing it through other routers on the way if needed until it reaches the right device. Routers use the network part of the IP address to decide where this data needs to be sent. Much like sending mail from one neighborhood to another through sorting post offices. So the network part of the IP address is like saying all houses on Maple Street while the host part is the exact house number on that street. This way, any device on any network can reach other network as long as there are routers linking these networks together. But wait, customers would not type in 203. 0. 13. 10 in browser to access our website, right? Instead, they would type something like shop easy. com when visiting our site. So that's where the main name system or DNS comes in. So DNS is like the internet's address book. It translates easy to remember website names or human readable website names like shope. com into the IP address that uniquely identifies the server that is hosting that website. because we humans definitely don't want to remember or type servers IP address but we can remember simple names like shopey. com or google. com. So when a user types a website name into the browser, the browser asks a DNS server for the matching IP address or an actual address of the server for the website and DNS will automatically translate the website name into the server's street address or IP. So the browser knows where to fetch the web page from. And in addition to that, even if the IP address changes in the background, the shope. com will bring users to the right server with a new IP address. And this process happens in milliseconds. And as I said at the beginning, all this will be neatly organized with practical visuals in the handout so you can review it and easily follow along. It will be in the link below. So go grab it. Now let's say we delivered mail to the right house. But how do recipients in that house actually get it? Meaning once the request from client reaches the server machine, how does it get to the actual web application running on that server or on that virtual machine? If we imagine a server like a house on a street, every house has an entrance for visitors and mail like the main entrance. And for computers and servers, the network interface acts as this main entrance. It's a special doorway where all network traffic comes in and goes out. One common network interface is called Ethernet zero. Think of ETH0 as the front door of the house. All data packets trying to reach the server must enter through this door. There can be other doors like ETH1 another Ethernet cable W len zero a Wi-Fi door or LO which is a small door for local self-communication for local host but let's focus on Ethernet zero which is the main way for outside traffic to arrive into the server. Inside the house there are different rooms each for different purpose and these are ports on a server. A web application room on port 80 or 443 is where website visitors go. The database room let's say port 3306 or 5432 handles data queries and other rooms exist for other services and programs. When the server gets a delivery, the package comes in through ETH0 as we said. But how does the right room get the delivery? Well, the operating system on the server is like the house manager. It looks at each package and checks the room number or the port written on it. So which port is this request addressing? the OS manager, the house manager so to say, then takes the package to the correct room, the program inside the house. So any request that is addressing the web app port gets to the web application. The database gets the queries addressed to the database on its port and so on. So in summary, the network interface connects your house or server to the road or network. G0 is the main front door for deliveries where all the network traffic to your server comes in. Ports are the rooms inside the house where different programs leave. The OS is the manager that figures out what goes where, making sure every delivery reaches the right room. Now, we have been running our website on this simple web server. However, this simple setup had major problems. First of all, if something happens to this house, like a fire or a broken lock, someone broke into the house, there is nowhere else for customers or mail to go. All your deliveries, web requests will stop and your shop is instantly offline. In real terms, if your server crashes, the whole business is down until it's fixed. There is no backup house or server to handle visitors or orders. Now, suppose it's a holiday season and crowds line up at your door. With only one house, you can't add more rooms or doors to serve more customers. Everyone must squeeze inside one entrance, so people have to wait outside. You have slower performance or outages. You can't expand quickly to keep up with busy times. But what if the opposite happens and nobody comes for a week or month? you still have to pay for rent and heating and upkeep on the house even when it's empty. So, one physical server is expensive whether it's serving one customer, 100 customers or none. And most of the time your resources sit unused, wasting money. Or consider, let's say you want to upgrade the kitchen or add new rooms to the house. You've got to close down the whole house and stop visitors from coming while you work on that remodel or renovation, meaning downtime every time you change or update things on your server. When the only server is being updated or fixed, the entire application must pause. So customers notice gaps in

service. To solve these problems, we moved to virtualization running multiple virtual machines on one physical server. So virtualization is like splitting that big house into many separate apartments. So from a single house we're moving to apartment buildings. Which means a virtual machine is like having many fully equipped apartments, selfsufficient isolated apartments inside one large building or a physical server. Each apartment has its own entrance, unique address for mail delivery, has its rooms, kitchen, bathroom, mailbox, and so on. And they can run independently as if each were its own house with private tenants or applications. A virtual machine or VM is an independent, fully functional computer created by software inside a real physical server. Here's how VMs work. Each VM gets its own slice of system resources of the underlying physical server. So they get a virtual CPU, virtual memory, disk and network. Every VM runs its own guest operating system like Windows, Linux, and can install apps, set configurations, and host network connections exactly as if running on real hardware. So VMs are fully isolated. So something running in one VM cannot interfere with another VM on the same hardware. And these VMs communicate over a virtual network created by the hypervisor which is a special program that sits between the physical server and the virtual machines. This virtual network is like having invisible network cables connecting virtual computers inside our physical server. So hypervisor lets the physical server share its actual physical CPU, memory, storage and network among several virtual machines but keeps them completely separated so that each VM acts like a real private computer. So with this setup there are several benefits that we gained for our application. This setup gives us isolation between services. A crash in one VM does not affect others. better resource utilization. So, we can run multiple VMs on one more powerful server. But the biggest difference between physical servers and VMs is that VMs are portable and easier to back up because their entire state including the operating system data configuration can be saved as a snapshot file which can be quickly restored or copied to another physical server. unlike physical servers that require reinstalling hardware OS and applications if they fail or need to be moved. And this means easier backups of our services because we can snapshot the entire VMs. So even if the underlying server machine crashes, the physical server basically burns or is not functional anymore, we can easily restore all our programs on another server using the backups because we can back it up in a snapshot file. But let's see how this works technically and what are the main networking components of VMs. So when you run multiple virtual machines inside one physical server, the building at 203. 01310, each VM's virtual network interface gets a unique apartment number in the building's private hallway like internal network often something like 10. 0. 05 10. 0. 0. 6 six, seven, and so on. These internal IPs are only used inside the building. They aren't visible from outside on the wider internet on the public internet. For example, a VM1 web server has an internal IP of 1005. VM2, which is database server, has internal IP of 1006. Let's say we have a cache server with internal IP of 10007 and so on. These VMs themselves can talk to each other using their private addresses, like neighbors passing nodes in the hallway in an apartment building without sending their messages onto the public street or internet or leaving the building. Each virtual network interface has a firewall that acts like a team of careful security guards who check every incoming or outgoing delivery based on strict rules. So verifying the sender's identity, what room or port they're trying to reach, and whether their message is allowed, so only trusted visitors and safe packages make it past the entrance, keeping the apartment's data secure from intruders, and so on. And all traffic is routed and managed by the hypervisor, which now acts like the building's supervisor or manager, making sure everyone's mail and messages reach the right apartment, and keeping outsiders out unless invited. If a VM needs to communicate with the outside world, its messages pass from its internal apartment number, the internal IP, out through the main entrance, the physical server's public IP. And the process uses network address translation to convert the private internal addresses to public ones. And every bit of traffic is filtered by software firewalls which check the data, enforce security policies and only allow safe permitted requests and responses to go through which keeps the entire communication secure. Now you just saw how even a simple VM setup requires managing firewall rules, IP addresses, net gateways and security groups. Now multiply that across cloud VMs, containers and Kubernetes clusters. This becomes a lot to manage and this is where Tails scale comes in which is a sponsor of this video. So shout out to Tailscale for supporting us. So, Tailscale is basically a modern, secure, zero trust connectivity platform and it provides a very easy and fast way to securely connect from and to any device or service anywhere. And unlike a legacy VPN where all traffic flows through one central server that becomes a bottleneck, Tailscale actually builds an encrypted mesh network where each device directly connects to the other devices that it needs to reach. This means no detour, no single point of failure, and it also adds massive improvements in latency and scalability because of that type of setup. And it also figures out how to make those direct connections automatically even when devices are buried behind nets and firewalls. So there's no need to open ports or manually touch any firewall rules etc. And that means with tails scale you can actually replace legacy VPN infrastructure in minutes and build simple networks across multiple multicloud environments. Also SSH into any device without managing keys and much more. You can get started for free at tailscale. com to test it out. The personal plan is always free and if you want to bring Tailscale to work, use code Nana for three free month on any paid plan. All the links and information is going to be in the description. Now, back to the video.

video. Now, as shop easy expanded, owning and maintaining our own giant apartment building or a physical server became overwhelming and costly because we needed to have a dedicated engineer or multiple engineers like network and server administrators who actually managed those physical machines. So we moved to the cloud which is like renting apartments in a huge expertly managed skyscraper built by professional landlords cloud providers who have already set up thousands of buildings data centers in different parts of the city or the world. So now, shop easy can quickly and affordably rent just the right amount of secure modern living space or modern space or computing resources that it needs scaling up or down instantly with all building maintenance, networking, security, and upgrades handled by the provider's team, leaving us free to focus on running our business, not managing the property. Think of it like that. Companies went and bought a whole bunch of computers, server machines, wired up the whole thing, connected all the network cables, configured the networking, built the data centers with all those machines in different locations, and then built a simple interface, a web browserbased interface to offer slices of these server resources to other companies as a rent. That's how cloud platforms like AWS, Google Cloud, and so on emerged. So technically cloud is easy access to vast amounts of servers that someone else is managing at scale. So let's see under the hood of most important cloud networking concepts. Moving to AWS is like shop easy renting the whole private wing in a giant modern skyscraper that's filled with many companies. So this private wing is called a virtual private cloud or VPC and it's isolated from the rest of the building. So only shop easy staff and customers have access to it and all our VMs or rooms are within our own VPC and inside our own section or office wing VPC we set up different hallways and rooms for different purposes which are called subnets. Subnets are like separate zones within our wing. A public subnet is let's say a storefront with doors and windows facing the street or the internet. Perfect for web servers that public must access. So the VMs in public subnets are accessible to internet or public traffic. A private subnet is secure office space hidden deeper inside used for databases or applications that only our internal staff should reach. No public or strangers should be allowed in those sections of the VPC. All the VMs in private subnet are not directly exposed to internet. So are only accessible from within which keeps them secure. Security groups are like security guards stationed at every door checking who goes in and out of each room based on strict guest lists or firewall rules. Route tables are the building's directory and navigation system showing exactly where deliveries, visitors, or messages should be sent to reach the right office, server, or storage room. If staff in a private office or private subnet need to grab something from outside like software updates, they use a net gateway. Think of it like a trusted concurge that allows them to fetch what they need from the street but keeps their office address hidden so uninvited visitors cannot get in. So as technical summary, AWSVPC lets businesses segment their cloud space into these isolated secure areas which is only dedicated to them. Further divided with subnets for different exposure levels and security needs with security groups as fine grained firewall policies. route tables to guide traffic flow and gateways to tightly control internet access or to act as the middleman as an interface to the public internet.

internet. So let's continue our network evolution story and let's switch contexts and imagine that shop easy ran all its operations in one giant factory. every team, payments, shipping, catalog and so on worked under the same roof and shared the same machinery. So basically a monolithic application in a VM. Any update meant pausing the entire factory making changes slow and risky affecting all the parts of the factory. As we grew, we realized that it was much smarter to break the factory into small independent workshops or workstations each focused on a single task like shipping, packaging, payment or managing inventory. And this is a shift to microservices. Instead of one huge system for everything, we now had teams specialized for each job. But if each workstation relied on the building to provide exact tools and supplies, we'd still face a problem. Like moving or replicating the workshop elsewhere would be a hassle, and updates could break if the new building didn't match the old setup. And that's where containers come in. A container is like a portable, fully stocked toolbox for each workstation. All the specific tools, supplies, dependencies, blueprints, a team needs are packed inside. And with this we can set up a new workstation on any factory floor. In other words, server or VM simply by unpacking the container. We don't care what equipment the building provides. The container comes ready to work. So with containers, every micros service is packaged together with all its dependencies, libraries, configuration, the operating system, environment configuration in a single unit. And this means we can deploy and run a service on any compatible server or cloud without worrying about what's installed and configured on underlying infrastructure. Now let's again look at how container networking works on top of VMs. Containers are like lightweight VMs that share the hosts operating system. So we have multiple VMs on the physical server and we then install multiple containers inside a single VM. The reason why containers are so lightweight is because they share the hosts or VMs, virtual hosts operating system kernel and only provide the isolated application layer on top of it. This means they don't need to boot the entire operating system like virtual machines. When they start, they just load the application layer on top of the existing kernel which is much faster and lightweight. So container images are measured in megabytes while VMs are measured in gigabytes. And Docker is the most popular container technology. But how do these containers communicate both with each other and with the outside world? That's where Docker networking comes in. By default, Docker sets up what's called a virtual bridge. Think of this as a private company hallway where all the toolboxes or containers on the same VM can talk to each other using their own unique desk phones or internal IPs. They can easily call each other directly and Docker's built-in phone book or DNS lets them connect by container name like dialing API or readies instead of memorizing the numbers the phone numbers or IP addresses. When shop easy expends to use several adjacent company buildings like multiple VMs or servers, Docker creates what's called overlay networks, special encrypted passages that seamlessly connect the rooms or containers from different buildings. So even if the containers are running in different VMs or servers, they can still talk to each other through the Docker overlay network. So in our analogy again, teams working different buildings of the same company can still communicate with each other even if they're in different places. So this enables reliable microser communication and scaling beyond a single virtual or physical machine. Now of course for containers that host web application or client-f facing front-end application, we need the outside world to access that container or the application that's running inside. And that's where container port mapping comes in. Containers are like own isolated machines with their own ports, right? So when a request comes to the VM that hosts the container, how does that request actually end up inside the container? Well, we map the host port, host being the VM where containers are running to the container port saying if a request comes to VM on port 80, then forward this request to container called web app on port 8080. It's like setting up a main receptionist at the building lobby which is the VM entrance who answers incoming calls on the building's main phone number. So public IP address port 80 let's say and then transfers them to the right internal extensions in this case port 80 to containers port 8080. For example, if we execute docker run with port mapping 80 to 8080. This tells docker to forward any calls coming to the port 80 to the containers port 8080 connecting outside traffic to the exact microser they need.

Now, as Shop Easy's digital operations grew, our agile teams found themselves launching tens, even hundreds of container toolboxes for all the shops, departments, and specialized tasks we created. And managing each of these toolboxes manually, figuring out where to put them, tracking which ones were running, and restarting any failed ones became like trying to supervise a bustling city block entirely by hand. It simply wasn't possible as we scaled up. That's when we hit the next phase and turned to container orchestration tool like Kubernetes. Just as a city brings in a master planner to coordinate where new buildings go, how traffic flows, and which shops open or close in response to real demand. Kubernetes acts as shop eased orchestrator. It knows every container's status, places new ones in the best available slots or servers, automatically restarts or replaces any failed ones, and dynamically scales up or down as business needs shift, which frees up our teams from manual container management and allows us to scale and grow continuously and reliably. So, how does Kubernetes networking work under the hood? A pod in Kubernetes is the smallest unit for running applications. It can have one or more containers that work closely together inside a pod. And every pod needs to communicate both with other pods and the rest of the infrastructure. To make this happen, Kubernetes gives each pod its own IP address. Just like an office gives each room its own unique phone number or door. All pods in the cluster are part of the same internal network. So one pod can connect directly to any other by using its IP even if they are on different machines. But setting up and managing all these network connections automatically is a big challenge and this is where the container network interface comes in also called CNI. So, Kubernetes uses a standard called CNI to automatically create a tiny virtual network cable, that's how you can imagine it, or virtual Ethernet interface for each pod. And this gives each pod its own unique IP address. So, it can talk to any other pod in the cluster, no matter which server it's on, without needing a router to translate addresses or extra setup by the user. So CNI is like the contractor that installs and plucks in the network cables for each new pod that gets created in the cluster. So when a new pod is scheduled, Kubernetes calls the CNI plug-in which plugs in this network cable for the pod giving it a virtual network cable or virtual Ethernet interface, assigns it a unique IP address and sets up the routes so that pod is directly reachable from anywhere in the cluster. So since every pod has its own network interface and IP address, even if pods are on different nodes, any pod can talk to any other pod inside the cluster as if they were on one flat companywide network or LAN, local area network. There's no need for port mapping or address translation and so on. However, even though each pod gets its own unique IP address, these IPs change whenever pods are restarted, moved or replaced. And pods are ephemeral. So that happens often. If another service tried to keep track of these changing addresses, it would be a mess. So to make things simple, Kubernetes gives us a service which is like a permanent company hotline. No matter how many employees or pods are working behind that hotline or if they change desks like IP addresses, the phone number stays the same. When someone calls the hotline, the service IP, Kubernetes distributes the calls to any available employee in that department, which means any healthy pod behind that service. So no one needs to know which desk they're at. And this load balancing is handled automatically by a piece called cube proxy using special routing rules to forward the call to whoever is available. So how do different teams in the company know how to call the right department? Well, Kubernetes has an internal phone book DNS where every service registers its name. For example, backend service. If the front end wants to reach the back end, it just calls backend service and Kubernetes takes care of connecting to the currently healthy pods behind that service even if the pods keep swapping in and out. This means developers don't have to worry about pod IPs changing. They just use simple neverchanging static names and connections that always work. Now again, we have all these services and pods inside cluster. But at some point we need to give outside clients access to the applications running within pods in the cluster. Right? And that's where Kubernetes ingress comes in. Ingress in Kubernetes is like a smart main entrance to your cluster. A single front door with a helpful receptionist. Instead of giving visitors a tricky map to every room or service inside to navigate, the receptionist looks at each guest's request, checks clear instructions, which are routing rules, and sends them directly to the right department like the web front end API or another internal app. Ingress can check the visitor's name or which door they knocked on like host name or path. provide secure connection, meaning it can make sure that the visitor is actually authorized to enter and talk to that specific service they're trying to connect to and make sure only right people get access without showing off all internal rooms to the public. And this way you have just one clearly managed entry point for outside users. And the ingress controller inside Kubernetes takes care of the rest which is efficiently directing traffic to the correct services and keeping your cluster both accessible and secure. By default, all the rooms or pods in Kubernetes can freely talk to each other, like having a building where every door is always unlocked. While this makes it easy for apps to communicate, it's not 100% secure, especially as your company grows and you want to keep sensitive areas private. And that's where network policies come in. These are services in Kubernetes that act like security guards and door locks in front of each pod or service. So you can write clear, detailed rules for who can come in or out of each room inside the office. For example, you may say only pods labeled as API server can enter the database room on port 5432. Everyone else gets blocked. You can set rules for incoming traffic. So it's like digital badge that based on your role gives you access to specific rooms in your office. You can set rules for incoming traffic like who's allowed in as well as outgoing traffic or who's allowed out. And these policies use things like pod names, labels, even name spaces to match the right rooms or sections of the rooms, and they work for both internal and sometimes external addresses. Once you apply a network policy, only the connections you allow are possible. Anything else is locked down in the background. Kubernetes uses built-in network features like IP tables or special plugins to enforce these rules. So in short, network policies in Kubernetes help you secure your cluster by letting you control exactly who can connect to what specific service locking the doors that should stay closed and opening just the ones your apps and teams really need, but also giving only specific people with specific authorization to walk into those doors. So to wrap up, Kubernetes networking starts with virtual network interfaces in every pod managed through CNI. It allows seamless pod-to-pod communication using services as unchanged endpoints, DNS for service discovery, ingress for controlled external access, and enforcing strict network policies for security.

security. From the days of plugging a single computer into the internet all the way to designing modern systems like Kubernetes, the basics of networking have stayed the same. even as the tools have become much more powerful and complex. So here are the fundamentals. Everything needs an address like an IP address. Rules control what traffic is allowed. These are firewalls, security groups, network policies. Names need to resolve to addresses, DNS, service discovery. Traffic needs routes to follow like routing tables. And if you get these basics like addresses, security rules, names, and phone books as well as routing, then you will feel comfortable troubleshooting any issues or designing new systems no matter if you're plugging in a physical server, setting up a VM, or building a modern cloud application like our shop easy on Kubernetes cluster. And as we saw in our simulated application example, each layer of abstraction actually adds powerful capabilities but also added complexity. And having a solid grasp of networking basics, the underlying fundamental knowledge of those building blocks so to say, actually helps you navigate that complexity with much more confidence. So, I hope this helped you a lot to build that foundation knowledge.