Skip to content

Scheduling Pods

Once KNS-3 is deployed, you opt individual pods into network-aware scheduling by setting schedulerName: kns-3-scheduler. The default Kubernetes scheduler continues to handle all other pods.

Add schedulerName: kns-3-scheduler to the pod spec:

apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
schedulerName: kns-3-scheduler
containers:
- name: app
image: my-app:latest

KNS-3 will query the NS-3 simulator to score all candidate nodes based on live network metrics, then bind the pod to the highest-scoring node.

Pods can declare a network quality-of-service requirement with the kns-3-scheduler/qos annotation.

Value Behaviour
rigorous The filter plugin requires candidate nodes to carry the label capability=rigorous. Nodes without that label are excluded before scoring.
apiVersion: v1
kind: Pod
metadata:
name: latency-sensitive-pod
annotations:
kns-3-scheduler/qos: rigorous
spec:
schedulerName: kns-3-scheduler
containers:
- name: app
image: my-app:latest

To mark a node as capable of rigorous QoS, add the label:

Terminal window
kubectl label node <node-name> capability=rigorous

To prevent KNS-3 from scheduling any pods onto a specific node, add the scheduler=disabled label:

Terminal window
kubectl label node <node-name> scheduler=disabled

The filter plugin will mark that node as Unschedulable for all KNS-3-managed pods.

Set schedulerName in the pod template of the Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
schedulerName: kns-3-scheduler
containers:
- name: app
image: my-app:latest

Each replica is scheduled independently, so pods may land on different nodes depending on the simulation results at that point in time.