SCTP Multihoming Router for Kubernetes Load-Balanced Failover
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Kubernetes environments face challenges in implementing Stream Control Transmission Protocol (SCTP) multihoming due to limitations in default services, which hinder fault-tolerant networking while maintaining load balancing capabilities.
Innovation Solution
A SCTP multihoming router (SMR) is deployed as a pod within the Kubernetes environment, utilizing a CNI plugin-in to attach to multiple networks, and performs source and destination network address translation (NAT) to establish multi-homed SCTP associations, ensuring fault-tolerant networking without sacrificing load balancing.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If Multus CNI or host network is used to attach multiple IPs to a pod, then SCTP multihoming capability is achieved, but load balancing functionality provided by default Kubernetes service objects is sacrificed
Solution Approach 1:
The patent introduces a gateway component as an intermediary between the Multus CNI multihoming mechanism and the Kubernetes service load balancing system. This gateway receives packets from the multihomed pod, performs load balancing based on service object configurations, and forwards packets to backend pods. This mediator approach allows both multihoming capability and load balancing functionality to coexist without conflict.
Solution Approach 2:
The patent segments the networking functionality into distinct components: the Multus CNI handles multihoming and multiple IP address attachment, the gateway component handles load balancing decisions, and the Kubernetes service object handles service discovery and routing. This segmentation allows each component to perform its specific function independently, preventing the sacrifice of load balancing when enabling multihoming.
2Productivity
If default Kubernetes services are used, then load balancing capabilities are maintained, but SCTP multihoming capability is limited to single IP path
Solution Approach 1:
The gateway component is designed with multi-functionality, serving both as a load balancer for Kubernetes services and as an SCTP multihoming router. It can process packets from multiple IP addresses simultaneously, perform load balancing decisions, and maintain SCTP associations across different IP paths. This universal approach enables the system to support both load balancing and multihoming without requiring separate dedicated components.
3Reliability
If multiple IP paths are implemented in Kubernetes, then fault tolerance is improved, but device complexity increases
Solution Approach 1:
The gateway component automatically performs SCTP header modifications, IP address translation, and packet routing decisions without requiring manual configuration of complex multihoming rules. It self-manages the SCTP associations and failover decisions, reducing the operational complexity while maintaining fault tolerance capabilities through automated mechanisms.
Solution Approach 2:
The patent utilizes dynamic parameter changes in SCTP headers and IP addresses to manage multihoming. The gateway modifies SCTP destination addresses and performs source IP translation based on current network conditions and service configurations. These parameter changes enable flexible routing and fault tolerance without requiring complex static configurations, as the system adapts to network changes dynamically.
Data Source
AI summary
A method for providing stream control transmission protocol (SCTP) multihoming between a Kubernetes environment and a non-Kubernetes environment includes receiving, at an SCTP multihoming router (SMR) deployed as a pod within the Kubernetes environment and from a client in the non-Kubernetes environment, an SCTP INIT message for establishing a multi-homed SCTP association between first and second Internet protocol (IP) addresses of the client and first and second local IP addresses of the SMR. The first and second local IP addresses of the SMR are added to an SCTP header of the SCTP INIT message. Source and destination network address translations (NATs) are performed to change a source IP address and a destination IP address in an IP header of an IP datagram carrying the SCTP INIT message to a third local IP address of the SMR and a service IP address of a service in the Kubernetes environment, respectively.