Update nodeInfo once node was cordoned

[jiaxuanzhou]

What this PR does / why we need it:

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #453 with #455
need to update the nodeInfo once the node was cordoned.
#uns
Special notes for your reviewer:
/assign @k82cn
Release note:

NONE

[k82cn]

Why not check Allocatable directly?

[jiaxuanzhou]

For field of status for node, there are several potential predictions as disk presure, volumes check , mem presure. etc. when scheduling . So i list three logics for this check: status, spec, metaData of the node, and Allocatable is part of the status.

[jiaxuanzhou]

BTW, for resource calculating of the func (ni *NodeInfo) AddTask(task *TaskInfo), there is not any mutex lock for nodeinfo, even the tasks(pods) were handled sequentially , but it is easy to happen that the nodeInfo for the next task(pod) is not the updated one, so the worst result is several pods were bind to the same node and the pods will be reported not enough of cpu 、 mem or GPU..

[k82cn]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jiaxuanzhou, k82cn

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [k82cn]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment