NCaaS Controller Cross-VPC Policy Enforcement

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

There is a need for defining policies in a software-defined network (SDN) for enforcing traffic to and from sets of containers in a Kubernetes container cluster, which existing technologies have not effectively addressed.

Innovation Solution

A method is provided where a second SDN controller cluster, residing in a second VPC, receives resource identifiers from adapters deployed in the first VPC. Using these identifiers, the second SDN controller cluster defines and distributes service policies to network elements to enforce on data messages associated with machines in the first VPC.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a single SDN controller cluster is used to manage container networks, then control is centralized and simple, but it cannot effectively define policies for third-party container clusters in different VPCs

Engineering Contradiction:
Improveability to define policies across multiple VPCsVSAvoidSDN controller architecture
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The SDN controller is designed to perform multiple functions: it acts as both a Kubernetes SDN controller for managing container networks and as a network virtualization controller for defining service policies across multiple VPCs. This multi-functionality allows a single controller to handle both container network management and cross-VPC policy enforcement without requiring separate specialized controllers.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The SDN controller is divided into distinct functional components: a Kubernetes SDN controller cluster that manages container networks and a network virtualization controller cluster that defines service policies. These segmented components work together through standardized interfaces, allowing independent operation and specialization while maintaining overall system coherence and policy enforcement capability across multiple VPCs.

Inventive Principle:
Principle #1Segmentation

2Adaptability or versatility

If existing SDN controllers are used for container clusters, then they manage internal container networking, but they cannot define service policies for traffic between different container clusters in different VPCs

Engineering Contradiction:
Improvepolicy definition capability for external trafficVSAvoidoperational simplicity
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The patent combines the Kubernetes SDN controller and network virtualization controller into a unified system where the same controller infrastructure manages both internal container networking and external cross-VPC service policies. This merging eliminates the need for separate controllers and simplifies operation by providing a single point of control for all networking and policy management.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The SDN controller acts as an intermediary between container clusters in different VPCs, receiving resource identifiers from adapters in one VPC and enforcing service policies on traffic to and from containers in another VPC. This intermediary role enables policy definition for external traffic while maintaining operational simplicity through centralized control.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Adaptability or versatility

If a distributed SDN controller architecture is implemented to enable policy enforcement across multiple VPCs, then adaptability improves, but system complexity increases

Engineering Contradiction:
Improvecross-VPC policy enforcement capabilityVSAvoidcontroller cluster architecture
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The SDN controller architecture is designed to be dynamic, allowing it to adapt its behavior based on the operational context. The controller can function as a Kubernetes SDN controller for container networks, as a network virtualization controller for service policies, or both simultaneously. This dynamic capability enables cross-VPC policy enforcement while managing complexity through context-aware operation.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system implements feedback mechanisms where the SDN controller receives resource identifiers from adapters deployed in VPCs, uses these identifiers to define service policies, and then enforces these policies on traffic. The controller continuously monitors and adjusts policy enforcement based on received identifiers and traffic patterns, enabling adaptive cross-VPC policy management.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS20250106116A1Network controller as a service (NCAAS) to define network policies for third-party container clusters
Publication Date: 2025.03.27 VMWARE INC
  • US20250106116A1 patent drawing
  • US20250106116A1 patent drawing
  • US20250106116A1 patent drawing

AI summary

Some embodiments provide a method for using a first SDN controller as a Network Controller as a Service (NCaaS). The first SDN controller receives a first set of network attributes regarding network elements in a first container cluster configured by a second SDN controller, and a second set of network attributes regarding network elements in a second container cluster configured by a third SDN controller. These container clusters do not have a controller for defining particular network policies. Based on the sets of network attributes, the first SDN controller defines the particular network policies to control forwarding data messages between the first and second container clusters. The first SDN controller distributes at least a subset of the particular network policies to the first container cluster in order for network elements at the first container cluster to enforce on data messages exchanged between the first and second container clusters.