PaperlayerView exact revision on arXiv

Source-linked AI summary

Genetic Algorithm for Multi-Objective Optimization of Container Allocation in Cloud Architecture

Carlos Guerrero, Isaac Lera, Carlos Juiz

arXiv:2401.12698v1cs.NI

TL;DR

Container allocation and elasticity management remain open problems in cloud environments, with allocation affecting performance, reliability, and elasticity. The paper applies NSGA-II to optimize four objectives and reports better optimization than Kubernetes allocation policies while using fewer physical machines.

  • Problem

    Container scheduling and management remain open, while existing Kubernetes approaches focus on physical resource usage and general thresholds despite allocation’s effects on performance, reliability, and elasticity.

  • Method

    The paper applies the NSGA-II genetic algorithm to container allocation and automatic elasticity management using four optimization objectives.

  • Results

    The approach achieved better optimization of all four objectives than Kubernetes allocation policies and used fewer physical machines.

  • Takeaways & Limitations

    NSGA-II is reported as a suitable solution for container allocation and elasticity, finding optimized solutions with 100 generations and a population of 200.

  • Takeaways & Limitations

    The allocation algorithm’s results still need evaluation in a real cloud container cluster.

Abstract

from arXiv · show

The use of containers in cloud architectures has become widespread because of advantages such as limited overhead, easier and faster deployment and higher portability. Moreover, they are a suitable architectural solution for deployment of applications created using a microservices development pattern. Despite the large number of solutions and implementations, open issues have not been addressed in container automation and management. Container resource allocation influences system performance and resource consumption so it is a key factor for cloud providers. We propose a genetic algorithm approach, using the Non-dominated Sorting Genetic Algorithm-II (NSGA-II), to optimize container allocation and elasticity management due to the good results obtained with this algorithm in other resource management optimization problems in cloud architectures. The optimization has been focused on a tight use of the resources and a reduction of the network overhead and system failure rate. A model for cloud cluster, containers, microservices and four optimization objectives is presented. Experimental results have shown that our approach is a suitable solution to address the problem of container allocation and elasticity and it obtains better objectives values than the container management policies implemented in Kubernetes.

1 Introduction

The paper frames container allocation and elasticity as open cloud-management problems and proposes NSGA-II to optimize four objectives spanning workload balance, application performance, reliability, and network overhead.

  • Motivation: Microservices use independent, modular services, while containers provide OS-level isolation with lower overhead than complete virtual machines.These properties support deploying each microservice in its own container.
  • Problem: Container placement affects performance, reliability, and elasticity, but existing Kubernetes approaches primarily use resource thresholds for allocation and scaling.The paper identifies container-based elasticity as less studied than virtual-machine elasticity.
  • Approach: The optimization problem is NP-complete, motivating a genetic-algorithm metaheuristic instead of exhaustive evaluation of all allocation and scalability combinations.NSGA-II is presented as a common approach for multi-objective cloud optimization.
  • Approach: NSGA-II optimizes container allocation and automatic scalability across four objectives: cluster workload balance, container workload balance, reliability, and network overhead.The objectives address provisioning, application performance, avoidance of single points of failure, and communication placement.
  • Evaluation: The study validates the evolutionary approach with workload and system models based on data from real deployed scenarios.Its contributions include improving container-cluster resource management through allocation and automatic scalability.

2 Related work

Prior work addresses cloud resource management and container scheduling with several optimization techniques, but container orchestration and self-management remain insufficiently addressed. The paper positions NSGA-II as an evolutionary approach to container allocation and elasticity not previously studied in this context.

  • Existing approaches: Cloud resource-management research covers scheduling, provisioning, and allocation, with evolutionary methods commonly applied to performance, reliability, and energy objectives.NSGA-II is described as a widely demonstrated, low-cost optimization approach in cloud environments.
  • Research gap: Container-based solutions are numerous, but orchestration and self-management remain open issues, and studies of container resource management are limited.The paper states that only three recent works addressed container allocation before its proposal.
  • Existing approaches: Other work applies linear programming, game theory, or stable-marriage matching to container allocation and resource utilization.These approaches use different optimization or ranking mechanisms for assigning containers to physical machines.
  • Existing approaches: Earlier schedulers optimize new container arrivals using deployment cost, energy consumption, or performance, rather than the broader allocation-and-elasticity problem.The cited approaches differ from the proposal because they focus only on newly arriving containers.
  • Contribution: The paper claims novelty in applying NSGA-II to container allocation and elasticity management, a resource-management problem not previously addressed with evolutionary strategies.This positions the work between established cloud genetic-algorithm methods and the limited container-allocation literature.

3 System model

The system model represents microservice applications, container replicas, physical machines, and their network so container allocation and scalability can be optimized jointly. It defines four objectives covering workload thresholds, cluster balance, application reliability, and intercommunication distance under physical-capacity constraints.

  • Application and microservice model: Applications are modeled as directed microservice graphs whose edges represent provider–consumer interoperability relationships.Each application is characterized by user requests and a microservices stack.
  • Container and machine model: Each microservice runs in one or more containers, with resource consumption divided uniformly according to its scalability level.Container allocation maps each container to a physical machine, while scalability determines the number of containers.
  • Container and machine model: Physical machines have computational capacities and failure rates, and allocated container resources must remain below each machine’s capacity.The machines are interconnected by a physical network whose paths characterize communication distances.
  • Optimization objectives: Threshold Distance measures deviation between container resource consumption and the microservice threshold, penalizing underused or overloaded scaling choices.The metric supports workload allocation that keeps container consumption near the service threshold.
  • Optimization objectives: Cluster Balanced Used evaluates the standard deviation of resource usage across active physical machines, excluding machines without allocated containers.Unused machines may be switched off and are omitted from the balance calculation.
  • Optimization objectives: System Failure models application failure when any microservice fails, with microservice failure occurring when all its container replicas fail.Container failure can arise from the container or its hosting physical machine.
  • Optimization objectives: Total Network Distance approximates communication overhead using mean distances between consumer and provider containers across microservice replicas.The formulation averages distances between replicas of a microservice and containers running the microservices they consume.
  • Optimization objectives: The optimization jointly determines container placement and microservice scalability using four objectives: Threshold Distance, Cluster Balanced Used, System Failure, and Total Network Distance.These objectives target appropriate container workload, uniform cluster use, distributed reliability, and short distances between related microservices.

4 Genetic algorithm proposal

The proposal represents container scalability and physical-machine allocation as chromosomes and applies NSGA-II to evolve multi-objective solutions. Crossover, mutation, Pareto ranking, crowding distance, and elitist selection guide the search.

  • Chromosome representation: NSGA-II represents each solution as a chromosome encoding microservice container counts and their physical-machine allocations.The representation uses a microservices array whose allocation-list length gives each microservice’s scalability level.
  • Crossover and mutation operators: Crossover independently applies single-point recombination to each allocation list, producing two offspring from two parent solutions.A separate random crossover point is generated for each allocation list.
  • Crossover and mutation operators: The proposal defines Swap, Shrink, and Growth mutations to rearrange allocations or decrease or increase microservice scalability levels.Shrink removes physical-machine identifiers from allocation lists, while Growth adds them.
  • Selection and evolution: NSGA-II evaluates each solution with four objective values, ranks solutions by Pareto fronts and crowding distance, and uses elitist selection to retain stronger individuals.The parent and offspring populations are combined, ranked, and reduced to the best half for the next generation.
  • Execution parametrization: The algorithm’s performance depends on its parameterization, including population initialization, stopping conditions, and operator application frequencies.The passage states that parameter values require prior testing or bibliographic support.

5 Experimental evaluation

The evaluation varies workload and cluster capacity in modeled cloud experiments, using Socks Shop-derived microservice parameters and comparing the approach with Kubernetes policies. Because comparable studies differed from the proposed approach, Kubernetes provides the comparison baseline.

  • Comparison: The evaluation measures multi-objective function values and generations needed to find suitable values, then compares the results with another approach.The paper reports that the comparison is performed against Kubernetes container policies.
  • Parameter sources: Microservice parameters are estimated from scenarios, including Socks Shop benchmarking for resource consumption and external traces for failure rates.Request counts are estimated from an e-commerce benchmark’s customer behavior model graph.
  • System model: The modeled cluster is heterogeneous, with four physical-machine capacities and machines distributed across two racks with specified network distances.Each machine type uses the same failure rate, and experiments contain equal quantities of each type.
  • Experiment design: The experiments vary applications, user-request rates, and available physical machines to test the optimizer under different workload and capacity conditions.The configurations use 1 or 2 applications, request levels from 1.0 to 2.0, and cluster sizes from 250 to 400 physical machines.
  • Comparison: Kubernetes allocates pods using resource-capacity feasibility and least-consumed-resource policies, both aimed at spreading containers across cluster machines.PodFitResources limits requested resources by machine capacity, while LeastRequestPriority favors machines with fewer consumed resources.

6 Results

The results analyze both generation-by-generation adaptation and final objective values across experiment configurations. Because NSGA-II returns Pareto fronts rather than one solution, the reported summaries use representative statistics and environment-dependent selection criteria.

  • Results analysis: The results are analyzed through objective evolution across generations and final optimization values.The paper presents representative configurations for the evolution analysis and all 24 configurations for final results.
  • Pareto-front analysis: Pareto-front solutions are summarized using minimum, mean, and minimum-SOV objective values rather than a single NSGA-II solution.The paper treats the Pareto front as a set of non-dominated individuals and uses data series to simplify analysis.
  • Evolution across generations: The evolution figures compare objective-function values and system conditions across experiments with different applications, workloads, and physical-machine counts.System conditions include microservice scale levels and the number of machines hosting at least one microservice.
  • Pareto-set evolution: The Pareto-set illustration plots objective combinations across six generations for the 350-machine, 1.5-request, two-application configuration.Two scatter plots represent pairs of the four objective values.
  • Final optimization results: Final results cover Total Network Distance, Threshold Distance, Cluster Balanced User, System Failure, and the number of used physical machines.One Pareto-front solution must be selected to represent a specific experiment and objective value.

7 Discussion

The NSGA-II optimization stabilizes quickly and produces diverse Pareto-front solutions, while final outcomes vary with workload and application count. Compared with Kubernetes, it improves all objectives using fewer physical machines, though solution coverage and scalability remain constrained in specific respects.

  • Evolution of the objectives: The representative minimum-SOV solution trades objective values, improving System Failure, Threshold Distance, and Network Distance while worsening Cluster Balanced.This reflects that the best values for different objectives belong to different Pareto solutions.
  • Evolution of the objectives: Pareto-front solutions shift into the search space within 30 generations, after which solution diversity continues increasing.The later generations populate the covered space with more solutions of comparable quality.
  • Evolution of the objectives: System Failure does not cover all possible solution values, and the authors propose additional mutation operators to improve its distribution.Three other objective search spaces are reported as well covered.
  • Final optimized results: Higher microservice counts and workloads worsen Network Distance and Threshold Distance, while Cluster Balanced Use and System Failure show no clear trend.The number of physical nodes also increases as workload or application count increases.
  • Final optimized results: The approach achieves better optimization for all objectives than Kubernetes while using fewer physical machines.Unused machines could be switched off, potentially reducing cluster power consumption.

8 Conclusion

The paper addresses container allocation and elasticity through a four-objective NSGA-II optimization. Experiments find suitable optimized solutions and better four-objective optimization than Kubernetes, with fewer physical machines, while real-cluster validation remains future work.

  • 8 Conclusion: The four objectives optimize Cluster Balanced Use, Threshold Distance, Network Distance, and System Failure for container allocation and elasticity.They target workload distribution, microservice-container workload distribution, network overhead, and reliability.
  • 8 Conclusion: NSGA-II finds optimized container-allocation solutions with 100 generations and a population size of 200 across varied machine and workload configurations.The experiments vary physical-machine counts and system workload to study the algorithm.
  • 8 Conclusion: The approach achieves better optimization of all four objectives than Kubernetes while using fewer physical machines.The comparison is based on the implemented Kubernetes allocation policies.
  • 8 Conclusion: Evaluation in a real cloud container cluster, additional objectives, and container live-migration cost remain future work.The authors also propose using migration cost rather than a single scalar Pareto-front criterion for selecting solutions.
Loading 2401.12698v1…