Critical Workload Management in Container-Based Computing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In container-based microservice environments, critical services often face resource shortages due to high resource utilization by less critical services, leading to potential out-of-memory exceptions and service level agreement violations, especially in Kubernetes platforms where resource allocation is not efficiently managed.
Innovation Solution
Implementing a critical service manager module that determines a resource trigger threshold for critical services, reallocates resources from less critical services when the threshold is reached, and reverts resources back when the critical service's needs decrease, using a calibration module to determine the optimal resource state and a sidecar module for real-time resource monitoring and re-allocation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If resources are allocated to less critical services, then resource utilization efficiency is improved, but critical services may experience resource shortages leading to out-of-memory exceptions and service level agreement violations
Solution Approach 1:
The patent implements dynamic resource allocation where the resource trigger threshold is not fixed but can be updated at given time intervals and/or at given event occurrences. This allows the system to adapt resource allocation between critical and non-critical services based on changing conditions, resolving the contradiction between maximizing resource utilization and ensuring critical service availability.
Solution Approach 2:
The system changes the parameter of resource trigger threshold dynamically. By updating this threshold parameter based on time intervals and event occurrences, the system can adjust the point at which resources are reallocated from non-critical to critical services, thereby balancing resource utilization efficiency with critical service reliability.
2Reliability
If resource trigger threshold is set low, then critical services receive resources promptly, but resource re-allocation frequency increases causing system instability
Solution Approach 1:
The system employs periodic action by updating the resource trigger threshold at given time intervals. This periodic update mechanism prevents overly frequent re-allocation while ensuring that critical services receive resources promptly when needed, thus maintaining both reliability and stability.
Solution Approach 2:
The system uses feedback mechanisms by monitoring when resource capacity reaches the trigger threshold and automatically reallocating resources. This closed-loop control prevents excessive re-allocation frequency while ensuring critical services receive resources when truly needed, balancing reliability and stability.
3Reliability
If resource capacity is re-allocated dynamically, then service level agreements are maintained, but system complexity increases due to multiple modules and re-allocation logic
Solution Approach 1:
The patent segments the resource management system into distinct functional modules: a calibration module for determining the resource trigger threshold, a critical service manager module for monitoring and managing re-allocation, and underlying container runtime components. This segmentation makes the complex system more manageable and maintainable while achieving service level agreement compliance.
Solution Approach 2:
The critical service manager module acts as an intermediary between the container runtime environment and the resource allocation logic. It receives telemetry from critical services, determines when re-allocation is needed based on the trigger threshold, and executes re-allocation from non-critical services, thereby simplifying the overall system architecture while maintaining reliability.
Data Source
AI summary
Techniques for managing critical workloads in container-based computing environments are disclosed. In one example, a method determines a resource trigger threshold associated with executing at least one containerized workload associated with a first service having a first criticality level, the resource trigger threshold corresponding to a resource capacity allocated to execute the first service. The method determines when the resource capacity allocated to execute the first service reaches the resource trigger threshold, and then re-allocates resource capacity allocated to execute at least one containerized workload associated with a second service having a second criticality level to the first service when the resource trigger threshold is reached. For example, the first criticality level may be higher than the second criticality level.