应用保障：如何让Pod运行得更健康

作为 Kubernetes 里的核心概念和原子调度单位，Pod 的主要职责是管理容器，以逻辑主机、容器集合、进程组的形式来代表应用，它的重要性是不言而喻的。

创建容器有三大隔离技术：namespace、cgroup、chroot。其中的 namespace 实现了独立的进程空间，chroot 实现了独立的文件系统，cgroup 的作用是管控 CPU、内存，保证容器不会无节制地占用基础资源，进而影响到系统里的其他应用。

CPU、内存的只要在 Pod 容器的描述部分添加一个新字段 resources 就可以了，它就相当于申请资源的 Claim。它下面有两个字段：

• “requests”，意思是容器要申请的资源，也就是说要求 Kubernetes 在创建 Pod 的时候必须分配这里列出的资源，否则容器就无法运行。
• “limits”，意思是容器使用资源的上限，不能超过设定值，否则就有可能被强制停止运行。

在请求 cpu 和 memory 这两种资源的时候，你需要特别注意它们的表示方式。

内存的写法和磁盘容量一样，使用 Ki、Mi、Gi 来表示 KB、MB、GB，比如 512Ki、100Mi、0.5Gi 等。

CPU 时间也不能无限分割，Kubernetes 里 CPU 的最小使用单位是 0.001，为了方便表示用了一个特别的单位 m，也就是“milli”“毫”的意思，比如说 500m 就相当于 0.5。

Kubernetes 为检查应用状态定义了三种探针，它们分别对应容器不同的状态：

• Startup，启动探针，用来检查应用是否已经启动成功，适合那些有大量初始化工作要做，启动很慢的应用。
• Liveness，存活探针，用来检查应用是否正常运行，是否存在死锁、死循环。
• Readiness，就绪探针，用来检查应用是否可以接收流量，是否能够对外提供服务。

这三种探针是递进的关系：应用程序先启动，加载完配置文件等基本的初始化数据就进入了 Startup 状态，之后如果没有什么异常就是 Liveness 存活状态，但可能有一些准备工作没有完成，还不一定能对外提供服务，只有到最后的 Readiness 状态才是一个容器最健康可用的状态。

 如果一个 Pod 里的容器配置了探针，Kubernetes 在启动容器后就会不断地调用探针来检查容器的状态：

• 如果 Startup 探针失败，Kubernetes 会认为容器没有正常启动，就会尝试反复重启，当然其后面的 Liveness 探针和 Readiness 探针也不会启动。
• 如果 Liveness 探针失败，Kubernetes 就会认为容器发生了异常，也会重启容器。
• 如果 Readiness 探针失败，Kubernetes 会认为容器虽然在运行，但内部有错误，不能正常提供服务，就会把容器从 Service 对象的负载均衡集合中排除，不会给它分配流量。

 startupProbe、livenessProbe、readinessProbe 这三种探针的配置方式都是一样的，关键字段有这么几个：

• periodSeconds，执行探测动作的时间间隔，默认是 10 秒探测一次。
• timeoutSeconds，探测动作的超时时间，如果超时就认为探测失败，默认是 1 秒。
• successThreshold，连续几次探测成功才认为是正常，对于 startupProbe 和 livenessProbe 来说它只能是 1。
• failureThreshold，连续探测失败几次才认为是真正发生了异常，默认是 3 次。

至于探测方式，Kubernetes 支持 3 种：Shell、TCP Socket、HTTP GET，它们也需要在探针里配置：

• exec，执行一个 Linux 命令，比如 ps、cat 等等，和 container 的 command 字段很类似。
• tcpSocket，使用 TCP 协议尝试连接容器的指定端口。
• httpGet，连接端口并发送 HTTP GET 请求。

此文章为7月Day22学习笔记，内容来源于极客时间《Kubernetes入门实战课》，推荐该课程。