[{"content":"","date":"18 Feb, 2024","externalUrl":null,"permalink":"/tags/devops/","section":"Tags","summary":"","title":"Devops","type":"tags"},{"content":"","date":"18 Feb, 2024","externalUrl":null,"permalink":"/tags/kubernetes/","section":"Tags","summary":"","title":"Kubernetes","type":"tags"},{"content":"","date":"18 Feb, 2024","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"18 Feb, 2024","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"This blogpost takes a deepdive into the series of events that transpire, when a Kubernetes pod is created\nHave you ever wondered what happens behind the scenes when you create a pod in Kubernetes? This blog post aims to unveil the intricate dance of events that unfolds from the moment you issue a command like kubectl run to the point where your pod is up and running.\nWe\u0026rsquo;ll break down the process into bite-sized steps, exploring various elements involved, including:\nClient-side interactions: How your command interacts with the Kubernetes API server. Authentication and authorization: Ensuring you have the necessary permissions to create pods. API communication: The exchange of information between different components. Worker node activities: Downloading images, launching containers, and managing resources. A pre requisite to this post is knowing about the distributed architecture of Kubernetes.\nWhy do I need to know this? # Understanding this process is crucial for both DevOps engineers and developers working with containerized applications in Kubernetes. Here\u0026rsquo;s why:\nFor DevOps Engineers: # Troubleshooting and debugging: A deeper understanding of pod creation enables efficient troubleshooting of deployment issues. Knowing the various steps involved helps pinpoint potential bottlenecks or errors that might occur during the process. Resource optimization: By understanding how pods are created and managed, DevOps engineers can make informed decisions about resource allocation, ensuring efficient utilization and cost optimization. Security considerations: Familiarity with the authentication and authorization aspects of pod creation empowers DevOps engineers to implement robust security measures and manage access controls effectively. For Developers: # Improved collaboration: When developers understand the underlying infrastructure, they can collaborate more effectively with DevOps teams, leading to smoother deployments and faster development cycles. Debugging deployments: Knowing the steps involved in pod creation allows developers to better debug issues related to their containerized applications and pinpoint problems within their code or configuration. Informed infrastructure decisions: Understanding the pod creation process empowers developers to make informed decisions about container image selection, resource requirements, and deployment strategies. By demystifying pod creation in Kubernetes, this series aims to equip both DevOps engineers and developers with the knowledge and understanding to navigate the containerized world with greater confidence and efficiency.\nThe process # So you just typed kubectl run myapp --image nginx:latest into your customised terminal with nerdfonts or a dull one with default prompt. Regardless, here\u0026rsquo;s what happens next:\nClient-side (kubectl): # User types and executes the command kubectl run myapp \u0026ndash;image nginx:latest. kubectl parses the command, identifying arguments like pod name and image. kubectl authenticates with the Kubernetes API server using configured credentials. kubectl constructs a REST API request targeting the Pods endpoint with the generated Pod manifest. API Server: # API server receives the request from kubectl. API server authenticates kubectl and authorizes the action based on configured policies. API server validates the provided Pod manifest against the Kubernetes Pod schema. Upon successful validation, the API server stores the new Pod object in its internal storage. Worker Node (kubelet): # Kubelet receives notification from the API server about the newly created Pod. Kubelet retrieves the Pod object details from the API server (if not already cached). Kubelet determines the image pull policy defined for the Pod (e.g., \u0026ldquo;Always,\u0026rdquo; \u0026ldquo;IfNotPresent\u0026rdquo;). If necessary, kubelet pulls the specified image (nginx:latest) from a container registry. Kubelet selects a suitable container runtime (e.g., Docker, containerd) based on configuration. Kubelet uses the container runtime to create a new container instance based on the image. Kubelet configures network namespaces and interfaces for the Pod and container. Kubelet sets up resource limits and requests based on the Pod specification. Kubelet starts the container within the Pod. Ongoing Management: # Kubelet continuously monitors the Pod and container health. Kubelet restarts the container if it crashes or fails liveness/readiness probes. Kubelet reports Pod and container resource usage metrics to the Metrics API for monitoring. Optional Service Exposure: # (If kubectl expose is used) Kubelet creates a Service object mapping the Pod\u0026rsquo;s internal IP to a cluster IP or load balancer. DNS records might be automatically created for accessing the service by name by kubeDNS or any other custom DNS controller (depending on configuration). Client-side Verification: # User can use kubectl get pods to verify the Pod creation and its \u0026ldquo;Running\u0026rdquo; state. For further details, kubectl logs can access container logs, and the API server allows querying various cluster resources.\nThe key learnings # Understanding the intricacies of pod creation in Kubernetes goes beyond mere theoretical knowledge. It empowers us to make informed decisions when designing applications and automating deployments. Here are some key ways to leverage this understanding:\nApplication Design: # Resource optimization: By knowing how resources are allocated during pod creation, developers can design their applications with efficient resource utilization in mind. This can involve choosing appropriate container images, optimizing memory and CPU usage, and defining clear resource requests and limits. Error handling and resiliency: Understanding the potential failure points during pod creation (e.g., image pull failures, container startup issues) allows developers to incorporate robust error handling mechanisms and build applications with inherent resiliency. Automation and CI/CD Pipelines: # Scripted deployments: Knowledge of pod creation steps enables the creation of scripts or tools that automate pod deployment workflows. This can streamline the process, reduce human error, and ensure consistent deployments across environments. Integration with CI/CD pipelines: By integrating pod creation automation with CI/CD pipelines, developers can achieve continuous integration and delivery, allowing for faster and more reliable deployments. Utilizing Kubernetes Hooks: # See: Container Lifecycle Hooks, Validating Admission Policy, Dynamic Admission Control for additional reading\nKubernetes API provides various hooks that allow injecting custom logic at specific points during the pod lifecycle. These hooks offer powerful capabilities for:\nPre-creation and post-creation validation: Utilize hooks to perform additional checks on pod specifications before and after creation, ensuring they adhere to security or compliance requirements. Resource injection: Inject environment variables, secrets, or configuration files into pods during creation using hooks, simplifying configuration management. Integration with external tools: Leverage hooks to trigger external tools or workflows upon pod creation or deletion, enabling actions like sending notifications or updating monitoring systems. Additional learning: Policy Enforcement with Tools like Open Policy Agent (OPA): # OPA is a popular policy engine that can integrate with Kubernetes to enforce policies during pod creation. Its uses the different Kubernetes hooks to validate configuration and enforce standards. By leveraging hooks and OPA, you can implement:\nSecurity policies: Define rules to restrict pod creation based on image sources, resource usage limits, or other security criteria. Compliance checks: Enforce compliance with organizational policies or regulations by evaluating pod specifications against predefined rules. Resource quotas: Set limits on the number of pods or resources that can be created within a namespace, ensuring efficient resource utilization and preventing resource exhaustion. Conclusion # Unveiling the intricate dance of pod creation in Kubernetes empowers both DevOps engineers and developers. This knowledge equips you to design efficient applications, automate deployments with confidence, and leverage powerful tools like hooks and OPA for enhanced security and control. As you delve deeper into the world of containerized applications, remember that understanding the foundations is key to building and managing robust and scalable deployments in the ever-evolving landscape of Kubernetes.\n","date":"18 Feb, 2024","externalUrl":null,"permalink":"/posts/what-happens-when-i-create-a-kubernetes-pod/","section":"Posts","summary":"","title":"What happens when: I create a Kubernetes Pod","type":"posts"},{"content":"","date":"18 Feb, 2024","externalUrl":null,"permalink":"/tags/what-happens-when/","section":"Tags","summary":"","title":"What-Happens-When","type":"tags"},{"content":"This blogpost is meant to initiate a conversation about DevOps Engineers and the value they bring with their automations\nEarly in my career, a senior developer challenged me with a question: \u0026ldquo;Isn\u0026rsquo;t DevOps just glorified support?\u0026rdquo;\nAs a recent graduate facing a sea of unfamiliar acronyms and complex automation processes, it felt like a jab. I wondered why building layers upon layers of automation seemed so important, and what real impact it had.\nInstead of accepting his statement at face value or getting defensive, I decided to take a different approach. Afterall this wasn\u0026rsquo;t just a random job I fell into; it was a conscious choice based on what I like to do and what skills I had. But before I could convince anyone else about the value of my work, I needed answers for myself.\nSo began my personal journey to understand not just the mechanics of DevOps, but the deeper purpose that went beyond lines of code and scripts.\nFast forward a few years, and I have a much clearer perspective than that bewildered graduate. In this post, I\u0026rsquo;ll share what I\u0026rsquo;ve learned, not just to debunk the \u0026ldquo;glorified support\u0026rdquo; myth, but to reveal the transformative power of DevOps.\nA Subjective definition # Enough has been said and written about DevOps by the experts over the years, and yet it is not possible to bind DevOps into a static definition. The reason why DevOps is so hard to define, boils down to \u0026ldquo;people are different\u0026rdquo;. People make teams, teams constitute an organisation and decide what tools they would use, what procedures they may follow, what standards they must hold etc. The variance in what DevOps means for different organisations hence makes binding DevOps into a genral definition very difficult.\nIts not that people have not tried. Just look at how Google talks about their way of DevOps that they have evangelised as Site Reliability Engineering. Its how a certain organisation \u0026ldquo;Google\u0026rdquo; happens to run their business and systems. They define their standards in objectives (SLOs) and they decide their own metrics (SLIs) to enforce adherence to their standards. Now, many other organisations have emulated or tried to emulate this approach to DevOps and ended up with their own versions of SRE that can be at times completely different from what Google or any other organisation for that matter, may see their SRE as.\nThen there is Platform Engineering, that abstracts away the infrastructre and lets people do what they are best at doing. So Devs can focus on building their applications, testing it and deploying it in a reliable way, while Platform Engineers making sure that the systems are resilient enough to handle the volume of changes required. But even the way that Platform engineering is implemented at different organisations is quite distinct.\nIn esssence you may find that even seemingly the most well defined and published implementations of DevOps, may have so many different versions. Its safe to say that even trying to define DevOps in terms of \u0026ldquo;what it containes\u0026rdquo; is futile. So instead, let me try to define DevOps in terms of its impact on an organisation. Essentialy, I\u0026rsquo;d define DevOps as an organisational firmware that does the following things:\nImproves the flow of work/changes by standardising and automating processes, improving the visibility of factors affecting the work and promoting collaboration and mutual understanding by sharing knowledge and responsibilities. Identifies and collects key metrics and feedback that is critical to business, and integrates it into the development process. Embraces the chaos of change by expecting failures and continuosly learning from failures. The above definition is a tradeoff between an exact definition, and a definition covering most if not all aspects of DevOps, in the favour of the latter. It is influcend by popular DevOps literature like The Pheonix Project, SRE Handbook and my own experiences of working with different teams and orgs.\nSo, what does it means to be a DevOps Engineer? # Since I defined DevOps in terms of its impact and outcomes, I\u0026rsquo;d say a DevOps Engineer is a professional who champions the changes that are needed to bring these outcomes. In bigger teams and orgs, this might becomcome blurred, since the responsibilities for implementing DevOps are greately distributed between different stakeholders like scrum masters, product owners, project managers, leads etc. This is actually the evidence that DevOps is quite mature now and needs less evangelising and more implementation within most orgs. Even without knowing what is the impact of your work as a DevOps Engineer, you might be able to contribute towards the DevOps goals of your team and org.\nHowever, only by knowing what DevOps stands for, can one truly see the impact and see if there is deviation and take corrective measures. You maybe writing and maintaining deployment pipelines, IaC, automation scipts or setting up monitoring, provisioning cloud resources using n umber of custom, open source tools, but in the end, how it impacts the business is what derrives the value of your work.\nI hope I was able to give a new perspective to how you see DevOps. Feel free to reach out if you want to talk more about this or anything else in tech.\n","date":"10 Feb, 2024","externalUrl":null,"permalink":"/posts/why-does-devops-matter/","section":"Posts","summary":"","title":"Demystifying DevOps: Why it's Not Just Fancy Plumbing","type":"posts"},{"content":"","date":"10 Feb, 2024","externalUrl":null,"permalink":"/tags/value/","section":"Tags","summary":"","title":"Value","type":"tags"},{"content":"","date":"10 Feb, 2024","externalUrl":null,"permalink":"/tags/why/","section":"Tags","summary":"","title":"Why","type":"tags"},{"content":" A DevOps Odyssey: Embracing Uncertainty, Fueled by AI # Welcome, fellow traveler, to a realm where the infinity loop spins in vibrant chaos, mirroring the ever-evolving landscape of DevOps. My journey began with quizzical glances, the term \u0026ldquo;DevOps Engineer\u0026rdquo; a whisper in the wind. Even now, its definition dances like a mischievous sprite, defying rigid structures.\nFor some, it\u0026rsquo;s a fancy cloak for the \u0026ldquo;ops\u0026rdquo; of old, others see it as a symphony of automation. Courses fling endless loops at you, interpretations galore, yet the essence lies in what your team, your tribe, defines it to be: a culture, a calling, a profession, or a harmonious blend of all.\nThis fluidity breeds whimsical combinations: MLOps, DataOps, AIOps, a dizzying dance of acronyms! While it might make seasoned veterans and wide-eyed newcomers alike stumble, within this uncertainty lies the true magic of DevOps\nNot knowing which tool, technology, or platform you\u0026rsquo;ll conquer next. Not being confined by processes, but propelled by an unending adventure. Building castles of code, resilient and scalable, weathering the storms of change. That, my friend, is the essence of being a DevOps professional.\nThe infinity loop whispers not just of software lifecycles and ever-morphing systems, but of the unceasing evolution of the teams, individuals, and organizations that embark on this path.\nOn this blog, I invite you to share my odyssey, to glean pearls of wisdom from my experiences, and to offer your own insights in return. For through shared stories, we collectively navigate this ever-changing terrain, growing wiser with each step.\nBut here\u0026rsquo;s the secret ingredient: a dash of AI magic, courtesy of Google Bard and its kin. These clever tools enhance my workflow, like a bard strumming melodies on the strings of efficiency.\nFear not, for every word here reflects my own expertise, my voice, honed through years of practice.\nAI acts as a catalyst, not a puppeteer! # It helps me delve into the mysteries of emerging technologies, dissect complex concepts, and draft tales of diverse DevOps landscapes. But I, the meticulous editor, curate and refine each phrase, ensuring it resonates with my unique perspective and adheres to technical truth. Code snippets and examples are scrutinized, battle-tested to ensure their integrity. AI is a tool to empower, not replace, my critical thinking and real-world experience. This AI-fueled efficiency allows me to weave richer narratives, offering:\nGlimpses into the future, exploringcutting-edge technologies and trends that shape the DevOps landscape. Concepts made clear, where AI-assisted drafting and editing unveil their intricacies. Real-world stories and case studies that bridge the gap between theory and practice. Remember, AI is but a tool in my toolbox, and I remain the architect crafting the content you see here.\nJoin me, fellow traveler, on this exciting journey where knowledge meets AI, and uncertainty fuels innovation! Let\u0026rsquo;s explore the uncharted territories of DevOps together, verse by verse, code by code.\n","externalUrl":null,"permalink":"/","section":"","summary":"","title":"","type":"page"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/blog/","section":"Blog","summary":"","title":"Blog","type":"blog"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":" DevOps Engineer - Cloud, IaC # shubham@devopsloop.in ∙ LinkedIn/shubham-om-sinha ∙ GitHub/devopsloop-ss ∙ View/Download as CV\nActive Certifications # Other / Past Certifications # AWS Certified DevOps Engineer - Professional CNCF Certified Kubernetes Application Developer Red Hat Certified System Administrator Red Hat Certified Specialist in OpenShift Administration Red Hat Certified Specialist in Ansible Automation AWS Certified Developer - Associate AWS Certified Cloud Practitioner Overview # DevOps Engineer with 7+ years of experience designing, automating, and scaling cloud-native infrastructure, CI/CD pipelines, and multi-cloud solutions for enterprise environments. Strong background in Infrastructure as Code (IaC) with Terraform, AWS and GCP cloud delivery, Kubernetes container orchestration, and developer enablement.\nSpecialized in converting manually managed environments into reusable, version-controlled IaC; building secure, repeatable deployment workflows; and implementing deployment patterns that improve release velocity, system reliability, and delivery pipelines. When not focused on critical delivery path tasks, I design and build custom automation utilities and developer tools—utilizing both traditional scripting and AI integration—to eliminate operational bottlenecks and elevate developer experience (DevEx) across teams.\nCore Skills # Cloud and Infrastructure: AWS, GCP, VPC, IAM, EC2, ECS/EKS, load balancing, networking, security controls, multi-environment infrastructure, cloud migration support\nInfrastructure as Code: Terraform, reusable modules, remote state, environment promotion, drift reduction, IaC migration, infrastructure review workflows\nDevOps and CI/CD Automation: GitOps (ArgoCD), CI/CD, GitHub Actions, Jenkins, release automation, configuration management, deployment verification, operational documentation\nContainers and Kubernetes: Kubernetes, Google Anthos, Helm, containerized application deployment, workload configuration, cluster operations, deployment troubleshooting\nAutomation and Operations: Bash, PowerShell, Ansible, Linux, incident support, runbooks, observability (Prometheus, Grafana, ELK Stack), compliance-aligned delivery, GitHub Copilot\nWays of Working: Agile delivery, cross-functional collaboration, architecture documentation, stakeholder communication, open source contribution, technical mentoring\nWork Experience # EPAM Systems (Sep 2024 - Present)\nRole: Senior System Engineer\nHighlights:\nEngineered application migrations and container workloads within a complex multi-cloud environment (MCOM), leveraging Jenkins, GKE, AWS EKS, and Google Anthos to establish secure, scalable orchestration platforms. Established GitOps continuous delivery patterns for GKE and EKS workloads using ArgoCD and GitHub Actions, automating cluster state synchronization and drift remediation. Designed and implemented secure secrets management systems using HashiCorp Vault, achieving strict access controls and credential rotating configurations. Optimized delivery workflows and accelerated code delivery by building end-to-end CI/CD pipelines utilizing Helm, JFrog Artifactory, and Google Artifact Registry. Enhanced platform observability and reduced incident resolution times by configuring comprehensive monitoring, alerting, and logging dashboards using Prometheus, Grafana, and the ELK Stack. Leveraged agentic workflows with GitHub Copilot to automate repetitive tasks, scripting utilities that optimized daily operational efficiency. Collaborated with cross-functional stakeholders and developers to resolve blockers, ensuring minimal downtime and seamless transitions during cutover and handover exercises. Skills: DevOps, Cloud Computing, Kubernetes, GKE, EKS, Anthos, GitOps, ArgoCD, Jenkins, Helm, JFrog Artifactory, Google Artifact Registry, HashiCorp Vault, Prometheus, Grafana, ELK Stack, GitHub Copilot, Multi-Cloud\nSourceFuse (Nov 2020 - Sep 2024)\nRoles: DevOps Engineer, Junior DevOps Engineer\nHighlights:\nLed the transition of legacy client AWS environments into version-controlled Terraform IaC, designing reusable modules that standardized provisioning and eliminated configuration drift. Architected and deployed production-ready CI/CD pipelines using GitHub Actions and Jenkins, automating multi-environment promotions and validation checks. Standardized Kubernetes deployments by implementing GitOps delivery pipelines with ArgoCD and Helm charts, reducing manual deployment errors. Built monitoring dashboards and alerting configurations using Prometheus and Grafana to track application performance and infrastructure health. Contributed to and maintained the organization\u0026rsquo;s open-source and internal reference architecture Terraform modules, reducing new environment provisioning times by 40%. Managed, deployed, and supported open-source and custom containerized applications on Kubernetes (EKS/GKE) and Helm, improving container scheduling efficiency. Partnered with client-side engineering teams, security officers, and architects to integrate platform services under strict design and compliance guidelines. Skills: Terraform, AWS, GitOps, ArgoCD, GitHub Actions, Jenkins, Kubernetes, Helm, Prometheus, Grafana, Bash, PowerShell, Linux, IaC migration, DevOps automation, open source\nDaffodil Software (Jan 2019 - Oct 2020)\nRole: Junior Associate IT (DevOps)\nHighlights:\nCollaborated on building scalable AWS and GCP cloud solutions, ensuring compliance, performance, and cost-efficiency. Standardized server configurations and accelerated developer onboarding by creating reusable Ansible playbooks and roles. Implemented and documented automated CI/CD pipelines to streamline application releases and testing workflows. Deployed, operated, and troubleshot development and staging Kubernetes clusters and containerized microservices. Authored architecture diagrams, runbooks, and recovery guides to ensure knowledge transfer and operational continuity. Skills: Ansible, Kubernetes, AWS, GCP, Linux, configuration management, cloud operations, technical documentation\nSelected Projects # Enterprise AWS Infrastructure Migration to Terraform\nScope: Supported an enterprise client in migrating manually created AWS infrastructure to Terraform. The work focused on reusable IaC design, environment consistency, reviewable change workflows, and automation around infrastructure deployments. Highlights: Migrated manually managed resources into maintainable Terraform code and reusable modules. Improved infrastructure consistency across environments by standardizing naming, configuration, and deployment patterns. Reduced reliance on manual console changes by introducing Git-based review and GitHub Actions driven Terraform workflows. Helped create documentation and handover practices for long-term client ownership. Internal Developer Platform and Reusable IaC Modules\nScope: Helped standardize infrastructure delivery across projects by building reusable Terraform components and supporting self-service patterns for engineering teams. Highlights: Improved developer productivity by making common infrastructure patterns easier to consume. Reduced environment setup effort through reusable IaC components and repeatable automation. Supported platform governance by encouraging consistent infrastructure defaults and code review practices. Contributed to open source module development and internal enablement documentation. Mission-Critical Backend API Platform for Enterprise 5G Infrastructure\nScope: Supported infrastructure and deployment automation for an enterprise 5G platform serving telecom infrastructure and compliance use cases. Highlights: Supported cloud infrastructure, CI/CD, and deployment workflows for a mission-critical API service. Improved operational readiness through automation, documentation, and environment consistency. Supported audit and security-aligned delivery practices for telecom requirements. Helped engineering teams troubleshoot deployments and reduce operational friction during delivery. Enterprise Multi-Wave Multi-Cloud Migration \u0026amp; Platform Orchestration\nScope: Orchestrated a multi-wave migration of application workloads and infrastructure for a complex multi-cloud environment, coordinating across multiple engineering teams and stakeholders. Highlights: Migrated legacy container workloads and microservices to GKE and AWS EKS managed by Google Anthos. Designed secure secrets management architectures with HashiCorp Vault and rotating credentials. Standardized release mechanisms by building Helm charts, ArgoCD GitOps configurations, and Jenkins CI/CD pipelines. Aligned migration waves across developer, security, and ops teams to guarantee zero-downtime cutovers. CV Keywords # DevOps Engineer, Cloud Engineer, Site Reliability Engineering, Infrastructure as Code, Terraform, AWS, Kubernetes, Helm, GitOps, ArgoCD, Prometheus, Grafana, CI/CD, GitHub Actions, Jenkins, Ansible, Bash, PowerShell, Linux, cloud migration, IaC migration, reusable Terraform modules, enterprise infrastructure, automation, release engineering, deployment automation, configuration management, cloud networking, IAM, security, compliance, operational documentation, runbooks, agile delivery.\n","externalUrl":null,"permalink":"/profile/","section":"","summary":"","title":"Shubham Sinha","type":"profile"}]