Kubernetes技术学习之---容器监测探针Liveness Probes

pod进阶|生命周期|就绪探针readnessprobe|存活探针livenessprobe|startupprobe|probe三种检测方法exec,tcpsocket,httpget|就绪探测检验 pod进阶|生命周期|就绪探针readnessprobe|存活探针livenessprobe|startupprobe|probe三种检测方法exec,tcpsocket,httpget|就绪探测检验实验 阅读详情

 

Keep fighting 2015-09-17 3031 阅读

 

大部分的应用程序我们在部署的时候都会适当的添加监控,对于运行载体容器则更应该如此。kubernetes提供了 liveness probes来检查我们的应用程序。它是由节点上的kubelet定期执行的。 

首先说一下Pod的整个生命阶段:

  • Pending :表示集群系统正在创建Pod,但是Pod中的container还没有全部被创建,这其中也包含集群为container创建网络,或者下载镜像的时间;
  • Running :表示pod已经运行在一个节点商量,并且所有的container都已经被创建。但是并不代表所有的container都运行,它仅仅代表至少有一个container是处于运行的状态或者进程出于启动中或者重启中;
  • Succeeded :所有Pod中的container都已经终止成功,并且没有处于重启的container;
  • Failed :所有的Pod中的container都已经终止了,但是至少还有一个container没有被正常的终止(其终止时的退出码不为0)

对于liveness probes的结果也有几个固定的可选项值:

  • Success :表示通过检测
  • Failure :表示没有通过检测
  • Unknown :表示检测没有正常进行

Liveness Probe的种类:

  • ExecAction :在container中执行指定的命令。当其执行成功时,将其退出码设置为0;
  • TCPSocketAction :执行一个TCP检查使用container的IP地址和指定的端口作为socket。如果端口处于打开状态视为成功;
  • HTTPGetAcction :执行一个HTTP默认请求使用container的IP地址和指定的端口以及请求的路径作为url,用户可以通过host参数设置请求的地址,通过scheme参数设置协议类型(HTTP、HTTPS)如果其响应代码在200~400之间,设为成功。

当前kubelet拥有两个检测器,他们分别对应不通的触发器(根据触发器的结构执行进一步的动作):

  • Liveness Probe :表示container是否处于live状态。如果LivenessProbe失败,LivenessProbe将会通知kubelet对应的container不健康了。随后kubelet将kill掉container,并根据RestarPolicy进行进一步的操作。默认情况下LivenessProbe在第一次检测之前初始化值为Success,如果container没有提供LivenessProbe,则也认为是Success;
  • ReadinessProbe :表示container是否以及处于可接受service请求的状态了。如果ReadinessProbe失败,endpoints controller将会从service所匹配到的endpoint列表中移除关于这个container的IP地址。因此对于Service匹配到的endpoint的维护其核心是ReadinessProbe。默认Readiness的初始值是Failure,如果一个container没有提供Readiness则被认为是Success。

对于LivenessProbe和ReadinessProbe用法都一样,拥有相同的参数和相同的监测方式。

  • initialDelaySeconds :用来表示初始化延迟的时间,也就是告诉监测从多久之后开始运行,单位是秒
  • timeoutSeconds : 用来表示监测的超时时间,如果超过这个时长后,则认为监测失败

当前对每一个Container都可以设置不同的restartpolicy,有三种值可以设置:

  • Always : 只要container退出就重新启动
  • OnFailure : 当container非正常退出后重新启动
  • Never : 从不进行重新启动

如果restartpolicy没有设置,那么默认值是Always。如果container需要重启,仅仅是通过kubelet在当前节点进行container级别的重启。 

最后针对LivenessProbe如何使用,请看下面的几种方式,如果要使用ReadinessProbe只需要将 livenessProbe 修改为 readinessProbe 即可:

apiVersion: v1
kind: Pod
metadata:
  name: probe-exec
  namespace: coocla
spec:
  containers:
  - name: nginx
    image: nginx
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/health
      initialDelaySeconds: 5
      timeoutSeconds: 1
---
apiVersion: v1
kind: Pod
metadata:
  name: probe-http
  namespace: coocla
spec:
  containers:
  - name: nginx
    image: nginx
    livenessProbe:
      httpGet:
        path: /
        port: 80
        host: www.baidu.com
        scheme: HTTPS
      initialDelaySeconds: 5
      timeoutSeconds: 1
---
apiVersion: v1
kind: Pod
metadata:
  name: probe-tcp
  namespace: coocla
spec:
  containers:
  - name: nginx
    image: nginx
    livenessProbe:
      initialDelaySeconds: 5
      timeoutSeconds: 1
      tcpSocket:
        port: 80

关于kubectl资源创建的语法可以参考: kubernetes技术学习之—Construct语法 

我们使用上面的construct创建资源:

kubectl create -f probe.yaml
kubectl get event

通过event我们可以发现对应的container由于probe监测失败一直处于循环重启中,其事件原因:unhealthy 

1C154BAA-20AA-4F30-985D-0A4913A483BA 

Kubernetes 容器自愈机制:Liveness Probe Liveness Probe 是 Kubernetes 容器健康检测的重要工具,通过 HTTP GET、TCP Socket 和 Exec 等多种方式来探测容器是否健康,并可以根据应用需求进行高级配置,如延迟启动、探测周期、失败阈值等。的工作机制及其不同配置方式。Liveness Probe 是用于检测容器健康状况的关键工具,可以在容器出现问题时进行自动恢复操作,如重启容器,确保系统的稳定性和可用性。,如果文件存在且命令执行成功(返回状态码为 0),则表示容器健康,否则 Kubernetes 将重启容器。 阅读详情

相关推荐

K8S Deployment Scripts Grammars

Kubernetes中的readinessProbe和livenessProbe是两种重要的容器健康检查机制。readinessProbe用于判断容器是否准备好接收流量,成功则加入负载均衡,失败则移除;适合处理应用初始化场景。livenessProbe检测容器是否存活,失败会触发重启,适用于处理死锁等故障。启动时会先执行startupProbe(如有),之后二者按配置时间间隔运行。它们都支持exec、httpGet和tcpSocket三种检测方式,且可以同时使用,确保服务可靠性和自动恢复能力。

summer_fish的专栏 844

K8S 三种探针 readinessProbe、livenessProbe和startupProbe

介绍 K8S 提供了3种探针 readinessProbe livenessProbe startupProbe(这个1.16版本增加的) 1、startupProbe readinessProbe:指示容器是否准备好服务请求(是否启动完成并就绪)。绪探针初始延迟之前的就绪状态默认为Failure,待容器启动成功弹指指标探测结果为成功后,状态变更为 Success。如果未配置就绪探针,则默认状态为Success。 只有状态为 Success ,才会被纳入 pod 所属 service 中,也就是

Jerry00713的博客 3万+

【信息科学与工程学】计算机科学与自动化 第二百零一十一 软件开发模型01

编号类型模型领域模型中的知识点/因素/参数关联知识和法律法规1传统顺序模型瀑布模型 (Waterfall)通用软件开发、硬件紧密耦合系统、政府/军工项目、需求稳定的传统信息系统严格线性阶段:可行性研究→需求分析(SRS,含功能/非功能/接口/约束,使用IEEE 830模板)→系统设计(概要设计HLD:架构、模块划分、数据库ER图;详细设计LLD:伪代码、类图、接口定义)→实现(编码规范、代码审查、静态分析工具SonarQube)→测试(单元测试JUnit、集成测试、系统测试、验收测试UAT,测试计划提前编写

weixin_49199313的博客 160

存活探针(Liveness Probe)

存活探针 Kubernetes提供了自愈的能力,具体就是能感知到容器崩溃,然后能够重启这个容器。但是有时候例如Java程序内存泄漏了,程序无法正常工作,但是JVM进程却是一直运行的,对于这种应用本身业务出了问题的情况,Kubernetes提供了Liveness Probe机制,通过检测容器响应是否正常来决定是否重启,这是一种很好的健康检查机制。 毫无疑问,每个Pod最好都定义Liveness Probe,否则Kubernetes无法感知Pod是否正常运行。 Kubernetes支持如下三种探测机制。 HT

weixin_44524077的博客 4444

【信息科学与工程学】【安全领域】第八十七篇 网络空间安全中的数学物理约束01

密码学基础(对称加密/公钥加密/哈希/数字签名)密码分析学(差分分析/线性分析/侧信道)安全协议与形式化验证(认证协议/TLS/密钥交换)访问控制与身份认证(Bell-LaPadula/BIBA/RBAC/ABAC)网络安全与攻防对抗(DDoS/入侵检测/攻防博弈)恶意代码分析(传播动力学/图论模型)隐私保护(差分隐私/同态加密/多方计算)可信计算与硬件安全(TPM/侧信道/故障注入)风险评估与漏洞管理(CVSS/攻击图/贝叶斯网络)信息论安全(完善保密性/熵/信息泄露量化)约束:侧信道攻击中的功耗模型(R

weixin_49199313的博客 558

C语言头文件完全解析(连“#”我都给你讲明白)

C语言头文件完全解析 引言 本文将尽量详细的介绍c语言的头文件所包含的知识,如有错误,还望指正。 萌新们肯定疑惑为什么每次打代码都要写一个所谓的头文件(如:#include<stdio.h>),这里先简单让大家有个了解,你所用的 printf("%d",a)就是这个 stdio里的东西,如果没有这个头文件,编译器都不知道 printf是个什么东东。所以头文件就是一个准备好的大仓库,你可...

CRAZY_eyes的博客 7万+

Kubernetes Liveness and Readiness Probes

在设计关键任务、高可用应用程序时,弹性是要考虑的最重要因素之一。当应用程序可以快速从故障中恢复时,它便具有弹性。云原生应用程序通常设计为使用微服务架构,其中每个组件都位于容器中。为了确保...

dotNET跨平台 246

四十二、Fluent欧拉模型流化床模拟:从基础设置到颗粒动力学解析

本文详细解析了Fluent欧拉模型在流化床模拟中的应用,从基础概念到颗粒动力学设置全面覆盖。重点介绍了欧拉模型的颗粒温度概念、多相流配置技巧以及关键参数优化策略,帮助工程师准确模拟气固两相流动现象。通过实用案例演示了网格检查、求解器配置和边界条件设置的最佳实践。

weixin_27303545的博客 445

Liveness and Readiness Probes with Spring Boot

Engineering Brian Clozel March 25, 2020 Update: this blog post has been updated for changes released in Spring Boot 2.3.0.RC1 The Spring Boot team is actively working on a Kubernetes theme for the next 2.3.0 release. After Docker images creation and Gracef

[Blog][Domain] programb.blog.youkuaiyun.com 580

MRI脑影像分析从哲学到技术:一文搞懂VBM预处理基本原理(全网最详细解析)

   分析大脑解剖学差异最常用方法之一是基于体素的形态学方法(voxel-based morphometry, VBM)。 VBM的基本思想是测量大脑组织,尤其是灰质的局部浓度的差异。在大脑的每个体素处进行操作,然后在两个或多个实验组之间进行统计比较,从而在受调查的组之间建立特定大脑区域中脑组织浓度的统计学显着差异。 VBM分析基于(高分辨率)MRI脑部扫描,涉及大量处理步骤,主要是空间归一化,分割,平滑和统计分析,最终结果是统计图,显示了各组之间组织类型明显不同的区域[^1]。 参考 [^1] ..

意疏的学习笔记 3万+

COMSOL仿真教程—激光烧蚀

本例使用二维模型,将来自激光的入射热通量模拟为金属表面上空间分布的热源,从而得到金属的烧蚀过程和瞬态温度分布。

qq_40977332的博客 2万+

kubernetes之pod生命周期

参考:https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/ Pod phase 系统中表示pod的条目包含一个表示pod状态的字段,称为“status”。“status”字段本身是一个“PodStatus”类型的对象,其中包含一个“phase”字段,用来表示pod当前所处的生命周期状态。以下是“phase”可能的取值...

山不转的博客 3628

基于YOLOv5的仪表读数识别系统:从检测到识别的完整解决方案

随着工业自动化水平的不断提高,仪表读数识别技术在电力系统、石油化工、智能制造等领域发挥着越来越重要的作用。本文提出了一种基于YOLOv5的仪表自动读数识别系统,该系统能够有效区分指针式和数字式仪表,并实现高精度的读数识别。我们详细介绍了系统的整体架构、数据集构建、模型训练策略以及用户界面设计,并提供了完整的代码实现。实验结果表明,本系统在仪表检测和读数识别任务上均取得了优异的表现,为工业现场的自动化监控提供了可靠的技术支持。关键词:仪表读数识别;YOLOv5;目标检测;深度学习;工业自动化。

YOLO 680

k8s的可观测性

在应用和 Kubernetes 环境中,**可观测性**测试的目标是确保应用的健康状态、资源使用情况和日志信息都能够实时监控和诊断。这样的测试有助于快速发现问题并作出相应的调整。具体来说,您提到的三个方面都与 **可观测性** 的核心要素密切相关:**健康状态监测**、**资源使用监控** 和 **日志分析**。下面将详细介绍如何进行这些方面的测试,以及常用的工具和方法。

qq_35861084的博客 1557

Pointnet++改进90:2025最新改进模块-EVA模块

本教程提出了一种改进PointNet++特征提取模块的方法,通过在PointNetSetAbstraction模块中加入NAMAttention注意力机制,显著提升了模型性能。具体改进包括:1)新建eva.py文件,实现了包含SDLSKA、CKS等关键组件的EVA模块;2)在pointnet2_utils.py中添加Conv和PointNetSetAbstractionAttention类,整合注意力机制;3)修改pointnet2_sem_seg.py模型结构。这种改进方法降低了实现难度,同时保持了33F

AIcurator的博客 361

Ubuntu 22.04+/WSL2 中解决 `error: externally-managed-environment` 并成功安装 PyTorch + vLLM 的完整指南

Ubuntu 22.04+/WSL2 因遵循 PEP 668 规范,系统 Python 被标记为“外部管理”,导致直接使用 pip install 安装包时报错 externally-managed-environment。解决方案是创建虚拟环境: 通过 python3 -m venv ~/vllm-env 创建隔离环境 激活环境后安装 PyTorch(CUDA 12.1)和 vLLM 避免使用 sudo pip 或 --break-system-packages,防止破坏系统依赖 关键点: 虚拟环

刘一说的IT专栏 298

微服务韧性验证实战:用 LitmusChaos 演练网络延迟、Pod 删除与依赖服务故障

> 本文以开源混沌工程平台 LitmusChaos 的真实用户实践为引子,完整还原一位全栈开发者利用 Litmus 对 4 个相互通信的微服务进行韧性验证的过程——手动测试全部通过,混沌测试却暴露出 API 缺少超时机制的缺陷,并最终推动了系统架构重构。围绕这一案例,文章将案例中出现的三类故障(网络延迟、Pod 删除、依赖服务不可用)逐一映射到 LitmusChaos 的具体混沌实验,并结合仓库中

gitblog_00939的博客 769

Spec Kit:GitHub 官方推出的规范驱动开发工具包,让 AI 编程真正可控、高效、高质量

先明确“做什么”和“为什么”,再考虑“如何做”。它通过一系列标准化命令(如/specify/plan/implement可验证的功能规格(spec)可执行的技术方案(plan)可追溯的开发任务(tasks)高质量的实现代码(code)最终实现“规范即代码,代码即规范”的闭环。📌项目地址许可证:MIT(完全开源,欢迎贡献)Spec Kit 代表了 GitHub 对AI 原生开发(AI-Native Development)AI 不应替代开发者,而应放大开发者的意图。

lpfasd123的博客 1713

存活探针(Liveness)、就绪探针(Readiness)、启动探针(Startup)

首先,如果没有定义就绪探针,那么新创建的pod就会立即加入到service的endpoint列表,如果容器里的业务程序需要很长时间才能开始处理传入的链接,而此时service又将客户端连接转发给了该pod,那么客户端就会看到“连接被拒绝”等类型的错误,所以,为每个容器定义一个就绪探针是很有必要的,即使是定义一个简单的http get 探针。

fhw925464207的博客 4053

IEM模型,地表粗糙度模拟

利用微波反演土壤水分时候,利用IEM模型可以实现对随机地表的模拟

文档:亲测可用解决vnc灰屏,黑屏,鼠标大黑叉情况

主要解决vnc-viewer灰屏,黑屏,鼠标大黑叉等现象,详细见文档。

14.Kubernetes 存活性探针(Liveness Probe)详解

区分存活性与就绪性探针 存活探针关注容器是否正常运行(失败触发重启),就绪探针关注容器是否准备好接收流量(失败则从 Service 中移除)。对启动耗时的应用(如加载大数据文件),需配置 startupProbe 延迟 livenessProbe 检测,防止启动阶段被误重启。避免与启动探针冲突 若容器启动较慢,需配合 启动探针(Startup Probe) 使用,确保存活探针不会在启动阶段误判。依赖外部资源的服务 若服务因依赖项故障(如数据库连接失败)无法运行,探针可重启容器尝试恢复。

Evan的博客 1433

WINCC7.3破解文件

WINCC7.3硬件够破解文件,有需要的下载!WINCC7.3硬件够破解文件,有需要的下载!

Kubernetes 健康检查之 livenessProbe/readinessProbe

Kubernetes三种探针 k8s支持存活livenessProbe和就绪readinessProbe两种探针,两种探针都支持以下三种方式 一、exec 通过执行shell命令的方式,判断退出状态码是否是0,示例: exec: command: - cat - /tmp/healthy 二、tcp 通过TCP请求的方式,是否能建立tcp连接,示例: tcpSocket: port: 808.....

小楼一夜听春雨,深巷明朝卖杏花 1万+

ssm框架搭建

这个是一个在idea上成功跑起来的ssm框架项目,保存在这里方便以后使用直接下载

DCOS之k8s的容器监测探针

大部分的应用程序我们在部署的时候都会适当的添加监控,对于运行载体容器则更应该如此。kubernetes提供了 liveness probes来检查我们的应用程序。它是由节点上的kubelet定期执行的。 首先说一下Pod的整个生命阶段: Pending:表示集群系统正在创建Pod,但是Pod中的container还没有全部被创建,这其中也包含集群为container创建网络,或者下载镜像的时间;

公众号 1万+

k8s-故障转移 livenessProbe & readinessProbe 学习总结

k8s-故障转移 livenessProbe 存活探测实例 readinessProbe就绪探测实例 springboot例子

liuyij3430448的博客 2961

K8S的pod探针(livenessProbe,readinessProbe),kubelet对pod的状态检查(kubelet-exec,httpGet,tcpSocket)

1、kubelet的探测方式 2、livenessProbe探针 2.1、livenessProbe和kubelet-exec 2.2、livenessProbe和kubelet-httpGet 2.3、livenessProbe和kubelet-tcpSocket 3、readinessProbe探针 3.1、readinessProbe和kubelet-exec 3.2、readinessProbe和kubelet-httpGet 3.3、readinessProbe和kubelet-tcpSocke.

DLWH_HWLD的博客 4907
上一篇: kubernetes--应用程序健康检查
下一篇: Kubernetes应用健康检查
王树民
博客等级 码龄10年 912粉丝 560原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值