Shubham Setia

𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 𝗢𝗽𝗲𝗻 𝗦𝘁𝗮𝗻𝗱𝗮𝗿𝗱𝘀 (𝗢𝗖𝗜, 𝗖𝗥𝗜, 𝗖𝗡𝗜, 𝗖𝗦𝗜, 𝗦𝗠𝗜, 𝗖𝗜𝗟) Kubernetes, the de facto standard for container orchestration, relies on a robust ecosystem of open standards. These standards are developed and maintained by the community and define how different components interact within the system 𝗞𝗲𝘆 𝗯𝗲𝗻𝗲𝗳𝗶𝘁𝘀 🔶 𝙄𝙣𝙩𝙚𝙧𝙤𝙥𝙚𝙧𝙖𝙗𝙞𝙡𝙞𝙩𝙮: Different vendors can create products adhering to the same standard, ensuring seamless integration. 🔶 𝙁𝙡𝙚𝙭𝙞𝙗𝙞𝙡𝙞𝙩𝙮: You can choose components and plugins from various vendors based on your specific needs. 𝗦𝘁𝗮𝗻𝗱𝗮𝗿𝗱𝘀 : 🔶 𝙊𝙥𝙚𝙣 𝘾𝙤𝙣𝙩𝙖𝙞𝙣𝙚𝙧 𝙄𝙣𝙞𝙩𝙞𝙖𝙩𝙞𝙫𝙚 (𝙊𝘾𝙄): Defines a standard for container image formats and runtimes. Popular examples include 𝘋𝘰𝘤𝘬𝘦𝘳, 𝘊𝘙𝘐-𝘖, 𝘢𝘯𝘥 𝘙𝘒𝘛 images. 🔶 𝘾𝙤𝙣𝙩𝙖𝙞𝙣𝙚𝙧 𝙍𝙪𝙣𝙩𝙞𝙢𝙚 𝙄𝙣𝙩𝙚𝙧𝙛𝙖𝙘𝙚 (𝘾𝙍𝙄): Establishes a consistent way for Kubernetes to interact with different container runtimes. CRI utilizes a plugin architecture, allowing support for various Runtime options like 𝘊𝘙𝘐-𝘖, c𝘰𝘯𝘵𝘢𝘪𝘯𝘦𝘳𝘥 etc 🔶 𝘾𝙤𝙣𝙩𝙖𝙞𝙣𝙚𝙧 𝙉𝙚𝙩𝙬𝙤𝙧𝙠 𝙄𝙣𝙩𝙚𝙧𝙛𝙖𝙘𝙚 (𝘾𝙉𝙄): Provides a specification and toolset for configuring network interfaces within containers. This plugin architecture enables Kubernetes to integrate with various network plugins like 𝘍𝘭𝘢𝘯𝘯𝘦𝘭, 𝘊𝘢𝘭𝘪𝘤𝘰, 𝘢𝘯𝘥 𝘞𝘦𝘢𝘷𝘦 𝘕𝘦𝘵. 🔶 𝘾𝙤𝙣𝙩𝙖𝙞𝙣𝙚𝙧 𝙎𝙩𝙤𝙧𝙖𝙜𝙚 𝙄𝙣𝙩𝙚𝙧𝙛𝙖𝙘𝙚 (𝘾𝙎𝙄): Facilitates communication between Kubernetes and diverse storage providers. Storage providers can develop CSI plugins that are compatible with various container orchestration systems. Examples 𝘈𝘞𝘚 𝘌𝘭𝘢𝘴𝘵𝘪𝘤 𝘉𝘭𝘰𝘤𝘬 𝘚𝘵𝘰𝘳𝘢𝘨𝘦, 𝘕𝘦𝘵𝘈𝘱𝘱 etc. 🔶 𝙎𝙚𝙧𝙫𝙞𝙘𝙚 𝙈𝙚𝙨𝙝 𝙄𝙣𝙩𝙚𝙧𝙛𝙖𝙘𝙚 (𝙎𝙈𝙄): Defines a standard for service meshes on Kubernetes, allowing consistent interaction with different service mesh implementations like 𝘐𝘴𝘵𝘪𝘰, 𝘓𝘪𝘯𝘬𝘦𝘳𝘥 etc 🔶 𝘾𝙤𝙣𝙩𝙖𝙞𝙣𝙚𝙧 𝙄𝙢𝙖𝙜𝙚 𝙇𝙞𝙗𝙧𝙖𝙧𝙮 (𝘾𝙄𝙇): This set of specifications defines how container images are stored, indexed, and distributed. Major container registries like 𝘋𝘰𝘤𝘬𝘦𝘳 𝘏𝘶𝘣, 𝘘𝘶𝘢𝘺.𝘪𝘰, 𝘢𝘯𝘥 𝘏𝘢𝘳𝘣𝘰𝘳 leverage CIL for sharing and reusing container images across various platforms and environments. #kubernetes #Containerization #Cloud

8

✨ Engineering, specially deploying and managing applications at scale is a very big challenging task. 🤔 Managed Kubernetes - EKS, AKS and GKE only solves half of the problem of managing the control plane of Kubernetes. It's still the work of your Devops / SRE / Backend engineers to do all these - - Upgrade K8s and node versions frequently - Build, manage, update Helm Charts as needed - Maintain and monitor your application status, debug any node/infra/network failures - Build and maintain a full logging, monitoring stack Devops is costly, either hire experienced devops engineers, or make your backend engineers learn all this (developer time cost) 💰💰

61

2 Comments

𝗥𝘂𝗻 𝗟𝗲𝗮𝗱𝗲𝗿 𝗘𝗹𝗲𝗰𝘁𝗶𝗼𝗻 𝗔𝗺𝗼𝗻𝗴 𝗣𝗼𝗱𝘀 𝗶𝗻 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 𝗟𝗲𝗮𝗱𝗲𝗿 𝗘𝗹𝗲𝗰𝘁𝗶𝗼𝗻: Some applications require specific processes to run only on a single Pod instance to avoid duplicate tasks. Kubernetes Deployments with multiple Pod replicas require a leader election process outside the Pods to ensure only one Pod performs these tasks. 𝗘𝘅𝗮𝗺𝗽𝗹𝗲 𝗨𝘀𝗲 𝗰𝗮𝘀𝗲𝘀: 🔶  𝙎𝙘𝙝𝙚𝙙𝙪𝙡𝙚𝙙 𝙏𝙖𝙨𝙠𝙨: Only one Pod should run batch processing, cache updates, etc. 🔶  𝙇𝙚𝙖𝙙𝙚𝙧-𝙊𝙣𝙡𝙮 𝙎𝙚𝙧𝙫𝙞𝙘𝙚𝙨: Sending notifications or triggering specific APIs that shouldn't be called multiple times. 𝘒𝘶𝘣𝘦𝘳𝘯𝘦𝘵𝘦𝘴 𝗟𝗲𝗮𝘀𝗲 𝘖𝘣𝘫𝘦𝘤𝘵 𝘤𝘰𝘮𝘦𝘴 𝘵𝘰 𝘵𝘩𝘦 𝘳𝘦𝘴𝘤𝘶𝘦!! Here's how leader election works using Leases: 🔶  𝙇𝙚𝙖𝙨𝙚 𝘾𝙧𝙚𝙖𝙩𝙞𝙤𝙣: The first Pod creates a Lease object using configurations such as Lease name, Pod name & namespace and updates the current timestamp along with the Lease duration. 🔶  𝙇𝙚𝙖𝙨𝙚 𝙏𝙧𝙖𝙘𝙠𝙞𝙣𝙜: The Lease object keeps track of the current leader Pod's name. 🔶  𝙇𝙚𝙖𝙙𝙚𝙧 𝙍𝙚𝙣𝙚𝙬𝙖𝙡: If the Leader Pod is still active, it renews the lease by updating the timestamp before it expires. 🔶  𝙇𝙚𝙖𝙙𝙚𝙧 𝙀𝙡𝙚𝙘𝙩𝙞𝙤𝙣: If the timestamp isn't updated, inactive replicas race to acquire the lock with its identity and assume the leader role. This process leverages the 𝙖𝙩𝙤𝙢𝙞𝙘 𝙣𝙖𝙩𝙪𝙧𝙚 𝙤𝙛 𝙆𝙪𝙗𝙚𝙧𝙣𝙚𝙩𝙚𝙨 operations to ensure that no two replicas can acquire the Lease simultaneously by keeping track of the 𝘳𝘦𝘴𝘰𝘶𝘳𝘤𝘦𝘝𝘦𝘳𝘴𝘪𝘰𝘯 field. Read more and Code snippet: https://lnkd.in/gatVJGzP & https://lnkd.in/gWNGht3J #Kubernetes #LeaderElection #Containerization

7

TLDR of Infra & Cloud Tooling Approaches in 2024: 1. Terraform* 2. Terraform as programming language code 3. Terraform apply in a loop running as a Kubernetes operator 4. High level application architecture compiled down to Terraform 5. Combining application architecture and application code into 1 6. Auto-generated terraform based on application code blog coming soon * Terraform the idea, not the actual implementation #InfrastructureAsCode #DevOps #CloudComputing #Terraform #Kubernetes

15

1 Comment

How Does Node.js Handle Different Client Requests in a Single Event Loop, and What Changes with NGINX as an Ingress Proxy? Node.js is built around a single-threaded event loop, ideal for handling I/O-bound tasks asynchronously. Let’s explore how it handles requests directly versus how it operates with NGINX as an ingress proxy. Node.js Without NGINX (Direct Handling) 1️⃣ Event Loop & Non-Blocking I/O:     Node.js processes each client request asynchronously, offloading I/O operations, allowing it to handle many connections efficiently. 2️⃣ Static Content:     Serving static files from Node.js can be inefficient and consumes resources that could be used for dynamic requests. 3️⃣ SSL/TLS Overhead:     Node.js can handle SSL/TLS natively, but this adds CPU load, reducing performance in high-traffic environments. 4️⃣ Connection Management:     Node.js is good at handling fast-moving connections but may struggle with long-running or slow connections, impacting its performance under heavy load. Benefits: - Simplicity and real-time communication. - Ideal for I/O-bound, fast-response applications. Cons: - Poor static file handling. - SSL adds load. - Limited scalability with direct connections. --- Node.js with NGINX as Ingress Proxy 1️⃣ Load Balancing:     NGINX distributes traffic across multiple Node.js instances, allowing for horizontal scaling and improved resource utilization. 2️⃣ Static File Handling:     NGINX handles static content, offloading it from Node.js and improving overall performance. 3️⃣ SSL Termination:     NGINX takes care of SSL/TLS encryption, reducing the CPU load on Node.js, especially under high traffic. 4️⃣ Connection Handling:     NGINX manages slow or idle connections, letting Node.js focus on active requests, improving concurrency. 5️⃣ Caching & Compression:     NGINX handles caching and compression, speeding up responses without adding extra work to Node.js. 6️⃣ Security Enhancements:    NGINX offers rate limiting, IP filtering, and protection against DDoS attacks, adding a critical layer of security. Benefits: - Scalability with load balancing. - Efficient static content serving and SSL offloading. - Advanced connection management and security. Cons: - Increased complexity with an additional layer to manage. - Resource overhead from adding a proxy. Conclusion: Without NGINX, Node.js is simple but can struggle with static content, SSL, and scalability. With NGINX, the system becomes highly scalable, efficient, and secure, making it ideal for production environments handling high traffic. #NodeJS #NGINX #LoadBalancing #WebPerformance #Scalability #Security

38

🚀 **Day 26 of 30-Day DevOps Interview Prep: Advanced Autoscaling Strategies in Kubernetes (Part 1)** 🚀 Today, we’re diving into advanced autoscaling strategies in Kubernetes. Autoscaling helps your applications handle fluctuating workloads efficiently, improving performance and resource utilization. Here’s a Q&A to guide you through the essential concepts: 1️⃣ **What is Horizontal Pod Autoscaling (HPA), and how does it work in Kubernetes?** HPA automatically scales the number of Pods in a deployment or replica set based on observed metrics like CPU and memory usage. It dynamically adjusts the number of running Pods to match the current workload, ensuring that your application has the resources it needs to handle traffic spikes while scaling down during low-traffic periods to save resources. 2️⃣ **What is Vertical Pod Autoscaling (VPA), and how does it complement HPA?** VPA automatically adjusts the resource requests and limits (e.g., CPU and memory) of Pods based on their actual usage. While HPA scales the number of Pods horizontally, VPA optimizes each Pod’s resource allocation vertically. This helps ensure that Pods are neither under- nor over-provisioned, improving resource efficiency and performance. 3️⃣ **How does Cluster Autoscaling work in Kubernetes?** Cluster Autoscaling automatically adjusts the number of nodes in your Kubernetes cluster based on the overall resource demands. When Pods cannot be scheduled due to insufficient resources, Cluster Autoscaling adds new nodes to the cluster. Conversely, when resources are underutilized, it scales down by removing unnecessary nodes. This helps optimize infrastructure costs and resource utilization. 4️⃣ **What are the best practices for combining HPA, VPA, and Cluster Autoscaling?** Combining HPA, VPA, and Cluster Autoscaling allows you to scale your applications and infrastructure efficiently. HPA scales Pods based on workload, VPA optimizes Pod resources, and Cluster Autoscaling adjusts the cluster size. Ensure that your resource requests and limits are configured properly to avoid conflicts between HPA and VPA. Additionally, monitor your scaling policies to ensure they respond effectively to traffic changes. 5️⃣ **How do you monitor autoscaling in Kubernetes, and why is it important?** Monitoring autoscaling is crucial for ensuring that your scaling strategies are working effectively. Use tools like Prometheus and Grafana to track metrics such as CPU usage, memory usage, and Pod scaling events. Set up alerts for scaling failures or unusual resource usage patterns, and regularly review your autoscaling logs to identify and resolve any issues. 👉 **Stay tuned for Part 2**, where we’ll cover advanced autoscaling strategies, including scaling for stateful applications, optimizing cost efficiency, and handling large-scale workloads in Kubernetes! #DevOps #Kubernetes #Autoscaling #Containers #InterviewPreparation #Learning

7

𝗜𝗻𝘁𝗲𝗿𝗲𝘀𝘁 𝗥𝗲𝗮𝗱 - 𝗞𝗮𝗿𝗽𝗲𝗻𝘁𝗲𝗿 𝗘𝗳𝗳𝗲𝗰𝘁𝘀   Came across this interesting blog https://lnkd.in/gvXvc4T7 about Karpenter effects.   Please read https://lnkd.in/g2XnwB7z previous post about Karpenter. 🔶 𝘾𝙡𝙪𝙨𝙩𝙚𝙧 𝙐𝙥𝙜𝙧𝙖𝙙𝙚𝙨 𝙖𝙧𝙚 𝙎𝙚𝙖𝙢𝙡𝙚𝙨𝙨   Without Karpenter, EKS-managed node groups have tight coupling between the control plane and node group upgrades. Any issue, like configuration errors or instance shortages, could cause failed stack upgrades and rollback loops.   With Karpenter, Control plane, and node pool upgrades are decoupled, the Control plane is upgraded at first, Karpenter asynchronously upgrades worker nodes by marking ‘Drifted’ tag if it does not match the target AMI Vesion. Drifted nodes are gradually replaced. 🔶 𝙁𝙞𝙣𝙚-𝙂𝙧𝙖𝙞𝙣𝙚𝙙 𝘾𝙤𝙣𝙩𝙧𝙤𝙡 𝙊𝙫𝙚𝙧 𝘿𝙞𝙨𝙧𝙪𝙥𝙩𝙞𝙤𝙣𝙨   Karpenter’s ability to respect Pod Disruption Budgets (PDBs) has been a significant improvement. The Cluster Autoscaler—even with the serialized option—would force-remove nodes after a short timeout, often leading to service disruptions. Karpenter works patiently within the disruption limits that are defined. 🔶 𝙁𝙡𝙚𝙭𝙞𝙗𝙞𝙡𝙞𝙩𝙮 𝙬𝙞𝙩𝙝 𝙄𝙣𝙨𝙩𝙖𝙣𝙘𝙚 𝙏𝙮𝙥𝙚𝙨   Karpenter abstracts away this complexity by defining instance requirements rather than instance types. It automatically selects the most appropriate and cheapest instances available. This flexibility mitigates the risk of instance exhaustion as well. It can dynamically migrate to cheaper/better nodes if they are available. 🔶 𝙀𝙣𝙝𝙖𝙣𝙘𝙚𝙙 𝙈𝙚𝙩𝙧𝙞𝙘𝙨 𝙖𝙣𝙙 𝙄𝙣𝙨𝙞𝙜𝙝𝙩𝙨   Karpenter provides a wealth of metrics. Drift detection, node disruption counts, and pod scheduling times are useful ones. 𝗖𝗵𝗮𝗹𝗹𝗲𝗻𝗴𝗲𝘀 𝘄𝗶𝘁𝗵 𝗞𝗮𝗿𝗽𝗲𝗻𝘁𝗲𝗿 🔶 𝙍𝙞𝙜𝙝𝙩 𝙘𝙤𝙣𝙛𝙞𝙜𝙪𝙧𝙖𝙩𝙞𝙤𝙣 𝙤𝙛 𝙋𝙤𝙙 𝘿𝙞𝙨𝙧𝙪𝙥𝙩𝙞𝙤𝙣 𝘽𝙪𝙙𝙜𝙚𝙩 (𝙋𝘿𝘽)   Without PDBs, Apps could experience disruptions. At the same time, overly strict PDBs hinder maintenance. 🔶 𝙏𝙝𝙚 “𝘾𝙝𝙚𝙖𝙥𝙚𝙨𝙩 𝙁𝙞𝙧𝙨𝙩” 𝙋𝙞𝙩𝙛𝙖𝙡𝙡   While Karpenter’s cost-optimization is generally beneficial, it’s not always ideal. For example, the m5a instances were marginally cheaper($.01/hr) than m6a instances but m6a has significantly better performance. A possible workaround is to set a higher weight for 6th-generation instances neglecting the 5th-generation. 🔶 𝗦𝗰𝗵𝗲𝗱𝘂𝗹𝗶𝗻𝗴 𝗟𝗮𝘁𝗲𝗻𝗰𝘆   With Karpenter’s dense packing of nodes, there are fewer idle resources available at any given time. When a sudden demand spike occurs, there may not be an immediate capacity to schedule new pods, waiting for karpenter to provision nodes. One possible option is to use PriorityClass to schedule lower-priority placeholder pods that can be preempted when higher-priority pods need to be scheduled.

10

🚀 Init ➡ Plan ➡ Apply ➡ Certified ✅ (For non-Terraformers, this is the typical Terraform workflow!) From writing my first .tf file to getting hands-on with Infrastructure as Code, I’m excited to share that I’ve leveled up with the HashiCorp Terraform Certified Associate certification! 💻🌍 View my verified achievement from HashiCorp.

22

6 Comments

Refreshing Kubernetes Secrets with HashiCorp Vault Agent The HashiCorp Vault Agent plays a crucial role in managing Kubernetes secrets by automating the process of updating and rotating secrets without requiring manual intervention or changes to application code. It leverages Vault's dynamic secrets capabilities, ensuring that secrets such as API keys and database credentials are always current and securely stored. This not only enhances security by minimizing the exposure time of sensitive information but also simplifies operations, allowing developers to focus on building features rather than managing security configurations. #HashiCorp #Kubernetes #DevOps #VaultAgent #CyberSecurity

21

I am receiving interview calls from both MNCs and start-up companies, and recruiters have focused on advanced technical questions as well as situational scenarios related to #Kubernetes. These are some of the questions they have asked me in the interviews. 1.    How do you use Helm in Kubernetes? 2.    What is the difference between a DaemonSet and a Deployment? 3.    How do you handle logging and monitoring in Kubernetes? 4.    What strategies do you use for managing secrets in Kubernetes? 5.    How do you perform rolling updates and rollbacks in Kubernetes? 6.    How do you troubleshoot a failing Kubernetes Pod? 7.    What steps would you take to resolve a node issue in a Kubernetes cluster? 8.     How do you debug network issues in Kubernetes? 9.    A specific Kubernetes Pod is consistently failing after deployment. Describe your troubleshooting steps. 10. You notice that the response time of your application has increased significantly. How would you investigate and resolve this performance issue within Kubernetes? 11.  One of your nodes in the Kubernetes cluster has gone down. What steps would you take to ensure high availability and minimal disruption to your services? 12. How do you integrate Kubernetes with CI/CD pipelines? 13. What tools do you use for continuous deployment in Kubernetes? 14.  How do you automate Kubernetes cluster maintenance and updates? 15. Your team wants to implement canary deployments to gradually roll out new features. How would you set this up in Kubernetes? 16.  During a security audit, you find that your Kubernetes cluster is not compliant with security best practices. What steps would you take to secure the cluster? #openforwork #devops #kubernetesinterview #experince

12

Test Driving SonarCloud on Kubernetes to understand the bugs it reports in Golang applications. https://lnkd.in/gm7WyNen * SonarCloud found 16,244 bugs with 16,244 false warnings/WONTFIX issues (100%). * Not a single serious bug is found. * SonarCloud missed one known high severity data race bug (https://lnkd.in/gVaxbNK2). * Triaging cost 2,707 hours ($351,910). * No improvement in quality. #sast #testdrive #sonarcloud #golang #opensource #sonarqube

7

2 Comments

Netflix Eureka. "Eureka" in the context of microservices typically refers to Netflix Eureka, which is a service registry for resilient mid-tier load balancing and failover of services. It is part of Netflix's open-source suite of tools known as Netflix OSS, designed to handle dynamic service discovery in the cloud. Here's a brief overview of what Eureka does and its role in a microservices architecture: Service Registration: Each microservice instance registers itself with Eureka server during startup. This allows Eureka to keep a real-time view of all active services and their locations (IP address and port). Service Discovery: Clients (other microservices or applications) can query Eureka server to discover available instances of a service. Eureka provides a dynamic list of available instances, which helps in load balancing requests among multiple instances of a service. Health Monitoring: Eureka server also tracks the status of each microservice instance (e.g., UP, DOWN, STARTING). This information is used to remove instances that are no longer responsive or to route traffic away from unhealthy instances. Client-Side Load Balancing: Eureka integrates with Ribbon (a client-side load balancer also from Netflix OSS) to provide load balancing capabilities when a client needs to make requests to a service. Ribbon uses the information from Eureka to dynamically locate available service instances. In summary, Eureka is crucial in microservices environments where services are constantly being created and removed, as it provides a centralized way to locate and manage these services dynamically. It promotes resilience and fault tolerance by ensuring that client applications can always find a healthy instance of a required service. If you're considering implementing microservices with Eureka, it's important to understand its architecture, integration with other Netflix OSS components (like Ribbon and Hystrix for resilience), and how it fits into your overall service discovery and communication strategy.

4

1 Comment

𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 𝘀𝗰𝗮𝗹𝗶𝗻𝗴 𝗘𝗳𝗳𝗶𝗰𝗶𝗲𝗻𝗰𝘆 𝘄𝗶𝘁𝗵 𝗞𝗮𝗿𝗽𝗲𝗻𝘁𝗲𝗿 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗞𝗮𝗿𝗽𝗲𝗻𝘁𝗲𝗿?           Karpenter is an 𝙤𝙥𝙚𝙣-𝙨𝙤𝙪𝙧𝙘𝙚 𝙆𝙪𝙗𝙚𝙧𝙣𝙚𝙩𝙚𝙨 𝙖𝙪𝙩𝙤𝙨𝙘𝙖𝙡𝙚𝙧 𝙩𝙝𝙖𝙩 𝙙𝙮𝙣𝙖𝙢𝙞𝙘𝙖𝙡𝙡𝙮 𝙖𝙙𝙟𝙪𝙨𝙩𝙨 𝙩𝙝𝙚 𝙘𝙡𝙪𝙨𝙩𝙚𝙧’𝙨 𝙘𝙤𝙢𝙥𝙪𝙩𝙚 𝙘𝙖𝙥𝙖𝙘𝙞𝙩𝙮 based on the workload requirements. It aims to provide a more flexible and efficient solution for managing the scaling needs of Kubernetes clusters. It is primarily built to work with Amazon Web Services (AWS) on its Elastic Kubernetes Service (EKS) or Self Managed Kubernets services. 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗖𝗹𝘂𝘀𝘁𝗲𝗿 𝗮𝘂𝘁𝗼𝘀𝗰𝗮𝗹𝗲𝗿 𝗮𝗻𝗱 𝘄𝗵𝗮𝘁𝘀 𝗮𝗿𝗲 𝘁𝗵𝗲 𝗹𝗶𝗺𝗶𝘁𝗮𝘁𝗶𝗼𝗻𝘀?           Before Karpenter, Kubernetes users relied on Amazon EC2 Auto Scaling groups and the Kubernetes Cluster Autoscaler (CAS) to dynamically adjust their clusters’ compute capacity. However, it comes with limitations. 𝗖𝗔𝗦 𝗟𝗶𝗺𝗶𝘁𝗮𝘁𝗶𝗼𝗻𝘀 🔶 𝗩𝗼𝗹𝘂𝗺𝗲 𝗡𝗼𝗱𝗲 𝗔𝗳𝗳𝗶𝗻𝗶𝘁𝘆 𝗖𝗼𝗻𝗳𝗹𝗶𝗰𝘁- For Stateful workloads, EKS uses EBS and EBS are zonal specific and can be attached to the EC2 in the same Zone only. CAS does not account for it by default and requires creating multiple auto-scaling groups specific to the zone, which is hard to manage. 🔶 𝗜𝗻𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝘁𝗼 𝗵𝗮𝗻𝗱𝗹𝗲 𝗱𝗶𝘃𝗲𝗿𝘀𝗲 𝘄𝗼𝗿𝗸𝗹𝗼𝗮𝗱𝘀: Traditional auto scalers often struggle to effectively balance resource needs when dealing with workloads that have varying resource requirements. 𝗪𝗵𝘆 𝗞𝗮𝗿𝗽𝗲𝗻𝘁𝗲𝗿?           Karpenter directly interacts with the EC2 Fleet API to manage EC2 instances. This allows Karpenter to provision nodes quickly and adaptively, based on actual workload requirements. It’s capable of scheduling pods on a variety of instance types and architectures, optimizing resource usage and cost-efficiency. Additionally, Karpenter considers the availability zone of EBS volumes when scheduling pods, avoiding the issue of orphaned nodes.           Karpenter applies three layers of constraints (bin-packing, Kubernetes constraints such as NodeSelector and affinities, EC2 pricing models, and availability) to select the right EC2 instance types. 🔶 𝗕𝗶𝗻-𝗽𝗮𝗰𝗸𝗶𝗻𝗴 𝗳𝗼𝗿 𝗯𝗲𝘁𝘁𝗲𝗿 𝗿𝗲𝘀𝗼𝘂𝗿𝗰𝗲 𝘂𝘁𝗶𝗹𝗶𝘇𝗮𝘁𝗶𝗼𝗻: Karpenter batches pending pods and then bin-packs them based on CPU, memory, and GPU requirements. 🔶 𝗘𝗳𝗳𝗶𝗰𝗶𝗲𝗻𝘁 𝗶𝗻𝘀𝘁𝗮𝗻𝗰𝗲 𝘁𝘆𝗽𝗲 𝘀𝗲𝗹𝗲𝗰𝘁𝗶𝗼𝗻: Karpenter leverages the EC2 Fleet and Spot Fleet APIs to evaluate all instance types, selecting the best node type for the pods. 🔶 𝗣𝗿𝗶𝗰𝗲 𝗖𝗮𝗽𝗮𝗰𝗶𝘁𝘆 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗲𝗱 𝗔𝗹𝗹𝗼𝗰𝗮𝘁𝗶𝗼𝗻 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝘆: The node provisioner uses cost-optimization strategies for both on-demand capacity and spot instances, combining the least interrupted and lowest price options. To read more - https://lnkd.in/gxjaGFnq #kubernetes #AWS #Cloud #SRE #Containerization

20

1 Comment

✅$terraform apply -target =certified 🚀Init ➡ Plan ➡ Apply ➡ HashiCorp Terraform Certified Associate ✅ Why Terraform? After spending quite some time working with Terraform, I decided it was time to get the Terraform Associate Certification by HashiCorp 💡 But what's it all about? Infrastructure as Code (IaC): Writing and managing infrastructure as code means fewer surprises and more control. Cloud-Agnostic Flexibility: Whether it's AWS, Azure, or GCP, Terraform has got you covered, making it easier to manage resources across different platforms. Version Control: Just like your code, you can version and track your infrastructure. Automation Power: Terraform automates infrastructure management, saving time and reducing errors. Seamless Collaboration: With a single source of truth for infrastructure, teams can collaborate more effectively and avoid costly misconfigurations. #Terraform #cloud #IAC #Prometeia

31

6 Comments

Preparing for a Microservices interview? Do check these most frequently asked patterns: 1. API Gateway: Routes client requests and handles authentication. 2. Service Registry: Tracks available services and instances. 3. Service Discovery: Allows services to find each other. 4. Circuit Breaker: Prevents cascading failures. 5. Service Mesh: Manages service-to-service communication. 6. Event Sourcing: Stores state as events. 7. CQRS: Separates data modification from querying. 8. Saga: Manages distributed transactions. 9. Strangler Fig: Gradual legacy system replacement. 10. Bulkhead: Isolates resources to prevent widespread failure. 11. Sidecar: Deploys additional functions alongside main services. 12. Adapter: Translates between different systems. 13. Database Per Service: Ensures independent scaling. 14. BFF: Optimizes backends for specific clients. 15. Decomposition: Breaks down monoliths into microservices. These patterns can help build resilient, scalable systems. Do connect with me here Ashish Barnwal 😊 #Microservices #SoftwareArchitecture #techinterviews

12

2 Comments

Kubernets 1.31 now truly vendor neutral platform !! What is it mean and how things going to affect The release of Kubernetes 1.31 marks the culmination of a significant migration effort to remove in-tree cloud provider integrations. Previously, Kubernetes supported cloud providers like AWS, Azure, and Google Cloud directly within its core code, which created vendor dependencies, increased complexity, and bloated the system. With the removal of these in-tree integrations, Kubernetes now relies on external cloud controller managers (CCMs), requiring users to deploy them separately for each cloud provider. This transition was a massive undertaking, involving the development of new subsystems such as the kubelet credential provider and storage migration. The migration successfully reduced the Kubernetes core by 1.5 million lines of code and decreased binary sizes by 40%. While it simplifies future Kubernetes development and makes the platform more cloud-neutral, it may require organizations to adjust their existing configurations and scripts to accommodate these changes. Key takeaways: 1. Removal of in-tree cloud providers in Kubernetes 1.31 simplifies the platform but breaks backward compatibility for cloud-provider arguments. 2. Users must deploy cloud controller managers (CCMs) separately for cloud integration. 3. The migration cut code size significantly, making Kubernetes more lightweight and secure. 4. Organizations need to adapt to new deployment methods, especially with the updated kubelet behavior and external integrations. #Kubernetes #Devops #cloud #AWS #Azure #GCP #docker #Security

6

𝗛𝗼𝘄 𝘁𝗼 𝗰𝗼𝗻𝗳𝗶𝗴𝘂𝗿𝗲 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 𝘄𝗶𝘁𝗵 𝗛𝗶𝗴𝗵 𝗔𝘃𝗮𝗶𝗹𝗮𝗯𝗶𝗹𝗶𝘁𝘆?              High Availability of the Kubernetes Control plan will ensure uninterrupted availability of applications running on the cluster worker nodes with all its functionalities such as Pod auto-failover, autoscaling, new deployment, etc. 𝗪𝗵𝗮𝘁 𝗛𝗮𝗽𝗽𝗲𝗻𝘀 𝗶𝗳 𝗖𝗼𝗻𝘁𝗿𝗼𝗹 𝗣𝗹𝗮𝗻𝗲 𝗙𝗮𝗶𝗹𝘀?              In the event of control plane failure, the exiting workloads on the worker nodes will continue to serve the requests. However, if there is a worker node failure or a pod failure occurs, pod scheduling activity or any update activity will not happen 𝗛𝗶𝗴𝗵 𝗔𝘃𝗮𝗶𝗹𝗮𝗯𝗶𝗹𝗶𝘁𝘆              The highly available Kubernetes control plane requires a 𝙢𝙞𝙣𝙞𝙢𝙪𝙢 𝙤𝙛 𝙩𝙝𝙧𝙚𝙚 𝙦𝙪𝙤𝙧𝙪𝙢 𝙘𝙤𝙣𝙩𝙧𝙤𝙡 𝙥𝙡𝙖𝙣𝙚 𝙣𝙤𝙙𝙚𝙨 with control plane components replicated across all three nodes. 𝗖𝗼𝗻𝘁𝗿𝗼𝗹 𝗽𝗹𝗮𝗻𝗲 𝗰𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁𝘀 & 𝗶𝘁𝘀 𝗮𝘃𝗮𝗶𝗹𝗮𝗯𝗶𝗹𝗶𝘁𝘆: 🔶 𝗘𝘁𝗰𝗱              Etcd is the primary datastore of Kubernetes cluster states. Etcd cluster needs a 𝙦𝙪𝙤𝙧𝙪𝙢( (𝙣/2)+1 ) to agree on updates to the cluster state. It is recommended to have an odd number of members in a cluster. 3 𝙉𝙤𝙙𝙚 𝙘𝙡𝙪𝙨𝙩𝙚𝙧 𝙥𝙧𝙤𝙫𝙞𝙙𝙚𝙨 1 𝙣𝙤𝙙𝙚 𝙛𝙖𝙞𝙡𝙪𝙧𝙚 𝙩𝙤𝙡𝙚𝙧𝙖𝙣𝙘𝙚 and the 5 node etcd cluster provides 2 nodes failure tolerance. 🔶 𝗔𝗣𝗜 𝗦𝗲𝗿𝘃𝗲𝗿              Its active-active, a stateless application that interacts with etcd to store and retrieve data, multiple instances of API server can be run across the control plane behind a load balancer for the worker nodes and end user’s communications with the cluster. 🔶 𝐊𝐮𝐛𝐞 𝐒𝐜𝐡𝐞𝐝𝐮𝐥𝐞𝐫              It takes care of Pod scheduling activities and follows the Leader-election method, only one Instance can make the decision. Running multiple replicas will make others as followers and in the event of leader pod failure, a follower will be elected as a leader to take over the scheduling decisions. 🔶 𝗸𝘂𝗯𝗲-𝗰𝗼𝗻𝘁𝗿𝗼𝗹𝗹𝗲𝗿-𝗺𝗮𝗻𝗮𝗴𝗲𝗿              It is responsible for keeping the cluster in the desired state. It follows the Leader-election method. 🔶 𝗪𝗼𝗿𝗸𝗲𝗿 𝗡𝗼𝗱𝗲𝘀              It’s required to run multiple worker nodes that meet the capacity requirements of the application workload. In the event of worker node failures, the control plane will schedule the pods to the available worker node. Pic Credit: Kubernetes Docs & To read more https://lnkd.in/gx8V65MK #Kubernetes #SRE #Devops #Containerization #Highavailability #Containers

20

Hi All, We are seeking a talented and experienced Grafana Developer to join our dynamic team. 𝐆𝐫𝐚𝐝𝐞: Senior Associate (5-10 yrs) 𝐋𝐨𝐜𝐚𝐭𝐢𝐨𝐧: PAN India 𝐍𝐨𝐭𝐢𝐜𝐞 𝐏𝐞𝐫𝐢𝐨𝐝: Max 90 days 𝐍𝐨. 𝐨𝐟 𝐏𝐨𝐬𝐢𝐭𝐢𝐨𝐧𝐬: 2 𝐉𝐨𝐛 𝐃𝐞𝐬𝐜𝐫𝐢𝐩𝐭𝐢𝐨𝐧: As a 𝐒𝐢𝐭𝐞 𝐑𝐞𝐥𝐢𝐚𝐛𝐢𝐥𝐢𝐭𝐲 𝐄𝐧𝐠𝐢𝐧𝐞𝐞𝐫 (𝐒𝐑𝐄) specializing in 𝐆𝐫𝐚𝐟𝐚𝐧𝐚, you will play a crucial role in ensuring the reliability, performance, and observability of our systems. Your mission is to bridge the gap between development and IT operations, making sure our software systems run efficiently and seamlessly. 𝐑𝐞𝐬𝐩𝐨𝐧𝐬𝐢𝐛𝐢𝐥𝐢𝐭𝐢𝐞𝐬: 1. 𝑮𝒓𝒂𝒇𝒂𝒏𝒂 𝑬𝒙𝒑𝒆𝒓𝒕𝒊𝒔𝒆: 𝐈𝐧𝐠𝐞𝐬𝐭𝐢𝐨𝐧 𝐁𝐞𝐬𝐭 𝐏𝐫𝐚𝐜𝐭𝐢𝐜𝐞𝐬: Design and implement robust data ingestion pipelines using Grafana. Ensure efficient and reliable data collection from various sources. 𝐃𝐚𝐬𝐡𝐛𝐨𝐚𝐫𝐝 𝐂𝐫𝐞𝐚𝐭𝐢𝐨𝐧: Develop and manage Grafana dashboards to visualize metrics, logs, and traces. Collaborate with application teams to create meaningful visualizations. 𝐀𝐥𝐞𝐫𝐭𝐢𝐧𝐠 𝐚𝐧𝐝 𝐌𝐨𝐧𝐢𝐭𝐨𝐫𝐢𝐧𝐠: Configure alerts and notifications within Grafana to proactively identify incidents, anomalies, and performance bottlenecks. 2. 𝑶𝒃𝒔𝒆𝒓𝒗𝒂𝒃𝒊𝒍𝒊𝒕𝒚 𝒂𝒏𝒅 𝑻𝒓𝒐𝒖𝒃𝒍𝒆𝒔𝒉𝒐𝒐𝒕𝒊𝒏𝒈: 𝐀𝐩𝐩𝐥𝐢𝐜𝐚𝐭𝐢𝐨𝐧 𝐈𝐧𝐬𝐢𝐠𝐡𝐭𝐬: Collaborate with development teams to instrument applications and services for metrics, logs, and traces. Provide insights into application behavior and performance. 𝐈𝐧𝐟𝐫𝐚𝐬𝐭𝐫𝐮𝐜𝐭𝐮𝐫𝐞 𝐌𝐨𝐧𝐢𝐭𝐨𝐫𝐢𝐧𝐠: Monitor infrastructure components (servers, databases, network) using Grafana. Troubleshoot issues and optimize resource utilization. 𝐈𝐧𝐜𝐢𝐝𝐞𝐧𝐭 𝐑𝐞𝐬𝐩𝐨𝐧𝐬𝐞: Investigate incidents, analyze root causes, and contribute to incident response processes. 3. 𝑩𝒆𝒔𝒕 𝑷𝒓𝒂𝒄𝒕𝒊𝒄𝒆𝒔 𝒂𝒏𝒅 𝑨𝒖𝒕𝒐𝒎𝒂𝒕𝒊𝒐𝒏: 𝐒𝐜𝐚𝐥𝐚𝐛𝐢𝐥𝐢𝐭𝐲 𝐚𝐧𝐝 𝐑𝐞𝐬𝐢𝐥𝐢𝐞𝐧𝐜𝐞: Implement best practices for scaling Grafana deployments. Optimize resource usage and ensure high availability. Automation: Automate routine tasks related to Grafana setup, configuration, and maintenance. 𝐂𝐈/𝐂𝐃 𝐈𝐧𝐭𝐞𝐠𝐫𝐚𝐭𝐢𝐨𝐧: Integrate Grafana into CI/CD pipelines for seamless deployment and version management. 4. 𝑪𝒐𝒍𝒍𝒂𝒃𝒐𝒓𝒂𝒕𝒊𝒐𝒏 𝒂𝒏𝒅 𝑲𝒏𝒐𝒘𝒍𝒆𝒅𝒈𝒆 𝑺𝒉𝒂𝒓𝒊𝒏𝒈: 𝐂𝐫𝐨𝐬𝐬-𝐅𝐮𝐧𝐜𝐭𝐢𝐨𝐧𝐚𝐥 𝐂𝐨𝐥𝐥𝐚𝐛𝐨𝐫𝐚𝐭𝐢𝐨𝐧: Work closely with development, operations, and other teams to align Grafana practices with overall system goals. 𝐌𝐞𝐧𝐭𝐨𝐫𝐢𝐧𝐠: Mentor team members on Grafana best practices, troubleshooting techniques, and observability principles. If you are passionate about Grafana development and eager to join our team, please submit your resume to 𝘺𝘰𝘨𝘦𝘴𝘩.𝘴𝘩𝘪𝘳𝘢𝘸𝘢𝘥𝘦𝘬𝘢𝘳@𝘤𝘰𝘨𝘯𝘪𝘻𝘢𝘯𝘵.𝘤𝘰𝘮 #sre #grafana #monitoring #observability #opening #job #cognizant

21

4 Comments

Hi 𝐂𝐨𝐧𝐧𝐞𝐜𝐭𝐢𝐨𝐧𝐬.....!!👋 #Usecase The main causes of issues in Kubernetes today are data loss and stability problems. This example will offer suggestions on how to use EFS instead of EBS in a Kubernetes setting, as well as how to manage pod data even after it's ended. Today's discussion focuses on below points with Usecase 1) How CSI Works 2) CSI in Kubernetes 3) How to create eks envionment 4) How to EFS drive integated with eks 5) Deploy the application in EKS 6) validation of efs after terminate the pods By practicing using the use case, you can gain a deeper understanding of EFS. The Container Storage Interface (CSI) is an industry-standard API specification designed to ensure compatibility between container orchestrators (like Kubernetes) and various storage systems. Developed by the Cloud Native Computing Foundation (CNCF), CSI simplifies and unifies how containerized applications interact with storage resources, providing a consistent, flexible way for containers to access, manage, and consume storage from different vendors https://lnkd.in/gud2F6ki 𝐇𝐚𝐩𝐩𝐲 𝐋𝐞𝐚𝐫𝐧𝐢𝐧𝐠 😀 ✨Follow me Sreekanth Kurapati on LinkedIn for interesting information and Quick Learnings.✨ Thank you to everyone who has been part of this journey! Let's keep pushing the boundaries of what's possible in the world of DevOps together. 👩‍💻ᴛᴇᴄʜɴᴏʟᴏɢʏ ɪɴꜱᴘɪʀᴇʀꜱ👩‍💻 Sabiha Ashik | Yujun Liang ⎈ ☁️| Gineesh Madapparambath | Bhuvaneswari Subramani | Bibin Wilson | Abhishek Veeramalla 💪#aws #devops #continuouslearning #awscommunity #learing #carrier #tcs #awsdevopsengineer

41