云原生架构与 GitOps 实战
王炜
前腾讯云 CODING 架构师
5442 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 44 讲
云原生架构与 GitOps 实战
15
15
1.0x
00:00/00:00
登录|注册

12|如何自动检查业务真实的健康状态?

你好,我是王炜。今天是 kubernetes 极简实战这一章的最后一课。
在上一节课中,我们学习了如何为工作负载配置资源配额,还详细介绍了资源 Request 和 Limit 的含义和用法。此外,我们还重点学习了如何为业务配置水平扩容(HPA),当业务面临较大的请求流量时,它能够实现自动扩容。
当触发自动扩容时,工作负载的 Replicas 字段将被调整,然后 ReplicaSets 对象将创建新的 Pod 副本,这些副本在未就绪(Ready)之前,我们观察到的现象是 kubernetes 不会将流量转发到这些 Pod 上。那么,你有没有考虑过,kubernetes 是怎么判断新创建的 Pod 是否已经处于“就绪”状态的呢?
对于启动时间比较慢的业务应用来说,启动阶段并不等于就绪,这是一个非常典型的场景,既然如此,我们怎么告诉 kubernetes 什么时候可以接收请求流量?
再说另一个我们上节课提到的场景,如果业务应用没有做好垃圾回收或者产生死锁,那么再运行一段时间后,它的内存和 CPU 消耗会迅速飙升。显然,这时候 Pod 已经处于不健康状态了,怎么让 kubernetes 识别并将它重启呢?
要解决这两个问题,我们需要使用到 kubernetes 的健康检查
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《云原生架构与 GitOps 实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(12)

  • 最新
  • 精选
  • Geek_9190ca
    k8s极简实践希望加上存储章节

    作者回复: 很好的建议👍🏻

    归属地:福建
    3
  • 郑海成
    1. 非k8s架构下其实也是通过探测来实现的只不过探测工具是自己的脚本和工具不一样。比如startupProbe可以通过查看进程是否存在、端口判断否启动;readinessProbe可以通过业务暴露的探活接口、真实业务接口来判断,但是摘除流量需要依赖负载均衡器的能力;livenessProbe也可以通过接口来判断但是重启就需要自己通过脚本来实现。在k8s架构下kubelet就像一位你的运维同事帮你把这些活儿给做了

    作者回复: 非常正确,传统架构下要把这些能力串起来不是一件容易的事。K8s 实际上把这些问题都抽象成能力了,这些开箱即用的能力可以帮助我们构建弹性,高可用的业务系统。

    归属地:北京
    2
  • xmr
    1.通过脚本定时检查进程是否存在,进程不存在则拉去

    作者回复: 是的,还可以结合 crontab。

    归属地:广东
    1
  • Geek_28f561
    老师上章节您讲HPA根据cpu或内存使用率扩容pod。请教一下,如何通过自定义指标扩容node主机节点呢。

    作者回复: Node 节点动态扩容(cluster-autoscale)一般由云厂商直接实现,具体用法你可以看这个文档:https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler

    归属地:北京
    1
  • êwěn
    如果服务接受流量后触发了bug,导致假死,这种如何快速发现呢?

    作者回复: 可以用 Liveness 探针来检查存活状态,如果业务无法返回 200 那么 K8s 会自动重启它。

    归属地:广东
    1
  • 争光 Alan
    如果存活和就绪配置一样,就会导致业务压力上来后本来应该摘除流量,结果业务重启了,这样场景有什么最佳实践吗?是默认存活比就绪配置的久检查一些?

    作者回复: 这是一个很好的真实场景,你提到的做法可以缓解这个问题,更好的做法可能是结合 istio 配置熔断机制,也就是在业务高峰的时候保护后端服务,避免雪崩。比如一些网站在双11流量高峰的时候对于新的流量会直接提示人数过多,请稍后再试。 此外,还可以结合 HPA,配置低一点的阈值,在业务高峰来之前快速把副本数量拉高,如果是业务高低峰非常明显的业务,可以定时进行扩缩容。

    归属地:广东
  • ghostwritten
    4. 探针: - Readiness:又称为就绪探针,它用来确定 Pod 是否为就绪(Ready)状态,以及是否能够接收外部流量。 - Liveness: 又称为存活探针,相比 Readiness 探针,它还能够在检测到 Pod 处于不健康状态时自动将 Pod 重启,(重启条件需要restartPolicy是 Always或OnFailure,默认是 Always) - StartupProbe:适用于业务应用启动慢的场景。当 Pod 启动时,如果配置了 StartupProbe,那么 Readiness 和 Liveness 探针都将被临时禁用,直到 StartupProbe 探针返回成功才会启用 Readiness 和 Liveness 探针 参数: - `initialDelaySeconds` 的含义是在容器启动之后,延迟 10 秒钟再进行第一次探针检查。 - `failureThreshold` 的含义是,如果连续 5 次探针失败则代表 Readiness 探针失败,Pod 状态为 NotReady,此时 Pod 不会接收外部请求。 - `periodSeconds` 的含义是探针每 10 秒钟轮询检测 1 次。 - `successThreshold` 的含义是只要探针成功 1 次就代表探针成功了,Pod 状态为 Ready 表示可以接收外部请求。 - `timeoutSeconds` 代表探针的超时时间为 1 秒。 5. TCP 探测: spec: containers: - name: flask-backend image: lyzhang1999/backend:latest ports: - containerPort: 5000 readinessProbe: tcpSocket: port: 5000 initialDelaySeconds: 10 failureThreshold: 5 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1 livenessProbe: tcpSocket: port: 5000 initialDelaySeconds: 10 failureThreshold: 5 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1

    作者回复: 正确

    归属地:广东
  • ghostwritten
    1. Pod 的生命周期一共有下面这 5 个状态: - Pending:正在创建 Pod,例如调度 Pod 和拉取镜像的阶段。 - Running:运行阶段,至少有一个容器正在启动或运行。 - Succeeded:运行成功,并且不会重新启动,例如 Job 创建的 Pod。 - Failed:Pod 的所有容器都停止了,并且至少有一个容器退出状态码非 0。Unknown:无法获取 Pod 的状态。 2. Pod 中的容器,也有下面 3 种状态: - `Waiting`:容器等待中,例如正在拉取镜像。 - `Running`:容器运行中,PID=1 的业务进程正在启动或运行。 - `Terminated`:容器终止中,例如正在删除 Pod。 3. Pod具有PodStatus,该状态具有`PodConditions`数组 ,该Pod已通过或未通过。PodCondition数组的每个元素都有六个可能的字段: - 该`lastProbeTime`字段提供上次探测Pod条件的时间戳。 - 该`lastTransitionTime`字段提供Pod上一次从一种状态转换为另一种状态的时间戳。 - 该`message`字段是人类可读的消息,指示有关过渡的详细信息。 - 该`reason`字段是条件最后一次转换的唯一单词CamelCase原因。 - 该`status`字段是一个字符串,可能的值为“ True”,“ False”和“ Unknown”。 - 该`type`字段是具有以下可能值的字符串: - PodScheduled:Pod已调度到一个节点; - Ready:Pod能够处理请求,应将其添加到所有匹配服务的负载平衡池中; - Initialized:所有初始化容器 已成功启动; - Unschedulable:例如,由于缺乏资源或其他限制,调度程序无法立即调度Pod; - ContainersReady:Pod中的所有容器已准备就绪。

    作者回复: 👍

    归属地:广东
  • 橙汁
    发现三处亮点 1.pod和容器的状态分别进行介绍,这差距 以前的文章都是pod状态多少多少种,基本没有提容器状态,这么一看理解更清晰 2.以前碰到过deployment进行更新时,会出现pod并未就绪就加入到endpoint里面,看完文章原来还是健康检查未理解 3.原来健康检查代表你的可用性,是有数据支持的 比如检测次数 间隔多久,这样说啥都有数据来支撑 真tm吊

    作者回复: 感谢你的认可~

    归属地:广东
  • includestdio.h
    1. 在我印象里我最初接触到的健康检查方式是Nginx upstream_check_module 开源模块实现的,一般是在 Nginx 作为反代的时候会用到 2. readinessProbe: tcpSocket: port: 5000

    作者回复: 是的,还有一种是类似于云监控的产品也能做健康检查,不过这两种健康检查都不能和重启策略直接关键起来。

    归属地:广东
收起评论
显示
设置
留言
12
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部