Kubernetes in Five Minutes
A self-inflicted challenge because I heard people dig Kubernetes in 2020
--
“If you can’t explain it simply enough, you don’t understand it well enough”.
Challenge accepted. Here’s my attempt to explain native components of Kubernetes in five minutes with the objective of covering concepts and resource types that will enable you to t̶a̶l̶k̶ ̶a̶b̶o̶u̶t̶ ̶K̶u̶b̶e̶r̶n̶e̶t̶e̶s̶ ̶l̶i̶k̶e̶ ̶y̶o̶u̶ ̶u̶n̶d̶e̶r̶s̶t̶a̶n̶d̶ ̶i̶t̶ understand Kubernetes and deploy applications at a basic level.
As a pretext, I’ve found it useful to think of Kubernetes-related work not as a collection of verbose YAML files defining strange kinds of resources, but as a set of abstractions representing common design patterns in application deployment.
To me, the areas that Kubernetes natively accounts for in logical — imo — order are:
- Hardware – Node
- Orchestration – Deployment, Job, CronJob, StatefulSet, DaemonSet
- Configuration – ConfigMap, Secret
- Persistence — PersistentVolumeClaim, PersistentVolume
- Execution – Pod, ReplicaSet
- Access Control – Namespace, ServiceAccount, Role, ClusterRole
- Exposure – Service, Ingress
Hardware
All software has one fundamental dependency: a machine to run on. We need hardware whether it’s our own computers or someone else’s and this abstraction comes in the form of a Node resource type.
- Node: Represents a logical machine/VM (eg. your computer, ec2 instance, a droplet).
Orchestration
After we’ve defined our hardware, we need a plan on how to deploy our application. Will it be a single instance? Do we need maybe two? When we need to update our application, should it be done one by one or all at once? Do we want it to be deployed across all our Nodes? Should it be run once every day at 3 AM? We need to orchestrate the deployment.
- Deployment: Long-standing workloads (eg. a server)
- Job: One-off workload (eg. a shell script/database migration task)
