【云原生之k8s】k8s资源限制以及探针检查

目录

一、资源限制

1、资源限制的使用

2、reuqest资源（请求）和limit资源（约束）

3、Pod和容器的资源请求和限制

4、官方文档示例

5、资源限制实操

5.1 编写yaml资源配置清单

5.2 释放内存（node节点，以node01为例）

5.3 创建资源

5.4 跟踪查看pod状态

5.5 查看容器日志

5.6 删除pod

5.7 修改yaml配置资源清单，提高mysql资源限制

5.8 再次创建资源

5.9 跟踪查看pod状态

5.10 查看pod详细信息

5.11 查看node资源使用

二、健康检查

1、健康检查的定义

2、探针的三种规则

2.1 livenessProbe存活探针

2.2 readinessProbe就绪探针

2.3 startupProbe启动探针（1.17版本新增）

2.4 同时定义

3、Probe支持的三种检测方法

3.1 exec

3.2 tcpSocket

3.3 httpGet

4、探测结果

5、exec方式

6、httpGet方式

7、tcpSocket方式 

三、总结

1. 探针

2. 检查方式

3. 常用的探针可选参数

4、重启策略

---

一、资源限制

1、资源限制的使用

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

2、reuqest资源（请求）和limit资源（约束）

1. 当为Pod中的容器指定了request资源时，调度器就使用该信息来决定将Pod调度到哪个节点上。当还为容器指定了limit资源时，kubelet就会确保运行的容器不会使用超出所设的limit资源量。kubelet还会为容器预留所设的request资源量，供该容器使用。
2. 如果Pod所在的节点具有足够的可用资源，容器可以使用超过所设置的request资源量。不过，容器不可以使用超出所设置的limit资源量。
3. 如果给容器设置了内存的limit值，但未设置内存的request值，Kubernetes会自动为其设置与内存limit相匹配的request值。类似的，如果给容器设置了CPU的limit值但未设置CPU的request值，则Kubernetes自动为其设置CPU的request值，并使之与CPU的limit值匹配。

3、Pod和容器的资源请求和限制

定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.cpu
定义创建容器时预分配的内存资源
spec.containers[].resources.requests.memory
定义创建容器时预分配的巨页资源
spec.containers[].resources.requests.hugepages-<size>
定义cpu的资源上限
spec.containers[].resources.limits.cpu
定义内存的资源上限
spec.containers[].resources.limits.memory
定义巨页的资源上限
spec.containers[].resources.limits.hugepages-<size>

4、官方文档示例

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"

此例子中Pod有两个Container。每个Container 的请求为 0.25 cpu 和 64MiB（226 字节）内存， 每个容器的资源约束为 0.5 cpu 和 128MiB 内存。 你可以认为该 Pod 的资源请求为 0.5 cpu 和 128 MiB 内存，资源限制为 1 cpu 和 256MiB 内存。

5、资源限制实操

5.1 编写yaml资源配置清单

[root@master ~]# mkdir /opt/test
[root@master ~]# cd !$
cd /opt/test
[root@master test]# vim test1.yaml
 
apiVersion: v1
kind: Pod
metadata:
  name: test1
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: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

5.2 释放内存（node节点，以node01为例）

由于mysql对于内存的使用要求比较高，因此需要先检查内存的可用空间是否能够满足mysql的正常运行，若剩余内存不够，可对其进行释放操作。

查看内存

free -mH

[root@node01 ~]# free -mh
              total        used        free      shared  buff/cache   available
Mem:           1.9G        1.0G         86M         26M        870M        663M
Swap:            0B          0B          0B

 内存总量为1.9G，实际使用1G，因此可有内存应该为0.9G左右。
但是由于有870M的内存被用于缓存，导致了free仅为86M。
86M剩余可用内存显然是不够用的，因此需要释放缓存。

手动释放缓存

echo [1\2\3] > /proc/sys/vm/drop_caches

[root@node01 ~]# cat /proc/sys/vm/drop_caches
0
[root@node01 ~]# echo 3 > /proc/sys/vm/drop_caches
[root@node01 ~]# free -mh
              total        used        free      shared  buff/cache   available
Mem:           1.9G        968M        770M         26M        245M        754M
Swap:            0B          0B          0B

0：0是系统默认值，默认情况下表示不释放内存，由操作系统自动管理
1：释放页缓存
2：释放dentries和inodes
3：释放所有缓存
注意：

如果因为是应用有像内存泄露、溢出的问题，从swap的使用情况是可以比较快速可以判断的，但free上面反而比较难查看。相反，如果在这个时候，我们告诉用户，修改系统的一个值，“可以”释放内存，free就大了。用户会怎么想？不会觉得操作系统“有问题”吗？所以说，既然核心是可以快速清空buffer或cache，也不难做到（这从上面的操作中可以明显看到），但核心并没有这样做（默认值是0），我们就不应该随便去改变它。
一般情况下，应用在系统上稳定运行了，free值也会保持在一个稳定值的，虽然看上去可能比较小。当发生内存不