A container image remote debugging method, system, device and storage medium

Abstract

This application discloses a method, system, device, and storage medium for remote debugging of container images. The technical solution provided in this application involves obtaining the image identifier of the target container image in response to a debugging request sent by the debugging end via a bidirectional communication channel; obtaining the node status of each node based on the node access interface of the container orchestration platform to determine the target node; creating and starting a debugging container with the corresponding image identifier on the target node through a secure communication channel with the target node and the container runtime interface of the container orchestration platform; receiving debugging instructions from the debugging end, forwarding the debugging instructions to the debugging container for execution, and forwarding the execution result returned by the debugging container based on the debugging instructions back to the debugging end. By employing the above technical means, the debugging efficiency and success rate of container images can be improved, meeting the operational and maintenance needs for efficient and reliable diagnosis of container images in containerized application environments.

Description

Technical Field

[0001] This application relates to the field of distributed systems, and more particularly to a method, system, device, and storage medium for remote debugging of container images. Background Technology

[0002] Currently, in the development and operation of containerized applications, debugging container images is a necessary step in locating and resolving container issues. A container image represents a statically defined collection of files, and a corresponding container instance can be started from the container image. When debugging a container image, it is usually necessary to directly enter the running container using Kubernetes (a container orchestration platform) commands while the container is running normally and execute interactive commands to achieve container image debugging. Alternatively, the temporary container functionality provided by Kubernetes can be used to inject a debug container with a shared namespace into the running management unit, and the container image can be debugged through this debug container. Furthermore, container image debugging can also be achieved by automatically starting containers and executing preset test scripts in a continuous integration / continuous deployment (CI / CD) pipeline.

[0003] However, all container image debugging solutions rely on the successful creation and operation of the target container instance. When the container image itself fails to start normally, or fails to be created successfully due to insufficient cluster resources or scheduling policy limitations, all debugging methods that depend on the running container will be ineffective. This makes it difficult for developers to diagnose problems with the image while the container is offline, thus affecting the debugging efficiency of the container image and the reliability of container operation. Summary of the Invention

[0004] This application provides a method, system, device, and storage medium for remote debugging of container images. By introducing a container runtime interface, it directly creates and starts a debugging container independent of the business container. This eliminates the dependency on the successful creation and running status of the target container instance during the debugging process of the container image, solving the technical problem of interactive container debugging when the container image cannot be started or has failed to be created. Compared with existing debugging methods that depend on running containers, this application improves the debugging efficiency and success rate of container images, meeting the operational and maintenance needs for efficient and reliable diagnosis of container images in containerized application environments.

[0005] In a first aspect, embodiments of this application provide a method for remote debugging of a container image, applied to a backend server, the method comprising: In response to a debug request from the debugger sent via a bidirectional communication channel for the target container image, the debug request is parsed to obtain the image identifier of the target container image. The node access interface of the container orchestration platform obtains the node status of each node, determines the target node based on the node status and image identifier, and creates and starts a debug container with the corresponding image identifier on the target node through a secure communication channel with the target node and the container runtime interface of the container orchestration platform. The debug container runs based on the target container image. Receive debugging instructions from the debugging end, forward the debugging instructions to the debugging container for execution, and forward the execution results returned by the debugging container based on the debugging instructions back to the debugging end.

[0006] In a second aspect, embodiments of this application provide a container image remote debugging system, configured on a backend server, comprising: The request and response module is configured to respond to debug requests sent by the debugger via a bidirectional communication channel to the target container image, and to parse the debug request to obtain the image identifier of the target container image. The container creation module is configured to obtain the node status of each node based on the node access interface of the container orchestration platform, determine the target node based on the node status and image identifier, and create and start a debug container with the corresponding image identifier on the target node through a secure communication channel with the target node and the container runtime interface of the container orchestration platform. The debug container runs based on the target container image. The debugging module is configured to receive debugging commands issued by the debugging end, forward the debugging commands to the debugging container for execution, and forward the execution results returned by the debugging container based on the debugging commands back to the debugging end.

[0007] In a third aspect, embodiments of this application provide a container image remote debugging device, comprising: Memory and one or more processors; The memory is configured to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the container image remote debugging method as described in the first aspect.

[0008] In a fourth aspect, embodiments of this application provide a non-volatile computer-readable storage medium storing computer-executable instructions that, when executed by a computer processor, are configured to perform the container image remote debugging method as described in the first aspect.

[0009] In a fifth aspect, embodiments of this application provide a computer program product containing instructions that, when executed on a computer or processor, cause the computer or processor to perform the container image remote debugging method as described in the first aspect.

[0010] This application embodiment responds to a debugging request for a target container image sent by the debugging end via a bidirectional communication channel. It parses the debugging request to obtain the image identifier of the target container image; obtains the node status of each node based on the node access interface of the container orchestration platform; determines the target node based on the node status and image identifier; and creates and starts a debugging container with the corresponding image identifier on the target node through a secure communication channel with the target node and the container runtime interface of the container orchestration platform. The debugging container runs based on the target container image. It receives debugging instructions from the debugging end, forwards the instructions to the debugging container for execution, and forwards the execution result returned by the debugging container based on the instructions back to the debugging end. By adopting the above technical means, and introducing a container runtime interface to directly create and start a debugging container independent of the business container, the debugging process of the container image is freed from dependence on the successful creation and running status of the target container instance. This improves the debugging efficiency and success rate of container images, meeting the operational and maintenance needs for efficient and reliable diagnosis of container images in a containerized application environment. Attached Figure Description

[0011] Figure 1 This is a flowchart of a remote debugging method for a container image provided in an embodiment of this application; Figure 2 This is a flowchart of the debugging process for the debugging container in this application embodiment; Figure 3 This is a flowchart of the debugging session management process for an event management instance in this application. Figure 4 This is a flowchart illustrating the lifecycle execution operations of the container runtime interface in this application embodiment; Figure 5 This is a schematic diagram of the structure of a container image remote debugging system provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a container image remote debugging device provided in an embodiment of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but may also have additional steps not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0013] The container image remote debugging method provided in this application aims to directly create and start a debugging container independent of the business container by introducing a container runtime interface, so that the debugging process of the container image is freed from the dependence on the successful creation and running status of the target container instance.

[0014] With the rapid development of cloud-native technologies, containers have become the core unit for modern application delivery and operation, encompassing the operating system base layer, dependency packages, runtime configuration, and the application itself. Mainstream container orchestration platforms such as Kubernetes (K8s, an open-source container orchestration platform) handle the scheduling, operation, and lifecycle management of large-scale containers. Kubernetes (K8s) is an open-source container orchestration platform that can automate many manual operations involved in deploying, managing, and scaling containerized applications. However, as cloud-native systems become increasingly complex, image debugging has evolved from single-node operations to collaborative scenarios involving multiple clusters, multiple tenants, and high concurrency. In the development, testing, and deployment of container applications, the difficulty of image debugging has increasingly become a key issue affecting delivery efficiency and system stability. In practice, long image build chains, complex dependencies, and significant environmental differences often lead to application runtime anomalies or build failures. Once a problem occurs, developers typically need to enter the running Pod (the smallest management unit of a container) or the container environment to troubleshoot. However, this approach has significant shortcomings. The following explanation uses conventional container image debugging methods to address these issues: 1. kubectl exec (execute command within container) method This method falls under online container debugging and is the most common debugging approach. Operations or development personnel use the `kubectl exec` command to directly enter the running Pod container and execute interactive commands (such as bash, cat, ps, netstat, etc.). This allows them to view the container's environment variables, file system structure, dependency installation status, log files, and process running status in real time, helping to determine the cause of application anomalies. However, this approach has significant limitations: First, it heavily relies on the container's online runtime environment; if the image fails to start or the Pod is not successfully scheduled, debugging within the container is impossible. Second, this method is highly intrusive; commands executed during debugging may modify the container's internal state, potentially causing business interruptions. Furthermore, the debugging process is difficult to record and reproduce, hindering problem tracking and team collaboration, and also presents certain security risks, such as container privilege escalation or sensitive information leakage. Overall, this method is more suitable for short-term, temporary online troubleshooting scenarios, but it has significant shortcomings for systematic, reproducible, and offline image-level debugging needs.

[0015] 2. Temporary container method EphemeralContainers are a new debugging mechanism introduced in Kubernetes (K8s) designed to reduce the risks of directly accessing production containers. The principle is to dynamically inject a new container with debugging tools into an existing Pod. This container shares the same namespace (such as PID, Network, IPC) as the target container but does not modify the original container's file system or lifecycle. Debuggers can use the ephemeral container to perform network probing, process analysis, or file reading to locate problems. However, its limitations are also significant: First, this method still relies on the target Pod being running, making it unsuitable for analyzing images that have failed to start; second, the debugging container has a short lifecycle, operation records are easily lost, and it's difficult to form a systematic analysis process; third, some low-level system calls are restricted due to namespace isolation, making it unsuitable for debugging scenarios requiring deep kernel access; finally, frequent injection of ephemeral containers in a production environment poses security and compliance risks. In summary, this solution is suitable for locating problems in runtime, but it still cannot cover image-level or offline debugging needs.

[0016] 3. CI / CD (Continuous Integration / Continuous Deployment) Automated Method After the image is built, a container instance is automatically launched to perform debugging tasks such as environment checks, dependency verification, health checks, and command verification. This approach typically relies on a pipeline system, which uses scripts to automatically pull the image, start the container, run test cases, and generate log reports. However, this approach also has significant drawbacks. First, the configuration of the build environment often differs from that of the actual running cluster, which can easily lead to situations where the build succeeds but the runtime fails. Second, the debugging process is mostly non-interactive, making it difficult to flexibly execute custom commands. In addition, resource and security policy limitations of the build node make it difficult to cover complex scenarios. Finally, CI / CD debugging is only applicable to the image build stage, with limited support for runtime and offline scenarios, making it difficult to meet the needs of in-depth image analysis and offline reproduction.

[0017] 4. Local mirror method This lower-level approach involves downloading the image file or pulling it from an image repository, then loading and analyzing it locally using relevant commands. Developers can unzip the image file, view its layered structure, configuration metadata, startup commands, and dependencies, and manually execute or verify application behavior in an isolated environment. However, its limitations are also quite obvious: First, this debugging method is complex and requires a high level of understanding of toolchain and container principles; second, it cannot truly reproduce the Kubernetes runtime environment (such as network policies, mounted volumes, namespace isolation, etc.), so many runtime issues cannot be reproduced; third, the lack of a unified visual interface and log archiving mechanism hinders team collaboration and problem reproduction.

[0018] In summary, current container image debugging methods generally rely on the Kubernetes online runtime environment, and debugging can only be performed after the Pod has been successfully started. The debugging process is intrusive to the business, poses security and compliance risks, and the differences in the environment make it difficult to reproduce the problem. Debugging methods mostly rely on command-line interaction, which is inefficient and difficult to manage uniformly. At the same time, it lacks the ability to debug offline and across nodes or specify specific nodes, which cannot meet the needs of distributed clusters and remote development.

[0019] Based on this, an embodiment of this application provides a method for remote debugging of container images, which directly creates and starts a debugging container independent of the business container by introducing a container runtime interface. This frees the debugging process of the container image from the dependence on the successful creation and running status of the target container instance, and solves the technical problem of interactive container debugging when the container image cannot be started or fails to be created.

[0020] Example: Figure 1A flowchart of a container image remote debugging method provided in this application embodiment is given. The container image remote debugging method provided in this embodiment can be executed by a container image remote debugging device, which can be implemented by software and / or hardware. The container image remote debugging device can consist of two or more physical entities, or it can consist of a single physical entity. Generally, the container image remote debugging device can be a backend server or other processing device.

[0021] The following description uses a backend server as the primary example to illustrate the remote debugging method for container images. (Refer to...) Figure 1 This method for remote debugging of container images, applied to backend servers, specifically includes: S110. In response to the debugging request of the target container image sent by the debugging end based on the bidirectional communication channel, parse the debugging request to obtain the image identifier of the target container image.

[0022] In this application, when remotely debugging a container image, the backend server establishes a communication connection with the debugging client through a bidirectional communication channel. Based on this channel, the backend server responds to debugging requests for a specific container image issued by the debugging client, defining that container image as the target container image. The request is then parsed to extract the unique identifier of the container image, defined as the image identifier. This debugging request is typically initiated by a user (such as a developer) through a browser-based visual interface or a dedicated client; the client initiating this debugging request is defined as the debugging client. The debugging request from the debugging client encapsulates the necessary information for locating the container image, such as the image's full name in the database, tags, or content address hash value. Upon receiving this network request, the backend server first performs protocol parsing and verification to ensure the request's legitimacy and completeness. Then, it accurately extracts the key parameter, i.e., the image identifier, from the request payload. The backend server can uniquely identify the image entity to be debugged based on the image identifier, and thus create the corresponding debugging container based on that image entity.

[0023] Specifically, refer to Figure 2 This application provides a debugging flowchart for debugging containers according to embodiments of the present application. Prior to responding to a debugging request for the target container image sent by the debugging terminal, the method further includes: A bidirectional communication channel is established between the debugging end and the full-duplex communication protocol. The bidirectional communication channel is used to transmit debugging requests, debugging commands, and execution results.

[0024] When performing remote debugging, the backend server first establishes a bidirectional communication channel with the debugging end based on WebSocket (a full-duplex communication protocol). This channel serves as the data transmission carrier for all subsequent debugging interactions, used to transmit corresponding debugging requests, debugging commands, and execution results. WebSocket is a network transmission protocol that enables full-duplex communication over a single TCP connection and resides in the application layer of the OSI model.

[0025] Specifically, the debugging platform employs a web console and a real-time communication mechanism using WebSocket. Users can initiate and establish debugging sessions through a browser without needing to log in to the Kubernetes cluster or a specific node. The persistent connection characteristic of the WebSocket protocol maintains a low-latency, full-duplex data channel between the front-end and back-end, enabling real-time operations such as command input, output echoing, log pushing, and file interaction. This mechanism significantly reduces network overhead while providing a smooth interactive experience, meeting the needs of high-concurrency, low-latency online debugging.

[0026] The introduction of the WebSocket protocol aims to build an efficient, real-time, and bidirectional debugging communication channel, enabling the browser (i.e., the debugging end) to interact with remote containers in a manner close to that of a native terminal. Once the WebSocket connection is established, continuous full-duplex communication can be maintained between the front-end and back-end, ensuring that users receive an interactive experience consistent with the local command line in the web interface. In the system's communication design, the WebSocket protocol, as the core carrier for debugging data exchange, is further abstracted into a structured data frame system with context state to support visual remote debugging of distributed container images. By defining a logical frame structure on top of the native frame structure, a session structure, an encoding / decoding structure, and a user attribute structure are introduced, which together constitute the logical foundation for debugging interaction. The logical frame structure may include: data frame type (such as ordinary messages, heartbeats, control commands, etc.), a unique session identifier, message encoding / decoding settings, sending timestamps, and session context information.

[0027] The logical frame structure can be represented by the following code: struct ws_frame { char type[8]; / / Data frame type: normal message / heartbeat / control, etc. char session_id

[64] ; / / Unique session identifier codec codec; / / Message encoding / decoding settings long timestamp; / / Send time user_attr; / / Session context information} Furthermore, to achieve user-target environment binding at the debugging level, information such as user ID, node IP, and image name is carried in the frame structure. This enables fine-grained access isolation and operation authorization in multi-user, multi-cluster environments, preventing unauthorized container access. Simultaneously, the width and height information of the terminal window containing the debugging container are also transmitted, ensuring accurate rendering of the terminal output on the web debugging end. This ensures consistency between the debugging end display and the container output, further enhancing the interactive experience. The user attribute structure may include: user identifier (used for permission verification and operation tracking), the IP address of the node where the container resides, the container image name, terminal width, and terminal height.

[0028] The user attribute structure can be represented by the following code: struct user_attr { char user_id

[64] ; / / User identifier, used for permission verification and operation tracking char node_ip

[64] ; / / IP address of the node containing the container char image_name

[128] ; / / Container image name int term_width; / / Terminal width int term_height; / / Terminal height } The node IP is designed as an optional field because, in real-world scenarios, it is not always necessary to specify it; rather, it can be flexibly selected based on the debugging target and requirements. One use case is for debugging with a specified node IP. When the target container must run on a specific node, or when the user wants to perform precise debugging on a specific node, the node IP needs to be explicitly provided. Typical scenarios include performance analysis requiring fixed node resources, debugging nodes having specific service dependencies, or needing to investigate abnormal states of containers on specific nodes. In these cases, the system will route the debugging session to the specified node based on the provided node IP, ensuring that commands and data only apply to containers on that node.

[0029] Secondly, there's random node debugging. When the target container for debugging doesn't strictly depend on node location, you don't need to specify a node IP. The system randomly selects a suitable node from the available node pool to perform debugging. This method is suitable for scenarios such as regular development debugging, rapid image verification, or functional testing. The system automatically load balances and allocates nodes, reducing user configuration costs while ensuring that debugging requests are reliably distributed to available nodes in the cluster. It supports both precisely controlled, highly secure debugging and flexible random debugging, balancing security, availability, and ease of operation in multi-user, multi-cluster environments.

[0030] Based on the above logical frame structure design, data interaction between the debugging end and the backend server is carried out, enabling the backend server to efficiently process requests from different debugging ends, ensuring that each user can perform independent debugging operations in their designated container environment without interference.

[0031] Optionally, before responding to a debug request for the target container image sent by the debugger via a bidirectional communication channel, the method further includes: A global event management instance for the event-driven model is created based on the instance creation function. Based on the instance management function, the first connection file descriptor and the first listening entry of the bidirectional communication connection are registered to the global event management instance. Based on the instance management function, the second connection file descriptor and the second listening entry of the secure communication connection are registered to the global event management instance; The debugging sessions between the debugging endpoint and the corresponding debugging container are managed uniformly through a global event management instance.

[0032] On the other hand, the instance creation function is used to create a global event management instance, i.e., a global epoll instance. The instance management function is used to register the connections to be monitored for the global epoll instance. The first connection file descriptor is a unique identifier for the WebSocket bidirectional communication connection between the debugger and the backend server, allowing the epoll instance to accurately identify this connection. The first listener entry is a list of the types of WebSocket connections the epoll instance needs to listen for, such as EPOLL_IN, EPOLL_OUT, EPOLL_RDHUP, EPOLL_ET, etc. The second connection file descriptor is a unique identifier for the SSH secure communication connection between the backend server and the target node, used to enable the epoll instance to accurately identify which node the SSH connection belongs to; subsequent command forwarding and container result reception rely on it for location. The second listener entry is the list of the types of SSH connections the epoll instance needs to listen for. The second listener entry can be the same as the first listener entry.

[0033] Before responding to the debugging request of the target container image sent by the debugging end, this application also needs to build a global event management instance based on the event-driven model, so as to uniformly manage the concurrent debugging sessions of various debugging ends through the event management instance. Specifically, the backend server uses the instance creation function epoll (scalable I / O event notification mechanism) to create a global event management instance of the asynchronous event-driven model to achieve efficient session management and I / O scheduling. epoll is the scalable I / O event notification mechanism of the Linux kernel, which first appeared in Linux 2.5.44. It is designed to replace the existing POSIX select(2) and poll(2) system functions, so that programs that require a large number of file descriptors can achieve better performance. Through the instance management function, the first connection file descriptor and the first listening entry of the bidirectional communication connection are added to the corresponding positions in the global event management instance to register the bidirectional communication connection, and the second connection file descriptor and the second listening entry of the secure communication connection are added to the corresponding positions in the global event management instance to register the secure communication connection. The global event management instance after registration uniformly manages the debugging sessions of the debugging end and the backend server, as well as the debugging sessions of the backend server and the corresponding debugging container. The epoll mechanism enables a single thread to listen to and process a large number of network connection events simultaneously. It achieves non-blocking read and write operations through event readiness notification and callback mechanisms, thereby improving the backend server's concurrent processing capabilities and overall resource utilization. It significantly reduces the overhead of thread context switching and the resource consumption of the thread itself, enabling the backend server to stably support the parallel debugging requests of a large number of users while maintaining extremely low CPU utilization.

[0034] Furthermore, referring to Figure 3 The event management instance manages the debugging sessions of each debugging end, including: S1101. Invoke the event management instance based on the first connection file descriptor and / or the second connection file descriptor, and listen for the session events between the debug terminal and the corresponding debug container according to the first listening entry and / or the second listening entry; S1102. Based on the session event handling, the debugging terminal and the debugging container exchange session information, which includes debugging requests, debugging instructions and execution results.

[0035] Specifically, the backend server first creates a global epoll instance (i.e., an event management instance), which serves as the core management unit of the event-driven architecture. This instance handles all WebSocket connection events and subsequent container debugging events, including debug requests, debug commands, and execution results within the debugging session. By registering the first and / or second connection file descriptors (i.e., socket file descriptors) to this epoll instance, it can wait for and respond to various events in a non-blocking manner, including new connection establishment, data readability, data writeability, and scheduled task triggering, thus achieving rapid response in high-concurrency environments. When the debugging client initiates and establishes a WebSocket connection, the epoll instance detects this new connection event, and the backend server immediately calls the corresponding callback function. In this callback, a corresponding structured data frame object is created and initialized. This object contains initialized user attributes, such as user ID, the name of the image to be debugged, terminal size, and an optional node IP address. Simultaneously, the backend server initializes the message encoder and decoder for subsequent message serialization and deserialization, and configures connection heartbeat parameters to ensure persistent session activity.

[0036] Each newly established WebSocket connection corresponds to a first listening connection file descriptor. This descriptor is at zero offset in the event-driven model and is opened in read-write mode. Its associated first listening entry event mask is a combined value indicating that this descriptor is simultaneously listening for readable events, writable events, connection pending events, or peer close events, and operates in edge-triggered mode. Furthermore, a context pointer to the aforementioned structured data frame object is associated with this descriptor to quickly locate the corresponding session information when an event is triggered.

[0037] The kernel view code for a WebSocket connection in an event-driven model is as follows: pos:0 / / Position offset flags:02 / / Enable flags, such as O_RDWR read / write mode tfd:3 events: 80002005 data: ffff9f55e5fca000 Here, tfd(target fd) corresponds to the first listening entry saved in the kernel for a newly established WebSocket connection on the Web client; events is the event mask (hexadecimal) saved by the kernel, represented as a bitwise OR of a set of EPOLL_* flags. The bit expansion of 0x80002005 is: 0x01 = EPOLL_IN (readable), 0x04 = EPOLL_OUT (writable), 0x10 = EPOLLHUP (suspend / peer close), and 0x80000000 = EPOLL_ET (edge ​​triggered); data is additional context information, which here points to the ws_frame object.

[0038] Regarding node scheduling, for scenarios where the user explicitly specifies a node IP, the backend server will directly route the debugging session to the specified target node to meet the need for precise debugging of a specific node. If the user does not specify a node, the system will dynamically select an optimal node as the target node from the available node resource pool based on an intelligent selection strategy. This selection strategy comprehensively considers multiple indicators such as the node's health status, CPU and memory load, and the number of current tasks, thereby achieving rapid response and cluster load balancing. After selecting the target node, the backend server will update the node IP information in the user attribute structure to ensure that all subsequent operations are bound to this session.

[0039] Once the target node is determined, the backend server establishes a secure SSH (Secure Shell, a network security protocol) connection with that node. This connection is used to remotely execute container debugging commands. SSH uses encryption and authentication mechanisms to achieve secure access and file transfer. The backend server does not simply issue a single command but treats the entire SSH connection as a long-term maintained I / O session. The second connection file descriptor of this SSH connection is also registered with the aforementioned global epoll instance and included in unified event management. At this point, from the kernel view, the backend server manages two key connection descriptors simultaneously: one is a WebSocket connection for the web frontend, and the other is an SSH connection for the target node. Both descriptors are configured to listen for readable, writable, and connection close events and run in edge-triggered mode, each associated with an independent session context data structure. Listening for writable events on the first and / or second listener entries ensures efficient delivery of debugging commands and user input; listening for readable events allows for timely capture of container output streams, execution results, and error messages; and listening for connection close events facilitates immediate triggering of resource reclamation processes when a connection is abnormally disconnected. The application of edge-triggered mode effectively reduces unnecessary repetitive event notifications in high-concurrency scenarios, thereby significantly improving the overall I / O processing performance of the system.

[0040] The kernel view code for SSH connections in an event-driven model is as follows: pos:0 / / Position offset flags:02 / / Enable flags, such as O_RDWR read / write mode tfd:3 events: 80002005 data: ffff9f55e5fca000 tfd:4 events: 80002005 data: ffff9f55e5fcb000 The EPOLL_OUT event listened to here is used to detect whether the connection is writable, thereby efficiently issuing debugging commands and user input. EPOLL_IN is used to listen to the output stream returned by the container, such as the container startup status, execution results and error messages. EPOLL_RDHUP is responsible for detecting whether the remote SSH connection is closed or abnormally disconnected, so as to trigger resource reclamation in a timely manner. EPOLL_ET enables edge triggering mode, which enables the system to reduce duplicate event notifications under high concurrency, thereby improving overall performance.

[0041] In this way, each debugging session has its own independent context information, ensuring complete isolation and non-interference between debugging sessions from different users or containers. The backend server, within a unified event loop, can efficiently handle WebSocket connections from the frontend and SSH connections with multiple backend nodes simultaneously, achieving unified asynchronous management and scheduling of multi-layered communication links. The entire process is built entirely on the epoll event-driven mechanism, thus forming a high-performance, scalable concurrent debugging session management architecture.

[0042] like Figure 1 As shown, in step S120, the node access interface of the container orchestration platform obtains the node status of each node, determines the target node based on the node status and image identifier, and creates and starts a debug container with the corresponding image identifier on the target node through a secure communication channel with the target node and the container runtime interface of the container orchestration platform. The debug container runs based on the target container image.

[0043] Furthermore, for scenarios where the user explicitly specifies the node IP, the backend server, based on the aforementioned debug session management architecture, obtains the precise image identifier after parsing the debug request from the debugger. Then, it directly creates and starts a debug container instance based on the aforementioned target container image on the specified target node or one dynamically selected by the system via the standardized Container Runtime Interface (CRI). CRI is a plugin interface that enables kubelet to use various container runtimes without recompiling cluster components. If no node IP is specified, the backend server intelligently selects a node from the available node pool. The selection strategy comprehensively considers node status, such as node health, CPU and memory load, and the number of current tasks, thereby achieving rapid response and load balancing. Finally, the selection result is written back to user_attr.node_ip to ensure the binding of commands and sessions. This intelligent selection mechanism ensures that even in a multi-node cluster environment, debugging tasks can be efficiently and securely allocated, even if the user does not care about the specific node.

[0044] Specifically, the backend server sends container creation and startup instructions to the container runtime (such as Containerd or a runtime compliant with the CRI-O specification) by calling the CRI interface. Containerd is a high-performance, reliable open-source container runtime designed as a core container management solution from development to production environments. The instruction carries the image source identified by the image identifier and pre-set container configuration parameters for debugging scenarios, such as allocating independent namespaces, setting resource limits, and mounting temporary storage volumes, to ensure that the debugging environment is completely isolated from and securely controllable from production business containers. This process does not rely on Kubernetes' scheduling and state management of Pods, nor does it require the image to successfully form a healthy business Pod. Even if the target image fails to start within the normal Pod lifecycle due to missing dependencies, configuration errors, or compatibility issues, the CRI interface can still create a container runtime process based on its file system layer, thus injecting an independent, interactive runtime environment into the static collection of image files. This removes the dependency of debugging activities on the running state of business containers, allowing debugging and diagnostics of images to be performed in early stages, such as before their startup.

[0045] By launching a temporary debug container based on the target image, users do not need to directly access Kubernetes or the nodes themselves. This fundamentally avoids the exposure of node access credentials, eliminates the intrusion risk of directly manipulating the cluster, and establishes a secure and isolated execution environment. Furthermore, the debug container created by the backend server originates directly from the target image and is completely isolated from the environment where the online business Pods reside. This provides a consistent, reproducible, and parallel-operation-supporting image debug environment without interfering with business operations.

[0046] Furthermore, the entire lifecycle of the debug container, including creation, startup, running, pausing, and eventual destruction, is managed uniformly through the Container Runtime Interface (CRI). The backend server, through the standardized CRI interface, decouples itself from the underlying container runtime. Instead of directly depending on a specific container, the backend server uses runtime services (such as Containerd or Docker) to control the runtime services on the target node to complete all actual operations. Docker is an open-source platform software used for developing, shipping, and running applications. Specifically, when a user initiates a debug request via the web, the backend parses the parameters and then initiates a container creation command via CRI, putting the container into the creation state. Subsequently, the container is started via CRI, putting its process into the running state. At this point, the WebSocket connection is responsible for transmitting the frontend's input commands to the container's stdin in real time and returning the container's stdout / stderr output to the frontend, achieving bidirectional interaction.

[0047] Optionally, the target node is determined based on the node status and mirror identifier, including: Parse the specified node identifier from the mirror identifier, and determine the node corresponding to the node identifier as the target node; or... Based on the node status, select a node from the service cluster as the target node.

[0048] In the frame structure of data sent from the debugging end, the node IP is designed as an optional field. Since the node IP is not always required in actual debugging scenarios, this optional IP field allows for flexible selection of the appropriate node for debugging based on the debugging target and requirements. Specifically, there are two debugging modes: one is specified node debugging, where the node IP must be explicitly provided when the target container must run on a specific node, or when the user wants to perform precise debugging on a specific node. Typical scenarios include performance analysis requiring fixed node resources, debugging services dependent on a specific node, or troubleshooting abnormal container states on a specific node. In this mode, the backend server parses the target container's image identifier based on the debugging request provided by the debugging end, and then parses the specified node identifier (node ​​IP) from the image identifier, routing the debugging session to the specified node (i.e., the target node), ensuring that commands and data only affect containers on that node. The other mode is random node debugging, where the target container does not have a strict dependency on node location, and the node IP is not specified. The backend server selects a suitable node from the available node pool based on the node status to perform debugging. This mode is suitable for scenarios such as routine development and debugging, rapid image verification, or functional testing. The backend server will automatically perform load balancing and node allocation, reducing user configuration complexity while ensuring that debugging requests are reliably distributed to available nodes in the cluster. Through the above design, the backend server can support both precisely controlled debugging modes and flexible random debugging, thus balancing security, availability, and ease of operation in multi-user, multi-cluster environments.

[0049] like Figure 1 As shown, S130 receives the debugging command issued by the debugging terminal, forwards the debugging command to the debugging container for execution, and forwards the execution result returned by the debugging container based on the debugging command to the debugging terminal.

[0050] After the debug container is created and started, the interactive debugging execution phase can begin. The backend server maintains a debugging session with the debugger via the aforementioned WebSocket connection. When the user enters command-line commands in the debugger interface, the commands are encapsulated as data frames and sent to the backend server through this connection. The backend server, acting as a secure proxy, forwards the received commands to the target node via an established secure channel (i.e., an SSH connection). The target node then inputs debug commands for the debug container via the CRI interface and outputs the results, thus enabling remote debugging of the container image.

[0051] Optionally, debugging instructions can be forwarded to the debugging container for execution, including: Debug commands are written to the standard input stream of the debug container through the container runtime interface; Forward the execution results returned by the debug container based on the debug commands to the debugger, including: The standard output stream of the debug container is read through the container runtime interface to obtain the execution result, and the execution result is forwarded to the debug end.

[0052] The received debugging commands are written to the standard input stream of the debugging container through this container runtime interface, thereby driving the corresponding process within the container to execute the commands. Correspondingly, the standard output stream of the debugging container is continuously read through this container runtime interface to capture the execution results, and then the results are forwarded to the debugging end for display, thus realizing a two-way remote command execution and feedback process.

[0053] Specifically, after the debugging client issues a debugging command, it uses a global epoll instance to listen to the WebSocket connection channel between the debugging client and the backend server, thereby obtaining the debugging command based on the listened-to writable events. Upon receiving the debugging command from the debugging client, the backend server's epoll instance writes the command data to the standard input stream associated with the process inside the debugging container by calling methods provided by the container runtime interface. This drives the container's pre-defined command-line interface to read and execute the corresponding command. During or after command execution, text or data output generated by the process inside the container is written to its standard output stream. The backend epoll instance continuously listens to and reads the contents of this standard output stream using another set of methods provided by the container runtime interface, thus capturing the complete execution result. This result data is then encapsulated and forwarded back to the debugging client in real time through the established bidirectional communication channel, and finally presented on the user interface, thus completing a remote interactive debugging session.

[0054] Optional, refer to Figure 4 After forwarding the debugging instructions to the debug container for execution, it also includes: S1301, Receive container control commands from the debugging end; S1302. In response to container control instructions, perform corresponding lifecycle operations on the debug container through the container runtime interface. The lifecycle operations include at least one of pausing the container, resuming the running container, or deleting the container.

[0055] The debugging client can also actively manage container states by sending specific control messages via WebSocket. For example, sending control messages of type "pause" or "resume" can drive the container state to switch between running and paused. By default, when the debugging session ends or the container's main process exits, the backend server automatically deletes the container and its associated resources via CRI, eventually changing the container state to "deleted." This automatic deletion strategy ensures clean cluster node resources, effectively preventing the waste of disk, memory, and network resources caused by the accumulation of temporary debugging containers, while simplifying system operation and maintenance and automated management.

[0056] On the other hand, manually pausing a container by sending a pause control message preserves the complete debug environment. Once paused, the container's runtime context is frozen, allowing users to reconnect at a later time to continue viewing the container's status, analyzing logs, or inspecting output without recreating the environment. This reentrant debugging mechanism is particularly convenient for diagnosing complex faults, reproducing specific runtime states, or verifying multi-step operational processes. The entire container state management is performed through a CRI standardized interface, ensuring broad compatibility with different container runtimes. This allows for flexible and efficient control and management of the debug container's state by performing corresponding lifecycle management operations (i.e., pausing, resuming, or deleting the container) through the container runtime interface.

[0057] Optionally, container control instructions include container freeze instructions; In response to container control commands, perform corresponding lifecycle operations on the debug container through the container runtime interface, including: In response to the container freeze command, the freeze status is written to the freeze subsystem control file of the debug container through the container runtime interface to pause the debug container and freeze the runtime environment of the debug container.

[0058] Freezing the runtime environment of a debug container relies on the debug container's freeze subsystem (Linux Cgroup Freezer subsystem). Upon receiving a container freeze command (type=PAUSE) sent by the debugger via WebSocket, the debugger writes a freeze (FROZEN) state to the Cgroup Freezer control file belonging to the debug container through the container runtime interface. This immediately suspends all processes under that Cgroup, preventing them from being scheduled for execution, but the process's memory, file descriptors, network connections, and other context information are fully preserved. Cgroups are a mechanism provided by the Linux kernel that can limit the resources used by a single process or multiple processes, allowing for fine-grained control over resources such as CPU and memory. This freeze action instantly locks the runtime environment of the debug container, suitable for scenarios such as preserving the debug state, performance analysis, or fault reproduction. In this way, the container can be paused to save its runtime context at a certain point in time, and subsequently, it can be woken up in response to a container wake-up command (type=RESUME) to restore the container to its execution state before freezing.

[0059] By default, container resources are automatically reclaimed after debugging to keep the cluster clean. For tasks that need to retain the debugging state, the container lifecycle can be extended through the PAUSE state to achieve controllable retention and subsequent recovery of the debugging state. This mechanism ensures efficient resource reclamation while taking into account both efficient resource utilization and continuous problem investigation.

[0060] As described above, in response to a debugging request from the debugging end via a bidirectional communication channel for the target container image, the system parses the debugging request to obtain the image identifier of the target container image. It then obtains the node status of each node based on the node access interface of the container orchestration platform. Based on the node status and image identifier, the system determines the target node. Through a secure communication channel with the target node and the container runtime interface of the container orchestration platform, it creates and starts a debugging container with the corresponding image identifier on the target node. This debugging container runs based on the target container image. Furthermore, it receives debugging commands from the debugging end, forwards these commands to the debugging container for execution, and forwards the execution results returned by the debugging container based on the debugging commands back to the debugging end. By employing these techniques and introducing a container runtime interface to directly create and start a debugging container independent of the business container, the debugging process for container images is freed from dependence on the successful creation and running status of the target container instance. This improves the efficiency and success rate of container image debugging, meeting the operational needs for efficient and reliable diagnostics of container images in containerized application environments.

[0061] Based on the above embodiments, Figure 5 This is a schematic diagram of the structure of a container image remote debugging system provided in this application. (Reference) Figure 5 The container image remote debugging system provided in this embodiment specifically includes: The request-response module 21 is configured to respond to the debugging request of the target container image sent by the debugging end based on the bidirectional communication channel, and parse the debugging request to obtain the image identifier of the target container image. The container creation module 22 is configured to obtain the node status of each node based on the node access interface of the container orchestration platform, determine the target node based on the node status and image identifier, and create and start the debug container with the corresponding image identifier on the target node through a secure communication channel with the target node and the container runtime interface of the container orchestration platform. The debug container runs based on the target container image. The debugging module 23 is configured to receive debugging instructions issued by the debugging terminal, forward the debugging instructions to the debugging container for execution, and forward the execution results returned by the debugging container based on the debugging instructions to the debugging terminal.

[0062] Specifically, before responding to a debug request for the target container image sent by the debugger, the following is also included: A bidirectional communication channel is established between the debugging end and the full-duplex communication protocol. The bidirectional communication channel is used to transmit debugging requests, debugging commands, and execution results.

[0063] Specifically, before responding to a debug request from the debugger for the target container image sent via a bidirectional communication channel, the following is also included: A global event management instance for the event-driven model is created based on the instance creation function. Based on the instance management function, the first connection file descriptor and the first listening entry of the bidirectional communication connection are registered to the global event management instance. Based on the instance management function, the second connection file descriptor and the second listening entry of the secure communication connection are registered to the global event management instance; The debugging sessions between the debugging client and the corresponding debugging container are managed uniformly through a global event management instance.

[0064] Among these features, a global event management instance is used to uniformly manage the debugging sessions between the debugging client and the corresponding debugging container, including: Invoke the event management instance based on the first connection file descriptor and / or the second connection file descriptor, and listen for session events between the debugger and the corresponding debug container according to the first listening entry and / or the second listening entry; The debugging endpoint and the debugging container interact based on the session event handling, and the session information includes debugging requests, debugging commands, and execution results.

[0065] Specifically, the target node is determined based on the node status and mirror identifier, including: Parse the specified node identifier from the mirror identifier, and determine the node corresponding to the node identifier as the target node; or... Based on the node status, select a node from the service cluster as the target node.

[0066] Specifically, forwarding debugging commands to the debugging container for execution includes: Debug commands are written to the standard input stream of the debug container through the container runtime interface; Forward the execution results returned by the debug container based on the debug commands to the debugger, including: The standard output stream of the debug container is read through the container runtime interface to obtain the execution result, and the execution result is forwarded to the debug end.

[0067] Specifically, after forwarding the debugging instructions to the debugging container for execution, it also includes: Receive container control commands from the debugging end; In response to container control commands, perform corresponding lifecycle operations on the debug container through the container runtime interface. Lifecycle operations include at least one of pausing the container, resuming the running container, or deleting the container.

[0068] Specifically, container control instructions include container freeze instructions; In response to container control commands, perform corresponding lifecycle operations on the debug container through the container runtime interface, including: In response to the container freeze command, the freeze status is written to the freeze subsystem control file of the debug container through the container runtime interface to pause the debug container and freeze the runtime environment of the debug container.

[0069] As described above, in response to a debugging request from the debugging end via a bidirectional communication channel for the target container image, the system parses the debugging request to obtain the image identifier of the target container image. It then obtains the node status of each node based on the node access interface of the container orchestration platform. Based on the node status and image identifier, the system determines the target node. Through a secure communication channel with the target node and the container runtime interface of the container orchestration platform, it creates and starts a debugging container with the corresponding image identifier on the target node. This debugging container runs based on the target container image. Furthermore, it receives debugging commands from the debugging end, forwards these commands to the debugging container for execution, and forwards the execution results returned by the debugging container based on the debugging commands back to the debugging end. By employing these techniques and introducing a container runtime interface to directly create and start a debugging container independent of the business container, the debugging process for container images is freed from dependence on the successful creation and running status of the target container instance. This improves the efficiency and success rate of container image debugging, meeting the operational needs for efficient and reliable diagnostics of container images in containerized application environments.

[0070] The container image remote debugging system provided in this application embodiment can be configured to execute the container image remote debugging method provided in the above embodiment, and has corresponding functions and beneficial effects.

[0071] Based on the above practical examples, this application also provides a container image remote debugging device, see below. Figure 6 The container image remote debugging device includes a processor 31, a memory 32, a communication module 33, an input device 34, and an output device 35. The memory, as a computer-readable storage medium, can be configured to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the container image remote debugging method described in any embodiment of this application (e.g., the request-response module, container creation module, and debugging module in the container image remote debugging system). The communication module is configured to perform data transmission. The processor executes various functional applications and data processing of the device by running the software programs, instructions, and modules stored in the memory, thereby implementing the aforementioned container image remote debugging method. The input device can be configured to receive input digital or character information and generate key signal inputs related to user settings and function control of the device. The output device may include a display screen or other display device. The container image remote debugging device provided above can be configured to execute the container image remote debugging method provided in the above embodiments, possessing corresponding functions and beneficial effects.

[0072] Based on the above embodiments, this application also provides a non-volatile computer-readable storage medium storing computer-executable instructions. These computer-executable instructions, when executed by a computer processor, are configured to perform a remote debugging method for a container image. The storage medium can be any type of memory device or storage device. Of course, the computer-executable instructions of the non-volatile computer-readable storage medium provided in this application are not limited to the remote debugging method for a container image as described above; they can also perform related operations in the remote debugging method for a container image provided in any embodiment of this application.

[0073] Based on the above embodiments, this application also provides a computer program product. The technical solution of this application, in essence or in other words, the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. The computer program product is stored in a storage medium and includes several instructions to cause a computer device, mobile terminal, or processor therein to execute all or part of the steps of the container image remote debugging method described in the various embodiments of this application.

Claims

1. A method for remote debugging of a container image, characterized in that, Applied to a backend server, the method includes: In response to a debug request for the target container image sent by the debugger via a bidirectional communication channel, the debug request is parsed to obtain the image identifier of the target container image; The node status of each node is obtained through the node access interface of the container orchestration platform. The target node is determined based on the node status and the image identifier. Through a secure communication channel with the target node and the container runtime interface of the container orchestration platform, a debug container corresponding to the image identifier is created and started on the target node. The debug container runs based on the target container image. The system receives debugging instructions from the debugging terminal, forwards the debugging instructions to the debugging container for execution, and forwards the execution result returned by the debugging container based on the debugging instructions back to the debugging terminal.

2. The container image remote debugging method according to claim 1, characterized in that, The step of forwarding the debugging instructions to the debugging container for execution includes: The debugging instructions are written to the standard input stream of the debugging container through the container runtime interface. The step of forwarding the execution result returned by the debugging container based on the debugging instruction to the debugging terminal includes: The standard output stream of the debug container is read through the container runtime interface to obtain the execution result, and the execution result is forwarded to the debug terminal.

3. The container image remote debugging method according to claim 1, characterized in that, After forwarding the debugging instructions to the debugging container for execution, the method further includes: Receive container control commands from the debugging terminal; In response to the container control command, the debug container is subjected to a corresponding lifecycle operation through the container runtime interface, the lifecycle operation including at least one of pausing the container, resuming the running container, or deleting the container.

4. The container image remote debugging method according to claim 3, characterized in that, The container control commands include container freeze commands; The step of responding to the container control command and performing corresponding lifecycle operations on the debug container through the container runtime interface includes: In response to the container freeze command, a freeze status is written to the freeze subsystem control file of the debug container through the container runtime interface to suspend the debug container and freeze the runtime environment of the debug container.

5. The container image remote debugging method according to claim 1, characterized in that, Prior to responding to the debug request for the target container image sent by the debugger via a bidirectional communication channel, the method further includes: A global event management instance for the event-driven model is created based on the instance creation function. Based on the instance management function, the first connection file descriptor and the first listening entry for the bidirectional communication connection are registered to the global event management instance. Based on the instance management function, the second connection file descriptor and the second listening entry of the secure communication connection are registered to the global event management instance; The global event management instance centrally manages the debugging sessions between the debugging client and the corresponding debugging container.

6. The remote debugging method for container images according to claim 5, characterized in that, The method of uniformly managing the debugging session between the debugging terminal and the corresponding debugging container through the global event management instance includes: The event management instance is invoked based on the first connection file descriptor and / or the second connection file descriptor to listen for session events between the debugger and the corresponding debug container according to the first listening entry and / or the second listening entry. The session information of the debugging session between the debugging terminal and the debugging container is processed according to the session event. The session information includes the debugging request, the debugging instruction, and the execution result.

7. The container image remote debugging method according to claim 1, characterized in that, Prior to the debug request for the target container image sent by the debugger, the following is also included: A bidirectional communication channel is established with the debugging terminal based on a full-duplex communication protocol. The bidirectional communication channel is used to transmit the debugging request, the debugging command, and the execution result.

8. The remote debugging method for container images according to claim 1, characterized in that, Determining the target node based on the node status and the mirror identifier includes: Parse the specified node identifier from the mirror identifier, and determine the node corresponding to the node identifier as the target node; or... Based on the node status, a node is selected from the service cluster as the target node.

9. A container image remote debugging system, characterized in that, Configured on the backend server, including: The request-response module is configured to respond to a debug request for a target container image sent by the debugger via a bidirectional communication channel, and to parse the debug request to obtain the image identifier of the target container image. The container creation module is configured to obtain the node status of each node based on the node access interface of the container orchestration platform, determine the target node based on the node status and the image identifier, and create and start a debug container corresponding to the image identifier on the target node through a secure communication channel with the target node and the container runtime interface of the container orchestration platform. The debug container runs based on the target container image. The debugging module is configured to receive debugging instructions issued by the debugging terminal, forward the debugging instructions to the debugging container for execution, and forward the execution result returned by the debugging container based on the debugging instructions to the debugging terminal.

10. A container image remote debugging device, characterized in that, include: Memory and one or more processors; The memory is configured to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the container image remote debugging method as described in any one of claims 1-8.

11. A non-volatile computer-readable storage medium, characterized in that, The non-volatile computer-readable storage medium stores computer-executable instructions that, when executed by a computer processor, are configured to perform the container image remote debugging method as described in any one of claims 1-8.

12. A computer program product, characterized in that, The computer program product includes instructions that, when executed on a computer or processor, cause the computer or processor to perform the container image remote debugging method as described in any one of claims 1-8.

Images