Pod Affinity Scheduling Without Blueprint Changes
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing Pod scheduling methods in Kubernetes-based cloud computing systems face challenges in managing service blueprints complexity due to the need for frequent modifications to accommodate service binding relationships between Pods, especially in large-scale scenarios, leading to increased complexity and risks.
Innovation Solution
A service scheduling method that includes sorting, pre-filtering, and post-scoring stages to manage service affinity and mutual exclusion relationships between Pods without modifying their blueprints, using affinity and mutual exclusion configuration information to deploy Pods at the same or different nodes based on their relationships.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If Pod service blueprints are modified to accommodate service binding relationships, then service scheduling flexibility is improved, but blueprint complexity and risk increase
Solution Approach 1:
The patent separates service binding relationship management from Pod blueprints by introducing an independent affinity configuration mechanism. This segments the system into: (1) Pod blueprints that remain unchanged and simple, and (2) affinity configurations that handle service binding relationships. The segmentation allows flexible scheduling through configurations without complicating the blueprints themselves.
Solution Approach 2:
The patent introduces affinity configuration information as an intermediary layer between service scheduling requirements and Pod blueprints. This intermediary mechanism manages service binding relationships externally, allowing the scheduler to enforce affinity rules without modifying the Pod blueprints. The intermediary preserves blueprint simplicity while achieving scheduling flexibility.
2Adaptability or versatility
If Pod service blueprints are frequently modified for special scenarios, then service binding requirements are met, but system reliability decreases due to increased risks
Solution Approach 1:
The patent implements preliminary action by pre-defining affinity configurations that encode service binding relationships. These configurations are established in advance and stored independently, allowing the scheduler to automatically enforce binding requirements without ad-hoc blueprint modifications. This preliminary setup reduces the frequency of changes and improves reliability.
Solution Approach 2:
The patent uses copying by replicating affinity relationship definitions from service blueprints into separate affinity configuration files. Instead of modifying original blueprints, the system creates copies of the binding relationship information in a dedicated configuration format. This copying mechanism preserves the original blueprints unchanged while enabling flexible scheduling, thereby maintaining system reliability.
3Device complexity
If service blueprints are simplified without modification, then blueprint complexity is reduced, but scheduling capability for service bindings is limited
Solution Approach 1:
The patent adds another dimension to the scheduling system by introducing affinity configuration information as a separate layer. Instead of embedding service binding logic within Pod blueprints (one dimension), the system uses affinity configurations as an additional dimension that works alongside simplified blueprints. This dimensional addition enables rich scheduling capabilities without increasing blueprint complexity.
Solution Approach 2:
The patent implements universality by creating an affinity configuration mechanism that can handle multiple service binding scenarios through a unified approach. The same affinity configuration structure can represent various binding relationships (required, preferred, anti-affinity) without requiring different blueprint formats. This universal mechanism provides versatile scheduling capability while keeping blueprints simple and standardized.
Data Source
AI summary
A service scheduling method, an electronic device, and a computer-readable storage medium are disclosed. The service scheduling method may include: performing screening processing on a first Pod sequence to obtain a second Pod sequence, where the screening processing includes: traversing Pods in the first Pod sequence, and for each Pod in the first Pod sequence, in response to determining according to affinity configuration information in service association configuration information that all affinity Pods corresponding to the Pod are present in the first Pod sequence, combining the Pod and all the affinity Pods to obtain a transition Pod; and performing node deployment for a target Pod in the second Pod sequence, where the node deployment includes: in response to determining that the target Pod is the transition Pod, deploying all the Pods, which are combined to obtain the target Pod, at the same target node.