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

目录

一、资源限制

二、探针(健康检查)

[2.1 含义](#2.1 含义)

[2.2 探针的三种规则](#2.2 探针的三种规则)

[2.3 probe支持三种检查方法](#2.3 probe支持三种检查方法)

[2.4 探针的示例](#2.4 探针的示例)

1、存活探针:livenessProbe

(1)exec方式

(2)httpGet方式

(3)tcpsocket方式

2、就绪探针:readinessProbe

[(1) 就绪探针1](#(1) 就绪探针1)

[(2) 就绪探针2](#(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配置文件

bash 复制代码
vim pod2.yaml
bash 复制代码
[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

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

(1)exec方式

编辑exec.yaml配置文件

bash 复制代码
vim exec.yaml
(2)httpGet方式

编辑httpget.yaml配置文件

bash 复制代码
vim httpget.yaml
bash 复制代码
[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
bash 复制代码
#查看刚刚创建的pod中容器的ip地址
[root@master01 ziyuan]# kubectl describe pod liveness-httpget
(3)tcpsocket方式

编辑tcpsocket.yaml配置文件

bash 复制代码
[root@master01 ziyuan]# vim tcpsocket.yaml
bash 复制代码
[root@master01 ziyuan]# kubectl create -f tcpsocket.yaml
pod/probe-tcp created
bash 复制代码
#这段输出表明在名为 "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

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

(1) 就绪探针1
bash 复制代码
vim readness-httpget.yaml
bash 复制代码
[root@master01 jiuxu]# kubectl create -f readness-httpget.yaml
pod/readliness-httpget created
bash 复制代码
[root@master01 jiuxu]# kubectl describe pod readliness-httpget
(2) 就绪探针2
bash 复制代码
vim demo01-readness-myapp.yaml
bash 复制代码
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
bash 复制代码
[root@master01 jiuxu]# kubectl apply -f demo01-readness-myapp.yaml
pod/myapp1 created
pod/myapp2 created
pod/myapp3 created
service/myapp-svc created
bash 复制代码
#删除其中之一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 字段 当容器退出时,会执行的操作。

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

bash 复制代码
[root@master01 jiuxu]# vim demo2-start-up.yaml
bash 复制代码
[root@master01 jiuxu]# kubectl create -f demo2-start-up.yaml
pod/lifecycle-demo created
bash 复制代码
#删除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对象的状态信息,通常由网络通信失败所导致。
相关推荐
为什么这亚子32 分钟前
九、Go语言快速入门之map
运维·开发语言·后端·算法·云原生·golang·云计算
ZHOU西口2 小时前
微服务实战系列之玩转Docker(十八)
分布式·docker·云原生·架构·数据安全·etcd·rbac
牛角上的男孩3 小时前
Istio Gateway发布服务
云原生·gateway·istio
JuiceFS4 小时前
好未来:多云环境下基于 JuiceFS 建设低运维模型仓库
运维·云原生
景天科技苑5 小时前
【云原生开发】K8S多集群资源管理平台架构设计
云原生·容器·kubernetes·k8s·云原生开发·k8s管理系统
wclass-zhengge6 小时前
K8S篇(基本介绍)
云原生·容器·kubernetes
颜淡慕潇6 小时前
【K8S问题系列 |1 】Kubernetes 中 NodePort 类型的 Service 无法访问【已解决】
后端·云原生·容器·kubernetes·问题解决
川石课堂软件测试8 小时前
性能测试|docker容器下搭建JMeter+Grafana+Influxdb监控可视化平台
运维·javascript·深度学习·jmeter·docker·容器·grafana
昌sit!14 小时前
K8S node节点没有相应的pod镜像运行故障处理办法
云原生·容器·kubernetes
A ?Charis17 小时前
Gitlab-runner running on Kubernetes - hostAliases
容器·kubernetes·gitlab