Anil Yadav

In Kubernetes, HPA uses a fixed 10% tolerance for both scale-up and scale-down. Meaning, HPA waits for at least 10% change in CPU/memory usage before adding or removing pods For example, If you set 70% as the usage target, Kubernetes would only scale up if it went above 77%, and scale down if it went below 63%. Here is the problem with with fixed 10%? Sometimes you want the system to react quickly when traffic spikes. Other times, you want it to be more cautious to avoid constant scaling up and down. Now in Kubernetes v1.33 (alpha feature - HPAConfigurableTolerance), You can set separate tolerance levels for scaling up and scaling down. I have published a short guide with hands on example in my newsletter. 𝗥𝗲𝗮𝗱 𝗶𝘁 𝗵𝗲𝗿𝗲: https://lnkd.in/gyAJTMXS 10,000+ professionals read my DevOps newsletter I share deep dives and insights on Kubernetes, DevOps, Cloud, MLOps and GitOps ♻️ If you find this useful, Repost with your network! #kubernetes

289

7 Comments

#Kubernetes Journey – Day 8: Volumes & Persistent Volumes In Kubernetes, containers are ephemeral – once a Pod is deleted or restarted, its data is lost. That’s where Volumes & Persistent Volumes (PV) come into play. 🔹 Volume – Provides storage to a Pod, ensuring data is available during container restarts inside the same Pod. 🔹 Persistent Volume (PV) – A cluster-wide storage resource that exists independently of Pods. 🔹 Persistent Volume Claim (PVC) – A request made by a Pod to use storage from a PV. ✅ Key Takeaways: Volumes solve the ephemeral nature of containers. PVs abstract the underlying storage (NFS, AWS EBS, GCP PD, Azure Disk, etc.). PVCs let developers request storage without worrying about backend implementation. StorageClasses automate dynamic provisioning of volumes. 💡 Real-World Example: Imagine running a database Pod (MySQL/Postgres) – you cannot afford to lose data every time the Pod restarts. By using PVCs with PVs, you ensure your data persists reliably. #Interview Question for You: Q.What is the difference between Volume, PV, and PVC in Kubernetes? #Kubernetes #DevOps #CloudComputing #Containers #LearningJourney Pod → PVC → PV → Storage

60

6 Comments

𝐊𝐮𝐛𝐞𝐫𝐧𝐞𝐭𝐞𝐬 𝐑𝐨𝐚𝐝𝐦𝐚𝐩 𝟐𝟎𝟐𝟓 Kubernetes has become the de facto standard for container orchestration. But with so many moving parts, it is easy to feel overwhelmed. 𝐇𝐞𝐫𝐞 𝐢𝐬 𝐚 𝐬𝐭𝐞𝐩-𝐛𝐲-𝐬𝐭𝐞𝐩 𝐫𝐨𝐚𝐝𝐦𝐚𝐩 𝐭𝐨 𝐠𝐮𝐢𝐝𝐞 𝐲𝐨𝐮𝐫 𝐥𝐞𝐚𝐫𝐧𝐢𝐧𝐠 𝐚𝐧𝐝 𝐚𝐝𝐨𝐩𝐭𝐢𝐨𝐧 𝐣𝐨𝐮𝐫𝐧𝐞𝐲: 1. Core Components Start with the basics: * Pods, ReplicaSets, Deployments → Understand how apps run and scale inside Kubernetes. 2. Stateful Application & Data Management Learn to manage stateful workloads: * PersistentVolumes (PV), StatefulSets → Handle databases and apps that need stable storage. 3. Infrastructure & Control Plane Get into the Kubernetes brain: * Nodes, Controllers, Scheduler → Know how the cluster makes decisions. 4. Security & Identity Management Lock down your cluster: * RBAC (Role-Based Access Control), Network Policies → Secure communication and access. 5. Auto Scaling & Load Balancing Make your apps self-healing and elastic: * HorizontalPodAutoscaler, Ingress Controllers → Optimize performance and traffic flow. 6. Backup, Restore & Disaster Recovery Be prepared for failures: * Velero (Heptio Ark) → Protect data and plan for cluster recovery. 7. Networking Understand how services talk: * Services, DNS, CNI (Container Network Interface) → Ensure seamless cluster communication. 8. Package Management & Configuration Simplify deployments: * Helm, Operators → Manage apps like a pro. 9. Monitoring & Observability Gain deep visibility: * Prometheus, Grafana → Track health, performance, and troubleshoot effectively. 10. Continuous Integration & Deployment (CI/CD) Automate your pipelines: * Jenkins, GitLab CI/CD → Streamline deployments from code to production. 💡 𝐏𝐫𝐨 𝐓𝐢𝐩: Start small, master the fundamentals, and gradually move into advanced areas like security, observability, and automation. Kubernetes mastery is not a sprint - it is a strategic journey. 🌟 ♻️ Repost this to help your network get started ➕ Follow Jaswindder Kummar for more

137

26 Comments

Ever wondered how to protect your Kubernetes workloads during maintenance or node scaling? In this video, I break down Pod Disruption Budgets - what they are, why they matter, and how to configure them effectively. 💡 What’s Inside? ✅ Clear explanation of PDB concepts ✅ Real-world scenarios where PDB saves the day ✅ Step-by-step hands-on demonstration in Kubernetes ✅ Tips for avoiding downtime during voluntary disruptions Whether you’re a Kubernetes beginner or an experienced DevOps engineer, this session will help you confidently set up PDBs and keep your applications running smoothly. Watch now and level up your Kubernetes reliability game! #Kubernetes #DevOps #SRE #Cloud Native Computing Foundation (CNCF) #PodDisruptionBudget https://lnkd.in/dm4wCnUh

48

1 Comment

Normal Pod vs Secured Pod – Why Security Context Matters in Kubernetes In today’s cloud-native world, containers and Kubernetes have become the backbone of modern applications. But with great agility comes an equally important responsibility: security. As solution architects, we must not only design for scalability and performance but also embed security as a first-class citizen in our architecture. One of the most overlooked areas in Kubernetes is the difference between a Normal Pod and a Secured Pod. At first glance, both seem identical—they run workloads, expose services, and scale as needed. But under the hood, the security posture can make all the difference between a resilient system and an open door for attackers. 🔹 Normal Pod A normal pod often runs with default settings. This usually means the container may run as root, the filesystem is writable, Linux capabilities are not restricted, and host-level access is possible. While this works for development speed, it leaves the environment vulnerable. If compromised, such a pod could allow privilege escalation, lateral movement across the cluster, or even host takeovers. 🔹 Secured Pod A secured pod, on the other hand, is designed with defense-in-depth principles. It enforces a SecurityContext and Pod Security Standards such as: Running as a non-root user Using a read-only filesystem Dropping all unnecessary Linux capabilities Applying seccomp/AppArmor profiles to restrict system calls Enforcing resource limits to prevent denial-of-service attacks By shifting left and securing pods at the design stage, we significantly reduce the attack surface. This also aligns with compliance frameworks like CIS Benchmarks, PCI DSS, and zero-trust models. 🔑 Why does this matter at an architectural level? Because Kubernetes security is not just a DevOps problem—it’s an enterprise resilience challenge. When you standardize secured pods, you embed trust into your CI/CD pipelines, accelerate audits, and prevent costly breaches. More importantly, you enable teams to innovate faster without the constant fear of vulnerabilities. ✅ Takeaway: A normal pod may be enough to run an app, but a secured pod ensures that the app runs safely, responsibly, and compliantly. As architects and technology leaders, we must advocate for secure defaults and foster a culture where security is seen not as a blocker, but as an enabler of sustainable innovation.

28

1 Comment

You can code and run your MCP server remotely on Kubernetes. Here's how: 1. Write code which conforms to the MCP standards. What does this mean? it means, it should work with JSON RPC 2.0 and can process standard MCP methods such as tools/list should send the name and description of the tools, tools/call should be able to invoke the tools etc. These standards are defined by Anthropic 2. You can either code the methods for MCP yourself, which can be tedious. Or use MCP implementation with library like FastMCP 3. Run Dockerfile to create a container and save it in ECR 4. Deploy to the Kubernetes cluster such as in Amazon EKS, and expose it using a ALB via service or ingress. ALB and container support streamable HTTP out of the box, and works nicely 5. Invoke your MCP Server using the ALB Url. For Streamable HTTP, you need to initialize a session, and then use the sessionID for subsequent calls to do tool discovery, and tool calls Check out detailed step by step demo, along with related codes, and pros-cons of local vs remote MCP server: https://lnkd.in/eXKENy6R --- Get byte sized system design, behavioral, Gen AI, and other interview and career switch tips in weekly newsletter : https://lnkd.in/eG7XdHmN #genai #ai #systemdesign

293

31 Comments

🚀 Terraform vs Ansible – Same Same, But Different One of the most common mix-ups I see when people start in DevOps is between Terraform and Ansible. Both are automation tools, but they solve very different problems. ✨ Terraform – The Architect Defines Infrastructure as Code (IaC). Provisions servers, networks, and cloud resources. 👉 Example: “Create 3 EC2 instances behind a load balancer in AWS.” ✨ Ansible – The Chef Handles Configuration Management. Installs packages, applies configs, manages deployments, keeps apps running. 👉 Example: “Install Nginx, deploy my app, and keep the service up.” 🔑 The Analogy Terraform → Builds the restaurant 🏗️ Ansible → Prepares the food & keeps service running 👨‍🍳 When combined, they’re not competitors—they complement each other. Terraform lays the foundation. Ansible makes it usable. That’s where the real DevOps magic happens. ✨ #DevOps #Terraform #Ansible #Cloud #Automation

47

5 Comments