Now that we have learned a lot of details about the most important resources in Kubernetes, it is helpful to compare the two orchestrators, SwarmKit and Kubernetes, by matching the important resources. Here is the table:
|
SwarmKit |
Kubernetes |
Description |
|
Swarm |
Cluster |
Set of servers/nodes managed by the respective orchestrator. |
|
Node |
Cluster member |
Single host (physical or virtual) which is a member of the swarm/cluster.
|
|
Manager node |
Master |
Node managing the swarm/cluster. This is the control plane. |
|
Worker node |
Node |
Member of the swarm/cluster running application workload. |
|
Container |
Container** |
Instance of a container image running on a node. In a Kubernetes cluster, we cannot run a container. |
|
Task |
Pod |
Instance of a service (swarm) or ReplicaSet (Kubernetes) running on a node. A task manages a single container while a Pod contains one to many containers that are all sharing the same network namespace. |
|
Service |
ReplicaSet |
Defines and reconciles the desired state of an application service consisting of multiple instances. |
|
Service |
Deployment |
A deployment is a ReplicaSet augmented with rolling update and rollback capabilities. |
|
Routing Mesh |
Service |
The Swarm Routing Mesh provides L4 routing and load balancing using IPVS. A Kubernetes service is an abstraction which defines a logical set of pods and a policy by which to access them. It is a stable endpoint for a set of pods. |
|
Stack |
Stack ** |
Definition of an application consisting of multiple (Swarm) services. While stacks are not native to Kubernetes, Docker's tool Docker for Mac or Windows, will translate them for deployment onto a Kubernetes cluster. |
|
Network |
Network policy |
Swarm software-defined networks (SDNs) are used to firewall containers. Kubernetes only defines a single flat network. Every pod can reach every other pod and or node, unless network policies are explicitly defined to constrain inter-pod communication. |