k8s应用监控探针详解
作者:wffeige
这篇文章主要为大家介绍了k8s应用监控探针的使用详解,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
应用监控
参考 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应用监控探针的资料请关注脚本之家其它相关文章!