对Pod的健康状态检查可以通过两类探针来检查:LivenessProbe和ReadinessProbe。
LivenessProbe探针:用于判断容器是否存活(running状态),如果LivenessProbe探针探测到容器不健康,
则kubelet将杀掉该容器,并根据容器的重启策略做相应的处理。
如果一个容器不包含LivenessProbe探针,那么kubelet认为该容器的LivenessProbe探针返回的值永远是“Success”。
ReadinessProbe探针:用于判断容器服务是否可用(ready状态),可以接收请求。
如果Readiness探针检测到失败,则Pod的状态将被修改。
Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的Endpoint。
kubelet定期执行LivenessProbe探针来诊断容器的健康状况。LivenessProbe有以下三种实现方式。
1.ExecAction:在容器内部执行一个命令,如果该命令的返回码为0,则表明容器健康。
apiVersion: v1 #required kind: Pod #required metadata: #required labels: test: liveness name: liveness-exec #required spec: containers: - name: liveness image: centos imagePullPolicy: IfNotPresent args: - /bin/sh - -c - echo ok > /tmp/health; sleep 10; rm -rf /tmp/health; sleep 600 livenessProbe: #探针配置 exec: #类型 command: #探针需要执行的命令 - cat - /tmp/health initialDelaySeconds: 15 #初次探测时间为15秒 timeoutSeconds: 1
通过执行cat /tmp/health命令来判断一个容器是否在运行。
在运行10秒之后会删除这个文件,15秒之后探测的结果将会去是Fail,
Kubelet将会杀死该容器并且重启它。
2.TCPSocketAction:通过容器的IP地址和端口号执行TCP检查,如果能够建立TCP连接,则表明容器健康。
apiVersion: v1 kind: Pod metadata: name: liveness-tcp spec: containers: - name: nginx image: nginx ports: - containerPort: 80 livenessProbe: tcpSocket: port: 80 initialDelaySeconds: 30 timeoutSeconds: 1
3.HTTPGetAction:通过容器的IP地址、端口号及路径调用HTTP Get方法,如果响应状态码大于等于200且小于400,则认为容器状态健康。
apiVersion: v1 kind: Pod metadata: name: liveness-http spec: containers: - name: nginx image: nginx ports: - containerPort: 80 livenessProbe: httpGet: path: /_status/healthz port: 80 initialDelaySeconds: 30 timeoutSeconds: 1
对于每种探测方式,都需要设置initialDelaySeconds和timeoutSeconds两个参数。
initialDelaySeconds:启动容器后进行首次健康检查的等待时间,单位为s。
timeoutSeconds:健康检查发送请求后等待响应的超时时间,单位为s。
当超时发生时,kubelet会认为容器已经无法提供服务,将重启该容器。
Kubernetes的ReadinessProbe机制可能无法满足某些复杂应用对容器内服务可用状态的判断。
所以Kubernetes从1.11版本开始,引入Pod Ready++特性对Readiness探测机制进行扩展,
在1.14版本时达到GA稳定版,称其为Pod Readiness Gates。
通过Pod Readiness Gates机制,用户可以将自定义的ReadinessProbe探测方式设置在Pod上,
辅助Kubernetes设置Pod何时达到服务可用状态(Ready)。
为了使自定义的ReadinessProbe生效,用户需要提供一个外部的控制器(Controller)来设置相应的Condition状态。
Pod的Readiness Gates在Pod定义中的ReadinessGate字段进行设置。
下面的例子设置了一个类型为www.example.com/feature-1的新Readiness Gate:
kind: Pod ... spec: readinessGates: - conditionType: "www.example.com/feature-1" status: conditions: - type: Ready status: "True" lastProbeTime: null lastTransitionTime: 2018-01-01T00:00:002 - type: "www.example.com/feature-1" status: "False" lastProbeTime: null lastTransitionTime: 2019-03-01T00:00:00z containerStatus: - containerID: docker://abcd... ready: true
新增的自定义Condition的状态(status)将由用户自定义的外部控制器设置,默认值为False。
Kubernetes将在判断全部readinessGates条件都为True时,才设置Pod为服务可用状态(Ready为True)。
原文:https://www.cnblogs.com/yangmingxianshen/p/12639609.html