CN118316885A - Method for isolating communication traffic among different services in Kubernetes cluster - Google Patents
Method for isolating communication traffic among different services in Kubernetes cluster Download PDFInfo
- Publication number
- CN118316885A CN118316885A CN202410467475.5A CN202410467475A CN118316885A CN 118316885 A CN118316885 A CN 118316885A CN 202410467475 A CN202410467475 A CN 202410467475A CN 118316885 A CN118316885 A CN 118316885A
- Authority
- CN
- China
- Prior art keywords
- network
- pod
- networks
- different services
- host
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000004891 communication Methods 0.000 title claims abstract description 24
- 238000000034 method Methods 0.000 title claims abstract description 19
- 230000005540 biological transmission Effects 0.000 claims abstract description 14
- 241000322338 Loeseliastrum Species 0.000 claims description 8
- 238000012545 processing Methods 0.000 claims description 3
- 238000002955 isolation Methods 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 2
- 238000011835 investigation Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention provides a method for isolating communication traffic among different services in a Kubernetes cluster. The method comprises the following steps: building a Kubernetes cluster on m hosts, wherein each host comprises a t Zhang Wuli network card; decoupling an application program into a plurality of functional modules, and disposing each functional module on a Pod; t networks are correspondingly created for t Zhang Wangka of each host, any one of the t networks is used as a cross-node network to realize cross-host network intercommunication among Pods, and the rest t-1 networks are used as additional networks; creating a network interface for each Pod, and enabling the Pod to access a cross-node network and an additional network through the network interface; deploying multiple services on the containers within each Pod, and creating a multi-port Nodeport service for the Pod; one Nodeport port is uniquely mapped to one service port on the container, so that the Pod can be used as an addressing mode to carry out isolated transmission of various communication traffic among different services in Nodeport mode.
Description
Technical Field
The invention relates to the technical field of container traffic isolation, in particular to a method for isolating communication traffic among different services in a Kubernetes cluster.
Background
In general, under the conventional configuration method of the Kubernetes cluster, cross-node network intercommunication in the cluster can be realized by applying one CNI network plug-in, and the CNI plug-in binds one network card of all nodes of the cluster as a default network card for traffic transmission in the cluster, so that the mutual communication among Pods of different nodes in the cluster is satisfied, the application program deployed in the Kubernetes cluster in the actual production environment is satisfied, and the traffic transmission requirement among all functional modules is satisfied.
However, for an application program that needs to strictly distinguish communication traffic between different services in a container in Pod, different service traffic needs to be transmitted in isolation through different network cards. However, through the conventional method, all inter-Pod communication traffic can be transmitted through a default network card, so that the requirements of isolated transmission of different service traffic cannot be met, mutual interference among the inter-Pod communication traffic is caused, the traffic transmission performance is affected, system management and fault investigation are inconvenient, the traffic of different services cannot be distinguished, and the difficulty of tracking and diagnosing problems is increased.
Disclosure of Invention
In order to solve the problem that different service traffic in a Pod needs to be transmitted in an isolated manner, the invention provides a method for isolating communication traffic among different services in a Kubernetes cluster.
The invention provides a method for isolating communication traffic among different services in a Kubernetes cluster, which comprises the following steps:
Step 1: building a Kubernetes cluster on m hosts; wherein, m-n host machines are used as Master nodes, n host machines are used as Node nodes, and each host machine comprises a t Zhang Wuli network card;
Step 2: decoupling an application program into a plurality of functional modules, and disposing each functional module on a Pod;
step 3: t networks are correspondingly created for t Zhang Wangka of each host, any one of the t networks is used as a cross-node network to realize cross-host network intercommunication among Pods, and the rest t-1 networks are used as additional networks;
step 4: creating a network interface for each Pod, and enabling the Pod to access a cross-node network and an additional network through the network interface;
step 5: deploying multiple services on the containers within each Pod, and creating a multi-port Nodeport service for the Pod; one Nodeport port is uniquely mapped to one service port on the container, so that the Pod can be used as an addressing mode to carry out isolated transmission of various communication traffic among different services in Nodeport mode.
Further, in step 2, deploying each functional module on the Pod includes:
and taking a single Pod as a minimum processing implementation unit of the functional module, and implementing one Pod or a plurality of pods in combination into one functional module.
Further, in step 3, the cross-node network is created by using a CNI network plug-in Calico according to the ith network card of all hosts, where i is a positive integer less than or equal to t.
In step 3, at least one additional network is created by using CNI network plug-in Flannel according to the jth network card of all hosts, where j is a positive integer less than or equal to t.
Further, in step 4, a network interface is created for each Pod using CNI network plug-in Multus.
The invention has the beneficial effects that:
(1) The invention utilizes the Pod multi-network card technology to create Nodeport service types provided by the Kubernetes cluster for external access, and uses the method of adding different port numbers to the physical IP address of any node of the cluster to access different services in the Pod in the cluster so as to solve the problem that different service flows cannot be transmitted in an isolated mode.
(2) The invention isolates communication flow between different services in a single container in the Pod through different network cards, can avoid mutual interference between the flows, and enables the flows of different services to independently share network bandwidth and resources, thereby realizing network isolation and performance isolation, and further improving the overall network performance and throughput.
(3) According to the invention, communication flow among different services in a single container in the Pod is isolated through different network cards, and because the control service flow is responsible for management and monitoring tasks, the safety of a network and a system is critical, and by isolating the control flow and other flows on different network cards, the safety strategy and the control measures can be implemented more easily, and potential safety risks and attacks are prevented.
(4) According to the invention, communication flow between different services in a single container in the Pod is isolated through different network cards, and problems can be tracked and diagnosed more easily by distinguishing the flow of different services, so that system management and fault investigation are facilitated.
Drawings
Fig. 1 is a flow chart of a method for isolating communication traffic between different services in a Kubernetes cluster according to an embodiment of the present invention.
Detailed Description
For the purpose of making the objects, technical solutions and advantages of the present invention more apparent, the technical solutions in the embodiments of the present invention will be clearly described below with reference to the accompanying drawings in the embodiments of the present invention, and it is apparent that the described embodiments are some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
The invention utilizes the Pod multi-network card technology to create Nodeport service types provided by the Kubernetes cluster for external access, and uses the method of adding different port numbers to the physical IP address of any node of the cluster to access different services in the Pod in the cluster so as to solve the problem that different service flows cannot be transmitted in an isolated mode.
As shown in fig. 1, an embodiment of the present invention provides a method for isolating communication traffic between different services in a Kubernetes cluster, including:
s101: building a Kubernetes cluster on m hosts; wherein, m-n host machines are used as Master nodes, n host machines are used as Node nodes, and each host machine comprises a t Zhang Wuli network card;
Specifically, a Master Node or a Node generally occupies a host, a Pod is a key component on the Node, a single Node may include multiple pods, a single container is generally created in a single Pod, and a container runtime environment is provided by a Docker. For example, the segment of Pod may be defined as 10.244.0.0/16.
S102: decoupling an application program into a plurality of functional modules, and disposing each functional module on a Pod;
Specifically, in order to enable the application program to be deployed in the Kubernetes environment to implement virtualization, the present embodiment needs to split the complex application program into different functional modules by decoupling, and plan the number of Pod needed to implement each functional module, the host nodes required to be deployed by each Pod, and the traffic types that the Pod needs to receive and process.
In one embodiment of the present invention, a single Pod is used as a minimum processing implementation unit of a functional module, and one Pod or a plurality of pods are combined to form a complete functional module.
S103: t networks are correspondingly created for t Zhang Wangka of each host, any one of the t networks is used as a cross-node network to realize cross-host network intercommunication among Pods, and the rest t-1 networks are used as additional networks;
Specifically, a network card creates a network correspondingly. In the embodiment of the present invention, a CNI network plug-in Calico is used to create a cross-node network according to the ith network card of all hosts, and the specific implementation is as follows: and reading cluster node network card information, selecting a network card to establish Calico a default network, and using a BGP mode of Calico network plug-in to realize network access between Pods in a cluster by using the node as a virtual router through a BGP routing protocol.
For example: the CNI network plug-in Calico is applied to synchronize routing tables for cluster nodes through BGP protocol based on BGP protocol, and uses each node as a router, uses network card 1 binding all nodes of the cluster as a flow transmission network card of Calico network, designates a network segment accessing Pod in Calico network, cannot coincide with a network segment of a host of the cluster node and a Pod network segment set in step S101, and can be designated as 10.255.0.0/16, for example.
Creating at least one additional network according to the j-th network card of all hosts by using a CNI network plug-in Flanel, wherein the implementation is as follows: and reading the network card information of the cluster node, selecting the network card to establish a Flannel additional network, and encapsulating the inter-Pod communication data packet in the cluster by the Flannel network plug-in based on the Overlay network to carry out route forwarding and communication.
For example, the CNI network plug-in Flannel is applied to encapsulate the data frame in the virtual network into the packet in the actual physical network for transmission based on VXLAN mode, so that an overlay network is constructed by a "tunnel" mechanism, the network card 2 binding all the nodes of the cluster is used as the traffic transmission network card of the Flannel network, and the network segment accessing the Pod in the Flannel network is designated to be consistent with the Pod network segment set in step S101, namely 10.244.0.0/16.
S104: creating a network interface for each Pod, and enabling the Pod to access a cross-node network and an additional network through the network interface;
specifically, in the embodiment of the present invention, a network interface is created for each Pod by using the CNI network plug-in Multus, which is specifically implemented as follows: multus reads the existing network plug-in file in the cluster, creates an additional network interface for the cluster, and Pod calls Multus add the additional network interface for its internal container.
For example, the application CNI network plug-in Multus reads the other CNI network plug-in files in the cluster node/etc/CNI/net.d and automatically creates a new file for Multus based on the default network configuration, and then creates custom resources, networkAttachmentDefinition, for storing interface information of the additional CNI network plug-ins. Call NetworkAttachmentDefinition adds an additional network interface for Pod.
S105: deploying multiple services on the containers within each Pod, and creating a multi-port Nodeport service for the Pod; one Nodeport port is mapped to one service port on the container only, so that the Pod can be used as an addressing mode to carry out isolation transmission of various communication traffic among different services in Nodeport mode, and finally, the service in the container can be accessed into a cluster network for traffic transmission through different network cards through default and additional network interfaces.
Specifically, a single container in a single Pod exposes multiple ports to the outside for simultaneously providing multiple service functions, each service function corresponds to different service flows, and multiple services correspondingly occupy different ports to provide access to the outside. A service type is created Nodeport for the Pod, and the plurality of ports are also exposed such that the destination ports of Nodeport are mapped to the exposed ports of the Pod, respectively.
When the inside and outside of the cluster requests to access the IP address and NodePort ports of any cluster node, the traffic is forwarded to ClusterIP of the service, the service forwards the traffic to the corresponding Pod according to the defined load balancing strategy, different services provided by different ports in the Pod are accessed through the corresponding mapping of the port numbers of different hosts of the cluster node, and the isolated transmission of different service traffic carried by different physical network cards of the cluster node is selected.
In the method provided by the embodiment of the invention, the application program is formed by a plurality of groups of Pod, the Pod is respectively deployed on a plurality of nodes of the Kubernetes cluster, the Kubernetes are uniformly arranged and managed, a plurality of service functions in the Pod expose different port numbers for providing respective services to the outside, the service functions are mutually accessed in a Nodeport mode as an addressing mode, and the Kubernetes cluster nodes are used for carrying out isolated transmission by different network cards.
Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present invention, and are not limiting; although the invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present invention.
Claims (5)
1. A method for isolating communication traffic between different services within a Kubernetes cluster, comprising:
Step 1: building a Kubernetes cluster on m hosts; wherein, m-n host machines are used as Master nodes, n host machines are used as Node nodes, and each host machine comprises a t Zhang Wuli network card;
Step 2: decoupling an application program into a plurality of functional modules, and disposing each functional module on a Pod;
step 3: t networks are correspondingly created for t Zhang Wangka of each host, any one of the t networks is used as a cross-node network to realize cross-host network intercommunication among Pods, and the rest t-1 networks are used as additional networks;
step 4: creating a network interface for each Pod, and enabling the Pod to access a cross-node network and an additional network through the network interface;
step 5: deploying multiple services on the containers within each Pod, and creating a multi-port Nodeport service for the Pod; one Nodeport port is uniquely mapped to one service port on the container, so that the Pod can be used as an addressing mode to carry out isolated transmission of various communication traffic among different services in Nodeport mode.
2. The method of claim 1, wherein in step 2, deploying each functional module on Pod comprises:
and taking a single Pod as a minimum processing implementation unit of the functional module, and implementing one Pod or a plurality of pods in combination into one functional module.
3. The method for isolating communication traffic between different services in a Kubernetes cluster according to claim 1, wherein in step 3, the cross-node network is created by using a CNI network plug-in Calico according to the ith network card of all hosts, where i is a positive integer less than or equal to t.
4. The method for isolating communication traffic between different services in a Kubernetes cluster according to claim 1, wherein in step 3, at least one additional network is created by using a CNI network plug-in Flannel according to a jth network card of all hosts, where j is a positive integer less than or equal to t.
5. The method of claim 1, wherein in step 4, a CNI network plug-in Multus is used to create a network interface for each Pod.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410467475.5A CN118316885A (en) | 2024-04-18 | 2024-04-18 | Method for isolating communication traffic among different services in Kubernetes cluster |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410467475.5A CN118316885A (en) | 2024-04-18 | 2024-04-18 | Method for isolating communication traffic among different services in Kubernetes cluster |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN118316885A true CN118316885A (en) | 2024-07-09 |
Family
ID=91726919
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410467475.5A Pending CN118316885A (en) | 2024-04-18 | 2024-04-18 | Method for isolating communication traffic among different services in Kubernetes cluster |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN118316885A (en) |
-
2024
- 2024-04-18 CN CN202410467475.5A patent/CN118316885A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4454499B2 (en) | Transmission system with functionality of multiple logical sub-transmission systems | |
| CN109716717A (en) | From software-defined network controller management virtual port channel switching equipment peer-to-peer | |
| US8799513B2 (en) | Managing resources for IP networking | |
| JP5529251B2 (en) | Method and system for providing a logical network layer for transmitting input / output data | |
| EP2192725B1 (en) | Packet switch being partitioned into virtual LANs (VLANs) | |
| CN111800326B (en) | Message transmission method and device, processing node and storage medium | |
| US20140310393A1 (en) | Virtual Network and Management Method of Virtual Network | |
| US20080123536A1 (en) | Virtual network testing and deployment using network stack instances and containers | |
| US20200007472A1 (en) | Service insertion in basic virtual network environment | |
| CN112491984B (en) | Container editing engine cluster management system based on virtual network bridge | |
| CN112130957A (en) | Method and system for using intelligent network card for breaking through virtualization isolation of container | |
| WO2023165137A1 (en) | Cross-cluster network communication system and method | |
| CN112600903B (en) | Elastic virtual network card migration method | |
| CN112583655B (en) | Data transmission method and device, electronic equipment and readable storage medium | |
| US8861545B2 (en) | Method for performing protocol translation in a network switch | |
| CN115987778B (en) | Container communication method based on Kubernetes cluster | |
| CN114143258B (en) | Service agent method based on Open vSwitch under Kubernetes environment | |
| CN109450768B (en) | Method for interconnecting containers and system for interconnecting containers | |
| CN114760165A (en) | Message transmission method, device and system | |
| CN118316885A (en) | Method for isolating communication traffic among different services in Kubernetes cluster | |
| CN111465038A (en) | Method and system for realizing two-layer communication between CPE and enterprise router | |
| CN116112435A (en) | Message transmission method, device, equipment and storage medium | |
| CN114390101A (en) | Kubernetes load balancing method based on BGP networking | |
| CN115208857A (en) | Address allocation method, device and equipment | |
| CN114301665B (en) | Data processing method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| CB02 | Change of applicant information |
Country or region after: China Address after: 450000 Science Avenue 62, Zhengzhou High-tech Zone, Henan Province Applicant after: Information Engineering University of the Chinese People's Liberation Army Cyberspace Force Address before: No. 62 Science Avenue, High tech Zone, Zhengzhou City, Henan Province Applicant before: Information Engineering University of Strategic Support Force,PLA Country or region before: China |