It’s a challenge to select right orchestration engine for developing containerized application. Architect and Developers have to think about numerous things like communication between containers, workload type, load balancing and much more.
It’s important to select the perfect orchestration engine before starting the development as features and limitations of a particular orchestration engine do affect a lot. So its important to carefully examine your product needs and select one which best suits your product.
Here, we will discuss kubernetes (k8s), Docker swarm and Mesosphere (Mesos) orchestration engine with their features and limitations. We are not going to discuss orchestration engines in details.
Kubernetes brings in a varied set of features which are useful in cluster-based deployments.
- Load balancing: Most capable method is Ingress, which operates by means of a controller in a specialized Kubernetes pod. Controllers have Ingress resource (A set of rules for traffic management)
- High Availability: According to the requirements rules can be added to Ingress resource
- Declarative system: Users can give the desired state of a system that’s required
- Cloud native application: k8s is web and cloud-native application friendly
- Big Cluster: Count of hosts more than or equal to 200, k8s works fine
Reasons to choose K8s
- K8s provide low latency between containers in terms of data transfer. Docker swarm doesn’t provide this.
- Replication Controller: If number of required services count for a critical service needs to be 5, and if any of this service goes down, then replication controller will bring up a new one immediately. Docker swarm doesn’t have this concept.
- Every resource in K8s has the metadata attached to it. It is required to keep track of all components attached to an application. Docker swarm doesn’t provide this property.
Apache mesos also has features similar to k8s for cloud-native deployments.
- Best at doing task-based and job-based workloads. It is able to run different frameworks concurrently like marathon, chronos.
- If your project requires Big-data house like Hadoop, then mesos is made for you.
- Load Balancing: Mesos-DNS work as load-balancer. To access applications, services have to surpass Mesos-DNS.
- High availability: This feature is applicable at the applications level
- Fault Tolerance: Mesos can handle tens or thousands of nodes without faults
- Gives assurance of high availability of resources to applications
Reasons to choose Apache Mesos
- If requirement says to schedule multiple giant workload types concurrently, Mesos can run Hadoop Marathon and Chronos all together. Eg. :If you have 50 giant workloads, mesos can handle it easily as compared to other systems
- If you have 10000+ node clusters: Cluster design is extremely scalable, and easily supports thousands of nodes.
- Cluster management: Swarm mode allows to connect multiple machines together (Manager & Worker ) to create a cluster that can host services. It will bring high-availability and elasticity.
- If several nodes are lost then cluster still work fine.
- Cluster provides addition, removal, promotion and demotion of nodes to the current load.
- Container Orchestration: you can declare service definition to push task scheduling to cluster.
- Service discovery & load balancing: Swarm mode includes load-balancing at kernel level so there is no need to handle it in generate ingress routes.
- Security: You can create secrets that are encrypted and never stored in memory. If a service granted secret is unencrypted and mounted in memory and if the service gets killed or stopped, the secret is flushed.
- Swarm is an imperative system (with declarative tools)
Reason to choose Docker Swarm
- If you like to use docker CLI and ecosystem tools. Swam provides native Docker API experience and compatibility.
- If the requirement is mix of cloud native and legacy applications in containers, swarm can run both applications designed for the cloud and legacy.
- For giant cluster, Swarm cluster design is extremely scalable and easily supports thousands of Nodes.
Process to choose one orchestration:
- Mesos developed by Apache Software foundation. Docker swarm by Docker Inc and Kubernetes by Google
- Docker swarm is the best for smaller projects, testing and if you are already in touch with docker container. For larger projects Kuberntes is the leader. At last, Mesos give industrial-grade solutions but it is complex in use
- Docker Swarm provides load balancing when pods present in container are running as service. K8s provides internal load balancing through any node. Mesos also provides load balancing
- K8s have concepts like Replica Sets, Pods and Stateful Sets not present in Docker Swarm
- Architectural difference k8s is a container orchestrator tool which manages containers, while mesos is like a cloud operating system which manages all resources of cloud which means it has more responsibility. Docker Swarm can be created by using of one or more than one Docker Engines. It uses swarmkit for orchestration. Mesos uses Master-Agent architecture.
- Docker Swarm is easy to setup whereas k8s takes time for installation. Mesos is also not too quick, it also takes time for installation.
- Swam is less customizable while K8s is highly customizable. Mesos is also customizable with the help of modules and it is also extensive.
- Networking model : Swarm uses Overlay network model, K8s uses flat networking space and Mesos uses container network interface (CNI)
- Storage used by Swarm is Volumes and k8s uses Persistent and Ephemeral. Mesos currently uses storage Local Resource Provider (SLRP)
- Large cluster: Swarm consider speed for strong cluster states. K8s provides scaling and container deployment at large clusters while not considering speed
- Scalability and performance are key features for Mesos. Swarm has the feature of fast container deployment and sacking in large container. K8s provides guarantee to cluster states in place of speed
- Swarm have low fault tolerance whereas k8s have high fault tolerance. Fault tolerance is one of the strength designed in architecture along with allowing scalability