k8s应用监控探针详解

目录
  • 应用监控
  • pod状态转换
    • pod的启动流程?
  • Pod支持的监测类型(健康探针)
  • 监测机制
  • 配置参数
  • 示例
  • image pull policy 镜像管理策略

应用监控

参考 https://www.jb51.net/article/241418.htm

在pod之上 添加一个探针, kubelet通过探针去检查应用

pod状态转换

pod的启动流程?

  • schduler环节 先绑定节点
  • kubelet接管
    • 准备CNI CSI CRI
    • 启动pod中的container
    • 启动探针
    • 存活探针
      • 监测pod是否健康
    • 就绪探针

容器式运行的应用类似于“黑盒”,默认不会配置探针时 所以kublet只会监视pod的存活状态(但是无法检查是否处于正常的服务 对于pod不处理请求的情况无法检查 不能执行一些高级的检查)

为了便于k8s对其进行监测，云原生应用应该输出用于监视自身的API

  • 包括健康状态、指标、分布式跟踪和日志等
  • 最基本要提供用于健康状态监测的API

Pod支持的监测类型(健康探针)

  • startup Probe 启动探针，用来检查应用是否已经启动成功，适合那些有大量初始化工作要做，启动很慢的应用
  • liveness Probe 存活探针，用来检查应用是否正常运行，是否存在死锁、死循环
  • readiness Probe 就绪探针，用来检查应用是否可以接收流量，是否能够对外提供服务。

监测机制

  • Exec Action：执行一个 Linux 命令看状态码，根据指定命令的结果状态码判定,
  • TcpSocket Action：使用TCP协议尝试连接容器的指定端口，根据相应TCP套接字连接建立状态判定
  • HTTPGet Action：连接端口并发送 HTTP GET 请求, 根据指定https/http服务URL的响应结果判定

配置参数

initialDelaySeconds

periodSeconds: 执行探测动作的时间间隔，默认是 10 秒探测一次。

timeoutSeconds: 探测动作的超时时间，如果超时就认为探测失败，默认是 1 秒。successThreshold: 连续几次探测成功才认为是正常，对于 startupProbe 和 livenessProbe 来说它只能是 1。

failureThreshold: 连续探测失败几次才认为是真正发生了异常，默认是 3 次。

示例

同时定义了三种探针

  • startup使用Exec Action
  • liveness和readiness使用HTTPGet Action

测试效果

  • liveness

    • URL "/livez" 支持以POST方法为livez参数设定不同值，非OK值都以5xx响应码响应；
  • readiness
    • URL "/readyz" 支持以POST方法为readyz参数设定不同值，非OK值都以5xx响应码响应；

image pull policy 镜像管理策略

Always 无论本地是否有相关的镜像 总是要到registry上下载 - 缺点 浪费带宽 - 好处 避免本地污染

if not present 本地不存在相关的image是 才去registry上下载 - 好处 运行快 - 缺点 可能被污染 never 从不下载

特殊情况 image 的tag是latest

apiVersion: v1
kind: Pod
metadata:
    name: pod-probe-demo
    namespace: default
spec:
    containers:
    - name: demo
    image: ikubernetes/demoapp:v1.0
    imagePullPolicy: IfNotPresent
    startupProbe:
        exec:
            command: ['/bin/sh','-c','test','"$(curl -s 127.0.0.1/livez)"=="OK"']
        initialDelaySeconds: 0
        failureThreshold: 3
        periodSeconds: 2
    livenessProbe:
        httpGet:
            path: '/livez'
            port: 80
            scheme: HTTP
        initialDelaySeconds: 3
        timeoutSeconds: 2
    readinessProbe:
        httpGet:
            path: '/readyz'
            port: 80
            scheme: HTTP
        initialDelaySeconds: 15
        timeoutSeconds: 2
    restartPolicy: Always

以上就是k8s应用监控探针详解的详细内容，更多关于k8s应用监控探针的资料请关注我们其它相关文章！

赞 (0)

相关推荐

  • K8S 实用工具之合并多个kubeconfig实现详解

    目录 开篇 解决方案 方案一:KUBECONFIG 环境变量指向多个文件 方案二:flatten 方案三:kubectl 插件 konfig 实用工具:krew 实用工具:konfig 总结 开篇 磨刀不误砍柴工 工欲善其事必先利其器 K8S 集群规模,有的公司倾向于少量大规模 K8S 集群,也有的公司会倾向于大量小规模的 K8S 集群. 如果是第二种情况,是否有一个简单的 kubectl 命令来获取一个 kubeconfig 文件并将其合并到 ~/.kube/config 文件作为一个额外的上

  • k8s编排之StatefulSet知识点详解一

    目录 正文 StatefulSet 的设计理解 Service 如何被访问 Headless Service 对应的 YAML文件 StatefulSet 的 YAML 文件 解析一下 Pod 对应的 Headless Service 正文 Deployment认为,一个应用的所有 Pod,是完全一样的.所以,它们互相之间没有顺序,也无所谓运行在哪台宿主机上.需要的时候,Deployment 就可以通过 Pod 模板创建新的 Pod:不需要的时候,Deployment 就可以“杀掉”任意一个 P

  • k8s编排之DaemonSet知识点详解

    目录 如何对 StatefulSet 进行“滚动更新”(rolling update)? 下面重点讲解一个\知识点:DaemonSet 列举几个例子: API 对象的定义 如何在指定的 Node 上创建新 Pod 呢? nodeAffinity 含义 如何对 StatefulSet 进行“滚动更新”(rolling update)? 你只要修改 StatefulSet 的 Pod 模板,就会自动触发“滚动更新”: kubectl patch statefulset mysql --type='j

  • k8s实现身份认证策略及过程解析

    目录 身份认证策略 API Server启用的身份认证机制 kubelet启用的身份认证机制 X.509数字证书认证 静态令牌文件 Service Account令牌 OpenID Connect(OIDC)令牌 Webhook令牌认证 身份认证代理 静态令牌认证配置案例 静态令牌认证的基础配置 配置示例 X509 数字证书认证 所有的证书 X509数字证书认证测试 身份认证策略 X.509客户端证书认证 持有者令牌(bearer token) 静态令牌文件(Static Token File)

  • k8s编排之StatefulSet知识点详解二

    目录 StatefulSet 对存储状态的管理机制 第一步:定义一个 PVC,声明想要的 Volume 的属性 第二步:在应用的 Pod 中,声明使用这个 PVC 常见的 PV 对象的 YAML 文件 StatefulSet 对存储状态的管理机制 这个机制,主要使用的是一个叫作 Persistent Volume Claim 的功能. 要在一个 Pod 里声明 Volume,只要在 Pod 里加上 spec.volumes 字段即可.然后,你就可以在这个字段里定义一个具体类型的 Volume 了

  • k8s部署redis集群搭建过程示例详解

    目录 写在前面 一.redis集群搭建 1.1使用redis-cli创建集群 1.2redis集群状态验证(可选) 1.3重启pod,验证集群(可选) 1.4创建Service服务 1.5 Springboot项目配置 1.6相关疑问分析 写在前面 在上一篇文章中,我们已经做到了已经创建好6个redis副本了. 具体的详情,可以查看这里:k8s部署redis集群(一) 那么接下来,我们就继续实现redis集群的搭建过程. 一.redis集群搭建 1.1使用redis-cli创建集群 # 查看re

  • k8s部署redis集群实现过程实例详解

    目录 写在前面 前置准备 一.nfs安装 二.SC.PV 创建 2.1创建SC 2.2创建PV 三.redis集群搭建 3.1创建headless服务 3.2创建redis对应pod集群 写在前面 一般来说,REDIS部署有三种模式. 单实例模式,一般用于测试环境. 哨兵模式 集群模式 后两者用于生产部署 哨兵模式 在redis3.0以前,要实现集群一般是借助哨兵sentinel工具来监控master节点的状态. 如果master节点异常,则会做主从切换,将某一台slave作为master. 引

  • k8s编排之Deployment知识点详解

    目录 Pod 复杂的API对象 nginx-deployment Deployment 及类似控制器总结 Deployment 所控制的 ReplicaSet查看 Pod 复杂的API对象 Pod 这个看似复杂的 API 对象,实际上就是对容器的进一步抽象和封装而已. 说得更形象些,“容器”镜像虽然好用,但是容器这样一个“沙盒”的概念,对于描述应用来说,还是太过简单了.这就好比,集装箱固然好用,但是如果它四面都光秃秃的,吊车还怎么把这个集装箱吊起来并摆放好呢? 所以,Pod 对象,其实就是容器的

  • k8s应用监控探针详解

    目录 应用监控 pod状态转换 pod的启动流程? Pod支持的监测类型(健康探针) 监测机制 配置参数 示例 image pull policy 镜像管理策略 应用监控 参考 https://www.jb51.net/article/241418.htm 在pod之上 添加一个探针, kubelet通过探针去检查应用 pod状态转换 pod的启动流程? schduler环节 先绑定节点 kubelet接管 准备CNI CSI CRI 启动pod中的container 启动探针 存活探针 监测p

  • docker cgroup 资源监控的详解

    docker cgroup 资源监控的详解 1.cgroup术语解析: blkio: 这个subsystem可以为块设备设定输入/输出限制,比如物理驱动设备(包括磁盘.固态硬盘.USB等). cpu: 这个subsystem使用调度程序控制task对CPU的使用. cpuacct: 这个subsystem自动生成cgroup中task对CPU资源使用情况的报告. cpuset: 这个subsystem可以为cgroup中的task分配独立的CPU(此处针对多处理器系统)和内存. devices

  • Python实现B站UP主自动监控功能详解

    Python实现B站UP主自动监控功能详解

    目录 开发工具 环境搭建 原理简介 1.确定小目标 2.模拟登录 3.自动关注 4.实时监控 效果展示 众所周知,B站有很多有趣的UP主,可以教大家一些"实用"的知识: 但是他们一般都没有固定的更新时间,那么如何才能第一时间知道自己又有新的饭点可以看的下饭素材呢?当然是用python来写个脚本自动监控UP是否更新了视频,并自动下载啦~ 废话不多说,让我们愉快地开始吧~ 开发工具 Python版本:3.7.8 相关模块: DecryptLogin模块: videofetch模块: 以及一

  • Spring boot admin 服务监控利器详解

    Spring boot admin 服务监控利器详解

    目录 一.简介 二.搭建 1.服务端 2.客户端 3.启动项目 4.客户端配置 3.微服务 3.1.服务端 3.2.客户端 4.我的微服务预警发送其他服务状态信息思路 一.简介 用于对 Spring Boot 应用的管理和监控.可以用来监控服务是否健康.是否在线.以及一些jvm数据等等.Spring Boot Admin 分为服务端(spring-boot-admin-server)和客户端(spring-boot-admin-client),服务端和客户端之间采用 http 通讯方式实现数据交

  • Java SpringBoot快速集成SpringBootAdmin管控台监控服务详解

    Java SpringBoot快速集成SpringBootAdmin管控台监控服务详解

    目录 1.初识SpringBootAdmin 2.搭建服务端--POM文件中添加相关依赖 3.修改服务端application启动类 4.配置security安全信息 5.启动server服务端 6.搭建client客户端 总结 SpringBootAdmin是一个针对 Spring Boot 的 Actuator 接口进行 UI 美化封装的监控工具,它可以在列表中浏览所有被监控 spring-boot 项目的基本信息.详细的 Health 信息.内存信息.JVM 信息.垃圾回收信息.各种配置信

  • K8S 中 kubectl 命令详解

    K8S 中 kubectl 命令详解

    目录 一.资源管理办法 1.1 陈述式资源管理方法 查看版本信息 查看资源对象简写 查看集群信息 配置kubectl自动补全 node 节点查看日志 1.2基本信息查看 查看master 节点状态 查看命令空间 查看default命名空间的所有资源 create 创建命名空间 (app) delete 删除命名空间(app) 在命名空间创建副本控制器启动Pod 查看命名空间kube-public中的pod信息 kubectl exec 登录容器 重启(删除)pod资源 扩容缩容 删除副本控制器

  • 基于python的Linux系统指定进程性能监控思路详解

    监控Linux服务器的工具.组件和程序网上有很多,但是一台服务器上会有很多进程同时运行,特别是做性能测试的时候,可能一台服务器上部署多个服务,如果只监控整个服务器的CPU和内存,当某个服务出现性能问题时,并不能有效准确的定位出(当然通过其他工具也可以实现),因此,很有必要只监控指定的进程.需求明确了,于是动手撸了一个性能监控脚本. 一.整体思路 1.为了方便的启动监控和停止监控,在想查看监控结果的时候随时查看监控结果,用flask开启了一个服务,通过发送get请求可以随时启停监控和查看监控结果.

  • redis哨兵常用命令和监控示例详解

    sentinel monitor advertise 192.168.0.5 28001 2 sentinel set advertise client-reconfig-script /etc/redis/reconfig.sh sentinel flushconfig sentinel启动后需要手动将配置文件对应的调整为sentinel deny-scripts-reconfig no,否则不支持命令行runtime修改client-reconfig-script # SECURITY #

  • Android性能优化死锁监控知识点详解

    目录 前言 死锁检测 线程Block状态 获取当前线程所请求的锁 通过锁获取当前持有的线程 线程启动 nativePeer 与 native Thread tid 与java Thread tid dlsym与调用 系统限制 死锁检测所有代码 总结 前言 “死锁”,这个从接触程序开发的时候就会经常听到的词,它其实也可以被称为一种“艺术”,即互斥资源访问循环的艺术,在Android中,如果主线程产生死锁,那么通常会以ANR结束app的生命周期,如果是两个子线程的死锁,那么就会白白浪费cpu的调度资

  • 详解Docker容器可视化监控中心搭建

    详解Docker容器可视化监控中心搭建

    概述 一个宿主机上可以运行多个容器化应用,容器化应用运行于宿主机上,我们需要知道该容器的运行情况,包括 CPU使用率.内存占用.网络状况以及磁盘空间等等一系列信息,而且这些信息随时间变化,我们称其为时序数据,本文将实操 如何搭建一个可视化的监控中心 来收集这些承载着具体应用的容器的时序信息并可视化分析与展示! 动手了,动手了... 准备镜像 adviser:负责收集容器的随时间变化的数据 influxdb:负责存储时序数据 grafana:负责分析和展示时序数据 部署Influxdb服务 可以将

随机推荐