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

一、资源限制

总结：

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    内存超过limits大小，就会报omm内存资源不足的错误 

spec.containers[].resources.limits.cpu   #定义 cpu 的资源上限 
spec.containers[].resources.limits.memory        #定义内存的资源上限

#pod容器能够使用资源量的一个上限  示例 ：4Gi内存上限 (不允许超过上限值)

kubectl describe 名称
 
#查看pod或者查看node资源使情况

  k8s中的应用服务质量

 可以用查看pod的详细信息

qos优先级：

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

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

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

2.1探针的三种规则 

总结：

不提供存活探针，默认为success，表示如果没有存活探针的情况下，都是认为探针成功正常的

在就绪探针中，判断容器是否准备好接受请求，表示，pod是否准备好接受客户端和通过service转发来的请求

先启动启动探针------随后启动存活探针或者就绪探针

2.2Probe支持三种检查方法

exec ：在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。
tcpSocket ：对指定端口上的容器的IP地址进行TCP检查（三次握手）。如果端口打开，则诊断被认为是成功的。
httpGet ：对指定的端口和路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于等于200且小于400，则诊断被认为是成功的

建议使用httpget和tcpsocket
 

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

• 成功：容器通过了诊断。
• 失败：容器未通过诊断。
• 未知：诊断失败，因此不会采取任何行动

官网示例：

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

 三、验证存活探针三大健康检查的方式

官网示例：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 中只有一个 Container。 periodSeconds 字段指定了 kubelet 应该每 5 秒执行一次存活探测。 initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒。 kubelet 在容器内执行命令 cat /tmp/healthy 来进行探测。 如果命令执行成功并且返回值为 0，kubelet 就会认为这个容器是健康存活的。 当到达第 31 秒时，这个命令返回非 0 值，kubelet 会杀死这个容器并重新启动它

 随后自己写一个例子：

 

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: busybox
    imagePullPolicy: IfNotPresent
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 10; rm -rf /tmp/healthy; sleep 15
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      failureThreshold: 2
      initialDelaySeconds: 5
      periodSeconds: 5

kubectl apply -f exec.yaml

kubectl get pod -w

 随后，去查看pod的详细信息，当82秒时检测存活探针失败，kubelet便会删除pod，随后重启pod

kubectl describe pod liveness-exec

 3.2httpget健康检查方式（必不可少的时port+path路径）

可以通过检测是否端口没有开启或者path路径下面的html页面是否存在 检验httpget

示例：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 秒，则第4秒开始。periodSeconds 字段指定了 kubelet 每隔 3 秒执行一次存活探测。kubelet 会向容器内运行的服务（服务会监听 8080 端口）发送一个 HTTP GET 请求来执行探测。如果服务器上 /healthz 路径下的处理程序返回成功代码，则 kubelet 认为容器是健康存活的。如果处理程序返回失败代码，则 kubelet 会杀死这个容器并且重新启动它。

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

 

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

 

kubectl describe pod liveness-httpget

 

这里的重启 不是停止容器再次重启，而是删除容器 再次启动!!! 

3.3tcpsocket健康检查方式  指定端口号

示例：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 探测失败，这个容器会被重新启动。

 

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 apply -f tcpsocket.yaml

 

kubectl exec -it probe-tcp  -- netstat -natp
 
kubectl describe pod probe-tcp #查看pod详细信息

 

重启原因：因为nginx的端口是80，而在yaml文件里面设置的tcpsocket的检测端口是8080 ，检测不到因此kubectl会杀死容器，随后重启。 

四、就绪探针

4.1就绪探针1

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 apply -f readiness-httpget.yaml
 
kubectl get pods

 出现0/1 running 表示其中一个pod无法接受请求，svc要在endpoints删除未请求的ip地址

kubectl describe pod readiness-httpget

kubectl exec -it readiness-httpget sh

cd /usr/share/nginx/html/
echo "qin yu nian2" > index1.html

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

kubectl get pods -w

完成启动探针成功以后、就绪和存活探针才会生效

就绪探针与存活探针  是在启动探针探测成功以后才会生效

 4.2就绪检测2

apiVersion: v1
kind: Pod
metadata:
  name: myapp1
  labels:
     app: myapp
spec:
  containers:
  - name: myapp
    image: soscscs/myapp:v1
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp2
  labels:
     app: myapp
spec:
  containers:
  - name: myapp
    image: soscscs/myapp:v1
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp3
  labels:
     app: myapp
spec:
  containers:
  - name: myapp
    image: soscscs/myapp:v1
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  type: ClusterIP
  ports:
  - name: http
    port: 80
    targetPort: 80

kubectl apply -f readiness-myapp.yaml
 
kubectl get pod -owide -w
 
kubectl get pods,svc,endpoints -owide

 

 删除页面，看效果

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

 

kubectl get svc,pod,endpoints -owide

readiness探测失败，Pod 无法进入READY状态，且端点控制器将从 endpoints 中剔除删除该 Pod 的 IP 地址 

kubectl get pods -owide -w

 恢复页面，查看内容

 4.3启动、退出动作

poststart 启动动作

prestop  推出动作

vim demo-pod02.yaml

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: soscscs/myapp:v1
    lifecycle:   #此为关键字段
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler >> /var/log/nginx/message"]
      preStop:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the poststop handler >> /var/log/nginx/message"]
    volumeMounts:
    - name: message-log
      mountPath: /var/log/nginx/
      readOnly: false
  initContainers:
  - name: init-myservice
    image: soscscs/myapp:v1
    command: ["/bin/sh", "-c", "echo 'Hello initContainers'   >> /var/log/nginx/message"]
    volumeMounts:
    - name: message-log
      mountPath: /var/log/nginx/
      readOnly: false
  volumes:
  - name: message-log
    hostPath:
      path: /data/volumes/nginx/log/
      type: DirectoryOrCreate

kubectl apply -f demo-pod02.yaml

 

kubectl get pods -owide
 
kubectl exec -it lifecycle-demo -- cat /var/log/nginx/message

 

 在 node02 节点上查看

#由上可知，init Container先执行，然后当一个主容器启动后，Kubernetes 将立即发送 postStart 事件。

删除 pod 后，再在 node02 节点上查看

kubectl delete pod lifecycle-demo
 
 
node02操作
cd /data/volumes/nginx/log/
cat message

 

#由上可知，当在容器被终结之前， Kubernetes 将发送一个 preStop 事件。 

 4.4验证启动探针、 就绪探针、存活探针的顺序

vim demo-pod03.yaml

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: demo1
  name: demo1
spec:
  containers:
  - name: nginx
    image: soscscs/myapp:v1
    ports:
    - containerPort: 80
      name: http
#设置存活探针，探测pod容器的运行状态，一旦探测失败，那么就会通过kubelet杀掉容器
    livenessProbe:
      httpGet:  #采用httpGet的方式 会像podip的指定端口发送http GET请求
        port: http
        path: /index.html      #做http健康检查的页面
      failureThreshold: 2      #表示连续探测失败2次才为探测失败
      initialDelaySeconds: 2   #表示初始等待2秒后再才是启动存活探针
      periodSeconds: 8         #表示探测周期为8秒
#设置就绪探针，探测pod是否处于就绪状态，如果说探测失败则为未就绪状态，service会将其从关联的pod中删除，请求也不转发给该pod
    readinessProbe:
      httpGet:  #采用httpGet的方式 会像podip的指定端口发送http GET请求
        port: http
        path: /index.html      #做http健康检查的页面
      failureThreshold: 2      #表示连续探测失败2次才为探测失败
      initialDelaySeconds: 2   #表示初始等待2秒后再才是启动存活探针
      periodSeconds: 10        #表示探测周期为10秒
#启动探针，为了探测容器应用是否处于运行状态，只有启动探针探测成功以后，就绪探针和存活探针才有效
    startupProbe:
      httpGet:  #采用httpGet的方式 会像podip的指定端口发送http GET请求
        port: http
        path: /index1.html      #做http健康检查的页面
      failureThreshold: 3      #表示连续探测失败3次才为探测失败
      initialDelaySeconds: 2   #表示初始等待2秒后再才是启动存活探针
      periodSeconds: 15        #表示探测周期为15秒

kubectl apply -f demo-pod03.yaml
 
kubectl describe pod demo1

kubectl get pods -owide -w

查看日志

 

 可验证 就绪探针与存活探针  是在启动探针探测成功以后才会生效，启动探针探测成功之后，不会再运行，接下来存活探针和就绪探针同时开始运行。

 4.5k8s探针图解

五、 pod的状态

1、pending：pod已经被系统认可了，但是内部的container还没有创建出来。这里包含调度到node上的时间以及下载镜像的时间，会持续一小段时间。

2、Running：pod已经与node绑定了（调度成功），而且pod中所有的container已经创建出来，至少有一个容器在运行中，或者容器的进程正在启动或者重启状态。--这里需要注意pod虽然已经Running了，但是内部的container不一定完全可用。因此需要进一步检测container的状态。

3、Succeeded：这个状态很少出现，表明pod中的所有container已经成功的terminated了，而且不会再被拉起了。

4、Failed：pod中的所有容器都被terminated，至少一个container是非正常终止的。（退出的时候返回了一个非0的值或者是被系统直接终止）

5、unknown：由于某些原因pod的状态获取不到，有可能是由于通信问题。 一般情况下pod最常见的就是前两种状态。而且当Running的时候，需要进一步关注container的状态

六、Container生命周期

1、Waiting：启动到运行中间的一个等待状态。

2、Running：运行状态。

3、Terminated：终止状态。 如果没有任何异常的情况下，container应该会从Waiting状态变为Running状态，这时容器可用。

但如果长时间处于Waiting状态，container会有一个字段reason表明它所处的状态和原因，如果这个原因很容易能标识这个容器再也无法启动起来时，例如ContainerCannotRun，整个服务启动就会迅速返回。（这里是一个失败状态返回的特性，不详细阐述）

三种探针

存活探针（livenessProbe）：探测Pod容器是否在正常运行。如果探测失败则kubelet杀掉容器，并根据容器重启策略决定是否重启容器
就绪探针（readinessProbe）：探测Pod是否进入就绪状态(ready状态栏是否100%比例)，并做好接收service转发来的请求准备。
如果探测失败则Pod变成未就绪状态(0/1 1/2)，service就会删除相关联的Pod端点，并不再转发请求给处于未就绪状态的Pod

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

关于探针的3种探测方式

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

initialDelaySeconds：指定容器启动后延迟探测的时间（单位为秒）
periodSeconds：指定每次探测的间隔时间
failureThreshold：指定判定探测失败的连续失败次数
timeoutSeconds：指定探测超时等待的时间
Pod容器的启动动作和退出动作：lifecycle.postStart|preStop（lifecycle与image字段同一层级）
lifecycle.postStart      设置Pod容器启动时额外执行的操作，此操作不会作为容器pid=1的主进程
lifecycle.preStop        设置Pod容器被kubelet杀掉退出时执行的操作