A container network management method, device and electronic equipment

Abstract

This application discloses a container network management method, apparatus, and electronic device. The method, applied to an analysis engine, includes: acquiring connection tracking information and container metadata from nodes in a container network; wherein the connection tracking information includes at least one connection tracking record, containing the source and destination addresses for both the access initiation and response directions; and the container metadata includes container instance addresses and container instance description information; determining the address of the target container instance initiating or being accessed based on the matching relationship between the access initiation and response addresses in the connection tracking record; searching for the corresponding container instance description information in the container metadata based on the target container instance address; and generating a first tracing result based on the connection tracking record and the container instance description information. This method enables accurate tracing from node addresses to container instance addresses.

Description

Technical Field

[0001] This application relates to the field of cloud-native technology, and in particular to a container network management method, apparatus, and electronic device. Background Technology

[0002] In the cloud-native technology ecosystem, containerized deployment and management of applications are achieved through a container orchestration platform. In a container orchestration platform, containerized applications are deployed in container instances (such as Pods) as the smallest unit. The container orchestration platform assigns an independent IP address to each container instance and manages communication between container instances and network connections between container instances and the outside world through the Container Network Interface (CNI) plugin, thereby forming a container network.

[0003] Among related technologies, traffic monitoring and security analysis solutions for container networks mainly include: service mesh proxy mode, kernel-mode data collection mode, and software-defined network (SDN) controller integration mode.

[0004] However, the above solutions generally suffer from a tracing blind spot when monitoring container instances accessing external services or when monitoring external access to container instances: they can only see the node IP, but cannot identify which container instance it is. Taking container instance accessing external services as an example, the node hosting the container instance performs Source Network Address Translation (SNAT), converting the container instance IP to the node IP. This means that from an external perspective, only the node IP is visible. Therefore, in the event of a security incident, operations personnel can only trace it back to the node level, not the container instance.

[0005] How to achieve accurate tracing from node IP to the original container instance IP in a container network environment, especially in scenarios with Network Address Translation (NAT), is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0006] This application provides a container network management method, apparatus, and electronic device that enables accurate tracing from node IP to the original container instance IP.

[0007] The embodiments of this application adopt the following technical solutions: Firstly, a container network management method is provided for application in an analytics engine, the method comprising: Obtain connection tracking information and container metadata from nodes in the container network. The connection tracking information includes at least one connection tracking record, which contains the source and destination addresses of the access initiation direction and the source and destination addresses of the access response direction. The container metadata contains the container instance address and container instance description information. Based on the matching relationship between the address of the access initiation direction and the address of the access response direction in the connection tracking record, the address of the target container instance that initiated or was accessed is determined. Based on the address of the target container instance, the corresponding container instance description information is found in the container metadata; A first tracing result is generated based on the connection tracking record and the container instance description information.

[0008] Secondly, a container network management device is provided for use in an analytics engine, the device comprising: The data acquisition module is used to acquire connection tracking information and container metadata from nodes in the container network. The connection tracking information includes at least one connection tracking record, which contains the source and destination addresses of the access initiation direction and the source and destination addresses of the access response direction. The container metadata contains the container instance address and container instance description information. The first determining module is used to determine the address of the target container instance that initiated or was accessed based on the matching relationship between the address of the access initiation direction and the address of the access response direction in the connection tracking record. The first query module is used to search for the corresponding container instance description information in the container metadata based on the address of the target container instance; The first generation module is used to generate a first tracing result based on the connection tracking record and the container instance description information.

[0009] Thirdly, an electronic device is provided, comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the method as described in the first aspect.

[0010] Fourthly, a computer-readable storage medium is provided, wherein when instructions in the storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform the method described in the first aspect.

[0011] Fifthly, a computer program product is provided, which is stored in a storage medium and, when executed by at least one processor, implements the method described in the first aspect.

[0012] In this embodiment, the analysis engine can obtain connection tracking information and container metadata from nodes in the container network. The connection tracking records include the source and destination addresses of the access initiation and response directions, while the container metadata includes the container instance address and description information. Based on the matching relationship between the address of the access initiation direction and the address of the access response direction, the target container instance address that initiated or was accessed is determined. The corresponding container instance description information is then searched in the container metadata based on this address. Finally, a first tracing result is generated. Because the address of the target container instance and its description information are directly determined based on the matching relationship between addresses in different directions in the connection tracking records, accurate tracing from the node address to the container instance address can be achieved. Therefore, when a security incident occurs, the source of the fault or attack can be accurately located to a specific container instance, rather than only being traced back to the node level. Attached Figure Description

[0013] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart illustrating a container network management method provided in an embodiment of this application.

[0014] Figure 2 This is a schematic diagram of the structure of a container network management device provided in an embodiment of this application.

[0015] Figure 3 This is a schematic diagram of the hardware structure of an electronic device provided in one embodiment of this application. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0017] In related technologies, within container orchestration platforms (such as Kubernetes), traffic monitoring and security analysis of container networks primarily employ the following three technical solutions: 1) Service Mesh Proxy Mode: By injecting a Sidecar proxy container (such as Envoy) into the business container instance (such as Pod), all incoming and outgoing traffic is intercepted. After parsing the traffic, the proxy container generates access logs and reports them to the central system.

[0018] 2) Kernel-mode data acquisition mode: Based on extended Berkeley PacketFilter (eBPF) technology, hook functions are attached to the node kernel to capture network packets or system calls. For example, CiliumHubble uses this technology to efficiently acquire network stream data.

[0019] 3) Software Defined Network (SDN) controller integration mode: Utilizes the application programming interface (API) of Container Network Interface (CNI) plugins (such as Calico, Flannel, etc.) to obtain network policies and traffic statistics information, usually supplemented by flow sampling technology (such as sFlow) for network monitoring.

[0020] The above-mentioned technical solutions have the following drawbacks: 1) There is a blind spot in Network Address Translation (NAT) tracing. All three approaches share a common drawback when monitoring north-south traffic (communication between the cluster and the outside world): when container instances within the cluster access external services, the nodes perform Source Network Address Translation (SNAT), converting the container instance IP to the node IP. This conversion leads to the following: Service Mesh Proxy Mode: Although the Sidecar can see the container instance IP, the traffic leaving the node is still overridden by the node's SNAT rules, and the central system ultimately receives the node IP; Kernel-mode Acquisition Mode: Although eBPF can capture the original data packets, after NAT conversion, without associating with the kernel connection tracking (conntrack) table, it is impossible to establish a mapping relationship between the "original container instance IP and the converted node IP"; SDN Controller Integration Mode: Relying on the CNI plugin API, it can only obtain IP allocation information and cannot perceive the dynamic NAT conversion process.

[0021] The end result is that when an external server is attacked, security personnel can only locate the node IP in the container network when tracing the attack, but cannot pinpoint the specific "culprit container instance." In attack and defense scenarios, this means that attackers can use a compromised node to cover up their true attack source, and security teams cannot implement precise isolation.

[0022] 2) East-West traffic context missing issue Even for communication between container instances within a cluster, existing solutions suffer from a severe "data fragmentation" problem: the collected network traffic only contains the IP 5-tuple (source IP, source port, destination IP, destination port, protocol type), lacking business context. When a security alert is triggered (e.g., an abnormal scan is detected from IP address A to IP address B), operations personnel cannot directly determine the business affiliation of these two IP addresses (i.e., which specific business application corresponds to each IP address). Manual login to the node is required to query the container instance name corresponding to the IP address using container orchestration platform command-line tools (such as kubectl) or container runtime command-line tools (such as crectl), delaying optimal response time. In environments with dynamic container scheduling and frequent IP address changes, this "post-event manual query" method is almost impractical.

[0023] 3) The contradiction between performance and coverage Service mesh proxy mode: Although it can obtain Layer 7 information, each container instance needs to be injected with a Sidecar container, which brings significant additional resource overhead and increases request latency; Kernel-mode data collection mode: Although eBPF is efficient, it has strict requirements on kernel version (e.g., it requires Linux kernel version 4.9 or above), and cannot be used on older systems such as CentOS 7, resulting in coverage blind spots; SDN controller integration mode: Based on sampling (such as sFlow), the accuracy is insufficient and cannot meet the accuracy requirements of security tracing.

[0024] 4) Storage costs constrain historical tracing issues. The existing solutions mentioned above still face significant challenges in data storage: to save historical connection data at the second level for later traceability, the storage volume increases linearly with the number of connections and time. Taking a cluster with 100,000 concurrent connections per second as an example, storing a full snapshot every second would generate 3.6 billion records in one hour, resulting in extremely high storage costs.

[0025] To address at least one of the aforementioned problems, embodiments of this application provide a container network management method, apparatus, and electronic device, the method being executable by an electronic device or software installed in the electronic device.

[0026] In some embodiments, to implement the container network management method proposed in this application, this application proposes an "end-edge-cloud" collaborative analysis system, including the following core components: Node Collector: A resident agent deployed on a node in a container network, responsible for collecting local multi-source data for that node, including connection tracking data, container metadata, and node self-description information.

[0027] Data pipeline: High-throughput, low-latency message queues (such as Kafka and Pulsar) are used to reliably transmit the data reported by the node collectors to the central end and to act as a buffer to cope with traffic bursts.

[0028] The correlation analysis engine (hereinafter referred to as the analysis engine) is the core processing unit located at the central end. It is responsible for receiving the raw data reported by the data pipeline and performing data cleaning, time alignment, NAT traversal correlation, session reassembly, and persistent storage.

[0029] Visualization and Search Interface: Provides a human-computer interactive front-end system that supports multi-dimensional traffic retrieval, topology display, threat hunting, and report export.

[0030] The following description, in conjunction with the accompanying drawings, illustrates a container network management method proposed in an embodiment of this application.

[0031] First, to address the blind spot problem in NAT source tracing, one embodiment of this application proposes a container network management method, which can be applied to the aforementioned analysis engine. This method can penetrate the node-level SNAT and Destination Network Address Translation (DNAT) methods of the container orchestration platform, reconstructing the complete communication link of "real source container instance address → translated node address → external destination address," achieving accurate container-level source tracing in north-south traffic scenarios. For example... Figure 1 As shown, the method may include: Step 101: Obtain connection tracking information and container metadata from nodes in the container network. The connection tracking information includes at least one connection tracking record, which contains the source and destination addresses of the access initiation direction and the source and destination addresses of the access response direction. The container metadata contains the container instance address and container instance description information.

[0032] In some embodiments, a container network refers to an interconnected network provided by a container orchestration platform (such as Kubernetes) for container instances. In a container network, each container instance is assigned an independent IP address, and communication between container instances and between container instances and the external network is managed through the Container Network Interface (CNI) plugin. A node refers to a worker machine in the container orchestration platform, which can be a physical server, virtual machine, or cloud host; each node typically runs multiple container instances. A connection refers to a communication session established between container instances or between a container instance and an external service; each connection corresponds to a connection trace record in the node kernel.

[0033] In some embodiments, the address may include, but is not limited to, an IP address and / or a port. Specifically, for a container instance, its address may be an IP address; for a node, its address may be an IP address and / or a port; and for an external service, its address may be an IP address and / or a port. It is understood that the specific form of the address may vary depending on the communication protocol and application scenario, and this application does not impose any limitations on this.

[0034] In some embodiments, step 101 is performed by an analysis engine deployed at the central endpoint. The data acquired by the analysis engine originates from node collectors. A node collector is a resident agent deployed on each node, responsible for executing local multi-source data acquisition tasks.

[0035] In some embodiments, the connection tracking information is obtained by a node collector (Agent) through a combination of fixed-interval full collection and incremental event listening. Specifically, the node collector communicates with the connection tracking module of the node kernel through the Netlink socket (Netlink) mechanism. Netlink is a socket protocol used for bidirectional communication between the kernel and user-space processes, and is widely used in Linux systems to obtain kernel status information.

[0036] In some embodiments, the node collector can perform a full data collection at a first time interval (e.g., 10 minutes, 30 minutes, or 1 hour, which can be dynamically adjusted according to the cluster size) to obtain all active connection tracking records on the current node (i.e., full data collection at fixed time intervals) and report it to the analysis engine. Optionally, the full data collection results can be used to establish a baseline state. Accordingly, obtaining connection tracking information and container metadata from nodes in the container network may include: receiving the currently active connection tracking records on the node that are fully collected and reported by the node at the first time interval, and receiving the change information of the connection tracking records collected and reported by the node within the first time interval.

[0037] In some embodiments, a connection tracking record may include at least one of the following fields: The source IP address and source port of the access originating direction (orig_src_ip, orig_src_port); Access the destination IP address and destination port (orig_dst_ip, orig_dst_port) of the initiating direction. Access the source IP address and source port of the reply direction (reply_src_ip, reply_src_port); Access the destination IP address and destination port of the reply direction (reply_dst_ip, reply_dst_port); Protocol type, such as Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). Connection state, such as ESTABLISHED (established) or TIME_WAIT (waiting to close).

[0038] In this context, the access initiation direction refers to the direction from which the party initiating the communication points to the party receiving the communication, while the access response direction refers to the direction from which the party receiving the communication responds to the party initiating the communication.

[0039] In some embodiments, during the first time interval, the node collector can also monitor real-time changes in the kernel connection tracking table through Netlink's event subscription mechanism, including events such as connection creation (new), update, and destruction. Once such an event occurs (i.e., incremental time monitoring), the node collector reports the connection tracking record change information corresponding to the event to the analysis engine without waiting for the next full collection cycle. Accordingly, obtaining connection tracking information and container metadata from nodes in the container network may also include: receiving the updated and reported container instance information table of the node.

[0040] In some embodiments, the container metadata is collected in real time by the node collector listening to the container runtime event interface. Specifically, the node collector captures the lifecycle changes of container instances (such as Pods) in real time by listening to the event interface of the control components (such as kubelet) of the container orchestration platform or the container runtime (such as containerd, Docker), including the creation, destruction, and IP address changes of container instances.

[0041] In some embodiments, the node collector may maintain a container instance information table locally, which may contain the following fields: Container instance name (pod_name); Namespace; Container instance IP address (pod_ip); The node it belongs to (node_name); Last updated timestamp (last_seen).

[0042] When a container instance changes, the node collector can immediately update its local table and report the change event (including a timestamp) to the data pipeline. The data pipeline then reports this to the analytics engine. Accordingly, the analytics engine receives the container instance information table reported by the node collector, thereby obtaining the container metadata.

[0043] The above data acquisition scheme is a low-overhead and highly compatible acquisition solution: it does not require intrusion into business container instances, does not rely on new kernel features such as eBPF, and is based on the connection tracking (conntrack) module that exists in Linux kernel version 2.6 and above, achieving full coverage of old environments.

[0044] In addition, through the above data collection methods, the analysis engine can obtain core data for subsequent NAT traversal and source tracing—connection tracking records and container metadata, laying a data foundation for restoring the complete communication link.

[0045] Optionally, after step 101 and before step 102 or step 103 below, the container network management method proposed in this application embodiment may further include: using a sliding time window to time-align the connection tracking record and the container metadata, wherein the sliding time window is centered on the timestamp of the connection tracking record, and container metadata with the same container instance address is retrieved and aligned within the sliding time window.

[0046] In some embodiments, since network events and container metadata events may have slight time differences (typically on the order of milliseconds) due to network latency or processing order, the analysis engine uses a sliding time window to align the two types of events. The size of the sliding time window can be configured according to the actual network environment and accuracy requirements, for example, it can be configured to 10 seconds. As an example, when processing a connection tracking record, the engine slides half a window forward and half a window backward from the timestamp of the connection tracking record (i.e., extending half a window forward and half a window backward from the timestamp). Within this sliding time window, container metadata events with the same container instance address are retrieved, thereby ensuring that the correct container instance information at that time point can be matched.

[0047] The time alignment operation described above can effectively avoid time mismatch between connection tracking records and container metadata caused by network latency or differences in data reporting order, providing an accurate data foundation for subsequent NAT traversal tracing and positive correlation.

[0048] Optionally, to address the low-cost storage problem of massive connection tracking records, this application embodiment designs an innovative storage model—Time-Accumulated Storage—which reduces the storage requirement from O(connections × seconds) to O(connections) while maintaining second-level time accuracy, making long-term full-history tracing of large-scale clusters possible. In this case, after step 101 and before step 102 or step 103 below, the container network management method proposed in this application embodiment may further include: Step 1: Whenever a connection trace record is received after full collection at the first time interval, a corresponding connection trace record (i.e., connection baseline record) is created in the database. This connection trace record can record the collection time, the five-tuple (i.e., source IP address, source port number, destination IP address, destination port number, and protocol type), the network address translation type (NAT type identified by comparing the IP address and port of the access initiation direction and access response direction, including source address translation SNAT or destination address translation DNAT), and the associated container instance metadata and node metadata, and initialize a liveness timer with an initial value of 0.

[0049] Step 2: Maintain a liveness timer for the connection tracking record in the database, and increment the liveness timer at a second time interval until a destruction event corresponding to the connection tracking record is received. For example, the analytics engine can maintain a scheduled task to increment the liveness timer for all active connection tracking records that have not received a destruction event at the second time interval (e.g., every second). The incremented value of the liveness timer represents the lifespan of the connection tracking record, and the second time interval is shorter than the first time interval.

[0050] Step 3: Before the next full data collection time arrives, if incremental change information (e.g., connection status update event) corresponding to the connection tracking record is received, the relevant fields of the connection tracking record in the database are updated, and the liveness timer continues to accumulate; if a destruction event corresponding to the connection tracking record is received, the record is marked as ended, and the end timestamp is recorded, and the record no longer participates in subsequent accumulation.

[0051] Through the aforementioned timing-based storage mechanism, each connection tracking record only needs to be stored once in the database. Its lifespan is dynamically accumulated by a lifespan timer, eliminating the need to repeatedly store state snapshots at specific time points. For example, assuming the first time interval (full data collection cycle) is 10 minutes, a connection is established and captured by the full data collection at time t0, and then remains alive. Over the next 10 minutes, the analysis engine increments its lifespan timer at a second time interval (e.g., every second). Before the next full data collection, the accumulated lifespan timer value for this record will be approximately 600 seconds. Compared to traditional solutions that require storing 600 time-point records, this application only needs to store one baseline record and dynamically maintain it using a lifespan timer, significantly reducing storage overhead.

[0052] In some embodiments, a combined strategy of "fixed-interval full data collection + incremental event monitoring + timed storage" can be adopted. The collaborative working process of the three is as follows: First, a full data collection is performed at fixed intervals. Every configurable first time interval T (e.g., 10 minutes, which can be dynamically adjusted according to the cluster size: the period can be shortened for small clusters to obtain more granular data, and the period can be appropriately extended for very large clusters to reduce overhead) the node collector performs a full collection and dump of connection tracking records, obtaining all active connection tracking records on the current node and providing a baseline status.

[0053] Secondly, incremental event monitoring. Within the first time interval T, the node collector captures changes in the connection tracking table in real time through the Netlink event mechanism, including connection creation (new), update, and destruction events, ensuring that critical events (such as the establishment of new connections) can be detected in time, meeting the real-time requirements of security monitoring.

[0054] Then, timed storage. In the analytics engine, by maintaining a dynamically incrementing liveness timer for each connection record, the state snapshots that would otherwise need to be repeatedly stored at time points (e.g., once per second) are compressed into a single baseline record combined with a continuously increasing liveness timer.

[0055] As an example, assuming the first time interval T = 10 minutes, taking node A as an example: At second 0, the node collector performs a full data collection, acquiring 100,000 active connection records from node A and reporting them to the analysis engine. The analysis engine creates a baseline record for each connection tracking record in the database, and the liveness timer for each record is initially set to 0 and begins to accumulate.

[0056] In the first second, 100 new connections are established on node A. The node collector captures these new connection events through incremental event listening and reports them. The analysis engine creates a new baseline record for each new connection, and the liveness timer starts accumulating from 0.

[0057] In the second second, a connection receives a destroy event, the analysis engine marks the record corresponding to that connection as terminated, and its liveness timer stops accumulating.

[0058] This process continues until the 600th second (i.e., T=10 minutes). At this point, the analysis engine accumulates the survival timers for all surviving connections. The earliest full-record survival timer may have reached 600 seconds, while the survival timers for new connections are between 0 and 600 seconds. Meanwhile, connections destroyed during this period are marked as terminated and no longer participate in subsequent accumulation.

[0059] At the 601st second, the next full data collection begins. The analysis engine stores the new full data into the database, and the survival timer for each new record starts at 0 and begins to accumulate.

[0060] Through the above design, the embodiments of this application achieve extremely low data redundancy and efficient storage utilization while ensuring data accuracy down to the second level. Taking a cluster with 100,000 concurrent connections per second as an example, traditional solutions store a full snapshot every second, requiring 3.6 billion records to be stored in one hour; while the embodiments of this application only need to store a baseline of records on the order of connections (such as 100,000 records). Each record's lifespan is dynamically represented by a liveness timer, reducing the storage requirement from O(number of connections × number of seconds) to O(number of connections), providing a feasible solution for long-term full historical tracing of large-scale clusters.

[0061] Step 102: Determine the address of the target container instance that initiated or was accessed based on the matching relationship between the address of the access initiation direction and the address of the access response direction in the connection tracking record.

[0062] In some embodiments, determining the address of the target container instance initiating or being accessed based on the matching relationship between the address in the access initiation direction and the address in the access response direction in the connection tracking record includes: The network address translation type is determined based on the matching relationship between the address in the access initiation direction and the address in the access response direction in the connection tracking record; In response to the network address translation type being Source Address Translation (SNAT), the source address of the access initiation direction is determined to be the address of the target container instance; or, In response to the network address translation type being Destination Address Translation (DNAT), the source address of the access response direction is determined to be the address of the target container instance.

[0063] Step 103: Based on the address of the target container instance, search for the corresponding container instance description information in the container metadata.

[0064] Step 104: Generate a first tracing result based on the connection tracking record and the container instance description information.

[0065] The following section provides a detailed explanation of the determination and tracing process for the two types of network address translation mentioned above, using specific examples.

[0066] 1) SNAT Scenario Example (Container Instance Accessing External Services) Suppose a container instance within the cluster (source IP 10.0.0.1, source port 12345) accesses an external server (destination IP 93.184.216.34, destination port 80). The node performs SNAT to translate the source IP to the node's IP (1.2.3.4).

[0067] The connection tracking records obtained by the analytics engine include: The source address of the access originating from is: 10.0.0.1:12345; Access originating from and destined for: 93.184.216.34:80; Access response source address: 93.184.216.34:80; Access response destination address: 1.2.3.4:6789.

[0068] Because the source address (10.0.0.1:12345) of the access initiation direction is inconsistent with the destination address (1.2.3.4:6789) of the access response direction, the analysis engine determines that SNAT has occurred and identifies the source address (10.0.0.1) of the access initiation direction as the target container instance address.

[0069] Then, using the target container instance address (10.0.0.1) as the association key, the corresponding container instance description information (such as container instance name, namespace, and node) is searched in the container metadata within the corresponding time window to generate the first tracing result.

[0070] As an example, the first source tracing result could be an enriched connection trace record, which could contain the following: the real source Pod name -> the transformed Node name -> the external destination IP.

[0071] For example, a richened connection trace record may include: the real source container instance IP: 10.0.0.1 (container instance name is payment-service-7d8f9c6d4-abc12); the transformed node: 1.2.3.4 (node ​​name is node-1); and the external destination address: 93.184.216.34:80.

[0072] Optionally, the original five-tuple information (source IP, source port, destination IP, destination port, protocol type) can also be retained in the first tracing result to facilitate subsequent evidence collection.

[0073] 2) DNAT Scenario Example (External Service Access to Container Instance) Suppose an external client (source IP 5.6.7.8, source port 54321) accesses the node IP (1.2.3.4:32767). This service is actually provided by a container instance within the cluster (destination IP 10.0.0.1, destination port 8080), exposed through the cluster service node port. The external traffic policy is local, meaning external traffic must be delivered to the target container running locally on the node. The node performs DNAT to translate the destination IP from the node IP to the container instance IP.

[0074] The connection tracking records obtained by the analytics engine include: The source address of the access originating from is: 5.6.7.8:54321; Access originating from: 1.2.3.4:32767; Access response source address: 10.0.0.1:8080; Access response destination address: 5.6.7.8:54321.

[0075] Because the destination address (1.2.3.4:32767) of the access initiation direction is inconsistent with the source address (10.0.0.1:8080) of the access response direction, the analysis engine determines that a DNAT has occurred and identifies the source address (10.0.0.1) of the access response direction as the target container instance address.

[0076] Then, using the target container instance address (10.0.0.1) as the association key, the corresponding container instance description information (such as container instance name, namespace, and node) is searched in the container metadata within the corresponding time window to generate the first tracing result.

[0077] As an example, the first source tracing result could be an enriched connection trace record, which could contain the following: external source address -> transformed node -> actual destination container instance.

[0078] For example, a richened connection trace record may include: External source address: 5.6.7.8:54321; The converted node is 1.2.3.4:32767 (the node name is node-1). The actual destination container instance is 10.0.0.1:8080 (the container instance name is database-service-5f4c8d9e-xyz78).

[0079] Optionally, the original five-tuple information (source IP, source port, destination IP, destination port, protocol type) can also be retained in the first tracing result to facilitate subsequent evidence collection.

[0080] Using the above methods, regardless of whether SNAT or DNAT occurs, the analysis engine can penetrate network address translation, determine the address of the target container instance, and associate it with its descriptive information, thereby achieving accurate container-level tracing in north-south traffic scenarios.

[0081] In a container network management method proposed in this application, an analysis engine can obtain connection tracking information and container metadata from nodes in the container network. The connection tracking records include the source and destination addresses of the access initiation and response directions, and the container metadata includes the container instance address and description information. Based on the matching relationship between the address of the access initiation direction and the address of the access response direction, the target container instance address that initiated or was accessed is determined. The corresponding container instance description information is then searched in the container metadata based on this address. Finally, a first tracing result is generated. Because the analysis engine can directly determine the address of the target container instance and associate it with its description information based on the matching relationship between addresses in different directions in the connection tracking records, it can achieve accurate tracing from the node address to the container instance address. Therefore, when a security incident occurs, the source of the fault or attack can be accurately located to a specific container instance, rather than only being traced to the node level.

[0082] In some embodiments, due to the establishment of a real-time association mechanism between kernel-mode connection tracking records and business-mode container metadata (such as container instance name, namespace, and node), network traffic records naturally carry business context, eliminating the need for manual secondary queries.

[0083] Furthermore, to address the issue of missing east-west traffic context in related technologies, in some embodiments, the container management method proposed in this application may further include: In the connection tracking record, if both the source address and destination address of the access initiation direction belong to the internal address of the container network, or if both the source address and destination address of the access response direction belong to the internal address of the container network, then based on the source address and the destination address, the container instance description information of the source container and the container instance description information of the destination container are obtained from the container metadata aligned with the time of the connection tracking record. A second tracing result is generated based on the container instance description information of the source container and the container instance description information of the destination container.

[0084] As an example, the analysis engine can query the container metadata within the current time window (or the real-time container information table) to resolve the destination address into the destination container instance description information (such as the destination container instance name and namespace), and at the same time resolve the source address into the source container instance description information (such as the source container instance name and namespace), generating a complete communication record containing the source container instance and the destination container instance.

[0085] Through the aforementioned positive correlation mechanism, when operations and maintenance personnel see a security alert (such as detecting an abnormal scan initiated by IP address A to IP address B), they can directly obtain the business context information of both communicating parties without manually logging into the node to query the container instance name corresponding to the IP, which greatly improves the timeliness of threat response and accurate isolation.

[0086] In some embodiments, the container management method proposed in this application may further include: providing a source tracing operation and display interface. Through the source tracing operation and display interface, multi-dimensional information retrieval and topology display can be achieved, helping security operations personnel quickly locate threats.

[0087] As an example, the source tracing operation and display interface can present the first source tracing result in a table view. For example, the following enriched connection tracking records can be displayed: Data collection time point (accurate to the second); The access originates from the source IP address, port, POD name, the node where the POD is located, and the namespace to which the POD belongs. The access originates from the destination IP address, port, POD name, POD node, and POD namespace. The response should include the source IP address, port, POD name, the node where the POD is located, and the namespace to which the POD belongs. The response should include the destination IP address, port, POD name, the node where the POD is located, and the namespace to which the POD belongs. Protocol type (TCP, UDP); Connection status (ESTABLISHED, TIME_WAIT); NAT information (SNAT / DNAT); Survival time (ttl_seconds).

[0088] As another example, the source tracing operation and display interface can respond to source tracing operation requests and perform source tracing searches. These requests can carry search criteria, which may include at least one of the following: connection tracking records and / or container metadata. For example, the source tracing operation and display interface can support selecting a dropdown menu for "Time Period (aggregated at X-minute intervals)," and supports inputting "Source IP of Initiating Access," "Source Port of Initiating Access," "Destination IP of Initiating Access," "Destination Port of Initiating Access," "Source IP of Response Access," "Source Port of Response Access," "Destination IP of Response Access," "Destination Port of Response Access," and "NAT Information" for retrieval or multi-field related searches. For example, inputting "Destination IP of Initiating Access 1.1.1.1" will immediately return all network connection information that accessed that IP within the X-minute time period (i.e., all field information in ①), and supports one-click report export.

[0089] In summary, the container network management method proposed in this application can achieve at least one of the following beneficial effects: 1) Precise NAT tracing capabilities This application's embodiments, by associating and linking the original direction field of the tracking records, can clearly indicate "which container instance accessed the external network through which node" or "which external client accessed which container instance" regardless of whether source address translation (SNAT) or destination address translation (DNAT) occurs, achieving container-level accurate tracing with zero false alarms. In contrast, existing technologies, in NodePort or SNAT scenarios, show the source IP as the node IP in the monitoring tools, failing to distinguish the specific container instance; traditional monitoring can only locate the node level.

[0090] 2) Low overhead and high compatibility The embodiments of this application can rely on the connection tracking (conntrack) module that exists in Linux kernel version 2.6 and above, covering all mainstream Linux distributions (including older systems such as CentOS 7), and do not require intrusion into the business container instance, thus having minimal impact on business performance. In contrast, the existing eBPF solution requires a newer kernel (≥4.9), which cannot be used in older environments; the Sidecar mode requires injecting a proxy container into each container instance, increasing business latency and resource overhead.

[0091] 3) Data consistency and completeness This application's embodiment completes the association and fusion of connection tracking data and container metadata during the data entry stage, generating a unified enriched record without requiring cross-system joint retrieval. In contrast, in existing technologies, network data and container metadata are typically stored in different systems, requiring cross-system joint retrieval for association queries, which is inefficient and error-prone. The query efficiency of this application's embodiment is several times higher than that of existing technologies, meeting the real-time requirements of security emergency response.

[0092] 4) Simple deployment, no business changes required This application embodiment only requires deploying the node collector as a daemon set on the node, which is completely transparent to the business and plug-and-play. In contrast, the existing sidecar mode requires restarting the container instance to inject the agent, involving business modifications; the eBPF solution requires upgrading the kernel or installing specific components.

[0093] 5) Low storage cost This application's embodiment employs a timed storage mechanism, requiring only one baseline record to be stored in the database for each connection tracking record. Its lifespan is dynamically accumulated via a lifespan timer, eliminating the need for repeatedly storing state snapshots at specific times. This reduces storage volume by several orders of magnitude, from O(connections × seconds) to O(connections), making long-term, full-history tracing of large-scale clusters possible. In contrast, existing technologies, if they require storing second-level historical data, experience linearly increasing storage volume with the number of connections and time, resulting in high costs.

[0094] The above describes a container network management method provided by embodiments of this application. Corresponding to the above method embodiments, embodiments of this application also provide a container network management device, which will be described below.

[0095] Figure 2 This is a schematic diagram of the structure of a container network management device 200 provided in one embodiment of this application. In one software implementation, the container network management device 200 can be applied to an analysis engine, and the device 200 may include: a data acquisition module 201, a first determination module 202, a first query module 203, and a first generation module 204.

[0096] The data acquisition module 201 is used to acquire connection tracking information and container metadata from nodes in the container network. The connection tracking information includes at least one connection tracking record, which contains the source address and destination address of the access initiation direction and the source address and destination address of the access response direction. The container metadata contains the container instance address and container instance description information.

[0097] In some embodiments, a container network refers to an interconnected network provided by a container orchestration platform (such as Kubernetes) for container instances. In a container network, each container instance is assigned an independent IP address, and communication between container instances and between container instances and the external network is managed through the Container Network Interface (CNI) plugin. A node refers to a worker machine in the container orchestration platform, which can be a physical server, virtual machine, or cloud host; each node typically runs multiple container instances. A connection refers to a communication session established between container instances or between a container instance and an external service; each connection corresponds to a connection trace record in the node kernel.

[0098] In some embodiments, the address may include, but is not limited to, an IP address and / or a port. Specifically, for a container instance, its address may be an IP address; for a node, its address may be an IP address and / or a port; and for an external service, its address may be an IP address and / or a port. It is understood that the specific form of the address may vary depending on the communication protocol and application scenario, and this application does not impose any limitations on this.

[0099] In some embodiments, the connection tracking information is obtained by a node collector (Agent) through a combination of fixed-interval full collection and incremental event listening. Specifically, the node collector communicates with the connection tracking module of the node kernel through the Netlink socket (Netlink) mechanism. Netlink is a socket protocol used for bidirectional communication between the kernel and user-space processes, and is widely used in Linux systems to obtain kernel status information.

[0100] In some embodiments, the node collector can perform a full data collection at a first time interval (e.g., 10 minutes, 30 minutes, or 1 hour, which can be dynamically adjusted according to the cluster size) to obtain all active connection tracking records on the current node (i.e., full data collection at fixed time intervals) and report them to the analysis engine. Optionally, the full data collection results can be used to establish a baseline state. Accordingly, the data acquisition module 201 can be used to: receive the currently active connection tracking records on the node that are fully collected and reported by the node at the first time interval, and receive the connection tracking record change information collected and reported by the node within the first time interval.

[0101] In some embodiments, a connection tracking record may include at least one of the following fields: The source IP address and source port of the access originating direction (orig_src_ip, orig_src_port); Access the destination IP address and destination port (orig_dst_ip, orig_dst_port) of the initiating direction. Access the source IP address and source port of the reply direction (reply_src_ip, reply_src_port); Access the destination IP address and destination port of the reply direction (reply_dst_ip, reply_dst_port); Protocol type, such as Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). Connection state, such as ESTABLISHED (established) or TIME_WAIT (waiting to close).

[0102] In this context, the access initiation direction refers to the direction from which the party initiating the communication points to the party receiving the communication, while the access response direction refers to the direction from which the party receiving the communication responds to the party initiating the communication.

[0103] In some embodiments, during the first time interval, the node collector can also monitor real-time changes in the kernel connection tracking table through Netlink's event subscription mechanism, including events such as connection creation (new), update, and destruction. Once such an event occurs (i.e., incremental time monitoring), the node collector reports the connection tracking record change information corresponding to the event to the analysis engine without waiting for the next full collection cycle. Accordingly, the data acquisition module 201 can also be used to: receive the node's updated and reported container instance information table.

[0104] In some embodiments, the container metadata is collected in real time by the node collector listening to the container runtime event interface. Specifically, the node collector captures the lifecycle changes of container instances (such as Pods) in real time by listening to the event interface of the control components (such as kubelet) of the container orchestration platform or the container runtime (such as containerd, Docker), including the creation, destruction, and IP address changes of container instances.

[0105] In some embodiments, the node collector may maintain a container instance information table locally, which may contain the following fields: Container instance name (pod_name); Namespace; Container instance IP address (pod_ip); The node it belongs to (node_name); Last updated timestamp (last_seen).

[0106] When a container instance changes, the node collector can immediately update its local table and report the change event (including a timestamp) to the data pipeline. The data pipeline then reports this to the analytics engine. Accordingly, the analytics engine receives the container instance information table reported by the node collector, thereby obtaining the container metadata.

[0107] Optionally, the container network management device proposed in this application embodiment may further include: a data alignment module, used to perform time alignment of the connection tracking record and the container metadata using a sliding time window after obtaining the connection tracking record and the container metadata, wherein the sliding time window is centered on the timestamp of the connection tracking record, and container metadata with the same container instance address is retrieved and aligned within the sliding time window.

[0108] In some embodiments, since network events and container metadata events may have slight time differences (typically on the order of milliseconds) due to network latency or processing order, the data alignment module can use a sliding time window to align the two types of events. The size of the sliding time window can be configured according to the actual network environment and accuracy requirements, for example, it can be configured to 10 seconds. As an example, when processing a connection tracking record, the module slides half a window forward and half a window backward from the timestamp of the connection tracking record (i.e., extending half a window forward and half a window backward from the timestamp). Within this sliding time window, container metadata events with the same container instance address are retrieved, thereby ensuring that the correct container instance information at that time point can be matched.

[0109] Optionally, to address the issue of low-cost storage of massive connection tracking records, the container network management device proposed in this application embodiment may further include: The record creation module is used to create a corresponding connection tracking record (i.e., a connection baseline record) in the database whenever a connection tracking record is received and fully collected at a first time interval. This connection tracking record can record the collection time, the 5-tuple (i.e., source IP address, source port number, destination IP address, destination port number, and protocol type), the network address translation type (NAT type identified by comparing the IP address and port of the access initiation direction and access response direction, including source address translation SNAT or destination address translation DNAT), and the associated container instance metadata and node metadata. It also initializes a liveness timer with an initial value of 0.

[0110] A timer maintenance module is used to maintain a liveness timer for the connection tracking records in the database, and to increment the liveness timer at a second time interval until a destruction event corresponding to the connection tracking record is received. For example, the timer maintenance module can maintain a scheduled task to increment the liveness timer of all active connection tracking records that have not received a destruction event at the second time interval (e.g., every second). The incremented value of the liveness timer is used to characterize the liveness duration of the connection tracking record, and the second time interval is shorter than the first time interval.

[0111] The incremental update module is used to update the relevant fields of the connection tracking record in the database if incremental change information (such as a connection status update event) corresponding to the connection tracking record is received before the next full data collection time arrives, and the liveness timer continues to accumulate; if a destruction event corresponding to the connection tracking record is received, the record is marked as ended and the end timestamp is recorded, and the record will no longer participate in subsequent accumulation.

[0112] The first determining module 202 is used to determine the address of the target container instance that initiates or is accessed based on the matching relationship between the address of the access initiation direction and the address of the access response direction in the connection tracking record.

[0113] In some embodiments, the first determining module 202 may specifically be used for: The network address translation type is determined based on the matching relationship between the address in the access initiation direction and the address in the access response direction in the connection tracking record; In response to the network address translation type being Source Address Translation (SNAT), the source address of the access initiation direction is determined to be the address of the target container instance; or, In response to the network address translation type being Destination Address Translation (DNAT), the source address of the access response direction is determined to be the address of the target container instance.

[0114] The first query module 203 is used to search for the corresponding container instance description information in the container metadata based on the address of the target container instance.

[0115] The first generation module 204 is used to generate a first tracing result based on the connection tracking record and the container instance description information.

[0116] The following section provides a detailed explanation of the determination and tracing process for the two types of network address translation mentioned above, using specific examples.

[0117] 1) SNAT Scenario Example (Container Instance Accessing External Services) Suppose a container instance within the cluster (source IP 10.0.0.1, source port 12345) accesses an external server (destination IP 93.184.216.34, destination port 80). The node performs SNAT to translate the source IP to the node's IP (1.2.3.4).

[0118] The connection tracking records acquired by data acquisition module 201 include: The source address of the access originating from is: 10.0.0.1:12345; Access originating from and destined for: 93.184.216.34:80; Access response source address: 93.184.216.34:80; Access response destination address: 1.2.3.4:6789.

[0119] Since the source address (10.0.0.1) of the access initiation direction is inconsistent with the destination address (1.2.3.4:6789) of the access response direction, the first determination module 202 determines that SNAT has occurred and determines the source address (10.0.0.1) of the access initiation direction as the target container instance address.

[0120] Then, the first query module 203 uses the target container instance address (10.0.0.1) as the association key to search for the corresponding container instance description information (such as container instance name, namespace, and node) in the container metadata within the corresponding time window. The first generation module 104 generates the first tracing result based on the connection tracking record and the found container instance description information.

[0121] For example, the first source tracing result could be an enriched connection tracing record, which could contain the following: the original source Pod name -> the transformed Node name -> the external destination IP.

[0122] Optionally, the original five-tuple information (source IP, source port, destination IP, destination port, protocol type) can also be retained in the first tracing result to facilitate subsequent evidence collection.

[0123] 2) DNAT Scenario Example (External Service Access to Container Instance) Suppose an external client (source IP 5.6.7.8, source port 54321) accesses the node IP (1.2.3.4:32767). This service is actually provided by a container instance within the cluster (destination IP 10.0.0.1, destination port 8080), exposed through the cluster service node port. The external traffic policy is local, meaning external traffic must be delivered to the target container running locally on the node. The node performs DNAT to translate the destination IP from the node IP to the container instance IP.

[0124] The connection tracking records acquired by data acquisition module 201 include: The source address of the access originating from is: 5.6.7.8:54321; Access originating from: 1.2.3.4:32767; Access response source address: 10.0.0.1:8080; Access response destination address: 5.6.7.8:54321.

[0125] Since the destination address (1.2.3.4:32767) of the access initiation direction is inconsistent with the source address (10.0.0.1:8080) of the access response direction, the first determination module 202 determines that a DNAT has occurred and determines the source address (10.0.0.1) of the access response direction as the target container instance address.

[0126] Then, the first query module 203 uses the target container instance address (10.0.0.1) as the association key to search for the corresponding container instance description information (such as container instance name, namespace, and node) in the container metadata within the corresponding time window. The first generation module 104 generates the first tracing result based on the connection tracking record and the found container instance description information.

[0127] As an example, the first source tracing result could be an enriched connection trace record, which could contain the following: external source address -> transformed node -> actual destination container instance.

[0128] Optionally, the original five-tuple information (source IP, source port, destination IP, destination port, protocol type) can also be retained in the first tracing result to facilitate subsequent evidence collection.

[0129] In some embodiments, the container management apparatus proposed in this application may further include: The second query module is used to, in the connection tracking record, if both the source address and destination address of the access initiation direction belong to the internal address of the container network, or both the source address and destination address of the access response direction belong to the internal address of the container network, then based on the source address and the destination address, obtain the container instance description information of the source container and the container instance description information of the destination container from the container metadata aligned with the time of the connection tracking record. The second generation module is used to generate a second tracing result based on the container instance description information of the source container and the container instance description information of the destination container.

[0130] As an example, the second query module can query the container metadata within the current time window (or the real-time container information table) to resolve the destination address into the destination container instance description information (such as the destination container instance name and namespace), and at the same time resolve the source address into the source container instance description information (such as the source container instance name and namespace). Based on this, the second generation module generates a complete communication record containing the source container instance and the destination container instance.

[0131] In some embodiments, the container management device proposed in this application may further include: a traceability operation and display interface for realizing multi-dimensional information retrieval and topology display, helping security operations and maintenance personnel to quickly locate threats.

[0132] As an example, the tracing operation and display interface can be used to: display the first tracing result in a table view. For example, displaying the enriched connection tracking records. As another example, the tracing operation and display interface can be used to: respond to tracing operation requests and perform tracing searches. The tracing operation request may carry search criteria, which may include at least one of the following: connection tracking records and / or container metadata.

[0133] Figure 2 The container network management device 200 shown can achieve Figure 1 The method described in the embodiment achieves the same technical effect, and can be specifically referred to in the above description. Figure 1 The container network management method of the illustrated embodiment will not be described in detail here.

[0134] Figure 3 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Please refer to it. Figure 3At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and memory. The memory may include main memory, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk drive. Of course, the electronic device may also include other hardware required for other business operations.

[0135] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 3 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0136] Memory is used to store programs. Specifically, programs may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides instructions and data to the processor.

[0137] The processor reads the corresponding computer program from non-volatile memory into main memory and then runs it, forming a container network management device at the logical level. The processor executes the program stored in memory and specifically performs its functions. Figure 1 The container network management method shown achieves the same technical effect and will not be described in detail here.

[0138] The above is as stated in this application. Figure 1The container network management method disclosed in the embodiments described above can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in one or more embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in one or more embodiments of this application can be directly implemented by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0139] The electronic device can also perform Figure 1 The container network management method described herein will not be elaborated further here.

[0140] This application also proposes a computer-readable storage medium that, when the instructions in the storage medium are executed by the processor of an electronic device, enables the electronic device to perform actions such as... Figure 1 The methods of the embodiments shown are not described in detail here.

[0141] This application also proposes a computer program product, which is stored in a storage medium and executed by at least one processor to implement... Figure 1 The methods of the embodiments shown are not described in detail here.

[0142] Of course, in addition to software implementation, the electronic device of this application does not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. In other words, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0143] In summary, the above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this application should be included within the scope of protection of one or more embodiments of this application.

[0144] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0145] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0146] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0147] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

Claims

1. A container network management method, characterized in that, Applied to an analytics engine, the method includes: Obtain connection tracking information and container metadata from nodes in the container network. The connection tracking information includes at least one connection tracking record, which contains the source and destination addresses of the access initiation direction and the source and destination addresses of the access response direction. The container metadata contains the container instance address and container instance description information. Based on the matching relationship between the address of the access initiation direction and the address of the access response direction in the connection tracking record, the address of the target container instance that initiated or was accessed is determined. Based on the address of the target container instance, the corresponding container instance description information is found in the container metadata; A first tracing result is generated based on the connection tracking record and the container instance description information.

2. The method according to claim 1, characterized in that, Determining the address of the target container instance initiating or being accessed based on the matching relationship between the address in the access initiation direction and the address in the access response direction in the connection tracking record includes: The network address translation type is determined based on the matching relationship between the address in the access initiation direction and the address in the access response direction in the connection tracking record; In response to the network address translation type being Source Address Translation (SNAT), the source address of the access initiation direction is determined to be the address of the target container instance; or, In response to the network address translation type being Destination Address Translation (DNAT), the source address of the access response direction is determined to be the address of the target container instance.

3. The method according to claim 1, characterized in that, The acquisition of connection tracking information and container metadata from nodes in the container network includes: Receive the currently active connection tracking records on the node that are fully collected and reported by the node at a first time interval, and receive the connection tracking record change information collected and reported by the node within the first time interval; Receive the container instance information table of the node that is updated and reported by the node.

4. The method according to claim 1, characterized in that, Before searching for the corresponding container instance description information in the container metadata based on the address of the target container instance, the method further includes: A sliding time window is used to align the connection tracking records and the container metadata in time. The sliding time window is centered on the timestamp of the connection tracking records. Within the sliding time window, container metadata with the same container instance address is retrieved and aligned.

5. The method according to claim 4, characterized in that, The method further includes: Whenever a connection tracking record is received and fully collected at the first time interval, a corresponding connection tracking record is created in the database; A liveness timer is maintained for the connection tracking record in the database, and the liveness timer is incremented at a second time interval until a destruction event corresponding to the connection tracking record is received; wherein, the incremented value of the liveness timer is used to characterize the liveness duration of the connection tracking record, and the second time interval is less than the first time interval; Before the next full data collection time arrives, if incremental change information corresponding to the connection tracking record is received, the relevant fields of the connection tracking record in the database are updated.

6. The method according to claim 1, characterized in that, The method further includes: In the connection tracking record, if both the source address and destination address of the access initiation direction belong to the internal address of the container network, or if both the source address and destination address of the access response direction belong to the internal address of the container network, then based on the source address and the destination address, the container instance description information of the source container and the container instance description information of the destination container are obtained from the container metadata aligned with the connection tracking record time. A second tracing result is generated based on the container instance description information of the source container and the container instance description information of the destination container.

7. The method according to claim 1, characterized in that, The container instance description information includes at least one of the following: container instance name, namespace, node, business tag, creation time, and running status.

8. A container network management device, characterized in that, Applied to an analytics engine, the device includes: The data acquisition module is used to acquire connection tracking information and container metadata from nodes in the container network. The connection tracking information includes at least one connection tracking record, which contains the source and destination addresses of the access initiation direction and the source and destination addresses of the access response direction. The container metadata contains the container instance address and container instance description information. The first determining module is used to determine the address of the target container instance that initiated or was accessed based on the matching relationship between the address of the access initiation direction and the address of the access response direction in the connection tracking record. The first query module is used to search for the corresponding container instance description information in the container metadata based on the address of the target container instance; The first generation module is used to generate a first tracing result based on the connection tracking record and the container instance description information.

9. An electronic device, comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the method as described in any one of claims 1-7.

10. A computer-readable storage medium, wherein instructions in the storage medium, when executed by a processor of an electronic device, enable the electronic device to perform the method as described in any one of claims 1-7.

Images