feature(cluster): Add VULTR vke as an inference cluster provider - #370
Open
haarchri wants to merge 1 commit into
Open
feature(cluster): Add VULTR vke as an inference cluster provider#370haarchri wants to merge 1 commit into
haarchri wants to merge 1 commit into
Conversation
Signed-off-by: Christopher Haar <christopher.haar@upbound.io>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of your changes
Modelplane can provision inference clusters on GKE, EKS, AKS, and Nebius; Vultr was listed as Planned on the providers page. This adds Vultr VKE as a fifth provisioned cluster source, built on the
xpkg.upbound.io/upbound/provider-vultrprovider.An
InferenceClusterwithsource: Vultrcomposes a newVultrClusterXR, served by the newcompose-vultr-clusterfunction. The VKE cluster carries a fixed inline system pool for control-plane components; each user GPU pool becomes a separateVkeNodePoolmanaged resource gated on cluster readiness, so pools can be added, resized, or removed without touching the cluster.InferenceClassgains avultrprovisioning block. Vultr sizes nodes by plan (e.g.vcg-l40s-16c-180g-48vramfor 1x L40S), so the block is just plan plus accelerator.Two things VKE ships built in shape the composition. Vultr pre-installs the NVIDIA GPU Operator on GPU clusters, so rather than composing a GPU stack,
VultrClustergates its readiness on an Observe-onlyObjectwith a CEL query over thenvidia-operator-validatorDaemonSet, the cluster only reports Ready once the GPU stack is validated andnvidia.com/gpuis advertised, and the serving stack never starts before that. The Vultr CSI driver likewise installs thevultr-vfs-storageRWX StorageClass (Vultr File System) on every cluster, and node autoscaling is served by VKE itself, so no CSI driver, StorageClass, or in-cluster autoscaler is composed.Known limitation:
vultr-vfs-storageRWX class can't be mounted on GPU nodes and the shared model-weights cache is effectively unavailable there until Vultr enables it. VFS is also not available in every region, which the docs notevpc_onlyflag fails cluster creation with Error 500), so nodes keep public network interfaces; a VPC can be attached but not made the only networkFixes #305
I have:
nix flake check(or./nix.sh flake check) and made sure it passes.git commit -s.Tested
Validated end to end: a single-node L40S GPU pool provisions, passes the GPU readiness gate, and serves a model.