Kubernetes Simplified: Control Plane, Worker Nodes, and Application Layer

🚀 Day 24 of #DevOps— Understanding Kubernetes Architecture Today I took a deep dive into how Kubernetes actually works behind the scenes. Kubernetes is designed in a way that separates decision-making from execution. 🔹 Control Plane (The Brain) Responsible for managing the cluster and making decisions: - API Server → Central entry point, all requests pass through it   - etcd → Stores complete cluster state (pods, configs, data)   - Scheduler → Decides which node a new pod should run on   - Controller Manager → Maintains desired state (creates/replaces pods if needed)  🔹 Worker Nodes (The Execution Layer) Responsible for running actual applications: - Kubelet → Node agent that runs and monitors containers   - Kube-proxy → Handles networking and routes traffic to correct pods   - Container Runtime → Runs containers (e.g., Docker)   - Pods → Smallest unit where application containers run  🔄 How everything works together: When a user sends a request using kubectl, it reaches the API Server. The scheduler assigns a node, the controller ensures the correct number of pods, kubelet runs them, and kube-proxy manages traffic. 💡 Key Insight: Kubernetes doesn’t guarantee reliability by default — it provides the tools. Real stability depends on how well we configure scaling, resource limits, and health checks. This helped me understand that Kubernetes is not just about running containers, but about managing systems in a reliable and scalable way. #Kubernetes #DevOps #LearningInPublic #Backend #Cloud

CI/CD Pipeline Flow for FastAPI Microservices using Azure DevOps & Docker Here’s a clear view of how a CI/CD pipeline works in a microservices-based setup. The Workflow Break-down: Automated Triggers: The moment a developer pushes code to a target branch, Azure DevOps detects the change and initiates the pipeline. Ephemeral Agent Pods: Instead of static VMs, the build runs on Self-Hosted Agents inside a Kubernetes cluster. This ensures environment isolation and efficient resource usage. Dynamic Docker Builds: The pipeline executes the Dockerfile, creating a fresh image. Dynamic Tagging logic to ensure every build is unique, traceable, and version-controlled. Secure Distribution: Utilizing Docker Registry Service Connections, the sanitized image is securely pushed to Docker Hub, making it immediately available for deployment. This approach enables faster and more reliable builds, reduces manual effort, and brings consistency across environments. It also fits well with microservices architecture, where each service can be built and managed independently. #DevOps #Azure #AzureDevOps #Docker #CICD #Microservices #CloudComputing

After understanding Kubernetes architecture, the next question is — how do you actually master it? 👇 Getting good at Kubernetes isn’t about memorizing commands or copying YAML. It’s about understanding how everything fits together so you can build, deploy, and manage systems that actually scale. Here’s a structured way to approach it: 🔹 1. Core Objects 📦 Pods, Deployments, Services, StatefulSets, ConfigMaps, Secrets, PVCs 👉 Learn this to define and run applications 🔹 2. Controllers ⚙️ ReplicaSet, Deployment Controller, HPA, DaemonSet, CronJobs 👉 Learn this to automate scaling & self-healing 🔹 3. Architecture 🧠 API Server, etcd, Scheduler, Controller Manager, Kubelet 👉 Learn this to understand how Kubernetes actually works 🔹 4. Runtime 🚀 Docker, containerd, CRI-O 👉 Learn this to know how containers run under the hood 🔹 5. Security 🔐 RBAC, Network Policies, Service Accounts, Secrets 👉 Learn this to secure your cluster properly 🔹 6. Observability 📊 Probes, Metrics Server, Prometheus, Grafana 👉 Learn this to monitor health & performance 🔹 7. Extensibility 🧩 Helm, CRDs, Operators, Kustomize 👉 Learn this to customize Kubernetes for real-world use 🔹 8. Advanced (Webhooks) ⚡ Mutating & Validating Webhooks, OPA 👉 Learn this for advanced automation & policy control 💡 Pro tip: Don’t try to learn everything at once. Start with Core Objects → then move step by step. If you're in DevOps or Cloud, mastering Kubernetes gives you a serious edge 🚀 What part of Kubernetes are you currently learning? P.S: “If you missed my previous post on Kubernetes Architecture, I highly recommend checking it out — it’ll make this roadmap much easier to understand.” #Kubernetes #DevOps #CloudComputing #AWS #Containers #K8s #TechLearning #CareerGrowth

TGIF!!! Let me start your day with something I’ve been trying to understand better lately: Why Kubernetes actually exists? In this 5-minute read, I walked through the real pain points teams faced before Kubernetes not just running containers, but trying to manage them at scale. Things like: ⏺️ manual deployments ⏺️ systems breaking under traffic ⏺️ no clear way to coordinate multiple services And that’s really where Kubernetes comes in. Not as just another tool… but as a system designed to handle complexity scaling, recovery, and coordination automatically. This article helped me move from: “Kubernetes feels complex” to “Kubernetes actually makes sense.” 🔗 https://lnkd.in/eYq7eyqG #Kubernetes #CloudNative #DevOps #KCNA #cloudcomputing #Softwaredelivery #Backend

💡 Sharing a practical DevOps concept around environment consistency and production reliability. One of the most common (and frustrating) issues in production: 👉 “Works in Dev… fails in Prod” In most cases, it usually happens when there is : 🔺 Configuration mismatches 🔺 Different / In-compatible instance types 🔺Missing environment variables 🔺Manual changes outside or inside the pipeline. ⚙️ A few practical ways to handle this: ➡️ Infrastructure as Code (IaC): Defining both environments in code (Terraform, etc.) helps maintain consistency. Example: terraform plan -var-file=dev.tfvars terraform plan -var-file=prod.tfvars This makes it easier to compare desired states and catch differences early. ➡️ State Comparison: Exporting and comparing Terraform states: terraform show > dev.txt terraform show > prod.txt diff dev.txt prod.txt Gives a clear view of what’s actually different. ➡️ Script-Based Validation: Simple comparison scripts can help detect mismatches before deployment. ➡️ Cloud-Level Checks Using AWS CLI to compare resources across environments: aws ec2 describe-instances --profile dev aws ec2 describe-instances --profile prod 🚀 Typical workflow I’ve seen work well: 1. Define infra using IaC 2. Maintain separate configs for Dev & Prod 3. Run automated comparisons 4. Detect differences early 5. Trigger alerts before deployment ✅ What stands Out : 👍🏻 Keep Dev and Prod as identical as possible. 👍🏻 Avoid manual changes. 👍🏻 Automate everything you can. Because if Dev and Prod drift… production issues are just a matter of time. #DevOps #AWS #Terraform #Cloud #Automation #InfrastructureAsCode #CI_CD

🚀 Kubernetes Study Guide – From Basics to Real Production Concepts Kubernetes is not hard because of complexity. It’s hard because everything is connected. This guide explains Kubernetes step by step—from core concepts to real-world architecture—so you can understand how systems actually run in production. 📘 What this guide covers: ✅ Core Concepts (Foundation) • Containers, Pods, Nodes, Clusters • Deployments, Replicas, Services • Desired state and self-healing ✅ Architecture (How Kubernetes Works) • API Server, etcd, Scheduler, Controller Manager • Worker nodes: kubelet, kube-proxy • How control plane manages workloads ✅ Pods & Lifecycle • Pod structure and types • Pod states (Running, Failed, CrashLoopBackOff) • Why Pods are not created directly in production ✅ kubectl & YAML (Real Usage) • Common kubectl commands for daily work • YAML structure: apiVersion, kind, metadata, spec • Applying and managing resources ✅ Deployments & Scaling • Deployment → ReplicaSet → Pods flow • Rolling updates and rollback • Manual and auto scaling (HPA) ✅ Networking & Services • Pod networking model • ClusterIP, NodePort, LoadBalancer • Service discovery and load balancing ✅ Storage, Labels & Selectors • Labels for grouping resources • Selectors for linking services and pods • Persistent storage basics ✅ Microservices Architecture (Real Example) • Voting app architecture (frontend, backend, DB) • Service-to-service communication • Independent scaling of components 💡 Why this matters: Kubernetes is easier when you stop memorizing commands and start understanding flow. Once you see how Pods, Services, and Deployments connect, everything starts to make sense. 🎯 Best suited for: • Beginners learning Kubernetes • DevOps and Cloud engineers • Interview preparation • Engineers moving to microservices Follow Prasanjit Sahoo for more practical DevOps, Kubernetes, and cloud engineering guides. #Kubernetes #K8s #DevOps #CloudEngineering #Containers #SRE #Microservices

Complexity is easy, connectivity is hard. Understanding how the Control Plane actually manages workloads is what separates a beginner from someone who can handle real-world production. This is a great breakdown of the K8s ecosystem from the ground up.

🚀 Kubernetes Fundamentals – A Practical Cheat Sheet for Engineers If you're working in DevOps, Cloud, or Platform Engineering, understanding Kubernetes is no longer optional. It’s essential. Here’s a simplified breakdown of core Kubernetes concepts every engineer should know. 🔹 1. Architecture Kubernetes follows a master-worker (Control Plane + Worker Nodes) architecture. Control Plane: Brain of the cluster Worker Nodes: Where applications actually run 🔹 2. Control Plane Components API Server – Entry point for all operations etcd – Stores cluster state Scheduler – Assigns Pods to nodes Controller Manager – Maintains desired state 🔹 3. Worker Node Components Kubelet – Talks to control plane, manages Pods Kube-proxy – Handles networking Container Runtime – Runs containers 🔹 4. Pod (Smallest Unit) A Pod = one or more containers Shares storage, network, and namespace 🔹 5. Deployments & ReplicaSets Declarative way to manage apps Ensures desired number of Pods are running Supports rolling updates 🔹 6. StatefulSets Used for stateful apps (like databases) Provides stable identity and storage 🔹 7. Jobs & CronJobs Jobs → Run once (batch processing) CronJobs → Run on schedule 🔹 8. DaemonSets Runs one Pod per node Useful for logging, monitoring agents 🔹 9. Services (Internal Communication) Stable IP/DNS for Pods Enables load balancing inside cluster 🔹 10. Service Types ClusterIP – Internal access NodePort – Exposes via node LoadBalancer – External access (cloud) 🔹 11. Ingress Manages external HTTP/HTTPS routing Supports domain-based and path-based routing 🔹 12. Persistent Storage (PV & PVC) PV → Actual storage PVC → Request for storage 🔹 13. ConfigMaps & Secrets ConfigMaps → Non-sensitive config Secrets → Sensitive data (encoded) 🔹 14. Horizontal Pod Autoscaler (HPA) It automatically scales Pods based on metrics like CPU and memory usage. 🔹 15. Health Checks Liveness Probe → Restart if unhealthy Readiness Probe → Control traffic routing Key takeaway Kubernetes follows a declarative model. You define the desired state, and the system continuously works to match it. Whether you're preparing for interviews, working on real-world deployments, or building scalable systems, mastering these fundamentals gives you a strong foundation. What Kubernetes concept did you find hardest to understand when you started? #Kubernetes #DevOps #CloudComputing #AWS #Docker #Microservices #SRE #PlatformEngineering

Today I ran into a Kubernetes issue that perfectly reminds why debugging step-by-step matters in real DevOps work. I deployed an application, everything looked fine at first glance: Deployment created ReplicaSet created But… no pods were coming up At this point, it’s easy to assume: “Maybe scheduling issue? NodeSelector? Image problem?” But the actual issue was something completely different. After digging deeper using: kubectl describe rs I found this error: "failed calling webhook https://lnkd.in/dKT-fZjZ: service 'istiod' not found" 👉 Root cause: Istio sidecar injection was enabled on the namespace, but the Istio control plane wasn’t running. So Kubernetes wasn’t failing silently — it was actively blocking pod creation because the admission webhook couldn’t complete. 💡 Fix: Simply disabled Istio injection on the namespace: kubectl label namespace app-service istio-injection=disabled --overwrite Then restarted the deployment — and pods started running instantly. This was a good reminder: In Kubernetes, the problem is often not where you first look. #Kubernetes #DevOps #Debugging #Istio #Cloud #SRE

🚀 Why Kubernetes is Amazing (and Why You Should Care) Premise: Kubernetes is amazing because it turns chaos into control. In a world of microservices, containers, and distributed systems, managing applications manually is like juggling knives in the dark. Kubernetes brings order by introducing a declarative, automated, and self-healing system. You define what you want, and Kubernetes ensures it stays that way. It’s not just a tool—it’s a mindset shift from “managing servers” to “engineering systems.” 🔥 10 Upsides of Kubernetes Declarative Management – Define desired state, not steps Self-Healing – Restarts failed containers automatically Auto-Scaling – Handles traffic spikes effortlessly High Availability – Distributes workloads across nodes Portability – Run anywhere: cloud, hybrid, on-prem Efficient Resource Usage – Smart scheduling saves cost Rolling Updates – Deploy without downtime Microservices Friendly – Perfect for modern architectures Strong Ecosystem – Integrates with CI/CD, monitoring, security Platform Engineering Ready – Foundation for internal developer platforms 🧠 10 Must-Know Kubernetes Skills Core Objects – Pods, Deployments, StatefulSets kubectl Mastery – Debug faster, operate smarter YAML Proficiency – Small errors, big impact Services & Ingress – Understand traffic flow ConfigMaps & Secrets – Manage config securely Health Checks – Liveness & readiness probes Scaling Strategies – HPA, cluster autoscaling Networking Basics – DNS, CNI, communication flow Storage Concepts – PV, PVC, persistent workloads Troubleshooting – Logs, events, resource issues 💡 Stay Motivated Kubernetes can feel overwhelming—but that’s a sign it’s worth learning. Don’t try to master everything at once. Build small projects, break things, fix them, repeat. Every confusion today becomes clarity tomorrow. Consistency beats intensity. Keep showing up, and one day Kubernetes will go from “complex” to “second nature.” #Kubernetes #DevOps #Cloud #PlatformEngineering #SRE 😊