Kubernetes资源请求与限制
Request/Limit 基本概念。
K8S支持在容器界别设置Request和Limit来约束容器所使用的CPU和Memory。
- Request表示在应用发布时,对容器所使用CPU和Memory的预估,提出的申请。K8S会根据当前工作节点的资源情况,进行调度决策,K8S会把POD调度到满足资源需求的节点上去运行。如果请求的资源不能得到满足,那发布的POD会处于Pending状态。
- Limit表示容器运行时对资源需求的限制,如果容器的CPU使用量达到或超过限制,K8S会限制容器对CPU资源的额外使用。如果容器的内存使用量达到或超过限制,K8S会Kill掉POD。
下图单位:
m为minicore
cpu: “1000m” = “1core”

QOS/POD Kill 策略
三种QOS设置类别的POD以及相应踢出决策。
- Guaranteed CPU&Memory 都需要设置,并且request=limit。这类POD只有在内存使用量超过限制的时候才会被Kill掉。
- Burstable 这类POD属于突发流量型,当节点资源不足的时候,这类POD可能会被Kill掉。
- Best Effort request和limit都不设置,这类POD属于尽最大努力型,当节点资源不足时,这类POD首先会被Kill掉。

资源查看命令
查看本机节点名称
kubectl get node
查看本机节点与运行POD的详情
kubectl describe node node_name
#找到Capacity, CPU, Memory, PODs数量, 已启动的POD的资源使用与限制。
POD发布文件-资源限制配置样例
注意:本文件仅为样例文件,如需发布,需要configmap文章中的所有yml文件。
petclinic-deployment.yml文件样例修改。
注意resources为新增配置。
apiVersion: apps/v1
kind: Deployment
metadata:
name: petclinic
spec:
replicas: 1
selector:
matchLabels:
app: petclinic
template:
metadata:
labels:
app: petclinic
spec:
containers:
- name: petclinic
# Run this image
image: spring2go/spring-petclinic:1.0.0.RELEASE
resources:
requests:
memory: "128Mi"
# 200 minicore, 1000m = 1core
cpu: "200m"
limits:
memory: "512Mi"
envFrom:
- configMapRef:
name: petclinic-config
---
apiVersion: v1
kind: Service
metadata:
# Unique key of the Service instance
name: petclinic
spec:
ports:
# Accept traffic sent to port 80
- name: http
# port为集群内部服务前通信的端口
port: 8080
targetPort: 8080
nodePort: 31080
selector:
# 下面标签app: petclinic表示本服务会路由指向所有app标签为petclinic的pod。
app: petclinic
type: NodePort
与其他文件搭配发布。需要此文档中的YAML文件一起发布。
可以再次查看节点详情。
查看本机节点名称
kubectl get node
查看本机节点与运行POD的详情
kubectl describe node node_name
#找到Capacity, CPU, Memory, PODs数量, 已启动的POD的资源使用与限制。
下面命令用于删除与当前路径下yml文件对应的POD/Service。
kubectl delete -f .
实验内存超限制
petclinic-deployment.yml文件样例修改。
修改位置:
- replicas
- requests - memory
- limits -memory
启动5个POD,每个容器启动的时候都需要1个G的内存。总量接近5个G,实际上本NODE只给了4G内存。
apiVersion: apps/v1
kind: Deployment
metadata:
name: petclinic
spec:
replicas: 5
selector:
matchLabels:
app: petclinic
template:
metadata:
labels:
app: petclinic
spec:
containers:
- name: petclinic
# Run this image
image: spring2go/spring-petclinic:1.0.0.RELEASE
resources:
requests:
memory: "1024Mi"
# 200 minicore, 1000m = 1core
cpu: "200m"
limits:
memory: "1024Mi"
envFrom:
- configMapRef:
name: petclinic-config
---
apiVersion: v1
kind: Service
metadata:
# Unique key of the Service instance
name: petclinic
spec:
ports:
# Accept traffic sent to port 80
- name: http
# port为集群内部服务前通信的端口
port: 8080
targetPort: 8080
nodePort: 31080
selector:
# 下面标签app: petclinic表示本服务会路由指向所有app标签为petclinic的pod。
app: petclinic
type: NodePort
发布服务之后,查看POD。
kubectl get po
发现pending状态的POD。由于节点内存不够,所以一直pending。
查看本机节点名称
kubectl get node
查看本机节点与运行POD的详情
kubectl describe node node_name
#找到Capacity, CPU, Memory, PODs数量, 已启动的POD的资源使用与限制。
下面命令用于删除与当前路径下yml文件对应的POD/Service。
kubectl detele -f .
实验限制内存过小
petclinic-deployment.yml文件样例修改。
修改位置:
- replicas
- requests - memory
- limits -memory
启动5个POD,每个容器启动的时候都需要1个G的内存。总量接近5个G,实际上本NODE只给了4G内存。
apiVersion: apps/v1
kind: Deployment
metadata:
name: petclinic
spec:
replicas: 1
selector:
matchLabels:
app: petclinic
template:
metadata:
labels:
app: petclinic
spec:
containers:
- name: petclinic
# Run this image
image: spring2go/spring-petclinic:1.0.0.RELEASE
resources:
requests:
memory: "20Mi"
# 200 minicore, 1000m = 1core
cpu: "200m"
limits:
memory: "20Mi"
envFrom:
- configMapRef:
name: petclinic-config
---
apiVersion: v1
kind: Service
metadata:
# Unique key of the Service instance
name: petclinic
spec:
ports:
# Accept traffic sent to port 80
- name: http
# port为集群内部服务前通信的端口
port: 8080
targetPort: 8080
nodePort: 31080
selector:
# 下面标签app: petclinic表示本服务会路由指向所有app标签为petclinic的pod。
app: petclinic
type: NodePort
发布服务之后,查看POD。
kubectl get po
#发现CrashLoopBackOff状态的POD。Restarts次数为1。因为该应用本身需要的运行内存大于20兆。
kubectl get po
#发现OOMKilled状态的POD。Restarts次数为2。K8S Limit生效,将POD Kill掉。
环境清理。
下面命令用于删除与当前路径下yml文件对应的deployment/Service。
kubectl detele -f .
本文介绍了Kubernetes中Request和Limit的概念,它们用于管理容器的CPU和内存资源。Request是预估应用所需的资源,影响POD调度;Limit则是资源使用上限,超出会导致容器被限制或终止。此外,还讲解了QoS类别及其Pod杀戮策略,并通过实例演示了内存超限和限制过小的实验情况。
667

被折叠的 条评论
为什么被折叠?



