Why Kubernetes?

Kubernetes is driven by its API. Your CI/CD system can communicate with Kubernetes via its REST and CLI interfaces to carry out actions within the cluster. You can build staging environments. You can automatically deploy new releases. You can perform staged rollouts with atomic versioning and easy rollbacks in the event of issues. You can tear down environments when they're no longer needed. Whether you use Jenkins, Gitlab, Circle, Travis, or the CI/CD system of tomorrow, Kubernetes seamlessly integrates with it and guarantees that tasks will be executed the same way every time, without human error.

Kubernetes monitors the containers running within it, performing readiness and health checks via TCP, HTTP, or by running a command within the container. Only healthy resources receive traffic, and those that fail health checks for too long will be restarted by Kubernetes or moved to other nodes in the cluster.

Gone are the days of ramping up server capacity in anticipation of a surge of traffic. Kubernetes is ready for Oprah, ready for a viral news story, ready for anything. It scales by deploying more copies of the pods that run your application, or it can allocate more host resources to applications where spawning more doesn't make sense. It can even scale the cluster size up if you deploy more resources than the current cluster can safely handle, or down when those resources are no longer needed.

Kubernetes turns a promise of cloud computing into a reality. You don't need to know, care, or pay attention to where resources are running. You can control scheduling if you wish, but Kubernetes makes everything available by default. It handles the internal wiring between pod replicas, the common IP address that load balances across them, and the external addresses that make those resources accessible to the world. It adds and removes resources to keep applications available as the number of replicas grows or shrinks, or as application failures occur. When you deploy a microservice-style application into a Kubernetes cluster, it builds and maintains all of the routing and communication paths for you, no matter which node your application lands on.

The Kubernetes model is declarative. You create instructions in YAML that tell it the desired state of the cluster. It then does what it needs to do to maintain this state. When the cluster deviates, such as when you want more or fewer pods running for your application, it recognizes that the current state differs from the desired state, and it carries out actions to bring the cluster back to the desired state. There are no surprises. You tell it what to be, and it works to become that and exist that way until told otherwise.