083f6dee05
* Refactor provider init This moves provider init out of vkubelet setup, instead preferring to initialize vkubelet with a provider. * Split API server configuration from setup. This makes sure that configuration (which is done primarily through env vars) is separate from actually standing up the servers. This also makes sure to abort daemon initialization if the API servers are not able to start.
Follow these steps to be accepted as a provider within the Virtual Kubelet repo.
- Replicate the life-cycle of a pod for example creation and deletion of a pod and how that maps to your service.
- Create a new provider folder with a descriptive name and the necessary code.
- When committing your code add a README.md, helm chart, dockerfile and specify a maintainer of the provider.
- Within the PR itself add a justification for why the provider should be accepted, as well as customer use cases if applicable.
Some providers are translations of Virtual Kubelet to allow others to adapt their service or applications that are written in other languages.