资源需求(Requests)和限制( Limits)
- name: jobmanager
image: ponylee/flink:1.15.0-java8
workingDir: /opt/flink
ports:
- containerPort: 6123
name: rpc
- containerPort: 6124
name: blob
- containerPort: 8081
name: ui
resources:
limits:
cpu: "1"
memory: "1Gi"
requests:
cpu: 250m
memory: "100Mi"
requests: Initial resource request for CPU and memory 容器需要的最低资源量(CPU,MEM)
limits: Upper limit until we want our application to grow at max 容器运行中所能分配的最大资源量
- 对于每一个资源,container可以指定具体的资源需求(requests)和限制(limits),requests申请范围是0到node节点的最大配置,而limits申请范围是requests到无限,
即0 <= requests <=Node Allocatable, requests <= limits <= Infinity。
- 对于CPU,如果pod中服务使用CPU超过设置的limits,pod不会被kill掉但会被限制。如果没有设置limits,pod可以使用全部空闲的cpu资源。
- 【k8s|Kubernetes服务质量保证之配置容器资源limits和requests】对于内存,当一个pod使用内存超过了设置的limits,pod中container的进程会被kernel因OOM kill掉。当container因为OOM被kill掉时,系统倾向于在其原所在的机器上重启该container或本机或其他重新创建一个pod。
- Best-Effort 最大努力
requests和limits两个参数都没有设置。就是没有对资源做限制,只要节点有足够资源会尽可能满足其需求。但是这种容器优先级是最低的:节点CPU或MEM资源不够时,会优先把该类容器杀掉以回收资源。
- Burstable 爆发的
requests和limits都有设置并且requests小于limits。即最低要求requests所指定的资源,最高以limits为上限。优先级较Best-Effort高一点: 节点资源不足时,如果没有Best-Effort类型的容器,会删除该类容器。
- Guaranteed 有保障的
requests参数与limits参数相同。具有最高优先级,资源不足时会优先删除Best-Effort和Burstable类容器以确保其运行。使用建议
- 如果资源充足,可将QoS pods类型均设置为Guaranteed。用计算资源换业务性能和稳定性,减少排查问题时间和成本。
- 如果想更好的提高资源利用率,业务服务可以设置为Guaranteed,而其他服务根据重要程度可分别设置为Burstable或Best-Effort,例如filebeat。
推荐阅读
- Kubernetes 标准化部署文档
- #云原生征文#深入Kubernetes(k8s)概念
- 云原生 | Kubernetes篇Kubernetes简介
- #云原生征文#Kubernetes集群部署
- #云原生征文#深入了解k8s的Pod
- 云原生|【微服务~远程调用】RestTemplate基本操作快速入门
- 云原生|【云原生实战】DevOps基础与实战项目
- kubernetes 核心组件之 APIServer
- kubernetes 核心组件之 Controller Manager