Container Orchestration via Workload Forecasting

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current container orchestration tools face challenges in automatically scaling and migrating containers in microservice architectures, particularly in predicting future workload demands and optimizing container placement to reduce network latency, as they rely on static policies and lack intelligence for proactive scaling and migration.

Innovation Solution

A computer-implemented method that uses a trained forecasting model to predict the number of containers required for each microservice based on intra-node and inter-node features, assigning scaling labels and values to adjust container numbers and migrating containers between nodes to optimize performance and reduce latency, leveraging machine learning for automated orchestration.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If container orchestration tools use static policies for scaling and migration, then device complexity is reduced and ease of operation is improved, but adaptability to future workload demands deteriorates and productivity decreases

Engineering Contradiction:
Improveease of container orchestrationVSAvoidadaptability to future workload
Core Design Contradiction:
Ease of operationVSAdaptability or versatility

Solution Approach 1:

The system performs preliminary actions by training a forecasting model on historical workload data to predict future container requirements. This predictive capability enables the orchestration system to proactively scale and migrate containers before workload demands arise, resolving the contradiction between static operational simplicity and dynamic adaptability to future workloads.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system implements feedback mechanisms by continuously monitoring actual workload performance and comparing it with forecasted predictions. This feedback loop allows the forecasting model to be retrained and refined over time, improving adaptability to changing workload patterns while maintaining automated orchestration operations.

Inventive Principle:
Principle #23Feedback

2Device complexity

If container orchestration tools rely on predefined constraints for scheduling, then device complexity is reduced, but manufacturing precision of container placement deteriorates and network latency increases

Engineering Contradiction:
Improvecomplexity of orchestration systemVSAvoidprecision of container placement
Core Design Contradiction:
Device complexityVSManufacturing precision

Solution Approach 1:

The forecasting model performs preliminary analysis of workload patterns and predicts optimal container placement locations before actual deployment. This predictive scheduling enables precise container placement that considers both resource constraints and performance optimization goals, resolving the contradiction between system simplicity and placement precision.

Inventive Principle:
Principle #10Preliminary action

3Adaptability or versatility

If manual monitoring and adjustment of container numbers is performed, then adaptability to workload changes is improved, but loss of time for operational intervention increases and productivity decreases

Engineering Contradiction:
Improveadaptability to workload changesVSAvoidtime for manual intervention
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The system implements self-service by automatically translating forecasting model predictions into container scaling and migration actions without requiring manual operational intervention. The orchestration system autonomously adjusts container numbers based on predicted workload demands, maintaining adaptability while eliminating time loss associated with manual monitoring and decision-making.

Inventive Principle:
Principle #25Self-service

4Productivity

If forecasting model is trained on historical workload data, then adaptability to future demands is improved and productivity increases, but use of energy for data processing and model training increases

Engineering Contradiction:
Improveproductivity of container orchestrationVSAvoidenergy for model training
Core Design Contradiction:
ProductivityVSUse of energy by moving object

Solution Approach 1:

The system applies partial action by training the forecasting model on a representative subset of historical workload data rather than processing complete historical records continuously. This approach achieves sufficient predictive accuracy for effective orchestration decisions while minimizing the energy consumption associated with data processing and model training operations.

Inventive Principle:
Principle #16Partial or excessive action

Data Source

PatentUS11704123B2Automated orchestration of containers by assessing microservices
Publication Date: 2023.07.18 INTERNATIONAL BUSINESS MACHINE CORPORATION
  • US11704123B2 patent drawing
  • US11704123B2 patent drawing
  • US11704123B2 patent drawing

AI summary

Performing container scaling and migration for container-based microservices is provided. A first set of features is extracted from each respective microservice of a plurality of different microservices. A number of containers required at a future point in time for each respective microservice of the plurality of different microservices is predicted using a trained forecasting model and the first set of features extracted from each respective microservice. A scaling label and a scaling value are assigned to each respective microservice of the plurality of different microservices based on a predicted change in a current number of containers corresponding to each respective microservice according to the number of containers required at the future point in time for each respective microservice. The current number of containers corresponding to each respective microservice of the plurality of different microservices is adjusted based on the scaling label and the scaling value assigned to each respective microservice.