一.资源限制

当定义 Pod时可以选择性地为每个容器设定所需要的资源数量。最常见的可设定资源是CPU和内存大小，以及其他类型的资源。

当为 pod 中的容器指定了request资源时，调度器就使用该信息来决定将Pod 调度到哪个节点上。当还为容器指定了limit资源时，kubelet就会确保运行的容器不会使用超出所设的 limit资源量。kubelet还会为容器预留所设的 request资源量，供该容器使用。

如果Pod运行所在的节点具有足够的可用资源，容器可以使用超出所设置的 request资源量。不过，容器不可以使用超出所设置的 limit资源量。如果给容器设置了内存的 limit值，但未设置内存的 request值，Kubernetes会自动为其设置与内存 limit相匹配的 request 值。类似的，如果给容器设置了 CPU的 limit值但未设置cPU的 request值，则 Kubernetes自动为其设置CPU 的 request值并使之与CPU的 limit值匹配。

官网示例：kubernetes.io/docs/concep…

1.1 Pod 和容器的资源请求和限制

定义创建容器时预分配的CPU资源：spec.containers[].resources.requests.cpu

定义创建容器时预分配的内存资源：spec.containers[].resources.requests.memory

定义cpu的资源上限：spec.containers[].resources.limits.cpu

定义内存的资源上限：spec.containers[].resources.limits.memory

1.2 CPU资源单位

CPU资源的request和 limit 以cpu为单位。Kubernetes 中的一个 cpu相当于1个 vCPU（1个超线程）。

Kubernetes也支持带小数CPU 的请求。spec.containers[].resources.requests.cpu为0.5的容器能够获得一个cpu 的一半CPU

资源（类似于Cgroup对CPU资源的时间分片）。表达式0.1等价于表达式100m（毫核），表示每1000毫秒内容器可以使用的CPU时间总量为0.1*1000毫秒。

Kubernetes 不允许设置精度小于1m 的CPU资源。

1.3 内存资源单位

内存的 request和 limit 以字节为单位。可以以整数表示，或者以10为底数的指数的单位（E、P、T、G、M、K）来表示，或者以2为底数的指数的单位（Ei、Pi、Ti、Gi、Mi、Ki）来表示。

如: 1KB=10^3=1000，1MB=10^6=1000000=1000KB，1GB=10^9=1000000000=1000MB；1KiB=2^10=1024，1MiB=2^20=1048576=1024KiB

PS：在买硬盘的时候，操作系统报的数量要比产品标出或商家号称的小一些，主要原因是标出的是以MB、GB为单位的，1GB就是1,000,000Byte，而操作系统是以2进制为处理单位的，因此检查硬盘容量时是以MiB、GiB为单位，1GiB=2^30=1,073,741,824，相比较而言，1GiB要比1GB多出1,073,741,824-1,000, 000,000=73,741,824Byte，所以检测实际结果要比标出的少一些。

1.4 示例：

修改数据库的资源限制

执行yaml文件创建pod

查看pod的状态（OOMKilled是指内存不够的情况）

修改yaml文件，给数据库足够的资源

查看资源使用情况

二.健康检查：又称为探针（Probe）

探针是由kubelet对容器执行的定期诊断。

2.1 探针的三种规则

livenessProbe：判断容器是否正在运行。如果探测失败，则kubelet会杀死容器，并且容器将根据restartRolicy来设置Pod状态。如果容器不提供存活探针，则默认状态为Success。

readinessProbe：判断容器是否准备好接受请求。如果探测失败，端点控制器将从与 pod 匹配的所有 service endpoints中剔除删除该Pod的IP地址。初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success。

startupProbe（这个1.17版本增加的）：判断容器内的应用程序是否已启动，主要针对于不能确定具体启动时间的应用。如果配置了startupProbe探测，在则在startupProbe状态为Success之前，其他所有探针都处于无效状态，直到它成功后其他探针才起作用。如果startupProbe失败，kubelet将杀死容器，容器将根据restartPolicy来重启。如果容器没有配置 startupProbe，则默认状态为Success。

注：以上规则可以同时定义。在readinessProbe检测成功之前，Pod的running状态是不会变成ready状态的。

2.2 Probe支持三种检查方法

exec：在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。

tcpSocket：对指定端口上的容器的IP地址进行TCP检查（三次握手）。如果端口打开，则诊断被认为是成功的。

httplet：对指定的端口和路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于等于200且小于400，则诊断被认为是成功的

2.3 每次探测都将获得以下三种结果之一

成功：容器通过了诊断。

失败：容器未通过诊断。

未知：诊断失败，因此不会采取任何行动

官网示例：kubernetes.io/docs/tasks/…

2.4示例：

exec方式

initialDelaySeconds：指定kubelet 在执行第一次探测前应该等待5秒，即第一次探测是在容器启动后的第6秒才开始执行。默认是0秒，最小值是0

periodSeconds：指定了kubelet 应该每5秒执行一次存活探测。默认是10秒。最小值是1

failureThreshold：当探测失败时，Kubernetes 将在放弃之前重试的次数。存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod会被打上未就绪的标签。默认值是3。最小值是1。

timeoutSeconds：探测的超时后等待多少秒。默认值是1秒。最小值是1。（在Kubernetes 1.20 版本之前，exec探针会忽略timeoutSeconds探针会无限期地持续运行，甚至可能超过所配置的限期，直到返回结果为止。）

可以看到 pod 中只有一个容器。kubelet 在执行第一次探测前需要等待5秒，kubelet 会每5秒执行一次存活探测。kubelet在容器内执行命令cat /tmp/healthy来进行探测。如果命令执行成功并且返回值为 0，kutbelet就会认为这个容器是健康存活的。当到达第 31秒时，这个命令返回非0值，kubelet会杀死这个容器并重新启动它。

测试过程（使用存活探针）

这里直接复制前面的demo1.yaml文件进行使用，修改demo3.yaml文件

执行yaml文件

查看pod详细信息

httpGet方式

在这个配置文件中，可以看到Pod 也只有一个容器。initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待3秒。periodSeconds 字段指定了kubelet每隔3秒执行一次存活探测。kubelet 会向容器内运行的服务（服务会监听8080端口）发送一个HTTP GET请求来执行探测。如果服务器上/healthz路径下的处理程序返回成功代码，则 kubelet 认为容器是健康存活的。如果处理程序返回失败代码，则kubelet 会杀死这个容器并且重新启动它。

任何大于或等于200并且小于400 的返回代码表示成功，其它返回代码都表示失败。

测试过程（使用存活探针）

直接复制前面的demo3.yaml文件进行使用，修改demo4.yaml文件

执行yaml文件

查看pod的日志记录

删除index.html文件

重启后再次查看日志，又能探测成功

原因：K8S 中不支持重启 Pod资源，只有删除重建。由于还是基于同一个镜像，所以又恢复到index.html违背删除的状态。

tcpSocket方式

这个例子同时使用readinesspProbe和 livenessProbe 探测。kubelet会在容器启动5秒后发送第一个readinessProbe探测。这会尝试连接 gproxy 容器的 8080端口。如果探测成功，kubelet 将继续每隔10秒运行一次检测。除了readinessProbe 探测，这个配置包括了一个livenessProbe 探测。kubelet 会在容器启动15秒后进行第一次 livenessProbe 探测。就像readinessProbe 探测一样，会尝试连接goproxy容器的 8080端口。如果livenessProbe探测失败，这个容器会被重新启动。