💚💚 💚 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.

CoreDNS and AWS VPC CNI in EKS: Understanding Internal and Upstream Flow When people start learning EKS networking, two components create the most confusion: CoreDNS AWS VPC CNI At first, they can look similar because both are involved when one service talks to another. But their jobs are very different. A simple way to understand them is this: CoreDNS tells your Pod where to send the request VPC CNI makes sure the request can actually travel there And once you understand upstream flow , everything starts making more sense. 1. CoreDNS: The Name Resolver Inside the Cluster CoreDNS is the DNS server running inside Kubernetes. Its primary job is to resolve internal service names like this: review-service.default.svc.cluster.local When a Pod calls another Kubernetes Service using its name, CoreDNS translates that name into an IP address. Internal service lookup flow Pod ↓ CoreDNS ↓ Service IP Diagram: Internal DNS resolution order...

EKS Add-ons Explained Through Real Traffic Flow In AWS EKS, Kubernetes doesn’t run in isolation. It depends on a set of add-ons to handle: networking DNS routing storage external traffic Instead of memorizing each component separately, the easiest way to understand them is: 👉 Follow a request as it flows through the system Flow 1: External Request → Your Application Let’s say a user opens your app in the browser. Step 1: Internet → Load Balancer https://your-app.com This hits an AWS Application Load Balancer (ALB) . Created by: AWS Load Balancer Controller Step 2: ALB → Kubernetes Ingress Ingress → Service The ALB routes the request based on rules defined in your Ingress. Step 3: Service → Pod (kube-proxy) Kubernetes needs to pick a Pod. This is handled by kube-proxy receives the request selects a Pod routes traffic using iptables/IPVS Step 4: Pod Receives Traffic (VPC CNI) The Pod already has a real VPC IP ad...

What Are EKS Add-ons? (Simple Explanation) When we create an EKS (Elastic Kubernetes Service) cluster, AWS automatically installs or expects some add-ons . These add-ons are important because Kubernetes alone does not know how to: connect to AWS network resolve DNS route traffic So AWS gives us these components to make the cluster work properly. Core EKS Add-ons 1. VPC CNI (Networking) Full name: Amazon VPC CNI What it does: It assigns an IP address to each Pod from the VPC subnet . Why it is important: Pods behave like real AWS resources inside your VPC. Example: A Pod may get an IP like 10.0.1.25 . 2. CoreDNS (DNS inside cluster) What it does: It converts a service name into an IP address. my-service.default.svc.cluster.local It also forwards external DNS requests to the VPC DNS resolver. 3. kube-proxy (Service routing) What it does: It routes traffic from a Service to the correct Pod . How it works: Uses iptables ...

AWS Load Balancer Controller Upgrade Guide: v2.x to v3.3 What is AWS Load Balancer Controller? AWS Load Balancer Controller is a Kubernetes controller that integrates Amazon EKS with AWS Elastic Load Balancing services. It watches Kubernetes resources and automatically creates or updates AWS load balancing resources based on the desired state defined inside the cluster. Instead of manually creating load balancers, listeners, target groups, and security group rules in AWS, teams can define Kubernetes resources such as Ingresses and Services. The controller then reconciles those resources with AWS. What Does It Manage? AWS Load Balancer Controller commonly manages: Application Load Balancers (ALB) Network Load Balancers (NLB) Listeners and listener rules Target groups Target registration and deregistration Security group rules Ingress resources TargetGroupBinding resources Beca...

Kubernetes Pod States (Phases) A Pod can be in one of these main states during its lifecycle. 1. Pending Pod is created Not running yet Waiting for: a node images to pull resources “I exist, but I’m not running.” 2. Running Pod is assigned to a node Containers are started Application is running (or starting) “I’m running on a node.” 3. Succeeded All containers finished successfully Common for Job-based Pods “I finished my work successfully.” 4. Failed One or more containers exited with an error The Pod will not restart itself “I failed and stopped.” 5. Unknown Kubernetes cannot determine the Pod state Usually caused by node communication issues “I don’t know what’s happening.” 6. Terminating (not an official phase, but important) Pod is being deleted Grace...

Understanding Kubernetes Workloads (and how this connects to taints, tolerations, upgrades, and PDBs) This explanation ties together Kubernetes workloads, Pods, controllers, taints & tolerations, upgrades, and PodDisruptionBudgets. taints , tolerations , upgrades , and PDBs . What is a workload in Kubernetes? (plain meaning) A workload is your application running on Kubernetes. But Kubernetes never runs an application directly. It always runs Pods . Workload → Controller → Pods → Containers What is a Pod (and why it matters) A Pod is: The smallest deployable unit One or more containers Always scheduled on a single node Critical rule from the docs: If the node where a Pod is running fails, that Pod is considered ...

Kubernetes Taints and Tolerations(with Node Affinity + EKS Upgrade Context) Kubernetes scheduling is the process of deciding which node runs a given Pod . This page explains how Kubernetes keeps Pods away from “inappropriate” nodes using taints (node-side restrictions) and tolerations (pod-side permissions), and how that relates to node affinity (pod-side attraction). 1) Core idea: attraction vs repulsion Node affinity (attraction) Node affinity is a property of Pods that attracts them to a set of nodes. You can express it as: Hard requirement (must match), or Preference (nice to have). Taints (repulsion) Taints are the opposite of node affinity. They allow a node to repel a set of Pods. Tolerations (permission) Tolerations are applied to Pods. A toleration allows the scheduler to schedule Pods onto nodes with matching taints. Important...

Understanding Argo CD Pods: Which One to Restart (and Why) When Argo CD behaves unexpectedly — sync stuck, UI showing wrong state, or deployments failing — the key is knowing which Argo CD pod actually does what . Restarting the wrong pod wastes time. Restarting the right one fixes the issue in minutes. Argo CD Core Pods Overview Run this command to see all Argo CD pods: kubectl -n argocd get pods You’ll typically see: argocd-application-controller-0 argocd-server argocd-repo-server argocd-dex-server 1. argocd-application-controller (The Most Important Pod) This is the brain and worker of Argo CD. What it does Compares Git state vs cluster state Executes syncs and deployments Applies manifests to Kubernetes Runs hooks and manages rollouts Updates application health and sync status Symptoms when it is broken Sync stuck or terminating another operation is already in progress Apps appear healthy but cannot deploy...

🟧☁️ AWS + 🌍 Global Accelerator (GA) + 🌐 Route 53 what they are and how they work together (especially for ALB/EKS). ☁️ AWS = Cloud platform 🌍 GA = Fast global routing + static IPs 🌐 Route 53 = DNS ☁️ What is AWS? AWS (Amazon Web Services) is Amazon’s cloud platform where you run servers, containers, databases, networking, DNS, monitoring, and more. EC2 (servers), EKS (Kubernetes), RDS (databases) ALB/NLB (load balancers), S3 (storage), Route 53 (DNS) What is AWS Global Accelerator? Global Accelerator (GA) improves availability and performance by routing users through AWS’s private global network to the nearest healthy endpoint . Key idea: Users hit GA (static Anycast IPs). GA picks the best Region/endpoint automatically. Static Anycast IPs (2 fixed IP addresse...

docker run -p 8080:5000 flask-hello Then open in your browser: http://localhost:8080 Step 6: Stop the container Press Ctrl + C in the terminal. Quick Troubleshooting Browser says “This site can’t be reached”: Make sure the container is running and you used the -p port mapping. Flask runs but not accessible: Confirm Flask is running with host="0.0.0.0" inside Docker (not 127.0.0.1 ). Port already in use: Try using a different host port, for example: docker run -p 9090:5000 flask-hello Next Post Ideas Docker image layers and caching (explained simply) Docker volumes : keeping data after a container stops Running the same container in Kubernetes (Pod basics)