Understanding the Why of Kubernetes

I've noticed that it can be quite a challenge to articulate the benefits of Kubernetes to others who haven't already been lured into learning more about it so it was a delight to come across this talk which compresses the primary points in a very succinct manner

https://www.youtube.com/watch?v=ZuIQurh_kDk - Kubernetes Design Principles: Understand the Why - Saad Ali, Google

The copy-pastable highlights.

Understanding the Why of Kubernetes

• Declarative workload configuration - define the desired target state instead of imperatively defining steps to execute
• Where traditionally you need to have complex logic for setup, non-happy path recovery actions, etc. to maintain the correct state
• Deploying a workload: create API object that's persisted in master node, all components work in parallel to drive to that state
• -> automatic recovery! And without service specific implementation
• Ability to trivially roll back
• And even automated! Istio service mesh (built on top of K8S) e.g. provides automated canary deployments where certain amount of traffic is first directed to new service and it's monitored to see whether everything's working fine. Only after proving that new version if fine is majority / all of the traffic directed to the new version and old one deactivated entirely
• This has a significant implication that services running within pods can also be written with highly simplified error handling (especially if you use a container-optimized OS + appserver + libraries stack leading to very fast start times - any issue from lost db connection to stack overflow (remember pod memory limits though!) to entirely unexpected errors that would traditionally require complex state handling and recovery can also be externalized to the Kube layer)
• I.e. simplifies service implementation when creating Kube native microservices - potentially significantly
• Nodes can function individually - they pull info on what they should be doing from master periodically
• Master defines desired state of worker node. Worker nodes independently drive themselves towards those states
• Meaning that master node can go down and worker nodes can still continue normal operations from latest known configuration until master is up again and ready to server different configuration set for each worker node
• Master node stays simple and the entire system stays highly fault tolerant
• No single point of failure
• Like an OS for distributed systems, Kubernetes is a true abstraction layer to decouple distributed system app development from cluster implementation
• While previously cluster implementations were written per-system
• Kubernetes essentially acts as a separation of concerns abstraction layer
• Decouples system and app development from cluster development
• Similar to how prior to OSs applications were very hardware dependent and OSs promised "as long as you write app against these APIs it's portable between different machines", Kubernetes provides this same for writing distributed systems (where for a long time everyone was writing custom applications against custom cluster implementations)
• Kube's promise: as long as you write application against Kube API and as long Kubernetes exists on that cluster, the app doesn't need to be modified and can be moved around from cluster to cluster
• Cloud / cluster agnostic
• But still possible to consume cloud-specific services when that adds value via custom resource definitions
• Workloads can often be moved between clusters running on entirely different platforms / clouds (obviously assuming cloud-specific CRDs are not used)
• Very extendable
• Kubernetes as a term can already often be used to refer to a large ecosystem of open source and other products building on it (e.g. service mesh)
• No hidden internal APIs which is key enabler of the extendability