惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Google Online Security Blog
Google Online Security Blog
S
Security @ Cisco Blogs
Recent Commits to openclaw:main
Recent Commits to openclaw:main
人人都是产品经理
人人都是产品经理
The Hacker News
The Hacker News
W
WeLiveSecurity
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
The Cloudflare Blog
博客园 - 司徒正美
雷峰网
雷峰网
L
LINUX DO - 最新话题
博客园 - 叶小钗
云风的 BLOG
云风的 BLOG
The Last Watchdog
The Last Watchdog
V2EX - 技术
V2EX - 技术
S
Security Affairs
有赞技术团队
有赞技术团队
月光博客
月光博客
T
Threatpost
T
Tor Project blog
O
OpenAI News
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
V
V2EX
Know Your Adversary
Know Your Adversary
Project Zero
Project Zero
博客园 - 三生石上(FineUI控件)
D
Docker
AWS News Blog
AWS News Blog
AI
AI
P
Proofpoint News Feed
K
Kaspersky official blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
D
Darknet – Hacking Tools, Hacker News & Cyber Security
www.infosecurity-magazine.com
www.infosecurity-magazine.com
S
Securelist
F
Fortinet All Blogs
F
Full Disclosure
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
量子位
Hacker News - Newest:
Hacker News - Newest: "LLM"
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
P
Palo Alto Networks Blog
Cyberwarzone
Cyberwarzone
Cisco Talos Blog
Cisco Talos Blog
美团技术团队
N
News | PayPal Newsroom
T
The Blog of Author Tim Ferriss
MyScale Blog
MyScale Blog

蛮荆

如何获取更多的免费服务器 Kubernetes 调度器队列 - 设计与实现 Kubernetes 调度器 - 核心流程 Kubernetes Networking Model & CNI Kubernetes 控制器管理总结 Kubernetes CronJob 设计与实现 Kubernetes Job 设计与实现 Kubernetes HPA 设计与实现 Kubernetes Deployment 滚动更新实现原理 Kubernetes GC 设计与实现 Kubernetes Pod 驱逐 - 设计与实现 Kubernetes Daemonset 设计与实现 Kubernetes ReplicaSet 设计与实现 Kubernetes EndPoint 设计与实现 Kubernetes Informer 设计与实现 降本增效之应用优化 (三) 日志存储与检索 Kubernetes Pod 设计与实现 - 创建流程 Kubernetes 探针设计与实现 Unix 编程艺术名句摘录 Kubernetes - CRI 概述 Golang 编译速度为什么这么快? Kubernetes Pod 设计与实现 - Pause 容器 Kubernetes - kube-proxy 代理模式工程优化 Kubernetes 应用最佳实践 - 优雅关闭长连接 Kubernetes Service 类型和会话亲和性 Kubernetes 为什么需要 Ingress Kubernetes 架构 - 控制平面和数据平面 降本增效之应用优化 (二) 大报表 Go 语言如何获取 CPU 利用率 降本增效之应用优化 (一) Redis 业务规则引擎演变过程简述 微服务中的熔断算法 漏桶算法和令牌桶算法 jsonparser 为什么比标准库的 encoding/json 快 10 倍 ? zap 高性能设计与实现 HTTP Router 算法演进 fastcache 高性能设计与实现 Web 常见的三个安全问题 ants Code Reading Go 线程安全 map 方案选型 布隆过滤器 死锁、活锁、饥饿、自旋锁 sync.Pool Code Reading Go 内存管理概述 Go netpoll Code Reading goroutine 泄漏与检测 time/Timer Code Reading GMP Scheduler Code Reading Go channel 的 15 条规则和底层实现 为什么 Linux “一切皆文件” context.Context Code Reading runtime/HACKING.md Goland 最佳实践 互联网开发与金庸武学 为什么 Redis 6.0 引入多线程模型? Kubernetes 应用最佳实践 - 金丝雀发布 容器中如何正确配置 GOMAXPROCS ? singleflight Code Reading sync.Map Code Reading sync.Cond Code Reading sync.WaitGroup Code Reading sync.RWMutex Code Reading sync.Mutex Code Reading sync.Once Code Reading Go 无锁编程 sync/atomic Code Reading goroutine 交替打印奇偶数 GODEBUG Go 并发模式 Go 汇编 UUID 通用技术选型 Kubernetes 应用最佳实践 - 水平自动伸缩 Go 高性能 Tips fasthttp 为什么比标准库 net/http 快 10 倍 ? 技术文章配图指南 ChatGPT 初体验 Docker 网络原理概览 iptables 的五表五链 Kubernetes 应用最佳实践 - 亲和性和污点容忍度 Go 的反射与三大定律 Docker 官方提供的最佳实践 Go 语言内置的设计模式 HTTP1 到 HTTP3 的工程优化 Kubernetes 应用最佳实践 - Sidecar 模式 Kubernetes 应用最佳实践 - init 容器和钩子函数 为什么 recover 必须在 defer 中调用? 为什么 defer 的执行顺序和注册顺序不同? Go map 设计与实现 Go 切片扩容底层实现 Go 语言中的零拷贝 Go Delve 云原生和边缘计算简介 Kubernetes 应用最佳实践 - 探针 Kubernetes 应用最佳实践 - 资源请求和限制 CDN 原理 Kubernetes 应用最佳实践 - 开篇 缓存策略和模式 Go 内存模型 Kubernetes 核心概念 软件版本语义化
Kubernetes Pod 服务质量等级
2023-03-07 · via 蛮荆

2023-03-07 Cloud Native Kubernetes Kubernetes 应用最佳实践

概述

本文主要是对 Kubernetes 应用最佳实践 - 资源请求和限制 的补充。

kubernetes 会自动将 Pod 的服务质量 (QoS) 分成三个等级,每个等级可以指定 Node 在资源不足时以什么策略来驱逐 Pod。

服务等级等级 优先级
BestEffort 最低
Guaranteed 最高
Burstable

BestEffort

BestEffort 是优先级最低的 Qos 等级,针对的目标是没有设置任何资源请求 (requests) 和资源限制 (limits) 的 Pod

# BestEffort 优先级示例
containers:
  name: foo
    resources:
  name: bar
    resources:

如果 Pod 的 Qos 等级是 BestEffort, 那么在极端情况下,这些 Pod 分配不到任何资源 (CPU, 内存等),同时当节点资源不足时,这些 Pod 会被优先终止, 不过有坏的一面,也有好的一面,当节点资源充足时,这些 Pod 同样会充分使用资源。

Guaranteed

Guaranteed 是优先级最高的 Qos 等级,针对的目标是已经设置了资源请求(requests) 和资源限制 (limits) 的 Pod

Guaranteed 等级的 Pod 需要满足以下几个条件:

  1. Pod 内的每个容器都需要设置 requests 和 limits (requests 默认情况下和 limits 相等,所以可以不用单独设置)
  2. requests 和 limits 指标必须同时包括 CPU 和内存
  3. requests 和 limits 指标值必须相等 (例如内存的 requests 和 limits 都是 2 GB)
# Guaranteed 优先级示例

containers:
  name: foo
    resources:
      limits:
        cpu: 10m
        memory: 1Gi
      requests:
        cpu: 10m
        memory: 1Gi
  name: bar
    resources:
      limits:
        cpu: 10m
        memory: 1Gi
      requests:
        cpu: 10m
        memory: 1Gi

如果 Pod 的 Qos 等级是 Guaranteed, 可以使用请求到的资源 (request),但是不能超过资源的限制量 (limits)。

Burstable

Burstable 是介于 BestEffort 和 Guaranteed 之间的 Qos 等级,如果 Pod 不属于上述两个等级,就属于 Burstable 等级。

通过 BestEffort 和 Guaranteed 两个等级的条件,我们可以得出 Burstable 等级的满足条件:

  1. Pod 内只有单个容器,且容器的 requests 和 limits 不相等
  2. Pod 内有多个容器,且至少有一个容器没有设置 limits
  3. Pod 内有多个容器,且至少有两个容器的 requests 和 limits 不相等 (包括没有设置的情况)
# Burstable 优先级示例
containers:
  name: foo
    resources:
      limits:
        cpu: 10m
        memory: 1Gi
      requests:
        cpu: 10m
        memory: 1Gi

  name: bar
    resources:
      limits:
        cpu: 100m
        memory: 100Mi
      requests:
        cpu: 100m
        memory: 100Mi

如果 Pod 的 Qos 等级是 Burstable, 可以使用请求到的资源 (request),如果设置了资源限制量 limits (则不能超过 limits),如果没有设置资源限制量 limits (可以充分利用资源)。


表格小结

根据上文中 Pod 和 Qos 等级之间的关系描述,我们可以总结出如下表格。

CPU (requests + limits) 内存 (requests + limits) QoS 等级
未设置 未设置 BestEffort
未设置 requests <= limits Burstable
requests <= limits 未设置 Burstable
requests = limits requests < limits Burstable
requests < limits requests = limits Burstable
requests = limits requests = limits Guaranteed

资源不足时的驱逐策略

当节点资源不足时,会驱逐 Pod 并释放出资源给优先级高的 Pod 使用,此时被驱逐的 Pod 的 Qos 等级依次为: BestEffort, Burstable, Guaranteed, Guaranteed 等级的 Pod 只有在系统进程需要资源时才会被驱逐。

如果两个 Pod 的 Qos 等级相同,会优先驱逐资源实际使用量占请求量比例更高的 Pod

最佳实践

  • 设置 Pod 的资源 requests 和 limits 参数时,要根据节点资源总量预留出一定的缓冲区,避免节点的资源耗尽
  • 将关键业务应用 Pod 的 Qos 等级设置为 Guaranteed, 保证其资源可用性和运行的稳定性
  • 非关键业务应用 Pod 的 Qos 等级可以适当调整为 Burstable, 预留出一定的弹性
  • 避免使用 BestEffort 等级,因为该等级不能提供任何资源保证,即使在资源充足时,该等级对应的 Pod 申请资源过程也是不可控的
  • 不仅要关注 Pod 的资源 requests 和 limits 参数,同时还要关注资源 requests 请求量和实际使用量,持续监控和调整

Reference