Guaranteed,Burstable, BestEfford-Kubernetes服务质量类

本文介绍了Kubernetes中Pod的质量服务类别(QoS Classes),包括Guaranteed、Burstable和BestEffort三种类型,详细解释了不同类型的配置要求及如何通过配置文件实现这些QoS类别。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在CAdvisor监控数据中,看到容器分了好多层,其中有burstable.slice, bestefford.slice,这个到底是什么意思呢?

原来这个是Kubernetes在Cgroup中的分类,用于对容器资源的控制(CPU, 内存)。

Kubernetes服务质量类包含三类:Guaranteed,Burstable, BestEfford。

QoS classes

When Kubernetes creates a Pod it assignsone of these QoS classes to the Pod:

   Guaranteed

   Burstable

   BestEffort

例如:

1、Create aPod that gets assigned a QoS class of Guaranteed

For a Podto be given a QoS class of Guaranteed:

    Every Container in the Pod must have a memory limit and a memory request, and they must be the same.

    Every Container in the Pod must have a cpu limit and a cpu request, and they must be the same.

Here isthe configuration file for a Pod that has one Container. The Container has a memorylimit and a memory request, both equal to 200 MiB. The Container has a cpulimit and a cpu request, both equal to 700 millicpu:

 

2、Create a Podthat gets assigned a QoS class of Burstable

A Pod isgiven a QoS class of Burstable if:

    The Pod does not meet the criteria for QoSclass Guaranteed.

    At least one Container in the Pod has amemory or cpu request.

Here isthe configuration file for a Pod that has one Container. The Container has amemory limit of 200 MiB and a memory request of 100 MiB.

 

3、Create aPod that gets assigned a QoS class of BestEffort

For a Podto be given a QoS class of BestEffort, the Containers in the Pod must not haveany memory or cpu limits or requests.

Here isthe configuration file for a Pod that has one Container. The Container has nomemory or cpu limits or requests:

参考:https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/

例子:

[docker@shanghai ~]$ kubectl get pod kubernetes-dashboard-747c4f7cf-dsr2v -o yaml -n kube-system 
apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubernetes.io/created-by: |
      {"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"kube-system","name":"kubernetes-dashboard-747c4f7cf","uid":"d8581f0c-e7ad-11e7-be5b-000c29e02f07","apiVersion":"extensions","resourceVersion":"1172"}}
  creationTimestamp: 2017-12-23T06:52:30Z
  generateName: kubernetes-dashboard-747c4f7cf-
  labels:
    k8s-app: kubernetes-dashboard
    pod-template-hash: "303709379"
  name: kubernetes-dashboard-747c4f7cf-dsr2v
  namespace: kube-system
  ownerReferences:
  - apiVersion: extensions/v1beta1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: kubernetes-dashboard-747c4f7cf
    uid: d8581f0c-e7ad-11e7-be5b-000c29e02f07
  resourceVersion: "3020906"
  selfLink: /api/v1/namespaces/kube-system/pods/kubernetes-dashboard-747c4f7cf-dsr2v
  uid: d86174c8-e7ad-11e7-be5b-000c29e02f07
spec:
  containers:
  - args:
    - --tls-key-file=/certs/dashboard.key
    - --tls-cert-file=/certs/dashboard.crt
    image: gcr.io/google_containers/kubernetes-dashboard-amd64:v1.7.1
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 3
      httpGet:
        path: /
        port: 8443
        scheme: HTTPS
      initialDelaySeconds: 30
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 30
    name: kubernetes-dashboard
    ports:
    - containerPort: 8443
      protocol: TCP
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /certs
      name: kubernetes-dashboard-certs
      readOnly: true
    - mountPath: /tmp
      name: tmp-volume
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kubernetes-dashboard-token-r8nvt
      readOnly: true
  dnsPolicy: ClusterFirst
  initContainers:
  - image: gcr.io/google_containers/kubernetes-dashboard-init-amd64:v1.0.1
    imagePullPolicy: IfNotPresent
    name: kubernetes-dashboard-init
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /certs
      name: kubernetes-dashboard-certs
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kubernetes-dashboard-token-r8nvt
      readOnly: true
  nodeName: shanghai
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: kubernetes-dashboard
  serviceAccountName: kubernetes-dashboard
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
  - effect: NoExecute
    key: node.alpha.kubernetes.io/notReady
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.alpha.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: kubernetes-dashboard-certs
    secret:
      defaultMode: 420
      secretName: kubernetes-dashboard-certs
  - emptyDir: {}
    name: tmp-volume
  - name: kubernetes-dashboard-token-r8nvt
    secret:
      defaultMode: 420
      secretName: kubernetes-dashboard-token-r8nvt
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: 2017-12-23T06:52:34Z
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: 2018-05-18T01:16:25Z
    status: "True"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: 2017-12-23T06:52:30Z
    status: "True"
    type: PodScheduled
  containerStatuses:
  - containerID: docker://b577fed877522034b5f613d720061e7d238762dd804a8933004f01e478d1553a
    image: gcr.io/google_containers/kubernetes-dashboard-amd64:v1.7.1
    imageID: docker://sha256:294879c6444ed35b8cb94c613e61c47b9938305a1d1eaf452c0d17db471d99e5
    lastState:
      terminated:
        containerID: docker://f6345017dc7dd242885a439b1b886c65573df4fba544e267c886d053c17dc267
        exitCode: 1
        finishedAt: 2018-05-18T01:13:49Z
        reason: Error
        startedAt: 2018-05-16T14:46:42Z
    name: kubernetes-dashboard
    ready: true
    restartCount: 22
    state:
      running:
        startedAt: 2018-05-18T01:16:20Z
  hostIP: 192.168.131.124
  initContainerStatuses:
  - containerID: docker://297b74cef9870e70f43c3744ed66e532e7ace15f5279f81eb35b0ef6cdfed77c
    image: gcr.io/google_containers/kubernetes-dashboard-init-amd64:v1.0.1
    imageID: docker://sha256:95bfc2b3e5a3375298b81c15e29bfd1e53d002ff48e5f22fdc808ae4207da7d4
    lastState: {}
    name: kubernetes-dashboard-init
    ready: true
    restartCount: 7
    state:
      terminated:
        containerID: docker://297b74cef9870e70f43c3744ed66e532e7ace15f5279f81eb35b0ef6cdfed77c
        exitCode: 0
        finishedAt: 2018-05-18T01:16:07Z
        reason: Completed
        startedAt: 2018-05-18T01:16:06Z
  phase: Running
  podIP: 192.168.101.25
  qosClass: BestEffort #《===================看这里=======================
  startTime: 2017-12-23T06:52:30Z
如果limit和request均未设置,则QoS为BestEffort类型。
<think>我们正在讨论如何合理配置Kubernetes中的资源请求(request)和限制(limit),以在资源利用率和服务质量(QoS)之间取得平衡。以下是最佳实践的总结,结合了引用内容和实际经验。 1. **理解请求(request)和限制(limit)的作用** - **请求(request)**:是容器启动所需的最小资源量,调度器根据节点的可用资源(总容量减去已分配请求的总和)来决定是否可以将Pod调度到该节点上。设置请求是为了保证Pod的“基本路权”[^1]。 - **限制(limit)**:是容器能够使用的资源上限,防止容器过度消耗资源(如CPU或内存)而影响其他容器。限制相当于防止“疯狂飙车”[^1]。 2. **设置请求和限制的黄金法则** - **重要服务(高优先级)**:将请求和限制设置为相同值(即资源固定分配)。这样做的好处是: - Pod的QoS级别为`Guaranteed`(最高优先级),在节点资源不足时不容易被驱逐[^3]。 - 适用于核心业务,如数据库、关键API服务等。 - 示例:`requests: cpu=2, memory=4Gi` 和 `limits: cpu=2, memory=4Gi`。 - **普通服务(中优先级)**:设置请求小于限制(例如,请求为限制的70%-80%)。这样做: - Pod的QoS级别为`Burstable`(中等优先级)。 - 允许服务在空闲时使用更多资源(利用闲置资源),但在资源紧张时限制其使用。 - 适用于一般业务应用,如Web服务、后台任务等。 - 示例:`requests: cpu=1, memory=2Gi` 和 `limits: cpu=1.5, memory=3Gi`。 - **低优先级或批处理任务**:可以只设置请求而不设置限制(或设置较高的限制),但风险是可能因资源竞争被驱逐。适用于可中断的任务(如数据分析作业)[^3]。 3. **提高资源利用率的技巧** - **超卖(Overcommitment)**:在节点上允许总请求量超过节点实际容量(但总限制不超过节点容量)。例如: - 节点有16核CPU,32Gi内存。 - 所有Pod的CPU请求总和为20核(超过16核),但CPU限制总和为24核(小于节点容量×超卖系数)。 - 这样在低负载时可提高利用率,但需监控节点负载,避免资源争用[^1]。 - **使用垂直扩缩容(VPA)**:根据历史使用量自动调整请求和限制。注意: - VPA不能与HPA(水平扩缩容)同时用于同一资源(如CPU),但可配合使用(例如HPA基于CPU,VPA基于内存)。 - **设置合理的资源值**: - 基于监控数据(如Prometheus)分析容器的实际使用量(P95/P99),避免凭猜测设置。 - 初始设置:启动时设置保守值(如请求=平均使用量×1.2,限制=峰值使用量×1.5),再逐步优化。 4. **保障服务质量QoS)的方法** - **避免“嘈杂邻居”问题**:通过限制确保单个容器不会耗尽节点资源。例如: - 限制内存可防止OOM Killer终止容器。 - 限制CPU可防止CPU饥饿(使用CFS配额实现)。 - **优先级和驱逐策略**: - 使用`PriorityClass`为关键Pod设置高优先级,确保在资源不足时优先保留。 - 在`kubelet`配置中调整驱逐阈值(如`--eviction-hard=memory.available<5%`)[^3]。 5. **持续优化实践** - **监控与告警**: - 监控指标:容器实际使用量 vs 请求量(利用率)、实际使用量 vs 限制量(饱和度)。 - 关键告警:当使用量持续低于请求量(如<50%)时,表示资源浪费;当使用量接近限制量(如>90%)时,表示需要扩容。 - **自动化调整**: - 使用VPA自动调整请求和限制(注意:需在非生产环境测试)。 - 定期检查资源分配情况(例如,`kubectl top pods` 对比 `kubectl describe node`)。 ### 配置示例 以下是一个Deployment的YAML片段,展示了如何为Web服务设置请求和限制: ```yaml resources: requests: cpu: "500m" # 0.5核 memory: "1Gi" # 1GB内存 limits: cpu: "1000m" # 1核 memory: "2Gi" # 2GB内存 ``` ### 总结 平衡资源利用率和服务质量的要点: 1. **按服务优先级选择策略**:关键服务用`Guaranteed`(请求=限制),普通服务用`Burstable`(请求<限制)。 2. **基于数据设置值**:使用历史监控数据(P95/P99)确定请求和限制。 3. **超卖与监控**:在可接受风险下超卖资源,并配合监控告警。 4. **持续优化**:通过VPA或手动调整定期优化配置[^1][^3]。 > 记住:好的资源管理不是一次性配置,而是持续优化的旅程![^1] §§相关问题§§ 1. 如何监控Kubernetes中资源请求和限制的利用率? 2. Kubernetes中如何配置VPA(垂直扩缩容)? 3. 如何解决Kubernetes中的“嘈杂邻居”问题? 4. Kubernetes资源超卖(Overcommit)的最佳实践是什么? 5. Kubernetes中有哪些常见的资源管理错误?</think>在 Kubernetes 中合理配置资源请求(Request)和限制(Limit)是优化资源利用率并确保服务质量QoS)的核心实践。以下是结合引用内容的最佳实践总结: ### 一、核心配置原则 1. **请求(Request)与限制(Limit)的黄金法则** - **请求(Request)**:容器启动的最小资源保障,调度器据此分配节点资源[^1][^3] *示例:`requests: cpu: "500m", memory: "1Gi"`* - **限制(Limit)**:容器资源使用的硬性上限,防止资源耗尽[^1][^2] *示例:`limits: cpu: "1", memory: "2Gi"`* - **平衡公式**: $$ \text{Request} \leq \text{实际使用量} \leq \text{Limit} $$ 实际使用量应基于P95/P99监控数据设定[^2] 2. **服务质量QoS)分级策略** | 配置方式 | QoS级别 | 驱逐优先级 | 适用场景 | |-------------------------|--------------|------------|------------------------| | Request = Limit | Guaranteed | 最低 | 核心服务(如数据库)[^3] | | Request < Limit | Burstable | 中等 | 普通应用(如Web服务) | | 未设置Request/Limit | BestEffort | 最高 | 非关键任务(批处理) | ### 二、优化资源利用率的关键实践 1. **重要服务配置** - 对核心业务(如支付系统): ```yaml resources: requests: {cpu: "1", memory: "2Gi"} limits: {cpu: "1", memory: "2Gi"} # Request=Limit ``` - ✅ 优点:获得最高QoS等级,避免节点故障时被驱逐[^3] - ⚠️ 注意:可能略微降低利用率(资源被固定预留) 2. **普通服务配置** - 对弹性应用(如API服务): ```yaml resources: requests: {cpu: "0.5", memory: "1Gi"} # 按平均负载设置 limits: {cpu: "1.5", memory: "3Gi"} # 按峰值负载设置 ``` - ✅ 优点:允许利用闲置资源(超卖),提高集群利用率[^1] - 📊 建议:`Limit/Request = 1.5~3`(根据业务波动调整) 3. **持续优化流程** ```mermaid graph TD A[监控实际使用量] --> B{分析P95/P99数据} B -->|使用量 < 60% Request| C[降低Request] B -->|使用量 > 90% Limit| D[提高Limit] B -->|波动剧烈| E[启用HPA+VPA] ``` ### 三、平衡利用率与稳定性的技巧 1. **避免资源浪费** - 定期检查:`kubectl top pods` 对比 Request 值 - 浪费判定:若 **实际使用量 < 50% Request** 持续24小时 ⇒ 需下调Request[^2] 2. **防止“嘈杂邻居”** - 关键操作: - 所有服务**必须设置Memory Limit**(避免OOM Killer误杀) - CPU Limit建议设为:`Request × 2`(允许突发流量) 3. **超卖(Overcommit)策略** - 安全比例(节点级别): $$ \frac{\sum\text{Requests}}{\text{Node Capacity}} \leq 150\% $$ $$ \frac{\sum\text{Limits}}{\text{Node Capacity}} \geq 100\% $$ - 监控指标:`kubelet` 的 `MemoryPressure`/`DiskPressure` ### 四、工具链推荐 1. **监控** - Prometheus + Grafana:采集容器实际使用量 - `kubectl describe node`:查看节点资源分配情况 2. **优化** - VPA(Vertical Pod Autoscaler):自动调整Request/Limit - Kube-resource-report:生成资源浪费报告 > 黄金实践总结:**像交通规则管理城市一样管理资源——Request保障“基本路权”,Limit防止“疯狂飙车”[^1]。持续监控和迭代配置,才能实现高效与稳定的平衡。**
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值