Single CNI Instance for Multi-Network Pod Configuration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current methods for configuring multiple virtual network interfaces in virtualized computing environments require separate CNI instances and brokers, leading to increased communication and resource overhead, as well as limited versatility in working with different orchestration systems and network infrastructures.
Innovation Solution
A single Container Networking Interface (CNI) instance is used to obtain and process a list of virtual network interfaces from a network controller, creating and attaching them to a pod, thereby enabling packetized communications across multiple networks without the need for separate CNI instances or brokers, and enhancing compatibility with various orchestration systems.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If separate CNI instances and brokers are used to configure multiple virtual network interfaces, then each network interface can be configured independently, but communication overhead and resource consumption increase
Solution Approach 1:
The patent combines multiple separate CNI instances and brokers into a single integrated CNI instance that can handle multiple virtual network interfaces simultaneously. This merging eliminates the need for multiple independent configuration processes, reducing communication overhead while maintaining configuration reliability through a unified management approach.
Solution Approach 2:
The CNI instance is designed with multi-functionality to handle various virtual network interface configurations through a single unified interface. It can manage multiple network interfaces, different network types (overlay, underlay, VLAN), and various orchestration systems without requiring separate specialized instances, thereby reducing overall system overhead.
2Adaptability or versatility
If separate CNI instances are used for each virtual network interface, then each interface can be managed independently, but device complexity increases
Solution Approach 1:
The CNI instance implements universal functionality to manage multiple types of virtual network interfaces through a single unified mechanism. It supports different network configurations (overlay, underlay, VLAN networks) and works with various orchestration systems (Kubernetes, Docker Swarm, Mesos) without requiring separate specialized instances, thereby reducing device complexity while maintaining adaptability.
Solution Approach 2:
The CNI instance employs dynamic configuration capabilities that allow it to adapt to different network interface requirements on-demand. Rather than requiring static separate instances for each interface type, the single CNI instance can dynamically adjust its behavior based on the specific network configuration needed, reducing overall system complexity.
3Adaptability or versatility
If multiple separate CNI instances are deployed to support different orchestration systems, then compatibility with various systems is achieved, but the number of components and overhead increases
Solution Approach 1:
The CNI instance is designed as a universal component that can interface with multiple orchestration systems (Kubernetes, Docker Swarm, Mesos, OpenStack) through a single unified implementation. It provides adapter mechanisms that enable compatibility with different orchestration systems without requiring separate dedicated instances for each system, thereby reducing the total quantity of CNI instances needed while maintaining broad compatibility.
Solution Approach 2:
The CNI instance acts as an intermediary layer between the virtual execution elements and various orchestration systems. This mediator approach allows a single CNI instance to communicate with multiple different orchestration systems through standardized interfaces, eliminating the need for multiple direct integrations and reducing the number of components required.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Techniques are described for creating multiple virtual network interfaces usable by a logically-related group of one or more containers ("pod") for communicating on respective virtual networks of a network infrastructure. In some examples, a control flow for pod network interface configuration on a host includes obtaining, by a CNI instance, a list of multiple virtual network interfaces from an agent of a network controller that is executing on the host. The single CNI instance processes the list of multiple virtual network interfaces to create corresponding virtual network interfaces for the pod and, for each of the virtual network interfaces, to attach the virtual network interface to the pod and to the virtual router or bridge for the host. In this way, the single CNI enables packetized communications by containers of the pod over multiple networks using the multiple virtual network interfaces configured for the pod.