orka3 in place of orka.
Before you begin
- A control plane that you manage with kubeadm, running Kubernetes 1.25 or later, where you can edit the kube-scheduler static pod manifest on each control plane node.
- SSH access with
sudoto every control plane node. kubectlaccess to the cluster as a cluster admin.
--scheduler most-allocated or set vm_scheduler_name to most-allocated-scheduler: VMs that ask for it stay Pending.
Add the scheduler profile
Only the kube-scheduler that holds the leader lease places pods, so every control plane node needs the profile. Change one node at a time, and confirm its kube-scheduler isRunning (step 3) before you move to the next.
1
Create the scheduler configuration
Create Keep the
/etc/kubernetes/kube-scheduler-config.yaml with the following content. It keeps the standard default-scheduler profile and adds a most-allocated-scheduler profile that scores nodes by how much of their resources are already allocated.default-scheduler profile. Every other pod in your cluster uses it. If your kube-scheduler already runs with a --config file, add the most-allocated-scheduler profile to that file instead of replacing it.2
Point kube-scheduler at the file
Edit The kubelet restarts kube-scheduler when you save the manifest.
/etc/kubernetes/manifests/kube-scheduler.yaml. If you keep a backup copy, store it outside /etc/kubernetes/manifests, or the kubelet starts it as a second scheduler. Add the --config flag to the container command, and mount the file into the pod:3
Check that kube-scheduler restarted
Running with a recent start time. If it’s in CrashLoopBackOff, check its logs with kubectl logs -n kube-system <POD_NAME>. A mistake in the configuration file is the usual cause.Repeat steps 1 to 3 on the next control plane node.4
Test the scheduler
After every control plane node is done, deploy a VM that asks for the most-allocated scheduler. A short timeout makes a missing profile show up quickly:If the VM starts, the profile works. Delete it with
orka vm delete scheduler-test. If the deploy times out, check the preceding steps on every control plane node.Keep the setup through Kubernetes upgrades
kubeadm upgrade regenerates the static pod manifests from the cluster configuration in the kubeadm-config ConfigMap, which removes the --config flag and the mount. To keep them, add them to the scheduler section of that ConfigMap:
v1beta4 configuration (Kubernetes 1.31 and later):
v1beta3, extraArgs is a map instead, for example config: /etc/kubernetes/kube-scheduler-config.yaml. After a Kubernetes upgrade, repeat the check in step 3.
Use the scheduler
After setup, choose the scheduler per VM config or per VM with--scheduler most-allocated. See orka vm-config create.
You can also make it the cluster default, for every VM that doesn’t name a scheduler. Talk to MacStadium before you do, because a mistake here affects every VM:
- Do it only after the setup succeeds on every control plane node. If the profile is missing or the name is misspelled, every VM that doesn’t name a scheduler stays
Pending. - Pass
-e vm_scheduler_name=most-allocated-schedulerto the Orka installer. Setting it incluster.ymldoesn’t work, because the installer’s own settings win. See Override installer settings. - Pass it on every installer run, including upgrades. A run without it sets the default back to
default-scheduler.

