策略描述
在pod的一次调度过程中，调度器（scheduler）会有预选策略和优选策略（打分策略），其中预选策略是选择出要调度的候选节点（比如检查node节点本身状态是否ok，node节点上的资源是否满足等），而优选策略是给选择出的候选节点打分，得分最高的node就是pod要调度的节点。
ImageLocalityPriority 就是优选策略中的一种，效果是，将pod调度到image已经存在的节点上（具体的实现就是打分score）。
关于"隐藏"的说明：是因为提高调度器scheduler的日志级别之后，该优选策略给节点所打的分数不会体现在日志中（而其他优选策略是有响应的打分日志）。
算法逻辑
1 sumImageScore （自适应分数的总和）
sumImageScorenode = C1(Image.Size speed) C2(Image.Size speed) ... Cn(Image.Size * speed)
其中speed = int(存在该镜像的nodes)/int(totalNodes)
2 score打分
一种情况：score = 0; if sumImageScore < minThreshold（23M）
一种情况：score = 10; if sumImageScore >= maxThreshold（1000M）
一种情况：score = MaxPriority * ( sumImageScore- minThreshold)/(maxThreshold - minThreshold)
相关问题案例
案例1 某个服务扩容时，新增的pod无法调度到新增节点上，而是调度到了其他pod实例已经存在的节点上。导致了pod调度的不均衡。
原因：其他pod实例已经存在的节点上，镜像已经存在了，优选策略打分时，节点的得分（对比刚新增的节点）会高。
案例2 某个服务配置了pod的反亲和性调度（podAntiAffinity），使用的是preferredDuringSchedulingIgnoredDuringExecution 软亲和性调度。但是依然存在pod实例调度到同一个节点上的情况。
原因：
- podAntiAffinity属于优选策略（pod调度）中的一种，然后再pod的调度过程中会给pod打分
- 除了podAntiAffinity还有一个隐藏的优选策略：ImageLocalityPriority，如果节点上有pod的运行所需的镜像，就会优先调度（满分是10分）。
解决方案
在其他节点上通过docker pull的方式，提前下载好pod所需的镜像。
