> For the complete documentation index, see [llms.txt](https://darren.gitbook.io/project/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://darren.gitbook.io/project/gai-nian-yu-yuan-li/untitled-2/qos-fu-wu-zhi-liang-deng-ji.md). # QoS（服务质量等级） QoS（Quality of Service），大部分译为“服务质量等级”，又译作“服务质量保证”，是作用在 Pod 上的一个配置，当 Kubernetes 创建一个 Pod 时，它就会给这个 Pod 分配一个 QoS 等级，可以是以下等级之一：+ * **Guaranteed**：Pod 里的每个容器都必须有内存/CPU 限制和请求，而且值必须相等。如果我们配置了limit，没有配置request，默认会以limit的值来定义request * **Burstable**：Pod 里至少有一个容器有内存或者 CPU 请求且不满足 Guarantee 等级的要求，即内存/CPU 的值设置的不同。 * **BestEffort**：容器必须没有任何内存或者 CPU 的限制或请求。 关于request和limit参考 [pod其他设置](https://darren.gitbook.io/project/~/edit/drafts/-LUF8vUYyGJ55B0Pam-g/gai-nian-yu-yuan-li-1/zi-yuan-dui-xiang/pod/pod-qi-ta-she-zhi#zi-yuan-xian-zhi) 该配置不是通过一个配置项来配置的，而是通过配置 CPU/内存的 `limits` 与 `requests` 值的大小来确认服务质量等级的。使用 `kubectl get pod -o yaml` 可以看到 pod 的配置输出中有 `qosClass` 一项。该配置的作用是为了给资源调度提供策略支持，调度算法根据不同的服务质量等级可以确定将 pod 调度到哪些节点上。 在Kubernetes中，POD的QoS服务质量一共有三个级别，如下图所示： ![](https://55104664-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LFq8o_9x6ob05ww-sNi%2F-LOW5crzFZ6nfKxt82FX%2F-LOW6xHH3BW5CdDY4M7U%2Fimage.png?alt=media\&token=411a32a3-210b-4904-9c30-76a8ec7c24ed) 这三个QoS级别介绍，可以看下面表格： | QoS级别 | QoS介绍 | | ---------- | ------------------------------------------------------------------------------------------------------- | | BestEffort | POD中的所有容器都没有指定CPU和内存的requests和limits，那么这个POD的QoS就是BestEffort级别 | | Burstable | POD中只要有一个容器，这个容器requests和limits的设置同其他容器设置的不一致，那么这个POD的QoS就是Burstable级别 | | Guaranteed | POD中所有容器都必须统一设置了limits，并且设置参数都一致，如果有一个容器要设置requests，那么所有容器都要设置，并设置参数同limits一致，那么这个POD的QoS就是Guaranteed级别 | 为了更清楚的了解这三个QoS级别，下面我们举例说明。 ![](https://55104664-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LFq8o_9x6ob05ww-sNi%2F-LOW5crzFZ6nfKxt82FX%2F-LOW7irGPbQclwgEdX-E%2Fimage.png?alt=media\&token=213b97ad-4dd0-4f7f-9cf9-455496ae270a) ![](https://55104664-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LFq8o_9x6ob05ww-sNi%2F-LOW5crzFZ6nfKxt82FX%2F-LOW8i4ubFMCFzmQYU9z%2Fimage.png?alt=media\&token=6b2d5613-80d1-43d4-95cb-d48448508aa6) ![](https://55104664-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LFq8o_9x6ob05ww-sNi%2F-LOW5crzFZ6nfKxt82FX%2F-LOW8q5acYvxgXXPvSLr%2Fimage.png?alt=media\&token=114d6d4e-070e-42ba-adc8-135659fad178) ![](https://55104664-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LFq8o_9x6ob05ww-sNi%2F-LOW5crzFZ6nfKxt82FX%2F-LOW971bsuee2NJmac0v%2Fimage.png?alt=media\&token=f80f687e-d56f-4cb6-bd0f-8ae83d210df8) ![](https://55104664-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LFq8o_9x6ob05ww-sNi%2F-LOW5crzFZ6nfKxt82FX%2F-LOW9CNlnmVRnoF_USEj%2Fimage.png?alt=media\&token=3a2c18b3-4700-44f0-b1db-7fcb636e27b2) QoS级别决定了kubernetes处理这些POD的方式，我们以内存资源为例： 1、当NODE节点上内存资源不够的时候，QoS级别是BestEffort的POD会最先被kill掉；当NODE节点上内存资源充足的时候，QoS级别是BestEffort的POD可以使用NODE节点上剩余的所有内存资源。 2、当NODE节点上内存资源不够的时候，如果QoS级别是BestEffort的POD已经都被kill掉了，那么会查找QoS级别是Burstable的POD，并且这些POD使用的内存已经超出了requests设置的内存值，这些被找到的POD会被kill掉；当NODE节点上内存资源充足的时候，QoS级别是Burstable的POD会按照requests和limits的设置来使用。 3、当NODE节点上内存资源不够的时候，如果QoS级别是BestEffort和Burstable的POD都已经被kill掉了，那么会查找QoS级别是Guaranteed的POD，并且这些POD使用的内存已经超出了limits设置的内存值，这些被找到的POD会被kill掉；当NODE节点上内存资源充足的时候，QoS级别是Burstable的POD会按照requests和limits的设置来使用。 从容器的角度出发，为了限制容器使用的CPU和内存，是通过cgroup来实现的，目前kubernetes的QoS只能管理CPU和内存，所以kubernetes现在也是通过对cgroup的配置来实现QoS管理的。 ![](https://55104664-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LFq8o_9x6ob05ww-sNi%2F-LOW5crzFZ6nfKxt82FX%2F-LOW9WE20aYIUphPJmCV%2Fimage.png?alt=media\&token=212562fb-5865-4732-8089-575c05dcd78c) 原文链接：