浅析Kubernetes Pod重启策略和健康检查
使用Kubernetes
的主要好处之一是它具有管理和维护集群中容器的能力,几乎可以提供服务零停机时间的保障。在创建一个Pod
资源后,Kubernetes
会为它选择worker节点,然后将其调度到节点上运行Pod
里的容器。Kubernetes
强大的功能可使应用程序的容器保持连续运行,还可以根据需求的增长自动扩展系统。除此之外在Pod
或容器出现故障时Kubernetes
还可以让系统实现"自愈"。在本文中,我们将介绍如何使用Kubernetes
内置的livenessProbe
和readinessProbe
来管理和控制应用程序的运行状况。
Pod的重启策略
Kubernetes
自身的系统修复能力有一部分是需要依托Pod
的重启策略的, 重启策略也叫restartPolicy
。它是Pod
的Spec
部分的一个标准字段(pod.spec.restartPolicy),默认值是Always,即:任何时候这个容器发生了异常,它一定会被重新创建。
可以通过设置 restartPolicy,改变 Pod 的恢复策略。除了 Always,它还有 OnFailure 和 Never 两种情况。
Always:在任何情况下,只要容器不在运行状态,就自动重启容器;
OnFailure: 只在容器 异常时才自动重启容器;
Never: 从来不重启容器。
在实际使用时,我们需要根据应用运行的特性,合理设置这三种恢复策略。
对于包含多个容器的 Pod,只有它里面所有的容器都进入异常状态后,Pod 才会进入 Failed 状态。在此之前,Pod 都是 Running 状态。此时,Pod 的 READY 字段会显示正常容器的个数,比如:
$ kubectl get pod test-liveness-exec
NAME READY STATUS RESTARTS AGE
liveness-exec 0/1 Running 1 1m
如果一个 Pod 里只有一个容器,然后这个容器异常退出了。那么,只有当 restartPolicy=Never 时,这个 Pod 才会进入 Failed 状态。而其他情况下,由于 Kubernetes 都可以重启这个容器,所以 Pod 的状态保持Running
不变,RESTARTS信息统计了Pod
的重启次数。需要注意的是:虽然是重启,但背后其实是Kubernetes
用重新创建的容器替换了旧容器。
Pod怎么实现自我修复?
将Pod
调度到某个节点后,该节点上的Kubelet将运行其中的容器,并在Pod
的生命周期内保持它们的运行。如果容器的主进程崩溃,kubelet
将重新启动容器。但是,如果容器内的应用程序抛出错误导致其不断重启,则Kubernetes
可以通过使用正确的诊断程序并遵循Pod
的重启策略来对其进行修复。
Kubernetes
可以对两种健康检查做出应对:
Liveness:活性检查,
kubelet
使用活性探针(livenessProbe)的返回状态作为重新启动容器的依据。一个Liveness探针用于在应用运行时检测容器的问题。容器进入此状态后,Pod
所在节点的kubelet
可以通过Pod
策略来重启容器。Readiness:就绪检查,这种类型的探测(readinessProbe)用于检测容器是否准备好接受流量。你可以使用这种探针来管理哪些
Pod
会被用作服务的后端。如果Pod
尚未准备就绪,则将其从服务的后端列表中删除。
Kubernetes
把放在Pod
里的健康检查处理程序叫做探针(Probe),比喻成医学手术上探测病变的探针,还是很形象的。
探针处理程序
为了使健康检查能够对Pod
的运行状况进行诊断,kubelet
会调用容器中为探针实现的处理程序,这些处理程序分为三大类:
Exec:在容器内执行命令。
TCPSocket:对指定端口上,容器的IP地址执行TCP检查。
HTTPGet:在容器的IP上执行HTTP GET请求。
处理程序的返回状态也分为三种:
Success:容器通过诊断。
Failed:容器无法通过诊断。
Unknown:诊断失败,状态不确定,将不采取任何措施。
聊完了探针程序的种类和返回值接下来我们来了解一下这两种探针的使用案例。
使用案例
活性和就绪探针都在Pod
的YAML
文件中配置。每种类型都有不同的用例。
livenessProbe
如前所述,活性探针用于诊断不健康的容器。他们可以在服务无法继续进行时检测到服务中的问题,并会根据其重启策略重启有问题的容器,期望通过这种方式来解决服务的问题。
例如,在容器内包含一个Exec活性探针,以检测应用程序何时转换为Broken
状态。
apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-exec
spec:containers:- name: livenessimage: k8s.gcr.io/busyboxargs:- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600livenessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 5periodSeconds: 5
这个YAML
定义一个单容器的Pod
。它表示kubelet
在容器启动完成后5秒进行第一次健康检查(initialDelaySeconds:5),之后每5秒都会执行一次检查(periodSeconds: 5)。kubelet
在容器中执行命令"cat/tmp/healthy",如果成功,则返回0,指示它是健康的。如果返回非零值,则kubelet
将kill掉该容器并重新启动它。
这个例子是官方教程里给的,除了在容器中执行命令外,发起 HTTP 或者 TCP 请求的livenessProbe,教程里也给出了示例:
...livenessProbe:httpGet:path: /healthzport: 8080httpHeaders:- name: Custom-Headervalue: AwesomeinitialDelaySeconds: 3periodSeconds: 3
...livenessProbe:tcpSocket:port: 8080initialDelaySeconds: 15periodSeconds: 20
在官方教程里可以找到更多示例,链接:https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
readinessProbe
就绪探针与活性探针(GET请求,TCP连接和命令执行)进行相同类型的检查。但是,纠正措施有所不同。它不会重启未通过检查的容器的Pod
,而是从Service
上摘除Pod
,暂时将其与流量隔离。
比如,有一个Pod
可能正在做大量计算或正在进行繁重的操作,从而增加了服务的响应延迟。让我们定义一个就绪探针,通过探针的timeoutSeconds参数定义超过两秒响应GET请求的Pod
的状态为非健康状态
apiVersion: v1
kind: Pod
metadata:name: nodedelayed
spec:containers:- image: k8s.gcr.io/livenessname: livenessports:- containerPort: 8080protocol: TCPreadinessProbe:httpGet:path: /port: 8080timeoutSeconds: 2
当探测响应时间超过两秒钟时,kubelet不会重新启动Pod,而是将流量路由到其他健康的Pod
上。等到Pod
不再过载后,kubelet
会将Pod
重新加回到原来的Service
中。
总结
默认情况下,Kubernetes
提供两种健康检查:readinessProbe 和 livenessProbe。它们都使用相同类型的探针处理程序(HTTP GET请求,TCP连接和命令执行)。他们对未通过检查的Pod
做出的纠错措施有所不同。livenessProbe将重新启动容器,预期重启后错误不再发生。readinessProbe会将Pod与流量隔离,直到故障原因消失。
通过在同一个Pod
中使用这两种健康检查,可以确保流量不会到达尚未准备就绪的Pod
,并且确保Pod
在发生故障时能重新启动。
良好的应用程序设计应同时记录足够的信息,尤其是在引发异常时。它还应公开必要的API端点,这些端点将会传达重要的运行状况和状态指标,以供监控系统(如Prometheus)使用。
参考链接:
kubernetes-best-practices-health-probes[1]
liveness-and-readiness-probes-in-kubernetes[2]
参考资料
[1]
kubernetes-best-practices-health-probes: https://www.magalix.com/blog/kubernetes-and-containers-best-practices-health-probes
[2]
liveness-and-readiness-probes-in-kubernetes: https://www.weave.works/blog/resilient-apps-with-liveness-and-readiness-probes-in-kubernetes
Kubernetes Pod入门指南
Docker容器的"单进程模型"
YAML,另一种标记语言?不止是标记语言!
❤️爱心三连
1.看到这里了就点个在看支持下吧,你的「在看」是我创作的动力。
2.关注公众号网管叨bi叨
,「每周为您分享原创技术文章」!
“在看转发”是最大的支持
浅析Kubernetes Pod重启策略和健康检查相关推荐
- k8s教程(pod篇)-生命周期、重启策略及健康检查
文章目录 01 引言 02 pod生命周期 03 pod重启策略 04 pod健康检查和服务可用性检查 4.1 方式一:ExecAction 4.2 方式二:TCPSocketAction 4.3 方 ...
- .net core i上 K8S(四).netcore程序的pod管理,重启策略与健康检查
目录 1.pod管理 2.重启策略 3.健康检查 4.进入容器 正文 上一章我们已经通过yaml文件将.netcore程序跑起来了,但还有一下细节问题可以分享给大家. 1.pod管理 1.1创建pod ...
- k8s中pod的重启策略和健康检查
目录 k8s中pod的重启策略 pod中一共有以下三个重启策略(restartPolicy) 健康检查: 健康检查类型 支持的检查方法: 检查示例 其他检查方式示例 k8s中pod的重启策略 pod中 ...
- k8s 重启策略、健康检查、环境变量、初始化容器
深入理解Pod对象:基本管理 Pod基本概念 Pod存在意义 Pod资源共享实现机制 Pod管理命令 重启策略 健康检查 环境变量 init Container(初始化容器) 先简单的做出两个运行ht ...
- Kubernetes Pod冗余策略
It is inevitable that something will fail in a distributed system, and we should plan as if it is a ...
- kubernetes云原生纪元:健康检查-高可用的守护者
kubernetes云原生纪元:健康检查-高可用的守护者
- @kubernetes(k8s)pod服务探针(健康检查)及回调钩子HOOK详解
文章目录 服务探针与回调hook(健康检查) 一.存活性探针(LivenessProbe) 1.存活型检查基本用法 2.存活性探针三种使用方式 [ExecAction] [TCPSocketActio ...
- Kubernetes(k8s) pod 重启策略
目录 一.重启策略 1.在k8s集群中有如下三种重启策略 2.Always 3.Never 4.OnFailure 4.1.非0状态 4.2.为0状态 二.Pod状态 1.Pod 一直处 ...
- 【云原生--Kubernetes】Pod重启策略
文章目录 一. 重启策略 二. Always 三. Never 四. OnFailure 4.1 非0状态 4.2 为0状态 五. Pod状态 引言:在k8s集群中,当某个pod资源需要重启时,我们只 ...
最新文章
- Powershell管理系列(八)Exchange 2013通讯组管理
- Openstack Nova 源码分析 — 使用 VCDriver 创建 VMware Instance
- 《Build your own AngularJS》笔记分享
- 危害网络安全或入信用“黑名单”
- TFS中的工作项(六)
- 四元素、欧拉角及旋转矩阵之间的转换
- if函数python_python入门(if函数)
- 中国矫形修复植入物市场趋势报告、技术动态创新及市场预测
- C++类的赋值运算符“=”重载,以及深拷贝和浅拷贝
- mysql5.7 单机多实例_MySQL数据库 5.7.21单机多实例安装
- Dll学习心得(2)
- 计算机控制器的简写,工业控制常用英语及缩写
- Android中关于libs和JniLibs的各种坑
- 一文读懂Hoo Smart Chain的可视化公链
- HTTP协议网络请求状态码
- TeamTalk安装部署手册
- 《孩子你慢慢来》的读后感作文3500字
- 110款表白网站源码,搭建表白网站必备,总有一款适合你
- 解决docker-compose: 未找到命令问题
- 使用logisim搭建单周期CPU与添加指令