Project: Virtual Kubelet (Runtime / Container Runtime)
File: providers.md

title: Providers description: Extend the Virtual Kubelet interface weight: 4 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. Virtual Kubelet providers must provide the following functionality to be considered a fully compliant integration: Provide the back-end plumbing necessary to support the lifecycle management of Pods, containers, and supporting resources in the context of Kubernetes. Conform to the current API provided by Virtual Kubelet. Restrict all access to the and provide a well-defined callback mechanism for retrieving data like or . Virtual Kubelet currently has a wide variety of providers: {{< providers >}} To add a new Virtual Kubelet provider, create a new directory for your provider. In that created directory, implement interface in . For an example implementation of the Virtual Kubelet `PodLifecycleHandler` interface, see the , especially . 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: ```go // 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

// 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 interface that providers can implement to expose Kubernetes Pod stats: ```go type PodMetricsProvider interface { GetStatsSummary(context.Context) (*stats.Summary, error) } ``` For a Virtual Kubelet provider to be considered viable, it must support the following functionality: It must provide the backend plumbing necessary to support the lifecycle management of Pods, containers, and supporting resources in the Kubernetes context. It must conform to the current API provided by Virtual Kubelet (see ) It won't have access to the , so it must provide a well-defined callback mechanism for fetching data like and . 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 . That list is generated from a 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. In order to test the provider you're developing, simply run `make test` from the root of the Virtual Kubelet directory.