K8s资源限制和三种探针

空中连线

已于 2024-06-05 22:40:06 修改

阅读量1.1k

点赞数 18

文章标签： kubernetes

于 2024-05-24 21:33:04 首次发布

本文链接：https://blog.csdn.net/mcb134/article/details/139173853

版权

一默写总结

1 pod 的组成

① Pod 中有几种容器？

init 初始化：阻塞主容器运行，初始化后方可运行主容器
pause 基础容器：提供network 的 namespace 和共享存储
业务容器：跑Pod 主应用

（POD中跑什么：微服务、数据库、监控、日志分析、mq、业务网关-类似Nginx的功能 SDK WSGI CGI等接口或协议的支持）

② Pod内网络环境

共享形式，类似于docker-container 模式通过localhost 通讯

2 pod的本身性质(pod的种类与说明)命令

① 自主式pod:没有自愈能力( Pod被删除后不会重启拉起新的pod）

② 控制器管理的pod:有自愈能力( Pod被删除后会重启拉起新的pod）

3 k8s中如何查看命名空间ky35中的pod的IP

kubectl get pods -n ky35 -o wide

4 k8s 中pod无法启动怎么排查原因?

kubectl describe pod

kubectl logs

二关于pod容器的资源限制

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

②当为 Pod 中的容器指定了 request 资源限制时，代表容器运行所需的最小资源量，调度器就使用该信息来决定将 Pod 调度到哪个节点上（也就是预选策略是根据requests设置的资源进行淘汰不符合要求的node节点）。当还为容器指定了 limit 资源时，kubelet 就会确保运行的容器不会使用超出所设的 limit 资源量。kubelet 还会为容器预留所设的 request 资源量，供该容器使用。

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

可以预留：先预选再优选，选择最佳方案

④如果给容器设置了内存的 limit 值，但未设置内存的 request 值，Kubernetes 会自动为其设置与内存 limit 相匹配的 request 值。

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

总结：

①requests表示创建pod时预留的资源，limits表示pod能够使用资源的最大值。requests值可以被超，limits值不能超过，

②如果是内存使用超过limits会触发oom然后杀掉进程，如果是cpu超过limits会压缩cpu的使用率。

K8官网示例：

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

Pod 和容器的资源请求和限制：

spec.containers[].resources.requests.cpu        //定义创建容器时预分配的CPU资源

spec.containers[].resources.requests.memory        //定义创建容器时预分配的内存资源

spec.containers[].resources.limits.cpu            //定义 cpu 的资源上限 

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

三资源限制的单位

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 资源。

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

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

总结：

cpu的单位可以是核个数如1.25，0.5等，可以是毫核如500m，1250m

memory的单位可以是128M或128Mi （分别是1000k=1M或1024Ki=1Mi）

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

3 为什么要做资源限制

留一些资源给系统用：20%留给自己，80%留给自己

案例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"

注意：mysql作为数据库调用时若memory与内存不足时会导致数据库崩溃

此例子中的 Pod 有两个容器！

① 每个容器的 request 值为 0.25 cpu 和 64MiB 内存，

② 每个容器的 limit值为 0.5 cpu 和 128MiB 内存。那么可以认为该 Pod 的总的资源 request 为 0.5

cpu 和 128 MiB 内存，总的资源 limit 为 1 cpu 和 256MiB 内存。

案例2：

① 编写yaml文件

② 启动查看资源情况

实验结论：资源不足将会无法建立容器

案例3：

apiVersion: v1
kind: Pod
metadata:
  name: ky35-web-mcb
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: mcb
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "abc123"
resources:
      requests:
        memory: "128Mi"
        cpu: "0.5"
      limits:
        memory: "1Gi"
        cpu: "1"

还在拉取中

[root@master pod]# kubectl describe nodes 可以查看占据资源情况

4 pod 容器的资源限制

① spec.containers.resources.requests.cpu/memory

#创建pod 容器时需要预留的资源量 0.5 500m/ 内存 MI GI(2为低的) M

G (10为底的)

② spec.containers.resources.limits.cpu/memory #pod容器能够使用资源量的一个上限

举例：4Gi内存上限(不允许超过上限值；Lcpu上限(不允许超过上限值)

③ kubectl descrbe 名称

査看pod 或査看 node 资源使用情况

四驱逐顺序

优先级：Guaranteed > Burstable > BestEffort

Guaranteed (QoS) 的 Pod，其优先级最高，在其资源使用量不超过其 limits 的情况下，可以确保

不被杀死

在系统内存资源紧张，且集群中没有 QoS 为 Best-Effort 级别的其它 Pod 时，一旦 Burstable

(QoS) 的Pod 使用的资源量超过了其 requests，这些 Pod 就容易被杀死

BestEffort (QoS) 的 Pod，其优先级最低，当系统内存资源紧张时，这些 Pod 底层容器中的进程是

最先会被杀死的

验证内存超过limit限制会触发oomkil杀掉容器

五关于pod容器的三种探针

健康检查：又称为探针（Probe），探针是由kubelet对容器执行的定期诊断。检测容器是否正常运行，是否准备好接受请求，告诉是否启动。就绪启动存活

1 探针的三种规则：

●livenessProbe ：判断容器是否正在运行。如果探测失败，则kubelet会杀死容器，并且容器将根

据 restartPolicy 来设置 Pod 状态。如果容器不提供存活探针，则默认状态为Success.（不想重启

never，一直启动aways）

●readinessProbe ：判断容器是否准备好接受请求。如果探测失败，端点控制器将从与 Pod 匹配

的所有 service endpoints 中剔除删除该Pod的IP地址。初始延迟之前的就绪

状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success。

●startupProbe（这个1.17版本增加的）：判断容器内的应用程序是否已启动，主要针对于不能确

定具体启动时间的应用。如果配置了 startupProbe 探测，则在 startupProbe 状态为 Success 之

前，其他所有探针都处于无效状态，直到它成功后其他探针才起作用。如果 startupProbe 失败，

kubelet 将杀死容器，容器将根据 restartPolicy 来重启。如果容器没有配置 startupProbe，则默认

状态为 Success。

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

ready状态的。

2 探针检测方式

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

●tcpSocket ：对指定端口上的容器的IP地址进行TCP检查（三次握手），如果端口打开，则诊断

被认为是成功的。

●httpGet ：对指定的端口和uri路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于

等于200且小于400，则诊断被认为是成功的

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

●成功（Success）：表示容器通过了检测。

●失败（Failure）：表示容器未通过检测。

●未知（Unknown）：表示检测没有正常进行。

探针官网示例：
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

4 存活探针

示例1：exec方式

验证存活探针；在容器内执行指定命令，若命令退回时返回码为0则认为诊断成功

示例1：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 会杀死这个容器并重新启动它。

此实验应该没有完全成功

示例2：httpGet方式

示例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: 1   #延迟1s
      periodSeconds: 3         #每3s探测一次
      timeoutSeconds: 10       #延迟10s 再启动

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 #http://ip/域名:80/index.html 2s  每3秒  超时10秒  没有给我回应杀死容器
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10

httpget http://IP:80/index.html  delay 延迟 =3  tomout=10s    period（频率）=3s   succes(成功)=1  faulure(失败)=3 机会      杀死容器

kubectl create -f httpget.yaml

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

kubectl get pods

再来一次看看：模拟失败

在这个配置文件中，可以看到 Pod 也只有一个容器。initialDelaySeconds 字段告诉 kubelet 在执行

第一次探测前应该等待 3 秒。periodSeconds 字段指定了 kubelet 每隔 3 秒执行一次存活探测。

kubelet 会向容器内运行的服务（服务会监听 8080 端口）发送一个 HTTP GET 请求来执行探测。

如果服务器上 /healthz 路径下的处理程序返回成功代码，则 kubelet 认为容器是健康存活的。如果

处理程序返回失败代码，则 kubelet 会杀死这个容器并且重新启动它。

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

示例3：tcpSocket方式

示例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

探针时间各不相

5 就绪检测

示例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

可以通过查看event事件找出错误信息

 kubectl get event |grep readiness-httpget

接着创建

[root@master pod]# kubectl describe pod readiness-httpget

是因为要求手速：第一个探针启动之后，第二个就启动失败

实验应该算成功

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

若就绪探针失败就会把绑定解除

启动、退出动作

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 get pods -o wide

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

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

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

6 启动探针

启动探针用于检测容器是否成功启动。在某些情况下，容器启动可能需要较长时间（如加载大量数据或执行初始化操作）。启动探针会在容器启动后立即开始探测，并在探测成功前阻止其他探针（如存活探针和就绪探针）的探测。这有助于确保容器在完全启动并准备好之前不会被错误地终止或加入到服务负载均衡中。

如果配置了 startupProbe 探测，在则在 startupProbe 状态为 Success 之前，其他所有探针都处于无效状态，直到它成功后其他探针才起作用。如果 startupProbe 失败，kubelet 将杀死容器，容器将根据 restartPolicy 来重启。如果容器没有配置 startupProbe，则默认状态为 Success