Hello, 

I need some help/advice on a scheduling use case I am trying to solve. 
Nodes in our kubernetes cluster are partitioned into multiple network 
scopes. Each network scope has certain number of available ips which can be 
assigned to pods on these nodes (we do this with the help of TPR, IPAM and 
network plugin). So when a pod is being scheduled, we want the available 
ips in the network scope of each node to be taken into consideration for 
deciding the priorities assigned to the nodes, and potentially avoid 
scheduling pods on the nodes if their network scope ran out of ips. So 
essentially the problem is that the resource is associated not with an 
individual node but with a group of nodes, and the scheduler is not aware 
of this third-party resource. What can be an ideal pattern to solve such a 
use case? One of the approaches we are thinking of, could be adding a new 
priority and predicate function to the default scheduler which could start 
another goroutine (not sure if this is a good idea) to maintain a cache of 
available ips in the network scope of all the nodes, and then deciding node 
priorities based on that. Scheduler extender could also be another 
candidate to manage such a resource. Any thoughts/suggestions on this?

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q&A" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.
  • [kubernetes... Nikhil Dixit
    • [kuber... Tim St. Clair
      • [k... Nikhil Dixit
        • ... Tim St. Clair
          • ... 'David Oppenheimer' via Kubernetes user discussion and Q&A
            • ... Avesh Agarwal
              • ... Nikhil Dixit
                • ... Avesh Agarwal
                • ... 'Tim Hockin' via Kubernetes user discussion and Q&A
                • ... Nikhil Dixit

Reply via email to