Kubernetes Architecture Analysis and Comparison of Scheduling Models with Mesos

The article begins by introducing the latest Kubernetes architecture, noting its dominance in cloud‑native environments and its role in managing both infrastructure and applications.

It then presents a simplified view of the official architecture, describing the key components:

ETCD – the distributed key‑value store that holds cluster state, provides event watching, subscription, and leader election.

API Server – a RESTful proxy to ETCD that adds authentication, caching, and other functions.

Controller Manager – handles task‑level scheduling for objects such as Deployments, DaemonSets, and Jobs.

Scheduler – performs resource‑level scheduling by assigning Pods to nodes based on cluster state.

Kubelet – an agent on each node that watches ETCD for Pods assigned to its node and runs them.

Kubectl – the command‑line client that interacts with the API Server.

A concrete example shows how a multi‑instance Nginx Deployment is created step‑by‑step using kubectl , how the Deployment controller creates a ReplicaSet, how the ReplicaSet creates Pods, how the Scheduler binds Pods to nodes, and how Kubelet launches the Pods.

The article then raises two questions: whether Kubernetes is a two‑layer scheduler and how its scalability compares to Mesos. It references Google’s Omega paper, classifying Borg as a monolithic scheduler, Mesos as two‑layer, and Omega as a shared‑state model.

It argues that Kubernetes, like Mesos, separates task scheduling (Controller Manager) from resource scheduling (Scheduler), making it a two‑layer scheduler. The comparison of push‑based scheduling (Mesos) versus pull‑based scheduling (Kubernetes) leads to an analysis of five criteria:

Resource utilization: Kubernetes wins because a single Scheduler has a global view of resources.

Scalability: Mesos wins; its push model makes it easier to migrate existing workloads.

Flexible task‑scheduling strategies: Mesos wins, supporting “all‑or‑nothing” semantics that Kubernetes lacks.

Performance: Mesos wins; historical data shows Mesos clusters managing far more nodes than early Kubernetes versions.

Scheduling latency: Kubernetes wins due to the inefficiency of Mesos’ Offer cycle.

The discussion then shifts to why most cluster schedulers cannot scale out horizontally. It introduces the concept of an “independent resource pool” and uses an e‑commerce analogy to illustrate that horizontal scalability is limited by the number of such pools.

In cluster scheduling, the entire cluster’s resources form a single resource pool, so the scheduler effectively has only one independent pool, preventing true multi‑active (multi‑node) scaling. The article concludes that because the scheduler’s decision space cannot be partitioned, cluster schedulers remain single‑active despite the desire for horizontal expansion.