赞
踩
存活指针,判断Pod(中的应用容器)是否健康,可以理解为健康检查。我们使用livenessProbe来定期的去探测,如果探测成功,则Pod状态可以判定为Running;如果探测失败,可kubectl会根据Pod的重启策略来重启容器。
如果未给Pod设置livenessProbe,则默认探针永远返回Success。
当我们执行kubectl get pods
命令,输出信息中STATUS
一列我们可以看到Pod是否处于Running
状态。
就绪指针,就绪的意思是已经准备好了,Pod的就绪我们可以理解为这个Pod可以接受请求和访问。我们使用readinessProbe来定期的去探测,如果探测成功,则Pod 的Ready状态判定为True;如果探测失败,Pod的Ready状态判定为False。
与livenessProbe不同的是,kubelet不会对readinessProbe的探测情况有重启操作。
当我们执行kubectl get pods
命令,输出信息中READY
一列我们可以看到Pod的READY
状态是否为True。
k8s应用更新虽然是滚动升级方式,但是很多后端程序启动都比较久,容器起来了,但是服务未起来,而k8s只要容器起来了就会移除掉旧的容器,这种情况就会导致在更新发版的时候应用访问失败。这时候就需要配置readinessProbe就绪检测,保证新的pod已经能正常使用了才会移除掉旧的pod。
有些后端应用在出现某些异常的时候会有假死的情况,这种情况容器依然是running状态,但是应用是无法访问的,所以需要加入存活探测livenessProbe来避免这种情况的发生。
- #readinessProbe就绪探测,用于判断容器是否启动完成
- readinessProbe:
- tcpSocket:
- port: 8080
- initialDelaySeconds: 5
- periodSeconds: 10
- #存活探测,用于判断容器是否存活(running状态)
- livenessProbe:
- tcpSocket:
- port: 8080
- initialDelaySeconds: 15
- periodSeconds: 20
在加入就绪检测前,刚执行kubectl apply 更新就可以看到容器运行起来了,已经在移除旧的pod了
加了就绪检测后,执行kubectl apply更新时候,新的pod启动一会,就绪检测没问题后才会把旧的pod移除掉
在nacos服务列表里也可以看到,在更新应用时,健康实例数是不变的。
- apiVersion: apps/v1
- kind: Deployment
- metadata:
- name: mbo-gaas-portal #应用名称
- namespace: mbo
- labels:
- app: mbo-gaas-portal
- mbo: mbo-gaas-portal
- spec:
- selector:
- matchLabels:
- app: mbo-gaas-portal
- replicas: 2 #开启实例份数
- template:
- metadata:
- labels:
- app: mbo-gaas-portal
- mbo: mbo-gaas-portal
- spec:
- imagePullSecrets:
- - name: docker-pull-images
- containers:
- - name: mbo-gaas-portal #容器名称
- image: xxx.aliyuncs.com/mbo-uat/gaas-portal:v2021-12-24
- imagePullPolicy: Always
- ports:
- - name: http
- containerPort: 8080
- #readinessProbe就绪探测,用于判断容器是否启动完成
- readinessProbe:
- tcpSocket:
- port: 8080
- initialDelaySeconds: 5
- periodSeconds: 10
- #存活探测,用于判断容器是否存活(running状态)
- livenessProbe:
- tcpSocket:
- port: 8080
- initialDelaySeconds: 15
- periodSeconds: 20
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。