Kubernetes vs. Mesos – an Architect’s Perspective

Linux containers are now in common use. But when they were first introduced in 2008, virtual machines, or VMs, were the state-of-the-art option for cloud providers and internal data centers looking to optimize a data center’s physical resources.

This arrangement worked well enough, except for one major flaw: Each VM required both a complete operating system and emulated instructions to reach the physical CPU. While some technologies like Intel VT-x and AMD-V promised to resolve this issue, they were not as efficient as bare metal. Kubernetes oline course from industrial experts.

Containers, on the other hand, take a different approach to maximizing resource usage: They use a common kernel for all applications, but enable it to freely choose all the operational resources it needs. All containers have exclusive access to resources (like CPU, memory, disk, and network) and each can be prioritized by a manager. In other words, containers can run on bare metal, sharing resources, but are unable to access other containers’ resources. While in some ways this resembles the sandboxing implementation in modern mobile operating systems, it runs at a low level and does not require changes to an application already running in a Linux distribution.

Containers have one major flaw—they are great for green field projects, but how can they be implemented for older tools that an entire company may be developing or using? The fact is that some technologies and products are simply too difficult to deploy as containers.

Kubernetes (K8S) is an open-source container orchestration system originally created by Google that handles the entire production lifecycle, from on-the-fly deployment, to scaling up and down, to health checks with high availability. It’s also very opinionated.

The Problem and the Different Approaches

We should emphasize that we’re comparing tools that have different approaches to the same problem. K8S is a container orchestrator or, in other words, a tool that manages containers and their peculiarities such as availability, scaling, and so on. Apache Mesos, on the other hand, is more like a “cloud operational system” that tries to manage all the resources of a cloud (public or private), meaning it has a far broader range of responsibilities.

While Kubernetes works on the concept that every computational resource must be enveloped within a container, Mesos understands that the world is not black and white, and that we should use the best tools for each particular situation.

Kubernetes architecture

Kubernetes has one or more kubernetes master instances and one or more kubernetes nodes. The master instance is used to manage the cluster and the available nodes. It also manages deployment settings (number of instances, what to do with a version upgrade, high availability, etc.) and service discovery. Every computing resource is enveloped by a container and cloud resources, such as network, storage, and everything else, should be provided by plugins to comply with the K8S philosophy.

Mesos architecture

Mesos’ architecture is similar, but it has evolved a whole new layer. Like K8S, Mesos has a master and nodes (agents), which provide analogous functionality. However, it adds a scheduler layer that doesn’t exist in K8S. A scheduler is an implementation of a technology that can use the Mesos infrastructure to run what it was built for. In the picture above, we’ve deployed Hadoop (big data) and MPI (messaging) schedulers; however, there are dozens of schedules available, from containers (Marathon) to continuous integration (Jenkins). Of the long list of schedulers built on Mesos, one worth highlighting is Marathon, which is a container orchestration scheduler, similar to K8S.

As a generalization, Kubernetes is a more opinionated tool that can be very useful—if you embrace its founders’ vision. Mesos, on the other hand, is more flexible, and even enables you to create your own scheduler. Containers are generally not a good fit for legacy or monolithic systems, but these can be accommodated by Mesos through the creation of suitable schedulers. Unfortunately, however, Mesos adds a new layer of complexity that many developers are not willing to tolerate.

In this case, our deployment, named wordpress-deployment, will have three instances and will run the image wordpress/wordpress:4.5-apache. online kubernetes course for more skills and techniques.

> kubectl set image deployment/wordpress-deployment wordpress=wordpress:4.8-apache

This will force the deployment to stop the old images and start the new ones; however, the old ones will be stopped and removed only when the new images are available. If you need to rollback a version, you simply type the following command and the previous state will be restored:

> kubectl rollout undo deployment/wordpress-deployment

All deployment updates are stored, so if needed, you can rollback through all revisions.

Mesos (through Marathon) also has a declarative approach for updates. To paraphrase from the documentation, each application has a unique id, and with every new execution, Marathon makes on-the-fly changes to the application’s properties. Some properties can be used for a fine-grained deployment. Besides those it has already altered, Marathon adds the property minimumHealthCapacity to aid deployment. This represents the proportion of old instances to new ones. For example, if minimumHealthCapacity = 0, all old instances can be killed before a new version is deployed. On the other hand, if minimumHealthCapacity = 1, all instances of the new version will be run side by side with the old version before the latter is removed.

Summary

Kubernetes and Mesos employ different tactics to handle the same problem. Mesos is more ambitious, as Kubernetes equates to just a single node of Mesos’ entire solution. However, the complexity of Mesos presents a higher barrier to entry for a new user. This is reflected in its limited adoption by the major cloud providers as an on-premises solution when compared with Kubernetes’ rapid uptake.

From an architect’s perspective, both solutions are equivalent in terms of features, with each having its own particular strengths. The nice architectural design of Mesos provides some good options for handling legacy systems and more specific technologies like distributed processing with Hadoop. Kubernetes online training helps you to learn more effectively.