Krustlet architecture

This document describes the Krustlet architecture at a high level.

The purpose of Krustlet

Krustlet acts as a Kubernetes Kubelet by listening on the Kubernetes API’s event stream for new Pod requests that match a particular set of node selectors, scheduling those workloads to run using a WASI-based runtime instead of a container-based runtime.

Implementation

Krustlet is written in Rust.

By acting as a Kubelet, Krustlet uses Kubernetes client libraries to communicate with the Kubernetes API. Currently, the client libraries use HTTP(s) as the communication protocol between Krustlet and the Kubernetes API, using JSON as the data format for serializing and de-serializing request bodies.

Krustlet sends status updates about scheduled pods to the Kubernetes API. Therefore, it does not require its own database.

Providers

Krustlet uses providers to interact with a given runtime. The kubelet crate has the common functionality for listing to a stream of pods (an “Informer” in Kubernetes parlance), keeping a node status updated, and handling requests from the Kubernetes API. The Kubelet expects to be given a provider (something that implements the Provider interface) which knows how to create “containers” for the runtime it is implementing. Note that these might not actually be Docker containers (they definitely are not if you are using one of the providers implemented in this repository), but Kubernetes still thinks of them as a “container.” The basic workflow is like this:

  1. kubelet receives a pod event from the stream
  2. Depending on the event type (added, modified, deleted), it calls the corresponding Provider method and creates, updates, or stops/deletes the “container”
  3. The Provider does work and returns an error if there is a problem