One of the things that my team and I are sticklers about is using the proper terminology for the proper technology. It’s just not the debate of “Principle” vs “Principal”, it’s the inferred technology that is applied by the terms you use. For instance, if a client told me they had a Docker Cluster, I might infer they are using Kubernetes, as that is correct terminology. When, in fact, they may be using Docker EE and should have used the term Docker Swarm.
Recently, when I was learning more about Docker EE Swarm at DockerCon ‘19, I started to realize the concepts are similar in Kubernetes, but the terminology was subtly different. I started to put together my own cheat sheet of similar components, so that I could keep things straight between the different sessions I attended. Now, I can speak both Swarm and Kubernetes without mingling terms, something my team will certainly appreciate!
|Swarm Term||Kubenetes Term||Loose Definition|
|Swarm||Cluster||A group of machines that are running that provide high availability of containers.|
|Node||Cluster Member||Either a physical or virtual host that is participating within the Swarm/Cluster.|
|Manager||Master||Manages the strategy of how work is distributed within the Swarm/Cluster.|
|Worker||(Worker) Node||A participating member of the Swarm/Cluster that is providing compute capacity.|
|Container||Container||A standard unit of software that packages up code and all its dependencies, so the application runs quickly and reliably from one computing environment to another.|
|Task||Pod||A group of containers that are deployed together on the same host.|
|Service||ReplicaSet||Starts and manages the tasks/pods, ensuring the desired state.|
|Service||Deployment||Provides declarative updates to ensure the desired state is maintained.|
|Stack||Stack||A collection of services to run an application.|
|VIP||ClusterIP Service||The IP address representing the service definition.|