Containers have more or less taken over the world of application, web APIs, mobile endpoints and other forms of deployment. They have become the currency, the "table stakes" and de-facto application deployment unit. Their raise to the fore has brought about a whole host of use cases which weren't practical or accessible in the world of "classic" paradigms of infrastructure and virtualization. Containers have also brought application deployment closer and more accessible to developers. But as more use cases, deployment styles and exponential adoption of containers was ongoing, a new set of problems began to surface: how do you manage the ever growing number of containers in a deployment? How do you make sure containers have the right resources, deployed to the right machine, running with the correct parameters, how do you scale in and out without disruption? How do you make sure in a fleet of X containers that they’re all running and in healthy state? Enter Kubernetes. Initially developed internally by Google to replace their own complex container orchestration and management framework. It had to meet all the stringent standards and mind-boggling scale that Google operates on, but from the get-go an effort was made to make the learning curve and developer experience as approachable as possible. At certain point the creators made the case to Google to release kubernetes to the open source community -- a crucial decision that has helped “k8s” (as it’s commonly referred to as) reach rock star levels of fame and mind share not just in the FOSS community but also across industries and businesses from small operations to gigantic multinational corporations with thousands of deployments.