k8s常见故障

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了k8s常见故障相关的知识,希望对你有一定的参考价值。

故障排查思路

k8s常见故障_docker

节点处于NotReady

节点是由kubelet管理的,所以要先检查kubelet的相关情况

排查思路:

  • 查看kubelet和docker服务是否正常
systemctl status kubectl
systemctl status docker
  • 查看kubelet的日志或者重启kubelet并查看日志
systemctl restart kubectl
# 查看日志 注意辨别日志 有些错误日志 并不影响
journalctl -u kubelet -f

pod运行不正常

关于pod状态的描述 ​​https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/​

  • 查看pod详情
kubectl describe pod <podName> 
  • 查看pod日志
kubectl logs pod <podName>
  • 查看节点状态
kubectl get node
  • 查看事件
kubectl get events

互联网用户无法访问应用(ingress或service无法访问)

  • pod工作正常吗
  • service是否关联pod
  • service指定的target port是否正确
  • 如果使用名称访问,dns是否正常工作
  • kube-proxy是否正常工作
  • CNI网络插件是否正常工作 比如calico


反思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统计量将成为一种有价值的新指标。

 

以上是关于k8s常见故障的主要内容,如果未能解决你的问题,请参考以下文章

故障排查:k8s内存不足(0 nodes are available:Insufficient memory)

K8s常见故障排查思路

K8s 集群 etcd节点故障解决方案

k8s医生k8s集群故障排查 – 关于kubelet 的NotReady故障

k8s故障排查指南

k8s操作常见命令