This topic describes the differences in the concepts used in Swarm and Kubernetes
In Swarm clusters, applications are similar to projects. One application consists
of multiple services. A service is an instance that provides specific functions of
an application. Services support horizontal scaling.
In Kubernetes clusters, applications are deployments that expose functions externally.
A deployment manages one or more pods and containers. Pods are the smallest deployable
computing units in Kubernetes. One pod may consist of multiple containers. A pod is
meant to run a single instance of an application. Pods support horizontal scaling
and can be scheduled to different nodes.
Note In the preceding figure, one pod consists of multiple containers. We recommend that
you use one pod to run a single container in practical use.
In Swarm clusters, a service is an instance of an application that provides specific
functions. When you create an application in a Swarm cluster, access to the application
services is directly exposed.
In Kubernetes clusters, service is an abstract concept. You can use services to expose
deployments to external users.
Access an application
When you create an application in a Swarm cluster, you can choose one of the following
methods to expose the application. All these methods enable external access to the
- Simple routing
- SLB routing
After you create an application in a Kubernetes cluster, you need to create services
to expose the application. To access an application from within a Kubernetes cluster,
you can use service names, which only support internal access. To access an application
from outside a Kubernetes cluster, you can create NodePort or LoadBalancer services
to expose the application.
- ClusterIP (Supports internal access)
- NodePort (Similar to <HostIP>:<port> in Swarm clusters)
- LoadBalancer (Similar to SLB routing in Swarm clusters)
- Domain names based on ingresses. (Similar to simple routing in Swarm clusters)