28｜应用保障：如何让Pod运行得更健康？
Chrono
你好，我是 Chrono。
在前面这么多节的课程中，我们都是在研究如何使用各种 API 对象来管理、操作 Pod，而对 Pod 本身的关注却不是太多。
作为 Kubernetes 里的核心概念和原子调度单位，Pod 的主要职责是管理容器，以逻辑主机、容器集合、进程组的形式来代表应用，它的重要性是不言而喻的。
那么今天我们回过头来，在之前那些上层 API 对象的基础上，一起来看看在 Kubernetes 里配置 Pod 的两种方法：资源配额 Resources、检查探针 Probe，它们能够给 Pod 添加各种运行保障，让应用运行得更健康。
容器资源配额
早在第 2 讲的时候我们就说过，创建容器有三大隔离技术：namespace、cgroup、chroot。其中的 namespace 实现了独立的进程空间，chroot 实现了独立的文件系统，但唯独没有看到 cgroup 的具体应用。
cgroup 的作用是管控 CPU、内存，保证容器不会无节制地占用基础资源，进而影响到系统里的其他应用。
不过，容器总是要使用 CPU 和内存的，该怎么处理好需求与限制这两者之间的关系呢？
Kubernetes 的做法与我们在第 24 讲里提到的 PersistentVolumeClaim 用法有些类似，就是容器需要先提出一个“书面申请”，Kubernetes 再依据这个“申请”决定资源是否分配和如何分配。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文介绍了如何通过资源配额和检查探针来保障Pod的健康运行。首先，文章详细介绍了容器资源配额的概念和使用方法，包括如何在Pod的描述部分添加 `resources` 字段来申请和限制CPU和内存资源，以及对资源单位的表示方式和申请错误的后果。其次，文章解释了容器状态探针的作用和三种探针的递进关系，以及Kubernetes如何使用探针来管理容器的状态，保证容器的正常运行。通过资源配额和检查探针的应用，读者可以更好地了解如何让Pod运行得更健康。 文章还介绍了如何在Pod的YAML描述文件里定义探针，包括startupProbe、livenessProbe、readinessProbe的配置方式和具体定义。通过实际示例，展示了不同探针的配置和使用方法，以及如何通过探针来监控容器的状态，保证应用的正常运行。最后，文章对资源配额和探针的应用进行了简单小结，并提出了两个思考题，引发读者对文章内容的深入思考和讨论。 总的来说，本文通过清晰的概念介绍、实际示例演示和思考题提出，全面而深入地介绍了资源配额和检查探针在Kubernetes中的应用，对读者了解和掌握这一技术具有很高的参考价值。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Kubernetes 入门实战课》，新⼈⾸单¥59
《Kubernetes 入门实战课》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(18)
- 最新
- 精选
dao思考题： 1. Liveness 和 Readiness 都是循环探测，Liveness 探测失败会重启，而 Readiness 探测失败不会重启，可以从 Pod 状态 看出重启次数。 两者都可以单独使用，这时差异不大。 如果同时使用两者，Liveness 主要是确认应用运行着或者说活着，而 Readiness 是确认应用提供着服务或者说服务就绪着（可以接收流量）。 2. Shell 是从容器内部探测，TCP Socket 和 HTTP GET 都是在容器外部探测。 TCP Socket 基于端口的探测，端口打开即成功；HTTP GET 更丰富些，可以是端口 + 路径。作者回复: good
2022-09-25归属地：北京21
新时代农民工老师请问，Startup、Liveness、Readiness三种探针是按顺序执行还是并行呢？作者回复: Startup成功之后才能执行后两个探针，后面两个是并行的。
2022-08-26归属地：北京20- 邵涵如老师原文所示，在startupProbe或livenessProbe探测失败之后，pod的status初始都是running。不过，在容器重启几次之后，pod的status会变为CrashLoopBackOff 如果startupProbe和livenessProbe探测成功，readinessProbe探测失败，pod的ready一直是0/1，status一直是running，当然，也不会重启 NAME READY STATUS RESTARTS AGE ngx-pod-probe 0/1 Running 0 27m
作者回复: great
2022-10-25归属地：上海8 
拾掇拾掇
Shell：不用知道端口；TCP Socket、HTTP GET这2个都得知道端口，用的时候还得显示调用端口吧作者回复: 是的，可以参考一些知名镜像的YAML ，看看它们是怎么做健康检查的。
2022-09-12归属地：北京25
LorryLiveness指的是进程是否存在，Readiness则是指是否能够正常提供服务，所以可以使用tcp'协议检测Liveness，进程存在端口即存在，使用http检测服务，只有服务启动了参能够相应请求。 Shell是系统内进程级别交互，所以只能够本地访问，Tcp可以跨机器访问，但是访问的级别比较低，不能够获得顶层数据，Http是协议层数据，可以拿到应用层的服务信息，但是关注顶层信息，底层故障，顶层无法提供有价值信息了作者回复: great
2023-02-03归属地：四川23- Geek_2ce074老师 tcpSocket探测是由谁发起的
作者回复: 当然是Kubernetes，不能内部具体如何运转的就没细研究了。
2022-09-30归属地：北京3 
YueShi"postStart"'"preStop"感觉可以做CICD，或者各种webhock钩子，或者简单的通知作者回复: 是的，这些都是Kubernetes为我们提供的回调接口。
2022-08-31归属地：北京3
大毛思考题 1. liveness 和 readiness 探针分别代表程序正常运行和可以提供服务。要探索两者的区别就要看应用在这两种状态下的差异，即在程序运行和提供服务之间，差了些什么。程序正常运行，可能代表代码没有 bug，没有硬性的致命的问题，但是要让它达到可以提供服务的程度，还需要一些条件，比如：启动时可能需要缓存预热，这个阶段可能就是 liveness 成功但 readiness 失败。可能 pod 的负载过大，需要进行降级，这就需要将 readness 从成功改成失败。 所以可能两种探针失败也有不同的含义：liveness 失败代表应用运行出现比较致命问题，需要重启来续命。readiness 失败代表程序不太健康，这种不健康是可以恢复的。 2. 三种探测方式应用的使用情境不同吧，shell 是在操作系统层面上的探测，毕竟跑起来的业务代码不方便（可能也不应该？）关心 OS。TCP Socket 关心的是网络，关心的是不同进程间的基础通信？http Get 是在应用层面上的探测，感觉它应该和业务的关联比较紧密。 忽然感觉 kubernetes 真厉害，三种探针和三种探测方式，基本上可以检测出各个层面的问题。作者回复: great
2023-06-26归属地：北京1
peter请教老师几个问题： Q1：第27讲中，创建4个nginx实例，没有端口冲突问题吗？ 四个nginx实例，两个在master，两个在worker。同一台机器上有两个pod，而pod的定义是一样的，即端口相同，那么，不存在端口冲突问题吗？ Q2：第27讲中，创建四个nginx实例后，不能访问nginx的欢迎页。 service也创建了。 用虚拟机上浏览器来访问127.0.0.1，失败， 执行“kubectl port-forward svc/ngx-svc 8080:80 &”以后， 浏览器上访问127.0.0.1:8080，报错： E0826 14:32:28.734987 42769 portforward.go:391] error copying from local connection to remote stream: read tcp4 127.0.0.1:8080->127.0.0.1:59752: read: connection reset by peer Q3：nginx的配置文件中，竖线是什么意思？ data: default.conf: |， 这里的竖线是什么意思？ Q4：操作系统能够看到的CPU，是指逻辑核吗？还是时间片？作者回复: 1.每个Nginx都是运行在pod里，被容器环境隔离，当然不会冲突，可以复习一下入门篇。 2. 这个暂时没看出是什么原因。 3.竖线是YAML 的长字符串语法，看前面的课程。 4.是逻辑核。
2022-08-26归属地：北京21
WilliamStartup，启动探针，用来检查应用是否已经启动成功，适合那些有大量初始化工作要做，启动很慢的应用。Liveness，存活探针，用来检查应用是否正常运行，是否存在死锁、死循环。 Readiness，就绪探针，用来检查应用是否可以接收流量，是否能够对外提供服务。 --- startupProbe 探测失败-会重启: 状态: ContainerCreating -> Running状态--> CrashLoopBackOff状态(重启过程中看到有在2个状态横跳, ContainerCreating不确定没看到) NAME READY STATUS RESTARTS AGE ngx-pod-probe 0/1 Running 1 (10s ago) 104s ngx-pod-probe 0/1 CrashLoopBackOff 5 (10s ago) 104s livenessProbe探测失败-会重启: 那么会持续默认5次重启(我试的默认是重启5次:RESTARTS=5), 这个过程中pod的状态会是变化Running , 重启次数完毕仍然未成功,那么状态会变成CrashLoopBackOff 状态: ContainerCreating -> Running --> CrashLoopBackOff READY: 1/1 -> 0/1 NAME READY STATUS RESTARTS AGE ngx-pod-probe 1/1 Running 2 (5s ago) 65s ngx-pod-probe 0/1 CrashLoopBackOff 5 (8s ago) 3m48s readinessProbe 探测失败 也会重启: 状态: Running --> CrashLoopBackOff READY: 0/1 NAME READY STATUS RESTARTS AGE ngx-pod-probe 0/1 ContainerCreating 0 2s ngx-pod-probe 0/1 Running 1 (4s ago) 10s ngx-pod-probe 0/1 CrashLoopBackOff 2 (6s ago) 20s ngx-pod-probe 0/1 Running 3 (19s ago) 33s ngx-pod-probe 0/1 CrashLoopBackOff 5 (38s ago) 2m12s作者回复: great
2024-01-12归属地：吉林
收起评论
