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

时间：2021-10-05 20:04:23

      上一篇文章中说到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的空间区分的目的。

标签：

相关文章