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

目录

一、资源限制

 二、探针(健康检查)

2.1 含义

2.2 探针的三种规则

2.3 probe支持三种检查方法

2.4 探针的示例

1、存活探针:livenessProbe

(1)exec方式

(2)httpGet方式

(3)tcpsocket方式

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

k8s之pod进阶---资源限制与探针_第1张图片

[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              


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

k8s之pod进阶---资源限制与探针_第2张图片

 二、探针(健康检查)

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

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

(1)exec方式

编辑exec.yaml配置文件

vim exec.yaml

k8s之pod进阶---资源限制与探针_第3张图片

k8s之pod进阶---资源限制与探针_第4张图片

(2)httpGet方式

编辑httpget.yaml配置文件

vim httpget.yaml

k8s之pod进阶---资源限制与探针_第5张图片

[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

k8s之pod进阶---资源限制与探针_第6张图片

k8s之pod进阶---资源限制与探针_第7张图片

(3)tcpsocket方式

编辑tcpsocket.yaml配置文件

[root@master01 ziyuan]# vim tcpsocket.yaml

k8s之pod进阶---资源限制与探针_第8张图片

[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

 k8s之pod进阶---资源限制与探针_第9张图片

2、就绪探针:readinessProbe

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

(1) 就绪探针1
vim readness-httpget.yaml

k8s之pod进阶---资源限制与探针_第10张图片

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

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

k8s之pod进阶---资源限制与探针_第11张图片

(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

k8s之pod进阶---资源限制与探针_第12张图片

k8s之pod进阶---资源限制与探针_第13张图片

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

k8s之pod进阶---资源限制与探针_第14张图片

k8s之pod进阶---资源限制与探针_第15张图片

 3、startupProbe

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

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

(这个1.17版本增加的):判断容器内的应用程序是否已启动,主要针对于不能确定具体启动时间的应用。如果配置了 startupProbe 探测,在则在 startupProbe 状态为 Success 之前,其他所有探针都处于无效状态,直到它成功后其他探针才起作用。 如果 startupProbe 失败,kubelet 将杀死容器,容器将根据 restartPolicy 来重启。如果容器没有配置 startupProbe, 则默认状态为 Success。

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

k8s之pod进阶---资源限制与探针_第16张图片

[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

k8s之pod进阶---资源限制与探针_第17张图片

三、pod生命周期的状态

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

 

你可能感兴趣的:(kubernetes,容器,云原生)