目录
一、资源限制
当定义 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 值匹配。
官网示例： https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
//查看相关命令：
kubectl explain deployment.spec.template.spec.containers.resources
kubectl explain statefulset.spec.template.spec.containers.resources
//Pod 和 容器 的资源请求和限制：
spec.containers[].resources.requests.cpu //定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory //定义创建容器时预分配的内存资源
spec.containers[].resources.limits.cpu //定义 cpu 的资源上限
spec.containers[].resources.limits.memory //定义内存的资源上限
pod控制的资源总共为两大类：
cpu，memory(内存)。其中我们运用最多的限制还是cpu和memory。
1.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 资源。
2.内存 资源单位
内存的 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,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，所以检测实际结果要比标出的少一些。
3.相关命令
kubectl apply -f test.yaml //创建
kubectl describe pod my-pod //查看容器的资源限制
kubectl get pods -o wide //查看pods的基本信息
kubectl describe nodes node02 //查看node节点的pod的资源限制情况
二、健康检查：又称为探针（Probe）
探针是由kubelet对容器执行的定期诊断。
1.探针的三种规则：
livenessProbe (存活探针):判断容器是否正常运行，如果失败则杀掉容器(不是pod) ,再根据重启策略是否重启容器
readinessProbe (就绪探针) :判断容器是否能够进入ready状态，探针失败则进入not ready状态， 并从service的endpoints中剔除此容器
startupProbe（1.17版本增加的）:判断容器内的应用是否启动成功，在success状态前，其它探针都处于无效状态
#注：以上规则可以同时定义。在readinessProbe检测成功之前，Pod的running状态是不会变成ready状态的。
2.Probe支持三种检查方法：
exec:使用command 字段设置命令，在容器中执行此命令，如果命令返回状态码为0，则认为探测成功
httpget:通过访问指定端口和url路径执行http get访问。如果返回的http状态码为大于等于200且小于400则认为成功
tcpsocket: 通过tcp连接pod (IP)和指定端口，如果端口无误且tcp三次握手连接成功，则认为探测成功
探针可选的参数:
initialDelaySeconds: 容器启动多少秒后开始执行探测，默认是0s
periodseconds:探测的周期，每多少秒执行一次探测，默认10s
failureThreshold: 探测失败后，允许再试几次， 默认3次
successThreshold： 连续几次探测成功，该探针被认为是成功的，默认1次
timeoutseconds :探测等待超时的时间，默认1s
每次探测都将获得以下三种结果之一： ●成功（success）：容器通过了诊断。 ●失败（failure）：容器未通过诊断。 ●未知（unknown）：诊断失败，因此不会采取任何行动
3.示例
官网示例： Configure Liveness, Readiness and Startup Probes | Kubernetes
（1）LivenessProbe 探针使用
//示例1：exec方式做健康探测
容器在初始化后，执行（/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"）首先创建一个 /tmp/healthy 文件，然后执行睡眠命令，睡眠 30 秒，到时间后执行删除 /tmp/healthy 文件命令。而设置的存活探针检检测方式为执行 shell 命令，用 cat 命令输出 healthy 文件的内容，> 如果能成功执行这条命令一次(默认successThreshold:1)，存活探针就认为探测成功，由于没有配置(failureThreshold、timeoutSeconds)，所以执行（cat /tmp/healthy）并只等待1s，如果1s内执行后返回失败， 探测失败。在前 30 秒内，由于文件存在，所以存活探针探测时执行 cat /tmp/healthy 命令成功执行。30 秒后 healthy 文件被删除，所以执行命令失败，Kubernetes 会根据 Pod 设置的重启策略来判断，是否重启 Pod。
//示例2：HTTP方式做健康探测
此外：
host：要连接的主机名，默认为Pod IP，可以在http request head中设置host头部。
httpHeaders：自定义HTTP请求headers，HTTP允许重复headers
#####过程了解##########################
Pod 中启动的容器是一个 SpringBoot 应用，其中引用了 Actuator 组件，提供了 /actuator/health 健康检查地址，在pod启动后，初始化等待20s后，livenessProbe开始工作，去请求HTTP://podIP:8081/actuator/health 接口，类似于curl -I HTTP://podIP:8081/actuator/health接口,考虑到请求会有延迟(curl -I后一直出现假死状态)，所以给这次请求操作一直持续5s，如果5s内访问返回数值在>=200且<=400代表第一次检测success，如果是其他的数值，或者5s后还是假死状态，执行类似（ctrl+c）中断，并反回failure失败。等待10s后，再一次的去请求HTTP://podIP:8081/actuator/health接口。如果有连续的2次都是success，代表无问题。如果期间有连续的5次都是failure，代表有问题，直接重启pod，此操作会伴随pod的整个生命周期
//示例3：TCP方式做健康探测
#########过程解析#####################
TCP 检查方式和 HTTP 检查方式非常相似，在容器启动 initialDelaySeconds 参数设定的时间后，kubelet 将发送第一个 livenessProbe 探针，尝试连接容器的 80 端口，类似于telnet 80端口，如果连接失败则将杀死 Pod 重启容器。
（2）ReadinessProbe 探针使用
该过程：
（1）首先是就绪探针在容器重启1s后进行httpGet方式探测，寻找到了 test.html网页验证成功。将该Pod 标记为就绪状态，kubelet 将继续每隔 10 秒运行一次探测。
（2）除此之外我还设置了存活探针，存活探针在容器启动的5s后，进行httpGet探测，因为默认网页被修改的缘故，找不到index.html,随后继续了两次4s间隔的探测，依旧没有发现uri目标网页。根据重启策略重启容器（该过程实际上就是删除原有pod，根据镜像拉取新的pod）。
（3）由于容器被重启，所以一切恢复默认初始化，此时默认的网页目录只存在Index.html,不在存在test.html。所以本次中就绪探针的httpGet进行uri的探测失败，此后期间会做出3次间隔3s的重复探测，最终均为失败。该pod则会进入NOTREADY状态，并且从所关联的service资源的端点（endpoints）中踢出，该pod将彻底称为notready状态，后面的就绪探针也就不在进行探测。
（3）启动探针的使用
三、pod的状态
1、pending：pod已经被系统认可了，但是内部的container还没有创建出来。这里包含调度到node上的时间以及下载镜像的时间，会持续一小段时间。
2、Running：pod已经与node绑定了（调度成功），而且pod中所有的container已经创建出来，至少有一个容器在运行中，或者容器的进程正在启动或者重启状态。--这里需要注意pod虽然已经Running了，但是内部的container不一定完全可用。因此需要进一步检测container的状态。
3、Succeeded：这个状态很少出现，表明pod中的所有container已经成功的terminated了，而且不会再被拉起了。
4、Failed：pod中的所有容器都被terminated，至少一个container是非正常终止的。（退出的时候返回了一个非0的值或者是被系统直接终止）
5、unknown：由于某些原因pod的状态获取不到，有可能是由于通信问题。 一般情况下pod最常见的就是前两种状态。而且当Running的时候，需要进一步关注container的状态
四、Container生命周期
1、Waiting：启动到运行中间的一个等待状态。
2、Running：运行状态。
3、Terminated：终止状态。 如果没有任何异常的情况下，container应该会从Waiting状态变为Running状态，这时容器可用。
但如果长时间处于Waiting状态，container会有一个字段reason表明它所处的状态和原因，如果这个原因很容易能标识这个容器再也无法启动起来时，例如ContainerCannotRun，整个服务启动就会迅速返回。（这里是一个失败状态返回的特性，不详细阐述）
扫一扫
1115
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
