Blog:博客园 个人

应用在运行过程中难免会出现错误,如程序异常、软件异常、硬件故障、网络故障等。因此,系统通过一些手段来判断应用是否运行正常,这些手段称之为健康检查(诊断)。

前置知识

回顾一下Pod的生命周期:

检查机制(Check mechanisms)

有以下几种方法来检查容器:

  • exec:在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
  • gRPC:使用gRPC执行远程过程调用。目标应该实施gRPC运行状况检查。如果响应的状态为SERVING,则认为诊断成功。gRPC检查是一项Alpha功能,仅当您启用GRPCContainerProbe时才可用。
  • httpGet:对容器的 IP 地址上指定端口和路径执行 HTTP Get 请求。如果响应的状态码大于等于 200 且小于 400,则诊断被认为是成功的。
  • tcpSocket:对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开,则诊断被认为是成功的。

每次探测都将获得以下三种结果之一:

  • Success(成功):容器通过了诊断。
  • Failure(失败):容器未通过诊断。
  • Unknown(未知):诊断失败,因此不会采取任何行动。

针对运行中的容器,kubelet 可以选择是否执行以下三种探针,以及如何针对探测结果作出反应:

  • livenessProbe:指示容器是否正在运行。如果存活态探测失败,则 kubelet 会杀死容器, 并且容器将根据其重启策略决定未来。如果容器不提供存活探针, 则默认状态为 Success
  • readinessProbe:指示容器是否准备好为请求提供服务。如果就绪态探测失败, 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 初始延迟之前的就绪态的状态值默认为 Failure。 如果容器不提供就绪态探针,则默认状态为 Success
  • startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探针,则所有其他探针都会被 禁用,直到此探针成功为止。如果启动探测失败,kubelet 将杀死容器,而容器依其重启策略进行重启。 如果容器没有提供启动探测,则默认状态为 Success

exec方式检测存活示例

创建一个 Pod,其中运行一个基于 busybox 镜像的容器:

apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: registry.aliyuncs.com/google_containers/busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5

当容器启动时,执行如下的命令:

/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"

这个容器生命的前 30 秒, /tmp/healthy 文件是存在的。 所以在这最开始的 30 秒内,执行命令 cat /tmp/healthy 会返回成功代码。 30 秒之后,执行命令 cat /tmp/healthy 就会返回失败代码。

事件如下:

Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 41s default-scheduler Successfully assigned default/liveness-exec to node-1
Normal Pulling 40s kubelet Pulling image "registry.aliyuncs.com/google_containers/busybox"
Normal Pulled 39s kubelet Successfully pulled image "registry.aliyuncs.com/google_containers/busybox" in 727.748993ms
Normal Created 39s kubelet Created container liveness
Normal Started 39s kubelet Started container liveness
Warning Unhealthy 1s (x2 over 6s) kubelet Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory

检查看这个容器被重启了:

[root@master test]# kubectl get pod
NAME READY STATUS RESTARTS AGE
liveness-exec 1/1 Running 1 82s

httpGet方式检测存活示例

创建一个 Pod ,其中运行一个基于 liveness 镜像的容器:

apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-http
spec:
containers:
- name: liveness
image: mirrorgooglecontainers/liveness
args:
- /server
livenessProbe:
httpGet:
path: /healthz
port: 8080
httpHeaders:
- name: Custom-Header
value: Awesome
initialDelaySeconds: 3
periodSeconds: 3

通过看 Pod 事件来检测存活探测器已经失败了并且容器被重新启动了。

kubectl describe pod liveness-http

事件如下:

Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 100s default-scheduler Successfully assigned default/liveness-http to node-1
Normal Pulled 84s kubelet Successfully pulled image "mirrorgooglecontainers/liveness" in 15.537483195s
Normal Pulled 52s kubelet Successfully pulled image "mirrorgooglecontainers/liveness" in 15.375906607s
Normal Pulled 19s kubelet Successfully pulled image "mirrorgooglecontainers/liveness" in 15.388654652s
Normal Created 18s (x3 over 83s) kubelet Created container liveness
Normal Started 18s (x3 over 83s) kubelet Started container liveness
Warning Unhealthy 1s (x9 over 73s) kubelet Liveness probe failed: HTTP probe failed with statuscode: 500
Normal Killing 1s (x3 over 67s) kubelet Container liveness failed liveness probe, will be restarted
Normal Pulling 1s (x4 over 99s) kubelet Pulling image "mirrorgooglecontainers/liveness"

tcpSocket方式检测存活示例

创建一个 Pod ,其中运行一个基于 goproxy 镜像的容器:

apiVersion: v1
kind: Pod
metadata:
name: goproxy
labels:
app: goproxy
spec:
containers:
- name: goproxy
image: mirrorgooglecontainers/goproxy:0.1
ports:
- containerPort: 8080
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 15
periodSeconds: 20

kubelet 会在容器启动 5 秒后发送第一个就绪探测。 这会尝试连接 goproxy 容器的 8080 端口。 如果探测成功,这个 Pod 会被标记为就绪状态,kubelet 将继续每隔 10 秒运行一次检测。

除了就绪探测,这个配置包括了一个存活探测。 kubelet 会在容器启动 15 秒后进行第一次存活探测。 与就绪探测类似,会尝试连接 goproxy 容器的 8080 端口。 如果存活探测失败,这个容器会被重新启动。

Kubernetes:健康检查的更多相关文章

  1. Docker Kubernetes 健康检查

    Docker Kubernetes 健康检查 提供Probe探测机制,有以下两种类型: livenessProbe:如果检查失败,将杀死容器,然后根据Pod的重启策略来决定是否重启. readines ...

  2. Kubernetes 健康检查的两种机制:Liveness 探测和 Readiness 探测

    Kubernetes 健康检查的两种机制:Liveness 探测和 Readiness 探测,并实践了健康检查在 Scale Up 和 Rolling Update 场景中的应用.kubelet使用启 ...

  3. kubernetes健康检查

    有时候容器在running的状态,但是里面的服务挂了,这个就难办了,所以k8s提供了一种检查服务是否健康的方法 Liveness Probe的种类: ● ExecAction:在container中执 ...

  4. Kubernetes应用健康检查

    目录贴:Kubernetes学习系列 在实际生产环境中,想要使得开发的应用程序完全没有bug,在任何时候都运行正常,几乎 是不可能的任务.因此,我们需要一套管理系统,来对用户的应用程序执行周期性的健康 ...

  5. Kubernetes中Pod的健康检查

    本文介绍 Pod 中容器健康检查相关的内容.配置方法以及实验测试,实验环境为 Kubernetes 1.11,搭建方法参考kubeadm安装kubernetes V1.11.1 集群 0. 什么是 C ...

  6. Kubernetes Pod 健康检查

    参考文档: https://jimmysong.io/kubernetes-handbook/guide/configure-liveness-readiness-probes.html 一.Pod的 ...

  7. Kubernetes 健康状态检查(九)

    强大的自愈能力是 Kubernetes 这类容器编排引擎的一个重要特性.自愈的默认实现方式是自动重启发生故障的容器.除此之外,用户还可以利用 Liveness 和 Readiness 探测机制设置更精 ...

  8. kubernetes之pod健康检查

    目录 kubernetes之pod健康检查 1.概述和分类 2.LivenessProbe探针(存活性探测) 3.ReadinessProbe探针(就绪型探测) 4.探针的实现方式 4.1.ExecA ...

  9. Kubernetes中Pod健康检查

    目录 1.何为健康检查 2.探针分类 2.1.LivenessProbe探针(存活性探测) 2.2.ReadinessProbe探针(就绪型探测) 3.探针实现方法 3.1.Container Exe ...

随机推荐

  1. Selenium_使用switch_to.frame处理网页框架切换(13)

    与在新窗口打开一个网页后需要切换窗口才能定位元素一样,在iframe标签中的元素也不能直接定位,需要切换到对应的iframe框架中才能进行元素定位. 完成网页框架切换操作需要用selenium中的两个 ...

  2. Centos更换阿里云源

    1.备份 mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup 2.下载新的CentOS-Base ...

  3. Go语言系列- Socket编程和Redis

    Socket编程 一.socket编程概述 什么是socket编程? socket编程是计算机PC机器上2个程序通过一个双向的通信连接实现数据的交互,这个连接的一端就是一个socket.socket的 ...

  4. PPT变为gif效果

    原文链接:https://www.toutiao.com/i6496812863263343117/ 首先我们点击"文件按钮" 在下拉列表中选择"另存为" 在& ...

  5. html手机调试

    长话短说 npm install anywhere -g 安装好后,cmd 命令 进入你要调试html页面的目录,运行 anywhere AnyWhere 静态文件服务器 软件简介 AnyWhere是 ...

  6. 关于 Intel CPU 和Iris Xe Graphics的报告问题

    关于 Intel CPU 和Iris Xe Graphics的报告问题 有些用户报告了一些技术问题,这里有更多的信息和如何解决. Intel 11th CPU & Iris Xe Graphi ...

  7. JUC之读写锁问题

    读写锁 读写锁在同一时刻可以允许多个读线程访问,但是在写线程访问时,所有的读线程和其他写线程均被阻塞.读写锁维护了一对锁,一个读锁和一个写锁,通过分离读锁和写锁,使得并发性相比一般的排他锁有了很大提升 ...

  8. system (color XX )函数详解:调整控制台颜色的命令

    1.指定控制台输出的颜色属性 2.颜色属性由两个十六进制数字指定 -- 第一个为背景,第二个则为前景.每个数字可以为以下任何值之一: 例如: "COLOR fc" 在亮白色上产生亮 ...

  9. 《剑指offer》面试题68 - I. 二叉搜索树的最近公共祖先

    问题描述 给定一个二叉搜索树, 找到该树中两个指定节点的最近公共祖先. 百度百科中最近公共祖先的定义为:"对于有根树 T 的两个结点 p.q,最近公共祖先表示为一个结点 x,满足 x 是 p ...

  10. TexStudio中Bibtex使用

    TexStudio中Bibtex使用 1.首先在百度文库中找到相应的参考文献: 2.建立bibfile.bib文件,放在和.tex同一目录下,将上面页面的结果考入该文件,注意其中第一行中的Tuan20 ...