【探索 Kubernetes|作业管理篇 系列 10】Pod 健康检查和恢复机制

这篇具有很好参考价值的文章主要介绍了【探索 Kubernetes|作业管理篇 系列 10】Pod 健康检查和恢复机制。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

前言

大家好,我是秋意零。

上一篇中介绍了,Pod 的服务对象,从而对 Pod 有了更深的理解;

今天的主题是 Pod 健康检查和恢复机制,我们将结束 Pod 的内容。

最近搞了一个扣扣群,旨在技术交流、博客互助,希望各位大佬多多支持!在我主页推广区域,如图:

  • 【探索 Kubernetes|作业管理篇 系列 10】Pod 健康检查和恢复机制

文章底部推广区域,如图:

  • 【探索 Kubernetes|作业管理篇 系列 10】Pod 健康检查和恢复机制

👿 简介

  • 🏠 个人主页: 秋意零
  • 🧑 个人介绍:在校期间参与众多云计算相关比赛,如:🌟 “省赛”、“国赛”,并斩获多项奖项荣誉证书
  • 🎉 目前状况:24 届毕业生,拿到一家私有云(IAAS)公司 offer,暑假开始实习
  • 🔥 账号:各个平台, 秋意零 账号创作者、 云社区 创建者
  • 💕欢迎大家:欢迎大家一起学习云计算,走向年薪 30 万

【探索 Kubernetes|作业管理篇 系列 10】Pod 健康检查和恢复机制

系列文章目录


【云原生|探索 Kubernetes-1】容器的本质是进程
【云原生|探索 Kubernetes-2】容器 Linux Cgroups 限制
【云原生|探索 Kubernetes 系列 3】深入理解容器进程的文件系统
【云原生|探索 Kubernetes 系列 4】现代云原生时代的引擎
【云原生|探索 Kubernetes 系列 5】简化 Kubernetes 的部署,深入解析其工作流程



正文开始

  • 快速上船,马上开始掌舵了(Kubernetes),距离开船还有 3s,2s,1s…

【探索 Kubernetes|作业管理篇 系列 10】Pod 健康检查和恢复机制

一、健康检查

在 Kubernetes 中,Pod 的状态决定不了服务的状态,如:Pod 的状态是 running,而一个 Web 服务 Down 掉了,那么 Pod 对它是无感知的。本来我们理想是,这种服务 Down 掉之后,随之影响 Pod 的状态。所以我就需要==采用 Pod 的健康检查 “探针”(Probe),这样,kubelet 就会根据这个 Probe 的返回值决定这个容器的状态,而不是直接以容器镜像是否运行(来自 Docker 返回的信息)作为依据。是生产环境中保证应用健康存活的重要手段。

健康检查 “探针”(Probe)属于 Pod 生命周期范畴。

在 【探索 Kubernetes|作业管理篇 系列 8】探究 Pod 的 API 对象属性级别与重要字段用法,这篇中就介绍过 Pod 生命周期,遗忘了可以回头看看。

Kubernetes 中的 Pod 探针可以使用以下三种方式进行健康检查:

  • Exec 探针(Exec Probe)通过在容器内执行命令来检查容器的健康状态。Kubernetes 将定期执行指定的命令,并根据命令的退出状态码来判断容器是否健康。
  • HTTP 探针(HTTP Probe)通过向容器内指定的 HTTP 端点发送 HTTP 请求来检查容器的健康状态。Kubernetes 将检查请求的响应状态码,只有在响应码在指定的成功范围内时才认为容器是健康的。
  • TCP 探针(TCP Probe)通过尝试建立到容器内指定端口的 TCP 连接来检查容器的健康状态。如果连接成功建立,则认为容器是健康的;否则,认为容器是不健康的。

Exec 方式

举个栗子:

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: test-liveness-exec
spec:
  containers:
  - name: liveness
    image: nginx
    imagePullPolicy: IfNotPresent
    args:
    - /bin/sh
    - -c
    - touche /usr/share/nginx/html/test.html; sleep 15; rm -rf /usr/share/nginx/html/test.html
    livenessProbe:
      exec:
        command:
        - cat
        - /usr/share/nginx/html/test.html
      initialDelaySeconds: 5
      periodSeconds: 5

这个 Pod 中,最开始会创建 一个 /usr/share/nginx/html/test.html 文件,过 15 s 之后会删除这个 /usr/share/nginx/html/test.html 文件。

同时,定义了一个 livenessProbe(健康检查探针),它的动作是 exec 进去容器执行 cat /usr/share/nginx/html/test.html 查看文件内容,如果命令成功执行那么返回值会是 0,否则就不是 0,返回为 0 就代表当前服务是健康的。

注意:这个健康检查,在容器启动 5 s 后开始执行(initialDelaySeconds: 5),每 5 s 执行一次(periodSeconds: 5)。所以,可以将 initialDelaySecondsperiodSeconds 看作是用来控制健康检查动作的属性。

首先,创建这个 Pod:

[root@master01 yaml]# kubectl apply -f liveness.yaml
pod/test-liveness-exec created

然后,查看这个 Pod 的状态,使用 -w 监控状态:

[root@master01 yaml]# kubectl get -f liveness.yaml -w
NAME                 READY   STATUS    RESTARTS   AGE
test-liveness-exec   1/1     Running   0          7s

test-liveness-exec   0/1     Completed   0          16s
test-liveness-exec   1/1     Running     1 (1s ago)   17s
test-liveness-exec   0/1     Completed   1 (16s ago)   32s

上述中,可以看到 16s 时,Pod 的状态就不在是 Running 而是 Completed,这时我们查看 Events 事件:

  • 看到我们,使用健康检查的来检测文件不存在,说明此时 Pod 的状态是不健康的。
  • 而现在 Pod 的状态是 Completed 这就和 Pod 的重启策略有关了。
kubectl describe -f liveness.yaml

【探索 Kubernetes|作业管理篇 系列 10】Pod 健康检查和恢复机制

我们查看 17 s 之后,Pod 的状态变为了 Runing,说明了 Pod 以及重新启动过一次了,RESTARTS 字段可以看出重新启动的次数,如下:

[root@master01 yaml]# kubectl get -f liveness.yaml -w
NAME                 READY   STATUS    RESTARTS   AGE
test-liveness-exec   1/1     Running   0          7s

test-liveness-exec   0/1     Completed   0          17s
test-liveness-exec   1/1     Running     1 (2s ago)   18s
test-liveness-exec   1/1     Running     2 (1s ago)   33s

这时就有个疑问,最开始 Pod 没有进入 Failed 状态,而是进入 Completed 再保持 Running 状态。这是为什么呢?这就是 Pod 的重启策略(restartPolicy),也就是 Pod 的恢复机制。

HTTP 方式

cat > liveness-http.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: web-app
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
    livenessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 10
EOF

【探索 Kubernetes|作业管理篇 系列 10】Pod 健康检查和恢复机制

可以看到,我们 liveness-http 方式的 Pod,一直在运行(健康),并没有重启。

[root@master01 yaml]# kubectl get -f liveness-http.yaml
NAME     READY   STATUS    RESTARTS   AGE
my-pod   1/1     Running   0          3m57s

TCP 方式

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 10

二、就绪检测

就绪检测(Readiness Probe)是 Kubernetes 中的一项功能,用于确定 Pod 是否已准备好接收流量和处理请求。就绪检测主要用于控制 Pod 在启动后何时被添加到服务负载均衡器中,以确保只有处于就绪状态的 Pod 才能接收到流量。

这部分内容,会在讲解 Service 时重点介绍。

三、恢复机制

restartPolicy。它是 Pod 的 Spec 部分的一个标准字段(pod.spec.restartPolicy),默认值是 Always,即:任何时候这个容器发生了异常,它一定会被重新创建。

*需要强调的是

  • Pod 的恢复过程,永远都是发生在当前节点上,而不会跑到别的节点上去。
  • 事实上,一旦一个 Pod 与一个节点(Node)绑定,除非这个绑定发生了变化(pod.spec.node 字段被修改),否则它永远都不会离开这个节点。
  • 这也就意味着,如果这个宿主机宕机了,这个 Pod 也不会主动迁移到其他节点上去。

而如果你想让 Pod 出现在其他的可用节点上,就必须使用 Deployment 这样的 “控制器” 来管理 Pod,哪怕只需要一个 Pod 副本。

Pod 和 Deployment 的区别:如果 Pod 所在 Node 异常,那么该 Pod 不会被迁移到其他节点;而 Deployment 会由 Kubernetes 负责调度保障业务正常运行,会重新调度新 Node 节点运行。

可以通过设置 restartPolicy,改变 Pod 的恢复策略,取值如下:

  • Always:在任何情况下,只要容器不在运行状态,就自动重启容器;
  • OnFailure: 只在容器 异常时才自动重启容器;
  • Never: 从来不重启容器。

在实际使用时,我们需要根据应用运行的特性,合理设置这三种恢复策略。

比如,一个 Pod,它只计算 1+1=2,计算完成输出结果后退出,变成 Succeeded 状态。这时,你如果再用 restartPolicy=Always 重启这个 Pod 的容器,就没有任何意义了,所以这种情况使用 OnFailure 策略

而如果你要关心这个容器退出后的上下文环境,比如容器退出后的日志、文件和目录,就需要将 restartPolicy 设置为 Never。因为一旦容器被自动重新创建,这些内容就有可能丢失掉了(被垃圾回收了)。

Kubernetes 官方文档中,总结了一堆的情况。实践上,只需要记住下面两个基本的设计原理即可:

  • 只要 Pod 的 restartPolicy 指定的策略允许重启异常的容器(Always、OnFailure),那么这个 Pod 就会保持 Running 状态。否则,Pod 就会进入 Failed 状态 。
  • 对于包含多个容器的 Pod,只有它里面所有的容器都进入异常状态后,Pod 才会进入 Failed 状态。在此之前,Pod 都是 Running 状态。

总结

主要讲解了,Pod 的健康检查的基本概率,以及 Exec、HTTP、TCP 三种使用方式;

接着讲解了 Pod 的恢复机制,我们知道了,实际上 Pod 的恢复机制就是 Pod 的三种重启策略。

至此 Pod 的内容也基本介绍完了,目前剩下就绪检查的概率,这个后续会说明。

下一章将是控制器部分的内容。

最后:技术交流、博客互助,点击下方或主页推广加入哦!!

【探索 Kubernetes|作业管理篇 系列 10】Pod 健康检查和恢复机制文章来源地址https://www.toymoban.com/news/detail-493059.html

到了这里,关于【探索 Kubernetes|作业管理篇 系列 10】Pod 健康检查和恢复机制的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【探索 Kubernetes|作业管理篇 系列 14】StatefulSet 存储状态

    大家好,我是秋意零。 在上一篇中,我们讲解了 StatefulSet 的拓扑状态;我们发现,它的拓扑状态,就是顺序启动/删除、Pod 名称+编号命名、将 Pod 名称设为 Hostname 名称、通过 Service 无头服务的 DNS 记录访问。 今天,就来看看 StatefulSet 的存储状态。 最近搞了一个扣扣群,旨在

    2024年02月11日
    浏览(43)
  • 【探索 Kubernetes|作业管理篇 系列 15】DaemonSet 的”过人之处“

    大家好,我是秋意零。 在上一篇中,我们讲解了 StatefulSet 的存储状态;我们发现,它的存储状态,就是利用了 PV 与 PVC 的设计。StatefulSet 自动为我们创建 PVC 并且以 pvc-name-pod-name-编号 命名,从而始终与 Pod 编号名一致的绑定。 需要注意的是 :StatefulSet 的“滚动更新”是从最

    2024年02月11日
    浏览(33)
  • 【探索 Kubernetes|作业管理篇 系列 11】控制器的核心功能

    大家好,我是秋意零。 上一篇结束了 Pod 对象的内容。 今天要探讨的内容是 “控制器”,它是 Kubernetes 编排最核心的功能。理解了 “控制器”,你就能理解 Deployment、StatefulSet、DaemontSet、Job、CroJob 控制器对象。 最近搞了一个扣扣群,旨在技术交流、博客互助,希望各位大佬

    2024年02月11日
    浏览(34)
  • 【探索 Kubernetes|作业管理篇 系列 16】离线业务 Job、CronJob

    大家好,我是秋意零。 在上一篇中,我们讲解了 DaemonSet 控制器,相信你以及理解了其的工作过程,分为三部。一是,获取所有 Node 节点中的 Pod;二是,判断是否有符合 DaemonSet 管理的 Pod;三是,通过“亲和性”和“容忍”来精确控制并保证 Pod 在目标节点运行。 今天的内容

    2024年02月12日
    浏览(37)
  • Linux之进程管理篇(2)

    1.1 ps命令 格式: ps  [选项] 作用: 显示进程的状态。没有选项的时候显示当前用户在当前终端启动的进程。 选项: * 高亮的为常用选项 a 显示所有进程 u 指定用户的所有进程 x 显示当前用户在所有终端下的进程信息 c 显示进程的真实名称k|--sort 属性 对属性排序,属性前加

    2024年01月24日
    浏览(40)
  • 【汤4操作系统】深入掌握操作系统-文件管理篇

    数据项记录文件 数据项分为: 基本数据项:描述对象的某些属性,例如学生的年龄,姓名学号等 组合数据项:由若干个基本数据项组合而成 记录:一组相关数据项的集合,用于描述一个对象在某方面的属性 文件:文件是指由创建者所定义的、 具有文件名的一组 相关元素的

    2024年02月09日
    浏览(42)
  • 【探索 Kubernetes|作业管理 Deployment 篇 系列 12】水平扩展 / 收缩、滚动 / 回滚更新

    大家好,我是秋意零。 在上一篇中,我们介绍了控制器的基本设计思想:控制器模式。通过这个 “控制器模式” 我们来看看 Deployment 是如何依靠它来实现的。 最近搞了一个扣扣群,旨在技术交流、博客互助,希望各位大佬多多支持! 获取方式: 1.在我主页推广区域,如图

    2024年02月11日
    浏览(32)
  • U3D客户端框架(资源管理篇)之自动化打Assetbundle包管理器

    AssetBundle是将资源使用Unity提供的一种用于存储资源的压缩格式打包后的集合,它可以存储任何一种Unity可以识别的资源,如模型,纹理图,音频,场景等资源。也可以加载开发者自定义的二进制文件。他们的文件类型是.assetbundle/.unity3d,他们先前被设计好,很容易就下载到我们

    2024年02月09日
    浏览(35)
  • 【管理篇 / 升级】❀ 13. FortiOS 7.4固件升级新规则 ❀ FortiGate 防火墙

    【简介】飞塔防火墙的固件升级一直是所有厂家中最好的。只要有注册官方帐号,有注册设备,并且只要有一台设备在服务期内,即可下载所有型号的所有版本的固件。即使其它设备服务期已过,也可以通过固件文件手动升级,避免防火墙受到漏洞攻击。但是从7.4版本开始,

    2024年01月17日
    浏览(52)
  • 【管理篇 / 恢复】❀ 08. 文件权限对macOS下用命令刷新固件的影响 ❀ FortiGate 防火墙

    【简介】虽然上篇文章中成功的在macOS下刷新了固件,但是很多小伙伴在实际操作中碰到了无法成功的状况,我们来看看最常见的一种。  在/private/tftpboot目录拷贝另一个版本的固件文件,具体拷贝过程不再详述。  打开终端,输入命令  sudo launchctl load -F /System/Library/LaunchDa

    2024年02月02日
    浏览(36)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包