How HTTP and HTTPS Traffic Flows Through an AWS ALB to EKS When an application runs in Amazon EKS , users normally don’t connect directly to Kubernetes Pods. An AWS Application Load Balancer (ALB) sits in front of the application and receives incoming traffic. But where exactly are HTTP and HTTPS used? And if the user connects over HTTPS, does that mean the traffic stays HTTPS all the way to the Pod? Let’s follow one request from the browser to an application running in EKS. Imagine an application running with multiple Pods: The Basic Traffic Flow The ALB provides the entry point for traffic coming from outside the Kubernetes cluster. Before looking deeper into this flow, let's understand HTTP and HTTPS. What Is HTTP? HTTP Hypertext Transfer Protocol  is a protocol used by clients and servers to communicate. For example : http://app.example.com HTTP traffic is not encrypted. That means we generally don't want sensitive information such as passwords, authentication tokens,...

HTTP vs HTTPS : What’s the Difference?   Every time you open a website, use a mobile app, or call an API, a client and a server need a way to communicate. One of the most common ways they communicate is through HTTP. But when we browse the web today, we usually see HTTPS instead. So what is the difference?     What is HTTP?  HTTP stands for HyperText Transfer Protocol. Simply put, HTTP defines how a client sends a request to a server and how the server sends a response back. For example, imagine opening a restaurant menu online. Your browser might ask:  GET /menu The server receives the request and responds:  200 OK  The communication looks like this:  HTTP is the conversation happening between the client and server. By default, HTTP commonly uses port 80 .   The problem with HTTP HTTP by itself does not encrypt the communication .Think of it like sending a postcard. The message gets to its destination, but the contents aren't protected ...

Kubernetes Deployments vs. Argo Rollouts: How Traffic Really Switches Between Old and New Versions When I first started learning Kubernetes deployments, I understood the concepts of Rolling Update , Blue-Green , and Canary . But one question kept bothering me: How does Kubernetes actually switch users from the old version to the new version? Does it change the Service? Does it move traffic? Does it kill old pods first? After digging into Kubernetes and Argo Rollouts, I realized that understanding ReplicaSets, Services, and readiness probes makes everything much easier. Let's walk through it step by step. Standard Kubernetes Deployment A normal Kubernetes deployment uses a Deployment resource.  kind: Deployment The Deployment controller is responsible for updating your application. Suppose your application is currently running Version 1. Users │ Kubernetes Service │ ReplicaSet (Version 1) ├── ...

Understanding Kubernetes Service Account Tokens in EKS When a Kubernetes pod starts, it usually needs a way to securely communicate with the Kubernetes API Server. To make this possible, Kubernetes automatically creates and mounts a temporary authentication token into the pod. What Is kube-api-access? Inside every pod, Kubernetes creates a special volume like: kube-api-access-xxxxx This volume contains: Service Account Token (JWT) Cluster CA Certificate Namespace Information These files are mounted inside the container at: /var/run/secrets/kubernetes.io/serviceaccount/ How Pod Authentication Works Pod Starts ↓ Kubelet prepares pod ↓ Kubelet requests token from API Server ↓ API Server signs JWT token ↓ Token mounted into pod ↓ Container starts successfully What Is the Token? The token is a JWT (JSON Web Token) used for Kubernetes authentication. It identifies the pod and its service account. Example: { "na...

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

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

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