Autonomous vehicles making split-second decisions, factories full of internet-of-things sensors streaming data, and augmented reality applications demanding instantaneous responses all share one uncomfortable truth: the traditional cloud is simply too far away. Sending every byte to a distant datacenter introduces latency, strains networks, and exposes data unnecessarily. The answer that researchers and industry have converged on is the edge-cloud continuum, a seamless integration of computing resources across the cloud, fog, and end-device layers that lets workloads live wherever they perform best. But while the concept is easy to state, realizing it has proven stubbornly difficult, because no platform has emerged that provides continuum-wide capabilities the way Kubernetes provides them for the cloud.
Now, a study published in the journal Cluster Computing by Vid Bregar and Matjaz B. Juric of the University of Ljubljana presents a serious attempt to close that gap. The researchers describe the architecture and evaluation of CosmoSpan, a Kubernetes-based platform that stitches heterogeneous cloud and fog clusters into a unified computing fabric and then continuously schedules and reschedules workloads across it. The headline result is striking: in large-scale simulations, CosmoSpan’s scheduler achieved an average Edge-Cloud Continuum Placement Score of 98.68, a 41 percent improvement over the default Kubernetes scheduler and a 27 percent improvement over the network-aware scheduler Diktyo, all without materially sacrificing scheduling time.
The choice to build on Kubernetes rather than invent a new platform from scratch is central to the work. Kubernetes, the de facto standard for container orchestration that evolved from Google’s Borg, offers extensibility through its modular architecture, an enormous ecosystem of tools, and significant functional overlap between cloud and fog operations. Yet the authors are candid about its limitations in edge settings. Kubernetes components such as the control plane, networking stack, and etcd distributed database consume resources that are scarce on fog nodes. The system assumes CPU homogeneity, struggles in unreliable high-latency networks due to its centralized architecture, and lacks any native mechanism for network-aware workload placement, load balancing, or autoscaling across an edge-cloud environment.
Those limitations shaped the platform’s architecture in fundamental ways. The researchers conducted a comparative analysis of single-cluster versus multi-cluster designs and concluded that multiple smaller clusters, each confined to a single fog location or cloud region, are the better foundation. Small clusters keep latency between nodes low, which is essential for Kubernetes performance, and each cluster can continue operating somewhat independently if the network partitions, breaking the centralized failure mode. Fog clusters can run lightweight Kubernetes adaptations such as K3s or K0s, while cloud clusters leverage fully featured managed offerings. To manage this federation of clusters, the team selected Karmada, an open-source federation solution compatible with the Kubernetes API that provides advanced multi-cluster scheduling. To dissolve the isolation between clusters, they chose the Istio service mesh, which interconnects cluster networks, resolves overlapping address ranges, enables multi-cluster service discovery, and adds security and traffic management features that can be tailored to continuum needs.
The real innovation lies in how users tell the platform what they want. CosmoSpan introduces specialized workload and node descriptors that convey edge-cloud requirements and preferences at deploy time. Workloads can specify which layer they must run on, their CPU and memory requests, network bandwidth needs, and node uptime requirements. Most notably, a latency request descriptor, built on an AppGroup custom resource definition adapted from a Kubernetes enhancement proposal, lets a workload declare that each of its instances must reach every dependent workload instance within a specified latency threshold, evaluated against historical metrics such as the 90th percentile over the past 24 hours. Because fog CPUs may be weaker than cloud CPUs, the platform normalizes advertised CPU capacity using benchmark scores rather than assuming all cores are equal.
Underneath the descriptors sits the CosmoSpan Data Collector, which gathers the platform’s current state from every cluster in the federation. It collects CPU and memory usage, restart counts, network throughput, node costs, and latencies, shipping metrics every 60 seconds to a Grafana Mimir time-series database. Measuring latency between every pair of nodes at scale would be impractical, so the researchers propose a scalable heuristic: each node measures latencies only to lower-numbered nodes within its own cluster and to a periodically elected cluster leader, while elected leaders measure inter-cluster latencies. Periodic leader elections prevent measurements from overfitting to specific nodes, allowing the system to converge toward average inter-cluster latencies. Precomputed aggregations and a real-time node capacity store then give the scheduling components fast access to a global view of the federation.
The CosmoSpan Scheduler itself is a greedy multi-criteria decision-making scheduler built on the Kubernetes Scheduling Framework, but with a crucial difference: instead of selecting only a node, it selects both a cluster and a node within that cluster. Each workload instance passes through filter, score, reserve, and bind stages, with plugins for node cost, node uptime, network bandwidth, and latency requests. Unschedulable instances expose per-plugin rejection reasons through standard Kubernetes events, making every decision interpretable and debuggable, a deliberate design goal. The semantic distinction the authors draw is important: baseline schedulers place nearly all instances but silently violate declared hard requirements, whereas CosmoSpan leaves an instance pending rather than knowingly breaching its constraints, turning a latent service level objective violation into an actionable signal.
Scheduling alone cannot keep a platform aligned with its goals when the environment keeps changing, so the researchers introduced CosmoSpan Deschedulers, one per cluster, that periodically scan workload instances for non-compliance. When a node’s uptime degrades, bandwidth guarantees change, latencies drift out of bounds, or costs shift, the deschedulers evict and recreate affected instances through the federation API, triggering fresh scheduling with updated state. Evictions respect Kubernetes Pod Disruption Budgets, limiting service disruption, and only stateless workloads are relocated; stateful workloads are placed strategically at initial deployment. In benchmarks across nine datasets of 300 nodes each, with ten successive environmental changes that worsened 10 percent of nodes and improved another 10 percent, the baseline platform’s placement score steadily declined while the descheduler-equipped platform maintained a consistently high score, with a standard deviation below 0.23 points across all datasets.
The evaluation went beyond simulation. The team deployed the full platform on real hardware across three geographic locations, a cloud cluster in Nuremberg, a fog cluster in Helsinki, and a minimal single-node fog cluster in Hillsboro, Oregon, interconnected via Istio and Karmada. Deploying three synthetic applications totaling 45 workload instances with the full suite of descriptors, they found that placement decisions matched a replicated simulation for 93 percent of instances, and the physical placement score of 97.8 differed from the simulated 98.1 by less than one point, while the default Kubernetes scheduler scored just 67.4 on the same infrastructure. When the researchers injected 60 milliseconds of artificial latency between Helsinki and Nuremberg using Linux traffic control, violating the latency requirements of seven workload instances, the Latency Requests descheduler plugin detected the violations within a single 60-second scan interval, and the platform converged within 94 seconds, restoring the placement score from 85.3 to 97.8 while an external traffic generator reported zero failed requests.
The overhead measurements ground the vision in practical reality. The platform consumes roughly 10 percent of a vCPU and about one gigabyte of memory per fog node when idle, which makes deployment on end-devices impractical but is feasible on fog nodes with at least four cores and 16 gigabytes of RAM. Latency overhead from the Istio networking stack is measurable, particularly for inter-cluster traffic, though future adoption of Istio’s sidecar-free Ambient Mode could reduce it. The authors acknowledge limitations, including a centralized control plane, reliance on periodic rather than event-driven telemetry, simplified latency and bandwidth modeling, and evaluation on synthetic datasets, and they outline future work on federation-wide autoscaling, automated stateful workload migration, and automated placement of gateway services to minimize end-user latency. Still, the demonstration that a Kubernetes-compatible platform can schedule workloads across a real, geographically distributed continuum, adapt within seconds to network degradation, and do so without dropping a single request marks a meaningful step toward making the edge-cloud continuum an operational reality rather than an architectural aspiration.
Subject of Research: Edge-cloud continuum workload scheduling with Kubernetes
Article Title: Toward adaptive workload scheduling in Kubernetes across the edge-cloud continuum
Article References: Bregar, V., & Juric, M. B. (2026). Toward adaptive workload scheduling in Kubernetes across the edge-cloud continuum. Cluster Computing, 29(15), Article 850. https://doi.org/10.1007/s10586-026-06669-7
Image Credits: AI Generated
DOI: 10.1007/s10586-026-06669-7
Keywords: edge-cloud continuum, Kubernetes, workload scheduling, CosmoSpan, Karmada, Istio, fog computing, descheduling, latency-aware scheduling, multi-cluster federation, Toward, adaptive
News Source: Denise Maddox. (October 16, 2026). New scheduler teaches Kubernetes to think across the edge-cloud continuum. Scienmag.
