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.
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.
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:
kubeletreceives a pod event from the stream
- Depending on the event type (added, modified, deleted), it calls the
Providermethod and creates, updates, or stops/deletes the “container”
Providerdoes work and returns an error if there is a problem