In the realm of containerization, the Container Runtime Interface (CRI) serves as a vital bridge between the Kubernetes kubelet and the container runtime. The CRI defines a set of gRPC methods that container runtimes must implement to seamlessly integrate with Kubernetes. Among these methods, three stand out for their unique functionality and implementation: Exec, Attach, and PortForward. In this blog post, we will delve into the intricacies of these streaming methods, exploring their purpose, history, and the challenges they pose for container runtime implementations.

Unveiling the Capabilities of Exec, Attach, and PortForward

Understanding Exec, Attach, and PortForward Exec, Attach, and PortForward are essential methods in the CRI that enable interactive communication with containers. Exec allows running commands within a container and streaming the output to the client, such as kubectl or crictl. It also supports interactive input through standard input (stdin). Attach, on the other hand, streams the output of the currently running process in the container and enables interaction with it. PortForward facilitates forwarding a port from the host to the container, enabling interaction using third-party network tools. These methods provide flexibility and control over container processes and networking.

CRI Streaming: A Historical Look

The Evolution of CRI Streaming The design and implementation of Exec, Attach, and PortForward have undergone significant changes since their inception. Initially, the kubelet had native implementations for these methods before the CRI initiative began. The original design document for these RPCs predates even the Kubernetes Enhancement Proposals (KEPs) and was outlined in 2016. The document explored various options, including using native RPC streaming and implementing a portable, runtime-agnostic solution in the kubelet. However, the final approach chosen was to have the container runtime implement a streaming server that manages active sessions and provides an HTTP endpoint for clients to connect to.

Exec vs. Attach vs. PortForward

The Streaming Protocol While Exec, Attach, and PortForward may appear similar at first glance, they follow distinct internal protocol definitions. Exec and Attach share similarities and are considered remote commands. Kubernetes defines five versions of the protocol for these methods, each introducing new features and improvements. The latest version, v5, adds support for a CLOSE signal. On the other hand, PortForward follows a different approach, utilizing plain SPDY frames or WebSocket connections to stream data between the client and the container.

Streamlining CRI Streaming with the Kubelet Library

Implementing CRI Streaming in Container Runtimes Implementing Exec, Attach, and PortForward in container runtimes requires careful consideration and adherence to the defined protocols. The kubelet provides a reusable library that outlines an interface called Runtime, which container runtimes must implement to leverage the streaming functionality. The library handles protocol interpretation, allowing runtimes to focus on the actual execution logic. For example, the CRI-O container runtime implements the Exec and Attach methods by retrieving the container, updating its status, and executing the command while streaming the data. Similarly, for PortForward, CRI-O enters the network namespace of the container, allocates the port, and streams the data using the provided library.

The Future of CRI Streaming: WebSockets and Beyond

Future Directions and Challenges As Kubernetes continues to evolve, container runtimes must keep pace with the latest implementations of Exec, Attach, and PortForward. One notable effort is the transition from the SPDY transport protocol to WebSockets, as outlined in KEP #4006. This transition requires support from both container runtimes and clients like crictl. Additionally, innovative approaches are being explored, such as CRI-O's experimental move to implement the streaming server in conmon-rs, a Rust-based container monitor. This approach allows active sessions to remain open even when CRI-O is not running, providing enhanced flexibility and resilience.