Programmable Container Kernel Upgrade via State Snapshot
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing container kernel upgrade methods disrupt application container operations significantly, requiring lengthy interruptions for upgrades due to the need to disable and migrate running applications, and do not support customized restoration of the kernel.
Innovation Solution
A programmable container kernel upgrade method that freezes the application container, stores its current status data, restarts with a new kernel, and updates data structures using stored data to enable seamless and customized kernel upgrades without interrupting the application.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional container kernel upgrade methods are used, then the container kernel can be upgraded, but the application container operations are disrupted significantly and lengthy interruptions are required
Solution Approach 1:
The system performs preliminary actions by freezing the application container and storing its current status data (including process information, memory state, and network connections) before the actual kernel upgrade. This snapshot is taken in advance so that when the container is restarted with the new kernel, the previous state can be restored without requiring lengthy interruptions or manual intervention.
Solution Approach 2:
The patent creates a copy of the application container's status data (processes, memory, network state) before upgrade. This copy serves as a template for restoration after the kernel upgrade, allowing the container to be quickly rebound to its previous operational state without actually migrating or disabling running applications during the upgrade process.
2Reliability
If traditional container kernel upgrade methods are used, then the container kernel can be upgraded, but running applications must be disabled and migrated
Solution Approach 1:
The patent enables continuous operation by freezing the application container in a suspended state rather than shutting it down completely. The container's status data is captured while still operational, and after the kernel upgrade, the container is restarted and the previous state is restored, maintaining application continuity without requiring disabling or migration of running applications.
Solution Approach 2:
The system introduces an intermediary mechanism (the status data snapshot and the programmable container kernel) that mediates between the old kernel and new kernel versions. This intermediary allows the transition to occur without directly affecting the running applications, as the status data acts as a bridge to restore the previous state after upgrade.
3Reliability
If traditional container kernel upgrade methods are used, then the container kernel can be upgraded, but customized restoration of the kernel is not supported
Solution Approach 1:
The patent implements a dynamic restoration mechanism where the programmable container kernel can adaptively restore status data based on customized policies. Rather than restoring everything exactly as before, the system can selectively restore certain processes, configurations, or states according to user-defined rules, enabling flexible and customized restoration after kernel upgrade.
Solution Approach 2:
The system allows changing parameters of the restoration process through the programmable container kernel. Users can modify restoration parameters such as which processes to restore, what configurations to apply, and how to handle data conflicts, enabling customized restoration strategies tailored to specific application needs rather than using a fixed restore procedure.
Data Source
AI summary
A container kernel upgrade based on a programmable container kernel, includes, in response to receiving a container kernel upgrade request, freezing an application container in which a to-be-upgraded first container kernel is located. Current container status data of an application container including first container kernel status data and application status data is stored. The application container is restarted by using a second container kernel used for upgrading a container kernel, where restarted container status data of the restarted application container includes second container kernel status data corresponding to the second container kernel when the application container is restarted. Using the stored current container status data, a corresponding data field is updated in a data structure of the restarted container status data. A container application is resumed running in the frozen application container in the restarted application container in response to completion of updating the restarted container status data.