【Kubernetes】k8s集群中pod的容器资源限制和三种探针

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.资源限制的单位

1.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 资源

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

案例

vim pod2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: web
    image: nginx                      #在两个容器下面都设置资源限制
    imagePullPolicy: IfNotPresent
    env:
    - name: WEB_ROOT_PASSWORD
      value: "password"
    resources:                        #资源限制
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: db
    image: mysql
    imagePullPolicy: IfNotPresent
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "abc123"
    resources:                     #资源限制，设置requests和limits中的memory数据一致会发生什么
      requests: 
        memory: "256Mi"
        cpu: "0.5"
      limits:
        memory: "256Mi"
        cpu: "1"
 
 
kubectl apply -f pod2.yaml
kubectl get pod -o wide -w

总结

cpu的单位可以是核个数如1.25，0.5等，可以是毫核如500m，1250m
memory的单位可以是128M或128Mi （分别是1000k=1M或1024Ki=1Mi）

二.关于QOS服务质量（pod的调度和驱逐有限制）

1.QoS服务质量分类

确定Pod的调度和驱逐优先级

Guaranteed：Pod中的每个容器（包括init容器），都设置了CPU、内存的 requests 和 limits，且 requests 和 limits 要相等
Burstable：Pod中至少有一个容器设置了CPU或内存的 requests
BestEffort：Pod中的所有容器都没有设置CPU或内存的 requests 和 limits

2.驱逐顺序

优先级：Guaranteed > Burstable > BestEffort

Guaranteed的Pod，优先级最高，在其资源使用量不超过其 limits 的情况下，可以确保不被杀死
在node节点的内存资源紧张，且没有其它QOS为BestEffort的Pod时，一旦Burstable的Pod使用的资源量超过了其 requests，这些Pod就容易被杀死
BestEffort的Pod，优先级最低，当node节点的内存资源紧张时，这些Pod会被最先杀死

三.关于pod容器的三种探针

健康检查：又称为探针（Probe)，探针是由kubelet对容器执行的定期诊断。

1.探针的三种规则

存活探针（livenessProbe）

探测Pod容器是否在正常运行。
如果探测失败则kubelet杀掉容器，并根据容器的重启策略决定是否重启容器

exec检查方式

vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: pod-test
  name: pod-test
spec:
  containers:
  - image: soscscs/myapp:v1
    name: myapp
    ports:
    - containerPort: 80
    resources: {}
    command:
    - sh
    - -c
    - "touch /tmp/scj.txt; sleep 20; rm -f /tmp/scj.txt; sleep 3600"
    livenessProbe:            #存活探针
      exec:
        command:
        - sh
        - -c
        - "test -f /tmp/scj.txt"
      initialDelaySeconds: 5
      periodSeconds: 5
      failureThreshold: 3
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}
 
kubectl apply -f pod3.yaml
kubectl get pod -o wide -w
kubectl describe pod pod-test

httpget检查方式

vim pod4.yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: pod-test
  name: pod-test
spec:
  containers:
  - image: soscscs/myapp:v1
    name: myapp
    ports:
    - containerPort: 80
      name: http
    resources: {}
    livenessProbe:               #存活探针  
      initialDelaySeconds: 5
      periodSeconds: 5
      failureThreshold: 3
      httpGet:                   #httpget检查方式   
        port: http
        path: /index.html
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}
 
kubectl apply -f pod4.yaml
kubectl log pod-test

tcpSocket检查方式

vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: pod-test
  name: pod-test
spec:
  containers:
  - image: soscscs/myapp:v1
    name: myapp
    ports:
    - containerPort: 80
    resources: {}
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
      failureThreshold: 3
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}
 
kubectl apply -f pod3.yaml
kubectl exec -it pod-test -- netstat -lntp

就绪探针（readinessProbe）

探测Pod是否能进入就绪状态（要求read状态栏是1/1 2/2），并做好接收service转发来的请求的准备
如果探测失败则Pod变成未就绪状态（read状态栏是0/1 1/2），service会删除未就绪的Pod端点，并不再转发请求给未就绪的Pod

vim pod4.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod-test
name: pod-test
spec:
containers:
- image: soscscs/myapp:v1
name: myapp
ports:
- containerPort: 80
name: http
resources: {}
readinessProbe: #就绪探针
initialDelaySeconds: 5
periodSeconds: 5
failureThreshold: 3
httpGet:
port: http
path: /scj.html #目标目录中不存在这个文件
livenessProbe:
initialDelaySeconds: 5
periodSeconds: 5
failureThreshold: 3
httpGet:
port: http
path: /index.html
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}

若想将状态变成就绪，如何操作？

kubectl exec -it pod-test -- sh
cd /usr/share/nginx/html/
echo 123 > scj.html    #创建这个文件后，就绪探针即可满足条件

启动探针（startupProbe）

探测Pod容器内的应用进程是否启动成功。在启动探针探测成功前，存活探针和就绪探针都会处于赞同状态，直到启动探针探测成功为止
如果探测失败则kubelet杀掉容器，并根据容器的重启策略决定是否重启容器

vim pod4.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: pod-test
name: pod-test
spec:
containers:
- image: soscscs/myapp:v1
name: myapp
ports:
- containerPort: 80
name: http
resources: {}
readinessProbe:
initialDelaySeconds: 5
periodSeconds: 5
failureThreshold: 3
httpGet:
port: http
path: /scj.html
livenessProbe:
initialDelaySeconds: 5
periodSeconds: 5
failureThreshold: 3
httpGet:
port: http
path: /index.html
startupProbe:
periodSeconds: 10
failureThreshold: 12
httpGet:
port: http
path: /tan.html
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}

2.Probe支持三种检查方法

**exec：**在容器里执行指定的Linux命令，如果命令返回码为0则认为探测成功，如果命令返回码为非0值则认为探测失败
**httpGet：**向Pod的指定端口及URL路径发送HTTP GET请求，如果HTTP响应状态码为2XX 3XX则认为探测成功，如果HTTP响应状态码为4XX 5XX则认为探测失败
**tcpSocket：**向Pod的指定端口发送TCP连接请求（三次握手），如果端口正确且TCP连接成功则认为探测成功，如果TCP连接失败则认为探测失败

3.探测的三种结果

成功（Success）：表示容器通过了检测
失败（Failure）：表示容器未通过检测
未知（Unknown）：表示检测没有正常进行

4.常用参数

initialDelaySeconds：指定容器启动后延迟探测的时间（单位为秒）
periodSeconds：指定每次探测的间隔时间
failureThreshold：指定判断探测失败的连续失败次数
timeoutSeconds：指定探测超时等待的时间

四.pod容器的启动、退出动作

postStart：当容器创建后且容器进程启动之前（即容器主进程开始运行但不一定完全准备好接收

请求时），Kubernetes会尝试执行postStart。通常用来执行一些初始化任务，比如资源部署、环境

配置等。如果postStart钩子执行失败，容器仍然会被启动，并且kubelet不会因此重启容器。

我们可以通过lifecycle配置项在 Pod 定义的 spec.containers[*].lifecycle.postStart 字段中指定一个

命令或者 HTTP 请求。

preStop：当容器即将被kubelet终止时，Kubernetes会尝试执行preStop。这个钩子可以优雅地关

闭连接、保存状态或释放资源。kubelet会确保preStop被触发并至少已经开始执行。如果容器突然

崩溃（CrashLoopBackOff等情况），preStop可能无法得到执行。

preStop的执行与SIGTERM信号是异步的，也就是说如果PreStop钩子脚本执行时间超过这个优雅

期，Kubernetes将强制终止Pod。

我们同样可以通过 spec.containers[*].lifecycle.preStop 字段来设置执行命令或HTTP请求。

示例

vim pod-test.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-test7
spec:
  volumes:
  - name: scj-vol
    hostPath:
      path: /data/scj/
      type: DirectoryOrCreate
  initContainers:
  - name: myapp
    image: soscscs/myapp:v1
    volumeMounts:
    - name: scj-vol
      mountPath: /mnt/                
    command:
    - sh
    - -c
    - "echo 'scj like 123 from initcontainer' >> /mnt/scj.txt"
  containers:
  - image: nginx:1.20
    name: nginx
    ports:
    - containerPort: 80
    resources: {}
    volumeMounts:
    - name: scj-vol
      mountPath: /usr/local/bin/       #将本地目录/data/scj/挂载到容器的/usr/local/bin/上
    lifecycle:
      postStart:                       #设置Pod容器启动时额外执行的操作
        exec:
          command:
          - sh
          - -c
          - "echo 'tangjun like from poststat' >> /usr/local/bin/scj.txt"
      preStop:                         #设置Pod容器被kubelet杀掉退出时执行的操作
        exec:
          command:
          - sh
          - -c
          - "echo 'jun like from prestop' >> /usr/local/bin/scj.txt"
  dnsPolicy: ClusterFirst
  restartPolicy: Always
 
kubectl apply -f pod-test.yaml

pod生命周期