CoreDNS vs AWS VPC CNI in EKS: What Each Component Actually Does When working with Amazon EKS , two important components help your Kubernetes cluster communicate properly: CoreDNS and AWS VPC CNI . Both are part of the networking story, but they do very different jobs. CoreDNS helps pods find services by name, while AWS VPC CNI gives pods network connectivity using IP addresses from your AWS VPC. In simple words: CoreDNS answers: “What IP address belongs to this service name?” AWS VPC CNI answers: “How does traffic reach that pod over the network?” 1. What is CoreDNS? CoreDNS is the DNS server used inside Kubernetes. Its main job is to resolve Kubernetes service names into IP addresses. For example, if one pod wants to call another service using a name like: user-service.default.svc.cluster.local CoreDNS resolves that service name into the correct Kubernetes service IP. What CoreDNS Does Resolves Kubernetes service names Supports pod-to...

Understanding Kubernetes Probes Understanding Kubernetes Probes Kubernetes doesn’t just run your application — it constantly checks if your app is healthy and ready. This is done using Probes . Probes tell Kubernetes: Is the app alive? Is the app ready to receive traffic? Has the app finished starting? There are 3 Types of Probes Startup Probe → “Has the app started?” Readiness Probe → “Can it receive traffic?” Liveness Probe → “Is it still alive?” 1. Startup Probe Startup probe is used when your application takes time to boot. While startup probe is running, Kubernetes will NOT run readiness or liveness probes. Pod starts ↓ startupProbe runs ↓ If success → move to readiness If failure → keep retrying startupProbe: httpGet: path: /healthz/ port: 8000 failureThreshold: 20 periodSeconds: 15 Best for slow-starting apps (DB connections, migrations, etc.) 2. Readiness Probe Readiness probe determines...

What Happens When You Type a URL in the Browser? When you type a website like xxxxggg.com in your browser, a lot of steps happen behind the scenes in milliseconds. Your browser does not directly understand domain names. It needs to convert the domain into an IP address and then communicate with the server. Step 1: Browser Checks Cache The browser first checks if it already knows the IP address. Browser cache OS cache If found → skip DNS lookup Step 2: DNS Resolution If the IP is not cached: Browser → /etc/resolv.conf → DNS server The DNS server returns: xxxxggg.com → 142.x.x.x Step 3: TCP Connection Now the browser connects to the server using the IP address. Browser → Server IP (Port 80 or 443) This uses TCP (a reliable connection). Step 4: TLS Handshake (HTTPS only) If the site uses HTTPS: Browser verifies SSL certificate Secure connection is established This step ensures the communication is encrypted and safe...

What is HTTP and HTTPS? What Is HTTP and HTTPS? When you open a website, your browser needs a way to talk to the server. That communication happens using a protocol. Two common ones are HTTP and HTTPS . Simple idea: HTTP is the normal way a browser talks to a website. HTTPS is the secure version of that communication. What Is HTTP? HTTP stands for HyperText Transfer Protocol . It is a set of rules used by browsers and servers to exchange data. Example: http://example.com With HTTP, the browser sends a request to the server, and the server sends back a response. Browser → Request → Server Browser ← Response ← Server What Is the Problem with HTTP? HTTP is not secure because the data is sent in plain text. That means someone in the middle could potentially read the data. username=rekha password=1234 With HTTP, sensitive information can be ex...

How This Works in Kubernetes Now that we understand /etc/resolv.conf on a laptop, let’s see how the same concept works inside Kubernetes. Even inside a Kubernetes Pod, the system still uses /etc/resolv.conf . But instead of pointing to Google DNS or your router, it points to an internal DNS service. Example Inside a Pod Run this inside a Pod: kubectl exec -it <pod> -- cat /etc/resolv.conf You might see: nameserver 1xx.xx.0.10 search default.svc.cluster.local svc.cluster.local cluster.local options ndots:5 What Changed? nameserver → now points to CoreDNS search → helps resolve internal service names What is CoreDNS? CoreDNS is the DNS server inside Kubernetes. It knows how to resolve service names like user-service . --- Real Example in Kubernetes App inside Pod ↓ Checks /etc/resolv.conf ↓ Finds nameserver (CoreDNS) ↓ Asks: "What is user-service?" ↓ CoreDNS responds: user-service.default.svc.cl...

Why Do We Need /etc/resolv.conf ? When we use a website name like google.com , our computer cannot use that name directly. A computer really wants an IP address, something like 142.250.x.x . So the real question becomes: How does the computer know where to ask for that IP address? The Problem Humans like names such as: google.com github.com amazon.com But computers work with IP addresses. That means every time you use a domain name, your system has to convert that name into an IP address. The Role of /etc/resolv.conf The file /etc/resolv.conf tells your system which DNS server it should ask. It usually looks something like this: nameserver 8.8.8.8 nameserver 1.1.1.1 This means: “If I do not know the IP address for a website, ask 8.8.8.8 first. If that does not work, ask 1.1.1.1 .” A Real Example Let’s say you open: github....

💚💚 💚 Understanding RabbitMQ Classic Mirrored Queues and Quorum  Queues 💚💚 💚   I understood RabbitMQ only after I understood why Classic Mirrored Queues were replaced . When I first started learning RabbitMQ, I kept hearing: Classic Queues Classic Mirrored Queues Quorum Queues Raft Consensus Everyone said:  "Use Quorum Queues." But I couldn't understand why. To understand Quorum Queues , I first had to understand how Classic Mirrored Queues worked.