K8S：pod资源限制及探针

文章目录

• 一.pod资源限制
• • 1.pod资源限制方式
  • 2.pod资源限制指定时指定的参数
  • • [（1）request 资源](#（1）request 资源)
    • [（2） limit 资源](#（2） limit 资源)
    • （3）两种资源匹配方式
  • 3.资源限制的示例
  • • （1）官网示例
    • （2）Pod和容器的资源请求和限制格式
    • [（3）CPU 资源单位介绍](#（3）CPU 资源单位介绍)
    • （4）内存资源单位
    • （5）资源限制示例1：
    • （6）资源限制示例2：
• 二.健康检查：又称为探针（Probe）
• • [1. 探针的规则](#1. 探针的规则)
  • 2.Probe支持三种检查方法
  • 3.探针三种方式示例
  • • （1）exec方式
    • （2）httpGet方式
    • （3）tcpSocket方式
    • （4）就绪检测示例
• 总：
• • 1.pod的资源限制
  • 2.pod容器探针
  • 3.三种探测方式：

一.pod资源限制

对pod资源限制原因：高并发占用所有的cpu资源、内存资源、会造成雪崩，

方式：对pod做限制、对k8s做限制

1.pod资源限制方式

当定义 Pod 时可以选择性地为每个容器设定所需要的资源数量。

最常见的可设定资源是 CPU 和内存大小，以及其他类型的资源。

2.pod资源限制指定时指定的参数

（1）request 资源

当为 Pod 中的容器指定了 request 资源时，调度器就使用该信息来决定将 Pod 调度到哪个节点上。

（2） limit 资源

当还为容器指定了 limit 资源时，kubelet 就会确保运行的容器不会使用超出所设的 limit 资 源量。kubelet 还会为容器预留所设的 request 资源量， 供该容器使用。

如果 Pod 运行所在的节点具有足够的可用资源，容器可以使用超出所设置的 request 资源量。不过，容器不可以使用超出所设置的 limit 资源量。

（3）两种资源匹配方式

如果给容器设置了内存的 limit 值，但未设置内存的 request 值，Kubernetes 会自动为其设置与内存 limit 相匹配的 request 值。 类似的，如果给容器设置了 CPU 的 limit 值但未设置 CPU 的 request 值，则 Kubernetes 自动为其设置 CPU 的 request 值 并使之与 CPU 的 limit 值匹配。

3.资源限制的示例

（1）官网示例

官网示例：

https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

（2）Pod和容器的资源请求和限制格式

#Pod 和 容器 的资源请求和限制：
spec.containers[].resources.requests.cpu		//定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory		//定义创建容器时预分配的内存资源
spec.containers[].resources.limits.cpu			//定义 cpu 的资源上限 
spec.containers[].resources.limits.memory		//定义内存的资源上限

（3）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 资源。

（4）内存资源单位

• 内存的 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，所以检测实际结果要比标出的少一些。

官方为 Pod 和容器管理资源介绍

https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/

（5）资源限制示例1：

#资源限制模板
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"

vim pod1.yaml 

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: web
    image: nginx:latest
    imagePullPolicy: IfNotPresent
    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: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

此例子中的 Pod 有两个容器。每个容器的 request 值为 0.25 cpu 和 64MiB 内存，每个容器的 limit 值为 0.5 cpu 和 128MiB 内存。那么可以认为该 Pod 的总的资源 request 为 0.5 cpu 和 128 MiB 内存，总的资源 limit 为 1 cpu 和 256MiB 内存。

kubectl apply -f pod1.yaml

kubectl get pod

kubectl describe pod1.yaml 

（6）资源限制示例2：

前面对pod1的资源限制，这里将cpu的大小进行调整

vim pod1.yaml
![在这里插入图片描述](https://img-blog.csdnimg.cn/698cf63987e14ea081a9d31b80d540c6.png)

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: web
    image: nginx
    env:
    - name: WEB_ROOT_PASSWORD
      value: "abc123"
      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: "512Mi"  
        cpu: "0.5"
      limits:
        memory: "1Gi"    
        cpu: "1"

kubectl apply -f pod1.yaml
kubectl describe pod frontend

 kubectl get pods -o wide
 
NAME       READY   STATUS    RESTARTS   AGE    IP            NODE     NOMINATED NODE   READINESS GATES
frontend   2/2     Running   0          100s   10.244.2.70   node01   <none>           <none>

kubectl describe nodes node02				

#查看mysql创建的pod日志
kubectl logs frontend -c db

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

1. 探针的规则

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

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

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

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

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

2.Probe支持三种检查方法

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

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

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

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

●成功：容器通过了诊断。

●失败：容器未通过诊断。

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

官网示例：

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

3.探针三种方式示例

（1）exec方式

#exec方式的模板
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:  
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      failureThreshold: 1
      initialDelaySeconds: 5
      periodSeconds: 5

#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，kubelet 就会认为这个容器是健康存活的。 当到达第 31 秒时，这个命令返回非 0 值，kubelet 会杀死这个容器并重新启动它。

#示例：、
vim pod2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
  namespace: default
spec:
  containers:
  - name: liveness-exec-container
    image: busybox
    imagePullPolicy: IfNotPresent
    command: ["/bin/sh","-c","touch /tmp/live ; sleep 30; rm -rf /tmp/live; sleep 3600"]
    livenessProbe:
      exec:
        command: ["test","-e","/tmp/live"]
      initialDelaySeconds: 1
      periodSeconds: 3

kubectl create -f exec.yaml

kubectl describe pods liveness-exec

kubectl get pods -w

（2）httpGet方式

#模板
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:

  - name: liveness
    image: k8s.gcr.io/liveness
    args:
    - /server
      livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
          initialDelaySeconds: 3
          periodSeconds: 3

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

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

vim httpget.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget
  namespace: default
spec:
  containers:
  - name: liveness-httpget-container
    image: soscscs/myapp:v1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    livenessProbe:
      httpGet:
        port: http
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10

liveness http-get http://IP:80/index.html 延迟1秒 timeout=1s period(频率)=3

success=1 failure（失败）=3 机器会杀死容器 重启

kubectl create -f httpget.yaml
kubectl get pod

#定义进入访问
kubectl exec -it liveness-httpget sh
#到nginx目录
cd /usr/share/nginx/
cd html/

#另开终端可以查看日志查看返回是否是正常的
kubectl logs liveness-httpget

#在原先的终端删除index.html探针会检测存活，如果再次进入查看存在就证明探针正常
rm -rf index.html

kubectl exec -it liveness-httpget sh

（3）tcpSocket方式

#模板
apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:

  - name: goproxy
    image: k8s.gcr.io/goproxy:0.1
    ports:
    - containerPort: 8080
      readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
      livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

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

vim tcpsocket.yaml

apiVersion: v1
kind: Pod
metadata:
  name: probe-tcp
spec:
  containers:

  - name: nginx
    image: soscscs/myapp:v1
    livenessProbe:
      initialDelaySeconds: 5
      timeoutSeconds: 1
      tcpSocket:
        port: 8080
      periodSeconds: 10
      failureThreshold: 2

kubectl create -f tcpsocket.yaml

kubectl exec -it probe-tcp  -- netstat -natp

kubectl get pods -w

NAME        READY   STATUS    RESTARTS   AGE
probe-tcp          1/1     Running            1          88s

probe-tcp          1/1     Running            2          90s
       #第一次是 init(5秒) + period(10秒) * 2
probe-tcp          1/1     Running            3          110s
       #第二次是 period(10秒) + period(10秒)  重试了两次
probe-tcp          1/1     Running            4          2m10s

（4）就绪检测示例

vim readiness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
  name: readiness-httpget
  namespace: default
spec:
  containers:
  - name: readiness-httpget-container
    image: soscscs/myapp:v1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index1.html
      initialDelaySeconds: 1
      periodSeconds: 3
    livenessProbe:
      httpGet:
        port: http
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10

kubectl create -f readiness-httpget.yaml

#readiness探测失败，无法进入READY状态
kubectl get pods 

kubectl exec -it readiness-httpget sh
cd /usr/share/nginx/html/
ls
50x.html    index.html
echo 123 > index1.html 
exit

kubectl get pods 

kubectl exec -it readiness-httpget -- rm -rf /usr/share/nginx/html/index.html

kubectl get pods -w

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

总：

1.pod的资源限制

（1）spec、containers、resources、requests、cpu/memory创建pod容器时需要预留的资源量 （设置0.5 或者500M )

（2）spec、containers、resources、limits、cpu/memory------pod容器能够使用的资源量的上线 MI Gi （2为底数） M G （19为底数）

2.pod容器探针

（1）存活探针：判断容器是否运行正常，如果探测失败则杀掉容器（不是pod），容器会根据容器策略决定是否重启

（2）就绪探针：判断pod是否能够进入ready状态，做好接受请求的准备，探测失败后进入notready状态并从service资源的endpoints中剔除，service将不会把访问请求转发给这个pod（做实验证明）

（3）启动探针：判断容器内的应用是否成功，在探测成功状态为success之前，其他探针都会处于失效状态

3.三种探测方式：

（1）exec：通过command设置执行在容器内执行的linux命令来探测，如果返回状态码为0，则认为探测成功

（2）httpget：通过httpget请求访问指定容器的url路径，如果返回状态码>=200且<400（2xx、3xx），则为探测成功

（3）tcpsocket：通过对指定的端口发送tcp连接，如果端口无误且三次握手（tcp连接成功），则为探测成功

ts、cpu/memory创建pod容器时需要预留的资源量 （设置0.5 或者500M )

（2）spec、containers、resources、limits、cpu/memory------pod容器能够使用的资源量的上线 MI Gi （2为底数） M G （19为底数）