There is no doubt that Kubernetes is the de facto container cluster management platform. If we look back, the reason why Kubernetes won the container orchestration war, over many other solutions, is NOT because it abstracted out compute (CRI), storage (CSI), network (CNI) and then built an ecosystem around it, but because it makes application lifecycle management for container based applications a lot easier for devops, via a declarative desired state based management approach. What’s that mean? Developers can write a simple YAML file to describe application topologies in terms of pods, services, etc., and Kubernetes will use what is described in this YAML file to deploy the application and place the container services. “This is not a big deal”, you might say; “I can easily write some scripts to automate the container deployment, and many other solutions such as Docker Compose can do that too.” You’re right, but the eureka moment comes when you start to deal with day 2 operations. If a host has a hardware failure and all container services running on that host node have died, in seconds Kubernetes will detect the application’s current deployment status has deviated from the desired state and will automatically relaunch containers to match with the desired state again. In a conventional automation system, admins would have to set up many monitoring and alerting rules, as well as automation scripts, to achieve this kind of self-healing functionality. Then comes the upgrade cycle, where instead of writing scripts to handle updates, migrations, and orchestration if there are multiple steps and conditions involved, all you have to do is update the YAML with the latest version of application services and configurations, and voila!, with one command Kubernetes will reload the YAML and automatically handle all your container services updates. This really makes devops’ life much better, and you will finally have time to enjoy a cookie rather than becoming a late night script debugging warrior.