Working a devoted Kubernetes cluster per crew typically ends in extra isolation than a company requires. Whereas one cluster may be efficiently shared throughout many groups, the coordination prices enhance because the variety of groups grows. Challenges embrace conflicting CRD variations, overlapping RBAC, and no clear method to carve GPU capability into team-level budgets. At a sure scale, groups would possibly begin asking for their very own clusters simply to regain autonomy.<\/p>\n
This publish offers a sample that preserves crew autonomy with out splitting the {hardware}. This answer entails a single management aircraft cluster with a GPU pool, GPU sharing with per-team quotas, and remoted Kubernetes management aircraft per crew together with an API server, controller, knowledge retailer, syncer, and scheduler. This may be achieved utilizing two open supply instruments: KAI Scheduler and vCluster.\u00a0<\/p>\n
Comply with together with the tutorial steps and also you\u2019ll have three groups operating actual GPU Kubernetes pods in their very own tenant clusters, all sharing a single bodily GPU. You\u2019ll additionally be capable to confirm that every crew solely sees their very own workloads.<\/p>\n
Tutorial conditions and notes<\/h2>\n
To maintain the method reproducible for customers which have restricted sources, this tutorial makes use of a cluster with one NVIDIA L40S GPU and three groups sharing fractions of it. This makes the transferring components simple to see and check out. The method works the identical means on a bigger cluster with tons of of GPU nodes and dozens of groups. You possibly can scale the node pool, the queue hierarchy, and the variety of tenant clusters.\u00a0<\/p>\n
KAI Scheduler is a strong, environment friendly, and scalable topology-aware Kubernetes scheduler that was purpose-built for optimizing GPU useful resource allocation for AI workloads. It\u2019s designed to handle large-scale GPU clusters, together with hundreds of nodes, and a excessive throughput of workloads. With KAI Scheduler, you possibly can dynamically allocate GPU sources to workloads. It may run alongside the default kube-scheduler. Any pod with schedulerName: kai-scheduler is dealt with by KAI Scheduler. Every thing else goes by means of the standard kube-scheduler course of.\u00a0<\/p>\n
The vCluster Kubernetes platform provisions absolutely remoted tenant clusters in your infrastructure or instantly on naked steel. Every tenant cluster will get its personal API server, customized useful resource definitions (CRDs), and role-based entry management (RBAC), indistinguishable from a devoted Kubernetes cluster, whereas sharing the underlying nodes and {hardware}. The virtualized management aircraft is invisible to tenants: no shared management aircraft nodes, no in-cluster agent pods, and no lateral path between environments. That makes vCluster a pure match for GPU infrastructure the place groups want their very own clear cluster expertise with out splitting the {hardware}.<\/p>\n
The vCluster shared-nodes mannequin is used for this tutorial, so groups share the GPU node whereas every will get its personal remoted management aircraft, the suitable match for trusted inner groups. For untrusted tenants needing node-, network-, and storage-level separation, the identical sample extends to vCluster personal nodes.<\/p>\n
The instance on this publish makes use of three groups: NLP Group, Imaginative and prescient Group, and Recommender System Group. The NLP Group needs to put in their very own CRDs. The Imaginative and prescient Group needs cluster-admin to debug scheduling. The Recommender Group is on a unique Kubeflow model. No one needs to share a kubectl context and unintentionally break each other\u2019s environments.<\/p>\n
Utilizing vCluster, every crew will get their very own remoted management aircraft, RBAC, namespaces, and CRDs. They will every have cluster-admin entry. Beneath, all tenant clusters share the identical nodes and GPUs.<\/p>\n
Demo setting<\/h3>\n
This demo runs on an NVIDIA Brev GPU occasion on Nebius with:<\/p>\n
One NVIDIA L40S, 40 vCPUs, 160 GiB RAM, 256 GiB disk (48 GB VRAM)<\/p>\n
Ubuntu 24.04.4 LTS<\/p>\n
MicroK8s v1.36.2 \u2013 Kubernetes was preconfigured by Brev, together with the MicroK8s gpu addon, which pre-installs the NVIDIA GPU Operator into the gpu-operator-resources namespace<\/p>\n
KAI Scheduler v0.16.4<\/p>\n
vCluster CLI 0.35.1<\/p>\n
Notice: For various setups, the cluster-creation and GPU Operator set up steps will differ on GKE\/EKS\/AKS\/vanilla k8s\/k3s. Step 3 (KAI Scheduler) onward is an identical on any Kubernetes that has the NVIDIA GPU Operator operating with Container Machine Interface (CDI) enabled.<\/p>\n
![\"Diagram](\"https:\/\/developer-blogs.nvidia.com\/wp-content\/uploads\/2026\/07\/kai-scheduler-vcluster-architecture-1.webp\")
Set up standalone kubectl and helm to keep away from prefixing each command with microk8s. Then wire up a kubeconfig and pin MicroK8s so snap doesn\u2019t auto-upgrade the management aircraft in the course of the demo.<\/p>\n
sudo snap set up kubectl –classic –channel=1.35\/secure
\nsudo snap set up helm –classic<\/p>\n
mkdir -p ~\/.kube
\nsudo microk8s config > ~\/.kube\/config
\nsudo chown $USER:$USER ~\/.kube\/config
\nchmod 600 ~\/.kube\/config\n<\/p><\/div>\n
Subsequent, be certain the required MicroK8s addons are enabled:<\/p>\n
\nmicrok8s allow hostpath-storage # vCluster wants PVCs\n<\/div>\n
Then confirm:\u00a0<\/p>\n
\nkubectl get storageclass\n<\/div>\n
\nbrev-8dq0cch1j Prepared 57d v1.36.2 10.0.0.20 Ubuntu 24.04.4 LTS 6.11.0-1016-nvidia (amd64) containerd:\/\/2.2.3<\/p>\n
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
\nmicrok8s-hostpath (default) microk8s.io\/hostpath Delete WaitForFirstConsumer false 20m\n<\/p><\/div>\n
Step 2: Add the Helm repo\u00a0<\/h2>\n
Add the NVIDIA Helm repo:<\/p>\n
\nhelm repo replace\n<\/div>\n
Step 3: Verify the GPU Operator<\/h2>\n\nkubectl get pods -n gpu-operator-resources\n<\/div>\n\nNAME READY STATUS RESTARTS AGE
\ngpu-feature-discovery-wpcjm 1\/1 Working 0 8m
\ngpu-operator-57d75775c8-npjzz 1\/1 Working 0 9m
\ngpu-operator-node-feature-discovery-… 1\/1 Working 0 9m
\nnvidia-container-toolkit-daemonset-ft4hb 1\/1 Working 0 8m
\nnvidia-cuda-validator-8vqdv 0\/1 Accomplished 0 8m
\nnvidia-device-plugin-daemonset-l6fj6 1\/1 Working 0 8m
\nnvidia-operator-validator-cdnmj 1\/1 Working 0 8m\n<\/div>\nIn case you\u2019re utilizing an older GPU Operator, improve in place to 26.3.x:<\/p>\n
\nhelm improve gpu-operator nvidia\/gpu-operator
\n -n gpu-operator-resources
\n –version v26.3.3
\n –reset-then-reuse-values\n<\/div>\nIf wanted, set up NVIDIA GPU Operator instantly:<\/p>\n
\nhelm set up gpu-operator nvidia\/gpu-operator
\n -n gpu-operator-resources –create-namespace
\n –version v26.3.3
\n –set driver.enabled=false
\n –set operator.defaultRuntime=containerd
\n –set toolkit.env[0].identify=CONTAINERD_CONFIG
\n –set toolkit.env[0].worth=\/var\/snap\/microk8s\/present\/args\/containerd.toml
\n –set toolkit.env[1].identify=CONTAINERD_SOCKET
\n –set toolkit.env[1].worth=\/var\/snap\/microk8s\/widespread\/run\/containerd.sock
\n –set-string toolkit.env[2].identify=CONTAINERD_SET_AS_DEFAULT
\n –set-string toolkit.env[2].worth=1\n<\/div>\nStep 4: Set up KAI Scheduler<\/h2>\n
Subsequent, set up the KAI Scheduler:<\/p>\n
\nhelm improve -i kai-scheduler
\n oci:\/\/ghcr.io\/kai-scheduler\/kai-scheduler\/kai-scheduler
\n -n kai-scheduler –create-namespace
\n –version v0.16.4
\n –set “international.gpuSharing=true”\n<\/div>\nThen confirm:<\/p>\n
\nkubectl get pods -n kai-scheduler\n<\/div>\n\nNAME READY STATUS RESTARTS AGE
\nadmission-57556f949-sp98t 1\/1 Working 0 47s
\nbinder-66785d8dd9-9frgk 1\/1 Working 0 46s
\nkai-operator-6fdf595c4d-292d7 1\/1 Working 0 52s
\nkai-scheduler-default-6bb667b767-vq2q4 1\/1 Working 0 46s
\npod-grouper-84dfc7759b-v5qtb 1\/1 Working 0 47s
\npodgroup-controller-5878f48dbb-v7wcn 1\/1 Working 0 47s
\nqueue-controller-7796bb8984-hdn5r 1\/1 Working 0 46s\n<\/div>\nStep 5: Outline crew queues<\/h2>\n
KAI Scheduler makes use of a Queue CRD to mannequin an org \u2192 crew hierarchy. This step entails creating one mother or father (ml-org, with a complete funds of 1 GPU) and three youngster queues. Every is assured 0.33 of the GPU and allowed to extend to the total GPU when others are idle.\u00a0<\/p>\n
Save the next as create-queues.yaml:<\/p>\n
\napiVersion: scheduling.run.ai\/v2
\nform: Queue
\nmetadata:
\n identify: ml-org
\nspec:
\n sources:
\n gpu: { quota: 1, restrict: -1, overQuotaWeight: 1 }
\n—
\napiVersion: scheduling.run.ai\/v2
\nform: Queue
\nmetadata:
\n identify: team-nlp
\nspec:
\n parentQueue: ml-org
\n precedence: 100
\n sources:
\n gpu: { quota: 0.33, restrict: 1, overQuotaWeight: 1 }
\n—
\napiVersion: scheduling.run.ai\/v2
\nform: Queue
\nmetadata:
\n identify: team-vision
\nspec:
\n parentQueue: ml-org
\n precedence: 100
\n sources:
\n gpu: { quota: 0.33, restrict: 1, overQuotaWeight: 1 }
\n—
\napiVersion: scheduling.run.ai\/v2
\nform: Queue
\nmetadata:
\n identify: team-recommender
\nspec:
\n parentQueue: ml-org
\n precedence: 100
\n sources:
\n gpu: { quota: 0.33, restrict: 1, overQuotaWeight: 1 }\n<\/div>\nRight here, quota is the assured minimal, restrict is the utmost allowed, and overQuotaWeight controls how surplus is break up.<\/p>\n
Subsequent, apply and record:<\/p>\n
\nkubectl apply -f create-queues.yaml
\nkubectl get queues\n<\/div>\n\nqueue.scheduling.run.ai\/ml-org created
\nqueue.scheduling.run.ai\/team-nlp created
\nqueue.scheduling.run.ai\/team-vision created
\nqueue.scheduling.run.ai\/team-recommender created<\/p>\nNAME PRIORITY PARENT CHILDREN DISPLAYNAME
\ndefault-parent-queue [“default-queue”]
\ndefault-queue default-parent-queue
\nml-org [“team-nlp”,”team-vision”,”team-recommender”]
\nteam-nlp 100 ml-org
\nteam-recommender 100 ml-org
\nteam-vision 100 ml-org\n<\/p><\/div>\n
Notice that default-parent-queue and default-queue are created mechanically by KAI Scheduler on first set up. They’re the fallback queue for any pod that doesn\u2019t specify one.<\/p>\n
Step 6: Spin up a vCluster per crew<\/h2>\n
Subsequent, set up the vCluster CLI:<\/p>\n
\ncurl -L -o vcluster “https:\/\/github.com\/loft-sh\/vcluster\/releases\/newest\/obtain\/vcluster-linux-amd64”
\nsudo set up -m 755 vcluster \/usr\/native\/bin\/vcluster
\nrm vcluster
\nvcluster –version\n<\/div>\nOutline the vCluster config. The crucial setting is setOwner: false. The KAI Scheduler pod-grouper walks possession chains (Job \u2192 Pod, Deployment \u2192 ReplicaSet \u2192 Pod) to auto-group workloads. Disabling vCluster proprietor rewriting permits KAI Scheduler to see the actual hierarchy.<\/p>\n
\ncat > vcluster.yaml <<‘EOF’
\nexperimental:
\n syncSettings:
\n setOwner: false <\/p>\nsync:
\n fromHost:
\n nodes:
\n enabled: true
\n selector:
\n all: true
\nEOF\n<\/p><\/div>\n
Then create one vCluster per crew:<\/p>\n
\nvcluster create team-nlp –values vcluster.yaml –connect=false
\nvcluster create team-vision –values vcluster.yaml –connect=false
\nvcluster create team-recommender –values vcluster.yaml –connect=false\n<\/div>\nConfirm that every one three vClusters are operating:<\/p>\n
\n NAME | NAMESPACE | STATUS | VERSION | CONNECTED | AGE
\n ——————-+—————————+———+———+———–+——-
\n team-nlp | vcluster-team-nlp | Working | 0.35.1 | | 102s
\n team-recommender | vcluster-team-recommender | Working | 0.35.1 | | 88s
\n team-vision | vcluster-team-vision | Working | 0.35.1 | | 93s\n<\/div>\nEvery crew sees the actual nodes, together with the GPU node:<\/p>\n
\nvcluster join team-nlp — kubectl get nodes\n<\/div>\n\n19:09:22 accomplished vCluster is up and operating
\nNAME STATUS ROLES AGE VERSION
\nbrev-8dq0cch1j Prepared 6m20s v1.36.2\n<\/div>\nStep 7: Deploy a workload from every crew<\/h2>\n
Every crew deploys their GPU workload from their very own vCluster. The pod spec is straightforward, with three fields telling KAI Scheduler what to do:<\/p>\n
\nvcluster join team-nlp — kubectl apply -f – <<‘EOF’
\napiVersion: v1
\nform: Pod
\nmetadata:
\n identify: nlp-sentiment-model
\n labels:
\n kai.scheduler\/queue: team-nlp # Which crew
\n annotations:
\n gpu-fraction: “0.33” # How a lot GPU
\nspec:
\n schedulerName: kai-scheduler. # Use KAI, not default
\n tolerations:
\n – key: nvidia.com\/gpu
\n operator: Exists
\n impact: NoSchedule
\n containers:
\n – identify: nlp-inference
\n picture: nvidia\/cuda:12.4.0-base-ubuntu22.04
\n command: [“bash”, “-c”, “nvidia-smi; sleep infinity”]
\n nodeSelector:
\n nvidia.com\/gpu.current: “true”
\nEOF\n<\/div>\n\n19:13:34 accomplished vCluster is up and operating
\npod\/nlp-sentiment-model created\n<\/div>\nDo the identical to deploy from every crew, altering the queue identify.\u00a0<\/p>\n
Now, confirm:<\/p>\n
\nNAMESPACE NAME READY STATUS RESTARTS AGE IP NODE
\nvcluster-team-nlp nlp-sentiment-model-x-default-x-team-nlp 1\/1 Working 0 110s 10.1.171.180 brev-8dq0cch1j
\nvcluster-team-recommender recommender-model-x-default-x-team-recommender 1\/1 Working 0 6s 10.1.171.187 brev-8dq0cch1j
\nvcluster-team-vision vision-classifier-model-x-default-x-team-vision 1\/1 Working 0 14s 10.1.171.145 brev-8dq0cch1j\n<\/div>\nThree pods, three totally different vcluster-team-* namespaces, all operating on the identical bodily node brev-8dq0cch1j.\u00a0<\/p>\n
Every crew sees solely their very own pod from inside their vCluster:<\/p>\n
\nvcluster join team-nlp — kubectl get pods -o huge
\nvcluster join team-vision — kubectl get pods -o huge
\nvcluster join team-recommender — kubectl get pods -o huge\n<\/div>\n\nNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
\nnlp-sentiment-model 1\/1 Working 0 3m11s 10.1.171.180 brev-8dq0cch1j <\/p>\nNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
\nvision-classifier-model 1\/1 Working 0 3m59s 10.1.171.145 brev-8dq0cch1j <\/p>\n
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
\nrecommender-model 1\/1 Working 0 2m45s 10.1.171.187 brev-8dq0cch1j\n<\/p><\/div>\n
Lastly, the queue confirms the allocation. You possibly can test all three on the identical time:<\/p>\n
\ngpu-feature-discovery-wpcjm 1\/1 Working 0 8m
\ngpu-operator-57d75775c8-npjzz 1\/1 Working 0 9m
\ngpu-operator-node-feature-discovery-… 1\/1 Working 0 9m
\nnvidia-container-toolkit-daemonset-ft4hb 1\/1 Working 0 8m
\nnvidia-cuda-validator-8vqdv 0\/1 Accomplished 0 8m
\nnvidia-device-plugin-daemonset-l6fj6 1\/1 Working 0 8m
\nnvidia-operator-validator-cdnmj 1\/1 Working 0 8m\n<\/div>\n
In case you\u2019re utilizing an older GPU Operator, improve in place to 26.3.x:<\/p>\n
\n -n gpu-operator-resources
\n –version v26.3.3
\n –reset-then-reuse-values\n<\/div>\n
If wanted, set up NVIDIA GPU Operator instantly:<\/p>\n
\n -n gpu-operator-resources –create-namespace
\n –version v26.3.3
\n –set driver.enabled=false
\n –set operator.defaultRuntime=containerd
\n –set toolkit.env[0].identify=CONTAINERD_CONFIG
\n –set toolkit.env[0].worth=\/var\/snap\/microk8s\/present\/args\/containerd.toml
\n –set toolkit.env[1].identify=CONTAINERD_SOCKET
\n –set toolkit.env[1].worth=\/var\/snap\/microk8s\/widespread\/run\/containerd.sock
\n –set-string toolkit.env[2].identify=CONTAINERD_SET_AS_DEFAULT
\n –set-string toolkit.env[2].worth=1\n<\/div>\n
Step 4: Set up KAI Scheduler<\/h2>\n
Subsequent, set up the KAI Scheduler:<\/p>\n
\n oci:\/\/ghcr.io\/kai-scheduler\/kai-scheduler\/kai-scheduler
\n -n kai-scheduler –create-namespace
\n –version v0.16.4
\n –set “international.gpuSharing=true”\n<\/div>\n
Then confirm:<\/p>\n
\nadmission-57556f949-sp98t 1\/1 Working 0 47s
\nbinder-66785d8dd9-9frgk 1\/1 Working 0 46s
\nkai-operator-6fdf595c4d-292d7 1\/1 Working 0 52s
\nkai-scheduler-default-6bb667b767-vq2q4 1\/1 Working 0 46s
\npod-grouper-84dfc7759b-v5qtb 1\/1 Working 0 47s
\npodgroup-controller-5878f48dbb-v7wcn 1\/1 Working 0 47s
\nqueue-controller-7796bb8984-hdn5r 1\/1 Working 0 46s\n<\/div>\n
Step 5: Outline crew queues<\/h2>\n
KAI Scheduler makes use of a Queue CRD to mannequin an org \u2192 crew hierarchy. This step entails creating one mother or father (ml-org, with a complete funds of 1 GPU) and three youngster queues. Every is assured 0.33 of the GPU and allowed to extend to the total GPU when others are idle.\u00a0<\/p>\n
Save the next as create-queues.yaml:<\/p>\n
\nform: Queue
\nmetadata:
\n identify: ml-org
\nspec:
\n sources:
\n gpu: { quota: 1, restrict: -1, overQuotaWeight: 1 }
\n—
\napiVersion: scheduling.run.ai\/v2
\nform: Queue
\nmetadata:
\n identify: team-nlp
\nspec:
\n parentQueue: ml-org
\n precedence: 100
\n sources:
\n gpu: { quota: 0.33, restrict: 1, overQuotaWeight: 1 }
\n—
\napiVersion: scheduling.run.ai\/v2
\nform: Queue
\nmetadata:
\n identify: team-vision
\nspec:
\n parentQueue: ml-org
\n precedence: 100
\n sources:
\n gpu: { quota: 0.33, restrict: 1, overQuotaWeight: 1 }
\n—
\napiVersion: scheduling.run.ai\/v2
\nform: Queue
\nmetadata:
\n identify: team-recommender
\nspec:
\n parentQueue: ml-org
\n precedence: 100
\n sources:
\n gpu: { quota: 0.33, restrict: 1, overQuotaWeight: 1 }\n<\/div>\n
Right here, quota is the assured minimal, restrict is the utmost allowed, and overQuotaWeight controls how surplus is break up.<\/p>\n
Subsequent, apply and record:<\/p>\n
\nkubectl get queues\n<\/div>\n
\nqueue.scheduling.run.ai\/team-nlp created
\nqueue.scheduling.run.ai\/team-vision created
\nqueue.scheduling.run.ai\/team-recommender created<\/p>\n
NAME PRIORITY PARENT CHILDREN DISPLAYNAME
\ndefault-parent-queue [“default-queue”]
\ndefault-queue default-parent-queue
\nml-org [“team-nlp”,”team-vision”,”team-recommender”]
\nteam-nlp 100 ml-org
\nteam-recommender 100 ml-org
\nteam-vision 100 ml-org\n<\/p><\/div>\n
Notice that default-parent-queue and default-queue are created mechanically by KAI Scheduler on first set up. They’re the fallback queue for any pod that doesn\u2019t specify one.<\/p>\n
Step 6: Spin up a vCluster per crew<\/h2>\n
Subsequent, set up the vCluster CLI:<\/p>\n
\nsudo set up -m 755 vcluster \/usr\/native\/bin\/vcluster
\nrm vcluster
\nvcluster –version\n<\/div>\n
Outline the vCluster config. The crucial setting is setOwner: false. The KAI Scheduler pod-grouper walks possession chains (Job \u2192 Pod, Deployment \u2192 ReplicaSet \u2192 Pod) to auto-group workloads. Disabling vCluster proprietor rewriting permits KAI Scheduler to see the actual hierarchy.<\/p>\n
\nexperimental:
\n syncSettings:
\n setOwner: false <\/p>\n
sync:
\n fromHost:
\n nodes:
\n enabled: true
\n selector:
\n all: true
\nEOF\n<\/p><\/div>\n
Then create one vCluster per crew:<\/p>\n
\nvcluster create team-vision –values vcluster.yaml –connect=false
\nvcluster create team-recommender –values vcluster.yaml –connect=false\n<\/div>\n
Confirm that every one three vClusters are operating:<\/p>\n
\n ——————-+—————————+———+———+———–+——-
\n team-nlp | vcluster-team-nlp | Working | 0.35.1 | | 102s
\n team-recommender | vcluster-team-recommender | Working | 0.35.1 | | 88s
\n team-vision | vcluster-team-vision | Working | 0.35.1 | | 93s\n<\/div>\n
Every crew sees the actual nodes, together with the GPU node:<\/p>\n
\nNAME STATUS ROLES AGE VERSION
\nbrev-8dq0cch1j Prepared 6m20s v1.36.2\n<\/div>\n
Step 7: Deploy a workload from every crew<\/h2>\n
Every crew deploys their GPU workload from their very own vCluster. The pod spec is straightforward, with three fields telling KAI Scheduler what to do:<\/p>\n
\napiVersion: v1
\nform: Pod
\nmetadata:
\n identify: nlp-sentiment-model
\n labels:
\n kai.scheduler\/queue: team-nlp # Which crew
\n annotations:
\n gpu-fraction: “0.33” # How a lot GPU
\nspec:
\n schedulerName: kai-scheduler. # Use KAI, not default
\n tolerations:
\n – key: nvidia.com\/gpu
\n operator: Exists
\n impact: NoSchedule
\n containers:
\n – identify: nlp-inference
\n picture: nvidia\/cuda:12.4.0-base-ubuntu22.04
\n command: [“bash”, “-c”, “nvidia-smi; sleep infinity”]
\n nodeSelector:
\n nvidia.com\/gpu.current: “true”
\nEOF\n<\/div>\n
\npod\/nlp-sentiment-model created\n<\/div>\n
Do the identical to deploy from every crew, altering the queue identify.\u00a0<\/p>\n
Now, confirm:<\/p>\n
\nvcluster-team-nlp nlp-sentiment-model-x-default-x-team-nlp 1\/1 Working 0 110s 10.1.171.180 brev-8dq0cch1j
\nvcluster-team-recommender recommender-model-x-default-x-team-recommender 1\/1 Working 0 6s 10.1.171.187 brev-8dq0cch1j
\nvcluster-team-vision vision-classifier-model-x-default-x-team-vision 1\/1 Working 0 14s 10.1.171.145 brev-8dq0cch1j\n<\/div>\n
Three pods, three totally different vcluster-team-* namespaces, all operating on the identical bodily node brev-8dq0cch1j.\u00a0<\/p>\n
Every crew sees solely their very own pod from inside their vCluster:<\/p>\n
\nvcluster join team-vision — kubectl get pods -o huge
\nvcluster join team-recommender — kubectl get pods -o huge\n<\/div>\n
\nnlp-sentiment-model 1\/1 Working 0 3m11s 10.1.171.180 brev-8dq0cch1j <\/p>\n
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
\nvision-classifier-model 1\/1 Working 0 3m59s 10.1.171.145 brev-8dq0cch1j <\/p>\n
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
\nrecommender-model 1\/1 Working 0 2m45s 10.1.171.187 brev-8dq0cch1j\n<\/p><\/div>\n
Lastly, the queue confirms the allocation. You possibly can test all three on the identical time:<\/p>\n