专栏名称: GoCN
最具规模和生命力的 Go 开发者社区
目录
相关文章推荐
北京厚朴中医  ·  今晚19:00直播 | 筑基开课指北 ·  18 小时前  
北京厚朴中医  ·  厚朴电子日历 | 早 ·  4 天前  
北京厚朴中医  ·  樱花季,在厚朴汤河原学堂来一次身与心的对话 ·  4 天前  
北京厚朴中医  ·  今晚19:00直播 | 肩痛非药物攻略 ·  4 天前  
51好读  ›  专栏  ›  GoCN

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

GoCN  · 公众号  ·  · 2024-04-02 08:00

正文

兴奋不?我们不都是吗?

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

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

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内存。

apiVersion: v1
kind: Pod
metadata:
  name: my-gpu-app
spec:
  containers:
  - name: gpu-container
    resources:
      requests:
        resource.k8s.io/nvidia.com/gpu:
          type: Resource
          minimum: 1
          maximum: 1
        resource.k8s.io/memory:
          type: Resource
          requests:
            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 节点上的交换使用情况。不要忘记在激活交换之前评估您的独特需求并制定适当的监控程序。

kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
# ... other kubelet configurations
featureGates:
  NodeSwap: "true"
memorySwap:
  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)。 通过大幅降低攻击面,这种隔离方法使受感染的容器更难滥用底层主机上的特权。

apiVersion: v1
kind: Pod
metadata:
  name: my-secure-pod
spec:
  securityContext:
    userNamespace: true
  containers:
  - name: my-app
    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 集群的资源分配和扩展策略。

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-deployment
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 80
  containerMetrics:
  - 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 -








请到「今天看啥」查看全文