• 【kubernetes】关于云原生之k8s集群中pod的容器资源限制和三种探针

    目录

    一、关于pod容器的资源限制

    1.1资源限制的单位

    CPU 资源单位

    内存 资源单位 

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

    2.1QoS服务质量分类

    guaranteed验证

    burstable验证

    besteffort验证

    2.2驱逐顺序

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

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

    3.2三种健康检查的方式

    3.3实操验证

    实操一：通过存活探针验证三大健康检查的方式

    存活探针——exec健康检查方式

     存活探针——tcpsocket健康检查方式

    ​编辑 存活探针之httpget健康检查方式

    实操二：验证启动探针、 就绪探针、存活探针的顺序

    实操三：验证就绪探针

    ​编辑 实操四、验证启动和退出动作

    四、总结：

    三种探针

    关于探针的3种探测方式

    探针参数：

    一、关于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的使用率。

    官网示例：https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
    Pod 和 容器 的资源请求和限制

    1. spec.containers[].resources.requests.cpu		//定义创建容器时预分配的CPU资源
    2. spec.containers[].resources.requests.memory		//定义创建容器时预分配的内存资源
    3. spec.containers[].resources.limits.cpu			//定义 cpu 的资源上限 
    4. spec.containers[].resources.limits.memory		//定义内存的资源上限
    5.  
    6. spec.containers[].resources.limits.hugepages-<size> 
    7. spec.containers[].resources.requests.hugepages-<size>

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

    内存 资源单位 

    内存的 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）

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

    2.1QoS服务质量分类

    • Guaranteed：Pod 中的每个容器，包含初始化容器，必须指定内存、CPU 的 requests 和 limits，并且 requests 和 limits 要相等
    • Burstable：Pod 中至少一个容器具有内存 或 CPU requests
    • BestEffort：Pod 中的所有容器都没有指定内存 或 CPU 的 requests和 limits

    guaranteed验证

    只有一个容器，而且容器的req与limit设置值一致

    只有1个容器，而且只设置容器的limit设置值

     有2个容器，而且容器的req与limit设置值一致

     

    burstable验证

    只有1个容器，而且只设置容器的requests设置值

     

     

     

    besteffort验证

    2.2驱逐顺序

    优先级：Guaranteed > Burstable > BestEffort

    • Guaranteed (QoS) 的 Pod，其优先级最高，在其资源使用量不超过其 limits 的情况下，可以确保不被杀死
    • 在系统内存资源紧张，且集群中没有 QoS 为 Best-Effort 级别的其它 Pod 时，一旦 Burstable (QoS) 的Pod 使用的资源量超过了其 requests，这些 Pod 就容易被杀死
    • BestEffort (QoS) 的 Pod，其优先级最低，当系统内存资源紧张时，这些 Pod 底层容器中的进程是最先会被杀死的

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

    1. apiVersion: v1
    2. kind: Pod
    3. metadata:
    4.   labels:
    5.     myapp: nginx
    6.   name: pod-demo7
    7. spec:
    8.   containers:
    9.   - image: nginx:1.20
    10.     imagePullPolicy: IfNotPresent
    11.     name: pod-c1
    12.     env:
    13.     - name: WEB_ROOT_PASSWORD
    14.       value: "password"
    15.     ports:
    16.     - containerPort: 80
    17.     resources:
    18.       requests:
    19.         cpu: "0.5"
    20.         memory: "128Mi"
    21.       limits:
    22.         cpu: "0.5"
    23.         memory: "128Mi"
    24.   - image: mysql
    25.     imagePullPolicy: IfNotPresent
    26.     env:
    27.     - name: MYSQL_ROOT_PASSWORD
    28.       value: "123123"
    29.     name: mydb
    30.     resources:
    31.       requests:
    32.         cpu: "0.5"
    33.         memory: "128Mi"
    34.       limits:
    35.         cpu: "0.5"
    36.         memory: "128Mi"
    37.   restartPolicy: Always

     

     

    1. kubectl describe -n <命名空间> pods <资源名称>       
    2. //查看Pod中的每个容器的资源限制的配置
    3.  
    4.  
    5. kubectl describe node <node节点名称>                 
    6. //查看node节点的资源总量、每个Pod的资源限制和节点的资源限制总量及比例

     

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

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

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

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

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

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

    3.2三种健康检查的方式

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

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

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

    每次探测都将获得以下三种结果之一：
    ●成功（Success）：表示容器通过了检测。
    ●失败（Failure）：表示容器未通过检测。
    ●未知（Unknown）：表示检测没有正常进行。

    3.3实操验证

    实操一：通过存活探针验证三大健康检查的方式

    存活探针——exec健康检查方式

    1. apiVersion: v1
    2. kind: Pod
    3. metadata:
    4.   labels:
    5.     test: demo1
    6.   name: demo1
    7. spec:
    8.   containers:
    9.   - name: nginx
    10.     image: soscscs/myapp:v1
    11. #args的作用相当于docker-compose文件中的CMD字段，可以设置容器启动命令
    12.     args:
    13.     - /bin/sh
    14.     - -c
    15.     - touch /tmp/healthy; sleep 10; rm -rf /tmp/healthy; sleep 10
    16. #设置存活探针，探测pod容器的运行状态，一旦探测失败，那么就会通过kubelet杀掉容器
    17.     livenessProbe:
    18.       exec:
    19.         command:
    20.         - cat
    21.         - /tmp/healthy
    22.       failureThreshold: 2      #表示连续探测失败2次才为探测失败
    23.       initialDelaySeconds: 2   #表示初始等待2秒后再才是启动存活探针
    24.       periodSeconds: 2         #表示探测周期为2秒

     存活探针——tcpsocket健康检查方式

    1. apiVersion: v1
    2. kind: Pod
    3. metadata:
    4.   labels:
    5.     test: demo1
    6.   name: demo1
    7. spec:
    8.   containers:
    9.   - name: nginx
    10.     image: soscscs/myapp:v1
    11.     ports:
    12.     - containerPort: 80
    13.       name: http
    14. #设置存活探针，探测pod容器的运行状态，一旦探测失败，那么就会通过kubelet杀掉容器
    15.     livenessProbe:
    16.       tcpSocket:
    17.         port: http             #表示探测端口为pod的80端口  这里引用暴露端口的名称来代替80端口 
    18.       failureThreshold: 2      #表示连续探测失败2次才为探测失败
    19.       initialDelaySeconds: 2   #表示初始等待2秒后再才是启动存活探针
    20.       periodSeconds: 2         #表示探测周期为2秒

     错误验证

    1. apiVersion: v1
    2. kind: Pod
    3. metadata:
    4.   labels:
    5.     test: demo1
    6.   name: demo1
    7. spec:
    8.   containers:
    9.   - name: nginx
    10.     image: soscscs/myapp:v1
    11.     ports:
    12.     - containerPort: 80
    13.       name: http
    14. #设置存活探针，探测pod容器的运行状态，一旦探测失败，那么就会通过kubelet杀掉容器
    15.     livenessProbe:
    16.       tcpSocket:
    17.         port: 8080             #该8080端口并未开放，模拟检查失败查看
    18.       failureThreshold: 2      #表示连续探测失败2次才为探测失败
    19.       initialDelaySeconds: 2   #表示初始等待2秒后再才是启动存活探针

     存活探针之httpget健康检查方式

    1. apiVersion: v1
    2. kind: Pod
    3. metadata:
    4.   labels:
    5.     test: demo1
    6.   name: demo1
    7. spec:
    8.   containers:
    9.   - name: nginx
    10.     image: soscscs/myapp:v1
    11.     ports:
    12.     - containerPort: 80
    13.       name: http
    14. #设置存活探针，探测pod容器的运行状态，一旦探测失败，那么就会通过kubelet杀掉容器
    15.     livenessProbe:
    16.       httpGet:  #采用httpGet的方式 会像podip的指定端口发送http GET请求
    17.         port: http
    18.         path: /index.html      #做http健康检查的页面
    19.       failureThreshold: 2      #表示连续探测失败2次才为探测失败
    20.       initialDelaySeconds: 2   #表示初始等待2秒后再才是启动存活探针
    21.       periodSeconds: 2         #表示探测周期为2秒

     

    实操二：验证启动探针、 就绪探针、存活探针的顺序

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

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

    实操三：验证就绪探针

    1. vim readiness-myapp.yaml
    2. apiVersion: v1
    3. kind: Pod
    4. metadata:
    5.   name: myapp1
    6.   labels:
    7.      app: myapp
    8. spec:
    9.   containers:
    10.   - name: myapp
    11.     image: soscscs/myapp:v1
    12.     ports:
    13.     - name: http
    14.       containerPort: 80
    15.     readinessProbe:
    16.       httpGet:
    17.         port: 80
    18.         path: /index.html
    19.       initialDelaySeconds: 5
    20.       periodSeconds: 5
    21.       timeoutSeconds: 10 
    22. ---
    23. apiVersion: v1
    24. kind: Pod
    25. metadata:
    26.   name: myapp2
    27.   labels:
    28.      app: myapp
    29. spec:
    30.   containers:
    31.   - name: myapp
    32.     image: soscscs/myapp:v1
    33.     ports:
    34.     - name: http
    35.       containerPort: 80
    36.     readinessProbe:
    37.       httpGet:
    38.         port: 80
    39.         path: /index.html
    40.       initialDelaySeconds: 5
    41.       periodSeconds: 5
    42.       timeoutSeconds: 10 
    43. ---
    44. apiVersion: v1
    45. kind: Pod
    46. metadata:
    47.   name: myapp3
    48.   labels:
    49.      app: myapp
    50. spec:
    51.   containers:
    52.   - name: myapp
    53.     image: soscscs/myapp:v1
    54.     ports:
    55.     - name: http
    56.       containerPort: 80
    57.     readinessProbe:
    58.       httpGet:
    59.         port: 80
    60.         path: /index.html
    61.       initialDelaySeconds: 5
    62.       periodSeconds: 5
    63.       timeoutSeconds: 10 
    64. ---
    65. apiVersion: v1
    66. kind: Service
    67. metadata:
    68.   name: myapp
    69. spec:
    70.   selector:
    71.     app: myapp
    72.   type: ClusterIP
    73.   ports:
    74.   - name: http
    75.     port: 80
    76.     targetPort: 80

     

    现在恢复index页面

     实操四、验证启动和退出动作

    1. apiVersion: v1
    2. kind: Pod
    3. metadata:
    4.   name: lifecycle-demo
    5. spec:
    6.   containers:
    7.   - name: lifecycle-demo-container
    8.     image: soscscs/myapp:v1
    9.     lifecycle:   #此为关键字段
    10.       postStart:
    11.         exec:
    12.           command: ["/bin/sh", "-c", "echo Hello from the postStart handler >> /var/log/nginx/message"]      
    13.       preStop:
    14.         exec:
    15.           command: ["/bin/sh", "-c", "echo Hello from the poststop handler >> /var/log/nginx/message"]
    16.     volumeMounts:
    17.     - name: message-log
    18.       mountPath: /var/log/nginx/
    19.       readOnly: false
    20.   initContainers:
    21.   - name: init-myservice
    22.     image: soscscs/myapp:v1
    23.     command: ["/bin/sh", "-c", "echo 'Hello initContainers'   >> /var/log/nginx/message"]
    24.     volumeMounts:
    25.     - name: message-log
    26.       mountPath: /var/log/nginx/
    27.       readOnly: false
    28.   volumes:
    29.   - name: message-log
    30.     hostPath:
    31.       path: /data/volumes/nginx/log/
    32.       type: DirectoryOrCreate

    Pod容器的启动动作和退出动作：lifecycle.postStart|preStop（lifecycle与image字段同一层级）
    lifecycle.postStart      设置Pod容器启动时额外执行的操作，此操作不会作为容器pid=1的主进程
    lifecycle.preStop        设置Pod容器被kubelet杀掉退出时执行的操作

     kubelet杀掉有两种：要么kubelet delete 杀掉或者探针 探测失败

    四、总结：

    三种探针

    • 存活探针（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杀掉退出时执行的操作
     

  • 相关阅读:
    k8s 之存储卷
    DBA的一天是怎样的？运维工程师告诉你答案
    算法金 | 这绝对是不一样的，独一无二的逻辑回归算法体验
    前端开发入门笔记（八）CSS3属性详解：动画详解+Flex布局图文详解+Web字体
    hive数据库delete删除部分数据/删除分区内的数据
    自然语言处理NLP：一文了解NLP自然语言处理技术，NLP在生活中的应用，图导加深了解，NLP语料库，NLP开源工具
    无题之2
    《如何使用C语言去下三子棋？》
    haproxy工具，负载均衡配置，反向代理配置，动静分离，高可用等等
    基于QPSK的载波同步和定时同步性能仿真,包括Costas环的gardner环
  • 原文地址：https://blog.csdn.net/liu_xueyin/article/details/136373162