经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置：技术经验 » 数据库/运维 » Kubernetes » 查看文章
liveness-probe探针和readness-probe
来源：cnblogs　　作者：FuShudi　　时间：2024/2/7 9:48:50　　对本文有异议

目录

探针

在我们之前提到过的deploy控制器里面，他是对pod的状态进行管理，只有当pod的状态不是running的时候他才会重构pod，但是如果我们启动了一个nginx的pod，但是这个pod的index文件被删除掉了，此时pod的状态依旧是running，但是用户无法拿到正常的页面，这种情况下控制器是做不了管控的，对于这种情况，我们可以来使用探针

liveness-probe 存活探针

这个探针的作用是保证pod的正常运行，注意，是正常运行而不是运行，这个就是他与deploy控制器最大的区别
我们可以使用这个探针来检测nginx容器的index.html文件是否存在，如果存在的话那么这个容器就是正常在运行的，如果不存在那么就是我们开头就提到过的那种情况，控制器看他的状态是running，但是他没有index文件，探针负责每隔一段时间就检查这个文件是否存在，如果存在就不做操作，如果不存在的话那么kebelet就会干掉这个容器并重新启动一个新的容器

探针的3种方式

探针有3种检测方式，分别是exec，httpGet和tcpSocket，这三种方式的定义方法都大差不差

1. exec

这种方式就是通过事先定义好的命令去检测，如果命令执行的结果为0那么就是正常的，如果命令的结果是非0的任何值，那么说明命令执行失败了，容器没有正常运行，需要重构容器

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   labels:
  5.     run: nginx
  6.   name: nginx
  7. spec:
  8.   containers:
  9.   - image: nginx
  10.     imagePullPolicy: IfNotPresent
  11.     name: nginx
  12.     resources: {}
  13. # 存活探针
  14.     livenessProbe:
  15. # 执行的操作
  16.       exec:
  17. # 使用test -f 命令来检测文件是否存在
  18.         command: ["test","-f","/usr/share/nginx/html/index.html" ]
  19. # 在执行第一次检测之前需要等待多少秒，这里是2
  20.       initialDelaySeconds: 2
  21. # 每隔多少秒触发一次检测，这里也是2
  22.       periodSeconds: 2
  23.   dnsPolicy: ClusterFirst
  24.   restartPolicy: Always
  25. status: {}

我们写好的yaml文件是检测index.html文件是否存在，那么我们现在来将他创建出来，然后删除index.html文件看看他会发生什么

  1. [root@master k8s]# kubectl apply -f liveness-probe.yaml 
  2. pod/nginx created
  3. [root@master k8s]# kubectl get pods
  4. NAME    READY   STATUS    RESTARTS   AGE
  5. nginx   1/1     Running   0          3s

他现在是正常运行的，并且重启次数是0，那么我们使用命令删除掉他的index.html文件

  1. [root@master k8s]# kubectl exec -it nginx -- rm -f /usr/share/nginx/html/index.html
  2. [root@master k8s]# kubectl get pods
  3. NAME    READY   STATUS    RESTARTS   AGE
  4. nginx   1/1     Running   0          60s
  5. [root@master k8s]# kubectl get pods
  6. NAME    READY   STATUS    RESTARTS   AGE
  7. nginx   1/1     Running   0          62s
  8. [root@master k8s]# kubectl get pods
  9. NAME    READY   STATUS    RESTARTS     AGE
  10. nginx   1/1     Running   1 (1s ago)   63s

我们可以看到，在我们执行完删除命令之后，过了几秒这个容器的重启次数就是1了，然后我们再来看看index.html文件是否回来了

  1. [root@master k8s]# kubectl exec -it nginx -- ls -l /usr/share/nginx/html/index.html
  2. -rw-r--r-- 1 root root 615 Oct 24 13:46 /usr/share/nginx/html/index.html

我们可以看到，这个文件确实重新回来了，为什么他会重新回来呢？
我们之前说过，只要存活探针检测到这个文件不存在了，那么他就会直接使用之前的镜像来创建一个新的pod
所以这个文件就又有了

2. httpGet

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   labels:
  5.     run: nginx
  6.   name: nginx
  7. spec:
  8.   containers:
  9.   - image: nginx
  10.     imagePullPolicy: IfNotPresent
  11.     name: nginx
  12.     resources: {}
  13.     livenessProbe:
  14. # 只改动了这个地方
  15.       httpGet:
  16. # http请求的地址，端口
  17.         path: /index.html
  18.         port: 80
  19.       initialDelaySeconds: 2
  20.       periodSeconds: 2
  21.   dnsPolicy: ClusterFirst
  22.   restartPolicy: Always
  23. status: {}

通过上面的yaml文件我们可以很清楚的知道，我们需要请求的是这个网站的根目录下的index.html，注意，是网站的根目录，不是linux的根目录，注意区分开

  1. [root@master k8s]# kubectl apply -f liveness-probe.yaml 
  2. pod/nginx created
  3. [root@master k8s]# kubectl get pods
  4. NAME    READY   STATUS    RESTARTS   AGE
  5. nginx   1/1     Running   0          3s

我们还是去删除掉他的index.html文件

  1. [root@master k8s]# kubectl exec -it nginx -- rm -f /usr/share/nginx/html/index.html
  2. [root@master k8s]# kubectl get pods
  3. NAME    READY   STATUS    RESTARTS   AGE
  4. nginx   1/1     Running   0          47s
  5. [root@master k8s]# kubectl get pods
  6. NAME    READY   STATUS    RESTARTS   AGE
  7. nginx   1/1     Running   0          48s
  8. [root@master k8s]# kubectl get pods
  9. NAME    READY   STATUS    RESTARTS     AGE
  10. nginx   1/1     Running   1 (0s ago)   49s

我们可以看到，当我们删除掉这个文件之后，他请求不到index.html文件了，所以这个容器会重启

3. tcpSocket

这个方式就更加简单了，探针会对你定义的端口发起tcp连接，如果可以不能正常进行三次握手，那么就会重启容器

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   labels:
  5.     run: nginx
  6.   name: nginx
  7. spec:
  8.   containers:
  9.   - image: nginx
  10.     imagePullPolicy: IfNotPresent
  11.     name: nginx
  12.     resources: {}
  13.     livenessProbe:
  14.       tcpSocket:
  15.         port: 81
  16.       initialDelaySeconds: 2
  17.       periodSeconds: 2
  18.   dnsPolicy: ClusterFirst
  19.   restartPolicy: Always
  20. status: {}

我们直接将80端口改为81端口，nginx使用的是80端口提供服务，我们现在让他去尝试连接81端口肯定是连接不上的，我们来看看效果

  1. [root@master k8s]# kubectl apply -f liveness-probe.yaml 
  2. pod/nginx created
  3. [root@master k8s]# kubectl get pods
  4. NAME    READY   STATUS    RESTARTS   AGE
  5. nginx   1/1     Running   0          8s
  6. [root@master k8s]# kubectl get pods
  7. NAME    READY   STATUS    RESTARTS     AGE
  8. nginx   1/1     Running   1 (1s ago)   9s

这种方式比较简单，就是直接对你指定的端口发起tcp连接，能连上就代表正常，连不上那就重启

这就是探针的3种检测方式了，接下来看就绪探针

readness-probe 就绪探针

这种探针跟liveness探针的区别就是，liveness会重启容器，这个探针不会，这个探针就是说，如果你的deployment的副本数为3，我这个探针依旧是检测你的index.html文件，如果这个文件不存在的话，那么我就不会将流量转发到这个pod上了，并不会重启容器，我们来看看

这个探针依旧是那3种方式

1. exec

我们这里使用deployment的方式来操作，看的更加直观一点

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4.   creationTimestamp: null
  5.   labels:
  6.     app: deploy1
  7.   name: deploy1
  8. spec:
  9.   replicas: 3
  10.   selector:
  11.     matchLabels:
  12.       app: deploy1
  13.   strategy: {}
  14.   template:
  15.     metadata:
  16.       creationTimestamp: null
  17.       labels:
  18.         app: deploy1
  19.     spec:
  20.       containers:
  21.       - image: nginx
  22.         imagePullPolicy: IfNotPresent
  23.         name: nginx
  24.         resources: {}
  25.         readinessProbe:
  26.           exec:
  27.             command: ["test", "-f", "/usr/share/nginx/html/index.html"]
  28.           initialDelaySeconds: 2
  29.           periodSeconds: 2
  30. status: {}

我们接下来的操作就是，创建这个控制器，然后进入到每个容器里面修改他的index.html文件的内容，最后再去删除某个容器的index.html文件，尝试访问

  1. # 我们先将这个控制器创建出来
  2. [root@master k8s]# kubectl apply -f deploy1.yaml 
  3. deployment.apps/deploy1 created
  4. [root@master k8s]# kubectl get pods -owide
  5. NAME                       READY   STATUS    RESTARTS   AGE   IP               NODE    NOMINATED NODE   READINESS GATES
  6. deploy1-869c888fcd-nkqcr   1/1     Running   0          7s    10.244.104.9     node2   <none>           <none>
  7. deploy1-869c888fcd-qpcj6   1/1     Running   0          7s    10.244.104.12    node2   <none>           <none>
  8. deploy1-869c888fcd-s9gjk   1/1     Running   0          7s    10.244.166.149   node1   <none>           <none>
  9. # 然后我们将服务暴露出去
  10. [root@master k8s]# kubectl expose deployment deploy1 --port=80 --target-port=80 --type=NodePort
  11. service/deploy1 exposed
  12. [root@master k8s]# kubectl get svc
  13. NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
  14. deploy1      NodePort    10.106.239.238   <none>        80:31268/TCP   33s
  15. kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP        30d
  16. # 我们将每个容器的index文件改掉
  17. [root@master k8s]# kubectl exec -it deploy1-869c888fcd-nkqcr -- bash
  18. root@deploy1-869c888fcd-nkqcr:/# echo host01 > /usr/share/nginx/html/index.html
  19. [root@master k8s]# kubectl exec -it deploy1-869c888fcd-qpcj6 -- bash
  20. root@deploy1-869c888fcd-qpcj6:/# echo host02 > /usr/share/nginx/html/index.html
  21. [root@master k8s]# kubectl exec -it deploy1-869c888fcd-s9gjk -- bash
  22. root@deploy1-869c888fcd-s9gjk:/# echo host03 > /usr/share/nginx/html/index.html 
  23. root@deploy1-869c888fcd-s9gjk:/# exit
  24. # 然后我们通过svc暴露出来的端口来访问
  25. [root@master k8s]# curl localhost:31268
  26. host03
  27. [root@master k8s]# curl localhost:31268
  28. host02
  29. [root@master k8s]# curl localhost:31268
  30. host01
  31. # 我们可以发现他会将流量转发到每一个pod上，此时我们来删除第一个容器的index.html文件
  32. [root@master k8s]# kubectl exec -it deploy1-869c888fcd-nkqcr -- rm -f /usr/share/nginx/html/index.html
  33. [root@master k8s]# kubectl get pods
  34. NAME                       READY   STATUS    RESTARTS   AGE
  35. deploy1-869c888fcd-nkqcr   0/1     Running   0          9m42s
  36. deploy1-869c888fcd-qpcj6   1/1     Running   0          9m42s
  37. deploy1-869c888fcd-s9gjk   1/1     Running   0          9m42s

这个时候我们看到第一个pod的read状态是0/1了，我们再来尝试访问

  1. [root@master k8s]# curl localhost:31268
  2. host02
  3. [root@master k8s]# curl localhost:31268
  4. host02
  5. [root@master k8s]# curl localhost:31268
  6. host02
  7. [root@master k8s]# curl localhost:31268
  8. host03

可以看到我们现在无论怎么访问他都不会将流量转发到这个pod上了

2. httpGet

这种方式的定义跟之前的定义方式一样

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4.   creationTimestamp: null
  5.   labels:
  6.     app: deploy1
  7.   name: deploy1
  8. spec:
  9.   replicas: 3
  10.   selector:
  11.     matchLabels:
  12.       app: deploy1
  13.   strategy: {}
  14.   template:
  15.     metadata:
  16.       creationTimestamp: null
  17.       labels:
  18.         app: deploy1
  19.     spec:
  20.       containers:
  21.       - image: nginx
  22.         imagePullPolicy: IfNotPresent
  23.         name: nginx
  24.         resources: {}
  25.         readinessProbe:
  26.           httpGet:
  27.             path: /index.html
  28.             port: 80
  29.           initialDelaySeconds: 2
  30.           periodSeconds: 2
  31. status: {}
  1. [root@master k8s]# kubectl apply -f deploy1.yaml 
  2. deployment.apps/deploy1 created
  3. [root@master k8s]# kubectl get pods
  4. NAME                       READY   STATUS    RESTARTS   AGE
  5. deploy1-6757fdb6d9-dl7fc   1/1     Running   0          3s
  6. deploy1-6757fdb6d9-mrttl   1/1     Running   0          3s
  7. deploy1-6757fdb6d9-zkj5b   1/1     Running   0          3s

我们还是同样删除一个容器里的index.html，其他效果就不演示了，只看他的状态就知道了

  1. [root@master k8s]# kubectl exec -it deploy1-6757fdb6d9-dl7fc -- rm -f /usr/share/nginx/html/index.html
  2. [root@master k8s]# kubectl get pods
  3. NAME                       READY   STATUS    RESTARTS   AGE
  4. deploy1-6757fdb6d9-dl7fc   1/1     Running   0          78s
  5. deploy1-6757fdb6d9-mrttl   1/1     Running   0          78s
  6. deploy1-6757fdb6d9-zkj5b   1/1     Running   0          78s
  7. [root@master k8s]# kubectl get pods
  8. NAME                       READY   STATUS    RESTARTS   AGE
  9. deploy1-6757fdb6d9-dl7fc   0/1     Running   0          79s
  10. deploy1-6757fdb6d9-mrttl   1/1     Running   0          79s
  11. deploy1-6757fdb6d9-zkj5b   1/1     Running   0          79s

可以看得到，ready那里已经变成0/1了也就是他不会在有流量转发到他这里了

3. tcpSocket

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4.   creationTimestamp: null
  5.   labels:
  6.     app: deploy1
  7.   name: deploy1
  8. spec:
  9.   replicas: 3
  10.   selector:
  11.     matchLabels:
  12.       app: deploy1
  13.   strategy: {}
  14.   template:
  15.     metadata:
  16.       creationTimestamp: null
  17.       labels:
  18.         app: deploy1
  19.     spec:
  20.       containers:
  21.       - image: nginx
  22.         imagePullPolicy: IfNotPresent
  23.         name: nginx
  24.         resources: {}
  25.         readinessProbe:
  26.           tcpSocket:
  27.             port: 80
  28.           initialDelaySeconds: 2
  29.           periodSeconds: 2
  30. status: {}

也是这样定义的，这个我就不演示了，效果跟前俩是一样的，tcp连接不上的话ready就会变成0

综述：虽然我这里全部都是使用nginx镜像，但是我们一般会使用exec来检测配置文件是否存在，使用httpGet来检测一些网站类的容器，使用tcpSocket来对开放了端口的容器进行检测

原文链接：https://www.cnblogs.com/fsdstudy/p/18010183

 友情链接：直通硅谷 　点职佳 　北美留学生论坛

Kubernetes热门文章

  • 【Azure K8S | AKS】在AKS集群中创建 PVC(PersistentVolumeClaim)和 PV(PersistentVolume) 示例
  • 无法访问k8s.gcr.io下载镜像问题解决办法
  • Kubernetes(k8s)访问控制：身份认证
  • Prometheus服务发现之kubernetes_sd_config
  • Arthas排查Kubernetes中应用频繁挂掉重启异常
  • Kubernetes客户端认证——基于CA证书的双向认证方式
  • k8s中kubeconfig的配置以及使用详解
  • Centos7 安装部署 Kubernetes(k8s) 高可用集群
  • Kubernetes 证书详解
  • 案例分享-full gc导致k8s pod重启

    • Kubernetes推荐文章

  • 修改kubeadm证书过期时间及更新k8s集群证书
  • 探究kubernetes 探针参数periodSeconds和timeoutSeconds
  • 从 Helm 到 Operator：Kubernetes应用管理的进化
  • 深入理解Prometheus: Kubernetes环境中的监控实践
  • k8s集群搭建及对一些组件的简单理解（二）
  • K8s高可用集群二进制部署-V1.20
  • Kubernetes容器生命周期 —— 钩子函数详解（postStart、preStop）
  • Kubernetes 审计（Auditing）
  • Thanos解码：打造企业级云原生监控解决方案
  • k8s使用rbd作为存储

    • 本站QQ群：前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

    W3xue 的所有内容仅供测试，对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
    关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接（目前9元/月）请联系QQ：27243702 沸活量
    皖ICP备17017327号-2　皖公网安备34020702000426号