Kubernetes集群架构-关于 cgroup v2

Kubernetes集群架构-关于 cgroup v2

  • Kubernetes 集群架构 - 关于 cgroup v2
    • 什么是 cgroup v2?
    • 使用 cgroup v2
      • 要求
      • LInux 发行版对 cgroup v2 的支持
      • 迁移到 cgroup v2
    • 识别 LInux 节点上的 cgroup 版本
  • 链接

Kubernetes 集群架构 - 关于 cgroup v2

在 Linux 上,控制组1限制分配给进程的资源。

kubelet 和底层容器运行时需要与 cgroups 交互,以对Pod 和容器实施资源管理,包括 CPU/内存请求和容器化工作负载的限制。

目前在 Linux 中存在有两种版本的 cgroup:cgroup v1 和 cgroup v2,cgroup v2 是新一代的 cgroup API。

什么是 cgroup v2?

功能状态:Kubernetes v1.25 [stable]

cgroup v2 是 Linux cgroup API 的下一个版本。cgroup v2 提供了一个统一的控制系统,具有增强的资源管理功能。

与 cgroup v1 相比,cgroup v2 提供了多项改进,例如:

  • API 中单个统一的层次结构设计
  • 更安全的子树委派给容器
  • 更新的功能特性, 例如压力阻塞信息(Pressure Stall Information,PSI)
  • 跨多个资源的增强资源分配管理和隔离
    • 统一核算不同类型的内存分配(网络内存、内核内存等)
    • 考虑非即时资源变化,例如页面缓存回写

某些 Kubernetes 功能专门使用 cgroup v2 来增强资源管理和隔离。例如,MemoryQoS2 功能提高了内存 QoS,并依赖于 cgroup v2 原语3

使用 cgroup v2

使用 cgroup v2 的推荐方法是使用默认启用 cgroup v2 的 Linux 发行版。

检查系统是否支持 cgroup v2 可以参考下文。

要求

cgroup v2 具有以下要求:

  • 操作系统发行版启用 cgroup v2
  • Linux 内核为 5.8 或更高版本
  • 容器运行时支持 cgroup v2。例如:
    • containerd v1.4 和更高版本
    • cri-o v1.20 和更高版本
  • kubelet 和容器运行时被配置为使用 systemd cgroup 驱动

LInux 发行版对 cgroup v2 的支持

有关使用 cgroup v2 的 Linux 发行版的列表,请参阅 cgroup v2 文档

  • Container-Optimized OS(从 M97 开始)
  • Ubuntu(从 21.10 开始,推荐 22.04+)
  • Debian GNU/Linux(从 Debian 11 Bullseye 开始)
  • Fedora(从 31 开始)
  • Arch Linux(从 2021 年 4 月开始)
  • RHEL 和类似 RHEL 的发行版(从 9 开始)

要检查Linux 发行版是否使用 cgroup v2,请参阅发行版文档或按照下下文的介绍进行操作。

还可以通过修改内核 cmdline 引导参数,在 Linux 发行版上手动启用 cgroup v2。如果发行版使用 GRUB,则应在 /etc/default/grub 下的 GRUB_CMDLINE_LINUX 中添加 systemd.unified_cgroup_hierarchy=1,然后是 sudo update-grub。但是,建议的方法是使用已默认启用 cgroup v2 的发行版。

迁移到 cgroup v2

要迁移到 cgroup v2,请确保满足要求,然后升级到默认启用 cgroup v2 的内核版本。

kubelet 会自动检测操作系统正在 cgroup v2 上运行,并执行相应的操作,无需额外配置。

切换到 cgroup v2 时,用户体验应该不会有任何明显差异,除非用户直接在节点上或从容器内访问 cgroup 文件系统。

cgroup v2 使用与 cgroup v1 不同的 API,因此,如果有任何应用程序直接访问 cgroup 文件系统,则需要将它们更新到支持 cgroup v2 的新版本。例如:

  • 一些第三方监控和安全代理可能依赖于 cgroup 文件系统。要将这些代理更新到支持 cgroup v2 的版本。
  • 如果以独立的 DaemonSet 的形式运行 cAdvisor4 以监控 Pod 和容器, 需将其更新到 v0.43.0 或更高版本。
  • 如果部署了 Java 应用程序,最好使用完全支持 cgroup v2 的版本:
    • OpenJDK / HotSpot: jdk8u372、11.0.16、15 及更高的版本
    • IBM Semeru Runtimes: 8.0.382.0、11.0.20.0、17.0.8.0 及更高的版本
    • IBM Java: 8.0.8.6 及更高的版本
  • 如果正在使用 uber-go/automaxprocs5包, 确保使用的版本是 v1.5.1 或者更高。

识别 LInux 节点上的 cgroup 版本

cgroup 版本取决于所使用的 Linux 发行版和操作系统上配置的默认 cgroup 版本。要检查发行版使用的 cgroup 版本,请在节点上运行 stat -fc %T /sys/fs/cgroup/ 命令:

stat -fc %T /sys/fs/cgroup/

对于 cgroup v2,输出为 cgroup2fs

对于 cgroup v1,输出为 tmpfs.

链接

  • Kubernetes Cluster Architecture About cgroup v2
  • 对Pod 和容器实施资源管理
  • 压力阻塞信息(Pressure Stall Information,PSI)
  • Pod Quality of Service Classes
  • 容器运行时
  • cgroup v2 文档

  1. Linux中的控制组(Control Group,cgroup)是一种内核特性,它可以将进程分组,并且对这些组进行资源限制(如CPU、内存、磁盘I/O等)和监控,从而有效管理和分配系统资源,确保系统的稳定性和性能。 ↩︎

  2. K8S中的MemoryQos是一种内存服务质量保障机制,通过为容器或Pod设置内存请求和限制,来确保内存资源在不同工作负载间合理分配,同时保障关键应用的内存使用,避免因内存竞争导致的应用异常。 ↩︎

  3. 原语是操作系统或计算机程序设计语言中,由若干条指令组成的、用于完成一个特定基本功能的不可分割的操作序列,它具有原子性,即要么全部执行,要么全部不执行。 ↩︎

  4. cAdvisor是一个运行在容器环境(如Kubernetes集群)中的容器资源监控工具,它可以收集容器的CPU、内存、网络I/O和磁盘I/O等资源使用信息,并提供相应的监控数据接口,帮助用户了解容器的资源消耗情况。 ↩︎

  5. automaxprocs是一个Go语言库,它能够自动根据机器的CPU核心数来设置Go程序运行时的最大可用CPU数(GOMAXPROCS),从而优化Go程序在不同环境下的性能。 ↩︎

你可能感兴趣的:(云原生,linux,kubernetes,linux,云原生,kubernetes)