The Secrets of the Container Runtime Interface: Streaming Made Easy!

The Kubernetes Container Runtime Interface (CRI) is the central link between the kubelet and the Container Runtime. These runtimes must provide a gRPC-server that fulfills a Protocol Buffer interface defined by Kubernetes. This API definition evolves over time as new features are added or fields are deprecated.

In this blog post, I want to highlight the functionality and history of three exceptional Remote Procedure Calls (RPCs) that stand out in their operation: Exec, Attach, and PortForward.

Exec can be used to execute specific commands within the container and stream the output to a client like kubectl or crictl. It also allows interaction with this process via standard input (stdin), for example, when users want to run a new shell instance within an existing workload.

Attach streams the output of the currently running process over Standard I/O from the container to the client and also allows interaction with them. This is particularly useful when users want to see what’s happening inside the container and interact with the process.

PortForward can be used to forward a port from the host to the container to interact with it via third-party network tools. This way, it can bypass the Kubernetes-Services for a specific workload and interact with their network interface.

What’s so special about them?

All CRI RPCs use either gRPC unary calls for communication or the function of Server-Side Streaming (only GetContainerEvents currently). This means that primarily all RPCs must retrieve a single client request and return a single server response. This also applies to Exec, Attach, and PortForward, whose protocol definition looks as follows:

protobuf // Exec prepares a streaming endpoint to execute a command in the container. rpc Exec(ExecRequest) returns (ExecResponse) {}

protobuf // Attach prepares a streaming endpoint to attach to a running container. rpc Attach(AttachRequest) returns (AttachResponse) {}

protobuf // PortForward prepares a streaming endpoint to forward ports from a PodSandbox. rpc PortForward(PortForwardRequest) returns (PortForwardResponse) {}

The requests contain everything required for the server to perform the task, such as the ContainerId or the command (Cmd) to be executed in the case of Exec. Interestingly, all their responses only contain a url:

protobuf message ExecResponse { // Fully qualified URL of the exec streaming server. string url = 1; }

protobuf message AttachResponse { // Fully qualified URL of the attach streaming server. string url = 1; }

protobuf message PortForwardResponse { // Fully qualified URL of the port-forward streaming server. string url = 1; }

Why is it implemented this way? Well, the original design document for these RPCs dates back to a time before the Kubernetes Enhancements Proposals (KEPs) and was originally outlined in 2016. The kubelet had a native implementation for Exec, Attach, and PortForward before the initiative to introduce these functionalities was launched.

At ayedo, we are proud to be at the forefront of these developments as a Kubernetes partner, helping our clients harness the full potential of Kubernetes.

Source: Kubernetes Blog