期待已久:K8S终于迎来交换内存Beta支持!

这篇具有很好参考价值的文章主要介绍了期待已久:K8S终于迎来交换内存Beta支持!。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

关注【云原生百宝箱】公众号,获取更多云原生消息

期待已久:K8S终于迎来交换内存Beta支持!,公众号#云原生百宝箱,kubernetes,java,容器,云原生

Kubernetes 1.22 版本开始支持在 Linux 节点上使用交换内存的 Alpha 特性,而在 1.28 版本中升级为 Beta 版本并进行了许多改进。之前版本的 Kubernetes 不支持 Linux 系统上的交换内存,但随着 Alpha 版本和后续的改进,Kubernetes 项目团队投入大量精力支持交换内存的 Beta 版本,使其更稳定、健壮和用户友好。 

此功能的使用方法包括激活 kubelet 上的 NodeSwap 特性门控,并配置 memorySwap.swapBehavior 选项来定义节点使用交换内存的方式。

1.22前不支持交换内存

在之前的版本中,Kubernetes 不支持在 Linux 上使用交换内存,因为涉及交换时很难提供保证和解释 pod 内存利用率。作为 Kubernetes 早期设计的一部分,交换支持被认为超出了范围,如果在节点上检测到交换,则默认情况下 kubelet 将无法启动

以下是一些关于 Kubernetes 1.22版本以前禁用内存交换的考虑:

  1. 1. 性能: 内存交换可能对容器的性能产生负面影响。当容器中的进程试图访问已经被交换出去的内存时,系统需要将其从磁盘交换回内存,这会导致性能下降。

  2. 2. 不确定性: 内存交换可能会引入不确定性。容器应该在其配置的内存限制范围内运行。如果发生了内存交换,容器的实际可用内存可能会受到不可控因素的影响,从而导致应用程序运行不稳定。

  3. 3. 资源保证: Kubernetes 在调度和管理容器时会依赖 cgroups 和 Linux 内核功能来确保资源隔离和限制。内存交换可能破坏了这种隔离性,使得 Kubernetes 对容器资源的管理变得更加困难。

  4. 4. 安全性考虑: 内存交换可能会使得敏感信息泄露到交换分区,这可能对安全性造成威胁。

然而,有许多需要使用交换内存的用例[1] 将受益于支持交换的 Kubernetes 节点,包括提高节点稳定性、更好地支持内存开销高但工作集较小的应用程序、内存受限设备的使用以及内存灵活性。

1.22开始支持交换内存

Kubernetes 1.22 版本为交换内存引入了一项 Alpha 支持[2], 用于为在 Linux 节点上运行的 Kubernetes 工作负载逐个节点地配置交换内存使用。现在,在 1.28 版中,对 Linux 节点上的交换内存的支持已升级为 Beta 版,并有许多新的改进。

在 1.22 版之前,Kubernetes 不提供对 Linux 系统上交换内存的支持。这是由于在涉及交换内存时保证和计算 Pod 内存利用率的固有困难。因此,交换内存支持被认为超出了 Kubernetes 的初始设计范围,并且如果在节点上检测到交换内存, kubelet 的默认行为是无法启动。

在 1.22 版中,Linux 的交换特性以 Alpha 阶段初次引入。这代表着一项重大进步,首次为 Linux 用户提供了尝试交换内存特性的机会。然而,作为 Alpha 版本,它尚未开发完成,并存在一些问题, 包括对 cgroup v2 支持的不足、指标和 API 统计摘要不足、测试不足等等。

Kubernetes 有许多交换内存用例[3], 并适用于大量用户。因此,Kubernetes 项目内的节点特别兴趣小组投入了大量精力来支持 Linux 节点上的交换内存特性的 Beta 版本。 与 Alpha 版本相比,启用交换内存后 kubelet 的运行更加稳定和健壮,更加用户友好,并且解决了许多已知缺陷。 这次升级到 Beta 版代表朝着实现在 Kubernetes 中完全支持交换内存的目标迈出了关键一步。

如何使用此特性?

通过激活 kubelet 上的 NodeSwap 特性门控,可以在已配置交换内存的节点上使用此特性。此外,你必须禁用 failSwapOn 设置,或者停用已被弃用的 --fail-swap-on 命令行标志。

可以配置 memorySwap.swapBehavior 选项来定义节点使用交换内存的方式。例如:

# 将此段内容放入 kubelet 配置文件
memorySwap:
  swapBehavior: UnlimitedSwap

swapBehavior 的可用配置选项有:

  • • UnlimitedSwap(默认):Kubernetes 工作负载可以根据请求使用尽可能多的交换内存,最多可达到系统限制。

  • • **LimitedSwap**:Kubernetes 工作负载对交换内存的使用受到限制。只有 BurstableQoS Pod [4] 才允许使用交换内存。

如果未指定 memorySwap 的配置并且启用了特性门控,则默认情况下, kubelet 将应用与 UnlimitedSwap 设置相同的行为。

请注意,仅 cgroup v2 支持 NodeSwap针对 Kubernetes v1.28,不再支持将交换内存与 cgroup v1 一起使用。

使用 kubeadm 安装支持交换内存的集群

开始之前

此演示需要安装 kubeadm 工具, 安装过程按照 kubeadm 安装指南[5]中描述的步骤进行操作。如果节点上已启用交换内存,则可以继续创建集群。如果未启用交换内存,请参阅提供的启用交换内存说明。

创建交换内存文件并开启交换内存功能

我将演示创建 4GiB 的未加密交换内存。

dd if=/dev/zero of=/swapfile bs=128M count=32
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
swapon -s # 仅在该节点被重新启动后启用该交换内存文件

要在引导时启动交换内存文件,请将诸如 /swapfile swap swap defaults 0 0 的内容添加到 /etc/fstab 文件中。

在 Kubernetes 集群中设置开启交换内存的节点

清晰起见,这里给出启用交换内存特性的集群的 kubeadm 配置文件示例 kubeadm-config.yaml

---
apiVersion: "kubeadm.k8s.io/v1beta3"
kind: InitConfiguration
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failSwapOn: false
featureGates:
  NodeSwap: true
memorySwap:
  swapBehavior: LimitedSwap

接下来使用 kubeadm init --config kubeadm-config.yaml 创建单节点集群。 在初始化过程中,如果 kubelet failSwapOn 设置为 true,则会出现一条警告,告知节点上启用了交换内存特性。我们计划在未来的版本中删除此警告。

如何通过 LimitedSwap 确定交换内存限额?

交换内存的配置(包括其局限性)是一项挑战。不仅容易出现配置错误,而且作为系统级属性, 任何错误配置都可能危及整个节点而不仅仅是特定的工作负载。为了减轻这种风险并确保节点的健康,我们在交换内存的 Beta 版本中实现了对缺陷的自动配置。

使用 LimitedSwap,不属于 Burstable QoS 类别的 Pod(即 BestEffort/Guaranteed QoS Pod)被禁止使用交换内存。 BestEffort QoS Pod 表现出不可预测的内存消耗模式,并且缺乏有关其内存使用情况的信息, 因此很难完成交换内存的安全分配。相反,Guaranteed QoS Pod 通常用于根据工作负载的设置精确分配资源的应用, 其中的内存资源立即可用。为了维持上述安全和节点健康保证,当 LimitedSwap 生效时,这些 Pod 将不允许使用交换内存。

在详细计算交换内存限制之前,有必要定义以下术语:

  • • nodeTotalMemory:节点上可用的物理内存总量。

  • • totalPodsSwapAvailable:节点上可供 Pod 使用的交换内存总量(可以保留一些交换内存供系统使用)。

  • • containerMemoryRequest:容器的内存请求。

交换内存限制配置为:(containerMemoryRequest / nodeTotalMemory) × totalPodsSwapAvailable

换句话说,容器能够使用的交换内存量与其内存请求、节点的总物理内存以及节点上可供 Pod 使用的交换内存总量呈比例关系。

值得注意的是,对于 Burstable QoS Pod 中的容器,可以通过设置内存限制与内存请求相同来选择不使用交换内存。以这种方式配置的容器将无法访问交换内存。

此特性如何工作?

我们可以想象可以在节点上使用交换内存的多种可能方式。当节点上提供了交换内存并可用时, SIG 节点建议[6] kubelet 应该能够遵循如下的配置:

  • • 在交换内存特性被启用时能够启动。

  • • 默认情况下,kubelet 将指示容器运行时接口(CRI)不为 Kubernetes 工作负载分配交换内存。

节点上的交换内存配置通过 KubeletConfiguration 中的 memorySwap[7] 向集群管理员公开。作为集群管理员,你可以通过设置 memorySwap.swapBehavior 来指定存在交换内存时节点的行为。

kubelet使用 CRI(容器运行时接口)[8] API 来指示 CRI 配置特定的 cgroup v2 参数(例如 memory.swap.max), 配置方式要支持容器所期望的交换内存配置。接下来,CRI 负责将这些设置写入容器级的 cgroup。

如何对交换内存进行监控?

期待已久:K8S终于迎来交换内存Beta支持!,公众号#云原生百宝箱,kubernetes,java,容器,云原生

Alpha 版本的一个显著缺陷是无法监控或检视交换内存的使用情况。这个问题已在 Kubernetes 1.28 引入的 Beta 版本中得到解决,该版本现在提供了通过多种不同方法监控交换内存使用情况的能力。

kubelet 的 Beta 版本现在支持收集节点级指标统计信息[9], 可以通过 /metrics/resource 和 /stats/summary kubelet HTTP 端点进行访问。这些信息使得客户端能够在使用 LimitedSwap 时直接访问 kubelet 来监控交换内存使用情况和剩余交换内存情况。此外,cadvisor 中还添加了 machine_swap_bytes 指标,以显示机器上总的物理交换内存容量。

注意事项

在系统上提供可用交换内存会降低可预测性。由于交换内存的性能比常规内存差, 有时差距甚至在多个数量级,因而可能会导致意外的性能下降。此外,交换内存会改变系统在内存压力下的行为。由于启用交换内存允许 Kubernetes 中的工作负载使用更大的内存量,而这一用量是无法预测的, 因此也会增加嘈杂邻居和非预期的装箱配置的风险,因为调度程序无法考虑交换内存使用情况。

期待已久:K8S终于迎来交换内存Beta支持!,公众号#云原生百宝箱,kubernetes,java,容器,云原生

启用交换内存的节点的性能取决于底层物理存储。当使用交换内存时,与固态硬盘或 NVMe 等更较快的存储介质相比, 在每秒 I/O 操作数(IOPS)受限的环境(例如具有 I/O 限制的云虚拟机)中,性能会明显变差。

因此,我们不提倡针对有性能约束的工作负载或环境使用交换内存。此外,建议使用 LimitedSwap,因为这可以显著减轻给节点带来的风险。

集群管理员和开发人员应该在生产场景中使用交换内存之前对其节点和应用进行基准测试, 我们需要你的帮助[10]!

安全风险

在没有加密的系统上启用交换内存会带来安全风险,因为 关键信息(例如代表 Kubernetes Secret 的卷)可能会被交换到磁盘[11]。如果未经授权的个人访问磁盘,他们就有可能获得这些机密数据。为了减轻这种风险, Kubernetes 项目强烈建议你对交换内存空间进行加密。但是,处理加密交换内存不是 kubelet 的责任; 相反,它其实是操作系统配置通用问题,应在该级别解决。管理员有责任提供加密交换内存来减轻这种风险。

此外,如前所述,启用 LimitedSwap 模式时,用户可以选择通过设置内存限制与内存请求相同来完全禁止容器使用交换内存。这种设置会阻止相应的容器访问交换内存。

展望未来

Kubernetes 1.28 版本引入了对 Linux 节点上交换内存的 Beta 支持, 我们将继续为交换内存正式发布[12]而努力。我希望这将包括:

  • • 添加根据 kubelet 在主机上检测到的内容来设置系统预留交换内存量的功能。

  • • 添加对通过 cgroup 在 Pod 级别控制交换内存用量的支持。

    • • 这一点仍在讨论中。

  • • 收集测试用例的反馈。

    • • 我们将考虑引入新的交换内存配置模式,例如在节点层面为工作负载设置交换内存限制。

如进一步学习?

你可以查看当前交换内存文档[13]以了解如何在 Kubernetes 中使用交换内存。

如需了解更多信息,以及协助测试和提供反馈,请参阅 交换内存KEP-2400[14] 及其交换内存设计提案[15]。

参考

https://kubernetes.io/blog/2021/08/09/run-nodes-with-swap-alpha/

https://kubernetes.io/blog/2023/08/24/swap-linux-beta/

引用链接

[1] 需要使用交换内存的用例: https://github.com/kubernetes/enhancements/blob/9d127347773ad19894ca488ee04f1cd3af5774fc/keps/sig-node/2400-node-swap/README.md#user-stories
[2] Kubernetes 1.22 版本为交换内存引入了一项 Alpha 支持https://kubernetes.io/blog/2021/08/09/run-nodes-with-swap-alpha/
[3] 交换内存用例: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md#user-stories
[4] BurstableQoS Pod : https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/pod-qos/#burstable
[5] kubeadm 安装指南: https://kubernetes.io/zh-cn/docs/setup/product-environment/tools/kubeadm/create-cluster-kubeadm
[6] SIG 节点建议: https://github.com/kubernetes/enhancements/blob/9d127347773ad19894ca488ee04f1cd3af5774fc/keps/sig-node/2400-node-swap/README.md#proposal
[7] KubeletConfiguration 中的 memorySwaphttps://kubernetes.io/zh-cn/docs/reference/config-api/kubelet-config.v1
[8] CRI(容器运行时接口): https://kubernetes.io/zh-cn/docs/concepts/architecture/cri
[9] 节点级指标统计信息: https://kubernetes.io/zh-cn/docs/reference/instrumentation/node-metrics/
[10] 我们需要你的帮助: https://kubernetes.io/zh-cn/blog/2023/08/24/swap-linux-beta/#how-do-i-get-involved
[11] 关键信息(例如代表 Kubernetes Secret 的卷)可能会被交换到磁盘: https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/#information-security-for-secrets
[12] 交换内存正式发布: https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#feature-stages
[13] 交换内存文档: https://kubernetes.io/zh-cn/docs/concepts/architecture/nodes/#swap-memory
[14] 交换内存KEP-2400: https://github.com/kubernetes/enhancements/issues/4128
[15] 交换内存设计提案: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md


推荐阅读

  • 叮,你收到一份来自CNCF的云原生景观简介

  • 要魔改Kubernetes,我们可以从哪里扩展

  • 问题排查太烦心,试试GPT的超能力

  • Copa:无需重建镜像,直接修补容器漏洞

  • 玩转K8s网络:16张图带你从小白到专家

  • 1000节点集群,5秒搭建好

  • 流量何处来又往何处去,这次一目了然

  • Kubernetes CNI 插件选型和应用场景探讨

  • 块/文件/对象存储难统一管理,试试这个集大成者

  • GPU越来越难买,如何提高利用率

  • 监控外部服务太复杂?ServiceMonitor 和 PrometheusRule有妙招

  • 容器快了,却不安全了,Rootless 安排上文章来源地址https://www.toymoban.com/news/detail-751394.html

到了这里,关于期待已久:K8S终于迎来交换内存Beta支持!的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 排查K8S的WSS内存一致升高

    公司后端服务是java体系,运用k8s进行搭建,服务监控是用Prometheus+Grafana进行监控,发现容器监控层面的WSS会持续增长,而RSS保持不变。故有个疑惑: WSS是什么指标 为什么WSS会持续增长 WSS增长之后到极限值后,怎么处理 VSS:Virtual Set Size 虚拟耗用的内存(包含与其他进程共享

    2024年02月13日
    浏览(33)
  • k8s pod “cpu和内存“ 资源限制

    转载用于收藏学习:原文 为了保证充分利用集群资源,且确保重要容器在运行周期内能够分配到足够的资源稳定运行,因此平台需要具备 Pod的资源限制的能力。 对于一个pod来说,资源最基础的2个的指标就是:CPU和内存。 Kubernetes提供了个采用requests和limits 两种类型参数对资

    2024年02月13日
    浏览(68)
  • kubernetes(k8s)为容器和 Pod 分配内存资源

    展示如何将内存请求(request)和内存限制(limit)分配给一个容器。 我们保障容器拥有它请求数量的内存,但不允许使用超过限制数量的内存。 创建新的命名空间 编辑yaml文件 配置文件的 args 部分提供了容器启动时的参数。 “–vm-bytes”, “150M” 参数告知容器尝试分配 15

    2024年02月15日
    浏览(58)
  • 在Kubernetes(K8s)中,CPU和内存的单位

    在Kubernetes(K8s)中,CPU和内存的单位有一些特定的表示法,它们是: CPU单位 - millicores (m): m 表示 millicores,即千分之一的 CPU 核心。 例如, 100m 表示 0.1 个 CPU 核心,而 500m 表示 0.5 个 CPU 核心。 这种表示法用于将 CPU 资源分配为相对小的单位,使得可以更精确地定义容器对

    2024年01月24日
    浏览(42)
  • K8S 1.27 新特性 Pod 无需重启调整CPU内存资源

    如果您已经部署了指定 CPU 或 Memory 资源的 Kubernetes pod,可能已经注意到更改资源值涉及重新启动 pod。直到现在,这一直是运行工作负载的破坏性操作。 在 Kubernetes v1.27 中,添加了一个新的 alpha 功能,允许用户在不重启容器的情况下调整分配给 Pod 的 CPU 或 memory 资源的大小。

    2024年02月11日
    浏览(37)
  • k8s故障排查个案:当Pod内存持续增长,OOM问题如何解决?

    pod 运行一段时间后,内存持续增长,甚至 oom 的情况. 容器化过程中,我们经常会发现 kubernetes 集群内 pod 的内存使用率会不停持续增长,加多少内存吃多少内存,如果对 cgroup 内存的构成不是很清楚的情况下,单纯看监控看不出什么问题。 经过一番查阅,目前总结出大致有

    2024年02月22日
    浏览(59)
  • k8s 检测node节点内存使用率平衡调度脚本 —— 筑梦之路

    直接上脚本: 参考资料: 一招完美解决k8s调度不均问题

    2024年01月16日
    浏览(48)
  • 记一次go应用在k8s pod已用内存告警不准确分析

    起因: 自监控应用凌晨告警:Pod 内存使用率大于80%(规格为1c1G)。内存缓慢增长,持续到早上内存使用率停止在81%左右。 疑点: 此模块是一个轻任务模块(基于go开发),请求量很低并且数据量非常少,平常内存占用一直以来都在100MB左右,出现内存不足的概率极小,而且

    2024年01月18日
    浏览(49)
  • K8S 1.27 动态调整容器CPU和内存资源限制,无需重启应用程序

    如果您在部署Pod时指定了 CPU 和内存资源,更改资源大小需要重新启动 Pod。到目前为止,重启对于正在运行工的作负载是一种破坏性操作。 Kubernetes 1.27 中的 alpha 功能发布。其中一项能够自动调整 Pod 的 CPU 和内存限制的大小,只需修补正在运行的 Pod 定义即可更改它们,而无

    2024年02月07日
    浏览(47)
  • 一直在期待的基于 Ubuntu 的滚动发布 Rhino Linux 终于来了

    导读 现在我们就一起来看看 Rhino Linux 有哪些值得特别关注的地方。 Hands of an office woman typing 你可能还记得我们 去年 报道过,Rhino Linux 将会接替现已停止开发的 “Rolling Rhino Remix”。 经过漫长的等待,它的首个稳定版本终于发布了! 现在我们就一起来看看 Rhino Linux 有哪些

    2024年02月11日
    浏览(45)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包