一.资源限制
当定义 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。