k8s nodeAffinity

Posted 2023-05-01

参考技术A Node Affinity
Affinity 翻译成中文是“亲和性”，它对应的是 Anti-Affinity，我们翻译成“互斥”。这两个词比较形象，可以把 pod 选择 node 的过程类比成磁铁的吸引和互斥，不同的是除了简单的正负极之外，pod 和 node 的吸引和互斥是可以灵活配置的。

Affinity的优点：

匹配有更多的逻辑组合，不只是字符串的完全相等
调度分成软策略(soft)和硬策略(hard)，在软策略下，如果没有满足调度条件的节点，pod会忽略这条规则，继续完成调度。
目前主要的node affinity：

requiredDuringSchedulingIgnoredDuringExecution
表示pod必须部署到满足条件的节点上，如果没有满足条件的节点，就不停重试。其中IgnoreDuringExecution表示pod部署之后运行的时候，如果节点标签发生了变化，不再满足pod指定的条件，pod也会继续运行。

requiredDuringSchedulingRequiredDuringExecution
表示pod必须部署到满足条件的节点上，如果没有满足条件的节点，就不停重试。其中RequiredDuringExecution表示pod部署之后运行的时候，如果节点标签发生了变化，不再满足pod指定的条件，则重新选择符合要求的节点。

preferredDuringSchedulingIgnoredDuringExecution
表示优先部署到满足条件的节点上，如果没有满足条件的节点，就忽略这些条件，按照正常逻辑部署。

preferredDuringSchedulingRequiredDuringExecution
表示优先部署到满足条件的节点上，如果没有满足条件的节点，就忽略这些条件，按照正常逻辑部署。其中RequiredDuringExecution表示如果后面节点标签发生了变化，满足了条件，则重新调度到满足条件的节点。

pod绑定节点最简单的方法是使用 nodeSelector，但它比较简单粗暴，使用起来不能灵活调度，这个在后续版本中也会慢慢过实，所以我们一般用 nodeAffinity来实现这些需求。
如果我不希望pod调度到打了 tester=chenqiang 这个标签的 node，那么需要使用 NotIn 这个介词，否则使用 In 。
假设不希望调度，则添加如下的 nodeAffinity:

这条规则表示，pod可以被调度到标签key为“kubernetes.io/e2e-az-name”，值为“e2e-az1”或“e2e-az2”的节点。另外，在满足该条件的节点中，优先使用具有“another-node-label-key”标签，且至为“another-node-label-value”的节点。
这个 pod 同时定义了 requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution 两种 nodeAffinity。第一个要求 pod 运行在特定 AZ 的节点上，第二个希望节点最好有对应的 another-node-label-key:another-node-label-value 标签。

这里的匹配逻辑是label在某个列表中，可选的操作符有：

In: label的值在某个列表中
NotIn：label的值不在某个列表中
Exists：某个label存在
DoesNotExist：某个label不存在
Gt：label的值大于某个值（字符串比较）
Lt：label的值小于某个值（字符串比较）
如果nodeAffinity中nodeSelector有多个选项，节点满足任何一个条件即可；如果matchExpressions有多个选项，则节点必须同时满足这些选项才能运行pod 。

需要说明的是，node并没有anti-affinity这种东西，因为NotIn和DoesNotExist能提供类似的功能。

反思K-S指标（KPMG大数据挖掘）

评估信用评级模型，反思K-S指标

2015-12-05 KPMG大数据团队 KPMG大数据挖掘

 

“信用评级”的概念听起来可以十分直截了当。比如一天早上你接到电话，有个熟人跟你借钱，而你将在半睡半醒间迅速做出决定：借，还是不借。在灵光闪现的一秒里，你或许考虑了对方的脾气秉性、经济实力、家庭住址、种种黑白历史……但最终，你面对的是一道只有两个选项的单选题，并需要承担选择的后果，这就是一种最简单的“评级”。商业银行对待申请借贷的客户也类似。为了控制不良贷款、避免损失，银行需要提前对客户进行信用评级。当然，主观评价客户缺乏操作性，这时就需要建立某种信用评级模型，利用数据将客户划分为“好客户”和“坏客户”，即守信客户和违约客户。

信用评级模型已经有了五六十年的实践应用历史，也在不断发展的过程中逐渐建立了相对较全面的评价体系。衡量信用评级模型是否强大的关键，是其区分好坏客户并进行正确排序的能力。根据业内经验，我们可以通过考察模型对客户按风险排序的结果与实际发生违约的结果之间的一致性来判断模型的准确性。在有效的情况下，模型会赋予那些容易违约的客户低评分值，同时赋予那些不易违约的客户赋予评分值，从而体现模型的区分能力：区分能力越高则说明模型越好，反之则说明模型越差。

根据这一原理，在信用评分模型的评价准则中，K-S统计量由于计算简便、易于理解，而成为少数几个被广泛使用的评价指标之一。本文将介绍K-S统计量及其存在的缺陷，并提出“AUKS统计量”作为一种新的评价标准，希望能为银行的信用评级业务及其他相关实践提供新思路。

K-S统计量来源于两样本Kolmogorov-Smirnov检验，这是一种非参数检验，用于检验两个一元概率分布是否相同。K-S统计量度量了两个分布之间的最大垂直距离，即

两样本K-S检验主要考察两个样本是否服从同一个分布，这一点被借鉴为信用评级模型的评判标准。信用评价模型的输出结果可认为是事件发生的概率。如果坏客户预测值的经验分布显著区别于好客户预测值的经验分布，说明信用评级模型分派给了好客户和坏客户显著不同的估计值。K-S统计量就等于好客户和坏客户的的经验分布间的最大距离。如果两个分布显著不同，则可以认为模型的K-S统计量足够区分申请人是否会成为坏客户。如下图所示：

如何评估一个信用评级模型的效果呢？我们必须选择一个验证样本，这个样本不同于创建模型的建模样本。和建模样本一样，验证样本中的一条观测代表一个客户，其中的因变量Y和输入变量X的值都是已知的。在验证模型的时候，首先会用待检验的模型来预测验证样本中每一个客户的或者信用评分。如果以K-S统计量作为模型优劣的评判标准，这个值就可以根据验证样本中每个客户的或者评分计算出来。把这些或者评分从低到高排序，然后等分成若干个组（通常为20组或者10组），每一组都会包含好客户和坏客户，因为模型的错误分类是不可能避免的，任何一个评分模型不可能给所有的坏客户绝对的低分所有的好客户绝对的高分。但是，一个好的模型能够保证坏客户的评分相对比较低而好客户的评分相对比较高，即好的模型能保证有更多的和谐对。上图中，虚线表示好客户的的经验分布，实线表示坏客户的的经验分布。两个经验分布之间的最大距离就是K-S统计量。K-S统计量的值越大，两个区别越显著，评分模型给出的评分越合理。因此，K-S统计量可以作为信用评分模型的评判标准，在实际操作中也较为方便，SAS中的NPAR1WAYProcedure和EM模块及R语言中的基本软件包stats都可以用来计算该指标。

然而，K-S统计量也存在相当显著的缺陷。K-S统计量仅仅从一个点来衡量两个分布的差异，其稳定性必然不足。我们曾设计验证方案，参考另一个常用指标AUC统计量，对样本量5960的验证样本进行多次抽样，并用每一个抽取出来的样本做模型验证计算K-S统计量和另一常用指标AUC统计量来检查它们的稳定性。最终，我们发现，K-S统计量的变异系数远远大于AUC统计量的变异系数。

要增加稳定性，最好的方法莫过于将距离变为面积，将局部推广到整体。为此，我们设计了一个新统计量：K-S曲线下的面积（Area under the K-S curve），可以简写为AUKS。

当，可以假设，则

与K-S统计量相比，AUKS统计量的优点在于：从整个评分的取值域而不是一个点来检验模型的优劣，具有更好的稳定性，对样本量的依赖程度相对较低。我们用两个统计量对评价模型进行了验证，在模拟实验中，与K-S统计量相比，AUKS统计量始终有更加稳定的均值、更小的标准差和更小的变异系数，作为信用评分模型的评价指标具有更好的稳定性。

在信用评分领域的多年实践工作中，业内已经创造并总结了一套较为全面的评价标准，这些标准互为补充，大体能保证信用评价模型的应用价值。然而，这些标准、指标和统计量仍存在缺陷，需要我们根据实际情况不断加以修正、改进，继续完善这一评价标准体系。相信AUKS统计量将成为一种有价值的新指标。