一、资源限制
总结：
requests表示创建pod时预留的资源，limits表示pod能够使用资源的最大值。requests值可以被超，limits值不能超过，如果是内存使用超过limits会触发oom然后杀掉进程，如果是cpu超过limits会压缩cpu的使用率。
官网示例如下：
Resource Management for Pods and Containers | Kubernetes
1.1Pod 和 容器的资源请求和限制
spec.containers[].resources.requests.cpu #定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory #定义创建容器时预分配的内存资源
spec.containers[].resources.limits.cpu #定义 cpu 的资源上限
spec.containers[].resources.limits.memory #定义内存的资源上限
spec.containers[].resources.limits.hugepages-<size>
spec.containers[].resources.requests.hugepages-<size>1.2Kubernetes 中的资源单位
1.2.1CPU 资源单位
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.2.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
例如：在买硬盘的时候，操作系统报的数量要比产品标出或商家号称的小一些，主要原因是标出的是以 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，所以检测实际结果要比标出的少一些。
cpu的单位可以是核个数如1.25，0.5等，可以是毫核如500m，1250m
memory的单位可以是128M或128Mi （分别是1000k=1M或1024Ki=1Mi）
1.3容器资源示例
官方文档
https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/
以下 Pod 有两个容器。每个容器的请求为 0.25 CPU 和 64MiB（226 字节）内存， 每个容器的资源限制为 0.5 CPU 和 128MiB 内存。 你可以认为该 Pod 的资源请求为 0.5 CPU 和 128 MiB 内存，资源限制为 1 CPU 和 256MiB 内存
apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
containers:
- name: app
image: images.my-company.example/app:v4
env:
- name: MYSQL_ROOT_PASSWORD
value: "password"
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
- name: log-aggregator
image: images.my-company.example/log-aggregator:v6
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"1.4部署容器资源限制
mkdir /opt/pod/
cd /opt/pod/apiVersion: v1
kind: Pod
metadata:
name: zzz-web-db
spec:
containers:
- name: web
image: nginx
env:
- name: WEB_ROOT_PASSWORD
value: "password"
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
- name: db
image: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: "abc123"
resources:
requests:
memory: "64Mi"
cpu: "0.25"
limits:
memory: "128Mi"
cpu: "500m"
可以看到状态是OOMKilled、表示资源不足、需要修改资源
OOMKilled：资源不足被杀死
kubectl logs zzz-web-db -c db 
然后进入修改配置
现在状态正常，running状态，创建成功
查看pod的详细信息
kubectl describe pod zzz-web-db 
kubectl get pods -owide 
看到调度到了node01上面，我们可以去查看详细信息，如下图
kubectl describe nodes
#查看资源占用多少 
预分配：request
Pod 和 容器 的资源请求和限制：
spec.containers[].resources.requests.cpu #定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory # 定义创建容器时预分配的内存资源#创建pod容器时需要预留你的资源量 示例：0.5 500m 内存 MI、GI（2为底的）MG(10为底的)
上限：limits
spec.containers[].resources.limits.cpu #定义 cpu 的资源上限
spec.containers[].resources.limits.memory #定义内存的资源上限#pod容器能够使用资源量的一个上限 示例 ：4Gi内存上限 (不允许超过上限值)
kubectl describe 名称
#查看pod或者查看node资源使情况二、健康检查：又称为探针（Probe）⭐⭐⭐⭐⭐
健康检查：又称为探针（Probe）
探针是由kubelet对容器执行的定期诊断
2.1探针的三种规则
