k8s之pod进阶---资源限制与探针

我叫yyy

已于 2023-11-01 15:16:38 修改

阅读量579

点赞数

文章标签： kubernetes 容器云原生

于 2023-11-01 14:40:16 首次发布

本文链接：https://blog.csdn.net/m0_72359405/article/details/134139200

版权

2、就绪探针：readinessProbe

(1) 就绪探针1

(2) 就绪探针2

3、startupProbe

一、资源限制

容器中的程序要运行，肯定是要占用一定资源的，比如cpu和内存等，如果不对某个容器的资源做限制，那么它就可能吃掉大量资源，导致其它容器无法运行。针对这种情况，kubernetes提供了对内存和cpu的资源进行配额的机制，这种机制主要通过resources选项实现，他有两个子选项：

limits：用于限制运行时容器的最大占用资源，当容器占用资源超过limits时会被终止，并进行重启

requests ：用于设置容器需要的最小资源，如果环境资源不够，容器将无法启动内存资源单位

内存的request 和limit 以字节为单位，可以整数表示，或者以10为底数的指数的单位（E、P、T、G、M、K）来表示，或者以2 为底数的指数来表示（Ei、Pi、Ti、Gi、Mi、Ki）来表示。 cpu的单位如果为0.5，表示该容器能获取的一个Cpu的一半，（类似于Cgroup对cpu的资源的时间分片），表达式0.1等价于表达式100m（毫核），表示每1000毫秒内容器可以使用cpu时间总量为100号秒。

k8s中会根据预选和优选的策略，就是预选和优选cpu和内存大小，会把不符合的首先剔除，然后再选能保证最小基本运行的。

编辑一个yaml配置文件

vim pod2.yaml

[root@master01 ziyuan]# kubectl apply -f pod1.yaml
pod/frontend created


#查看刚刚创建的pod，frontend所在的节点服务器，在node01
[root@master01 ziyuan]# kubectl get pods -owide
NAME        READY   STATUS             RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
frontend    2/2     Running            0          29m   10.244.1.73   node01   <none>           <none>


#查看节点01的详细信息，包含cpu，内存资源等信息，验证资源限制是否成功
[root@master01 ziyuan]# kubectl describe nodes node01

二、探针（健康检查）

2.1 含义

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

2.2 探针的三种规则

（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.3 probe支持三种检查方法

（1）exec

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

（2）tcpSocket

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

（3）httpGet

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

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

成功：容器通过了诊断。

失败：容器未通过诊断。

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

2.4 探针的示例

1、存活探针：livenessProbe

（1）exec方式

编辑exec.yaml配置文件

vim exec.yaml

（2）httpGet方式

编辑httpget.yaml配置文件

vim httpget.yaml

[root@master01 ziyuan]# kubectl create -f httpget.yaml
pod/liveness-httpget created

查看刚刚创建的pod
[root@master01 ziyuan]# kubectl get pods
NAME               READY   STATUS             RESTARTS   AGE
frontend           2/2     Running            0          77m
ky30               0/1     Error              0          21h
liveness-exec      1/1     Running            7          12m
liveness-httpget   1/1     Running            0          38s
myapp-pod          1/1     Running            8          24h
pod-demo2          0/1     CrashLoopBackOff   87         22h


#进入liveness-httpgetpod中，并删除index.html文件进行测试
[root@master01 ziyuan]# kubectl exec -it liveness-httpget -- rm -rf /usr/share/nginx/html/index.html

#再次查看刚刚创建的pod，发现因为刚刚删除过index.html文件了，导致pod中的容器重启
[root@master01 ziyuan]# kubectl get pods
NAME               READY   STATUS             RESTARTS   AGE
frontend           2/2     Running            0          77m
ky30               0/1     Error              0          21h
liveness-exec      1/1     Running            7          12m
liveness-httpget   1/1     Running            1          42s
myapp-pod          1/1     Running            8          24h
pod-demo2          0/1     CrashLoopBackOff   87         22h

#查看刚刚创建的pod中容器的ip地址
[root@master01 ziyuan]# kubectl describe pod liveness-httpget

（3）tcpsocket方式

编辑tcpsocket.yaml配置文件

[root@master01 ziyuan]# vim tcpsocket.yaml

[root@master01 ziyuan]# kubectl create -f tcpsocket.yaml
pod/probe-tcp created

#这段输出表明在名为 "probe-tcp" 的 Pod 中，有一个正在监听 80 端口的 TCP 连接，该连接与 Nginx 服务器的主进程相关。这是一个常见的网络配置，用于接受来自客户端的 HTTP 请求。但是刚刚配置文件中指定的探测的端口是8080，所以探测失败，会重新再次探测。因为failureThreshold的值设置为2，所以当连续两次探测失败后，就会重启容器。
[root@master01 ziyuan]# kubectl exec -it probe-tcp -- netstat -natp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1/nginx: master pro

2、就绪探针：readinessProbe

(1) 就绪探针1

vim readness-httpget.yaml

[root@master01 jiuxu]# kubectl create -f readness-httpget.yaml
pod/readliness-httpget created

[root@master01 jiuxu]# kubectl describe pod readliness-httpget

(2) 就绪探针2

vim demo01-readness-myapp.yaml

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

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

---
apiVersion: v1
kind: Pod
metadata:
  name: myapp3
  namespace: default
  labels:
    app: myapp
spec:
  containers:
  - name: readiness-http-container
    image: soscscs/myapp:v1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: myapp

[root@master01 jiuxu]# kubectl apply -f demo01-readness-myapp.yaml
pod/myapp1 created
pod/myapp2 created
pod/myapp3 created
service/myapp-svc created

#删除其中之一pod容器的html页面，使其就绪探针readiness探测失败
[root@master01 jiuxu]# kubectl exec -it myapp2 -- rm -rf /usr/share/nginx/html/index.html

3、startupProbe

spec.container.lifecycle.postStart 配合 exec.command 字段当容器启动时，会执行的额外操作。

spec.container.lifecycle.postStop 配合 exec.command 字段当容器退出时，会执行的操作。

[root@master01 jiuxu]# vim demo2-start-up.yaml

[root@master01 jiuxu]# kubectl create -f demo2-start-up.yaml
pod/lifecycle-demo created

#删除pod
[root@master01 jiuxu]# kubectl delete pod lifecycle-demo
pod "lifecycle-demo" deleted

三、pod生命周期的状态

挂起（Pending）：apiserver已经创建了pod资源对象，但它尚未被调度完成或者仍处于下载镜像的过程中。
运行中（Running）：pod已经被调度至某节点，并且所有容器都已经被kubelet创建完成。
成功（Succeeded）：pod中的所有容器都已经成功终止并且不会被重启。
失败（Failed）：所有容器都已经终止，但至少有一个容器终止失败，即容器返回了非0值的退出状态。
未知（Unknown）：apiserver无法正常获取到pod对象的状态信息，通常由网络通信失败所导致。

我叫yyy

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
k8s之pod进阶---资源限制与探针

cpu的单位如果为0.5，表示该容器能获取的一个Cpu的一半，（类似于Cgroup对cpu的资源的时间分片），表达式0.1等价于表达式100m（毫核），表示每1000毫秒内容器可以使用cpu时间总量为100号秒。容器中的程序要运行，肯定是要占用一定资源的，比如cpu和内存等，如果不对某个容器的资源做限制，那么它就可能吃掉大量资源，导致其它容器无法运行。如果探测失败，则kubelet会杀死容器，并且容器将根据 restartPolicy 来设置 Pod 状态。如果端口打开，则诊断被认为是成功的。
复制链接

扫一扫