Canonical Kubernetes 1.29 现已正式发布

by Canonical on 30 January 2024

上游 Kubernetes 新版本 1.29 现已正式发布，其中包含重要的新增功能和漏洞修复。Canonical 密切关注上游开发，进行版本协调，以提供及时、最新的增强功能，这意味着 MicroK8s 1.29 也已正式发布，Charmed Kubernetes 1.29 也即将正式发布。

Canonical Kubernetes 1.29 中的新增功能

Canonical 的 Kubernetes 发行版，MicroK8s 和 Charmed Kubernetes，提供了上游 Kubernetes 1.29 中可用的所有功能。我们还增加了许多新功能。有关更改和增强功能的完整列表，请参阅 MicroK8s 和 Charmed Kubernetes 版本说明。

MicroK8s 1.29 的亮点 

大规模 AI/ML 与 NVIDIA 集成

我们在新版 NVIDIA 插件中加入了 GPU 和网络 NVIDIA 运营工具。NVIDIA GPU 运营工具可以自动管理提供 GPU 所需的所有 NVIDIA 软件组件，例如内核驱动程序或 NVIDIA Container Toolkit。Network Operator 与 GPU 运营工具协同工作，并在兼容系统上启用 GPU-Direct RDMA。

欲了解更多信息，请阅读以下博客文章：

• Canonical Kubernetes 通过 NVIDIA 集成增强 AI/ML 开发功能（英）
• 使用 Canonical 和 NVIDIA AI Enterprise 加快 AI 应用程序开发（中）

针对 DQLite 的可用性和性能改进

MicroK8s 团队近期的关注点大多放在提高随 Kubernetes 发行版一起提供的默认数据存储的稳定性和效率上。除此之外，MicroK8s 版本中还有以下更改：

• 在故障域可用性/更改情况下重新分配 DQLite 节点角色
• 可选准入控制，保护数据存储的性能
• 处理磁盘存储不足的情况
• 与 DQlite 和 SQL 查询准备的静态链接相关的性能改进

不断发展的社区和合作伙伴生态系统

我们增添了 Canonical 合作伙伴和社区成员提供的三款新插件：

• Falco：云原生安全工具，对内核事件采用自定义规则来提供实时警报
• CloudNative PG Operator：利用云原生 Postgres、EDB Postgres for Kubernetes 可以提高基础架构现代化的速度、效率和保护
• ngrok：入口控制器，即刻添加连接性、负载平衡、身份验证和可观测性到您的服务

Charmed Kubernetes 1.29 的亮点

Charmed Operator 框架 (Ops)

我们很高兴地宣布，本年度早期开始的 Charmed Kubernetes 重构已经完成。Charms 已从反应式和特异式风格转变为 ops 框架，以便能够访问公共 charm 库，获得更好的 Juju 支持，以及拥有更加一致的社区参与体验。

开箱即用的监控增强功能

Canonical Observability Stack (COS) 对运行在 Juju 内外的工作负载所生成的遥测信号进行收集、处理、可视化和报警。COS 提供一个开箱即用的基于一流开源可观测性工具的可观测性套件。

此版本扩展了我们的 COS 集成，其包含对 Charmed Kubernetes 控制平面和工作节点组件的丰富监测功能。

容器网络增强功能

Kube-OVN 1.12

Charmed Kubernetes 将继续致力于先进的容器网络，并且提供对 Kube-OVN CNI 的支持。此版本包括 Kube-OVN 到 v1.12 的升级。您可以在上游版本说明中找到有关功能和修复的更多信息。

Tigera Calico Enterprise

calico-enterprise charm 在此版本中作为 Charmed Kubernetes 的新增容器网络选项首次亮相。此 charm 提供先进的 Calico 网络/网络策略支持，并作为默认 Calico CNI 的替代方案提供。

组件升级和修复

欲查看 Charmed Kubernetes 1.29 版本的组件升级、功能和漏洞修复的完整列表，请访问 Launchpad 里程碑页面。

上游 Kubernetes 1.29 的重大更改

您可以阅读完整的更改日志，了解 1.29 版本中包含的默认功能、弃用项和漏洞修复。以下是最重要的更改。

Sidecar 容器进入测试阶段并默认启用

这种非常受欢迎的 sidecar 容器 运行模式进入了测试阶段，并将慢慢但必然成为一流的容器。此外，通过显式定义的 sidecar 容器，您可以先于主应用程序或 init 容器启动日志采集 sidecar 容器。您无需担心应用程序启动或 pod 终止时的服务网格可用性—— sidecar 容器已经为您解决了该问题。此功能即将进入测试阶段，从 1.29 版本开始将默认启用。

用于准入控制的通用表达式语言（CEL）的改进

准入验证策略使用通用表达式语言（CEL），通过简单的表达式即可声明 Kubernetes 资源的准入策略（例如，不允许创建没有必要标签的 pod，或者具有特权主机路径挂载的 pod）。它们具有高度可配置性，使策略创建者能够定义可以参数化并根据集群管理员的需要将范围限定在资源的策略。用于准入控制的通用表达式语言 (CEL) 自 1.26 版本开始提供。其默认启用，并且可使用 ValidatingAdmissionPolicy 功能标记启用。

CRI-full 容器和 Pod 状态功能进入测试阶段

对工作负载的监测是在生产环境中运行集群最关键的方面之一。不然您如何了解容器和 pod 资源的使用情况呢？目前，这些信息来自 CRI 和 cAdvisor，这会导致重复的工作，有时还导致参数来源不明确。此增强功能旨在扩展 CRI API 和实现规模，以便它们能够提供实现容器和 pod 适当可观测性所需的所有参数。您可以使用 PodAndContainerStatsFromCRI 标记启用此功能。 

对 pod 中用户名称空间的支持改进

目前，容器进程用户 ID（UID）和分组 ID（GID）在 pod 内部和主机上是相同的。因此，当这样的进程能够脱离 pod 进入主机时，会产生一项特殊的安全挑战——其仍然使用相同的 UID/GID。如有任何其他使用相同 UID/GID 运行的容器，则会有流氓进程对其进行干扰。在最坏的情况下，在 pod 中以 root 身份运行的进程仍然会以 root 身份在主机上运行。此增强功能拟支持用户名称空间，这样可以在用户和分组 ID 不同于主机上的 pod 中运行容器。如想启用用户名称空间支持，其在 K8s 1.29 中仍是测试版本，可使用 UserNamespacesSupport 功能标记启用。

了解关于 Canonical Kubernetes 的更多信息或联系我们的团队

• ubuntu.com/kubernetes
• microk8s.io
• Kubernetes Slack 上的 #canonical-kubernetes 和 #microk8s
• Discourse
• Matrix
• 联系我们获取支持