Kubernetes Container Authority Control via CRI Interface
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current solutions for device mapping in Kubernetes (k8s) require either dedicated hardware plugins or privileged mode, which limit flexibility and control over container authority and resource allocation.
Innovation Solution
A method and apparatus for creating a container that acquires a description file for resource demands, determines a target work node based on idle resources, and sends a CRI request to a container engine with configuration information to create and manage containers, allowing for controlled authority and resource allocation without privileged mode.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If dedicated hardware plugins are used for device mapping in Kubernetes, then device access functionality is achieved, but system complexity and hardware requirements increase
Solution Approach 1:
The CRI interface is designed as a universal interface that can handle multiple device types (GPUs, FPGAs, storage devices, network devices) through a single standardized protocol, eliminating the need for dedicated hardware plugins for each device type. The container engine implements this universal interface to manage diverse devices uniformly.
Solution Approach 2:
The CRI interface acts as an intermediary layer between the Kubernetes scheduler and the container engine, enabling device mapping functionality without requiring direct integration or dedicated plugins. This mediator approach simplifies the system architecture by providing a standardized communication protocol that handles device allocation requests.
2Ease of operation
If privileged mode is enabled for Pod in Kubernetes, then container authority and control are improved, but system security and resource isolation are compromised
Solution Approach 1:
Instead of granting privileged mode globally to entire Pods, the invention implements fine-grained authority control at the container level. The CRI interface allows specific containers within a Pod to receive targeted device access permissions based on their individual requirements, while other containers maintain standard security restrictions. This local quality approach provides necessary container authority without compromising overall system security.
Solution Approach 2:
The invention segments device access authority from the Pod level to the container level. Rather than enabling privileged mode for the entire Pod, each container can be individually configured with specific device access rights through the CRI interface. This segmentation allows precise control over which containers have enhanced authority, maintaining security isolation while providing necessary operational capabilities.
3Reliability
If flexible device allocation is implemented without privileged mode, then system security is maintained, but device mapping capability is limited
Solution Approach 1:
The CRI interface provides a universal mechanism that enables flexible device allocation across multiple device types without requiring privileged mode. The interface handles GPU allocation, FPGA assignment, storage device mapping, and network device configuration through standardized requests, maintaining security while providing comprehensive device mapping capability.
Solution Approach 2:
The CRI interface serves as an intermediary that enables sophisticated device mapping capabilities while maintaining security boundaries. It translates Kubernetes scheduling decisions into container engine-specific device allocation commands, providing versatile device management functionality without requiring containers to run in privileged mode. The interface handles device discovery, allocation, and cleanup operations securely.
Data Source
AI summary
A method for creating a container, an apparatus for creating a container, a device, a medium, and a program product are provided. The method includes: acquiring a description file of a to-be-scheduled container group (Pod), where the description file of the Pod is used for describing resource demand information; determining, based on the description file of the to-be-scheduled Pod and idle resource information of each of work nodes, a target work node from the work nodes, and binding the to-be-scheduled Pod to the target work node; and sending a container runtime interface (CRI) request to a container engine, where the CRI request is used for instructing node to create a target container at the target work based on configuration information in the CRI request, and the configuration information is used for limiting an authority of the target container.