There are countless articles, discussions, and many communities chattering about Docker, Kubernetes, and Mesos. If you were listening to word of mouth, you might think that these three open source projects are fighting tooth and nail for container dominance. You may also believe that choosing one of them is as sacred as a religion — true believers will be true to their beliefs and will burn heretics who dare to consider alternatives.

That’s rubbish.

While all three technologies make it possible to deploy, manage, and scale applications using containers, they actually solve different problems and are rooted in very different contexts. In fact, these three widely used tool chains are different.

Instead of comparing the overlapping features of these rapidly iterating technologies, let’s revisit each project’s original mission, technical architecture, and how they complement and interact with each other.

Let’s start with Docker…

Docker started as a platform as a service (PaaS) provider called dotCloud. The dotCloud team found that it took a lot of work to manage dependencies and binaries across many applications and customers. So they combined some of Linux’s Cgroups and namespace capabilities into a single, easy-to-use package so that applications can run consistently on any infrastructure. This package is called a Docker image, and it provides the following functionality:

  • Encapsulate the application and dependent libraries in a software package (that is, a Docker image) so that applications can be consistently deployed across environments;
  • Providing git-like semantics, such as Docker push and Docker Commit commands, allows application developers to quickly accept this new technology and integrate it into existing workflows.
  • Define Docker images as immutable layers that support immutable infrastructure. Newly committed changes are kept separately as read-only layers, making it easy to reuse images and track change records. The layer also saves disk space and network traffic by only transmitting updates instead of the entire image;
  • The Docker container is run by instantiating an immutable image and a read-write layer that temporarily stores runtime changes, making it easy to deploy and extend multiple instances of the application.

As Docker became more and more popular, developers moved from running containers on laptops to running containers in production environments. Coordinating these containers across multiple machines requires additional tools, called container orchestration. Interestingly, the first container choreography tool to support Docker images (in June 2014) was Marathon of Apache Mesos (more on that later). That year, Docker founder and CTO Solomon Hykes recommended Mesos as “the gold standard for production clusters.” Before long, Mesos’s Marathon was joined by a host of container choreography technologies: Nomad, Kubernetes, and, unsurprisingly, Docker Swarm (which is now part of the Docker engine).

As Docker began to commercialize its open source file format, the company also began introducing tools to improve its core Docker file format and runtime engine, including:

  • Docker hub for public storage of Docker images;
  • Docker Registry stores private images;
  • Docker Cloud, for building and running container management services;
  • Docker data center as a commercial product embodies many Docker technologies;

Source: www.docker.com

Docker’s insight into encapsulating software and its dependencies in a single package is a game-changer for the software industry, just as the advent of mp3 reshaped the music industry. The Docker file format became the industry standard, Leading container technology vendors (including Docker, Google, Pivotal, Mesosphere, and others) formed the Cloud Native Computing Foundation f=”https://www.cncf.io/”> (CNCF), and “https://www.opencontainers.org/” > Open Container promotion union Open Container Initiative (OCI). Today, CNCF and OCI aim to ensure interoperability and standardized interfaces between container technologies, and to ensure that any Docker container built using any tool can run on any runtime or infrastructure.

Enter the Kubernetes

Google recognized Docker’s potential early on and attempted to provide container choreography “as a service” on the Google Cloud Platform (GCP). Google has a lot of experience with containers (they introduced Cgroups in Linux), but existing internal containers and distributed computing tools like Borg are directly coupled to their infrastructure. So instead of using any code from the original system, Google designed Kubernetes (K8S) from scratch to orchestrate the Docker container. Kubernetes was released in February 2015 with the following goals and considerations:

  • Provide powerful tools for application developers to orchestrate Docker containers without interacting with the underlying infrastructure;
  • Provide standard deployment interfaces and primitives to achieve cloud consistent application deployment experience and API;
  • Based on a modular API core, it allows vendors to integrate their systems around Kubernetes’ core technologies.

In March 2016, Google donated Kubernetes to CNCF and remains a major contributor to the project today (followed by Redhat, CoreOS, etc.).

Source: wikipedia

Kubernetes is very attractive to application developers because it reduces the dependency on infrastructure and operations teams. Vendors also like Kubernetes because it provides an easy way to embrace the containerization movement and provide business solutions for customers to deploy their own Kubernetes (which remains a challenge worth taking seriously). Kubernetes is also attractive because it is an open source project under CNCF, as opposed to Docker Swarm, which is tightly controlled by Docker despite being open source.

The core strength of Kubernetes is that it provides application developers with powerful tools for orchestrating stateless Docker containers. While there are several proposals to expand the scope of the project to provide additional capabilities (such as analytics and stateful data services), these proposals are still at a very early stage and it remains to be seen how successful they will be.

Apache Mesos

Apache Mesos began as a next-generation container Cluster manager project at UC Berkeley, and applied lessons learned from cloud-level distributed infrastructures such as Google’s Borg and Facebook’s Tupperware. While Borg and Tupperware have a single architecture and are closed source proprietary technologies tightly tied to the physical infrastructure, Mesos has introduced a modular architecture, an open source development approach designed to be completely infrastructure independent. Mesos was quickly adopted by Twitter, Apple (in Siri), Yelp, Uber, Netflix, and many leading technology companies, enabling everything from microservices, big data, and real-time analytics to elastic scaling.

As a cluster manager, Mesos is designed to solve a different set of challenges:

  • Abstract data center resources into a single pool to simplify resource allocation and provide consistent application, operation and maintenance experience in both private and public clouds.
  • Coordinate multiple workloads such as analytics, stateless microservices, distributed data services, and traditional applications on the same infrastructure to improve utilization and reduce costs and countertop space;
  • Automating the next day’s operations for application-specific tasks such as deployment, self-repair, expansion, and upgrade; Providing a highly usable fault-tolerant infrastructure;
  • Provides persistent extensibility to run new applications and technologies without modifying the cluster manager or any existing applications built on top of it;
  • Elastic scaling can scale applications and underlying infrastructure from a handful to tens to tens of thousands of nodes.

Mesos’s unique ability to independently manage various workloads — including traditional applications like Java, stateless Docker microservices, batch jobs, real-time analytics, and stateful distributed data services. Mesos’s extensive workload coverage comes from its two-tier architecture, enabling “application aware” scheduling. Application-aware scheduling is implemented by encapsulating application-specific operational logic in a “Mesos framework” (similar to an operational manual in an operation). The resource manager Mesos Master provides parts of the framework infrastructure while maintaining isolation. This approach allows each workload to have its own purpose-built application scheduler that understands its specific operational requirements for deployment, scaling, and upgrading. The application scheduler is also developed, managed, and updated independently, giving Mesos the ability to be highly extensible to support new workloads or add more operational functionality over time.

Mesos two-level scheduler

Give an example of how a team manages an application upgrade. Stateless applications can benefit from blue/green deployment scenarios; When the new version of the application is running, the old version of the application is still running, and when the old application is destroyed, the traffic will be switched to the new application. However, upgrade data workloads such as HDFS or Cassandra require a node shutdown, local data volumes need to be persisted to prevent data loss, and in-place upgrades need to be performed in a specific order, with specific checks and commands performed on each node type before and after the upgrade. Any of these steps are application – or service-specific and may even be version-specific. This makes it very difficult to manage data services using regular container choreography schedulers.

Mesos manages various workloads in a way that is specific to each workload, leading many companies to use Mesos as a unified platform for bringing together microservices and data services. The common reference architecture for data-intensive applications is the LCTT family (Spark, Mesos, Akka, Cassandra, Kafka).

It’s time to figure that out

Please note that we have not yet had any description of the container choreography of Apache Mesos. So why do people automatically associate Mesos with container choreography? Container choreography is an example of a workload that can run on Mesos’s modular architecture through a specialized choreography “framework” called Marathon, a tool built on top of Mesos. Marathon was originally developed to orchestrate application archives (such as JARS, tarballs, ZIP files) in CGroup containers, and was one of the first orchestrators to support Docker containers in 2014.

So when people compare Docker and Kubernetes to Mesos, they’re actually comparing Kubernetes and Docker Swarm to Marathon running on Mesos.

Why is it important to figure this out? Because Mesos frankly doesn’t care what’s running on it. Mesos can provide Java application servers with clustering services, Docker container choreography, Jenkins continuous integration tasks, Apache Spark analysis, Apache Kafka streams, and many more on top of a shared infrastructure. Mesos can even run Kubernetes or other container choreography tools, even if common integrations are not currently available.

Source: Apache Mesos 2016 Questionnaire

Another consideration for Mesos (and why it is so attractive to many enterprise architects) is the maturity of running mission-critical workloads. Mesos has been running in mass production environments (tens of thousands of servers) for over seven years, which is why it is more production-feasible and scalable than many other container technologies on the market.

What do I mean by all this?

In summary, all three of these technologies are related to Docker containers and allow you to implement portability and extensibility of your applications on top of container choreography. So how do you choose between them? It comes down to choosing the right tool for the job (and perhaps different tools for different jobs). If you’re an application developer looking for modern ways to build and package your applications, or want to accelerate your microservice initiatives, Docker containers and development tools are the best choice.

If you’re a developer or DevOps team and want to build a system dedicated to Docker container choreography and are willing to spend time fiddling with integration solutions and underlying infrastructure (or relying on public cloud infrastructure), Like Google Container Engine (GCE) or Azure Container Services (ACS)), Kubernetes is a good technology to consider.

If you want to build a reliable platform to run multiple mission-critical workloads, including Docker containers, traditional applications (like Java), and distributed data services (like Spark, Kafka, Cassandra, Elastic), And hopefully all of this can be ported to a cloud provider or data center, so Mesos (or our own Mesos distribution, Mesosphere DC/OS) is more suited to your needs.

Whatever you choose, you’ll embrace a set of tools that make more efficient use of server resources, simplify application portability, and improve developer agility. You really can’t go wrong with your choice.

via: https://mesosphere.com/blog/docker-vs-kubernetes-vs-apache-mesos/

By Amr Abdelrazik translated by Rieonke proofread by WXY

This article is originally compiled by LCTT and released in Linux China