kubernetes的三种探针

startupprobe: k8s1.16版本后新加的探测方式,用于判断容器内应用程序是否已经启动,如果配置了startuprobe,就会先禁用其他的探测,直到它成功为止,成功后将不再进行探测。

ReadinessProbe: 一般用于探测容器内的程序是否健康,它的返回值如果为success,那么就代表这个容器已经完成启动,并且程序已经是可以接受流量的状态.

LivenessProbe:用于探测容器是否运行,如果探测失败,kubelet会根据配置的重启策略进行相应的处理,如果没有配置该探针,默认就是success!

pod探针的检测方式

startupProbe   启动检查
livenessProbe 存活检查
readinessProbe 就绪检查 # startupProbe 启动检查
----------------------------------
startupProbe: #健康检查方式:[readinessProbe,livenessProbe,StartupProbe]
failureThreshold: 3 #检测失败3次表示未就绪
httpGet: #请求方式
path: /ready #请求路径
port: 8182 #请求端口
scheme: HTTP #请求协议
periodSeconds: 10 #检测间隔
successThreshold: 1 #检查成功为2次表示就绪
timeoutSeconds: 1 #检测失败1次表示未就绪
---------------------------------- # livenessProbe 存活检查 #案例1:
----------------------------------
livenessProbe: #健康检查方式:[readinessProbe,livenessProbe,StartupProbe]
failureThreshold: 5 #检测失败5次表示未就绪
httpGet: #请求方式
path: /health #请求路径
port: 8080 #请求端口
scheme: HTTP #请求协议
initialDelaySeconds: 60 #初始化时间
periodSeconds: 10 #检测间隔
successThreshold: 1 #检查成功为2次表示就绪
timeoutSeconds: 5 #检测失败1次表示未就绪 livenessProbe: #健康检查方式:[readinessProbe,livenessProbe,StartupProbe]
failureThreshold: 5 #检测失败5次表示未就绪
httpGet: #请求方式
path: /health #请求路径
port: 8080 #请求端口
initialDelaySeconds: 60 #初始化时间
periodSeconds: 10 #检测间隔
successThreshold: 1 #检查成功为2次表示就绪
timeoutSeconds: 5 #检测失败1次表示未就绪 ---------------------------------- 案例2:
----------------------------------
livenessProbe:
httpGet:
path: /healthz
port: liveness-port
failureThreshold: 1
periodSeconds: 60
terminationGracePeriodSeconds: 60 #宽限时间,不能用于设置就绪态探针,它将被 API 服务器拒绝。
---------------------------------- # readinessProbe 就绪检查
----------------------------------
案例1[get方式]:
readinessProbe: #健康检查方式:[readinessProbe,livenessProbe,StartupProbe]
failureThreshold: 3 #检测失败3次表示未就绪
httpGet: #请求方式
path: /ready #请求路径
port: 8181 #请求端口
scheme: HTTP #请求协议
periodSeconds: 10 #检测间隔
successThreshold: 1 #检查成功为2次表示就绪
timeoutSeconds: 1 #检测失败1次表示未就绪 案例2 [检查文件内容]:
readinessProbe: #检查方式
exec: #使用命令检查
command: #指令
- cat #指令
- /etc/hosts #指令
initialDelaySeconds: 5 #容器启动后要等待多少秒后存活和就绪探测器才被初始化,默认是 0 秒,最小值是 0。
timeoutSeconds: 2 #检测失败1次表示未就绪
successThreshold: 3 #检查成功为2次表示就绪
failureThreshold: 2 #检测失败重试次数
periodSeconds: 5 #检测间隔
---------------------------------- initialDelaySeconds:容器启动后要等待多少秒后存活和就绪探测器才被初始化,默认是 0 秒,最小值是 0。
periodSeconds:执行探测的时间间隔(单位是秒)。默认是 10 秒。最小值是 1。
timeoutSeconds:探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。
successThreshold:探测器在失败后,被视为成功的最小连续成功数。默认值是 1 存活和启动探测的这个值必须是1 最小值是 1
failureThreshold:当探测失败时,Kubernetes 的重试次数。 存活探测情况下的放弃就意味着重新启动容器。 就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。 #注意:
配置了 startupProbe 之后,livenessProbe和readinessProbe参数将会被暂时禁用,直到程序被检测到启动完成了livenessProbe,readinessProbe才会被启用
在程序启动较慢的时候可以配置startupProbe参数。

启动案例

StartupProbe案例[检测容器内进程是否完成启动]

参考文档: https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

apiVersion: v1 # 必选,API的版本号
kind: Pod # 必选,类型Pod
metadata: # 必选,元数据
name: nginx01 # 必选,符合RFC 1035规范的Pod名称
labels: # 可选,标签选择器,一般用于过滤和区分Pod
app: nginx
role: frontend # 可以写多个
annotations: # 可选,注释列表,可以写多个
app: nginx
spec: # 必选,用于定义容器的详细信息
containers: # 必选,容器列表
- name: nginx01 # 必选,符合RFC 1035规范的容器名称
image: nginx:latest # 必选,容器所用的镜像的地址
imagePullPolicy: Always # 可选,镜像拉取策略
command: # 可选,容器启动执行的命令
- nginx
- -g
- "daemon off;"
workingDir: /usr/share/nginx/html # 可选,容器的工作目录
ports: # 可选,容器需要暴露的端口号列表
- name: http # 端口名称
containerPort: 80 # 端口号
protocol: TCP # 端口协议,默认TCP
env: # 可选,环境变量配置列表
- name: TZ # 变量名
value: Asia/Shanghai # 变量的值
- name: LANG
value: en_US.utf8
startupProbe: # 可选,检测容器内进程是否完成启动。注意三种检查方式同时只能使用一种。
httpGet: # httpGet检测方式,生产环境建议使用httpGet实现接口级健康检查,健康检查由应用程序提供。
path: /api/successStart # 检查路径
port: 80
restartPolicy: Always # 可选,默认为Always
root@k8s-master01[23:26:10]:~$ kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-startupprobe 0/1 Running 1 79s 创建后会无法启动,原因是无法检测到这个地址,通过日志可以看到:
2021/06/25 23:26:02 [error] 7#7: *3 open() "/usr/share/nginx/html/api/successStart" failed (2: No such file or directory), client: 192.168.3.84, server: localhost, request: "GET /api/successStart HTTP/1.1", host: "172.17.125.25:80"

ReadinessProbe案例 [可以提供服务的状态]

参考文档: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

apiVersion: v1 # 必选,API的版本号
kind: Pod # 必选,类型Pod
metadata: # 必选,元数据
name: nginx-read # 必选,符合RFC 1035规范的Pod名称
labels: # 可选,标签选择器,一般用于过滤和区分Pod
app: nginx
role: frontend # 可以写多个
annotations: # 可选,注释列表,可以写多个
app: nginx
spec: # 必选,用于定义容器的详细信息
containers: # 必选,容器列表
- name: nginx-read # 必选,符合RFC 1035规范的容器名称
image: nginx:latest # 必选,容器所用的镜像的地址
imagePullPolicy: Always # 可选,镜像拉取策略
command: # 可选,容器启动执行的命令
- nginx
- -g
- "daemon off;"
workingDir: /usr/share/nginx/html # 可选,容器的工作目录
ports: # 可选,容器需要暴露的端口号列表
- name: http # 端口名称
containerPort: 80 # 端口号
protocol: TCP # 端口协议,默认TCP
env: # 可选,环境变量配置列表
- name: TZ # 变量名
value: Asia/Shanghai # 变量的值
- name: LANG
value: en_US.utf8
readinessProbe:
httpGet:
path: /
port: 80
restartPolicy: Always # 可选,默认为Always
kubectl apply -f  readinessProbe-pod.yaml

LivenessProbe检测容器中的应用是否正常运行

参考文档:https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

apiVersion: v1 # 必选,API的版本号
kind: Pod # 必选,类型Pod
metadata: # 必选,元数据
name: nginx-live # 必选,符合RFC 1035规范的Pod名称
labels: # 可选,标签选择器,一般用于过滤和区分Pod
app: nginx
role: frontend # 可以写多个
annotations: # 可选,注释列表,可以写多个
app: nginx
spec: # 必选,用于定义容器的详细信息
containers: # 必选,容器列表
- name: nginx-live # 必选,符合RFC 1035规范的容器名称
image: nginx:latest # 必选,容器所用的镜像的地址
imagePullPolicy: Always # 可选,镜像拉取策略
command: # 可选,容器启动执行的命令
- nginx
- -g
- "daemon off;"
workingDir: /usr/share/nginx/html # 可选,容器的工作目录
ports: # 可选,容器需要暴露的端口号列表
- name: http # 端口名称
containerPort: 80 # 端口号
protocol: TCP # 端口协议,默认TCP
env: # 可选,环境变量配置列表
- name: TZ # 变量名
value: Asia/Shanghai # 变量的值
- name: LANG
value: en_US.utf8
livenessProbe:
httpGet:
path: /
port: 80
kubectl apply -f  livenessProbe.yaml

#检查 nginx-live pod是否正常
root@k8s-master01[23:41:31]:~$ kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-live 1/1 Running 0 35s
nginx-read 1/1 Running 0 10m
nginx-startupprobe 0/1 Running 9 16m

混合配置

readinessProbe+livenessProbe案例

apiVersion: v1 # 必选,API的版本号
kind: Pod # 必选,类型Pod
metadata: # 必选,元数据
name: nginx-read # 必选,符合RFC 1035规范的Pod名称
labels: # 可选,标签选择器,一般用于过滤和区分Pod
app: nginx
role: frontend # 可以写多个
annotations: # 可选,注释列表,可以写多个
app: nginx
spec: # 必选,用于定义容器的详细信息
containers: # 必选,容器列表
- name: nginx-read # 必选,符合RFC 1035规范的容器名称
image: nginx:latest # 必选,容器所用的镜像的地址
imagePullPolicy: Always # 可选,镜像拉取策略
command: # 可选,容器启动执行的命令
- nginx
- -g
- "daemon off;"
workingDir: /usr/share/nginx/html # 可选,容器的工作目录
ports: # 可选,容器需要暴露的端口号列表
- name: http # 端口名称
containerPort: 80 # 端口号
protocol: TCP # 端口协议,默认TCP
env: # 可选,环境变量配置列表
- name: TZ # 变量名
value: Asia/Shanghai # 变量的值
- name: LANG
value: en_US.utf8
readinessProbe:
exec:
command:
- cat
- /etc/hosts
initialDelaySeconds: 5
timeoutSeconds: 2
successThreshold: 3
failureThreshold: 2
periodSeconds: 5 livenessProbe: #健康检查方式:[readinessProbe,livenessProbe,StartupProbe]
failureThreshold: 5 #检测失败5次表示未就绪
httpGet: #请求方式
path: /health #请求路径
port: 8080 #请求端口
scheme: HTTP ##请求协议
initialDelaySeconds: 60 #初始化时间
periodSeconds: 10 #检测间隔
successThreshold: 1 #检查成功为2次表示就绪
timeoutSeconds: 5 #检测失败1次表示未就绪

startupprobe+readinessProbe+ 混合案例

apiVersion: v1                # 必选,API的版本号
kind: Pod # 必选,类型Pod
metadata: # 必选,元数据
name: read-startup # 必选,符合RFC 1035规范的Pod名称
labels: # 可选,标签选择器,一般用于过滤和区分Pod
app: nginx
role: frontend # 可以写多个
annotations: # 可选,注释列表,可以写多个
app: nginx
spec: # 必选,用于定义容器的详细信息
containers: # 必选,容器列表
- name: read-startup # 必选,符合RFC 1035规范的容器名称
image: nginx:latest # 必选,容器所用的镜像的地址
imagePullPolicy: Always # 可选,镜像拉取策略
command: # 可选,容器启动执行的命令
- nginx
- -g
- "daemon off;"
workingDir: /usr/share/nginx/html # 可选,容器的工作目录
ports: # 可选,容器需要暴露的端口号列表
- name: http # 端口名称
containerPort: 80 # 端口号
protocol: TCP # 端口协议,默认TCP
env: # 可选,环境变量配置列表
- name: TZ # 变量名
value: Asia/Shanghai # 变量的值
- name: LANG
value: en_US.utf8
readinessProbe:
exec:
command:
- cat
- /etc/hosts
initialDelaySeconds: 5
timeoutSeconds: 2
successThreshold: 3
failureThreshold: 2
periodSeconds: 5 startupProbe:
httpGet:
path: /
port: 80
failureThreshold: 30
periodSeconds: 10

startupprobe+readinessProbe+ livenessProbe混合案例

apiVersion: v1                # 必选,API的版本号
kind: Pod # 必选,类型Pod
metadata: # 必选,元数据
name: read-startup # 必选,符合RFC 1035规范的Pod名称
labels: # 可选,标签选择器,一般用于过滤和区分Pod
app: nginx
role: frontend # 可以写多个
annotations: # 可选,注释列表,可以写多个
app: nginx
spec: # 必选,用于定义容器的详细信息
containers: # 必选,容器列表
- name: read-startup # 必选,符合RFC 1035规范的容器名称
image: nginx:latest # 必选,容器所用的镜像的地址
imagePullPolicy: Always # 可选,镜像拉取策略
command: # 可选,容器启动执行的命令
- nginx
- -g
- "daemon off;"
workingDir: /usr/share/nginx/html # 可选,容器的工作目录
ports: # 可选,容器需要暴露的端口号列表
- name: http # 端口名称
containerPort: 80 # 端口号
protocol: TCP # 端口协议,默认TCP
env: # 可选,环境变量配置列表
- name: TZ # 变量名
value: Asia/Shanghai # 变量的值
- name: LANG
value: en_US.utf8
readinessProbe:
exec:
command:
- cat
- /etc/hosts
initialDelaySeconds: 5
timeoutSeconds: 2
successThreshold: 3
failureThreshold: 2
periodSeconds: 5 startupProbe:
httpGet:
path: /
port: 80
failureThreshold: 30
periodSeconds: 10 livenessProbe:
httpGet:
path: /healthz
port: 80
failureThreshold: 1
periodSeconds: 10

检测时间计算

准确的时间计算:每次检查的间隔是10秒,最长超时时间是5秒,也就是单次检查应该是10 + 5 = 15秒(periodSeconds + timeoutSeconds),并不是10 * 5
所以最长的重启时间为(10 + 5)* 5
(periodSeconds + timeoutSeconds) * failureThreshold 此时又分为了两种情况:
1. 首次启动时:最长重启时间需要加上initialDelaySeconds,因为需要等待initialDelaySeconds秒后才会执行健康检查。最长重启时间:(periodSeconds + timeoutSeconds) * failureThreshold + initialDelaySeconds
2. 程序启动完成后:
此时不需要计入initialDelaySeconds,最长重启时间:(periodSeconds + timeoutSeconds) * failureThreshold

kubernetes的三种探针startupprobe,ReadinessProbe,LivenessProbe记录的更多相关文章

  1. Kubernetes的三种探针

    k8s支持存活livenessProbe和就绪readinessProbe两种探针 两种探针都支持以下三种方式 1.exec 通过执行shell命令的方式,判断退出状态码是否是0 示例 exec: c ...

  2. Kubernetes的三种外部访问方式:NodePort、LoadBalancer和Ingress(转发)

    原文 http://cloud.51cto.com/art/201804/570386.htm Kubernetes的三种外部访问方式:NodePort.LoadBalancer和Ingress 最近 ...

  3. 一个简单的例子理解Kubernetes的三种IP地址类型

    很多Kubernetes的初学者对Kubernetes里面三种不同的IP地址和工作机制理解得不是很清楚. 本文我们通过一个最简单的例子来学习. 用如下命令行创建一个基于nginx的deployment ...

  4. Kubernetes service 三种类型/NodePort端口固定

    Kubernetes service 三种类型 • ClusterIP:默认,分配一个集群内部可以访问的虚拟IP(VIP)• NodePort:在每个Node上分配一个端口作为外部访问入口• Load ...

  5. Kubernetes的三种外部访问方式:NodePort、LoadBalancer和Ingress

    NodePort,LoadBalancer和Ingress之间的区别.它们都是将集群外部流量导入到集群内的方式,只是实现方式不同. ClusterIP ClusterIP服务是Kubernetes的默 ...

  6. 在本地运行Kubernetes的3种主流方式

    作者简介 Chris Tozzi,曾担任记者和Linux管理员.对开源技术.敏捷基础架构以及网络问题兴趣浓厚.目前担任高级内容编辑,并且是Fixate IO的DevOps分析师. 原文链接: http ...

  7. 不吹不黑,今天我们来聊一聊 Kubernetes 落地的三种方式

    作者 | 王国梁  Kubernetes 社区成员与项目维护者原文标题<Kubernetes 应用之道:让 Kubernetes落地的"三板斧">,首发于知乎专栏:进击 ...

  8. Kubernetes 对象管理的三种方式

    Kubernetes 中文文档 1. Kubernetes 对象管理的三种方式对比 Kubernetes 中的对象管理方式,根据对象配置信息的位置不同可以分为两大类: 命令式:对象的参数通过命令指定 ...

  9. Kubernetes系列三:二进制安装Kubernetes环境

    安装环境: # 三个节点信息 192.168.31.11 主机名:env11 角色:部署Master节点/Node节点/ETCD节点 192.168.31.12 主机名:env12 角色:部署Node ...

  10. Kubernetes 存活、就绪探针

    在设计关键任务.高可用应用程序时,弹性是要考虑的最重要因素之一. 当应用程序可以快速从故障中恢复时,它便具有弹性. 云原生应用程序通常设计为使用微服务架构,其中每个组件都位于容器中.为了确保Kuber ...

随机推荐

  1. UML 哲学之道——启航篇[一]

    前言 简单去介绍一下uml的哲学之道也是自我整理之道. 正文 什么是uml,全程是统一建模语言(unified modeling language),简单的说就是用图形来表示文档. 是描述构造和文档化 ...

  2. List拖拽功能的实现

    概述   如何在HarmonyOS应用中实现一个可拖拽的列表组件,通过这个组件,用户可以拖动列表中的项并将其放置在新的位置,实现列表的动态排序.   核心功能   列表初始化:创建并填充列表数据. 拖 ...

  3. vue-cli4.0 (vue3.0 的脚手架)

    前言: 这个搭建脚手架的话实际是我们创建一个新项目的第一步,当然,现在脚手架4.0都出来了,经过使用后发现跟我们之前的3.0使用方法是答题一样的,其中用vue-cli3.0来搭建我们的项目的话又分为两 ...

  4. numpy函数向量化,np.vectorize

    import numpy as np import time def myfunc(a, b): if a>b: return a-b else: return a+b vfunc = np.v ...

  5. CF1832B Maximum Sum 题解

    [题目描述] 给定一个长度为 \(n\) 的数列,其中每个元素互不相同,进行 \(k\) 次操作,每次可以选择删除序列中最小的两个数或最大的一个数.求操作后剩余数的和的最大值. [思路] 我们构造一组 ...

  6. Apache Flink 在汽车之家的应用与实践

    ​简介: 汽车之家如何基于 Flink 上线了 AutoStream 平台并持续打磨. 本文整理自汽车之家实时计算平台负责人邸星星在 Flink Forward Asia 2020 分享的议题< ...

  7. HTML中元素分类与对应的CSS样式特点

    元素就是标签,布局中常用的有三种标签,块元素.内联元素.内联块元素,了解这三种元素的特性,才能熟练的进行页面布局. 块元素 块元素,也可以称为行元素,布局中常用的标签如:div.p.ul.li.h1~ ...

  8. Quill富文本编辑器的实践 - DevUI

    DevUI 是一款面向企业中后台产品的开源前端解决方案,它倡导沉浸.灵活.至简的设计价值观,提倡设计者为真实的需求服务,为多数人的设计,拒绝哗众取宠.取悦眼球的设计.如果你正在开发 ToB 的工具类产 ...

  9. dotnet 给 NuGet 包加上 Aliases 别名解决类型冲突

    有时某个相同命名空间相同名字的类型被两个不同的 NuGet 包定义了,尽管这是非常少见的事情,咱需要使用到其中的一个 NuGet 包的类型,但默认情况下将会因为类型冲突而构建不通过.本文将告诉大家如何 ...

  10. 2018-5-28-WPF-Process.Start-出现-Win32Exception-异常

    title author date CreateTime categories WPF Process.Start 出现 Win32Exception 异常 lindexi 2018-05-28 10 ...