{"id":13451614,"url":"https://github.com/virtual-kubelet/virtual-kubelet","last_synced_at":"2025-05-11T03:43:33.639Z","repository":{"id":37938731,"uuid":"113086028","full_name":"virtual-kubelet/virtual-kubelet","owner":"virtual-kubelet","description":"Virtual Kubelet is an open source Kubernetes kubelet implementation.","archived":false,"fork":false,"pushed_at":"2025-04-16T23:06:33.000Z","size":60528,"stargazers_count":4328,"open_issues_count":78,"forks_count":622,"subscribers_count":101,"default_branch":"master","last_synced_at":"2025-05-11T03:43:27.252Z","etag":null,"topics":["cncf","kubernetes"],"latest_commit_sha":null,"homepage":"https://virtual-kubelet.io","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/virtual-kubelet.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":"docs/roadmap/virtual-kubelet-2019.md","authors":"AUTHORS","dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2017-12-04T19:32:57.000Z","updated_at":"2025-05-09T08:20:39.000Z","dependencies_parsed_at":"2024-03-30T22:21:14.648Z","dependency_job_id":"1ed53624-cbef-4ec7-ad79-a8af843fadc5","html_url":"https://github.com/virtual-kubelet/virtual-kubelet","commit_stats":{"total_commits":773,"total_committers":138,"mean_commits":5.601449275362318,"dds":0.8240620957309185,"last_synced_commit":"7676cc320ca4516bb8699e152ff6a0fd6c5802bd"},"previous_names":[],"tags_count":48,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/virtual-kubelet%2Fvirtual-kubelet","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/virtual-kubelet%2Fvirtual-kubelet/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/virtual-kubelet%2Fvirtual-kubelet/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/virtual-kubelet%2Fvirtual-kubelet/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/virtual-kubelet","download_url":"https://codeload.github.com/virtual-kubelet/virtual-kubelet/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253514552,"owners_count":21920334,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["cncf","kubernetes"],"created_at":"2024-07-31T07:00:57.054Z","updated_at":"2025-05-11T03:43:33.615Z","avatar_url":"https://github.com/virtual-kubelet.png","language":"Go","funding_links":[],"categories":["Serverless Implementations","Go","kubernetes"],"sub_categories":["[Jenkins](#jenkins)"],"readme":"# Virtual Kubelet\n\n[![Go Reference](https://pkg.go.dev/badge/github.com/virtual-kubelet/virtual-kubelet.svg)](https://pkg.go.dev/github.com/virtual-kubelet/virtual-kubelet)\n\nVirtual Kubelet is an open source [Kubernetes kubelet](https://kubernetes.io/docs/reference/generated/kubelet/)\nimplementation that masquerades as a kubelet for the purposes of connecting Kubernetes to other APIs.\nThis allows the nodes to be backed by other services like ACI, AWS Fargate, [IoT Edge](https://github.com/Azure/iot-edge-virtual-kubelet-provider), [Tensile Kube](https://github.com/virtual-kubelet/tensile-kube) etc. The primary scenario for VK is enabling the extension of the Kubernetes API into serverless container platforms like ACI and Fargate, though we are open to others. However, it should be noted that VK is explicitly not intended to be an alternative to Kubernetes federation.\n\nVirtual Kubelet features a pluggable architecture and direct use of Kubernetes primitives, making it much easier to build on.\n\nWe invite the Kubernetes ecosystem to join us in empowering developers to build\nupon our base. Join our slack channel named, virtual-kubelet, within the [Kubernetes slack group](https://kubernetes.slack.com/).\n\nThe best description is \"Kubernetes API on top, programmable back.\"\n\n#### Table of Contents\n\n* [How It Works](#how-it-works)\n* [Usage](#usage)\n* [Providers](#providers)\n    + [Admiralty Multi-Cluster Scheduler](#admiralty-multi-cluster-scheduler)\n    + [Alibaba Cloud ECI Provider](#alibaba-cloud-eci-provider)\n    + [Azure Container Instances Provider](#azure-container-instances-provider)\n\t+ [Azure Batch GPU Provider](https://github.com/virtual-kubelet/azure-batch/blob/master/README.md)\n    + [AWS Fargate Provider](#aws-fargate-provider)\n    + [Elotl Kip](#elotl-kip)\n\t+ [HashiCorp Nomad](#hashicorp-nomad-provider)\n    + [InterLink](#interlink-provider)\n    + [Liqo](#liqo-provider)\n    + [OpenStack Zun](#openstack-zun-provider)\n    + [Tensile Kube Provider](#tensile-kube-provider)\n    + [Adding a New Provider via the Provider Interface](#adding-a-new-provider-via-the-provider-interface)\n* [Testing](#testing)\n    + [Unit tests](#unit-tests)\n    + [End-to-end tests](#end-to-end-tests)\n* [Known quirks and workarounds](#known-quirks-and-workarounds)\n* [Contributing](#contributing)\n\n## How It Works\n\nThe diagram below illustrates how Virtual-Kubelet works.\n\n![diagram](website/static/img/diagram.svg)\n\n## Usage\n\nVirtual Kubelet is focused on providing a library that you can consume in your\nproject to build a custom Kubernetes node agent.\n\nSee godoc for up to date instructions on consuming this project:\nhttps://godoc.org/github.com/virtual-kubelet/virtual-kubelet\n\nThere are implementations available for [several providers](#providers), see\nthose repos for details on how to deploy.\n\n## Current Features\n\n- create, delete and update pods\n- container logs, exec, and metrics\n- get pod, pods and pod status\n- capacity\n- node addresses, node capacity, node daemon endpoints\n- operating system\n- bring your own virtual network\n\n\n## Providers\n\nThis project features a pluggable provider interface developers can implement\nthat defines the actions of a typical kubelet.\n\nThis enables on-demand and nearly instantaneous container compute, orchestrated\nby Kubernetes, without having VM infrastructure to manage and while still\nleveraging the portable Kubernetes API.\n\nEach provider may have its own configuration file, and required environmental variables.\n\nProviders must provide the following functionality to be considered a supported integration with Virtual Kubelet.\n1. Provides the back-end plumbing necessary to support the lifecycle management of pods, containers and supporting resources in the context of Kubernetes.\n2. Conforms to the current API provided by Virtual Kubelet.\n3. Does not have access to the Kubernetes API Server and has a well-defined callback mechanism for getting data like secrets or configmaps.\n\n### Admiralty Multi-Cluster Scheduler\n\nAdmiralty Multi-Cluster Scheduler mutates annotated pods into \"proxy pods\" scheduled on a virtual-kubelet node and creates corresponding \"delegate pods\" in remote clusters (actually running the containers). A feedback loop updates the statuses and annotations of the proxy pods to reflect the statuses and annotations of the delegate pods. You can find more details in the [Admiralty Multi-Cluster Scheduler documentation](https://github.com/admiraltyio/multicluster-scheduler).\n\n### Alibaba Cloud ECI Provider\n\nAlibaba Cloud ECI(Elastic Container Instance) is a service that allow you run containers without having to manage servers or clusters.\n\nYou can find more details in the [Alibaba Cloud ECI provider documentation](https://github.com/virtual-kubelet/alibabacloud-eci/blob/master/README.md).\n\n#### Configuration File\n\nThe alibaba ECI provider will read configuration file specified by the `--provider-config` flag.\n\nThe example configure file is in the [ECI provider repository](https://github.com/virtual-kubelet/alibabacloud-eci/blob/master/eci.toml).\n\n### Azure Container Instances Provider\n\nThe Azure Container Instances Provider allows you to utilize both\ntypical pods on VMs and Azure Container instances simultaneously in the\nsame Kubernetes cluster.\n\nYou can find detailed instructions on how to set it up and how to test it in the [Azure Container Instances Provider documentation](https://github.com/virtual-kubelet/azure-aci/blob/master/README.md).\n\n#### Configuration File\n\nThe Azure connector can use a configuration file specified by the `--provider-config` flag.\nThe config file is in TOML format, and an example lives in `providers/azure/example.toml`.\n\n### AWS Fargate Provider\n\n[AWS Fargate](https://aws.amazon.com/fargate/) is a technology that allows you to run containers\nwithout having to manage servers or clusters.\n\nThe AWS Fargate provider allows you to deploy pods to [AWS Fargate](https://aws.amazon.com/fargate/).\nYour pods on AWS Fargate have access to VPC networking with dedicated ENIs in your subnets, public\nIP addresses to connect to the internet, private IP addresses to connect to your Kubernetes cluster,\nsecurity groups, IAM roles, CloudWatch Logs and many other AWS services. Pods on Fargate can\nco-exist with pods on regular worker nodes in the same Kubernetes cluster.\n\nEasy instructions and a sample configuration file is available in the [AWS Fargate provider documentation](https://github.com/virtual-kubelet/aws-fargate). Please note that this provider is not currently supported. \n\n### Elotl Kip\n\n[Kip](https://github.com/elotl/kip) is a provider that runs pods in cloud instances, allowing a Kubernetes cluster to transparently scale workloads into a cloud. When a pod is scheduled onto the virtual node, Kip starts a right-sized cloud instance for the pod's workload and dispatches the pod onto the instance. When the pod is finished running, the cloud instance is terminated.\n\nWhen workloads run on Kip, your cluster size naturally scales with the cluster workload, pods are strongly isolated from each other and the user is freed from managing worker nodes and strategically packing pods onto nodes.\n\n### HashiCorp Nomad Provider\n\nHashiCorp [Nomad](https://nomadproject.io) provider for Virtual Kubelet connects your Kubernetes cluster\nwith Nomad cluster by exposing the Nomad cluster as a node in Kubernetes. By\nusing the provider, pods that are scheduled on the virtual Nomad node\nregistered on Kubernetes will run as jobs on Nomad clients as they\nwould on a Kubernetes node.\n\nFor detailed instructions, follow the guide [here](https://github.com/virtual-kubelet/nomad/blob/master/README.md).\n\n### Interlink Provider\n\n[interLink](https://intertwin-eu.github.io/interLink/) provides an abstraction for the execution of a Kubernetes pod on any remote resource that has the capability to manage a container's execution lifecycle. The use cases that drove the initial development of the tool are the Slurm-powered HPC centers, regardless the plugin based design is enabling several additional use cases to provide Kubernetes-API based access to infrastracture that cannot host a Kubelet processes. \nInterLink is a Virtual Kubelet provider that can manage container lifecycle through a well defined API specification, allowing for any resource provider to be integrated with a simple http server and a handful of methods.\nIn other words, this is an attempt to streamline the process of creating custom Virtual Kubelet providers, avoiding the need for any resource provider to implement its own version of a Kubelet workflow, which would require having some domain expertise in the Kubernetes internals.\n\nFor detailed instruction, follow the guide [here](https://intertwin-eu.github.io/interLink/docs/category/guides).\n\n### Liqo Provider\n\n[Liqo](https://liqo.io) implements a provider for Virtual Kubelet designed to transparently offload pods and services to \"peered\" Kubernetes remote cluster. Liqo is capable of discovering neighbor clusters (using DNS, mDNS) and \"peer\" with them, or in other words, establish a relationship to share part of the cluster resources. When a cluster has established a peering, a new instance of the Liqo Virtual Kubelet is spawned to seamlessly extend the capacity of the cluster, by providing an abstraction of the resources of the remote cluster. The provider combined with the Liqo network fabric extends the cluster networking by enabling Pod-to-Pod traffic and multi-cluster east-west services, supporting endpoints on both clusters.\n\nFor detailed instruction, follow the guide [here](https://github.com/liqotech/liqo/blob/master/README.md)\n\n### OpenStack Zun Provider\n\nOpenStack [Zun](https://docs.openstack.org/zun/latest/) provider for Virtual Kubelet connects\nyour Kubernetes cluster with OpenStack in order to run Kubernetes pods on OpenStack Cloud.\nYour pods on OpenStack have access to OpenStack tenant networks because they have Neutron ports\nin your subnets. Each pod will have private IP addresses to connect to other OpenStack resources\n(i.e. VMs) within your tenant, optionally have floating IP addresses to connect to the internet,\nand bind-mount Cinder volumes into a path inside a pod's container.\n\n```bash\n./bin/virtual-kubelet --provider=\"openstack\"\n```\n\nFor detailed instructions, follow the guide [here](https://github.com/virtual-kubelet/openstack-zun/blob/master/README.md).\n\n### Tensile Kube Provider\n\n[Tensile kube](https://github.com/virtual-kubelet/tensile-kube/blob/master/README.md) is contributed by [tencent\n games](https://game.qq.com), which is provider for Virtual Kubelet connects your Kubernetes cluster with other Kubernetes clusters. This provider enables us extending Kubernetes to an unlimited one. By using the provider, pods that are scheduled on the virtual node registered on Kubernetes will run as jobs on other Kubernetes clusters' nodes.\n\n### Adding a New Provider via the Provider Interface\n\nProviders consume this project as a library which implements the core logic of\na Kubernetes node agent (Kubelet), and wire up their implementation for\nperforming the neccessary actions.\n\nThere are 3 main interfaces:\n\n#### PodLifecycleHandler\n\nWhen pods are created, updated, or deleted from Kubernetes, these methods are\ncalled to handle those actions.\n\n[godoc#PodLifecycleHandler](https://godoc.org/github.com/virtual-kubelet/virtual-kubelet/node#PodLifecycleHandler)\n\n```go\ntype PodLifecycleHandler interface {\n    // CreatePod takes a Kubernetes Pod and deploys it within the provider.\n    CreatePod(ctx context.Context, pod *corev1.Pod) error\n\n    // UpdatePod takes a Kubernetes Pod and updates it within the provider.\n    UpdatePod(ctx context.Context, pod *corev1.Pod) error\n\n    // DeletePod takes a Kubernetes Pod and deletes it from the provider.\n    DeletePod(ctx context.Context, pod *corev1.Pod) error\n\n    // GetPod retrieves a pod by name from the provider (can be cached).\n    GetPod(ctx context.Context, namespace, name string) (*corev1.Pod, error)\n\n    // GetPodStatus retrieves the status of a pod by name from the provider.\n    GetPodStatus(ctx context.Context, namespace, name string) (*corev1.PodStatus, error)\n\n    // GetPods retrieves a list of all pods running on the provider (can be cached).\n    GetPods(context.Context) ([]*corev1.Pod, error)\n}\n```\n\nThere is also an optional interface `PodNotifier` which enables the provider to\nasynchronously notify the virtual-kubelet about pod status changes. If this\ninterface is not implemented, virtual-kubelet will periodically check the status\nof all pods.\n\nIt is highly recommended to implement `PodNotifier`, especially if you plan\nto run a large number of pods.\n\n[godoc#PodNotifier](https://godoc.org/github.com/virtual-kubelet/virtual-kubelet/node#PodNotifier)\n\n```go\ntype PodNotifier interface {\n    // NotifyPods instructs the notifier to call the passed in function when\n    // the pod status changes.\n    //\n    // NotifyPods should not block callers.\n    NotifyPods(context.Context, func(*corev1.Pod))\n}\n```\n\n`PodLifecycleHandler` is consumed by the `PodController` which is the core\nlogic for managing pods assigned to the node.\n\n```go\n\tpc, _ := node.NewPodController(podControllerConfig) // \u003c-- instatiates the pod controller\n\tpc.Run(ctx) // \u003c-- starts watching for pods to be scheduled on the node\n```\n\n#### NodeProvider\n\nNodeProvider is responsible for notifying the virtual-kubelet about node status\nupdates. Virtual-Kubelet will periodically check the status of the node and\nupdate Kubernetes accordingly.\n\n[godoc#NodeProvider](https://godoc.org/github.com/virtual-kubelet/virtual-kubelet/node#NodeProvider)\n\n```go\ntype NodeProvider interface {\n    // Ping checks if the node is still active.\n    // This is intended to be lightweight as it will be called periodically as a\n    // heartbeat to keep the node marked as ready in Kubernetes.\n    Ping(context.Context) error\n\n    // NotifyNodeStatus is used to asynchronously monitor the node.\n    // The passed in callback should be called any time there is a change to the\n    // node's status.\n    // This will generally trigger a call to the Kubernetes API server to update\n    // the status.\n    //\n    // NotifyNodeStatus should not block callers.\n    NotifyNodeStatus(ctx context.Context, cb func(*corev1.Node))\n}\n```\n\nVirtual Kubelet provides a `NaiveNodeProvider` that you can use if you do not\nplan to have custom node behavior.\n\n[godoc#NaiveNodeProvider](https://godoc.org/github.com/virtual-kubelet/virtual-kubelet/node#NaiveNodeProvider)\n\n`NodeProvider` gets consumed by the `NodeController`, which is core logic for\nmanaging the node object in Kubernetes.\n\n```go\n\tnc, _ := node.NewNodeController(nodeProvider, nodeSpec) // \u003c-- instantiate a node controller from a node provider and a kubernetes node spec\n\tnc.Run(ctx) // \u003c-- creates the node in kubernetes and starts up he controller\n```\n\n#### API endpoints\n\nOne of the roles of a Kubelet is to accept requests from the API server for\nthings like `kubectl logs` and  `kubectl exec`. Helpers for setting this up are\nprovided [here](https://godoc.org/github.com/virtual-kubelet/virtual-kubelet/node/api)\n\n#### Scrape Pod metrics\n\nIf you want to use HPA(Horizontal Pod Autoscaler) in your cluster, the provider should implement the `GetStatsSummary` function. Then metrics-server will be able to get the metrics of the pods on virtual-kubelet. Otherwise, you may see `No metrics for pod ` on metrics-server, which means the metrics of the pods on virtual-kubelet are not collected.\n\n\n## Testing\n\n### Unit tests\n\nRunning the unit tests locally is as simple as `make test`.\n\n### End-to-end tests\n\nCheck out [`test/e2e`](./test/e2e) for more details.\n\n## Known quirks and workarounds\n\n### Missing Load Balancer IP addresses for services\n\n#### Providers that do not support service discovery\n\nKubernetes 1.9 introduces a new flag, `ServiceNodeExclusion`, for the control plane's Controller Manager. Enabling this flag in the Controller Manager's manifest allows Kubernetes to exclude Virtual Kubelet nodes from being added to Load Balancer pools, allowing you to create public facing services with external IPs without issue.\n\n#### Workaround\n\nCluster requirements: Kubernetes 1.9 or above\n\nEnable the ServiceNodeExclusion flag, by modifying the Controller Manager manifest and adding `--feature-gates=ServiceNodeExclusion=true` to the command line arguments.\n\n## Contributing\n\nVirtual Kubelet follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).\nSign the [CNCF CLA](https://github.com/kubernetes/community/blob/master/CLA.md) to be able to make Pull Requests to this repo.\n\nMonthly Virtual Kubelet Office Hours are held at 10am PST on the second Thursday of every month in this [zoom meeting room](https://zoom.us/j/94701509915). Check out the calendar [here](https://calendar.google.com/calendar/embed?src=b119ced62134053de07d6c261b50d21ebde0da54f4163f5771b60ecf906e8b90%40group.calendar.google.com\u0026ctz=America%2FLos_Angeles).\n\nOur google drive with design specifications and meeting notes are [here](https://drive.google.com/drive/folders/19Ndu11WBCCBDowo9CrrGUHoIfd2L8Ueg?usp=sharing).\n\nWe also have a community slack channel named virtual-kubelet in the Kubernetes slack. You can also connect with the Virtual Kubelet community via the [mailing list](https://lists.cncf.io/g/virtualkubelet-dev).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fvirtual-kubelet%2Fvirtual-kubelet","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fvirtual-kubelet%2Fvirtual-kubelet","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fvirtual-kubelet%2Fvirtual-kubelet/lists"}