k8s scheduler不同namespace同名node节点调度异常

      上一篇文章中说到k8s是一个主从架构，接口管理和调度模块都在主节点上，node节点作为kubernetes的从节点，负责实际的pod

管理。在创建Pod时决定Pod创建在那个node节点上则是由scheduler模块来进行调度。

       目前工作中用的kubernetes版本为1.5版本，在使用过程中发现存在同名节点导致调度异常的问题，这周仔细研究了下kubernetes

 scheduler模块的源码，发现在对node节点进行管理时，kubernetes维持了一个cache，cache采用Map<name,nodeInfo>对node节点的

信息进行缓存，这里的name只是存了node节点的名称，并没有加入node的namespace，这个就会产生问题，在存在不同namespace

下同名的node时，在缓存中只会随机存入一个node节点的信息，scheduler只会感知一个node,所有pod都会调度到缓存的节点上，当这

个node节点资源不足时则调度失败，而这时另一个namespace下的同名node没有被调度。

func (cache *schedulerCache) AddNode(node *v1.Node) error {cache.mu.Lock()defer cache.mu.Unlock()n, ok := cache.nodes[node.Name]if !ok {n = NewNodeInfo()cache.nodes[node.Name] = n}return n.SetNode(node)}

   node节点作为kubernetes的从节点，通过纳管流程将普通的计算节点纳管到kubermetes中进行管理，纳管时kubernetes会在计算节点

上装上kubelet和kube-proxy,用来在节点上管理Pod和Pod的路由。node节点纳管进kubernetes后，会在etcd中存入相应节点信息，同时

scheduler也会在cache中调用addNode在Map<name,nodeInfo>加入nodeInfo。用户调用接口创建Pod之后，scheduler watch到这个动

作，会对Pod进行调度，主要是执行gennic_scheduler.go中的Scherdule()方法，找到合适的node进行具体创建这个Pod。

func (g *genericScheduler) Schedule(pod *v1.Pod, nodeLister algorithm.NodeLister) (string, error) {trace := utiltrace.New(fmt.Sprintf("Scheduling %s/%s", pod.Namespace, pod.Name))defer trace.LogIfLong(100 * time.Millisecond)nodes, err := nodeLister.List()if err != nil {return "", err}if len(nodes) == 0 {return "", ErrNoNodesAvailable}// Used for all fit and priority funcs.err = g.cache.UpdateNodeNameToInfoMap(g.cachedNodeInfoMap)if err != nil {return "", err}trace.Step("Computing predicates")filteredNodes, failedPredicateMap, err := findNodesThatFit(pod, g.cachedNodeInfoMap, nodes, g.predicates, g.extenders, g.predicateMetaProducer, g.equivalenceCache)if err != nil {return "", err}if len(filteredNodes) == 0 {return "", &FitError{Pod:              pod,FailedPredicates: failedPredicateMap,}}trace.Step("Prioritizing")metaPrioritiesInterface := g.priorityMetaProducer(pod, g.cachedNodeInfoMap)priorityList, err := PrioritizeNodes(pod, g.cachedNodeInfoMap, metaPrioritiesInterface, g.prioritizers, filteredNodes, g.extenders)if err != nil {return "", err}trace.Step("Selecting host")return g.selectHost(priorityList)}

  schedule方法先通过listNodeNamespace方法从etcd获取到node节点，然后通过UpdateNodeNameToInfoMap方法更新cache中的node信息，之后通过一系列算法进行节点的选择，都没有涉及到namespace的区分。

解决方法：

  在cache的node操作方法中都用namespace+"/"+name作为node的缓存键值，在获取nodeList时只获取pod当前namespace和default namespace下的node节点，对应的在NodeNameToInfoMap中也只获取当前namespace下的node，后面的预测和选取都针对当前namespace下的节点操作，达到namespace的空间区分的目的。