devbox
你好赵伟
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

探索Kubernetes v1.30：激动人心的新功能和升级！

作者：你好赵伟 | 2024-04-23 08:03:00

赞

踩

探索Kubernetes v1.30：激动人心的新功能和升级！

兴奋不？我们不都是吗？

Kubernetes v1.30 版本带来了一系列令人期待的更新，包括动态资源分配（DRA）的结构化参数和节点交换内存 SWAP 支持的改进。动态资源分配的结构化参数增加了资源管理的透明度和效率，而节点交换内存的改进则提高了系统稳定性。

现在让我们探讨一下将 Kubernetes 1.30 提升到新版本的主要功能。

a53c88697b8105f80fa250d6098019f4.jpeg

Kubernetes v1.30 的主要变化

1. 动态资源分配（DRA）的结构化参数 (KEP-4381[1])

动态资源分配（DRA）[2] 在 Kubernetes v1.26 中作为 alpha 特性添加。

它定义了一种替代传统设备插件 device plugin API 的方式，用于请求访问第三方资源。在设计上，动态资源分配（DRA）使用的资源参数对于核心 Kubernetes 完全不透明。这种方法对于集群自动缩放器（CA）或任何需要为一组 Pod 做决策的高级控制器（例如作业调度器）都会带来问题。这一设计无法模拟在不同时间分配或释放请求的效果。只有第三方 DRA 驱动程序才拥有信息来做到这一点。

动态资源分配（DRA）的结构化参数是对原始实现的扩展，它通过构建一个框架来支持增加请求参数的透明度来解决这个问题。 驱动程序不再需要自己处理所有请求参数的语义，而是可以使用 Kubernetes 预定义的特定“结构化模型”来管理和描述资源。这一设计允许了解这个“结构化规范”的组件做出关于这些资源的决策，而不再将它们外包给某些第三方控制器。例如，调度器可以在不与动态资源分配（DRA）驱动程序反复通信的前提下快速完成分配请求。这个版本的工作重点是定义一个框架来支持不同的“结构化模型”，并实现“命名资源”模型。此模型允许列出各个资源实例，同时，与传统的设备插件 API 相比，模型增加了通过属性逐一选择实例的能力。

示例：动态资源分配

结构化参数增加了 Pod 资源分配的灵活性。通过更精确地定义资源请求和限制，开发人员可以优化可用资源的使用。

在这种情况下，Pod 对一个 GPU 资源发出最小和最大请求（nvidia.com/gpu ）。它还使用标准内存资源定义来请求8GB内存。

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: my-gpu-app
  5. spec:
  6.   containers:
  7.   - name: gpu-container
  8.     resources:
  9.       requests:
  10.         resource.k8s.io/nvidia.com/gpu:
  11.           type: Resource
  12.           minimum: 1
  13.           maximum: 1
  14.         resource.k8s.io/memory:
  15.           type: Resource
  16.           requests:
  17.             memory: "8Gi"

Kubernetes 1.30 中的 DRA 以其结构化参数打开了通向更加动态和有效的资源管理环境的大门。随着该功能的发展，我们应该预期会有更广泛的受众，以及满足各种应用程序需求的充满活力的第三方资源驱动程序生态系统的出现。

2. 节点交换内存 SWAP 支持 (KEP-2400[3])

在 Kubernetes v1.30 中，Linux 节点上的交换内存支持机制有了重大改进，其重点是提高系统的稳定性。 以前的 Kubernetes 版本默认情况下禁用了 NodeSwap 特性门控。当门控被启用时，UnlimitedSwap 行为被作为默认行为。为了提高稳定性，UnlimitedSwap 行为（可能会影响节点的稳定性）将在 v1.30 中被移除。

更新后的 Linux 节点上的交换内存支持仍然是 beta 级别，并且默认情况下开启。 然而，节点默认行为是使用 NoSwap（而不是 UnlimitedSwap）模式。在 NoSwap 模式下，kubelet 支持在启用了磁盘交换空间的节点上运行，但 Pod 不会使用页面文件（pagefile）。你仍然需要为 kubelet 设置 --fail-swap-on=false 才能让 kubelet 在该节点上运行。 特性的另一个重大变化是针对另一种模式：LimitedSwap。在 LimitedSwap 模式下，kubelet 会实际使用节点上的页面文件，并允许 Pod 的一些虚拟内存被换页出去。 容器（及其父 Pod）访问交换内存空间不可超出其内存限制，但系统的确可以使用可用的交换空间。

Kubernetes 的 SIG Node 小组还将根据最终用户、贡献者和更广泛的 Kubernetes 社区的反馈更新文档， 以帮助你了解如何使用经过修订的实现。

阅读之前的Kubernetes 1.28：在 Linux 上使用交换内存的 Beta 支持[4]或交换内存管理文档[5]以获取有关 Kubernetes 中 Linux 节点交换支持的更多详细信息。

示例：节点内存交换

Kubernetes 1.30 现在支持节点内存交换。通过允许内核使用节点上的交换空间进行内存管理，这可以在施加内存压力时增强系统稳定性。

在 Kubernetes 1.30 中，节点内存交换功能经过重新设计，优先考虑稳定性，同时提供更多控制。通过引入 LimitedSwap 代替 UnlimitedSwap，Kubernetes 提供了一种更加可控和可预测的方法来处理 Linux 节点上的交换使用情况。不要忘记在激活交换之前评估您的独特需求并制定适当的监控程序。

  1. kind: KubeletConfiguration
  2. apiVersion: kubelet.config.k8s.io/v1beta1
  3. # ... other kubelet configurations
  4. featureGates:
  5.   NodeSwap: "true"
  6. memorySwap:
  7.   swapBehavior: LimitedSwap

3. 支持 Pod 运行在用户命名空间 (KEP-127[6])

用户命名空间[7] 是一个仅在 Linux 上可用的特性，它更好地隔离 Pod， 以防止或减轻几个高/严重级别的 CVE，包括 2024 年 1 月发布的 CVE-2024-21626[8]。在 Kubernetes 1.30 中，对用户命名空间的支持正在迁移到 beta，并且现在支持带有和不带有卷的 Pod，自定义 UID/GID 范围等等！

示例：用户命名空间可实现更好的 Pod 隔离 [Beta版本]

这一突破性的功能使 Pod 内的用户能够对其身份进行细粒度的控制；它将在 1.30 升级到Beta版本。它允许将主机系统上的各种值映射到 Pod 内使用的 UID（用户 ID）和 GID（组 ID）。通过大幅降低攻击面，这种隔离方法使受感染的容器更难滥用底层主机上的特权。

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: my-secure-pod
  5. spec:
  6.   securityContext:
  7.     userNamespace: true
  8.   containers:
  9.   - name: my-app
  10.     image: my-secure-image:latest

4. 结构化鉴权配置(KEP-3221[9])

对结构化鉴权配置[10]的支持正在晋级到 Beta 版本，并将默认启用。 这个特性支持创建具有明确参数定义的多个 Webhook 所构成的鉴权链；这些 Webhook 按特定顺序验证请求， 并允许进行细粒度的控制，例如在失败时明确拒绝。配置文件方法甚至允许你指定 CEL[11] 规则，以在将请求分派到 Webhook 之前对其进行预过滤，帮助你防止不必要的调用。当配置文件被修改时，API 服务器还会自动重新加载鉴权链。

你必须使用 --authorization-config 命令行参数指定鉴权配置的路径。如果你想继续使用命令行标志而不是配置文件，命令行方式没有变化。要访问新的 Webhook 功能，例如多 Webhook 支持、失败策略和预过滤规则，需要切换到将选项放在 --authorization-config 文件中。从 Kubernetes 1.30 开始，配置文件格式约定是 beta 级别的，只需要指定 --authorization-config，因为特性门控默认启用。 鉴权文档[12] 中提供了一个包含所有可能值的示例配置。有关更多详细信息，请阅读鉴权文档[13]。

5. 基于容器资源指标的 Pod 自动扩缩容 (KEP-1610[14])

基于 ContainerResource 指标的 Pod 水平自动扩缩容将在 v1.30 中升级为稳定版。 HorizontalPodAutoscaler 的这一新行为允许你根据各个容器的资源使用情况而不是 Pod 的聚合资源使用情况来配置自动伸缩。 有关更多详细信息，请参阅我们的Kubernetes 1.27：HorizontalPodAutoscaler ContainerResource 类型指标进阶至 Beta[15]， 或阅读容器资源指标[16]。

示例：基于容器资源的 Pod 自动伸缩

通过使用此功能，可以启用基于容器内存或 CPU 指标的水平 Pod 自动缩放 (HPA)。这使得可以根据容器的实际需求更精确地进行扩展。您可以通过专注于各个容器的指标来充分利用 Kubernetes 集群的资源分配和扩展策略。

  1. apiVersion: autoscaling/v2beta2
  2. kind: HorizontalPodAutoscaler
  3. metadata:
  4.   name: my-hpa
  5. spec:
  6.   scaleTargetRef:
  7.     apiVersion: apps/v1
  8.     kind: Deployment
  9.     name: my-deployment
  10.   minReplicas: 2
  11.   maxReplicas: 5
  12.   metrics:
  13.   - type: Resource
  14.     resource:
  15.       name: cpu
  16.       target:
  17.         type: Utilization
  18.         averageUtilization: 80
  19.   containerMetrics:
  20.   - name: web-container # Target container within the Pod

在部署过程中，HPA 会密切关注每个 Pod 使用的 CPU 资源量。HPA 将扩展部署，以在 Web 容器的所有实例中保持平均 CPU 使用率 80%，因为平均利用率设置为 80。指定要监视 CPU 指标的容器名称 (web-container)在容器指标部分。

6. 在准入控制中使用 CEL (KEP-3488[17])

Kubernetes 为准入控制集成了 Common Expression Language (CEL) 。这一集成引入了一种更动态、表达能力更强的方式来判定准入请求。这个特性允许通过 Kubernetes API 直接定义和执行复杂的、细粒度的策略，同时增强了安全性和治理能力，而不会影响性能或灵活性。

将 CEL 引入到 Kubernetes 的准入控制后，集群管理员就具有了制定复杂规则的能力， 这些规则可以根据集群的期望状态和策略来评估 API 请求的内容，而无需使用基于 Webhook 的访问控制器。 这种控制水平对于维护集群操作的完整性、安全性和效率至关重要，使 Kubernetes 环境更加健壮，更适应各种用例和需求。有关使用 CEL 进行准入控制的更多信息，请参阅 验证准入策略（ValidatingAdmissionPolicy）[18]中的 ValidatingAdmissionPolicy。

我们希望你和我们一样对这个版本的发布感到兴奋。请在未来几周内密切关注官方发布博客，以了解其他亮点！

引用链接

[1] KEP-4381: https://kep.k8s.io/4381
[2] 动态资源分配（DRA）: https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation/
[3] KEP-2400: https://kep.k8s.io/2400
[4] Kubernetes 1.28：在 Linux 上使用交换内存的 Beta 支持: https://kubernetes.io/zh-cn/blog/2023/08/24/swap-linux-beta/
[5] 交换内存管理文档: https://kubernetes.io/zh-cn/docs/concepts/architecture/nodes/#swap-memory
[6] KEP-127: https://kep.k8s.io/127
[7] 用户命名空间: https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/user-namespaces
[8] CVE-2024-21626: https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv
[9] KEP-3221: https://kep.k8s.io/3221
[10] 结构化鉴权配置: https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/authorization/#configuring-the-api-server-using-an-authorization-config-file
[11] CEL: https://kubernetes.io/zh-cn/docs/reference/using-api/cel/
[12] 鉴权文档: https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/authorization/#configuring-the-api-server-using-an-authorization-config-file
[13] 鉴权文档: https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/authorization/#configuring-the-api-server-using-an-authorization-config-file
[14] KEP-1610: https://kep.k8s.io/1610
[15] Kubernetes 1.27：HorizontalPodAutoscaler ContainerResource 类型指标进阶至 Beta: https://kubernetes.io/zh-cn/blog/2023/05/02/hpa-container-resource-metric/
[16] 容器资源指标: https://kubernetes.io/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/#container-resource-metrics
[17] KEP-3488: https://kep.k8s.io/3488
[18] 验证准入策略（ValidatingAdmissionPolicy）: https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/validating-admission-policy

- END -

推荐阅读:

2024 Gopher Meetup 武汉站活动

go 中更加强大的 traces

2024年的Rust与Go

「GoCN酷Go推荐」我用go写了魔兽世界登录器?

Go区不大，创造神话，科目三杀进来了

Go 1.22新特性前瞻

想要了解Go更多内容，欢迎扫描下方

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/你好赵伟/article/detail/472906
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。