- 13GPP 38.311 NR Radio Resource Control (RRC) protocol specification_3gpp ts 38.331
- 2鸿蒙迎来纯血版本，你还不来学习一下
- 3千万流量秒杀系统-过载保护：如何通过熔断和限流解决流量过载问题？_微服务过载保护
- 4android ubuntu 桌面快捷方式,[转] 给ubuntu中的软件设置desktop快捷方式（以android studio为例）...
- 5netty实现webSocket握手处理并添加响应头_netty websocket 握手
- 6Windows安装DVWA（全过程）_windows搭建dvwa
- 7图像处理代码编写三：基于C++的高斯滤波程序实现_高斯滤波c++代码
- 8用通俗易懂的方式讲解：一文搞懂大模型 Prompt Engineering（提示工程）_prompt engineering 的原理
- 9Android针对视频部分截屏是黑色的解决办法_andorid 截屏视频控件是黑的
- 10限流算法总结：计数器、滑动窗口、漏桶算法、令牌桶算法（抄的）_滑动窗口限流算法
存活探针(Liveness)、就绪探针(Readiness)、启动探针(Startup)_livenessprobe
赞
踩
存活探针(Liveness)、就绪探针(Readiness)、启动探针(Startup)
就绪探针与存活探针的最大区别
存活探针是将检查失败的容器杀死，创建新的启动容器来保持pod正常工作；
就绪探针是，当就绪探针检查失败，并不重启容器，而是将pod移出服务，就绪探针确保服务中的pod都是可用的，确保客户端只与正常的pod交互并且客户端永远不会知道系统存在问题。
一、存活探针（Liveness Probe）
存活探针
用于判断容器是否存活（running状态），如果LivenessProbe探针探测到容器不健康，则kubelet杀掉该容器，并根据容器的重启策略做相应的处理。如果一个容器不包含LivenessProbe探针，则kubelet认为该容器的LivenessProbe探针返回的值永远是“Success”。
探测机制
Kubernetes支持如下三种探测机制。
-
HTTP GET：向容器发送HTTP GET请求，如果Probe收到2xx或3xx，说明容器是健康的。
-
TCP Socket：尝试与容器指定端口建立TCP连接，如果连接成功建立，说明容器是健康的。
-
Exec：Probe执行容器中的命令并检查命令退出的状态码，如果状态码为0则说明容器是健康的。
HTTP GET (生产环境建议使用 httpGet探针 进行探测)
HTTP GET方式是最常见的探测方法，其具体机制是向容器发送HTTP GET请求，如果Probe收到2xx或3xx，说明容器是健康的，定义方法如下所示。
apiVersion: apps/v1 kind: ReplicaSet metadata: name: rs-nginx-http namespace: default spec: replicas: 3 selector: matchLabels: app: nginx-rs matchExpressions: - {key: env, operator: In, values: [dev]} template: metadata: labels: app: nginx-rs env: dev spec: containers: - image: nginx:1.7.9 name: nginx-container ports: - containerPort: 80 livenessProbe: #为容器定义一个存活探针 httpGet: #探针类型为httpGet探针 # host: 10.244.0.49 #指定主机，默认是pod的ip，一般省略不写 path: / #路径 port: 80 #端口 initialDelaySeconds: 15 #初始延时时间为15s periodSeconds: 5 #探测周期 timeoutSeconds: 2 #超时时间 failureThreshold: 9 #失败次数
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
存活探针属性说明
initialDelaySeconds：表示在容器启动后延时多久秒才开始探测；
periodSeconds：表示执行探测的频率，即间隔多少秒探测一次，默认间隔周期是10秒，最小1秒；
timeoutSeconds：表示探测超时时间，默认1秒，最小1秒，表示容器必须在超时时间范围内做出响应，否则视为本次探测失败；
successThreshold：表示最少连续探测成功多少次才被认定为成功，默认是1，对于liveness必须是1，最小值是1；
failureThreshold：表示连续探测失败多少次才被认定为失败，默认是3，连续3次失败，k8s 将根据pod重启策略对容器做出决定；
- 1
- 2
- 3
- 4
- 5
注意：定义存活探针时，一定要设置initialDelaySeconds属性，该属性为初始延时，如果不设置，默认容器启动时探针就开始探测了，这样可能会存在应用程序还未启动就绪，就会导致探针检测失败，k8s就会根据pod重启策略杀掉容器然后再重新创建容器的莫名其妙的问题。
在生产环境中，一定要定义一个存活探针。
exec探针
exec探针是通过在容器内执行shell命令，根据命令退出状态码是否为0判定成功失败；
[root@master ~]# cat rs_nginx.yaml apiVersion: apps/v1 kind: ReplicaSet metadata: name: rs-nginx-http namespace: default spec: replicas: 3 selector: matchLabels: app: nginx-rs matchExpressions: - {key: env, operator: In, values: [dev]} template: metadata: labels: app: nginx-rs env: dev spec: containers: - image: nginx:1.7.9 name: nginx-container ports: - containerPort: 80 livenessProbe: #定义探针 exec: #探针类型为exec探针 command: - cat #表示cat /usr/share/nginx/html/index.html文件，根据命令执行 - /usr/share/nginx/html/index.html #结果返回状态是否非0来表示探针状态 initialDelaySeconds: 8 #初始延时，表示容器启动15秒后才开始探测 periodSeconds: 3 #探测周期，3秒探测一次 timeoutSeconds: 2 #超时时间为2秒，表示必须2秒内做出回应，否则将视本次探测失败 failureThreshold: 1 #连续失败次数，表示连续失败1次就定义为失败，k8s将根据pod重启机制 #做出是否重启容器的就决定 #下面将进入容器内部删除 /usr/share/nginx/html/index.html文件，看探针是否生效 [root@master ~]# kubectl exec rs-nginx-http-2rng2 -it -- bash #进入容器 root@rs-nginx-http-2rng2:/# rm -rf /usr/share/nginx/html/index.html #删除/usr/share/nginx/html/index.html root@rs-nginx-http-2rng2:/# exit #退出容器 [root@master ~]# kubectl get pods #查看pod NAME READY STATUS RESTARTS AGE pod/rs-nginx-http-2rng2 1/1 Running 1 (11s ago) 74s #发现pod的容器重启过一次 pod/rs-nginx-http-bgr4m 1/1 Running 0 74s pod/rs-nginx-http-cv9bv 1/1 Running 0 74s [root@master ~]# kubectl describe pod/rs-nginx-http-2rng2 #查看pod信息,可以看出探针探测失败，容器被重新启动了 ................ Restart Count: 1 Liveness: exec [cat /usr/share/nginx/html/index.html] delay=8s timeout=2s period=3s #success=1 #failure=1 ................................ Normal Pulled 9m32s (x2 over 10m) kubelet Container image "nginx:1.7.9" already present on machine Normal Created 9m32s (x2 over 10m) kubelet Created container nginx-container Warning Unhealthy 9m32s kubelet Liveness probe failed: cat: /usr/share/nginx/html/index.html: No such file or directory Normal Killing 9m32s kubelet Container nginx-container failed liveness probe, will be restarted Normal Started 9m31s (x2 over 10m) kubelet Started container nginx-container [root@master ~]#
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
tcpSocket探针
tcpSocket探针，根据容器的IP地址、端口发起tcp Socket链接，探测是否能成功与容器的端口建立tcp Socket链接；
[root@master ~]# cat rs_nginx.yaml apiVersion: apps/v1 kind: ReplicaSet metadata: name: rs-nginx-http namespace: default spec: replicas: 3 selector: matchLabels: app: nginx-rs matchExpressions: - {key: env, operator: In, values: [dev]} template: metadata: labels: app: nginx-rs env: dev spec: containers: - image: nginx:1.7.9 name: nginx-container ports: - containerPort: 80 livenessProbe: #定义存活探针 tcpSocket: #探针类型为tcpSocket探针 # host: 10.244.0.49 #指定主机，默认是pod的ip，一般省略不写 port: 80 #探测与80端口是否能成功建立tcp链接 initialDelaySeconds: 8 periodSeconds: 3 timeoutSeconds: 2 failureThreshold: 1
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
二、就绪探针（Readiness Probe）
就绪探针
用于判断容器是否启动完成（ready状态），可以接收请求。如果ReadinessProbe探针检测到失败，则Pod的状态被修改。Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的Endpoint。
我们知道，当一个pod启动后，就会立即加入service的endpoint ip列表中，并开始接收到客户端的链接请求，假若此时pod中的容器的业务进程还没有初始化完毕，那么这些客户端链接请求就会失败，为了解决这个问题，kubernetes提供了就绪探针来解决这个问题的。
在pod中的容器定义一个就绪探针，就绪探针周期性检查容器，如果就绪探针检查失败了，说明该pod还未准备就绪，不能接受客户端链接，则该pod将从endpoint列表中移除，被剔除了service就不会把请求分发给该pod，然后就绪探针继续检查，如果随后容器就绪，则再重新把pod加回endpoint列表。
务必定义就绪探针
首先，如果没有定义就绪探针，那么新创建的pod就会立即加入到service的endpoint列表，如果容器里的业务程序需要很长时间才能开始处理传入的链接，而此时service又将客户端连接转发给了该pod，那么客户端就会看到“连接被拒绝”等类型的错误，所以，为每个容器定义一个就绪探针是很有必要的，即使是定义一个简单的http get 探针。
在生产环境中，一般会让开发提供容器的健康检查接口，在spring boot已经有原生的健康检查接口，所有然开发定义健康检查接口后我们再使用http get方法来定义我们的探针。
就绪探针的三大类型
就绪探针也有三种类型，exec，httpGet和tcpSocket。
exec：执行容器中的命令并检查命令退出的状态码，如果状态码为0则说明容器已经准备就绪；
httpGet：向容器的ip，端口、路径发送http get请求，通过响应的http状态码是否位于200-400之间判断容器是否准备就绪；
tcpSocke：向容器的IP地址、端口发起tcp socket链接，如果能正常建立链接，则认为容器已经准备就绪。
- 1
- 2
- 3
就绪探针的属性
就绪探针的附加属性有以下几个：
initialDelaySeconds：延时秒数，即容器启动多少秒后才开始探测，不写默认容器启动就探测；
periodSeconds ：执行探测的频率（秒），默认为10秒，最低值为1；
timeoutSeconds ：超时时间，表示探测时在超时时间内必须得到响应，负责视为本次探测失败，默认为1秒，最小值为1；
failureThreshold ：连续探测失败的次数，视为本次探测失败，默认为3次，最小值为1次；
successThreshold ：连续探测成功的次数，视为本次探测成功，默认为1次，最小值为1次；
- 1
- 2
- 3
- 4
- 5
创建一个exec存活探针
exec存活探针，执行容器中的命令并检查命令退出的状态码，如果状态码为0则说明容器已经准备就绪；
下面使用deployment部署3个有exec就绪探针的pod（service已经存在了），如下所示：
[root@master ~]# cat deplyment_nginx.yaml apiVersion: apps/v1 kind: Deployment metadata: name: deployment-nginx namespace: default spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx:1.7.9 name: nginx-container readinessProbe: #定义exec探针 initialDelaySeconds: 5 #容器启动5秒后才开始探测 periodSeconds: 10 #探针周期为10s探测一次 timeoutSeconds: 2 #超时时间，2秒得不到响应则视为探测失败 failureThreshold: 3 #连续探测失败3次，视为本次探测失败 successThreshold: 1 #探测成功1次则视为本次探测成功 exec: #探针类型为exec command: #执行的命令是ls /var/ready - ls - /var/ready ports: - name: http containerPort: 80 [root@master ~]# kubectl get pods #查看pod，发现没有一个是ready状态的 NAME READY STATUS RESTARTS AGE deployment-nginx-68bb45dd46-5rj7c 0/1 Running 0 3m1s deployment-nginx-68bb45dd46-78ld2 0/1 Running 0 3m1s deployment-nginx-68bb45dd46-gnnhn 0/1 Running 0 3m1 [root@master ~]# kubectl describe pods deployment-nginx-68bb45dd46-5rj7c |tail -n 3 #查看某个pod的详细信息，显示存活探针检测失败了 Normal Created 5m7s kubelet Created container nginx-container Normal Started 5m7s kubelet Started container nginx-container Warning Unhealthy 2m18s (x22 over 5m6s) kubelet Readiness probe failed: ls: cannot access /var/ready: No such file or directory [root@master ~]# [root@master ~]# kubectl get ep svc-rc-nginx-nodeport #查看service的endpoint列表，显示没有任何pod ip列表可用 NAME ENDPOINTS AGE svc-rc-nginx-nodeport 6h32m # 现在，我们手动在某个pod中创建一个/var/ready文件，这样pod就会处于准备就绪状态，service就能成功添加该pod [root@master ~]# kubectl exec deployment-nginx-68bb45dd46-5rj7c -- touch /var/ready #为该pod创建/var/ready文件 [root@master ~]# kubectl get pods,ep -o wide #查看该pod，发现pod已处于就绪状态 NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/deployment-nginx-68bb45dd46-5rj7c 1/1 Running 0 8m52s 10.244.1.77 node1 <none> pod/deployment-nginx-68bb45dd46-78ld2 0/1 Running 0 8m52s 10.244.1.76 node1 <none> pod/deployment-nginx-68bb45dd46-gnnhn 0/1 Running 0 8m52s 10.244.2.38 node2 <none> NAME ENDPOINTS AGE #endpoint已经有该pod的ip端口 endpoints/svc-rc-nginx-nodeport 10.244.1.77:80 6h36m [root@master ~]#
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
创建一个httpGet存活探针
httpGet存活探针，向容器发送http get请求，通过响应的http状态码判断容器是否准备就绪；
下面使用deployment部署3个有httpGet就绪探针的pod，如下所示：
..........
containers:
- image: nginx:1.7.9
name: nginx-container
readinessProbe: #定义探针
httpGet: # 探针类型为httpGet
# host: 10.244.0.49 #指定主机，默认是pod的ip，一般省略不写
path: /read
port: 80
...........
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
创建一个tcpSocket存活探针
tcpSocket存活探针，打开一个tcp连接到容器的指定端口，如果连接已建立，则认为容器已经准备就绪。
下面使用deployment部署有tcpSocket就绪探针的pod，如下所示：
..........
containers:
- image: nginx:1.7.9
name: nginx-container
readinessProbe: #定义探针
tcpSocket: # 探针类型为tcpSocket
# host: 10.244.0.49 #指定主机，默认是pod的ip，一般省略不写
port: 80
...........
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
三、启动探针（StartupProbe）
启动探针
指示容器中的应用是否已经启动。如果提供了启动探针(startup probe)，则禁用所有其他探针，直到它成功为止。如果启动探针失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探针，则默认状态为成功Success。
startupProbe 启动探针，startupProbe探针是1.16版本加入的探针，用于判断容器进程是否已经启动，是为了解决程序启动时间很长，启动慢等问题的，当配置了startupProbe启动探针，会先禁用其他探针，直到startupProbe探针成功，成功后将退出不在进行探测，如果startupProbe探针探测失败，pod将会重启。
