• Geek_9190ca
    2023-02-09 来自福建
    k8s极简实践希望加上存储章节

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

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

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

    
    2
  • xmr
    2023-07-08 来自广东
    1.通过脚本定时检查进程是否存在,进程不存在则拉去

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

    
    1
  • Geek_28f561
    2023-02-21 来自北京
    老师上章节您讲HPA根据cpu或内存使用率扩容pod。请教一下,如何通过自定义指标扩容node主机节点呢。

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

    
    1
  • êwěn
    2023-01-04 来自广东
    如果服务接受流量后触发了bug,导致假死,这种如何快速发现呢?

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

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

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

    
    
  • ghostwritten
    2023-01-04 来自广东
    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
    2023-01-04 来自广东
    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中的所有容器已准备就绪。
    展开

    作者回复: 👍

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

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

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

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

    
    