Preface

If you read one of the other books in The DevOps Toolkit Series (http://www.devopstoolkitseries.com/), you already know that I am a huge fan of containers, schedulers, and orchestrators. The DevOps 2.0 Toolkit: Automating the Continuous Deployment Pipeline with Containerized Microservices (https://www.amazon.com/dp/B01BJ4V66M) started as an overview of many different DevOps tools and practices, with containers having an important, but not a decisive role. In the meantime, I fell in utter and complete love with Docker and Swarm, so I chose to write The DevOps 2.1 Toolkit: Docker Swarm: Building, testing, deploying, and monitoring services inside Docker Swarm clusters (https://www.amazon.com/dp/1542468914). By the time I finished it, I felt that some advanced topics were not explored and deserve a book on its own. The DevOps 2.2 Toolkit: Self-Sufficient Docker Clusters: Building Self-Adaptive And Self-Healing Docker Clusters (https://www.amazon.com/dp/1979347190) was born.

All those books were (directly or indirectly) focused on Docker Swarm, and I felt that Kubernetes deserves its own space. Truth be told, I was negative about it a few years ago. It was too complicated for most use cases. It was enough to try installing it and, after days of struggle, give up. However, Kubernetes has come a long way since then. Even though its founding principles are the same, with time, it became more mature, more straightforward, and much bigger. Today, it is the biggest and the most adopted container orchestration platform. Some of the most prominent software companies rallied around it. Many startups emerged with new solutions. The open source community behind Kubernetes is one of the biggest in the history of software development. The community is vibrant, fast moving, and with a lot of vested interest in seeing Kubernetes succeed. Even Docker chose to support it and join the community. Kubernetes has a bright future ahead, and no one should ignore it.

If you already chose a different container scheduler (for example, Docker Swarm, Mesos, Nomad, or something else), you might wonder whether it makes sense for you to invest time learning Kubernetes. I think it does. We should always be on a lookout for different solutions. Otherwise, we’re being forced to choose one blindly. No matter whether you decide to adopt Kubernetes or to stick with something else, I’ll argue that you should know how it works and what it offers. It’s all about making an educated decision.