Understanding ReplicaSets in Kubernetes

Dear Kubernetes expert, Yes, we all know Deployments manage ReplicaSets. But when was the last time you directly interacted with a ReplicaSet? A ReplicaSet ensures a specified number of pod replicas are running at any given time. But here’s the catch, most of us never create them manually because Deployments abstract them away. So why should you care? 👇 🔹 Debugging: Ever noticed orphaned ReplicaSets lingering after updates? Understanding their lifecycle is key. 🔹 Custom Controllers: Building advanced patterns like canary or blue/green deploys sometimes requires ReplicaSet-level control. 🔹 Rollbacks: They rely on ReplicaSets, especially when tracking Deployment history. 🔹 Fine-grained Management: Need precise control over selector behavior? ReplicaSets give you that flexibility, Deployments enforce immutability of selectors for stability. Tip: Want to observe how a Deployment handles ReplicaSets? Run a rollout and watch the creation of new ReplicaSets while old ones get scaled down. ______________________________________________________ 🔁 If you found this useful, repost to help others find it, sharing is caring. 👨💻 Tag someone learning anything and everything Cloud-Native, Kubernetes & MLOps. 💾 Save this post for future reference. I post daily insights here, and break things down deeper in my weekly newsletter. Subscribe to stay updated. ______________________________________________________ #Kubernetes #DevOps #CloudNative #ReplicaSet #K8sTips #SRE #hellodeolu #learnin

☸️ Kubernetes changed how I think about infrastructure. Here's why. Before K8s, our deployment process looked like this: → SSH into the server → Pull the new Docker image → Restart the container → Pray nothing breaks It worked. Until it didn't. After moving to Kubernetes (K3s for lightweight clusters, K8s for full production), our entire mental model shifted. Here's what actually changed: 1. Failures became expected, not feared K8s restarts crashed pods automatically. The cluster self-heals. You stop worrying about individual container death and start thinking about the desired state. 2. Deployments became boring (in a good way) Rolling updates. Zero-downtime. Blue-green strategies. What used to be a tense 2 AM window became a standard CI/CD pipeline step. 3. Scaling stopped being a manual task Horizontal pod autoscaling means the cluster responds to load. Not the on-call engineer. 4. GitOps made state auditable With Argo CD, every deployment is a Git commit. You can see exactly what changed, when, and why. Rollback is a git revert. 5. Observability got serious Prometheus + Grafana natively integrate. Suddenly, you have cluster health, pod metrics, and API response times all in one dashboard. The learning curve is real. The first time you debug a CrashLoopBackOff at midnight, you'll question your choices. But once the cluster is running? There's nothing like watching 20 pods spin up in seconds. What's been your biggest K8s lesson? 👇 #Kubernetes #DevOps #CloudNative #ArgoCD #Containers #Docker #GitOps #Prometheus #Grafana #Infrastructure

Kubernetes: CrashLoopBackOff at 2am The most dreaded status in Kubernetes: CrashLoopBackOff Pod starts. Crashes. Kubernetes restarts it. Crashes again. Repeat forever. It works perfectly in docker-compose. Breaks the moment it hits Kubernetes. Here's the exact debugging process that saved me: Step 1: kubectl logs <pod-name> → See the actual application error. This is usually enough. Step 2: kubectl describe pod <pod-name> → Shows events: image pull failures, resource limits hit, liveness probe failures Step 3: kubectl get pod <pod-name> -o yaml → Full pod spec. Compare against what you intended to deploy. In my case, Step 1 showed it immediately: sqlalchemy.exc.OperationalError: could not connect to server environment variable DATABASE_URL is not set The DATABASE_URL env variable was defined in docker-compose.yml. It was never added to the Kubernetes deployment YAML. docker-compose and Kubernetes don't share config. They never did. One missing environment variable. Six hours of confusion if you don't know where to look. Bookmark these three commands. You will use them every single week as a DevOps engineer. What's the Kubernetes error that took you the longest to debug? 👇 #Kubernetes #DevOps #Debugging #CrashLoopBackOff #CloudNative #SRE #PlatformEngineering

More on Docker learnings… Docker layers how each instruction in a Dockerfile creates a layer, making builds faster and more efficient when used correctly. This naturally led me to understanding cache optimization—how structuring Dockerfiles smartly can drastically reduce build times. Docker volumes Initially, containers felt ephemeral, but volumes showed how we can persist data and even share it across multiple containers—making stateful applications possible. Docker networking learning how containers communicate with each other seamlessly within isolated environments. It really simplifies building multi-service applications locally. Docker Compose. Probably one of the most practical tools—defining and running multi-container applications with a single command. No more struggling with setting up complex dependencies manually on local machines. #Docker #DevOps #LearningInPublic #SoftwareEngineering #Containers #BackendDevelopment

Day 44 of #100DaysOfDevOps I deployed a Kubernetes pod, got the YAML "right" — and still failed the task. We needed a pod that prints environment variables on startup — GREETING, COMPANY, and GROUP — using a bash image with a one-shot command and restartPolicy: Never. Simple enough. I wrote the manifest, triple-checked the env values, the command syntax, the restart policy. Looked clean. It wasn't. The pod name was print-envars-greeting. And I'd used the same name for the container too — out of habit. The requirement said the container name should be print-env-container. One field, buried in spec, completely overlooked. Changed it, reapplied, done. spec: restartPolicy: Never containers: - name: print-env-container image: bash command: ["/bin/sh", "-c", 'echo "$GREETING $COMPANY $GROUP"'] env: - name: GREETING value: "Welcome to" - name: COMPANY value: "xFusionCorp" - name: GROUP value: "Group" Kubernetes doesn't care that your logic is right. It cares that your spec matches exactly. In real clusters, a wrong container name breaks log queries, metric scraping, and sidecar injection — silent failures that surface at the worst time. Read the requirements like a contract. Every field is a clause. #Kubernetes #DevOps #KodeKloud #CloudEngineering #LearningInPublic

☸️ Understanding Kubernetes – 5 Core Building Blocks Before diving deep into Kubernetes, it's important to understand its core building blocks. These are the foundation of every Kubernetes cluster. 📦 1. Container A container is the smallest lightweight unit that runs your application. It packages: • Application code (binary) • Dependencies • Runtime environment Containers are managed by container runtimes like containerd. 🛑 Important: Kubernetes does NOT manage containers directly. ✅ It manages Pods, which run containers. 🧩 2. Pod A Pod is the smallest deployable unit in Kubernetes. • Contains one or more containers • Shares the same network and storage • Managed by controllers (like Deployments) to ensure reliability 👉 You never deploy containers directly in Kubernetes — you deploy Pods. 🖥️ 3. Node A Node is a machine (virtual or physical) where Pods run. Each node includes: • Container runtime (e.g., containerd) • Kubelet (agent communicating with control plane) • Kube-proxy (handles networking rules) 👉 Pods run on Nodes, and Nodes are part of a cluster. 🌐 4. Cluster A Kubernetes Cluster is a complete system that consists of: • Control Plane Nodes → manage the cluster • Worker Nodes → run applications All operations like deploying, scaling, and managing apps happen inside the cluster. 🛠️ 5. kubectl kubectl is the command-line tool used to interact with the cluster. With kubectl, you can: • View cluster resources • Deploy applications • Update or delete resources • Debug issues 👉 Think of kubectl as your remote control for Kubernetes 📌 Example Commands kubectl get pods kubectl get all kubectl apply -f app.yaml kubectl describe pod <name> Understanding these fundamentals is the first step toward mastering Kubernetes and building scalable, containerized applications. #Kubernetes #DevOps #Containers #CloudComputing #K8s #LearningInPublic

The Kubernetes mistake that wastes 30 minutes every day: Using a single kubeconfig file for multiple clusters. 😅 Here's what happens: → You run a command → Wrong cluster responds → You panic and double-check everything → Repeat 10 times a day The fix is simple: Separate config files (config.dev, config.uat, config.prod) Set KUBECONFIG to auto-merge them Use kubectl config get-contexts to verify ✅ Switch contexts explicitly: kubectl config use-context admin-dev Bonus: Install k9s for visual cluster management 🎯 Now I know exactly which cluster I'm working with. Time saved per week: ~2.5 hours ⏰ Accidental production changes: 0 🛡️ What's your approach to managing multiple clusters? Would love to hear what's working for you. 💬 #Kubernetes #DevOps #BestPractices

📅Day 2 of 30 | 💡Topic: Kubernetes Architecture (Simplified) | 🚀 From Zero to Kubernetes 🚀 Most engineers run Kubernetes… But very few understand what happens behind the scenes 👇 Kubernetes has 2 main parts: 🧠 Control Plane (Brain) • API Server → Entry point • Scheduler → Assigns Pods to Nodes • Controller Manager → Maintains desired state • etcd → Stores cluster data ⚙️ Worker Nodes (Execution) • Kubelet → Runs Pods • Container Runtime → Runs containers • Kube Proxy → Handles networking 🔄 Flow: kubectl → API Server → Scheduler → Node → Kubelet → Pod 🎯 Why this matters? ✔ Debug issues faster ✔ Understand scheduling ✔ Crack CKAD exam 🧠 CKAD Practice Question: 👉 You create a Pod using kubectl apply, but it stays in Pending state. ❓ Which Kubernetes component is responsible for assigning the Pod to a Node? A. Kubelet B. Scheduler C. Controller Manager D. Kube Proxy 👇 Drop your answer in comments 📚 Official Reference (for deeper understanding): https://lnkd.in/dJh6kZRa 📅 Day 3:  Install Kubernetes using Kubeadm (Production Style) 🚀 Follow for more Kubernetes | CKAD | DevOps | SRE content #Kubernetes #CKAD #DevOps #SRE #Cloud #Docker #LearningInPublic #K8s #PlatformEngineering

Deploying backend on Kubernetes and debugging real-world issues — Day 34 Deployed FastAPI backend using Kubernetes (Deployment + Service) as part of my DevOps platform. Faced real production-like challenges: - Health check failures due to DB dependency - Kubernetes using cached Docker images despite rebuilds Resolved by: - Redesigning /health endpoint to remove external dependencies - Forcing image updates using imagePullPolicy: Always - Debugging using kubectl logs and rollout restart Key learning: Health checks must be lightweight and independent. Image versioning and pull behavior are critical in Kubernetes. This step marks my transition from containerization to orchestration. Next focus: Deploying full system (frontend + backend) on Kubernetes Project: https://lnkd.in/gj4YWDis #DevOps #Kubernetes #Docker #CloudEngineering #Microservices

Kubernetes Is Declarative — Not Reactive Most teams interact with Kubernetes as if it executes commands. It doesn’t. 🧠 The Core Mental Model Kubernetes is not a system you tell what to do. It is a system you tell: what must be true ⚙️ The Shift Old model: • request resources • trigger actions • wait for results Kubernetes model: • declare desired state • controllers observe reality • system reconciles continuously 🔄 What Actually Happens You don’t deploy. You declare: • desired replicas • configuration • networking • dependencies Kubernetes: • schedules • creates • replaces • heals Without asking again. 🧩 The Hidden Mechanism Every component operates as: a reconciliation loop desired state ≠ actual state → system corrects deviation ⚠️ Why Reactive Thinking Fails If you treat Kubernetes as reactive: • scripts control behavior • manual fixes accumulate • drift becomes normal Result: no consistent system state 🎯 Declarative Systems Behavior When state is declared: • workloads become predictable • recovery becomes automatic • scaling becomes controlled • operations become repeatable ⚖️ The Real Distinction Unpredictable Workloads • ad-hoc changes • manual overrides • hidden dependencies Outcome: unstable clusters Declared Workloads • explicit state • enforced constraints • continuous reconciliation Outcome: operable systems ⚠️ The Dangerous Failure Mode Non-declarative systems: • do not fail clearly • do not fail consistently They: fail randomly 🧠 Final Insight Kubernetes does not execute your intent. It enforces: your declared reality Core Principle If your system is not declarative: You are not using Kubernetes. You are: issuing commands to infrastructure #Kubernetes #PlatformEngineering #CloudNative #GitOps #SystemDesign #DevOps