kubert

Rust Kubernetes runtime helpers. Based on kube-rs.

/ˈkuː.bərt/

Features

• clap command-line interface support;
• A basic admin server with /ready and /live probe endpoints;
• Optional prometheus-client integration, with process and Tokio Runtime metrics;
• A default Kubernetes client;
• Graceful shutdown on SIGTERM or SIGINT signals;
• An HTTPS server (for admission controllers and API extensions) with certificate reloading;
• A utility for maintaining an index derived from watching one or more Kubernetes resources types;
• A requeue channel that supports deferring/rescheduling updates (i.e. in case a write fails);
• And a Runtime type that ties it all together!

Why not kube-rs?

The kube crate is great! And in fact, kubert builds on kube's client and runtime modules. This crate, however, captures some of the repeated patterns we've encountered building controllers for Linkerd. It doesn't try to hide kube--though it does reduce boilerplate around initializing watches and caches (reflectors); and it expects you to schedule work via the tokio runtime.

Examples

This repository includes a simple example application that demonstrates how to use a kubert::Runtime.

Other examples include:

• Linkerd2 policy controller

kubert-prometheus-process

The kubert-prometheus-process crate provides process metrics for prometheus-client. It has no dependencies on kubert, and can be used independently.

kubert-prometheus-tokio

The kubert-prometheus-tokio crate exposes Tokio runtime metrics for prometheus-client. It also has no dependencies on kubert, and can be used independently.

Note that tokio runtime metrics require RUSTFLAGS="--cfg tokio_unstable" to be set at compile-time.

Status

This crate is still fairly experimental, though it's based on production code from Linkerd; and we plan to use it in Linkerd moving forward.