The Virtual Kubelet provides a pluggable provider interface that developers can implement to define the actions of a typical kubelet.

This enables on-demand and nearly instantaneous container compute, orchestrated by Kubernetes, without needing to manage VM infrastructure.

Each provider may have its own configuration file and required environment variables.

Provider interface

Virtual Kubelet providers must provide the following functionality to be considered a fully compliant integration:

1. Provide the back-end plumbing necessary to support the lifecycle management of Pods, containers, and supporting resources in the context of Kubernetes.
2. Conform to the current API provided by Virtual Kubelet.
3. Restrict all access to the Kubernetes API Server and provide a well-defined callback mechanism for retrieving data like Secrets or ConfigMaps.

Current providers

Virtual Kubelet currently has a wide variety of providers:

Adding new providers

To add a new Virtual Kubelet provider, create a new directory for your provider.

In that created directory, implement PodLifecycleHandler interface in Go.

For an example implementation of the Virtual Kubelet PodLifecycleHandler interface, see the Virtual Kubelet CRI Provider, especially cri.go.

Each Virtual Kubelet provider can be configured using its own configuration file and environment variables.

You can see the list of required methods, with relevant descriptions of each method, below:

// PodLifecycleHandler defines the interface used by the PodController to react
// to new and changed pods scheduled to the node that is being managed.
//
// Errors produced by these methods should implement an interface from
// github.com/virtual-kubelet/virtual-kubelet/errdefs package in order for the
// core logic to be able to understand the type of failure.
type PodLifecycleHandler interface {
    // CreatePod takes a Kubernetes Pod and deploys it within the provider.
    CreatePod(ctx context.Context, pod *corev1.Pod) error

    // UpdatePod takes a Kubernetes Pod and updates it within the provider.
    UpdatePod(ctx context.Context, pod *corev1.Pod) error

    // DeletePod takes a Kubernetes Pod and deletes it from the provider.
    DeletePod(ctx context.Context, pod *corev1.Pod) error

    // GetPod retrieves a pod by name from the provider (can be cached).
    // The Pod returned is expected to be immutable, and may be accessed
    // concurrently outside of the calling goroutine. Therefore it is recommended
    // to return a version after DeepCopy.
    GetPod(ctx context.Context, namespace, name string) (*corev1.Pod, error)

    // GetPodStatus retrieves the status of a pod by name from the provider.
    // The PodStatus returned is expected to be immutable, and may be accessed
    // concurrently outside of the calling goroutine. Therefore it is recommended
    // to return a version after DeepCopy.
    GetPodStatus(ctx context.Context, namespace, name string) (*corev1.PodStatus, error)

    // GetPods retrieves a list of all pods running on the provider (can be cached).
    // The Pods returned are expected to be immutable, and may be accessed
    // concurrently outside of the calling goroutine. Therefore it is recommended
    // to return a version after DeepCopy.
    GetPods(context.Context) ([]*corev1.Pod, error)
}

In addition to PodLifecycleHandler, there’s an optional PodMetricsProvider interface that providers can implement to expose Kubernetes Pod stats:

type PodMetricsProvider interface {
    GetStatsSummary(context.Context) (*stats.Summary, error)
}

For a Virtual Kubelet provider to be considered viable, it must support the following functionality:

1. It must provide the backend plumbing necessary to support the lifecycle management of Pods, containers, and supporting resources in the Kubernetes context.
2. It must conform to the current API provided by Virtual Kubelet (see above)
3. It won’t have access to the Kubernetes API server, so it must provide a well-defined callback mechanism for fetching data like Secrets and ConfigMaps.

Documentation

No Virtual Kubelet provider is complete without solid documentation. We strongly recommend providing a README for your provider in its directory. The READMEs for the currently existing implementations can provide a blueprint.

You’ll also likely want your provider to appear in the list of current providers. That list is generated from a provider.yaml file. Add a name field for the displayed name of the provider and the subdirectory as the tag field. The name field supports Markdown, so feel free to use bold text or a hyperlink.

Testing

In order to test the provider you’re developing, simply run make test from the root of the Virtual Kubelet directory.