容器运行时接口串流机制详解

Kubernetes 容器运行时接口 (CRI) 是 kubelet 与 容器运行时 之间的主要连接。这些运行时必须提供一个 gRPC 服务器，该服务器必须满足 Kubernetes 定义的 Protocol Buffer 接口。此 API 定义会随时间演进，例如当贡献者添加新特性或字段被弃用时。

在这篇博文中，我想深入探讨三种非凡的远程过程调用 (RPC) 的功能和历史，它们在工作方式方面确实非常出色：Exec、Attach 和 PortForward。

Exec 可用于在容器内运行特定命令，并将输出流式传输到客户端，例如 kubectl 或 crictl。它还允许使用标准输入 (stdin) 与该进程进行交互，例如用户希望在现有工作负载中运行新的 shell 实例时。

Attach 通过标准 I/O 将当前运行进程的输出从容器流式传输到客户端，并允许与其交互。如果用户想查看容器中正在发生什么并能够与进程进行交互，这将特别有用。

PortForward 可用于将主机端口转发到容器，以便使用第三方网络工具与其交互。这允许绕过特定工作负载的 Kubernetes Service 并与其网络接口进行交互。

它们有什么特别之处？

CRI 的所有 RPC 要么使用gRPC 一元调用进行通信，要么使用服务器端流特性（目前仅 GetContainerEvents）。这意味着所有 RPC 主要接收一个客户端请求并必须返回一个服务器响应。Exec、Attach 和 PortForward 也是如此，它们的协议定义如下所示

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

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

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

请求携带服务器执行工作所需的所有信息，例如 ContainerId 或在 Exec 情况下要运行的命令 (Cmd)。更有趣的是，它们的所有响应只包含一个 url

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

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

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

为什么这样实现？嗯，这些 RPC 的原始设计文档甚至早于Kubernetes 增强提案 (KEPs)，最初于 2016 年概述。在将功能引入 CRI 的倡议开始之前，kubelet 对 Exec、Attach 和 PortForward 有原生的实现。在此之前，一切都绑定到Docker 或后来被放弃的容器运行时 rkt。

与 CRI 相关的设计文档也详细阐述了对 exec、attach 和 port forward 使用原生 RPC 流的选项。但缺点超过了这种方法：kubelet 仍然会产生网络瓶颈，并且未来的运行时在选择服务器实现细节方面会受到限制。此外，kubelet 实现可移植、与运行时无关的解决方案的另一个选项也被放弃，因为这意味着需要维护另一个项目，而这个项目无论如何都将依赖于运行时。

这意味着，Exec、Attach 和 PortForward 的基本流程被提议如下所示

crictl 或 kubelet (通过 kubectl) 等客户端使用 gRPC 接口向运行时请求新的 exec、attach 或 port forward 会话。运行时实现一个流式服务器，该服务器也管理活动会话。此流式服务器提供一个 HTTP 端点供客户端连接。客户端将连接升级为使用 SPDY 流协议或 (将来) WebSocket 连接，并开始双向传输数据。

这种实现方式使运行时能够灵活地以自己想要的方式实现 Exec、Attach 和 PortForward，并且还提供了一个简单的测试路径。运行时可以更改底层实现来支持任何类型的特性，而无需修改 CRI。

在过去几年中，许多对这种整体方法的较小改进已合并到 Kubernetes 中，但通用模式始终保持不变。kubelet 源代码已转换为一个可复用库，如今容器运行时可以使用该库来实现基本的流功能。

流是如何实际工作的？

乍一看，好像所有这三个 RPC 的工作方式都相同，但事实并非如此。可以将 Exec 和 Attach 的功能归为一类，而 PortForward 遵循着独特的内部协议定义。

Exec 和 Attach

Kubernetes 将 Exec 和 Attach 定义为远程命令，其协议定义存在于五个不同的版本中

除此之外，作为 KEP #4006 的一部分，有一个整体努力正在将 SPDY 传输协议替换为 WebSocket。运行时必须在其整个生命周期中满足这些协议，以与 Kubernetes 实现保持同步。

假设客户端使用最新 (v5) 版协议并通过 WebSocket 进行通信。在这种情况下，一般流程将是

1. 客户端使用 CRI 请求 Exec 或 Attach 的 URL 端点。

   • 服务器 (运行时) 验证请求，将其插入连接跟踪缓存，并为该请求提供 HTTP 端点 URL。

2. 客户端连接到该 URL，升级连接以建立 WebSocket，并开始流式传输数据。

   • 在 Attach 的情况下，服务器必须将主要容器进程数据流式传输到客户端。
   • 在 Exec 的情况下，服务器必须在容器内创建子进程命令，然后将输出流式传输到客户端。

   如果需要 stdin，则服务器也需要监听 stdin 并将其重定向到相应的进程。

解释定义好的协议数据相当简单：每个输入和输出数据包的第一个字节定义了实际的流

运行时现在应该如何利用所提供的 kubelet 库来实现 Exec 和 Attach 的流式服务器方法？关键在于 kubelet 中的流式服务器实现定义了一个接口，名为 Runtime，如果实际的容器运行时希望使用该库，则必须实现此接口。

// Runtime is the interface to execute the commands and provide the streams.
type Runtime interface {
        Exec(ctx context.Context, containerID string, cmd []string, in io.Reader, out, err io.WriteCloser, tty bool, resize <-chan remotecommand.TerminalSize) error
        Attach(ctx context.Context, containerID string, in io.Reader, out, err io.WriteCloser, tty bool, resize <-chan remotecommand.TerminalSize) error
        PortForward(ctx context.Context, podSandboxID string, port int32, stream io.ReadWriteCloser) error
}

协议解释相关的所有内容都已到位，运行时只需实现实际的 Exec 和 Attach 逻辑即可。例如，容器运行时 CRI-O 按如下伪代码实现它

func (s StreamService) Exec(
    ctx context.Context,
    containerID string,
    cmd []string,
    stdin io.Reader, stdout, stderr io.WriteCloser,
    tty bool,
    resizeChan <-chan remotecommand.TerminalSize,
) error {
    // Retrieve the container by the provided containerID
    // …

    // Update the container status and verify that the workload is running
    // …

    // Execute the command and stream the data
    return s.runtimeServer.Runtime().ExecContainer(
        s.ctx, c, cmd, stdin, stdout, stderr, tty, resizeChan,
    )
}

PortForward

将端口转发到容器与从工作负载流式传输 IO 数据略有不同。服务器仍然必须提供一个 URL 端点供客户端连接，但之后容器运行时必须进入容器的网络命名空间，分配端口并双向传输数据。不像 Exec 或 Attach 那样有简单的协议定义。这意味着客户端将流式传输原始的 SPDY 帧 (无论是否附加 WebSocket 连接)，可以使用 moby/spdystream 等库进行解释。

幸运的是，kubelet 库已经提供了 PortForward 接口方法，运行时必须实现该方法。CRI-O 通过 (简化) 以下方式实现了它

func (s StreamService) PortForward(
    ctx context.Context,
    podSandboxID string,
    port int32,
    stream io.ReadWriteCloser,
) error {
    // Retrieve the pod sandbox by the provided podSandboxID
    sandboxID, err := s.runtimeServer.PodIDIndex().Get(podSandboxID)
    sb := s.runtimeServer.GetSandbox(sandboxID)
    // …

    // Get the network namespace path on disk for that sandbox
    netNsPath := sb.NetNsPath()
    // …

    // Enter the network namespace and stream the data
    return s.runtimeServer.Runtime().PortForwardContainer(
        ctx, sb.InfraContainer(), netNsPath, port, stream,
    )
}

未来工作

Kubernetes 为 RPC Exec、Attach 和 PortForward 提供的灵活性与其他方法相比确实非常出色。然而，容器运行时必须跟上最新和最优秀的实现，以便以有意义的方式支持这些特性。支持 WebSocket 的总体努力不仅是 Kubernetes 本身的事情，容器运行时以及 crictl 等客户端也必须支持它。

例如，crictl v1.30 为 exec、attach 和 port-forward 子命令提供了新的 --transport 标志 (#1383, #1385)，允许在 websocket 和 spdy 之间进行选择。

CRI-O 正在进行一项实验性工作，将流式服务器实现迁移到 conmon-rs 中（conmon 容器监控器的替代品）。conmon-rs 是原始容器监控器的 Rust 实现，允许使用支持的库直接流式传输 WebSocket (#2070)。这种方法的主要好处是 CRI-O 甚至不必运行，而 conmon-rs 可以保持活动的 Exec、Attach 和 PortForward 会话开放。直接使用 crictl 的简化流程将如下所示

所有这些改进都需要迭代的设计决策，而最初精心构思的实现则作为这些改进的基础。我真心希望您喜欢这次对 CRI RPC 历史的简短回顾。欢迎随时通过官方 Kubernetes Slack 与我联系，提出建议或反馈。

• ←上一页
• 下一页→