K8S容器编排之POD健康检测(2)
ReadinessProbe探针配置:
ReadinessProbe
探针的使用场景livenessProbe
稍有不同,有的时候应用程序可能暂时无法接受请求,比如Pod
已经Running
了,但是容器内应用程序尚未启动成功,在这种情况下,如果没有ReadinessProbe
,则Kubernetes
认为它可以处理请求了,然而此时,我们知道程序还没启动成功是不能接收用户请求的,所以不希望kubernetes
把请求调度给它,则使用ReadinessProbe
探针。
ReadinessProbe
和livenessProbe
可以使用相同探测方式,只是对Pod
的处置方式不同,ReadinessProbe
是将Pod IP:Port
从对应的EndPoint
列表中删除,而livenessProbe
则Kill
容器并根据Pod
的重启策略
来决定作出对应的措施。
ReadinessProbe
探针探测容器是否已准备就绪,如果未准备就绪则kubernetes
不会将流量转发给此Pod
。
ReadinessProbe
探针与livenessProbe
一样也支持exec、httpGet、TCP
的探测方式,配置方式相同,只不过是将livenessProbe
字段修改为ReadinessProbe
。
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
ReadinessProb
e探针的HTTP
、TCP
的探测方式也与livenessProbe
的基本一致。
示例四: ReadinessProbe示例
现在来看一个加入ReadinessProbe
探针和一个没有ReadinessProbe
探针的示例:
该示例中,创建了一个deploy
,名为JavaApp
,启动的容器运行一个java
应用程序,程序监听端口为8080
。
# 没有加入ReadinessProbe
cat JavaApp.yaml
---
kind: Deployment
apiVersion: apps/v1
metadata:
name: JavaApp
namespace: default
spec:
replicas: 1
selector:
matchLabels:
test: JavaApp
template:
metadata:
labels:
test: JavaApp
spec:
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: env
operator: In
values:
- testing
containers:
- image: 192.168.1.183:8081/jar/JavaApp:29
name: JavaApp
ports:
- containerPort: 8080
imagePullSecrets:
- name: myregistrykey
---
kind: Service
apiVersion: v1
metadata:
name: JavaApp
namespace: default
spec:
selector:
test: JavaApp
ports:
- protocol: TCP
port: 8080# 没有加入ReadinessProbe
cat JavaApp.yaml
---
kind: Deployment
apiVersion: apps/v1
metadata:
name: JavaApp
namespace: default
spec:
replicas: 1
selector:
matchLabels:
test: JavaApp
template:
metadata:
labels:
test: JavaApp
spec:
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: env
operator: In
values:
- testing
containers:
- image: 192.168.1.183:8081/jar/JavaApp:29
name: JavaApp
ports:
- containerPort: 8080
imagePullSecrets:
- name: myregistrykey
---
kind: Service
apiVersion: v1
metadata:
name: JavaApp
namespace: default
spec:
selector:
test: JavaApp
ports:
- protocol: TCP
port: 8080
创建:
kubectl create -f JavaApp.yaml
刚创建后,等几秒钟后,查看Pod状态
:
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
JavaApp-579b45567c-tdsrk 1/1 Running 0 6s
从上面可以看到,Pod
刚启动6s
,自身状态已Running
,其READ
字段,1/1
表示1个容器状态已准备就绪了,此时,对于kubernetes
而言,它已经可以接收请求了,而实际上服务还无法访问,因为JAVA程序
还尚启动起来,本人实验中的JAVA程序
启动时间大概需要50
s,50s
后方可正常访问,所以针对此类程序,必须配置ReadinessProbe
。
#加入readinessProbe
kind: Deployment
apiVersion: apps/v1
metadata:
name: JavaApp
namespace: default
spec:
replicas: 1
selector:
matchLabels:
test: JavaApp
template:
metadata:
labels:
test: JavaApp
spec:
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: env
operator: In
values:
- testing
containers:
- image: 192.168.1.183:8081/jar/JavaApp:29
name: JavaApp
ports:
- containerPort: 8080
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 60
periodSeconds: 10
imagePullSecrets:
- name: myregistrykey
---
kind: Service
apiVersion: v1
metadata:
name: JavaApp
namespace: default
spec:
selector:
test: JavaApp
ports:
- protocol: TCP
port: 8080
在该配置文件中,ReadinessProb
e探针的探测方式为tcpSocket
,因为程序监听在8080
端口,所以这里探测为对8080
建立连接。程序启动时间大概50
多秒,所以这里第一次探测时间是在Pod Runing
后60
秒后,间隔10
秒后执行第二次探测
。
创建Pod:
kubectl create -f JavaApp.yaml
创建后等50秒查看状态:
$ kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
JavaApp-64b58cfd5c-kpc4s 0/1 Running 0 55s 172.26.91.109 192.168.1.180
Pod
虽然已处于Runnig
状态,但是由于第一次探测时间未到,所以READY
字段为0/1
,即容器的状态为未准备就绪
,在未准备就绪的情况下,其Pod
对应的Service
下的Endpoint
也为空,所以才不会有任何请求被调度进来。
$ kubectl get endpoints
NAME ENDPOINTS
JavaApp
当通过第一次探测的检查通过后,容器的状态自然会转为READ
状态。
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
JavaApp-64b58cfd5c-qj886 1/ Running 0 1m
$ kubectl get endpoints
NAME ENDPOINTS AGE
JavaApp 172.26.91.113:8080 1m
此后根据指定的间隔时间10s
后再次探测,如果不通过,则kubernetes
就会将Pod IP
从EndPoint
列表中移除。
配置探针(Probe)相关属性
探针(Probe)有许多可选字段,可以用来更加精确的控制Liveness和Readiness两种探针的行为(Probe):
- initialDelaySeconds:Pod启动后延迟多久才进行检查,单位:秒。
- periodSeconds:检查的间隔时间,默认为10,单位:秒。
- timeoutSeconds:探测的超时时间,默认为1,单位:秒。
- successThreshold:探测失败后认为成功的最小连接成功次数,默认为1,在Liveness探针中必须为1,最小值为1。
- failureThreshold:探测失败的重试次数,重试一定次数后将认为失败,在readiness探针中,Pod会被标记为未就绪,默认为3,最小值为1。