k8s 探针

Posted 2023-04-03 魏志标

在Kubernetes中可以通过探针配置运行状况检查，以确定每个 Pod 的状态。

一、概述

在k8s中只要将pod调度到某个节点，Kubelet就会运行pod的容器，如果该pod的容器有一个或者所有的都终止运行(容器的主进程崩溃)，Kubelet将重启容器，所以即使应用程序本身没有做任何特殊的事，在Kubemetes中运行也能自动获得自我修复的能力。

自动重启容器以保证应用的正常运行，这是使用Kubernetes的优势，不过在某些情况，即使进程没有崩溃，有时应用程序运行也会出错。默认情况下Kubernetes只是检查Pod容器是否正常运行，但容器正常运行并不一定代表应用健康。

• Kubemetes可以通过存活探针(liveness probe)检查容器是否还在运行；
• 通过就绪探针(readiness probe)保证只有准备好了请求的Pod才能接收客户端请求。

二、探针介绍

K8S 提供了3种探针

• readinessProbe：

指示容器是否准备好服务请求（是否启动完成并就绪）。就绪探针初始延迟之前的就绪状态默认为Failure，待容器启动成功弹指指标探测结果为成功后，状态变更为 Success。如果未配置就绪探针，则默认状态为Success。
只有状态为 Success ，才会被纳入 pod 所属 service ，添加到endpoint中，也就是 service 接收到请求后才有可能会被分发处理请求。
如果ReadinessProbe探针检测到失败，则Pod的状态被修改。Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的Endpoint。

• livenessProbe：

用于判断容器是否存活（running状态），如果LivenessProbe探针探测到容器不健康（你可以配置连续多少次失败才记为不健康），则 kubelet 会杀掉该容器，并根据容器的重启策略restartPolicy做相应的处理。如果未配置存活探针，则默认状态为Success。即探针返回的值永远是 Success。

• startupProbe:

判断容器内的应用程序是否已启动。如果配置了启动探测，在则在启动探针状态为 Succes 之前，其他所有探针都处于无效状态，直到它成功后其他探针才起作用。如果启动探测失败，kubelet 将杀死容器，容器将服从其重启策略。如果容器没有配置启动探测，则默认状态为 Success。

容器重启策略restartPolicy有三个可选值：
Always：当容器终止退出后，总是重启容器，默认策略。
OnFailure：当容器异常退出（退出状态码非0）时，才重启容器。
Never：当容器终止退出，从不重启容器。

以上三种探针都具有以下参数：

initialDelaySeconds ：启动 liveness、readiness 探针前要等待的秒数。默认是0
periodSeconds ：检查探针的频率。默认是1
timeoutSeconds ：检测超时时间，默认是1
successThreshold ：探针需要通过的最小连续成功检查次数。通过为成功，默认是1
failureThreshold ：将探针标记为失败之前的重试次数。对于 liveness 探针，这将导致 Pod 重新启动。对于 readiness 探针，将标记 Pod 为未就绪（unready）。默认是1

三、探针探测方式

每种探测机制支持三种健康检查方法，分别是命令行exec，httpGet和tcpSocket，其中exec通用性最强，适用与大部分场景，tcpSocket适用于TCP业务，httpGet适用于web业务

exec（自定义健康检查）：在容器中执行指定的命令，如果执行成功，退出码为 0 则探测成功。
httpGet：通过容器的IP地址、端口号及路径调用 HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器 健康。
tcpSocket：通过容器的 IP 地址和端口号执行 TCP 检 查，如果能够建立 TCP 连接，则表明容器健康。

探针探测结果有以下值：

• Success：表示通过检测。
• Failure：表示未通过检测。
• Unknown：表示检测没有正常进行。

四、探针区别

readinessProbe 和 livenessProbe 可以使用相同探测方式，只是对 Pod 的处置方式不同。

livenessProbe 当检测失败后，将杀死容器并根据 Pod 的重启策略来决定作出对应的措施。

readinessProbe 当检测失败后，将 Pod 的 IP:Port 从对应的 EndPoint 列表中删除,不在接收流量

五、案例

启动pod，使用livenessProbe以及readinessProbe

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: test
spec:
  containers:
    - name: nginx
      image: nginx:latest
      livenessProbe:
        httpGet:
          path: /health
          port: 80
        initialDelaySeconds: 30
        periodSeconds: 10
      readinessProbe:
        tcpSocket:
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 5

kubectl get po -n test

[root@master ~]# kubectl get po  -n test  -o wide 
NAME    READY   STATUS    RESTARTS   AGE   IP             NODE    NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          19s   10.233.90.14   node1   <none>           <none>


####nginx日志如下：每隔10S检测一下状态
[root@master ~]# kubectl logs nginx -n test  
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2023/04/03 06:30:29 [notice] 1#1: using the "epoll" event method
2023/04/03 06:30:29 [notice] 1#1: nginx/1.23.3
2023/04/03 06:30:29 [notice] 1#1: built by gcc 10.2.1 20210110 (Debian 10.2.1-6) 
2023/04/03 06:30:29 [notice] 1#1: OS: Linux 3.10.0-1127.el7.x86_64
2023/04/03 06:30:29 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2023/04/03 06:30:29 [notice] 1#1: start worker processes
2023/04/03 06:30:29 [notice] 1#1: start worker process 30
2023/04/03 06:30:29 [notice] 1#1: start worker process 31
2023/04/03 06:30:29 [notice] 1#1: start worker process 32
2023/04/03 06:30:29 [notice] 1#1: start worker process 33
192.168.5.227 - - [03/Apr/2023:06:31:08 +0000] "GET / HTTP/1.1" 200 615 "-" "kube-probe/1.25" "-"
192.168.5.227 - - [03/Apr/2023:06:31:18 +0000] "GET / HTTP/1.1" 200 615 "-" "kube-probe/1.25" "-"
192.168.5.227 - - [03/Apr/2023:06:31:28 +0000] "GET / HTTP/1.1" 200 615 "-" "kube-probe/1.25" "-"
192.168.5.227 - - [03/Apr/2023:06:31:38 +0000] "GET / HTTP/1.1" 200 615 "-" "kube-probe/1.25" "-"

测试异常情况:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  namespace: test
spec:
  nodeName: node1
  restartPolicy:  Always
  containers:
  - name: count
    image: nginx:latest
    imagePullPolicy: IfNotPresent
    livenessProbe:
      httpGet:
        port: 81    ####修改端口为81 
      initialDelaySeconds: 30
      periodSeconds: 10
    readinessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 5

启动pod后，查看pod日志信息，如下：

2023/04/03 06:13:44 [notice] 32#32: gracefully shutting down
2023/04/03 06:13:44 [notice] 33#33: gracefully shutting down
2023/04/03 06:13:44 [notice] 32#32: exiting
2023/04/03 06:13:44 [notice] 33#33: exiting
2023/04/03 06:13:44 [notice] 33#33: exit
2023/04/03 06:13:44 [notice] 32#32: exit
2023/04/03 06:13:44 [notice] 31#31: gracefully shutting down
2023/04/03 06:13:44 [notice] 31#31: exiting
2023/04/03 06:13:44 [notice] 31#31: exit
2023/04/03 06:13:45 [notice] 30#30: gracefully shutting down
2023/04/03 06:13:45 [notice] 30#30: exiting
2023/04/03 06:13:45 [notice] 30#30: exit
2023/04/03 06:13:45 [notice] 1#1: signal 17 (SIGCHLD) received from 33
2023/04/03 06:13:45 [notice] 1#1: worker process 32 exited with code 0
2023/04/03 06:13:45 [notice] 1#1: worker process 33 exited with code 0
2023/04/03 06:13:45 [notice] 1#1: signal 29 (SIGIO) received
2023/04/03 06:13:45 [notice] 1#1: signal 17 (SIGCHLD) received from 32
2023/04/03 06:13:45 [notice] 1#1: signal 17 (SIGCHLD) received from 31
2023/04/03 06:13:45 [notice] 1#1: worker process 31 exited with code 0
2023/04/03 06:13:45 [notice] 1#1: signal 29 (SIGIO) received
2023/04/03 06:13:45 [notice] 1#1: signal 17 (SIGCHLD) received from 30
2023/04/03 06:13:45 [notice] 1#1: worker process 30 exited with code 0
2023/04/03 06:13:45 [notice] 1#1: exit

kubectl get po -n test查看pod

[root@master ~]# kubectl get po  -n test -o wide 
NAME    READY   STATUS             RESTARTS      AGE     IP             NODE    NOMINATED NODE   READINESS GATES
nginx   0/1     CrashLoopBackOff   5 (27s ago)   6m28s   10.233.90.12   node1   <none>           <none>

[root@master ~]# kubectl describe po nginx -n test    ####describe查看pod信息如下，提示Liveness probe failed 

Name:             nginx
Namespace:        test
Priority:         0
Service Account:  default
Node:             node1/192.168.5.227
Start Time:       Mon, 03 Apr 2023 14:07:44 +0800
Labels:           <none>
Annotations:      cni.projectcalico.org/containerID: fc89567be28e2010a6f0997482489b65649ac2136c92c603d5a5537dc2e7efbd
                  cni.projectcalico.org/podIP: 10.233.90.12/32
                  cni.projectcalico.org/podIPs: 10.233.90.12/32
Status:           Running
IP:               10.233.90.12
IPs:
  IP:  10.233.90.12
Containers:
  count:
    Container ID:   containerd://10de8e85609ac2d33cac17fa995a7a1c88f318ef10ddbb6086898fb32b216bb6
    Image:          nginx:latest
    Image ID:       docker.io/library/nginx@sha256:aa0afebbb3cfa473099a62c4b32e9b3fb73ed23f2a75a65ce1d4b4f55a5c2ef2
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Mon, 03 Apr 2023 14:18:51 +0800
      Finished:     Mon, 03 Apr 2023 14:19:45 +0800
    Ready:          False
    Restart Count:  7
    Liveness:       http-get http://:81/ delay=30s timeout=1s period=10s #success=1 #failure=3
    Readiness:      tcp-socket :80 delay=5s timeout=1s period=5s #success=1 #failure=3
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-zpsdf (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  kube-api-access-zpsdf:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                     From     Message
  ----     ------     ----                    ----     -------
  Normal   Killing    10m (x3 over 12m)       kubelet  Container count failed liveness probe, will be restarted
  Normal   Pulled     10m (x4 over 13m)       kubelet  Container image "nginx:latest" already present on machine
  Normal   Started    10m (x4 over 13m)       kubelet  Started container count
  Warning  Unhealthy  9m57s (x10 over 12m)    kubelet  Liveness probe failed: Get "http://10.233.90.12:81/": dial tcp 10.233.90.12:81: connect: connection refused
  Normal   Created    8m36s (x6 over 13m)     kubelet  Created container count
  Warning  BackOff    3m22s (x19 over 7m36s)  kubelet  Back-off restarting failed container
[root@master ~]# 

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