Kubernetes Blog

Kubernetes v1.33 预览

Wed, 26 Mar 2025 10:30:00 -0800

随着 Kubernetes v1.33 版本的发布临近，Kubernetes 项目仍在不断发展。为了提升项目的整体健康状况，某些特性可能会被弃用、移除或替换。这篇博客文章概述了 v1.33 版本的一些计划变更，发布团队认为你有必要了解这些内容，以确保 Kubernetes 环境的持续平稳运行，并让你掌握最新的发展动态。以下信息基于 v1.33 版本的当前状态，在最终发布日期之前可能会有所变化。

Kubernetes API 的移除与弃用流程

Kubernetes 项目针对特性的弃用有一套完善的弃用政策。该政策规定，只有在有更新的、稳定的同名 API 可用时，才能弃用稳定的 API，并且每个稳定性级别的 API 都有最低的生命周期要求。被弃用的 API 已被标记为将在未来的 Kubernetes 版本中移除。在移除之前（自弃用起至少一年内），它仍然可以继续使用，但使用时会显示警告信息。已被移除的 API 在当前版本中不再可用，届时你必须迁移到使用替代方案。

一般可用（GA）或稳定 API 版本可以被标记为已弃用，但在 Kubernetes 的一个主要版本内不得移除。
测试版或预发布 API 版本在弃用后必须支持至少三个发行版本。
Alpha 或实验性 API 版本可以在任何版本中被移除，且无需事先发出弃用通知；如果同一特性已经有了不同的实现，这个过程可能会变为撤回。

无论是由于某个特性从测试阶段升级为稳定阶段而导致 API 被移除，还是因为该 API 未能成功，所有的移除操作都遵循此弃用政策。每当一个 API 被移除时，迁移选项都会在弃用指南中进行说明。

Kubernetes v1.33 的弃用与移除

稳定版 Endpoints API 的弃用

EndpointSlices API 自 v1.21 起已稳定，实际上取代了原有的 Endpoints API。虽然原有的 Endpoints API 简单直接，但在扩展到大量网络端点时也带来了一些挑战。EndpointSlices API 引入了诸如双栈网络等新特性，使得原有的 Endpoints API 已准备好被弃用。

此弃用仅影响那些直接在工作负载或脚本中使用 Endpoints API 的用户；这些用户应迁移到使用 EndpointSlices。未来几周内将发布一篇专门的博客文章，详细介绍弃用的影响和迁移计划。

你可以在 KEP-4974: Deprecate v1.Endpoints 中找到更多信息。

节点状态中 kube-proxy 版本信息的移除

继在 v1.31 中被弃用，并在发布说明中强调后， status.nodeInfo.kubeProxyVersion 字段将在 v1.33 中被移除。此字段由 kubelet 设置，但其值并不总是准确的。由于自 v1.31 起该字段默认已被禁用，v1.33 发行版将完全移除此字段。

你可以在 KEP-4004: Deprecate status.nodeInfo.kubeProxyVersion field 中找到更多信息。

移除对 Windows Pod 的主机网络支持

Windows Pod 网络旨在通过允许容器使用节点的网络命名空间来实现与 Linux 的特性对等，并提供更高的集群密度。最初的实现作为 Alpha 版本在 v1.26 中引入，但由于遇到了未预期的 containerd 行为，且存在替代方案，Kubernetes 项目决定撤回相关的 KEP。我们预计在 v1.33 中完全移除对该特性的支持。

你可以在 KEP-3503: Host network support for Windows pods 中找到更多信息。

Kubernetes v1.33 的特色改进

作为本文的作者，我们挑选了一项改进作为最重要的变更来特别提及！

Linux Pods 中用户命名空间的支持

当前最古老的开放 KEP 之一是 KEP-127，通过使用 Linux 用户命名空间为 Pod 提供安全性改进。该 KEP 最初在 2016 年末提出，经过多次迭代，在 v1.25 中发布了 Alpha 版本，在 v1.30 中首次进入 Beta 阶段（在此版本中默认禁用），现在它将成为 v1.33 的一部分，默认情况下即可使用该特性。

除非你手动指定 pod.spec.hostUsers 以选择使用此特性，否则此支持不会影响现有的 Pod。正如在 v1.30 预览博客中强调的那样，就缓解漏洞的影响而言，这是一个重要里程碑。

你可以在 KEP-127: Support User Namespaces in pods 中找到更多信息。

精选的其他 Kubernetes v1.33 改进

以下列出的改进很可能会包含在即将到来的 v1.33 发行版中。这些改进尚无法承诺，发行内容仍有可能发生变化。

Pod 垂直扩展的就地资源调整

在制备某个 Pod 时，你可以使用诸如 Deployment、StatefulSet 等多种资源。为了满足可扩缩性需求，可能需要通过更新 Pod 副本数量进行水平扩缩，或通过更新分配给 Pod 容器的资源进行垂直扩缩。在此增强特性之前，Pod 的 spec 中定义的容器资源是不可变的，更新 Pod 模板中的这类细节会触发 Pod 的替换。

但是如果可以在不重启的情况下动态更新现有 Pod 的资源配置，那会怎样呢？

KEP-1287 正是为了实现这种就地 Pod 更新而设计的。它为无状态进程的垂直扩缩开辟了多种可能性，例如在不停机的情况下进行扩容、在流量较低时无缝缩容，甚至在启动时分配更多资源，待初始设置完成后减少资源分配。该特性在 v1.27 中以 Alpha 版本发布，并预计在 v1.33 中进入 beta 阶段。

你可以在 KEP-1287：Pod 资源的就地更新中找到更多信息。

DRA 的 ResourceClaim 设备状态升级为 Beta

在 v1.32 版本中首次引入的 ResourceClaim status 中的 devices 字段，预计将在 v1.33 中升级为 beta 阶段。此字段允许驱动程序报告设备状态数据，从而提升可观测性和故障排查能力。

例如，在 ResourceClaim 的状态中报告网络接口的接口名称、MAC 地址和 IP 地址，可以显著帮助配置和管理网络服务，并且在调试网络相关问题时也非常有用。你可以在动态资源分配：ResourceClaim 设备状态文档中阅读关于 ResourceClaim 设备状态的更多信息。

此外，你可以在 KEP-4817: DRA: Resource Claim Status with possible standardized network interface data 中找到更多关于此计划增强特性的信息。

有序的命名空间删除

此 KEP 为 Kubernetes 命名空间引入了一种更为结构化的删除流程，以确保更为安全且更为确定的资源移除。当前半随机的删除顺序可能会导致安全漏洞或意外行为，例如在相关的 NetworkPolicy 被删除后，Pod 仍然存在。通过强制执行尊重逻辑和安全依赖关系的结构化删除顺序，此方法确保在删除其他资源之前先删除 Pod。这种设计通过减少与非确定性删除相关的风险，提升了 Kubernetes 的安全性和可靠性。

你可以在 KEP-5080: Ordered namespace deletion 中找到更多信息。

针对带索引作业（Indexed Job）管理的增强

这两个 KEP 都计划升级为 GA，以提供更好的作业处理可靠性，特别是针对索引作业。 KEP-3850 为索引作业中的不同索引分别支持独立的回退限制，这使得每个索引可以完全独立于其他索引。此外，KEP-3998 扩展了 Job API，定义了在并非所有索引都成功的情况下将索引作业标记为成功完成的条件。

你可以在 KEP-3850: Backoff Limit Per Index For Indexed Jobs 和 KEP-3998: Job success/completion policy 中找到更多信息。

想了解更多？

新特性和弃用也会在 Kubernetes 发行说明中宣布。我们将在该版本的 CHANGELOG 中正式宣布 Kubernetes v1.33 的新内容。

Kubernetes v1.33 版本计划于 2025年4月23日星期三发布。请持续关注以获取更新！

你也可以在以下版本的发行说明中查看变更公告：

参与进来

参与 Kubernetes 最简单的方式是加入与你兴趣相符的众多特别兴趣小组（SIG）之一。你有什么想向 Kubernetes 社区广播的内容吗？通过我们每周的社区会议和以下渠道分享你的声音。感谢你持续的反馈和支持。

在 Bluesky 上关注我们 @kubernetes.io 以获取最新更新
在 Discuss 上参与社区讨论
在 Slack 上加入社区
在 Server Fault 或 Stack Overflow 上提问（或回答问题）
分享你的 Kubernetes 故事
在博客上阅读更多关于 Kubernetes 最新动态的内容
了解更多关于 Kubernetes 发布团队的信息

ingress-nginx CVE-2025-1974 须知

Mon, 24 Mar 2025 12:00:00 -0800

今天，ingress-nginx 项目的维护者们发布了一批关键漏洞的修复补丁，这些漏洞可能让攻击者轻易接管你的 Kubernetes 集群。目前有 40% 以上的 Kubernetes 管理员正在使用 ingress-nginx，如果你是其中之一，请立即采取行动，保护你的用户和数据。

背景

Ingress 是 Kubernetes 提供的一种传统特性，可以将你的工作负载 Pod 暴露给外部世界，方便外部用户使用。 Kubernetes 用户可以用与实现无关的方式来定义应用如何在网络上可用。 Ingress 控制器会根据定义，配置所需的本地资源或云端资源，以满足用户的特定场景和需求。

为了满足不同云厂商用户或负载均衡器产品的需求，目前有许多不同类型的 Ingress 控制器。 ingress-nginx 是 Kubernetes 项目提供的纯软件的 Ingress 控制器。 ingress-nginx 由于灵活易用，非常受用户欢迎。它已经被部署在超过 40% 的 Kubernetes 集群中！

ingress-nginx 会将 Ingress 对象中的要求转换为 Nginx（一个强大的开源 Web 服务器守护进程）的配置。 Nginx 使用这些配置接受请求并将其路由到 Kubernetes 集群中运行的不同应用。正确处理这些 Nginx 配置参数至关重要，因为 ingress-nginx 既要给予用户足够的灵活性，又要防止用户无意或有意诱使 Nginx 执行其不应执行的操作。

今日修复的漏洞

今天修复的四个 ingress-nginx 漏洞都是对 ingress-nginx 如何处理特定 Nginx 配置细节的改进。如果不打这些修复补丁，一个精心构造的 Ingress 资源对象就可以让 Nginx 出现异常行为，包括泄露 ingress-nginx 可访问的 Secret 的值。默认情况下，ingress-nginx 可以访问集群范围内的所有 Secret，因此这往往会导致任一有权限创建 Ingress 的用户或实体接管整个集群。

本次最严重的漏洞是 CVE-2025-1974， CVSS 评分高达 9.8，它允许 Pod 网络中的任意实体通过 ingress-nginx 的验证性准入控制器特性滥用配置注入漏洞。这种机制使得这些漏洞会产生更危险的情形：攻击者通常需要能够在集群中创建 Ingress 对象（这是一种较高权限的操作）。当结合使用今天修复的其他漏洞（比如 CVE-2025-1974）， 就意味着 Pod 网络中的任何实体都有极大可能接管你的 Kubernetes 集群，而不需要任何凭证或管理权限。在许多常见场景下，Pod 网络可以访问云端 VPC 中的所有工作负载，甚至能访问连接到你公司内网的任何人的机器！这是一个非常严重的安全风险。

我们今天已经发布了 ingress-nginx v1.12.1 和 v1.11.5，这两个版本修复了所有这 5 个漏洞。

你需要做什么

首先，确定你的集群是否在使用 ingress-nginx。大多数情况下，你可以使用集群管理员权限运行以下命令进行检查：

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

如果你在使用 ingress-nginx，请立即针对这些漏洞制定补救计划。

最简单且推荐的补救方案是立即升级到最新补丁版本。 安装今天的补丁，就能修复所有这 5 个漏洞。

如果你暂时无法升级，可以通过关闭 ingress-nginx 的验证性准入控制器特性来显著降低风险。

如果你使用 Helm 安装了 ingress-nginx
- 重新安装，设置 Helm 参数 controller.admissionWebhooks.enabled=false
如果你是手动安装的
- 删除名为 ingress-nginx-admission 的 ValidatingWebhookConfiguration
- 编辑 ingress-nginx-controller Deployment 或 DaemonSet，从控制器容器的参数列表中移除 --validating-webhook

如果你为了缓解 CVE-2025-1974 造成的风险而关闭了验证性准入控制器特性，请在升级完成后记得重新开启此特性。这个特性可以为你的用户提供重要的生命期帮助，可以在错误的 Ingress 配置在生效之前及时提醒用户。

总结、致谢与更多参考

今天公布的包括 CVE-2025-1974 在内的 ingress-nginx 漏洞对许多 Kubernetes 用户及其数据构成了严重风险。如果你正在使用 ingress-nginx，请立即采取行动确保自身安全。

我们要感谢来自 Wiz 的 Nir Ohfeld、Sagi Tzadik、Ronen Shustin 和 Hillai Ben-Sasson，他们负责任地披露了这些漏洞，并与 Kubernetes 安全响应委员会成员以及 ingress-nginx 维护者（Marco Ebert 和 James Strong）协同合作，确保这些漏洞被有效修复。

有关 ingress-nginx 的维护和未来的更多信息，请参阅这个 GitHub Issue，或参与 James 和 Marco 在 KubeCon/CloudNativeCon EU 2025 的演讲。

关于本文中提到的具体漏洞的信息，请参阅以下 GitHub Issue：

聚焦 SIG Apps

Wed, 12 Mar 2025 00:00:00 +0000

在我们正在进行的 SIG 聚焦系列中，我们通过与 Kubernetes 项目各个特别兴趣小组（SIG）的领导者对话，深入探讨 Kubernetes 项目的核心。这一次，我们聚焦于 SIG Apps，这个小组负责 Kubernetes 上与应用程序开发、部署和操作相关的所有内容。 Sandipan Panda（[DevZero](https://www.devzero.io/））有机会采访了 SIG Apps 的主席和技术负责人 Maciej Szulik（Defense Unicorns）以及 Janet Kuo（Google）。他们分享了在 Kubernetes 生态系统中关于应用管理的经验、挑战以及未来愿景。

自我介绍

Sandipan：你好，能否先简单介绍一下你自己、你的角色，以及你在 Kubernetes 社区中的经历，这些经历是如何引导你担任 SIG Apps 的当前角色的？

Maciej：嗨，我叫 Maciej，是 SIG Apps 的负责人之一。除了这个角色，你还可以看到我在协助 SIG CLI 的工作，同时我也是指导委员会的成员之一。自 2014 年底以来，我一直为 Kubernetes 做出贡献，涉及的领域包括控制器、API 服务器以及 kubectl。

Janet：当然可以！我是 Janet，在 Google 担任资深软件工程师，并且从 Kubernetes 项目早期（甚至在 2015 年 1.0 版本发布之前）就深度参与其中。这是一段非常精彩的旅程！

我在 Kubernetes 社区中的当前角色是 SIG Apps 的主席之一和技术负责人之一。我与 SIG Apps 的结缘始于自然而然的过程。最初，我从构建 Deployment API 并添加滚动更新功能开始，逐渐对 SIG Apps 产生了浓厚的兴趣，并且参与度越来越高。随着时间推移，我承担了更多的责任，最终走到了目前的领导岗位。

关于 SIG Apps

以下所有回答均由 Maciej 和 Janet 共同提供。

Sandipan：对于那些不熟悉的人，能否简要介绍一下 SIG Apps 的使命和目标？它在 Kubernetes 生态系统中旨在解决哪些关键问题？

正如我们在章程中所描述的那样，我们涵盖了与在 Kubernetes 上开发、部署和操作应用程序相关的广泛领域。简而言之，这意味着我们欢迎每个人参加我们的双周会议，讨论在 Kubernetes 上编写和部署各种应用程序的经验和挑战。

Sandipan：SIG Apps 目前正在进行的一些最重要项目或倡议有哪些？

在当前阶段，推动我们控制器开发的主要因素是运行各种 AI 相关工作负载所带来的挑战。在此值得一提的是，过去几年我们支持的两个工作组：

Batch 工作组，该工作组致力于在 Kubernetes 上运行 HPC、AI/ML 和数据分析作业。
Serving 工作组，该工作组专注于硬件加速的 AI/ML 推理。

最佳实践与挑战

Sandipan：SIG Apps 在为 Kubernetes 开发应用程序管理最佳实践方面发挥着关键作用。你能分享一些这些最佳实践吗？以及它们如何帮助改进应用程序生命周期管理？

实施健康检查和就绪探针确保你的应用程序处于健康状态并准备好处理流量，从而提高可靠性和正常运行时间。结合全面的日志记录、监控和跟踪解决方案，上述措施将为您提供应用程序行为的洞察，使你能够快速识别并解决问题。

根据资源利用率或自定义指标自动扩缩你的应用，优化资源使用并确保您的应用程序能够处理不同的负载。

对于无状态应用程序使用 Deployment，对于有状态应用程序使用 StatefulSet，对于批处理工作负载使用 Job 和 CronJob，在每个节点上运行守护进程时使用 DaemonSet。使用 Operator 和 CRD 扩展 Kubernetes API 以自动化复杂应用程序的部署、管理和生命周期，使其更易于操作并减少手动干预。

Sandipan：SIG Apps 面临的一些常见挑战是什么？你们是如何解决这些问题的？

我们一直面临的最大挑战是需要拒绝许多功能、想法和改进。这需要大量的纪律性和耐心，以便能够解释做出这些决定背后的原因。

Sandipan：Kubernetes 的演进如何影响了 SIG Apps 的工作？ Kubernetes 最近是否有任何变化或即将推出的功能，你认为对 SIG Apps 特别相关或有益？

对我们以及围绕 SIG Apps 的整个社区而言，最大的好处是能够通过自定义资源定义（Custom Resource Definitions）扩展 Kubernetes。用户可以利用内置控制器构建自己的自定义控制器，以实现他们可能面对的各种复杂用例，而我们作为核心维护者，可能没有考虑过这些用例，或者无法在 Kubernetes 内部高效解决。

贡献于 SIG Apps

Sandipan：对于想要参与 SIG Apps 的新贡献者，有哪些机会？你会给他们什么建议？

我们经常被问道：“你们建议我们从哪个好的初始问题开始？” :-) 但遗憾的是，这个问题没有简单的答案。我们总是告诉大家，为核心控制器做贡献的最佳方式是找到一个你愿意花时间研究的控制器。阅读代码，然后尝试运行针对该控制器的单元测试和集成测试。一旦你掌握了大致的概念，试着破坏它并再次运行测试以验证你的改动。当你开始有信心理解了这个特定的控制器后，你可以搜索影响该控制器的待处理问题，提供一些建议，解释用户遇到的问题，或者尝试提交你的第一个修复。

正如我们所说，在这条道路上没有捷径可走；你需要花时间研究代码库，以理解我们逐步积累的所有边缘情况，从而达到我们现在的位置。一旦你在一个控制器上取得了成功，你就需要在其他控制器上重复同样的过程。

Sandipan：SIG Apps 如何从社区收集反馈，以及这些反馈是如何整合到你们的工作中的？

我们总是鼓励每个人参加我们的双周会议，并在会上提出他们的问题和解决方案。只要你是在 Kubernetes 上解决一个有趣的问题，并且能够对任何核心控制器提供有价值的反馈，我们都非常乐意听取每个人的意见。

展望未来

Sandipan：展望未来，Kubernetes 中应用程序管理的关键关注领域或即将到来的趋势有哪些是 SIG Apps 感到兴奋的？SIG 是如何适应这些趋势的？

当前的 AI 热潮无疑是主要的驱动因素；如上所述，我们有两个工作组，每个工作组都涵盖了它的一个不同方面。

Sandipan：关于这个 SIG，你们最喜欢的事情有哪些？

毫无疑问，参与我们会议和 Slack 频道的人们是最让我们感到欣慰的。他们不知疲倦地帮助处理问题、拉取请求，并投入大量的时间（很多时候是他们的私人时间）来让 Kubernetes 变得更好！

SIG Apps 是 Kubernetes 社区的重要组成部分，帮助塑造了应用程序如何在大规模下部署和管理的方式。从改进 Kubernetes 的工作负载 API 到推动 AI/ML 应用程序管理的创新，SIG Apps 不断适应以满足现代应用程序开发者和操作人员的需求。无论你是新贡献者还是有经验的开发者，都有机会参与其中并产生影响。

如果你有兴趣了解更多关于 SIG Apps 的信息或为其做出贡献，务必查看他们的 SIG README，并加入他们的双周会议。

kube-proxy 的 NFTables 模式

Fri, 28 Feb 2025 00:00:00 +0000

Kubernetes 1.29 引入了一种新的 Alpha 特性：kube-proxy 的 nftables 模式。目前该模式处于 Beta 阶段，并预计将在 1.33 版本中达到一般可用（GA）状态。新模式解决了 iptables 模式长期存在的性能问题，建议所有运行在较新内核版本系统上的用户尝试使用。出于兼容性原因，即使 nftables 成为 GA 功能，iptables 仍将是默认模式。

为什么选择 nftables？第一部分：数据平面延迟

iptables API 是被设计用于实现简单的防火墙功能，在扩展到支持大型 Kubernetes 集群中的 Service 代理时存在局限性，尤其是在包含数万个 Service 的集群中。

通常，kube-proxy 在 iptables 模式下生成的规则集中的 iptables 规则数量与 Service 数量和总端点数量的总和成正比。特别是，在规则集的顶层，针对数据包可能指向的每个可能的 Service IP（以及端口），都有一条规则用于测试。

# 如果数据包的目标地址是 172.30.0.41:80，则跳转到 KUBE-SVC-XPGD46QRK7WJZT7O 链进行进一步处理
-A KUBE-SERVICES -m comment --comment "namespace1/service1:p80 cluster IP" -m tcp -p tcp -d 172.30.0.41 --dport 80 -j KUBE-SVC-XPGD46QRK7WJZT7O
# 如果数据包的目标地址是 172.30.0.42:443，则...
-A KUBE-SERVICES -m comment --comment "namespace2/service2:p443 cluster IP" -m tcp -p tcp -d 172.30.0.42 --dport 443 -j KUBE-SVC-GNZBNJ2PO5MGZ6GT
# 等等...
-A KUBE-SERVICES -m comment --comment "namespace3/service3:p80 cluster IP" -m tcp -p tcp -d 172.30.0.43 --dport 80 -j KUBE-SVC-X27LE4BHSL4DOUIK

这意味着当数据包到达时，内核检查该数据包与所有 Service 规则所需的时间是 O(n)，其中 n 为 Service 的数量。随着 Service 数量的增加，新连接的第一个数据包的平均延迟和最坏情况下的延迟都会增加（最佳情况、平均情况和最坏情况之间的差异主要取决于某个 Service IP 地址在 KUBE-SERVICES 链中出现的顺序是靠前还是靠后）。

相比之下，使用 nftables，编写此类规则集的常规方法是使用一个单一规则，并通过"判决映射"（verdict map）来完成分发：

table ip kube-proxy {
# service-ips 判决映射指示了对每个匹配数据包应采取的操作。
map service-ips {
type ipv4_addr . inet_proto . inet_service : verdict
comment "ClusterIP、ExternalIP 和 LoadBalancer IP 流量"
elements = { 172.30.0.41 . tcp . 80 : goto service-ULMVA6XW-namespace1/service1/tcp/p80,
172.30.0.42 . tcp . 443 : goto service-42NFTM6N-namespace2/service2/tcp/p443,
172.30.0.43 . tcp . 80 : goto service-4AT6LBPK-namespace3/service3/tcp/p80,
... }
}
# 现在我们只需要一条规则来处理所有与映射中元素匹配的数据包。
# （此规则表示："根据目标 IP 地址、第 4 层协议和目标端口构建一个元组；
# 在 'service-ips' 中查找该元组；如果找到匹配项，则执行与之关联的判定。"）
chain services {
ip daddr . meta l4proto . th dport vmap @service-ips
}
...
}

由于只有一条规则，并且映射查找的时间复杂度大约为 O(1)，因此数据包处理时间几乎与集群规模无关，并且最佳、平均和最坏情况下的表现非常接近：

但请注意图表中 iptables 和 nftables 之间在纵轴上的巨大差异！在包含 5000 和 10,000 个 Service 的集群中，nftables 的 p50（平均）延迟与 iptables 的 p01（接近最佳情况）延迟大致相同。在包含 30,000 个 Service 的集群中，nftables 的 p99（接近最坏情况）延迟比 iptables 的 p01 延迟快了几微秒！以下是两组数据的对比图，但你可能需要仔细观察才能看到 nftables 的结果！

为什么选择 nftables？第二部分：控制平面延迟

虽然在大型集群中数据平面延迟的改进非常显著，但 iptables 模式的 kube-proxy 还存在另一个问题，这往往使得用户无法将集群扩展到较大规模：那就是当 Service 及其端点发生变化时，kube-proxy 更新 iptables 规则所需的时间。

对于 iptables 和 nftables，规则集的整体大小（实际规则加上相关数据）与 Service 及其端点的总数呈 O(n) 关系。原来，iptables 后端在每次更新时都会重写所有规则，当集群中存在数万个 Service 时，这可能导致规则数量增长至数十万条 iptables 规则。从 Kubernetes 1.26 开始，我们开始优化 kube-proxy，使其能够在每次更新时跳过对大多数未更改规则的更新，但由于 iptables-restore API 的限制，仍然需要发送与 Service 数量呈 O(n) 比例的更新（尽管常数因子比以前明显减小）。即使进行了这些优化，有时仍需使用 kube-proxy 的 minSyncPeriod 配置选项，以确保它不会每秒钟都在尝试推送 iptables 更新。

nftables API 支持更为增量化的更新，当以 nftables 模式运行的 kube-proxy 执行更新时，更新的规模仅与自上次同步以来发生变化的 Service 和端点数量呈 O(n) 关系，而与总的 Service 和端点数量无关。此外，由于 nftables API 允许每个使用 nftables 的组件拥有自己的私有表，因此不会像 iptables 那样在组件之间产生全局锁竞争。结果是，kube-proxy 在 nftables 模式下的更新可以比 iptables 模式下高效得多。

（不幸的是，这部分我没有酷炫的图表。）

不选择 nftables 的理由有哪些？

尽管如此，仍有几个原因可能让你目前不希望立即使用 nftables 后端。

首先，该代码仍然相对较新。虽然它拥有大量的单元测试，在我们的 CI 系统中表现正确，并且已经在现实世界中被多个用户使用，但其实际使用量远远不及 iptables 后端，因此我们无法保证它同样稳定且无缺陷。

其次，nftables 模式无法在较旧的 Linux 发行版上工作；目前它需要 5.13 或更高版本的内核。此外，由于早期版本的 nft 命令行工具存在缺陷，不应在运行旧版本（早于 1.0.0） nft 的节点主机文件系统中上以 nftables 模式运行 kube-proxy（否则 kube-proxy 对 nftables 的使用可能会影响系统上其他程序对 nftables 的使用）。

第三，你的集群中可能还存在其他网络组件，例如 Pod 网络或 NetworkPolicy 实现，这些组件可能尚不支持以 nftables 模式运行的 kube-proxy。你应查阅相关组件的文档（或论坛、问题跟踪系统等），以确认它们是否与 nftables 模式存在兼容性问题。（在许多情况下，它们并不会受到影响；只要它们不尝试直接操作或覆盖 kube-proxy 的 iptables 规则，就不在乎 kube-proxy 使用的是 iptables 还是 nftables。）此外，相较于 iptables 模式下，尚未更新的可观测性和监控工具在 nftables 模式下可能会为 kube-proxy 提供更少的数据。

最后，以 nftables 模式运行的 kube-proxy 有意不与以 iptables 模式运行的 kube-proxy 完全兼容。有一些较旧的 kube-proxy 功能，默认行为不如我们期望的那样安全、高效或直观，但我们认为更改默认行为会导致兼容性问题。由于 nftables 模式是可选的，这为我们提供了一个机会，在不影响期望稳定性的用户的情况下修复这些不良默认设置。（特别是，在 nftables 模式下，NodePort 类型的 Service 现在仅在其节点的默认 IP 上可访问，而在 iptables 模式下，它们在所有 IP 上均可访问，包括 127.0.0.1。）kube-proxy 文档提供了更多关于此方面的信息，包括如何通过查看某些指标来判断你是否依赖于任何已更改的特性，以及有哪些配置选项可用于实现更向后兼容的行为。

尝试使用 nftables 模式

准备尝试了吗？在 Kubernetes 1.31 及更高版本中，你只需将 --proxy-mode nftables 参数传递给 kube-proxy（或在 kube-proxy 配置文件中设置 mode: nftables）。

如果你使用 kubeadm 部署集群，kubeadm 文档解释了如何向 kubeadm init 传递 KubeProxyConfiguration。你还可以通过 kind 部署基于 nftables 的集群。

你还可以通过更新 kube-proxy 配置并重启 kube-proxy Pod，将现有集群从 iptables（或 ipvs）模式转换为 nftables 模式。（无需重启节点：在以 nftables 模式重新启动时，kube-proxy 会删除现有的所有 iptables 或 ipvs 规则；同样，如果你之后切换回 iptables 或 ipvs 模式，它将删除现有的所有 nftables 规则。）

未来计划

如上所述，虽然 nftables 现在是的 kube-proxy 的最佳模式，但它还不是默认模式，我们目前还没有更改这一设置的计划。我们将继续长期支持 iptables 模式。

kube-proxy 的 IPVS 模式的未来则不太确定：它相对于 iptables 的主要优势在于速度更快，但 IPVS 的架构和 API 在某些方面对 kube-proxy 来说不够理想（例如，kube-ipvs0 设备需要被分配所有 Service IP 地址），并且 Kubernetes Service 代理的部分语义使用 IPVS 难以实现（特别是某些 Service 根据连接的客户端是本地还是远程，需要有不同的端点）。现在，nftables 模式的性能与 IPVS 模式相同（实际上略胜一筹），而且没有任何缺点：

（理论上，IPVS 模式还具有可以使用其他 IPVS 功能的优势，例如使用替代的"调度器"来平衡端点。但实际上，这并不太有用，因为 kube-proxy 在每个节点上独立运行，每个节点上的 IPVS 调度器无法与其他节点上的代理共享状态，从而无法实现更智能的流量均衡。）

虽然 Kubernetes 项目目前没有立即放弃 IPVS 后端的计划，但从长远来看，IPVS 可能难逃被淘汰的命运。目前使用 IPVS 模式的用户应尝试使用 nftables 模式（如果发现 nftables 模式中缺少某些无法绕过的功能，请提交问题报告）。

进一步了解

"KEP-3866: Add an nftables-based kube-proxy backend" 记录了此新特性的历史。
"How the Tables Have Turned: Kubernetes Says Goodbye to IPTables"，来自 2024 年 KubeCon/CloudNativeCon 北美大会，讨论了将 kube-proxy 和 Calico 从 iptables 迁移到 nftables 的过程。
"From Observability to Performance"，同样来自 2024 年 KubeCon/CloudNativeCon 北美大会。（kube-proxy 延迟数据来源于此；raw data for the charts 也可用。）

云控制器管理器（Cloud Controller Manager）'鸡与蛋'的问题

Fri, 14 Feb 2025 00:00:00 +0000

Kubernetes 1.31
完成了 Kubernetes 历史上最大的迁移，移除了树内云驱动（in-tree cloud provider）。虽然组件迁移已经完成，但这为用户和安装项目（例如 kOps 或 Cluster API）带来了一些额外的复杂性。我们将回顾这些额外的步骤和可能的故障点，并为集群所有者提供改进建议。
此次迁移非常复杂，必须从核心组件中提取部分逻辑，构建四个新的子系统。

云控制器管理器 (KEP-2392)
API 服务器网络代理 (KEP-1281)
kubelet 凭证提供程序插件 (KEP-2133)
存储迁移到使用 CSI (KEP-625)

云控制器管理器是控制平面的一部分。这是一个关键组件，替换了之前存在于 kube-controller-manager 和 kubelet 中的某些特性。

Kubernetes 组件

云控制器管理器最重要的功能之一是节点控制器，它负责节点的初始化。

从下图可以看出，当 kubelet 启动时，它会向 apiserver 注册 Node 对象，并对节点设置污点，以便云控制器管理器可以先处理该节点。初始的 Node 缺少与云提供商相关的信息，例如节点地址和包含云提供商特定信息的标签，如节点、区域和实例类型信息。

鸡和蛋问题时序图

这一新的初始化过程会增加节点就绪的延迟。以前，kubelet 可以在创建节点的同时初始化节点。对于某些 Kubernetes 架构而言，其控制平面其他组件以静态 Pod、独立二进制文件或具有容忍污点功能的、用 hostNetwork DaemonSet/Deployment 部署，由于节点初始化逻辑已移至云控制管理器中，如果不将控制器管理器作为控制平面的一部分，则可能会导致集群引导过程中出现鸡和蛋问题（更多内容见下文）。

依赖问题的示例

如上所述，在引导过程中，云控制器管理器可能无法被调度，因此集群将无法正确初始化。以下几个具体示例说明此问题的可能表现形式及其根本原因。

这些示例假设你使用 Kubernetes 资源（例如 Deployment、DaemonSet 或类似资源）来控制云控制器管理器的生命周期。由于这些方法依赖于 Kubernetes 来调度云控制器管理器，因此必须确保其能够正确调度。

示例：由于未初始化的污点导致云控制器管理器无法调度

如 Kubernetes 文档中所述，当 kubelet 使用命令行标志 --cloud-provider=external 启动时，其对应的 Node 对象将添加一个名为 node.cloudprovider.kubernetes.io/uninitialized 的不可调度污点。由于云控制器管理器负责移除该不可调度污点，这可能会导致由某个 Kubernetes 资源（例如 Deployment 或 DaemonSet）管理的云控制器管理器无法被调度的情况。

如果在控制平面初始化期间云控制器管理器无法被调度，那么生成的 Node 对象将全部带有 node.cloudprovider.kubernetes.io/uninitialized 不可调度污点。这也意味着该污点不会被移除，因为云控制器管理器负责其移除工作。如果不可调度污点未被移除，关键工作负载（例如容器网络接口控制器）将无法被调度，集群将处于不健康状态。

示例：由于未就绪污点导致云控制器管理器无法调度

下一个示例可能出现在容器网络接口（CNI）正在等待来自云控制器管理器（CCM）的 IP 地址信息，而 CCM 未容忍将由 CNI 移除的污点的情况下。

Kubernetes 文档对 node.kubernetes.io/not-ready 污点的描述如下：

"节点控制器通过监控节点的健康状态来检测节点是否已准备好，并据此添加或移除此污点。"

当容器网络尚未在某节点上初始化时，可能导致 Node 资源具有此污点。由于云控制器管理器负责为 Node 资源添加 IP 地址，而容器网络控制器需要这些 IP 地址来正确配置容器网络，因此在某些情况下，节点可能会永久处于未就绪且未初始化的状态。

这种情况的发生原因与第一个示例类似，但在此情况下，node.kubernetes.io/not-ready 污点使用了 NoExecute 效果，从而导致云控制器管理器无法在带有该污点的节点上运行。如果云控制器管理器无法执行，则它将无法初始化节点。这将进一步导致容器网络控制器无法正常运行，节点最终会同时携带 node.cloudprovider.kubernetes.io/uninitialized 和 node.kubernetes.io/not-ready 两个污点，从而使集群处于不健康状态。

我们的建议

运行云控制器管理器并没有唯一的“正确方式”。具体细节将取决于集群管理员和用户的特定需求。在规划你的集群以及云控制器管理器的生命周期时，请考虑以下指导。

对于在同一集群中运行的云控制器管理器，它们所管理的集群也是这一集群，需要特别注意。

使用主机网络模式，而不是 Pod 网络：在大多数情况下，云控制器管理器需要与基础设施相关的 API 服务端点进行通信。将 "hostNetwork" 设置为 true 可确保云控制器使用主机网络而非容器网络，从而拥有与主机操作系统相同的网络访问权限。这还将消除对网络插件的依赖。这可以确保云控制器能够访问基础设施端点（你应该始终检查网络配置是否与基础设施提供商所给的指导相符）。
使用规模可扩缩的资源类型。Deployment 和 DaemonSet 对于控制云控制器的生命周期非常有用。它们支持轻松地运行多个副本以实现冗余，并利用 Kubernetes 调度来确保在集群中的正确放置。当使用这些原语控制云控制器的生命周期并运行多个副本时，请务必启用领导者选举，否则控制器之间可能会发生冲突，导致集群中的节点无法初始化。

将控制器管理器容器定位到控制平面。可能存在一些需要在控制平面之外运行的其他控制器（例如，Azure 的节点管理器控制器），但云控制器管理器本身应部署到控制平面。使用节点选择算符或亲和性配置将云控制器管理器定向调度到控制平面节点，以确保它们运行在受保护的空间中。云控制器管理器在集群中添加和移除节点时至关重要，因为它们构成了 Kubernetes 与物理基础设施之间的桥梁。
1. 值得注意的是，使用反亲和性配置以防止多个云控制器管理器运行在同一主机上也非常有用，这可以确保单个节点故障不会影响云控制器管理器的性能。

确保污点容忍规则允许操作。在云控制器管理器容器的清单中使用污点容忍规则，以确保其能够被调度到正确的节点，并能够在节点初始化时运行。这意味着云控制器应容忍 node.cloudprovider.kubernetes.io/uninitialized 污点，还应容忍与控制平面相关的任何污点（例如，node-role.kubernetes.io/control-plane 或 node-role.kubernetes.io/master）。容忍 node.kubernetes.io/not-ready 污点也可能很有用，以确保即使节点尚未准备好进行健康监控时，云控制器仍能运行。

对于不在其所管理的集群上（例如，在其他集群上的托管控制平面上）运行的云控制器管理器，其规则将更多地受限于运行云控制器管理器的集群环境的依赖项。针对自管集群的运行建议可能不适用，因为冲突类型和网络约束会有所不同。请根据这些场景咨询你的拓扑结构的架构和需求。

示例

这是一个 Kubernetes Deployment 的示例，突显了上述指导原则。需要注意的是，此示例仅用于演示目的，对于生产环境的使用，请参考你的云提供商的文档。

apiVersion: apps/v1
kind: Deployment
metadata:
 labels:
 app.kubernetes.io/name: cloud-controller-manager
 name: cloud-controller-manager
 namespace: kube-system
spec:
 replicas: 2
 selector:
 matchLabels:
 app.kubernetes.io/name: cloud-controller-manager
 strategy:
 type: Recreate
 template:
 metadata:
 labels:
 app.kubernetes.io/name: cloud-controller-manager
 annotations:
 kubernetes.io/description: Cloud controller manager for my infrastructure
 spec:
 containers: # 容器的详细信息将取决于你具体的云控制器管理器
 - name: cloud-controller-manager
 command:
 - /bin/my-infrastructure-cloud-controller-manager
 - --leader-elect=true
 - -v=1
 image: registry/my-infrastructure-cloud-controller-manager@latest
 resources:
 requests:
 cpu: 200m
 memory: 50Mi
 hostNetwork: true # 这些 Pod 是控制平面的一部分
 nodeSelector:
 node-role.kubernetes.io/control-plane: ""
 affinity:
 podAntiAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
 - topologyKey: "kubernetes.io/hostname"
 labelSelector:
 matchLabels:
 app.kubernetes.io/name: cloud-controller-manager
 tolerations:
 - effect: NoSchedule
 key: node-role.kubernetes.io/master
 operator: Exists
 - effect: NoExecute
 key: node.kubernetes.io/unreachable
 operator: Exists
 tolerationSeconds: 120
 - effect: NoExecute
 key: node.kubernetes.io/not-ready
 operator: Exists
 tolerationSeconds: 120
 - effect: NoSchedule
 key: node.cloudprovider.kubernetes.io/uninitialized
 operator: Exists
 - effect: NoSchedule
 key: node.kubernetes.io/not-ready
 operator: Exists

在决定如何部署云控制器管理器时，需要注意的是，不建议使用与集群规模成比例的或基于资源的 Pod 自动规模扩缩。运行多个云控制器管理器副本是确保高可用性和冗余的良好实践，但这并不会提高性能。通常情况下，任何时候只有一个云控制器管理器实例会负责协调集群。

聚焦 SIG Architecture: Enhancements

Tue, 21 Jan 2025 00:00:00 +0000

这是 SIG Architecture 聚光灯系列的第四次采访，我们将介绍 SIG Architecture: Enhancements。

在本次 SIG Architecture 专题采访中，我们访谈了 Enhancements 子项目的负责人 Kirsten Garrison。

Enhancements 子项目

Frederico (FSM)：你好 Kirsten，很高兴有机会讨论 Enhancements 子项目。开始请先介绍一下你自己和所承担的职责。

Kirsten Garrison (KG)：我是 SIG-Architecture 的 Enhancements 子项目的负责人，目前就职于 Google。我最初在 Carolyn Van Slyck 的帮助下，为 service-catalog 项目贡献代码，后来加入了 Release 团队，最终成为 Enhancements Lead 和 Release Lead 影子。在发布团队工作期间，我根据团队的经验为 SIG 和 Enhancements 团队提出了一些改进流程的想法（如参与其中的流程）。之后，我开始参加子项目会议，并为这个子项目的工作做贡献。

FSM：你提到了 Enhancements 子项目，你如何描述它的主要目标和干预范围？

KG：Enhancements 子项目的核心是管理 Kubernetes 增强提案（KEP），这是 Kubernetes 项目所有特性和重大变更的“设计”文档。

KEP 及其影响

FSM：KEP 流程的改进一直是 SIG Architecture 深度参与的工作之一。你能为不了解的人介绍一下这个流程吗？

KG：在每次发布版本时，各个 SIG 需要告知 Release Team 各自计划将哪些特性放到当前的版本发布中。正如前面提到的，所有变更的前提是有一个 KEP，这是一种标准化的设计文档，所有 KEP 的作者必须在发布周期的最初几周内填写完并获得批准。大多数特性会经历三个阶段： Alpha、Beta，最终进入 GA，因此批准一个特性对 SIG 来说是一项重大承诺。

KEP 作为某个特性真实、完整的信息来源。 KEP 模板对处于不同阶段的特性具有不同的要求，但通常需要详细讨论其设计、影响，并提供稳定性和性能的证明材料。 KEP 通常会在作者、SIG 审查人员、API 审查团队和 Production Readiness Review 团队¹之间进行多轮迭代后才能获批。每组审查者都会确保提案符合其标准，以保证 Kubernetes 版本的稳定性和性能。只有在所有审批完成后，作者才能将其特性合并到 Kubernetes 代码库。

FSM：我懂了，新增了一些结构。回顾来看，你认为这种流程方法最重要的改进是什么？

KG：总体而言，我认为最有影响力的改进在于聚焦 KEP 的核心意图。 KEP 不仅仅是设计的存档文件，更是提供了一种结构化的方式来讨论和达成共识。 KEP 流程的核心是沟通和审慎考虑。

为此，一些重要的改进围绕着更详细且更易于访问的 KEP 模板展开。我们投入了大量时间，使 k/enhancements 仓库发展成当前的形式：目录结构按 SIG 小组划分，附带现代 KEP 模板文件，其中包含 Proposal/Motivation/Design Details（提案/动机/设计细节）等小节。我们今天可能认为这种基本结构是理所当然的，但它实际上代表付出了许多人力和时间努力工作才奠定了这一流程基础。

随着 Kubernetes 的发展和成熟，我们需要考虑的不仅仅是如何合并单个特性，还需要关注稳定性、性能、设置和用户期望等问题。因此随着我们的思考深入，KEP 模板变得更详细。例如增加了 Production Readiness Review 机制，同时对测试要求进行了强化（这些要求会随着 KEP 生命周期的不同阶段动态调整）。

当前关注领域

FSM：说到发展，我们最近发布了 Kubernetes v1.31，而 v1.32 版本的开发工作已经开始。 Enhancements 子项目目前有哪些领域正在推进以改进这个流程？

KG：我们目前正在进行两项工作：

创建一个 Process KEP 模板。有时，人们希望使用 KEP 流程来记录重要的流程变更，而不是特性变更。我们希望支持这一点，因为记录变更很重要，为此提供更好的工具将鼓励更多的讨论和更透明。
KEP 版本化。虽然我们的模板变更旨在尽量减少破坏性影响，但我们认为引入 KEP 版本化及相应的策略，可以让变更更易于追踪并更好地与社区沟通。

这两项改进都需要时间来完善和推广（就像 KEP 特性本身一样），但我们相信它们最终会给社区带来很大的好处。

FSM：你提到了改进：我记得最近的发布引入了用于 Enhancement 追踪的项目看板（Project Board），发布团队成员对此表示一致好评。这是 Enhancements 子项目的一个重点方向吗？

KG：Enhancements 子项目为 Release Team 的 Enhancement 团队提供支持，从使用电子表格迁移到一个项目看板。增强提案的收集和跟踪一直是后勤支持的一项挑战。在我担任 Release Team 成员期间，我帮助推动了增强的“选择加入”机制，即 SIG 负责人需要主动“选择加入” KEP 进行发布追踪。这有助于在对 KEP 实施重大工作之前，加强作者与 SIG 之间的沟通，并减少 Enhancements 团队的重复工作。这一变更利用了现有工具，以避免一次性向社区引入过多变化。后来，Release Team 向子项目提出了利用 GitHub 项目看板进一步改进收集流程的想法。这一举措旨在从使用复杂的电子表格转为使用 k/enhancement Issues 和项目看板上的原生仓库标签。

FSM：这无疑简化了工作流程...

KG：减少摩擦来源、促进清晰沟通对 Enhancements 子项目至关重要。同时，我们也需要谨慎考虑影响整个社区的决策。我们希望确保变更既带来好处，又不会在推广过程中造成回归或额外负担。我们支持 Release Team 进行头脑风暴，并协助完成迁移到项目看板的工作。这次变更取得了巨大成功，很高兴看到团队做出了高影响力的改进，使所有参与 KEP 流程的每个人受益！

如何参与

FSM：如果有人想要参与 Enhancements 子项目，你认为需要具备哪些技能？

KG：熟悉 KEP 机制，无论是通过体验，还是花时间阅读 kubernetes/enhancements 仓库都会有所帮助。我们欢迎所有感兴趣的人参与，我们可以一步步引导他们。

FSM：太棒了！非常感谢你的时间和分享——最后你有什么想对读者们说的吗？

KG：Enhancements 流程是 Kubernetes 生态中最重要组成部分之一，需要各个团队的密切协作才能成功。我很感激并敬佩大家持续不断的努力工作和奉献，让这个项目越来越好。这真是一个很棒的社区。

更多信息参考 Production Readiness Review 专题采访。 ↩︎

使用 API 流式传输来增强 Kubernetes API 服务器效率

Tue, 17 Dec 2024 00:00:00 +0000

高效管理 Kubernetes 集群至关重要，特别是在集群规模不断增长的情况下更是如此。大型集群面临的一个重大挑战是 list 请求所造成的内存开销。

在现有的实现中，kube-apiserver 在处理 list 请求时，先在内存中组装整个响应，再将所有数据传输给客户端。但如果响应体非常庞大，比如数百兆字节呢？另外再想象这样一种场景，有多个 list 请求同时涌入，可能是在短暂的网络中断后涌入。虽然 API 优先级和公平性已经证明可以合理地保护 kube-apiserver 免受 CPU 过载，但其对内存保护的影响却明显较弱。这可以解释为各个 API 请求的资源消耗性质有所不同。在任何给定时间，CPU 使用量都会受到某个常量的限制，而内存由于不可压缩，会随着处理对象数量的增加而成比例增长，且没有上限。这种情况会带来真正的风险，kube-apiserver 可能会在几秒钟内因内存不足（OOM）状况而淹没和崩溃。为了更直观地查验这个问题，我们看看下面的图表。

以上图表显示了 kube-apiserver 在一次模拟测试中的内存使用情况。（有关更多细节，参见模拟测试一节）。结果清楚地表明，增加 informer 的数量显著提高了服务器的内存消耗量。值得注意的是，在大约 16:40 时，服务器在仅提供了 16 个 informer 时就崩溃了。

为什么 kube-apiserver 为 list 请求分配这么多内存？

我们的调查显示，这种大量内存分配的发生是因为在向客户端发送第一个字节之前，服务器必须：

从数据库中获取数据
对数据执行从其存储格式的反序列化
最后通过将数据转换和序列化为客户端所请求的格式来构造最终的响应。

这个序列导致了显著的临时内存消耗。实际使用量取决于许多因素，比如分页大小、所施加的过滤器（例如标签选择算符）、查询参数和单个对象的体量。

不巧的是，无论是 API 优先级和公平性，还是 Golang 的垃圾收集或 Golang 的内存限制，都无法在这些状况下防止系统耗尽内存。内存是被突然且快速分配的，仅仅几个请求就可能迅速耗尽可用内存，导致资源耗尽。

取决于 API 服务器在节点上的运行方式，API 服务器可能在这些不受控制的峰值期间因为超过所配置的内存限制而被内核通过 OOM 杀死，或者如果没有为服务器配置限制值，则其可能对控制平面节点产生更糟糕的影响。最糟糕的是，在第一个 API 服务器出现故障后，相同的请求将很可能会影响高可用（HA）部署中的另一个控制平面节点，并可能产生相同的影响。这可能是一个难以诊断和难以恢复的情况。

流式处理 list 请求

今天，我们很高兴地宣布一项重大改进。随着 Kubernetes 1.32 中 watch list 特性进阶至 Beta， client-go 用户可以选择（在显式启用 WatchListClient 特性门控后）通过将 list 请求切换为（某种特殊类别的） watch 请求来进行流式处理。

watch 请求使用 监视缓存（watch cache） 提供服务，监视缓存是设计来提高读操作扩缩容能力的一个内存缓存。通过逐个流式传输每一项，而不是返回整个集合，这种新方法保持了恒定的内存开销。 API 服务器受限于 etcd 中对象的最大允许体量加上少量额外分配的内存。与传统的 list 请求相比，尤其是在分页情况下内存消耗仍较高的、具有大量特定类别的对象或对象体量平均较大的集群中，这种方法大幅降低了临时内存使用量，确保了系统更高效和更稳定。

基于模拟测试所了解的情况（参见模拟测试），我们开发了一种自动化的性能测试，以系统地评估 watch list 特性的影响。此测试能够重现相同的场景，生成大量载荷较大的 Secret，并扩缩容 informer 的数量以模拟高频率的 list 请求模式。这种自动化测试被定期执行，以监控启用和禁用此特性后服务器的内存使用情况。

结果表明，启用 watch list 特性后有显著改善。启用此特性时，kube-apiserver 的内存消耗稳定在大约 2 GB。相比之下，禁用此特性时，内存使用量增加到约 20 GB，增长了 10 倍！这些结果证实了新的流式 API 的有效性，减少了临时内存占用。

为你的组件启用 API 流式传输

升级到 Kubernetes 1.32。确保你的集群使用 etcd v3.4.31+ 或 v3.5.13+。将你的客户端软件更改为使用 watch list。如果你的客户端代码是用 Golang 编写的，你将需要为 client-go 启用 WatchListClient。有关启用该特性的细节，参阅为 client-go 引入特性门控：增强灵活性和控制。

接下来

在 Kubernetes 1.32 中，尽管此特性处于 Beta 状态，但在 kube-controller-manager 中默认被启用。一旦此特性进阶至正式发布（GA），或许更早，此特性最终将被扩展到 kube-scheduler 或 kubelet 这类其他核心组件。我们鼓励其他第三方组件在此特性处于 Beta 阶段时选择使用此特性，特别是这些组件在有可能访问大量资源或对象体量较大的情况下。

目前，API 优先级和公平性为 list 请求带来了少量但合理的开销。这是必要的，以允许在通常 list 请求开销足够低的情况下实现足够的并行性。但这并不适用于对象数量众多、体量巨大的峰值异常情形。一旦大多数 Kubernetes 生态体系切换到 watch list ，就可以将 list 开销估算调整为更大的值，而不必担心在平均情况下出现性能下降，从而提高对未来可能仍会影响 API 服务器的此类请求的保护。

模拟测试

为了重现此问题，我们实施了手动测试，以了解 list 请求对 kube-apiserver 内存使用量的影响。在测试中，我们创建了 400 个 Secret，每个 Secret 包含 1 MB 的数据，并使用 informer 检索所有 Secret。

结果令人担忧，仅需 16 个 informer 就足以导致测试服务器内存耗尽并崩溃，展示了在这些状况下内存消耗快速增长的方式。

特别感谢 @deads2k 在构造此特性所提供的帮助。

Kubernetes v1.32 增加了新的 CPU Manager 静态策略选项用于严格 CPU 预留

Mon, 16 Dec 2024 00:00:00 +0000

在 Kubernetes v1.32 中，经过社区多年的讨论，我们很高兴地引入了 CPU Manager 静态策略的 strict-cpu-reservation 选项。此特性当前处于 Alpha 阶段，默认情况下关联的策略是隐藏的。只有在你的集群中明确启用了此 Alpha 行为后，才能使用此策略。

理解此特性

CPU Manager 静态策略用于减少延迟或提高性能。reservedSystemCPUs 定义了一个明确的 CPU 集合，供操作系统系统守护进程和 Kubernetes 系统守护进程使用。此选项专为 Telco/NFV 类型的使用场景设计，在这些场景中，不受控制的中断/计时器可能会影响工作负载的性能。你可以使用此选项为系统/Kubernetes 守护进程以及中断/计时器定义明确的 CPU 集合，从而使系统上的其余 CPU 可以专用于工作负载，并减少不受控制的中断/计时器带来的影响。有关此参数的更多详细信息，请参阅显式预留的 CPU 列表页面。

如果你希望保护系统守护进程和中断处理，显而易见的方法是使用 reservedSystemCPUs 选项。

然而，在 Kubernetes v1.32 发布之前，这种隔离仅针对请求整数个 CPU 的 Guaranteed 类型 Pod 实现。在 Pod 准入时，kubelet 仅将 CPU 请求量与可分配的 CPU 进行比较。在 Kubernetes 中，限制值可以高于请求值；之前的实现允许 Burstable 和 BestEffort 类型的 Pod 使用 reservedSystemCPUs 的容量，这可能导致主机操作系统服务缺乏足够的 CPU 资源 —— 并且我们已经知道在实际部署中确实发生过这种情况。现有的行为还导致基础设施和工作负载的基准测试结果不准确。

当启用这个新的 strict-cpu-reservation 策略选项后，CPU Manager 静态策略将不允许任何工作负载使用预留的系统 CPU 核心。

启用此特性

要启用此特性，你需要同时开启 CPUManagerPolicyAlphaOptions 特性门控和 strict-cpu-reservation 策略选项。并且如果存在 /var/lib/kubelet/cpu_manager_state 文件，则需要删除该文件并重启 kubelet。

使用以下 kubelet 配置：

kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
featureGates:
 ...
 CPUManagerPolicyOptions: true
 CPUManagerPolicyAlphaOptions: true
cpuManagerPolicy: static
cpuManagerPolicyOptions:
 strict-cpu-reservation: "true"
reservedSystemCPUs: "0,32,1,33,16,48"
...

当未设置 strict-cpu-reservation 或将其设置为 false 时：

# cat /var/lib/kubelet/cpu_manager_state
{"policyName":"static","defaultCpuSet":"0-63","checksum":1058907510}

当 strict-cpu-reservation 设置为 true 时：

# cat /var/lib/kubelet/cpu_manager_state
{"policyName":"static","defaultCpuSet":"2-15,17-31,34-47,49-63","checksum":4141502832}

监控此特性

你可以通过检查以下 CPU Manager 计数器来监控该特性的影响：

cpu_manager_shared_pool_size_millicores：报告共享池大小，以毫核为单位（例如 13500m）
cpu_manager_exclusive_cpu_allocation_count：报告独占分配的核心数，按完整核心计数（例如 16）

如果 cpu_manager_shared_pool_size_millicores 计数在长时间内为零，你的 BestEffort 类型工作负载可能会因资源匮乏而受到影响。

我们建议，任何用于操作目的的 Pod（如日志转发器）都不应以 BestEffort 方式运行，但你可以根据需要审查并调整预留的 CPU 核心数量。

总结

严格的 CPU 预留对于 Telco/NFV 使用场景至关重要。它也是启用一体化部署类型（其中工作负载被放置在同时担任控制面节点、工作节点和存储角色的节点上）的前提条件。

我们希望你开始使用该特性，并期待你的反馈。

进一步阅读

请查看节点上的控制 CPU 管理策略任务页面，以了解更多关于 CPU Manager 的信息，以及它如何与其他节点级资源管理器相关联。

参与其中

此特性由 SIG Node 推动。如果你有兴趣帮助开发此特性、分享反馈或参与任何其他正在进行的 SIG Node 项目，请参加 SIG Node 会议以获取更多详情。

Kubernetes v1.32：内存管理器进阶至 GA

Fri, 13 Dec 2024 00:00:00 +0000

随着 Kubernetes 1.32 的发布，内存管理器已进阶至正式发布（GA），这标志着在为容器化应用实现高效和可预测的内存分配的旅程中迈出了重要的一步。内存管理器自 Kubernetes v1.22 进阶至 Beta 后，其可靠性、稳定性已得到证实，是 CPU 管理器的一个良好补充特性。

作为 kubelet 的工作负载准入过程的一部分，内存管理器提供拓扑提示以优化内存分配和对齐。这使得用户能够为 Guaranteed QoS 类的 Pod 分配独占的内存。有关此过程的细节，参见博客：内存管理器进阶至 Beta。

自 Beta 以来引入的大部分变更是修复 Bug、内部重构以及改进可观测性（例如优化指标和日志）。

改进可观测性

作为提高内存管理器可观测性工作的一部分，新增了一些指标以提供关于内存分配模式的某些统计信息。

memory_manager_pinning_requests_total - 跟踪 Pod 规约要求内存管理器锁定内存页的次数。
memory_manager_pinning_errors_total - 跟踪 Pod 规约要求内存管理器锁定内存页但分配失败的次数。

提高内存管理器可靠性和一致性

kubelet 不保证在 Pod 重启或重新引导后准入 Pod 的顺序。

在某些边缘情况下，这种行为可能导致内存管理器拒绝某些 Pod，在更极端的情况下，可能导致 kubelet 在重启时失败。

以前，Beta 实现缺乏某些检查和逻辑来防止这些问题的发生。

为了使内存管理器更为稳定，以便为进阶至正式发布（GA）做好准备，我们对算法进行了小而美的改进，提高了其稳健性和对边缘场景的处理能力。

未来发展

总体而言，未来对拓扑管理器（Topology Manager），特别是内存管理器，会有更多特性推出。值得一提的是，目前的工作重心是将内存管理器支持扩展到 Windows，使得在 Windows 操作系统上实现 CPU 和内存亲和性成为可能。

参与其中

此特性由 SIG Node 社区推动。请加入我们，与社区建立联系，分享你对上述特性及其他方面的想法和反馈。我们期待听到你的声音！

Kubernetes v1.32：QueueingHint 为优化 Pod 调度带来了新的可能

Thu, 12 Dec 2024 00:00:00 +0000

Kubernetes 调度器是为新 Pod 选择运行节点的核心组件，调度器会逐一处理这些新 Pod。因此，集群规模越大，调度器的吞吐量就越重要。

多年来，Kubernetes SIG Scheduling 通过多次增强改进了调度器的吞吐量。本博客文章描述了 Kubernetes v1.32 中对调度器的一项重大改进：一个名为 QueueingHint 的调度上下文元素。本页面提供了关于调度器的背景知识，并解释了 QueueingHint 如何提升调度吞吐量。

调度队列

调度器将所有未调度的 Pod 存储在一个名为调度队列的内部组件中。

调度队列由以下数据结构组成：

ActiveQ：保存新创建的 Pod 或准备重试调度的 Pod。
BackoffQ：保存准备重试但正在等待退避期结束的 Pod。退避期取决于调度器对该 Pod 执行的不成功调度尝试次数。
无法调度的 Pod 池：保存调度器不会尝试调度的 Pod，原因可能包括以下几点：
- 调度器之前尝试调度这些 Pod 但未能成功。自那次尝试以来，集群没有发生任何使得这些 Pod 可以被调度的变化。
- 这些 Pod 被 PreEnqueue 插件阻止进入调度周期，例如，它们具有一个调度门控，并被调度门控插件阻止。

调度框架和插件

Kubernetes 调度器的实现遵循 Kubernetes 的调度框架。

并且，所有的调度特性都是以插件的形式实现的（例如，Pod 亲和性是在 InterPodAffinity 插件中实现的。）

调度器按照称为周期的阶段来处理待调度的 Pod，具体如下：

调度周期（Scheduling cycle）：调度器从调度队列的 activeQ 组件中逐一取出待调度的 Pod。对于每个 Pod，调度器会运行来自每个调度插件的过滤/评分逻辑。然后，调度器决定最适合该 Pod 的节点，或者决定当前无法调度该 Pod。

如果调度器决定一个 Pod 无法被调度，该 Pod 将进入调度队列的无法调度的 Pod 池（Unschedulable Pod Pool）组件。然而，如果调度器决定将 Pod 放置到某个节点上，该 Pod 将进入绑定周期（Binding cycle）。
绑定周期（Binding cycle）：调度器将节点分配决策传达给 Kubernetes API 服务器。这一操作将 Pod 绑定到选定的节点。

除了少数例外情况，大多数未调度的 Pod 在每次调度周期后都会进入无法调度的 Pod 池。无法调度的 Pod 池组件至关重要，因为调度周期是逐个处理 Pod 的。如果调度器需要不断重试放置那些无法调度的 Pod，而不是将这些 Pod 分载到无法调度的 Pod 池中，将会在这些 Pod 上浪费很多调度周期。

使用 QueueingHint 改进 Pod 调度重试

无法调度的 Pod 仅在集群发生可能允许调度器将这些 Pod 放置到节点上的变化时，才会重新移入调度队列的 ActiveQ 或 BackoffQ 组件。

在 v1.32 之前，每个插件通过 EnqueueExtensions（EventsToRegister）注册哪些集群变化（称为集群事件，即集群中的对象创建、更新或删除）可以解决其失败情况。当某个插件在之前的调度周期中拒绝了某个 Pod 后，调度队列会在出现该插件注册的事件时重试该 Pod 的调度。

此外，我们还拥有一个名为 preCheck 的内部特性，它基于 Kubernetes 核心调度约束进一步过滤事件以提高效率；例如，preCheck 可以在节点状态为 NotReady 时过滤掉与节点相关的事件。

然而，这些方法存在两个问题：

基于事件的重新排队过于宽泛，可能会导致毫无来由的调度重试。
- 新调度的 Pod 可能解决 InterPodAffinity 失败的问题，但并非所有新 Pod 都能做到。例如，如果创建了一个新的 Pod，但该 Pod 没有与无法调度的 Pod 的 InterPodAffinity 匹配的标签，则该 Pod 仍然无法被调度。
preCheck 依赖于 in-tree 插件的逻辑，并且不适用于自定义插件，如在问题 #110175 中所述。

在这里，QueueingHints 发挥了作用；QueueingHint 订阅特定类型的集群事件，并决定每个传入的事件是否可以使 Pod 变得可调度。

例如，考虑一个名为 pod-a 的 Pod，它具有必需的 Pod 亲和性。pod-a 在调度周期中被 InterPodAffinity 插件拒绝，因为没有节点上有现有的 Pod 符合 pod-a 的 Pod 亲和性规约。

显示调度队列和被 InterPodAffinity 插件拒绝的 pod-a 的图示

pod-a 移入无法调度的 Pod 池 (Unschedulable Pod Pool)。调度队列记录了导致 Pod 调度失败的插件。对于 pod-a，调度队列记录了 InterPodAffinity 插件拒绝了该 Pod。

pod-a 在 InterPodAffinity 失败被解决之前将永远不会被调度。有一些情景可以解决这一失败，例如，一个现有的运行中的 Pod 获取了标签更新并符合 Pod 亲和性要求。在这种情况下，InterPodAffinity 插件的 QueuingHint 回调函数会检查集群中发生的每一个 Pod 标签更新。然后，如果一个 Pod 的标签更新符合 pod-a 的 Pod 亲和性要求，InterPodAffinity 插件的 QueuingHint 会提示调度队列将 pod-a 重新移入 ActiveQ 或 BackoffQ 组件。

显示调度队列和由 InterPodAffinity QueuingHint 移动的 pod-a 的图示

QueueingHint 的历史及 v1.32 中的新变化

在 SIG Scheduling，我们自 Kubernetes v1.28 开始就致力于 QueueingHint 的开发。

尽管 QueueingHint 并不是面向用户的特性，我们在最初添加此特性时还是实现了 SchedulerQueueingHints 特性门控作为安全措施。在 v1.28 中，我们实验性地为几个 in-tree 插件实现了 QueueingHints，并将该特性门控默认启用。

然而，用户报告了一个内存泄漏问题，因此我们在 v1.28 的一个补丁版本中禁用了该特性门控。从 v1.28 到 v1.31，我们一直在其余的 in-tree 插件中继续开发 QueueingHint，并修复相关 bug。

在 v1.32 中，我们再次默认启用了这一特性。我们完成了所有插件中 QueueingHints 的实现，并且找到了内存泄漏的原因！

我们感谢所有参与此特性开发的贡献者，以及那些报告和调查早期问题的用户。

参与其中

这些特性由 Kubernetes SIG Scheduling 管理。

请加入我们并分享你的反馈。

如何了解更多？

KEP-4247：为调度队列中的高效重新排队实现每插件回调函数

Kubernetes v1.32 预览

Fri, 08 Nov 2024 00:00:00 +0000

随着 Kubernetes v1.32 发布日期的临近，Kubernetes 项目继续发展和成熟。在这个过程中，某些特性可能会被弃用、移除或被更好的特性取代，以确保项目的整体健康与发展。

本文概述了 Kubernetes v1.32 发布的一些计划变更，发布团队认为你应该了解这些变更，以确保你的 Kubernetes 环境得以持续维护并跟上最新的变化。以下信息基于 v1.32 发布的当前状态，实际发布日期前可能会有所变动。

Kubernetes API 的移除和弃用流程

Kubernetes 项目对功能特性有一个文档完备的弃用策略。该策略规定，只有当较新的、稳定的相同 API 可用时，原有的稳定 API 才可能被弃用，每个稳定级别的 API 都有一个最短的生命周期。弃用的 API 指的是已标记为将在后续发行某个 Kubernetes 版本时移除的 API；移除之前该 API 将继续发挥作用（从弃用起至少一年时间），但使用时会显示一条警告。移除的 API 将在当前版本中不再可用，此时你必须迁移以使用替换的 API。

正式发布的（GA）或稳定的 API 版本可被标记为已弃用，但不得在 Kubernetes 主要版本未变时删除。
Beta 或预发布 API 版本，必须保持在被弃用后 3 个发布版本中仍然可用。
Alpha 或实验性 API 版本可以在任何版本中删除，不必提前通知；如果同一特性已有不同实施方案，则此过程可能会成为撤销。

无论 API 是因为特性从 Beta 升级到稳定状态还是因为未能成功而被移除，所有移除操作都遵守此弃用策略。每当 API 被移除时，迁移选项都会在弃用指南中进行说明。

关于撤回 DRA 的旧的实现的说明

增强特性 #3063 在 Kubernetes 1.26 中引入了动态资源分配（DRA）。

然而，在 Kubernetes v1.32 中，这种 DRA 的实现方法将发生重大变化。与原来实现相关的代码将被删除，只留下 KEP #4381 作为"新"的基础特性。

改变现有方法的决定源于其与集群自动伸缩的不兼容性，因为资源可用性是不透明的，这使得 Cluster Autoscaler 和控制器的决策变得复杂。新增的结构化参数模型替换了原有特性。

这次移除将使 Kubernetes 能够更可预测地处理新的硬件需求和资源声明，避免了与 kube-apiserver 之间复杂的来回 API 调用。

请参阅增强问题 #3063 以了解更多信息。

API 移除

在 Kubernetes v1.32 中，计划仅移除一个 API：

flowcontrol.apiserver.k8s.io/v1beta3 版本的 FlowSchema 和 PriorityLevelConfiguration 已被移除。为了对此做好准备，你可以编辑现有的清单文件并重写客户端软件，使用自 v1.29 起可用的 flowcontrol.apiserver.k8s.io/v1 API 版本。所有现有的持久化对象都可以通过新 API 访问。flowcontrol.apiserver.k8s.io/v1beta3 中的重要变化包括：当未指定时，PriorityLevelConfiguration 的 spec.limited.nominalConcurrencyShares 字段仅默认为 30，而显式设置的 0 值不会被更改为此默认值。

有关更多信息，请参阅 API 弃用指南。

Kubernetes v1.32 的抢先预览

以下增强特性有可能会被包含在 v1.32 发布版本中。请注意，这并不是最终承诺，发布内容可能会发生变化。

Windows 工作继续

KEP #4802 为 Kubernetes 集群中的 Windows 节点添加了体面关机支持。在此之前，Kubernetes 为 Linux 节点提供了体面关机特性，但缺乏对 Windows 节点的同等支持。这一增强特性使 Windows 节点上的 kubelet 能够正确处理系统关机事件，确保在 Windows 节点上运行的 Pod 能够体面终止，从而允许工作负载在不受干扰的情况下重新调度。这一改进提高了包含 Windows 节点的集群的可靠性和稳定性，特别是在计划维护或系统更新期间。

允许环境变量中使用特殊字符

随着这一增强特性升级到 Beta 阶段， Kubernetes 现在允许几乎所有的可打印 ASCII 字符（不包括 =）作为环境变量名称。这一变化解决了此前对变量命名的限制，通过适应各种应用需求，促进了 Kubernetes 的更广泛采用。放宽的验证将通过 RelaxedEnvironmentVariableValidation 特性门控默认启用，确保用户可以轻松使用环境变量而不受严格限制，增强了开发者在处理需要特殊字符配置的应用（如 .NET Core）时的灵活性。

使 Kubernetes 感知到 LoadBalancer 的行为

KEP #1860 升级到 GA 阶段，为 type: LoadBalancer 类型的 Service 引入了 ipMode 字段，该字段可以设置为 "VIP" 或 "Proxy"。这一增强旨在改善云提供商负载均衡器与 kube-proxy 的交互方式，对最终用户来说是透明的。使用 "VIP" 时，kube-proxy 会继续处理负载均衡，保持现有的行为。使用 "Proxy" 时，流量将直接发送到负载均衡器，提供云提供商对依赖 kube-proxy 的更大控制权；这意味着对于某些云提供商，你可能会看到负载均衡器性能的提升。

为资源生成名称时重试

这一增强特性改进了使用 generateName 字段创建 Kubernetes 资源时的名称冲突处理。此前，如果发生名称冲突， API 服务器会返回 409 HTTP 冲突错误，客户端需要手动重试请求。通过此次更新， API 服务器在发生冲突时会自动重试生成新名称，最多重试七次。这显著降低了冲突的可能性，确保生成多达 100 万个名称时冲突的概率低于 0.1%，为大规模工作负载提供了更高的弹性。

想了解更多？

新特性和弃用特性也会在 Kubernetes 发布说明中宣布。我们将在此次发布的 Kubernetes v1.32 的 CHANGELOG 中正式宣布新内容。

你可以在以下版本的发布说明中查看变更公告：

关于日本的 Kubernetes 上游培训的特别报道

Mon, 28 Oct 2024 00:00:00 +0000

我们是日本 Kubernetes 上游培训的组织者。我们的团队由积极向 Kubernetes 做贡献的成员组成，他们在社区中担任了 Member、Reviewer、Approver 和 Chair 等角色。

我们的目标是增加 Kubernetes 贡献者的数量，并促进社区的成长。虽然 Kubernetes 社区友好协作，但新手可能会发现迈出贡献的第一步有些困难。我们的培训项目旨在降低壁垒，创造一个即使是初学者也能顺利参与的环境。

日本 Kubernetes 上游培训是什么？

我们的培训始于 2019 年，每年举办 1 到 2 次。最初，Kubernetes 上游培训曾作为 KubeCon（Kubernetes 贡献者峰会）的同场地活动进行，后来我们在日本推出了 Kubernetes 上游培训，目的是通过在日本举办类似活动来增加日本的贡献者。

在疫情之前，培训是面对面进行的，但自 2020 年以来，我们已转为在线上进行。培训为尚未参与过 Kubernetes 贡献的学员提供以下内容：

Kubernetes 社区简介
Kubernetes 代码库概述以及如何创建你的第一个 PR
各种降低参与壁垒（如语言）的提示和鼓励
如何搭建开发环境
使用 kubernetes-sigs/contributor-playground 开展实践课程

在培训开始时，我们讲解为什么贡献 Kubernetes 很重要以及谁可以做贡献。我们强调，贡献 Kubernetes 可以让你产生全球影响，而 Kubernetes 社区期待着你的贡献！

我们还讲解 Kubernetes 社区、SIG（特别兴趣小组）和 WG（工作组）。接下来，我们讲解 Member、Reviewer、Approver、Tech Lead 和 Chair 的角色与职责。此外，我们介绍大家所使用的主要沟通工具，如 Slack、GitHub 和邮件列表。一些讲日语的人可能会觉得用英语沟通是一个障碍。此外，社区的新人需要理解在哪儿以及如何与人交流。我们强调迈出第一步的重要性，这是我们培训中最关注的方面！

然后，我们讲解 Kubernetes 代码库的结构、主要的仓库、如何创建 PR 以及使用 Prow 的 CI/CD 流程。我们详细讲解从创建 PR 到合并 PR 的过程。

经过几节课后，参与者将体验使用 kubernetes-sigs/contributor-playground 开展实践工作，在那里他们可以创建一个简单的 PR。目标是让参与者体验贡献 Kubernetes 的过程。

在项目结束时，我们还提供关于为贡献 kubernetes/kubernetes 仓库搭建开发环境的详细说明，包括如何在本地构建代码、如何高效运行测试以及如何搭建集群。

与参与者的访谈

我们对参与我们培训项目的人进行了访谈。我们询问了他们参加的原因、印象和未来目标。

Keita Mochizuki（NTT DATA 集团公司）

Keita Mochizuki 是一位持续为 Kubernetes 及相关项目做贡献的贡献者。他还是容器安全领域的专业人士，他最近出版了一本书。此外，他还发布了一份新贡献者路线图，对新贡献者非常有帮助。

Junya： 你为什么决定参加 Kubernetes 上游培训？

Keita： 实际上，我分别在 2020 年和 2022 年参加过两次培训。在 2020 年，我刚开始学习 Kubernetes，想尝试参与工作以外的活动，所以在 Twitter 上偶然看到活动后报了名参加了活动。然而，那时我的知识积累还不多，贡献 OSS 感觉超出了我的能力。因此，在培训后的理解比较肤浅，离开时更多是“嗯，好吧”的感觉。

在 2022 年，我再次参加，那时我认真考虑开始贡献。我事先进行了研究，并能够在讲座中解决我的问题，那次经历非常有成效。

Junya： 参加后你有什么感受？

Keita： 我觉得培训的意义很大程度上取决于参与者的心态。培训本身包括常规的讲解和简单的实践练习，但这并不意味着参加培训就会立即会去做贡献。

Junya： 你贡献的目的是什么？

Keita： 我最初的动机是“深入理解 Kubernetes 并生成成绩记录”，也就是说“贡献本身就是目标”。如今，我还会通过贡献来解决我在工作中发现的 Bug 或约束。此外，通过贡献，我变得不再那么犹豫，会去直接基于源代码分析了解没有文档记录的特性。

Junya： 贡献中遇到的挑战是什么？

Keita： 最困难的部分是迈出第一步。贡献 OSS 需要一定的知识水平，利用像这样的培训和他人的支持至关重要。一句让我印象深刻的话是，“一旦你迈出第一步，后续就会变得更容易。”
此外，在作为工作的一部分继续贡献时，最具挑战性的是将输出的结果变为成就感。要保持长期贡献，将贡献与业务目标和策略对齐非常重要，但上游贡献并不总是能直接产生与表现相关的即时结果。因此，确保与管理人员的相互理解并获得他们的支持至关重要。

Junya： 你未来的目标是什么？

Keita： 我的目标是对影响更大的领域做出贡献。到目前为止，我主要通过修复较小的 Bug 来做贡献，因为我的主要关注是生成一份成绩单，但未来，我希望挑战自己对 Kubernetes 用户产生更大影响的贡献，或解决与我工作相关的问题。最近，我还在努力将我对代码库所做的更改反映到官方文档中，我将这视为实现我目标的一步。

Junya： 非常感谢！

Yoshiki Fujikane（CyberAgent, Inc.）

Yoshiki Fujikane 是 CNCF 沙盒项目 PipeCD 的维护者之一。除了在 PipeCD 中开发对 Kubernetes 支持的新特性外， Yoshiki 还积极参与社区管理，并在各种技术会议上发言。

Junya： 你为什么决定参加 Kubernetes 上游培训？

Yoshiki： 当我参与培训时，我还是一名学生。我只简短地接触过 EKS，我觉得 Kubernetes 看起来复杂但很酷，我对此有一种随意的兴趣。当时，OSS 对我来说感觉像是遥不可及，而 Kubernetes 的上游开发似乎非常令人生畏。虽然我一直对 OSS 感兴趣，但我不知道从哪里开始。也就在那个时候，我了解到 Kubernetes 上游培训，并决定挑战自己为 Kubernetes 做贡献。

Junya： 参加后你的印象是什么？

Yoshiki： 我发现对于了解如何成为 OSS 社区的一部分，这种培训是一种非常有价值的方式。当时，我的英语水平不是很好，所以获取主要信息源对我来说是一个很大的障碍。 Kubernetes 是一个非常大的项目，我对整体结构没有清晰的理解，更不用说贡献所需的内容了。上游培训提供了对社区结构的日文解释，并让我获得了实际贡献的实践经验。得益于我所得到的指导，我学会了如何接触主要信息源，并将其作为进一步研究的切入点，这对我帮助很大。这次经历让我意识到组织和评审主要信息源的重要性，现在我经常在 GitHub Issue 和文档中深入研究我感兴趣的内容。因此，虽然我不再直接向 Kubernetes 做贡献，但这次经历为我在其他项目中做贡献奠定了很好的基础。

Junya： 你目前在哪些领域做贡献？你参与了哪些其他项目？

Yoshiki： 目前，我不再从事 Kubernetes 的工作，而是担任 CNCF 沙盒项目 PipeCD 的维护者。 PipeCD 是一个支持各种应用平台的 GitOps 式部署的 CD 工具。此工具最初作为 CyberAgent 的内部项目启动。随着不同团队采用不同的平台，PipeCD 设计为提供一个统一的 CD 平台，确保用户体验一致。目前，它支持 Kubernetes、AWS ECS、Lambda、Cloud Run 和 Terraform。

Junya： 你在 PipeCD 团队中扮演什么角色？

Yoshiki： 我全职负责团队中与 Kubernetes 相关特性的改进和开发。由于我们将 PipeCD 作为内部 SaaS 提供，我的主要关注点是添加新特性和改进现有特性，确保 PipeCD 能够持续良好支持 Kubernetes 等平台。除了代码贡献外，我还通过在各种活动上发言和管理社区会议来帮助发展 PipeCD 社区。

Junya： 你能讲解一下你对于 Kubernetes 正在进行哪些改进或开发吗？

Yoshiki： PipeCD 支持 Kubernetes 的 GitOps 和渐进式交付，因此我参与这些特性的开发。最近，我一直在开发简化跨多个集群部署的特性。

Junya： 在贡献 OSS 的过程中，你遇到过哪些挑战？

Yoshiki： 一个挑战是开发在满足用户用例的同时保持通用性的特性。当我们在运营内部 SaaS 期间收到特性请求时，我们首先考虑添加特性来解决这些问题。与此同时，我们希望 PipeCD 作为一个 OSS 工具被更广泛的受众使用。因此，我总是思考为一个用例设计的特性是否可以应用于其他用例，以确保 PipeCD 这个软件保持灵活且广泛可用。

Junya： 你未来的目标是什么？

Yoshiki： 我希望专注于扩展 PipeCD 的功能。目前，我们正在以“普遍可用的持续交付”（One CD for All）的口号开发 PipeCD。正如我之前提到的，它支持 Kubernetes、AWS ECS、Lambda、Cloud Run 和 Terraform，但还有许多其他平台，以及未来可能会出现的新平台。因此，我们目前正在开发一个插件系统，允许用户自行扩展 PipeCD，我希望将这一努力向前推进。我也在处理 Kubernetes 的多集群部署特性，目标是继续做出有影响力的贡献。

Junya： 非常感谢！

Kubernetes 上游培训的未来

我们计划继续在日本举办 Kubernetes 上游培训，并期待欢迎更多的新贡献者。我们的下一次培训定于 11 月底在 CloudNative Days Winter 2024 期间举行。

此外，我们的目标不仅是在日本推广这些培训项目，还希望推广到全球。今年的 Kubernetes 十周年庆，以及为了使社区更加活跃，让全球各地的人们持续贡献至关重要。虽然上游培训已经在多个地区举行，但我们希望将其带到更多地方。

我们希望随着越来越多的人加入 Kubernetes 社区并做出贡献，我们的社区将变得更加生机勃勃！

公布 2024 年指导委员会选举结果

Wed, 02 Oct 2024 15:10:00 -0500

2024 年指导委员会选举现已完成。 Kubernetes 指导委员会由 7 个席位组成，其中 3 个席位于 2024 年进行选举。新任委员会成员的任期为 2 年，所有成员均由 Kubernetes 社区选举产生。

这个社区机构非常重要，因为它负责监督整个 Kubernetes 项目的治理。权力越大责任越大，你可以在其章程中了解有关指导委员会角色的更多信息。

感谢所有在选举中投票的人；你们的参与有助于支持社区的持续健康和成功。

结果

祝贺当选的委员会成员，其两年任期立即开始（按 GitHub 句柄按字母顺序列出）：

Antonio Ojea (@aojea), Google
Benjamin Elder (@BenTheElder), Google
Sascha Grunert (@saschagrunert), Red Hat

他们将与以下连任成员一起工作：

Stephen Augustus (@justaugustus), Cisco
Paco Xu 徐俊杰 (@pacoxu), DaoCloud
Patrick Ohly (@pohly), Intel
Maciej Szulik (@soltysh), Defense Unicorns

Benjamin Elder 是一位回归的指导委员会成员。

十分感谢！

感谢并祝贺本轮选举官员成功完成选举工作：

Bridget Kromhout (@bridgetkromhout)
Christoph Blecker (@cblecker)
Priyanka Saggu (@Priyankasaggu11929)

感谢名誉指导委员会成员，你们的服务受到社区的赞赏：

Bob Killen (@mrbobbytables)
Nabarun Pal (@palnabarun)

感谢所有前来竞选的候选人。

参与指导委员会

这个管理机构与所有 Kubernetes 一样，向所有人开放。你可以关注指导委员会会议记录，并通过提交 Issue 或针对其 repo 创建 PR 来参与。他们在太平洋时间每月第一个周一上午 8:00 举行开放的会议。你还可以通过其公共邮件列表 steering@kubernetes.io 与他们联系。

你可以通过在 YouTube 播放列表上观看过去的会议来了解指导委员会会议的全部内容。

如果你想认识一些新当选的指导委员会成员，欢迎参加在盐湖城举行的 2024 年北美 Kubernetes 贡献者峰会上的 Steering AMA。

这篇文章是由贡献者通信子项目撰写的。如果你想撰写有关 Kubernetes 社区的故事，请了解有关我们的更多信息。

SIG Scheduling 访谈

Tue, 24 Sep 2024 00:00:00 +0000

在本次 SIG Scheduling 的访谈中，我们与 Kensei Nakada 进行了交流，他是 SIG Scheduling 的一名 Approver。

介绍

Arvind: 你好，感谢你让我们有机会了解 SIG Scheduling！你能介绍一下自己，告诉我们你的角色以及你是如何参与 Kubernetes 的吗？

Kensei: 嗨，感谢你给我这个机会！我是 Kensei Nakada (@sanposhiho)，是来自 Tetrate.io 的一名软件工程师。我在业余时间为 Kubernetes 贡献了超过 3 年的时间，现在我是 Kubernetes 中 SIG Scheduling 的一名 Approver。同时，我还是两个 SIG 子项目的创始人/负责人： kube-scheduler-simulator 和 kube-scheduler-wasm-extension。

关于 SIG Scheduling

AP: 太棒了！你参与这个项目已经很久了。你能简要概述一下 SIG Scheduling，并说明它在 Kubernetes 生态系统中的角色吗？

KN: 正如名字所示，我们的责任是增强 Kubernetes 中的调度特性。具体来说，我们开发了一些组件，将每个 Pod 调度到最合适的 Node。在 Kubernetes 中，我们的主要关注点是维护 kube-scheduler，以及其他调度相关的组件，这些组件是 SIG Scheduling 的子项目。

AP: 明白了！我有点好奇，SIG Scheduling 最近为 Kubernetes 调度引入了哪些创新或发展？

KN: 从特性的角度来看，最近对 PodTopologySpread 进行了几项增强。 PodTopologySpread 是调度器中一个相对较新的特性，我们仍在收集反馈并进行改进。

最近，我们专注于一个内部增强特性，称为 QueueingHint，这个特性旨在提高调度的吞吐量。吞吐量是我们调度中的关键指标之一。传统上，我们主要关注优化每个调度周期的延迟。而 QueueingHint 采取了一种不同的方法，它可以优化何时重试调度，从而减少浪费调度周期的可能性。

A: 听起来很有趣！你目前在 SIG Scheduling 中还有其他有趣的主题或项目吗？

KN: 我正在牵头刚刚提到的 QueueingHint 的开发。考虑到这是我们面临的一项重大新挑战，我们遇到了许多意想不到的问题，特别是在可扩展性方面，我们正在努力解决每一个问题，使这项特性最终能够默认启用。

此外，我认为我去年启动的 kube-scheduler-wasm-extension（SIG 子项目）对许多人来说也会很有趣。Kubernetes 有各种扩展来自许多组件。传统上，扩展通过 Webhook （调度器中的 extender）或 Go SDK（调度器中的调度框架）提供。然而，这些方法存在缺点，首先是 Webhook 的性能问题以及需要重建和替换调度器的 Go SDK，这就给那些希望扩展调度器但对其不熟悉的人带来了困难。此项目尝试引入一种新的解决方案来应对这一普遍挑战，即基于 WebAssembly 的扩展。 Wasm 允许用户轻松构建插件，而无需担心重新编译或替换调度器，还能规避性能问题。

通过这个项目，SIG Scheduling 正在积累 WebAssembly 与大型 Kubernetes 对象交互的宝贵洞察。我相信我们所获得的经验应该对整个社区都很有用，而不仅限于 SIG Scheduling 的范围。

A: 当然！目前 SIG Scheduling 有 8 个子项目。你想谈谈它们吗？有没有一些你想强调的有趣贡献？

KN: 让我挑选三个子项目：Kueue、KWOK 和 Descheduler。

Kueue:: 最近，许多人尝试使用 Kubernetes 管理批处理工作负载，2022 年，Kubernetes 社区成立了 WG-Batch，以更好地支持 Kubernetes 中的此类批处理工作负载。 Kueue 是一个在其中扮演关键角色的项目。它是一个作业队列控制器，决定何时一个作业应该等待，何时一个作业应该被准许启动，以及何时一个作业应该被抢占。 Kueue 旨在安装在一个普通的 Kubernetes 集群上，同时与现有的成熟控制器（调度器、cluster-autoscaler、kube-controller-manager 等）协作。

KWOK: KWOK 这个组件可以在几秒钟内创建一个包含数千个节点的集群。它主要用于模拟/测试轻量级集群，实际上另一个 SIG 子项目 kube-scheduler-simulator 就在后端使用了 KWOK。
Descheduler: Descheduler 这个组件可以将运行在不理想的节点上的 Pod 重新创建。在 Kubernetes 中，调度约束（PodAffinity、NodeAffinity、PodTopologySpread 等）仅在 Pod 调度时被考虑，但不能保证这些约束在之后仍然被满足。Descheduler 会驱逐违反其调度约束（或其他不符合预期状况）的 Pod，以便这些 Pod 被重新创建和重新调度。

Descheduling Framework:: 一个非常有趣的正在进行的项目，类似于调度器中的调度框架，旨在使去调度逻辑可扩展，并允许维护者们专注于构建 Descheduler 的核心引擎。

AP: 感谢你告诉我们这些！我想问一下，你最喜欢这个 SIG 的哪些方面？

KN: 我真正喜欢这个 SIG 的地方在于每个人都积极参与。我们来自不同的公司和行业，带来了多样的视角。这些差异并没有造成分歧，实际上产生了丰富的观点。每种观点都会受到尊重，这使我们的讨论既丰富又富有成效。

我非常欣赏这种协作氛围，我相信这对我们多年来不断改进组件至关重要。

给 SIG Scheduling 做贡献

AP: Kubernetes 是一个社区驱动的项目。你对新贡献者或希望参与并为 SIG Scheduling 做出贡献的初学者有什么建议？他们应该从哪里开始？

KN: 让我先给出一个关于为任何 SIG 贡献的通用建议：一种常见的方法是寻找 good-first-issue。然而，你很快就会意识到，世界各地有很多人正在尝试为 Kubernetes 仓库做贡献。

我建议先查看你感兴趣的某个组件的实现。如果你对该组件有任何疑问，可以在相应的 Slack 频道中提问（例如，调度器的 #sig-scheduling，kubelet 的 #sig-node 等）。一旦你对实现有了大致了解，就可以查看 SIG 中的 Issue （例如，sig-scheduling），相比 good-first-issue，在这里你会发现更多未分配的 Issue。你可能还想过滤带有 kind/cleanup 标签的 Issue，这通常表示较低优先级的任务，可以作为起点。

具体对于 SIG Scheduling 而言，你应该先了解调度框架，这是 kube-scheduler 的基本架构。大多数实现都可以在 pkg/scheduler中找到。我建议从 ScheduleOne 函数开始，然后再深入探索。

此外，除了 kubernetes/kubernetes 主仓库外，还可以考虑查看一些子项目。这些子项目的维护者通常比较少，你有更多的机会来对其产生重大影响。尽管被称为“子”项目，但许多项目实际上有大量用户，并对社区产生了相当大的影响。

最后但同样重要的是，记住为社区做贡献不仅仅是编写代码。虽然我谈到了很多关于实现的贡献，但还有许多其他方式可以做贡献，每一种都很有价值。对某个 Issue 的一条评论，对现有特性的一个反馈，对 PR 的一个审查建议，对文档的一个说明阐述；每一个小贡献都有助于推动 Kubernetes 生态系统向前发展。

AP: 这些建议非常有用！冒昧问一下，你是如何帮助新贡献者入门的，参与 SIG Scheduling 的贡献者可能会学习到哪些技能？

KN: 我们的维护者在 #sig-scheduling Slack 频道中随时可以回答你的问题。多多参与，你将深入了解 Kubernetes 的调度，并有机会与来自不同背景的维护者合作和建立联系。你将学习到的不仅仅是如何编写代码，还有如何维护大型项目、设计和讨论新特性、解决 Bug 等等。

未来方向

AP: 在调度方面，Kubernetes 特有的挑战有哪些？有没有特别的痛点？

KN: 在 Kubernetes 中进行调度可能相当具有挑战性，因为不同组织有不同的业务要求。在 kube-scheduler 中支持所有可能的使用场景是不可能的。因此，可扩展性是我们关注的核心焦点。几年前，我们使用调度框架为 kube-scheduler 重新设计了架构，为用户通过插件实现各种调度需求提供了灵活的可扩展性。这使得维护者们能够专注于核心调度特性和框架运行时。

另一个主要问题是保持足够的调度吞吐量。通常，一个 Kubernetes 集群只有一个 kube-scheduler，因此其吞吐量直接影响整体调度的可扩展性，从而影响集群的可扩展性。尽管我们有一个内部性能测试 (scheduler_perf)，但不巧的是，我们有时会忽视在不常见场景下的性能下降。即使是与性能无关的小改动也有难度，可能导致性能下降。

AP: 接下来 SIG Scheduling 有哪些即将实现的目标或计划？你如何看待 SIG 的未来发展？

KN: 我们的主要目标始终是构建和维护可扩展的和稳定的调度运行时，我敢打赌这个目标将永远不会改变。

正如之前所提到的，可扩展性是解决调度多样化需求挑战的关键。我们不会尝试直接在 kube-scheduler 中支持每种不同的使用场景，而是将继续专注于增强可扩展性，以便能够适应各种用例。我提到的 kube-scheduler-wasm-extension 也是这一计划的一部分。

关于稳定性，引入 QueueHint 这类新的优化是我们的一项策略。此外，保持吞吐量也是面向未来的关键目标。我们计划增强我们的吞吐量监控 (参考)，以便在发布之前尽可能多地发现性能下降问题。但实际上，我们无法覆盖每个可能的场景。我们非常感谢社区对调度吞吐量的关注，鼓励大家提出反馈，就性能问题提出警示！

结束语

AP: 最后，你想对那些有兴趣了解 SIG Scheduling 的人说些什么？

KN: 调度是 Kubernetes 中最复杂的领域之一，你可能一开始会觉得很困难。但正如我之前分享的，你可以找到许多贡献的机会，许多维护者愿意帮助你理解各事项。我们知道你独特的视角和技能是我们的开源项目能够如此强大的源泉 😊

随时可以通过 Slack (#sig-scheduling) 或会议联系我们。我希望这篇文章能引起大家的兴趣，希望能吸引到新的贡献者！

AP: 非常感谢你抽出时间进行这次访谈！我相信很多人会发现这些信息对理解 SIG Scheduling 和参与 SIG 的贡献非常有价值。

Kubernetes v1.31：kubeadm v1beta4

Fri, 23 Aug 2024 00:00:00 +0000

作为 Kubernetes v1.31 发布的一部分，kubeadm 采用了全新版本（v1beta4）的配置文件格式。之前 v1beta3 格式的配置现已正式弃用，这意味着尽管之前的格式仍然受支持，但你应迁移到 v1beta4 并停止使用已弃用的格式。对 v1beta3 配置的支持将在至少 3 次 Kubernetes 次要版本发布后被移除。

在本文中，我将介绍关键的变更；我将解释 kubeadm v1beta4 配置格式，以及如何从 v1beta3 迁移到 v1beta4。

你可以参阅 v1beta4 配置格式的参考文档： kubeadm 配置 (v1beta4)。

自 v1beta3 以来的变更列表

此版本通过修复一些小问题并添加一些新字段来改进 v1beta3 格式。

简单而言，

增加了两个新的配置元素：ResetConfiguration 和 UpgradeConfiguration
对于 InitConfiguration 和 JoinConfiguration，支持 dryRun 模式和 nodeRegistration.imagePullSerial
对于 ClusterConfiguration，新增字段包括 certificateValidityPeriod、caCertificateValidityPeriod、 encryptionAlgorithm、dns.disabled 和 proxy.disabled
所有控制平面组件支持 extraEnvs
extraArgs 从映射变更为支持重复的结构化额外参数
为 init、join、upgrade 和 reset 添加了 timeouts 结构

有关细节请参阅以下官方文档：

在 ClusterConfiguration 下支持控制平面组件的自定义环境变量。可以使用 apiServer.extraEnvs、controllerManager.extraEnvs、scheduler.extraEnvs、etcd.local.extraEnvs。
ResetConfiguration API 类型现在在 v1beta4 中得到支持。用户可以通过将 --config 文件传递给 kubeadm reset 来重置节点。
dryRun 模式现在在 InitConfiguration 和 JoinConfiguration 中可配置。

用支持重复的结构化额外参数替换现有的 string/string 额外参数映射。此变更适用于 ClusterConfiguration - apiServer.extraArgs、controllerManager.extraArgs、 scheduler.extraArgs、etcd.local.extraArgs。也适用于 nodeRegistrationOptions.kubeletExtraArgs。
添加了 ClusterConfiguration.encryptionAlgorithm，可用于设置此集群的密钥和证书所使用的非对称加密算法。可以是 "RSA-2048"（默认）、"RSA-3072"、"RSA-4096" 或 "ECDSA-P256" 之一。
添加了 ClusterConfiguration.dns.disabled 和 ClusterConfiguration.proxy.disabled，可用于在集群初始化期间禁用 CoreDNS 和 kube-proxy 插件。在集群创建期间跳过相关插件阶段将把相同的字段设置为 true。

在 InitConfiguration 和 JoinConfiguration 中添加了 nodeRegistration.imagePullSerial 字段，可用于控制 kubeadm 是顺序拉取镜像还是并行拉取镜像。
当将 --config 传递给 kubeadm upgrade 子命令时，现已在 v1beta4 中支持 UpgradeConfiguration kubeadm API。对于升级子命令，kubelet 和 kube-proxy 的组件配置以及 InitConfiguration 和 ClusterConfiguration 的用法现已弃用，并将在传递 --config 时被忽略。
在 InitConfiguration、JoinConfiguration、ResetConfiguration 和 UpgradeConfiguration 中添加了 timeouts 结构，可用于配置各种超时。 ClusterConfiguration.timeoutForControlPlane 字段被 timeouts.controlPlaneComponentHealthCheck 替换。 JoinConfiguration.discovery.timeout 被 timeouts.discovery 替换。

向 ClusterConfiguration 添加了 certificateValidityPeriod 和 caCertificateValidityPeriod 字段。这些字段可用于控制 kubeadm 在 init、join、upgrade 和 certs 等子命令中生成的证书的有效期。默认值继续为非 CA 证书 1 年和 CA 证书 10 年。另请注意，只有非 CA 证书可以通过 kubeadm certs renew 进行续期。

这些变更简化了使用 kubeadm 的工具的配置，并提高了 kubeadm 本身的可扩展性。

如何将 v1beta3 配置迁移到 v1beta4？

如果你的配置未使用最新版本，建议你使用 kubeadm config migrate 命令进行迁移。

此命令读取使用旧格式的现有配置文件，并写入一个使用当前格式的新文件。

示例

使用 kubeadm v1.31，运行 kubeadm config migrate --old-config old-v1beta3.yaml --new-config new-v1beta4.yaml

我该如何参与？

衷心感谢在此特性的设计、实现和评审中提供帮助的所有贡献者：

Lubomir I. Ivanov (neolit123)
Dave Chen (chendave)
Paco Xu (pacoxu)
Sata Qiu (sataqiu)
Baofa Fan (carlory)
Calvin Chen (calvin0327)
Ruquan Zhao (ruquanzhao)

如果你有兴趣参与 kubeadm 配置的后续讨论，可以通过多种方式与 kubeadm 或 SIG-cluster-lifecycle 联系：

v1beta4 相关事项在 kubeadm issue #2890 中跟踪。
Slack: #kubeadm 或 #sig-cluster-lifecycle
邮件列表

Kubernetes 1.31：kubectl debug 中的自定义模板化配置特性已进入 Beta 阶段

Thu, 22 Aug 2024 00:00:00 +0000

有很多方法可以对集群中的 Pod 和节点进行故障排查，而 kubectl debug 是最简单、使用最广泛、最突出的方法之一。它提供了一组静态配置，每个配置适用于不同类型的角色。例如，从网络管理员的视角来看，调试节点应该像这样简单：

$ kubectl debug node/mynode -it --image=busybox --profile=netadmin

另一方面，静态配置也存在固有的刚性，对某些 Pod 所产生的影响与其易用性是相悖的。因为各种类型的 Pod（或节点）都有其特定的需求，不幸的是，有些问题仅通过静态配置是无法调试的。

以一个简单的 Pod 为例，此 Pod 由一个容器组成，其健康状况依赖于环境变量：

apiVersion: v1
kind: Pod
metadata:
 name: example-pod
spec:
 containers:
 - name: example-container
 image: customapp:latest
 env:
 - name: REQUIRED_ENV_VAR
 value: "value1"

目前，复制 Pod 是使用 kubectl debug 命令调试此 Pod 的唯一机制。此外，如果用户需要将 REQUIRED_ENV_VAR 环境变量修改为其他不同值来进行高级故障排查，当前并没有机制能够实现这一需求。

自定义模板化配置

自定义模板化配置使用 --custom 标志提供的一项新特性，在 kubectl debug 中引入以提供可扩展性。它需要以 YAML 或 JSON 格式的内容填充 container 规约，为了通过创建临时容器来调试上面的示例容器，我们只需定义此 YAML：

# partial_container.yaml
env:
 - name: REQUIRED_ENV_VAR
 value: value2

并且执行：

kubectl debug example-pod -it --image=customapp --custom=partial_container.yaml

下面是另一个在 JSON 中一次修改多个字段（更改端口号、添加资源限制、修改环境变量）的示例：

{
 "ports": [
 {
 "containerPort": 80
 }
 ],
 "resources": {
 "limits": {
 "cpu": "0.5",
 "memory": "512Mi"
 },
 "requests": {
 "cpu": "0.2",
 "memory": "256Mi"
 }
 },
 "env": [
 {
 "name": "REQUIRED_ENV_VAR",
 "value": "value2"
 }
 ]
}

约束

不受控制的扩展性会损害可用性。因此，某些字段（例如命令、镜像、生命周期、卷设备和容器名称）不允许进行自定义模版化配置。将来如果需要，可以将更多字段添加到禁止列表中。

限制

kubectl debug 命令有 3 个方面：使用临时容器进行调试、Pod 复制和节点调试。这些方面最大的交集是 Pod 内的容器规约，因此自定义模版化配置仅支持修改使用 containers 下定义的字段。这导致了一个限制，如果用户需要修改 Pod 规约中的其他字段，则不受支持。

致谢

特别感谢所有审查和评论此特性（从最初的概念到实际实施）的贡献者（按字母顺序排列）：

Kubernetes 1.31：细粒度的 SupplementalGroups 控制

Thu, 22 Aug 2024 00:00:00 +0000

本博客讨论了 Kubernetes 1.31 中的一项新特性，目的是改善处理 Pod 中容器内的附加组。

动机：容器镜像中 `/etc/group` 中定义的隐式组成员关系

尽管这种行为可能并不受许多 Kubernetes 集群用户/管理员的欢迎，但 Kubernetes 默认情况下会将 Pod 中的组信息与容器镜像中 /etc/group 中定义的信息进行合并。

让我们看一个例子，以下 Pod 在 Pod 的安全上下文中指定了 runAsUser=1000、runAsGroup=3000 和 supplementalGroups=4000。

implicit-groups.yaml

apiVersion: v1
kind: Pod
metadata:
 name: implicit-groups
spec:
 securityContext:
 runAsUser: 1000
 runAsGroup: 3000
 supplementalGroups: [4000]
 containers:
 - name: ctr
 image: registry.k8s.io/e2e-test-images/agnhost:2.45
 command: [ "sh", "-c", "sleep 1h" ]
 securityContext:
 allowPrivilegeEscalation: false

在 ctr 容器中执行 id 命令的结果是什么？

# 创建 Pod：
$ kubectl apply -f https://k8s.io/blog/2024-08-22-Fine-grained-SupplementalGroups-control/implicit-groups.yaml

# 验证 Pod 的容器正在运行：
$ kubectl get pod implicit-groups

# 检查 id 命令
$ kubectl exec implicit-groups -- id

输出应类似于：

uid=1000 gid=3000 groups=3000,4000,50000

尽管 50000 根本没有在 Pod 的清单中被定义，但附加组中的组 ID 50000（groups 字段）是从哪里来的呢？答案是容器镜像中的 /etc/group 文件。

检查容器镜像中 /etc/group 的内容应如下所示：

$ kubectl exec implicit-groups -- cat /etc/group
...
user-defined-in-image:x:1000:
group-defined-in-image:x:50000:user-defined-in-image

原来如此！容器的主要用户 1000 属于最后一个条目中的组 50000。

因此，容器镜像中为容器的主要用户定义的组成员关系会被隐式合并到 Pod 的信息中。请注意，这是当前 CRI 实现从 Docker 继承的设计决策，而社区直到现在才重新考虑这个问题。

这有什么问题？

从容器镜像中的 /etc/group 隐式合并的组信息可能会引起一些担忧，特别是在访问卷时（有关细节参见 kubernetes/kubernetes#112879），因为在 Linux 中文件权限是通过 uid/gid 进行控制的。更糟糕的是，隐式的 gid 无法被任何策略引擎所检测/验证，因为在清单中没有隐式组信息的线索。这对 Kubernetes 的安全性也可能构成隐患。

Pod 中的细粒度 SupplementalGroups 控制：`SupplementaryGroupsPolicy`

为了解决上述问题，Kubernetes 1.31 在 Pod 的 .spec.securityContext 中引入了新的字段 supplementalGroupsPolicy。

此字段提供了一种控制 Pod 中容器进程如何计算附加组的方法。可用的策略如下：

Merge：将容器的主要用户在 /etc/group 中定义的组成员关系进行合并。如果不指定，则应用此策略（即为了向后兼容性而保持的原有行为）。
Strict：仅将 fsGroup、supplementalGroups 或 runAsGroup 字段中指定的组 ID 挂接为容器进程的附加组。这意味着容器的主要用户在 /etc/group 中定义的任何组成员关系都不会被合并。

让我们看看 Strict 策略是如何工作的。

strict-supplementalgroups-policy.yaml

apiVersion: v1
kind: Pod
metadata:
 name: strict-supplementalgroups-policy
spec:
 securityContext:
 runAsUser: 1000
 runAsGroup: 3000
 supplementalGroups: [4000]
 supplementalGroupsPolicy: Strict
 containers:
 - name: ctr
 image: registry.k8s.io/e2e-test-images/agnhost:2.45
 command: [ "sh", "-c", "sleep 1h" ]
 securityContext:
 allowPrivilegeEscalation: false

# 创建 Pod：
$ kubectl apply -f https://k8s.io/blog/2024-08-22-Fine-grained-SupplementalGroups-control/strict-supplementalgroups-policy.yaml

# 验证 Pod 的容器正在运行：
$ kubectl get pod strict-supplementalgroups-policy

# 检查进程身份：
kubectl exec -it strict-supplementalgroups-policy -- id

输出应类似于：

uid=1000 gid=3000 groups=3000,4000

你可以看到 Strict 策略可以将组 50000 从 groups 中排除出去！

因此，确保（通过某些策略机制强制执行的）supplementalGroupsPolicy: Strict 有助于防止 Pod 中的隐式附加组。

说明：

实际上，这还不够，因为具有足够权限/能力的容器可以更改其进程身份。有关细节参见以下章节。

Pod 状态中挂接的进程身份

此特性还通过 .status.containerStatuses[].user.linux 字段公开挂接到容器的第一个容器进程的进程身份。这将有助于查看隐式组 ID 是否被挂接。

...
status:
 containerStatuses:
 - name: ctr
 user:
 linux:
 gid: 3000
 supplementalGroups:
 - 3000
 - 4000
 uid: 1000
...

说明：

请注意，status.containerStatuses[].user.linux 字段中的值是首次挂接到容器中第一个容器进程的进程身份。如果容器具有足够的权限调用与进程身份相关的系统调用（例如 setuid(2)、 setgid(2) 或 setgroups(2) 等），则容器进程可以更改其身份。因此，实际的进程身份将是动态的。

特性可用性

要启用 supplementalGroupsPolicy 字段，必须使用以下组件：

Kubernetes：v1.31 或更高版本，启用 SupplementalGroupsPolicy 特性门控。截至 v1.31，此门控标记为 Alpha。
CRI 运行时：
- containerd：v2.0 或更高版本
- CRI-O：v1.31 或更高版本

你可以在 Node 的 .status.features.supplementalGroupsPolicy 字段中查看此特性是否受支持。

apiVersion: v1
kind: Node
...
status:
 features:
 supplementalGroupsPolicy: true

接下来

Kubernetes SIG Node 希望并期待此特性将在 Kubernetes 后续版本中进阶至 Beta，并最终进阶至正式发布（GA），以便用户不再需要手动启用特性门控。

当 supplementalGroupsPolicy 未被指定时，将应用 Merge 策略，以保持向后兼容性。

我如何了解更多？

为 Pod 或容器配置安全上下文以获取有关 supplementalGroupsPolicy 的更多细节
KEP-3619：细粒度 SupplementalGroups 控制

如何参与？

此特性由 SIG Node 社区推动。请加入我们，与社区保持联系，分享你对上述特性及其他方面的想法和反馈。我们期待听到你的声音！

Kubernetes v1.31：全新的 Kubernetes CPUManager 静态策略：跨核分发 CPU

Thu, 22 Aug 2024 00:00:00 +0000

在 Kubernetes v1.31 中，我们很高兴引入了对 CPU 管理能力的重大增强：针对 CPUManager 静态策略的 distribute-cpus-across-cores 选项。此特性目前处于 Alpha 阶段，默认被隐藏，标志着旨在优化 CPU 利用率和改善多核处理器系统性能的战略转变。

理解这一特性

传统上，Kubernetes 的 CPUManager 倾向于尽可能紧凑地分配 CPU，通常将这些 CPU 打包到尽可能少的物理核上。然而，分配策略很重要，因为同一物理主机上的 CPU 仍然共享一些物理核的资源，例如缓存和执行单元等。

虽然默认方法可以最小化核间通信，并在某些情况下是有益的，但也带来了挑战。在同一物理核上共享的 CPU 可能导致资源竞争，从而可能造成性能瓶颈，这在 CPU 密集型应用中尤为明显。

全新的 distribute-cpus-across-cores 特性通过修改分配策略来解决这个问题。当此特性被启用时，此策略选项指示 CPUManager 尽可能将 CPU（硬件线程）分发到尽可能多的物理核上。这种分发旨在最小化共享同一物理核的 CPU 之间的争用，从而通过为应用提供专用的核资源来潜在提高性能。

从技术上讲，在这个静态策略中，可用的 CPU 列表按照图示的方式重新排序，旨在从不同的物理核分配 CPU。

启用此特性

要启用此特性，用户首先需要在 kubelet 配置中添加 --cpu-manager-policy=static kubelet 标志或 cpuManagerPolicy: static 字段。然后用户可以在 Kubernetes 配置中添加 --cpu-manager-policy-options distribute-cpus-across-cores=true 或 distribute-cpus-across-cores=true 到自己的 CPUManager 策略选项中。此设置指示 CPUManager 采用新的分发策略。需要注意的是，目前此策略选项无法与 full-pcpus-only 或 distribute-cpus-across-numa 选项一起使用。

当前限制和未来方向

与所有新特性一样，尤其是处于 Alpha 阶段的特性，此特性也存在一些限制，很多方面还有待后续改进。当前一个显著的限制是 distribute-cpus-across-cores 不能与可能在 CPU 分配策略上存在冲突的其他策略选项结合使用。这一限制可能会影响与（依赖于更专业的资源管理的）某些工作负载和部署场景的兼容性。

展望未来，我们将致力于增强 distribute-cpus-across-cores 选项的兼容性和特性。未来的更新将专注于解决这些兼容性问题，使此策略能够与其他 CPUManager 策略无缝结合。我们的目标是提供一个更灵活和强大的 CPU 分配框架，能够适应各种工作负载和性能需求。

结论

在 Kubernetes CPUManager 中引入 distribute-cpus-across-cores 策略是我们持续努力改进资源管理和提升应用性能而向前迈出的一步。通过减少物理核上的争用，此特性提供了更加平衡的 CPU 资源分配方法，特别有利于运行异构工作负载的环境。我们鼓励 Kubernetes 用户测试这一新特性并提供反馈，这将对其未来发展至关重要。

本文旨在清晰地解释这一新特性，同时设定对其当前阶段和未来改进的期望。

进一步阅读

请查阅节点上的 CPU 管理策略任务页面，以了解有关 CPU 管理器的更多信息，以及 CPU 管理器与其他节点级资源管理器的关系。

参与其中

此特性由 SIG Node 推动。如果你有兴趣帮助开发此特性、分享反馈或参与其他目前 SIG Node 项目的工作，请参加 SIG Node 会议了解更多细节。

Kubernetes 1.31: 节点 Cgroup 驱动程序的自动配置 (beta)

Wed, 21 Aug 2024 00:00:00 +0000

一直以来，为新运行的 Kubernetes 集群配置正确的 cgroup 驱动程序是用户的一个痛点。在 Linux 系统中，存在两种不同的 cgroup 驱动程序：cgroupfs 和 systemd。过去，kubelet 和 CRI 实现（如 CRI-O 或 containerd）需要配置为使用相同的 cgroup 驱动程序，否则 kubelet 会报错并退出。这让许多集群管理员头疼不已。不过，现在曙光乍现！

自动检测 cgroup 驱动程序

在 v1.28.0 版本中，SIG Node 社区引入了 KubeletCgroupDriverFromCRI 特性门控，它指示 kubelet 向 CRI 实现询问使用哪个 cgroup 驱动程序。在两个主要的 CRI 实现（containerd 和 CRI-O）增加对该功能的支持这段期间，Kubernetes 经历了几次小版本发布，但从 v1.31.0 版本开始，此功能现已进入 beta 阶段！

除了设置特性门控之外，集群管理员还需要确保 CRI 实现版本足够新：

containerd：v2.0.0 版本开始支持
CRI-O：v1.28.0 版本开始支持

然后，他们应该确保配置其 CRI 实现使用他们想要的 cgroup 驱动程序。

未来工作

最终，kubelet 对 cgroupDriver 配置字段的支持将会被移除，如果 CRI 实现的版本不够新，无法支持此功能，kubelet 将无法启动。

Kubernetes 1.31：流式传输从 SPDY 转换为 WebSocket

Tue, 20 Aug 2024 00:00:00 +0000

在 Kubernetes 1.31 中，kubectl 现在默认使用 WebSocket 协议而不是 SPDY 进行流式传输。

这篇文章介绍了这些变化对你意味着什么以及这些流式传输 API 的重要性。

Kubernetes 中的流式 API

在 Kubernetes 中，某些以 HTTP 或 RESTful 接口公开的某些端点会被升级为流式连接，因而需要使用流式协议。与 HTTP 这种请求-响应协议不同，流式协议提供了一种持久的双向连接，具有低延迟的特点，并允许实时交互。流式协议支持在客户端与服务器之间通过同一个连接进行双向的数据读写。这种类型的连接非常有用，例如，当你从本地工作站在某个运行中的容器内创建 shell 并在该容器中运行命令时。

为什么要改变流式传输协议？

在 v1.31 版本发布之前，Kubernetes 默认使用 SPDY/3.1 协议来升级流式连接。但是 SPDY/3.1 已经被废弃了八年之久，并且从未被标准化，许多现代代理、网关和负载均衡器已经不再支持该协议。因此，当你尝试通过代理或网关访问集群时，可能会发现像 kubectl cp、kubectl attach、kubectl exec 和 kubectl port-forward 这样的命令无法正常工作。

从 Kubernetes v1.31 版本开始，SIG API Machinery 修改了 Kubernetes 客户端（如 kubectl）中用于这些命令的流式传输协议，将其改为更现代化的 WebSocket 流式传输协议。 WebSocket 协议是一种当前得到支持的标准流式传输协议，它可以确保与不同组件及编程语言之间的兼容性和互操作性。相较于 SPDY，WebSocket 协议更为广泛地被现代代理和网关所支持。

流式 API 的工作原理

Kubernetes 通过在原始的 HTTP 请求中添加特定的升级头字段来将 HTTP 连接升级为流式连接。例如，在集群内的 nginx 容器上运行 date 命令的 HTTP 升级请求类似于以下内容：

$ kubectl exec -v=8 nginx -- date
GET https://127.0.0.1:43251/api/v1/namespaces/default/pods/nginx/exec?command=date…
Request Headers:
 Connection: Upgrade
 Upgrade: websocket
 Sec-Websocket-Protocol: v5.channel.k8s.io
 User-Agent: kubectl/v1.31.0 (linux/amd64) kubernetes/6911225

如果容器运行时支持 WebSocket 流式协议及其至少一个子协议版本（例如 v5.channel.k8s.io），服务器会以代表成功的 101 Switching Protocols 状态码进行响应，并附带协商后的子协议版本：

Response Status: 101 Switching Protocols in 3 milliseconds
Response Headers:
 Upgrade: websocket
 Connection: Upgrade
 Sec-Websocket-Accept: j0/jHW9RpaUoGsUAv97EcKw8jFM=
 Sec-Websocket-Protocol: v5.channel.k8s.io

此时，原本用于 HTTP 协议的 TCP 连接已转换为流式连接。随后，此 Shell 交互中的标准输入（STDIN）、标准输出（STDOUT）和标准错误输出（STDERR）数据（以及终端重置大小数据和进程退出码数据）会通过这个升级后的连接进行流式传输。

如何使用新的 WebSocket 流式协议

如果你的集群和 kubectl 版本为 1.29 及以上版本，有两个控制面特性门控以及两个 kubectl 环境变量用来控制启用 WebSocket 而不是 SPDY 作为流式协议。在 Kubernetes 1.31 中，以下所有特性门控均处于 Beta 阶段，并且默认被启用：

特性门控
- TranslateStreamCloseWebsocketRequests
  - .../exec
  - .../attach
- PortForwardWebsockets
  - .../port-forward
kubectl 特性控制环境变量
- KUBECTL_REMOTE_COMMAND_WEBSOCKETS
  - kubectl exec
  - kubectl cp
  - kubectl attach
- KUBECTL_PORT_FORWARD_WEBSOCKETS
  - kubectl port-forward

如果你正在使用一个较旧的集群但可以管理其特性门控设置，那么可以通过开启 TranslateStreamCloseWebsocketRequests（在 Kubernetes v1.29 中添加）和 PortForwardWebsockets（在 Kubernetes v1.30 中添加）来尝试启用 Websocket 作为流式传输协议。版本为 1.31 的 kubectl 可以自动使用新的行为，但你需要连接到明确启用了服务器端特性的集群。

了解有关流式 API 的更多信息

Kubernetes 1.31：针对 Job 的 Pod 失效策略进阶至 GA

Mon, 19 Aug 2024 00:00:00 +0000

这篇博文阐述在 Kubernetes 1.31 中进阶至 Stable 的 Pod 失效策略，还介绍如何在你的 Job 中使用此策略。

关于 Pod 失效策略

当你在 Kubernetes 上运行工作负载时，Pod 可能因各种原因而失效。理想情况下，像 Job 这样的工作负载应该能够忽略瞬时的、可重试的失效，并继续运行直到完成。

要允许这些瞬时的失效，Kubernetes Job 需包含 backoffLimit 字段，此字段允许你指定在 Job 执行期间你愿意容忍的 Pod 失效次数。然而，如果你为 backoffLimit 字段设置了一个较大的值，并完全依赖这个字段，你可能会发现，由于在满足 backoffLimit 条件之前 Pod 重启次数太多，导致运营成本发生不必要的增加。

在运行大规模的、包含跨数千节点且长时间运行的 Pod 的 Job 时，这个问题尤其严重。

Pod 失效策略扩展了回退限制机制，帮助你通过以下方式降低成本：

让你在出现不可重试的 Pod 失效时控制 Job 失败。
允许你忽略可重试的错误，而不增加 backoffLimit 字段。

例如，通过忽略由节点体面关闭引起的 Pod 失效，你可以使用 Pod 失效策略在更实惠的临时机器上运行你的工作负载。

此策略允许你基于失效 Pod 中的容器退出码或 Pod 状况来区分可重试和不可重试的 Pod 失效。

它是如何工作的

你在 Job 规约中指定的 Pod 失效策略是一个规则的列表。

对于每个规则，你基于以下属性之一来定义匹配条件：

容器退出码：onExitCodes 属性。
Pod 状况：onPodConditions 属性。

此外，对于每个规则，你要指定在 Pod 与此规则匹配时应采取的动作，可选动作为以下之一：

Ignore：不将失效计入 backoffLimit 或 backoffLimitPerIndex。
FailJob：让整个 Job 失败并终止所有运行的 Pod。
FailIndex：与失效 Pod 对应的索引失效。
此动作与逐索引回退限制特性一起使用。
Count：将失效计入 backoffLimit 或 backoffLimitPerIndex。这是默认行为。

当在运行的 Job 中发生 Pod 失效时，Kubernetes 按所给的顺序将失效 Pod 的状态与 Pod 失效策略规则的列表进行匹配，并根据匹配的第一个规则采取相应的动作。

请注意，在指定 Pod 失效策略时，你还必须在 Job 的 Pod 模板中设置 restartPolicy: Never。此字段可以防止在对 Pod 失效计数时在 kubelet 和 Job 控制器之间出现竞争条件。

Kubernetes 发起的 Pod 干扰

为了允许将 Pod 失效策略规则与由 Kubernetes 引发的干扰所导致的失效进行匹配，此特性引入了 DisruptionTarget Pod 状况。

Kubernetes 会将此状况添加到因可重试的干扰场景而失效的所有 Pod，无论其是否由 Job 控制器管理。其中 DisruptionTarget 状况包含与这些干扰场景对应的以下原因之一：

PreemptionByKubeScheduler：由 kube-scheduler 抢占以接纳更高优先级的新 Pod。
DeletionByTaintManager - Pod 因其不容忍的 NoExecute 污点而被 kube-controller-manager 删除。
EvictionByEvictionAPI - Pod 因为 API 发起的驱逐而被删除。
DeletionByPodGC - Pod 被绑定到一个不再存在的节点，并将通过 Pod 垃圾收集而被删除。
TerminationByKubelet - Pod 因节点体面关闭、节点压力驱逐或被系统关键 Pod抢占

在所有其他干扰场景中，例如因超过 Pod 容器限制而驱逐， Pod 不会收到 DisruptionTarget 状况，因为干扰可能是由 Pod 引起的，并且在重试时会再次发生干扰。

示例

下面的 Pod 失效策略片段演示了一种用法：

podFailurePolicy:
 rules:
 - action: Ignore
 onPodConditions:
 - type: DisruptionTarget
 - action: FailJob
 onPodConditions:
 - type: ConfigIssue
 - action: FailJob
 onExitCodes:
 operator: In
 values: [ 42 ]

在这个例子中，Pod 失效策略执行以下操作：

忽略任何具有内置 DisruptionTarget 状况的失效 Pod。这些 Pod 不计入 Job 回退限制。
如果任何失效的 Pod 具有用户自定义的、由自定义控制器或 Webhook 添加的 ConfigIssue 状况，则让 Job 失败。
如果任何容器以退出码 42 退出，则让 Job 失败。
将所有其他 Pod 失效计入默认的 backoffLimit（在合适的情况下，计入 backoffLimitPerIndex）。

进一步了解

有关使用 Pod 失效策略的实践指南，参见使用 Pod 失效策略处理可重试和不可重试的 Pod 失效
阅读文档：Pod 失效策略和逐索引回退限制
阅读文档：Pod 干扰状况
阅读 KEP：Pod 失效策略

参与其中

这项工作由 Batch Working Group（批处理工作组）发起，与 SIG Apps、 SIG Node 和 SIG Scheduling 社区密切合作。

如果你有兴趣处理这个领域中的新特性，建议你订阅我们的 Slack 频道，并参加定期的社区会议。

感谢

我想感谢在这些年里参与过这个项目的每个人。这是一段旅程，也是一个社区共同努力的见证！以下名单是我尽力记住并对此特性产生过影响的人。感谢大家！

Aldo Culquicondor 在整个过程中提供指导和审查
Jordan Liggitt 审查 KEP 和 API
David Eads 审查 API
Maciej Szulik 从 SIG Apps 角度审查 KEP
Clayton Coleman 提供指导和 SIG Node 审查
Sergey Kanzhelev 从 SIG Node 角度审查 KEP
Dawn Chen 从 SIG Node 角度审查 KEP
Daniel Smith 从 SIG API Machinery 角度进行审查
Antoine Pelisse 从 SIG API Machinery 角度进行审查
John Belamaric 审查 PRR
Filip Křepinský 从 SIG Apps 角度进行全面审查并修复 Bug
David Porter 从 SIG Node 角度进行全面审查
Jensen Lo 进行早期需求讨论、测试和报告问题
Daniel Vega-Myhre 推进 JobSet 集成并报告问题
Abdullah Gharaibeh 进行早期设计讨论和指导
Antonio Ojea 审查测试
Yuki Iwai 审查并协调相关 Job 特性的实现
Kevin Hannon 审查并协调相关 Job 特性的实现
Tim Bannister 审查文档
Shannon Kularathna 审查文档
Paola Cortés 审查文档

Kubernetes 1.31：podAffinity 中的 matchLabelKeys 进阶至 Beta

Fri, 16 Aug 2024 00:00:00 +0000

Kubernetes 1.29 在 podAffinity 和 podAntiAffinity 中引入了新的字段 matchLabelKeys 和 mismatchLabelKeys。

在 Kubernetes 1.31 中，此特性进阶至 Beta，并且相应的特性门控（MatchLabelKeysInPodAffinity）默认启用。

`matchLabelKeys` - 为多样化滚动更新增强了调度

在工作负载（例如 Deployment）的滚动更新期间，集群中可能同时存在多个版本的 Pod。
然而，调度器无法基于 podAffinity 或 podAntiAffinity 中指定的 labelSelector 区分新旧版本。结果，调度器将并置或分散调度 Pod，不会考虑这些 Pod 的版本。

这可能导致次优的调度结果，例如：

新版本的 Pod 与旧版本的 Pod（podAffinity）并置在一起，这些旧版本的 Pod 最终将在滚动更新后被移除。
旧版本的 Pod 被分布在所有可用的拓扑中，导致新版本的 Pod 由于 podAntiAffinity 无法找到节点。

matchLabelKeys 是一组 Pod 标签键，可以解决上述问题。
调度器从新 Pod 的标签中查找这些键的值，并将其与 labelSelector 结合，以便 podAffinity 匹配到具有相同标签键值的 Pod。

通过在 matchLabelKeys 中使用标签 pod-template-hash，
你可以确保对 podAffinity 或 podAntiAffinity 进行评估时仅考虑相同版本的 Pod。

apiVersion: apps/v1
kind: Deployment
metadata:
 name: application-server
...
 affinity:
 podAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
 - labelSelector:
 matchExpressions:
 - key: app
 operator: In
 values:
 - database
 topologyKey: topology.kubernetes.io/zone
 matchLabelKeys:
 - pod-template-hash

上述 Pod 中的 matchLabelKeys 将被转换为：

kind: Pod
metadata:
 name: application-server
 labels:
 pod-template-hash: xyz
...
 affinity:
 podAffinity:
 requiredDuringSchedulingIgnoredDuringExecution:
 - labelSelector:
 matchExpressions:
 - key: app
 operator: In
 values:
 - database
 - key: pod-template-hash # 从 matchLabelKeys 添加; 只有来自同一 ReplicaSet 的 Pod 将与此亲和性匹配
 operator: In
 values:
 - xyz 
 topologyKey: topology.kubernetes.io/zone
 matchLabelKeys:
 - pod-template-hash

`mismatchLabelKeys` - 服务隔离

mismatchLabelKeys 是一组 Pod 标签键，类似于 matchLabelKeys，
它在新 Pod 的标签中查找这些键的值，并将其与 labelSelector 合并为 key notin (value)，以便 podAffinity 不会匹配到具有相同标签键值的 Pod。

假设每个租户的所有 Pod 通过控制器或像 Helm 这样的清单管理工具得到 tenant 标签。

尽管在组合每个工作负载的清单时，tenant 标签的值是未知的，
但集群管理员希望实现租户与域之间形成排他性的 1:1 对应关系，以便隔离租户。

mismatchLabelKeys 适用于这一使用场景；
通过使用变更性质的 Webhook 在全局应用以下亲和性，集群管理员可以确保来自同一租户的 Pod 将以独占方式落到同一域上，
这意味着来自其他租户的 Pod 不会落到同一域上。

affinity:
 podAffinity: # 确保此租户的 Pod 落在同一节点池上
 requiredDuringSchedulingIgnoredDuringExecution:
 - matchLabelKeys:
 - tenant
 topologyKey: node-pool
 podAntiAffinity: # 确保只有此租户的 Pod 落在同一节点池上
 requiredDuringSchedulingIgnoredDuringExecution:
 - mismatchLabelKeys:
 - tenant
 labelSelector:
 matchExpressions:
 - key: tenant
 operator: Exists
 topologyKey: node-pool

上述的 matchLabelKeys 和 mismatchLabelKeys 将被转换为：

kind: Pod
metadata:
 name: application-server
 labels:
 tenant: service-a
spec:
 affinity:
 podAffinity: # 确保此租户的 Pod 落在同一节点池上
 requiredDuringSchedulingIgnoredDuringExecution:
 - matchLabelKeys:
 - tenant
 topologyKey: node-pool
 labelSelector:
 matchExpressions:
 - key: tenant
 operator: In
 values:
 - service-a 
 podAntiAffinity: # 确保只有此租户的 Pod 落在同一节点池上
 requiredDuringSchedulingIgnoredDuringExecution:
 - mismatchLabelKeys:
 - tenant
 labelSelector:
 matchExpressions:
 - key: tenant
 operator: Exists
 - key: tenant
 operator: NotIn
 values:
 - service-a 
 topologyKey: node-pool

参与其中

这些特性由 Kubernetes SIG Scheduling 管理。

请加入我们并分享你的反馈。我们期待听到你的声音！

了解更多

Kubernetes 1.31：防止无序删除时 PersistentVolume 泄漏

Fri, 16 Aug 2024 00:00:00 +0000

PersistentVolume（简称 PV）具有与之关联的回收策略。回收策略用于确定在删除绑定到 PV 的 PVC 时存储后端需要采取的操作。当回收策略为 Delete 时，期望存储后端释放为 PV 所分配的存储资源。实际上，在 PV 被删除时就需要执行此回收策略。

在最近发布的 Kubernetes v1.31 版本中，一个 Beta 特性允许你配置集群以这种方式运行并执行你配置的回收策略。

在以前的 Kubernetes 版本中回收是如何工作的？

PersistentVolumeClaim （简称 PVC）是用户对存储的请求。如果新创建了 PV 或找到了匹配的 PV，那么此 PV 和此 PVC 被视为已绑定。 PV 本身是由存储后端所分配的卷支持的。

通常，如果卷要被删除，对应的预期是为一个已绑定的 PV-PVC 对删除其中的 PVC。不过，对于在删除 PVC 之前可否删除 PV 并没有限制。

首先，我将演示运行旧版本 Kubernetes 的集群的行为。

检索绑定到 PV 的 PVC

检索现有的 PVC example-vanilla-block-pvc：

kubectl get pvc example-vanilla-block-pvc

以下输出显示了 PVC 及其绑定的 PV；此 PV 显示在 VOLUME 列下：

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
example-vanilla-block-pvc Bound pvc-6791fdd4-5fad-438e-a7fb-16410363e3da 5Gi RWO example-vanilla-block-sc 19s

删除 PV

当我尝试删除已绑定的 PV 时，kubectl 会话被阻塞，且 kubectl 工具不会将控制权返回给 Shell；例如：

kubectl delete pv pvc-6791fdd4-5fad-438e-a7fb-16410363e3da

persistentvolume "pvc-6791fdd4-5fad-438e-a7fb-16410363e3da" deleted
^C

检索 PV

kubectl get pv pvc-6791fdd4-5fad-438e-a7fb-16410363e3da

你可以观察到 PV 处于 Terminating 状态：

NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-6791fdd4-5fad-438e-a7fb-16410363e3da 5Gi RWO Delete Terminating default/example-vanilla-block-pvc example-vanilla-block-sc 2m23s

删除 PVC

kubectl delete pvc example-vanilla-block-pvc

如果 PVC 被成功删除，则会看到以下输出：

persistentvolumeclaim "example-vanilla-block-pvc" deleted

集群中的 PV 对象也被删除。当尝试检索 PV 时，你会观察到该 PV 已不再存在：

kubectl get pv pvc-6791fdd4-5fad-438e-a7fb-16410363e3da

Error from server (NotFound): persistentvolumes "pvc-6791fdd4-5fad-438e-a7fb-16410363e3da" not found

尽管 PV 被删除，但下层存储资源并未被删除，需要手动移除。

总结一下，与 PersistentVolume 关联的回收策略在某些情况下会被忽略。对于 Bound 的 PV-PVC 对，PV-PVC 删除的顺序决定了回收策略是否被执行。如果 PVC 先被删除，则回收策略被执行；但如果在删除 PVC 之前 PV 被删除，则回收策略不会被执行。因此，外部基础设施中关联的存储资产未被移除。

Kubernetes v1.31 的 PV 回收策略

新的行为确保当用户尝试手动删除 PV 时，下层存储对象会从后端被删除。

如何启用新的行为？

要利用新的行为，你必须将集群升级到 Kubernetes v1.31 版本，并运行 CSI external-provisioner v5.0.1 或更高版本。

工作方式

对于 CSI 卷，新的行为是通过在新创建和现有的 PV 上添加 Finalizer external-provisioner.volume.kubernetes.io/finalizer 来实现的。只有在后端存储被删除后，Finalizer 才会被移除。

下面是一个带 Finalizer 的 PV 示例，请注意 Finalizer 列表中的新 Finalizer：

kubectl get pv pvc-a7b7e3ba-f837-45ba-b243-dec7d8aaed53 -o yaml

apiVersion: v1
kind: PersistentVolume
metadata:
 annotations:
 pv.kubernetes.io/provisioned-by: csi.vsphere.vmware.com
 creationTimestamp: "2021-11-17T19:28:56Z"
 finalizers:
 - kubernetes.io/pv-protection
 - external-provisioner.volume.kubernetes.io/finalizer
 name: pvc-a7b7e3ba-f837-45ba-b243-dec7d8aaed53
 resourceVersion: "194711"
 uid: 087f14f2-4157-4e95-8a70-8294b039d30e
spec:
 accessModes:
 - ReadWriteOnce
 capacity:
 storage: 1Gi
 claimRef:
 apiVersion: v1
 kind: PersistentVolumeClaim
 name: example-vanilla-block-pvc
 namespace: default
 resourceVersion: "194677"
 uid: a7b7e3ba-f837-45ba-b243-dec7d8aaed53
 csi:
 driver: csi.vsphere.vmware.com
 fsType: ext4
 volumeAttributes:
 storage.kubernetes.io/csiProvisionerIdentity: 1637110610497-8081-csi.vsphere.vmware.com
 type: vSphere CNS Block Volume
 volumeHandle: 2dacf297-803f-4ccc-afc7-3d3c3f02051e
 persistentVolumeReclaimPolicy: Delete
 storageClassName: example-vanilla-block-sc
 volumeMode: Filesystem
status:
 phase: Bound

Finalizer 防止此 PersistentVolume 从集群中被移除。如前文所述，Finalizer 仅在从存储后端被成功删除后才会从 PV 对象中被移除。进一步了解 Finalizer，请参阅使用 Finalizer 控制删除。

同样，Finalizer kubernetes.io/pv-controller 也被添加到动态制备的树内插件卷中。

有关 CSI 迁移的卷

本次修复同样适用于 CSI 迁移的卷。

一些注意事项

本次修复不适用于静态制备的树内插件卷。

参考

我该如何参与？

Kubernetes Slack SIG Storage 交流频道是与 SIG Storage 和迁移工作组团队联系的良好媒介。

特别感谢以下人员的用心评审、周全考虑和宝贵贡献：

Fan Baofa (carlory)
Jan Šafránek (jsafrane)
Xing Yang (xing-yang)
Matthew Wong (wongma7)

如果你有兴趣参与 CSI 或 Kubernetes Storage 系统任何部分的设计和开发，请加入 Kubernetes Storage SIG。我们正在快速成长，始终欢迎新的贡献者。

Kubernetes 1.31：基于 OCI 工件的只读卷 (Alpha)

Fri, 16 Aug 2024 00:00:00 +0000

Kubernetes 社区正朝着在未来满足更多人工智能（AI）和机器学习（ML）使用场景的方向发展。虽然此项目在过去设计为满足微服务架构，但现在是时候听听最终用户的声音并引入更侧重于 AI/ML 的特性了。

其中一项需求是直接支持与开放容器倡议（OCI）兼容的镜像和工件（称为 OCI 对象）作为原生卷源。这使得用户能够专注于 OCI 标准，且能够使用 OCI 镜像仓库存储和分发任何内容。与此类似的特性让 Kubernetes 项目有机会扩大其使用场景，不再局限于运行特定镜像。

在这一背景下，Kubernetes 社区自豪地展示在 v1.31 中引入的一项新的 Alpha 特性：镜像卷源（KEP-4639）。此特性允许用户在 Pod 中指定一个镜像引用作为卷，并在容器内将其作为卷挂载进行复用：

…
kind: Pod
spec:
 containers:
 - …
 volumeMounts:
 - name: my-volume
 mountPath: /path/to/directory
 volumes:
 - name: my-volume
 image:
 reference: my-image:tag

上述示例的结果是将 my-image:tag 挂载到 Pod 的容器中的 /path/to/directory。

使用场景

此增强特性的目标是在尽可能贴近 kubelet 中现有的容器镜像实现的同时，引入新的 API 接口以支持更广泛的使用场景。

例如，用户可以在 Pod 中的多个容器之间共享一个配置文件，而无需将此文件包含在主镜像中，这样用户就可以将安全风险最小化和并缩减整体镜像大小。用户还可以使用 OCI 镜像打包和分发二进制工件，并直接将它们挂载到 Kubernetes Pod 中，例如用户这样就可以简化其 CI/CD 流水线。

数据科学家、MLOps 工程师或 AI 开发者可以与模型服务器一起在 Pod 中挂载大语言模型权重或机器学习模型权重数据，从而可以更高效地提供服务，且无需将这些模型包含在模型服务器容器镜像中。他们可以将这些模型打包在 OCI 对象中，以利用 OCI 分发机制，还可以确保高效的模型部署。这一新特性允许他们将模型规约/内容与处理它们的可执行文件分开。

另一个使用场景是安全工程师可以使用公共镜像作为恶意软件扫描器，并将私有的（商业的）恶意软件签名挂载到卷中，这样他们就可以加载这些签名且无需制作自己的组合镜像（公共镜像的版权要求可能不允许这样做）。签名数据文件与操作系统或扫描器软件版本无关，总是可以被使用。

但就长期而言，作为此项目的最终用户的你要负责为这一新特性的其他重要使用场景给出规划。 SIG Node 乐于接收与进一步增强此特性以适应更高级的使用场景有关的所有反馈或建议。你可以通过使用 Kubernetes Slack（#sig-node）频道或 SIG Node 邮件列表提供反馈。

详细示例

你需要在 API 服务器以及 kubelet 上启用 Kubernetes Alpha 特性门控 ImageVolume，才能使其正常工作。如果启用了此特性，并且容器运行时支持此特性（如 CRI-O ≥ v1.31），那就可以创建这样一个示例 pod.yaml：

apiVersion: v1
kind: Pod
metadata:
 name: pod
spec:
 containers:
 - name: test
 image: registry.k8s.io/e2e-test-images/echoserver:2.3
 volumeMounts:
 - name: volume
 mountPath: /volume
 volumes:
 - name: volume
 image:
 reference: quay.io/crio/artifact:v1
 pullPolicy: IfNotPresent

此 Pod 使用值为 quay.io/crio/artifact:v1 的 image.reference 声明一个新卷，该字段值引用了一个包含两个文件的 OCI 对象。pullPolicy 的行为与容器镜像相同，允许以下值：

Always：kubelet 总是尝试拉取引用，如果拉取失败，容器创建将失败。
Never：kubelet 从不拉取引用，只使用本地镜像或工件。如果引用不存在，容器创建将失败。
IfNotPresent：kubelet 会在引用已不在磁盘上时进行拉取。如果引用不存在且拉取失败，容器创建将失败。

volumeMounts 字段表示名为 test 的容器应将卷挂载到 /volume 路径下。

如果你现在创建 Pod：

kubectl apply -f pod.yaml

然后通过 exec 进入此 Pod：

kubectl exec -it pod -- sh

那么你就能够查看已挂载的内容：

/ # ls /volume
dir file
/ # cat /volume/file
2
/ # ls /volume/dir
file
/ # cat /volume/dir/file
1

你已经成功地使用 Kubernetes 访问了 OCI 工件！

容器运行时拉取镜像（或工件），将其挂载到容器中，并最终使其可被直接使用。在实现中有很多细节，这些细节与 kubelet 现有的镜像拉取行为密切相关。例如：

如果提供给 reference 的值包含 :latest 标签，pullPolicy 将默认为 Always，而在任何其他情况下，pullPolicy 在未被设置的情况下都默认为 IfNotPresent。
如果 Pod 被删除并重新创建，卷将被重新解析，这意味着在 Pod 重新创建时将可以访问新的远端内容。如果在 Pod 启动期间未能解析或未能拉取镜像，将会容器启动会被阻止，并可能显著增加延迟。如果拉取镜像失败，将使用正常的卷回退机制进行重试，并将在 Pod 的原因和消息中报告出错原因。

拉取 Secret 的组装方式与容器镜像所用的方式相同，也是通过查找节点凭据、服务账户镜像拉取 Secret 和 Pod 规约中的镜像拉取 Secret 来完成。
OCI 对象被挂载到单个目录中，清单层的合并方式与容器镜像相同。
卷以只读（ro）和非可执行文件（noexec）的方式被挂载。

容器的子路径挂载不被支持（spec.containers[*].volumeMounts.subpath）。
字段 spec.securityContext.fsGroupChangePolicy 对这种卷类型没有影响。
如果已启用，此特性也将与 AlwaysPullImages 准入插件一起工作。

感谢你阅读到这篇博客文章的结尾！对于将此特性作为 Kubernetes v1.31 的一部分交付，SIG Node 感到很高兴也很自豪。

作为这篇博客的作者，我想特别感谢所有参与者！你们都很棒，让我们继续开发之旅！

进一步阅读

Kubernetes 1.31：通过 VolumeAttributesClass 修改卷进阶至 Beta

Thu, 15 Aug 2024 00:00:00 +0000

在 Kubernetes 中，卷由两个属性描述：存储类和容量。存储类是卷的不可变属性，而容量可以通过卷调整大小进行动态变更。

这使得使用卷的工作负载的垂直扩缩容变得复杂。虽然云厂商和存储供应商通常提供了一些允许指定注入 IOPS 或吞吐量等 IO 服务质量（性能）参数的卷，并允许在工作负载运行期间调整这些参数，但 Kubernetes 没有提供用来更改这些参数的 API。

我们很高兴地宣布，自 Kubernetes 1.29 起以 Alpha 引入的 VolumeAttributesClass KEP 将在 1.31 中进入 Beta 阶段。这一机制提供了一个通用的、Kubernetes 原生的 API，可用来修改诸如所提供的 IO 能力这类卷参数。

类似于 Kubernetes 中所有新的卷特性，此 API 是通过容器存储接口（CSI）实现的。除了 VolumeAttributesClass 特性门控外，特定于制备器的 CSI 驱动还必须支持此特性在 CSI 一侧的全新的 ModifyVolume API。

有关细节请参阅完整文档。在这里，我们展示了常见的工作流程。

动态修改卷属性

VolumeAttributesClass 是一个集群范围的资源，用来指定特定于制备器的属性。这些属性由集群管理员创建，方式上与存储类相同。例如，你可以为卷创建一系列金、银和铜级别的卷属性类，以区隔不同级别的 IO 能力。

apiVersion: storage.k8s.io/v1alpha1
kind: VolumeAttributesClass
metadata:
 name: silver
driverName: your-csi-driver
parameters:
 provisioned-iops: "500"
 provisioned-throughput: "50MiB/s"
---
apiVersion: storage.k8s.io/v1alpha1
kind: VolumeAttributesClass
metadata:
 name: gold
driverName: your-csi-driver
parameters:
 provisioned-iops: "10000"
 provisioned-throughput: "500MiB/s"

属性类的添加方式与存储类类似。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: test-pv-claim
spec:
 storageClassName: any-storage-class
 volumeAttributesClassName: silver
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 64Gi

与存储类不同，卷属性类可以被更改：

kubectl patch pvc test-pv-claim -p '{"spec": "volumeAttributesClassName": "gold"}'

Kubernetes 将与 CSI 驱动协作来更新卷的属性。 PVC 的状态将跟踪当前和所需的属性类。 PV 资源也将依据新的卷属性类完成更新，卷属性类也会被依据 PV 当前活跃的属性完成设置。

Beta 阶段的限制

作为一个 Beta 特性，仍有一些特性计划在 GA 阶段推出，但尚未实现。最大的限制是配额支持，详见 KEP 和 sig-storage 中的讨论。

有关此特性在 CSI 驱动中的最新支持信息，请参阅 Kubernetes CSI 驱动列表。

Kubernetes v1.31：通过基于缓存的一致性读加速集群性能

Thu, 15 Aug 2024 00:00:00 +0000

Kubernetes 以其强大的容器化应用编排能力而闻名，但随着集群规模扩大，对控制平面的需求可能成为性能瓶颈。其中一个主要挑战是确保从 etcd 数据存储进行强一致性读，这通常需要资源密集型仲裁读取操作。

今天，Kubernetes 社区很高兴地宣布一个重大改进：基于缓存的一致性读，已在 Kubernetes v1.31 中晋升至 Beta 阶段。

为什么一致性读如此重要

一致性读是确保 Kubernetes 组件准确了解最新集群状态的关键。保证一致性读对于保持 Kubernetes 操作准确性和可靠性至关重要，使组件能够根据最新信息做出明智决策。在大型集群中，数据的获取和处理往往会成为性能瓶颈，特别是那些需要过滤结果的请求。

虽然 Kubernetes 可以直接在 etcd 中按命名空间过滤数据，但如果按标签或字段选择器过滤，则需要从 etcd 获取整个数据集，然后由 Kubernetes API 服务器在内存中执行过滤操作。这对 Kubelet 等组件的影响尤为显著，因为 Kubelet 现在仅需列出调度到其节点的 Pod，而之前却需要 API 服务器和 etcd 处理集群中所有的 Pod。

突破：自信地缓存

Kubernetes 长期以来一直使用监视缓存来优化读取操作。监视缓存保存集群状态的快照，并通过对 etcd 的监视获取更新。然而，直到现在,它无法直接支持一致性读，因为没有机制保证缓存是最新的。

基于缓存的一致性读 特性通过使用 etcd 的进度通知机制来解决这一问题。这些通知会向监视缓存说明其数据与 etcd 相比的新旧状态。当发出一致性读请求时，系统会首先检查监视缓存是否为最新状态。

如果缓存未更新到最新状态，系统会通过查询 etcd 的进度通知，直到确认缓存已经足够新。一旦缓存就绪，读取操作就可以直接从缓存中高效地获取数据，这可以显著提升性能，尤其是在需要从 etcd 获取大量数据的场景下。这种方式支持通过缓存处理数据过滤请求，仅需从 etcd 读取少量的元数据。

重要提示： 要享受此特性带来的好处，你的 Kubernetes 集群需运行 etcd 版本 3.4.31+ 或 3.5.13+。对于较早版本的 Etcd，Kubernetes 将自动回退为直接从 etcd 提供一致性读。

你将注意到的性能提升

这个看似简单的改动，对 Kubernetes 的性能和可扩展性有着深远影响:

降低 etcd 负载： Kubernetes v1.31 可以将部分工作从 etcd 分载出去，为其他关键操作释放资源。
更低的延迟： 从缓存读取数据的速度显著快于从 etcd 获取并处理数据。这使组件的响应速度更快，提升了集群整体的响应能力。
增强的可扩展性： 拥有数千个节点和 Pod 的大型集群将获得最显著的性能增益，因为 etcd 负载的降低使得控制平面可以在不牺牲性能的情况下处理更多请求。

5 千节点扩缩容测试结果： 在最近针对 5,000 节点集群的扩缩容测试中，启用基于缓存的一致性读带来了显著提升：

kube-apiserver CPU 使用率降低 30%
etcd CPU 使用率降低 25%
第 99 百分位的 Pod 列表请求延迟出现了高至 3 倍的减少（从 5 秒降至 1.5 秒）

下一步是什么？

随着基于缓存的一致性读特性晋升至 Beta 版，该特性已默认启用，为所有使用受支持 etcd 版本的 Kubernetes 用户提供了无缝的性能提升。

我们的探索并未止步于此。Kubernetes 社区正积极研究在监视缓存中加入分页支持，未来有望带来更多性能优化。

开始使用

升级到 Kubernetes v1.31 并确保使用 etcd 版本 3.4.31+ 或 3.5.13+，是体验基于缓存的一致性读优势的最简单方法。如果有任何问题或反馈，不要犹豫，随时联系 Kubernetes 社区。

请让我们知道基于缓存的一致性读如何改善了你的 Kubernetes 体验！

特别感谢 @ah8ad3 和 @p0lyn0mial 对这一特性做出的贡献！

Kubernetes 1.31：对 cgroup v1 的支持转为维护模式

Wed, 14 Aug 2024 00:00:00 +0000

随着 Kubernetes 不断发展，为了适应容器编排全景图的变化，社区决定在 v1.31 中将对 cgroup v1 的支持转为维护模式。这一转变与行业更广泛地向 cgroup v2 的迁移保持一致，后者的功能更强，包括可扩展性和更加一致的接口。在我们深入探讨对 Kubernetes 的影响之前，先回顾一下 cgroup 的概念及其在 Linux 中的重要意义。

理解 cgroup

控制组（Control Group）也称为 cgroup，是 Linux 内核的一项特性，允许在进程之间分配、划分优先级、拒绝和管理系统资源（如 CPU、内存、磁盘 I/O 和网络带宽）。这一功能对于维护系统性能至关重要，确保没有单个进程能够垄断系统资源，这在多租户环境中尤其重要。

cgroup 有两个版本： v1 和 v2。虽然 cgroup v1 提供了足够的资源管理能力，但其局限性促使了 cgroup v2 的开发。 cgroup v2 在更好的资源控制特性之外提供了更统一且更一致的接口。

Kubernetes 中的 cgroup

对于 Linux 节点，Kubernetes 在管理和隔离 Pod 中运行的容器所消耗的资源方面高度依赖 cgroup。 Kubernetes 中的每个容器都放在其自己的 cgroup 中，这使得 Kubernetes 能够强制执行资源限制、监控使用情况并确保所有容器之间的资源公平分配。

Kubernetes 如何使用 cgroup

资源分配: 确保容器不超过其分配的 CPU 和内存限制。
隔离: 将容器相互隔离，防止资源争用。
监控: 跟踪每个容器的资源使用情况，以提供洞察数据和指标。

向 cgroup v2 过渡

Linux 社区一直在聚焦于为 cgroup v2 提供新特性和各项改进。主要的 Linux 发行版和像 systemd 这样的项目正在过渡到 cgroup v2。使用 cgroup v2 相较于使用 cgroup v1 提供了多个好处，例如统一的层次结构、改进的接口、更好的资源控制，以及 cgroup 感知的 OOM 杀手、非 root 支持等。

鉴于这些优势，Kubernetes 也正在更全面地转向 cgroup v2。然而，这一过渡需要谨慎处理，以避免干扰现有的工作负载，并为用户提供平滑的迁移路径。

对 cgroup v1 的支持转入维护模式

维护模式意味着什么？

当 cgroup v1 在 Kubernetes 中被置于维护模式时，这意味着：

特性冻结：不会再向 cgroup v1 添加新特性。
安全修复：仍将提供关键的安全修复。
尽力而为的 Bug 修复：在可行的情况下可能会修复重大 Bug，但某些问题可能保持未解决。

为什么要转入维护模式？

转入维护模式的原因是为了与更广泛的生态体系保持一致，也为了鼓励采用 cgroup v2，后者提供了更好的性能、安全性和可用性。通过将 cgroup v1 转入维护模式，Kubernetes 可以专注于增强对 cgroup v2 的支持，并确保其满足现代工作负载的需求。需要注意的是，维护模式并不意味着弃用；cgroup v1 将继续按需进行关键的安全修复和重大 Bug 修复。

这对集群管理员意味着什么

目前强烈鼓励那些依赖 cgroup v1 的用户做好向 cgroup v2 过渡的计划。这一过渡涉及：

升级系统：确保底层操作系统和容器运行时支持 cgroup v2。
测试工作负载：验证工作负载和应用程序在 cgroup v2 下正常工作。

进一步阅读

Kubernetes v1.31: PersistentVolume 的最后阶段转换时间进阶到 GA

Wed, 14 Aug 2024 00:00:00 +0000

现在宣布 PersistentVolume 的 lastTransitionTime 状态字段在 Kubernetes v1.31 版本进阶至正式发布（GA）！

Kubernetes SIG Storage 团队很高兴地宣布，"PersistentVolumeLastPhaseTransitionTime" 特性自 Kubernetes v1.28 作为 Alpha 版本引入以来，现已进阶至正式发布（GA），并正式成为 Kubernetes v1.31 版本的一部分。该功能帮助 Kubernetes 用户增强对 PersistentVolume 在不同阶段之间转换的理解，从而实现更高效和更明智的资源管理。

在 v1.31 集群中，你可以默认每个 PersistentVolume 对象都包含 .status.lastTransitionTime 字段，该字段记录存储卷最近一次发生阶段转换时的时间戳。该更改不会立刻生效，而是在升级到 Kubernetes v1.31 后，当 PersistentVolume 发生更新并首次在（Pending、Bound 或 Released）这几个阶段之间进行转换时，才会填充该字段。

有什么变化？

更新 PersistentVolume 对象的 API 策略已经被修改，当存储卷转换阶段时会自动填充当前时间戳到 .status.lastTransitionTime 字段。如果需要，用户可以手动设置该字段，但当 PersistentVolume 再次转换阶段时，该字段会被新时间戳覆盖。

想了解更多信息，可以查阅 Kubernetes 文档中的阶段转换时间戳。你还可以阅读此前的博客文章，该文章介绍了此特性在 v1.28 版本中作为 Alpha 版本发布的情况。

要提供反馈，请加入我们的 Kubernetes 存储特别兴趣小组 (SIG) 或参与公共 Slack 频道上的讨论。

Kubernetes v1.31: Elli

Tue, 13 Aug 2024 00:00:00 +0000

编辑: Matteo Bianchi, Yigit Demirbas, Abigail McCarthy, Edith Puclla, Rashan Smith

Kubernetes v1.31：Elli 宣布发布！

与之前的版本类似，Kubernetes v1.31 的发布中引入了新的稳定版、Beta 版和 Alpha 特性功能。持续提供高质量的版本彰显了我们开发周期的强劲实力以及社区的大力支持。此版本包含 45 项增强功能。在这些增强功能中，11 项已升级到稳定版，22 项正在进入 Beta 版，12 项已升级到 Alpha 版。

发布主题和 logo

Kubernetes v1.31 的发布主题是 "Elli"。

Kubernetes v1.31 的 Elli 是一只可爱欢快的小狗，戴着一顶漂亮的水手帽，这是对庞大而多样化的 Kubernetes 贡献者家族的一个俏皮致意。

Kubernetes v1.31 标志着该项目成功庆祝其诞生十周年后的首次发布。自诞生以来，Kubernetes 已经走过了漫长的道路，并且每次发布都在朝着令人兴奋的新方向前进。十年后，回顾无数 Kubernetes 贡献者为实现这一目标所付出的努力、奉献、技能、智慧和辛勤工作，令人敬畏。

还有，尽管运营项目需要付出巨大的努力，仍然有大量的人不断以热情、微笑和自豪感出现，为社区做出贡献并成为其中的一员。我们从新老贡献者那里看到的这种"精神"是一个充满活力的社区的标志，我们可以称之为"欢乐"的社区。

Kubernetes v1.31 的 Elli 就是为了庆祝这种美好的精神!让我们为 Kubernetes 的下一个十年干杯!

晋级为稳定版的功能亮点

以下是 v1.31 发布后晋级为稳定版的部分改进。

AppArmor 支持现已稳定

Kubernetes 对 AppArmor 的支持现已正式发布。通过在容器的 securityContext 中设置 appArmorProfile.type 字段，可以使用 AppArmor 保护您的容器。请注意，在 Kubernetes v1.30 之前，AppArmor 是通过注解控制的；从 v1.30 开始，它是通过字段控制的。建议您停止使用注解，开始使用 appArmorProfile.type 字段。

要了解更多信息，请阅读 AppArmor 教程。这项工作是作为 KEP #24 的一部分由 SIG Node 完成的。

改进 kube-proxy 的入站连接可靠性

kube-proxy 改进的入站连接可靠性在 v1.31 中已稳定。 Kubernetes 中负载均衡器的一个常见问题是为避免流量丢失而在不同组件之间进行同步的机制。此特性在 kube-proxy 中实现了一种机制，用于负载均衡器对 type: LoadBalancer 和 externalTrafficPolicy: Cluster 服务所公开的、进入终止进程的 Node 进行连接排空，并为云提供商和 Kubernetes 负载均衡器实现建立了一些最佳实践。

要使用此特性，kube-proxy 需要在集群上作为默认服务代理运行，并且负载均衡器需要支持连接排空。使用此特性不需要进行特定的更改，它自 v1.30 以来在 kube-proxy 中默认启用，并在 v1.31 中晋级为稳定版。

有关此特性的更多详细信息，请访问虚拟 IP 和服务代理文档页面。

这项工作是作为 KEP #3836 的一部分由 SIG Network 完成的。

持久卷最近阶段转换时间

持久卷最近阶段转换时间功能在 v1.31 中晋级为正式版（GA）。此特性添加了一个 PersistentVolumeStatus 字段，用于保存 PersistentVolume 最近转换到不同阶段的时间戳。启用此特性后，每个 PersistentVolume 对象将有一个新字段 .status.lastTransitionTime 保存卷最近转换阶段的时间戳。这种变化并不是立即的；新字段将在 PersistentVolume 更新并在升级到 Kubernetes v1.31 后首次在各阶段（Pending、Bound 或 Released）之间转换时填充。这允许您测量 PersistentVolume 从 Pending 移动到 Bound 之间的时间。这对于提供指标和 SLO 也很有用。

有关此特性的更多详细信息，请访问 PersistentVolume 文档页面。

这项工作是作为 KEP #3762 的一部分由 SIG Storage 完成的。

晋级为 Beta 版的功能亮点

以下是 v1.31 发布后晋级为 Beta 版的部分改进。

kube-proxy 的 nftables 后端

nftables 后端在 v1.31 中晋级为 Beta 版，由 NFTablesProxyMode 特性门控控制，现在默认启用。

nftables API 是 iptables API 的继任者，旨在提供比 iptables 更好的性能和可扩展性。 nftables 代理模式能够比 iptables 模式更快、更高效地处理服务端点的变化，并且在内核中也能更高效地处理数据包（尽管这只有在拥有数万个服务的集群中才会显著）。

截至 Kubernetes v1.31，nftables 模式仍相对较新，可能与某些网络插件不兼容；请查阅您的网络插件文档。此代理模式仅在 Linux 节点上可用，并且需要内核 5.13 或更高版本。在迁移之前，请注意某些功能，特别是与 NodePort 服务相关的功能，在 nftables 模式下的实现方式与 iptables 模式不完全相同。查看迁移指南以了解是否需要覆盖默认配置。

这项工作是作为 KEP #3866 的一部分由 SIG Network 完成的。

PersistentVolumes 回收策略的变更

始终遵循 PersistentVolume 回收策略这一特性在 Kubernetes v1.31 中晋级为 Beta 版。这项增强确保即使在所关联的 PersistentVolumeClaim (PVC) 被删除后，PersistentVolume (PV) 回收策略也会被遵循，从而防止卷的泄漏。

在此特性之前，与 PV 相关联的回收策略可能在特定条件下被忽视，这取决于 PV 或 PVC 是否先被删除。因此，即使回收策略设置为 "Delete"，外部基础设施中相应的存储资源也可能不会被删除。这导致了潜在的不一致性和资源泄漏。

随着这项功能的引入，Kubernetes 现在保证 "Delete" 回收策略将被执行，确保底层存储对象从后端基础设施中删除，无论 PV 和 PVC 的删除顺序如何。

这项工作是作为 KEP #2644 的一部分由 SIG Storage 完成的。

绑定服务账户令牌的改进

ServiceAccountTokenNodeBinding 功能在 v1.31 中晋级为 Beta 版。此特性允许请求仅绑定到节点而不是 Pod 的令牌，在令牌中包含节点信息的声明，并在使用令牌时验证节点的存在。有关更多信息，请阅读绑定服务账户令牌文档。

这项工作是作为 KEP #4193 的一部分由 SIG Auth 完成的。

多个 Service CIDR

支持具有多个服务 CIDR 的集群在 v1.31 中晋级为 Beta 版(默认禁用)。

Kubernetes 集群中有多个组件消耗 IP 地址: Node、Pod 和 Service。 Node 和 Pod 的 IP 范围可以动态更改，因为它们分别取决于基础设施或网络插件。然而，Service IP 范围是在集群创建期间作为 kube-apiserver 中的硬编码标志定义的。 IP 耗尽一直是长期存在或大型集群的问题，因为管理员需要扩展、缩小甚至完全替换分配的服务 CIDR 范围。这些操作从未得到原生支持，并且是通过复杂和精细的维护操作执行的，经常导致集群无法正常服务。这个新特性允许用户和集群管理员以零中断时间动态修改服务 CIDR 范围。

有关此特性的更多详细信息，请访问虚拟 IP 和服务代理文档页面。

这项工作是作为 KEP #1880 的一部分由 SIG Network 完成的。

Service 的流量分配

Service 的流量分配在 v1.31 中晋级为 Beta 版，并默认启用。

为实现 Service 联网的最佳用户体验和流量工程能力，经过多次迭代后，SIG Networking 在服务规约中实现了 trafficDistribution 字段，作为底层实现在做出路由决策时考虑的指导原则。

有关此特性的更多详细信息，请阅读 1.30 发布博客或访问 Service 文档页面。

这项工作是作为 KEP #4444 的一部分由 SIG Network 完成的。

Kubernetes VolumeAttributesClass ModifyVolume

VolumeAttributesClass API 在 v1.31 中晋级为 Beta 版。 VolumeAttributesClass 提供了一个通用的、Kubernetes 原生的 API，用于修改动态卷参数，如所提供的 IO 能力。这允许工作负载在线垂直扩展其卷，以平衡成本和性能（如果提供商支持）。该功能自 Kubernetes 1.29 以来一直处于 Alpha 状态。

这项工作是作为 KEP #3751 的一部分完成的，由 SIG Storage 领导。

Alpha 版的新功能

以下是 v1.31 发布后晋级为 Alpha 版的部分改进。

用于更好管理加速器和其他硬件的新 DRA API

Kubernetes v1.31 带来了更新的动态资源分配（DRA）API 和设计。此次更新的主要焦点是结构化参数，因为它们使资源信息和请求对 Kubernetes 和客户端透明，并能够实现集群自动扩缩容等功能。 kubelet 中的 DRA 支持已更新，使得 kubelet 和控制平面之间的版本偏差成为可能。通过结构化参数，调度器在调度 Pod 时分配 ResourceClaims。通过现在称为"经典 DRA"的方式，仍然支持由 DRA 驱动程序控制器进行分配。

从 Kubernetes v1.31 开始,经典 DRA 有一个单独的特性门控名为 DRAControlPlaneController，您需要显式启用它。通过这样的控制平面控制器，DRA 驱动程序可以实现尚未通过结构化参数支持的分配策略。

这项工作是作为 KEP #3063 的一部分由 SIG Node 完成的。

对镜像卷的支持

Kubernetes 社区正在朝着在未来满足更多人工智能(AI)和机器学习(ML)用例的方向发展。

满足这些用例的要求之一是直接将开放容器倡议(OCI)兼容的镜像和工件(称为 OCI 对象)作为原生卷源支持。这允许用户专注于 OCI 标准，并使他们能够使用 OCI 注册表存储和分发任何内容。

鉴于此，v1.31 添加了一个新的 Alpha 特性，允许在 Pod 中使用 OCI 镜像作为卷。此特性允许用户在 pod 中指定镜像引用作为卷，同时在容器内重用它作为卷挂载。您需要启用 ImageVolume 特性门控才能尝试此特性。

这项工作是作为 KEP #4639 的一部分由 SIG Node 和 SIG Storage 完成的。

通过 Pod 状态暴露设备健康信息

通过 Pod 状态暴露设备健康信息作为新的 Alpha 特性添加到 v1.31 中，默认被禁用。

在 Kubernetes v1.31 之前，了解 Pod 是否与故障设备关联的方法是使用 PodResources API。

通过启用此特性，字段 allocatedResourcesStatus 将添加到每个容器状态中，在每个 Pod 的 .status 内。 allocatedResourcesStatus 字段报告分配给容器的各个设备的健康信息。

这项工作是作为 KEP #4680 的一部分由 SIG Node 完成的。

基于选择算符的细粒度鉴权

此特性允许 Webhook 鉴权组件和未来（但目前尚未设计）的树内鉴权组件允许 list 和 watch 请求，前提是这些请求使用标签和/或字段选择算符。例如，现在鉴权组件可以表达：此用户不能列出所有 Pod，但可以列举所有 .spec.nodeName 匹配某个特定值的 Pod。或者允许用户监视命名空间中所有未标记为 confidential: true 的 Secret。结合 CRD 字段选择器（在 v1.31 中也晋级为 Beta 版），可以编写更安全的节点级别扩展。

这项工作是作为 KEP #4601 的一部分由 SIG Auth 完成的。

对匿名 API 访问的限制

通过启用特性门控 AnonymousAuthConfigurableEndpoints，用户现在可以使用身份认证配置文件来配置可以通过匿名请求访问的端点。这允许用户保护自己免受 RBAC 错误配置的影响；错误的配置可能会给匿名用户提供对集群的更多访问权限。

这项工作是作为 KEP #4633 的一部分由 SIG Auth 完成的。

1.31 中的晋级、弃用和移除

晋级为稳定版

以下列出了所有晋级为稳定版（也称为 正式可用 ）的功能。有关包括新功能和从 Alpha 晋级到 Beta 的完整列表，请参阅发行说明。

此版本包括总共 11 项晋级为稳定版的增强:

弃用和移除

随着 Kubernetes 的发展和成熟，某些特性可能会被弃用、移除或替换为更好的特性，以确保项目的整体健康。有关此过程的更多详细信息，请参阅 Kubernetes 弃用和移除策略。

Cgroup v1 进入维护模式

随着 Kubernetes 继续发展并适应容器编排不断变化的格局，社区决定在 v1.31 中将 cgroup v1 支持移入维护模式。这一转变与行业中普遍向 cgroup v2 迁移的趋势一致，提供了改进的功能、可扩展性和更一致的接口。 Kubernetes 维护模式意味着不会向 cgroup v1 支持添加新功能。社区仍将提供关键的安全修复，但是，错误修复现在是尽力而为。这意味着如果可行，可能会修复重大错误，但某些问题可能保持未解决状态。

建议您尽快开始切换到使用 cgroup v2。这种转变取决于您的架构，包括确保底层操作系统和容器运行时支持 cgroup v2，以及测试工作负载以验证工作负载和应用程序在 cgroup v2 下是否正常运行。

如果遇到任何问题,请通过提交 issue 进行报告。

这项工作是作为 KEP #4569 的一部分由 SIG Node 完成的。

关于 SHA-1 签名支持的说明

在 go1.18（2022 年 3 月发布）中，crypto/x509 库开始拒绝使用 SHA-1 哈希函数签名的证书。虽然 SHA-1 已被确定为不安全，并且公共信任的证书颁发机构自 2015 年以来就不再颁发 SHA-1 证书，但在 Kubernetes 语境中可能仍然存在用户提供的证书通过私有机构使用 SHA-1 哈希函数签名的情况，这些证书用于聚合 API 服务器或 Webhook。如果您依赖基于 SHA-1 的证书，必须通过在环境变量中设置 GODEBUG=x509sha1=1 来明确选择重新启用其支持。

鉴于 Go 的 GODEBUG 兼容性策略，x509sha1 GODEBUG 和对 SHA-1 证书的支持将在 go1.24 中完全消失，而 go1.24 将在 2025 年上半年发布。如果您依赖 SHA-1 证书,请开始迁移离开它们。

请查看 Kubernetes issue #125689 以了解有关 SHA-1 支持消失的时间线、Kubernetes 发布计划何时采用 go1.24，以及如何通过指标和审计日志检测 SHA-1 证书使用情况的更多详细信息。

弃用 Node 节点的 `status.nodeInfo.kubeProxyVersion` 字段 (KEP 4004)

节点的 .status.nodeInfo.kubeProxyVersion 字段在 Kubernetes v1.31 中已被弃用, 并将在以后的版本中删除。它被弃用是因为这个字段的值不准确（现在也不准确）。这个字段是由 kubelet 设置的，而 kubelet 没有关于 kube-proxy 版本或 kube-proxy 是否正在运行的可靠信息。

DisableNodeKubeProxyVersion 特性门控将在 v1.31 中默认设置为 true，kubelet 将不再尝试为其关联的节点设置 .status.kubeProxyVersion 字段。

移除所有树内云提供商集成

正如之前的文章中强调的那样，作为 v1.31 发布的一部分，最后剩余的树内云平台集成支持已被移除。这并不意味着您不能与云平台集成，但是您现在必须使用推荐的方法使用外部集成。一些集成是 Kubernetes 项目的一部分，而其他则是第三方软件。

这一里程碑标志着所有云提供商集成从 Kubernetes 核心外部化过程的完成（KEP-2395），这个过程始于 Kubernetes v1.26。这一变化有助于 Kubernetes 更接近成为一个真正供应商中立的平台。

有关云提供商集成的更多详细信息，请阅读我们的 v1.29 云提供商集成功能博客。有关树内代码移除的额外背景，我们邀请您查看（v1.29 弃用博客）。

后者的博客还包含了需要迁移到 v1.29 及更高版本的用户的有用信息。

移除树内供应商特性门控

在 Kubernetes v1.31 中，以下 Alpha 特性门控 InTreePluginAWSUnregister、InTreePluginAzureDiskUnregister、 InTreePluginAzureFileUnregister、InTreePluginGCEUnregister、InTreePluginOpenStackUnregister 和 InTreePluginvSphereUnregister 已被移除。这些特性门控的引入是为了便于测试从代码库中移除树内卷插件的场景，而无需实际移除它们。由于 Kubernetes 1.30 已弃用这些树内卷插件，这些特性门控变得多余，不再有用。唯一仍然存在的 CSI 迁移门控是 InTreePluginPortworxUnregister，它将保持 Alpha 状态，直到 Portworx 的 CSI 迁移完成，其树内卷插件准备好被移除。

移除 kubelet 的 `--keep-terminated-pod-volumes` 命令行标志

作为 v1.31 版本的一部分，已移除 kubelet 标志 --keep-terminated-pod-volumes。该标志于 2017 年被弃用。

您可以在拉取请求 #122082 中找到更多详细信息。

移除 CephFS 卷插件

本次发布中移除了 CephFS 卷插件，cephfs 卷类型变为不可用。

建议您改用 CephFS CSI 驱动作为第三方存储驱动程序。如果您在将集群版本升级到 v1.31 之前使用了 CephFS 卷插件，则必须重新部署应用程序以使用新的驱动程序。

CephFS 卷插件在 v1.28 中正式标记为废弃。

移除 Ceph RBD 卷插件

v1.31 版本移除了 Ceph RBD volume plugin 及其 CSI 迁移支持，使 rbd 卷类型变为不可用。

建议您在集群中改用 RBD CSI driver。如果您在将集群版本升级到 v1.31 之前使用了 Ceph RBD 卷插件，则必须重新部署应用程序以使用新的驱动程序。

Ceph RBD 卷插件在 v1.28 中正式标记为废弃。

废弃 kube-scheduler 中的非 CSI 卷限制插件

v1.31 版本将废弃所有非 CSI 卷限制调度器插件，并将从默认插件中移除一些已废弃的插件，包括：

AzureDiskLimits
CinderLimits
EBSLimits
GCEPDLimits

建议您改用 NodeVolumeLimits 插件，因为自从这些卷类型迁移到 CSI 后，该插件可以处理与已移除插件相同的功能。如果您在调度器配置中明确使用了已废弃的插件，请将它们替换为 NodeVolumeLimits 插件。 AzureDiskLimits、CinderLimits、EBSLimits 和 GCEPDLimits 插件将在未来的版本中被移除。

这些插件自 Kubernetes v1.14 以来已被废弃，将从默认调度器插件列表中移除。

发布说明和所需的升级操作

请在我们的发布说明中查看 Kubernetes v1.31 版本的完整详细信息。

启用 `SchedulerQueueingHints` 时，调度器现在使用 QueueingHint

社区为调度器添加了支持，以便在启用 SchedulerQueueingHints 功能门控时，开始使用为 Pod/Updated 事件注册的 QueueingHint，以确定对先前不可调度的 Pod 的更新是否使其变得可调度。以前，当不可调度的 Pod 被更新时，调度器总是将 Pod 放回队列（activeQ / backoffQ）。然而，并非所有对 Pod 的更新都会使 Pod 变得可调度，特别是考虑到现在许多调度约束是不可变更的。在新的行为下，一旦不可调度的 Pod 被更新，调度队列会通过 QueueingHint 检查该更新是否可能使 Pod 变得可调度，并且只有当至少一个 QueueingHint 返回 Queue 时，才将它们重新排队到 activeQ 或 backoffQ。

自定义调度器插件开发者需要采取的操作：如果插件的拒绝可以通过更新未调度的 Pod 本身来解决，那么插件必须为 Pod/Update 事件实现 QueueingHint。例如：假设您开发了一个自定义插件，该插件拒绝具有 schedulable=false 标签的 Pod。鉴于带有 schedulable=false 标签的 Pod 在移除该标签后将变得可调度，这个插件将为 Pod/Update 事件实现 QueueingHint，当在未调度的 Pod 中进行此类标签更改时返回 Queue。您可以在 pull request #122234 中找到更多详细信息。

移除 kubelet --keep-terminated-pod-volumes 命令行标志

作为 v1.31 版本的一部分，已移除 kubelet 标志 --keep-terminated-pod-volumes。该标志于 2017 年被弃用。您可以在拉取请求 #122082 中找到更多详细信息。

可用性

Kubernetes v1.31 可在 GitHub 或 Kubernetes 下载页面上下载。

要开始使用 Kubernetes，请查看这些交互式教程或使用 minikube 运行本地 Kubernetes 集群。您还可以使用 kubeadm 轻松安装 v1.31。

发布团队

Kubernetes 的实现离不开社区的支持、投入和辛勤工作。每个发布团队由致力于构建 Kubernetes 发布版本各个部分的专门社区志愿者组成。这需要来自我们社区各个角落的人员的专业技能，从代码本身到文档和项目管理。

我们要感谢整个发布团队为向我们的社区交付 Kubernetes v1.31 版本所付出的时间和努力。发布团队的成员从首次参与的影子成员到经历多个发布周期的回归团队负责人不等。特别感谢我们的发布负责人 Angelos Kolaitis，他支持我们完成了一个成功的发布周期，为我们发声，确保我们都能以最佳方式贡献，并挑战我们改进发布过程。

项目速度

CNCF K8s DevStats 项目汇总了许多与 Kubernetes 及各个子项目速度相关的有趣数据点。这包括从个人贡献到贡献公司数量的所有内容，展示了进化这个生态系统所投入的深度和广度。

在为期 14 周的 v1.31 发布周期（5 月 7 日至 8 月 13 日）中，我们看到来自 113 家不同公司和 528 个个人对 Kubernetes 的贡献。

在整个云原生生态系统中，我们有 379 家公司，共计 2268 名贡献者 - 这意味着相比上一个发布周期，个人贡献者数量惊人地增加了 63%！

数据来源：

贡献指的是当某人进行提交、代码审查、评论、创建问题或 PR、审查 PR（包括博客和文档）或对问题和 PR 进行评论。

如果您有兴趣贡献，请访问此页面开始。

查看 DevStats 以了解更多关于 Kubernetes 项目和社区整体速度的信息。

活动更新

探索 2024 年 8 月至 11 月即将举行的 Kubernetes 和云原生活动，包括 KubeCon、KCD 和其他全球知名会议。保持了解并参与 Kubernetes 社区。

2024 年 8 月

KubeCon + CloudNativeCon + 开源峰会中国 2024：2024 年 8 月 21-23 日 | 中国香港
KubeDay Japan：2024 年 8 月 27 日 | 东京，日本

2024 年 9 月

KCD 拉合尔 - 巴基斯坦 2024: 2024 年 9 月 1 日 | 拉合尔，巴基斯坦
KuberTENes 生日庆典斯德哥尔摩: 2024 年 9 月 5 日 | 斯德哥尔摩，瑞典
KCD Sydney ’24: 2024 年 9 月 5-6 日 | 悉尼，澳大利亚
KCD Washington DC 2024: 2024 年 9 月 24 日 | 华盛顿特区，美国
KCD Porto 2024: 2024 年 9 月 27-28 日 | 波尔图，葡萄牙

2024 年 10 月

KCD Austria 2024: 2024 年 10 月 8-10 日 | 维也纳，奥地利
KubeDay Australia: 2024 年 10 月 15 日 | 墨尔本，澳大利亚
KCD UK - London 2024: 2024 年 10 月 22-23 日 | 伦敦，英国

2024 年 11 月

KubeCon + CloudNativeCon North America 2024: 2024 年 11 月 12-15 日 | 盐湖城，美国
Kubernetes on EDGE Day North America: 2024 年 11 月 12 日 | 盐湖城，美国

即将举行的发布网络研讨会

加入 Kubernetes v1.31 发布团队成员，于 2024 年 9 月 12 日星期四太平洋时间上午 10 点了解此版本的主要特性，以及废弃和移除的内容，以帮助规划升级。有关更多信息和注册，请访问 CNCF 在线项目网站上的活动页面。

参与其中

参与 Kubernetes 的最简单方式是加入与您兴趣相符的众多特殊兴趣小组（SIG）之一。您有什么想向 Kubernetes 社区广播的内容吗？在我们的每周社区会议上分享您的声音，并通过以下渠道。感谢您持续的反馈和支持。

在 X 上关注我们 @Kubernetesio 获取最新更新
在 Discuss 上加入社区讨论
在 Slack 上加入社区
在 Stack Overflow 上发布问题（或回答问题）
分享您的 Kubernetes 故事
在博客上阅读更多关于 Kubernetes 的最新动态
了解更多关于 Kubernetes 发布团队的信息

向 Client-Go 引入特性门控：增强灵活性和控制力

Mon, 12 Aug 2024 00:00:00 +0000

Kubernetes 组件使用称为“特性门控（Feature Gates）”的开关来管理添加新特性的风险，特性门控机制使特性能够通过 Alpha、Beta 和 GA 阶段逐步升级。

Kubernetes 组件（例如 kube-controller-manager 和 kube-scheduler）使用 client-go 库与 API 交互，整个 Kubernetes 生态系统使用相同的库来构建控制器、工具、webhook 等。 client-go 现在包含自己的特性门控机制，使开发人员和集群管理员能够更好地控制如何使用客户端特性。

要了解有关 Kubernetes 中特性门控的更多信息，请参阅特性门控。

动机

在没有 client-go 特性门控的情况下，每个新特性都以自己的方式（如果有的话）将特性可用性与特性的启用分开。某些特性可通过更新到较新版本的 client-go 来启用，其他特性则需要在每个使用它们的程序中进行主动配置，其中一些可在运行时使用环境变量进行配置。使用 kube-apiserver 公开的特性门控功能时，有时需要客户端回退机制，以保持与由于版本新旧或配置不同而不支持该特性服务器的兼容性。如果在这些回退机制中发现问题，则缓解措施需要更新到 client-go 的固定版本或回滚。

这些方法都无法很好地支持为某些（但不是全部）使用 client-go 的程序默认启用特性。默认设置的更改不会首先仅为单个组件启用新特性，而是会立即影响所有 Kubernetes 组件的默认设置，从而大大扩大影响半径。

client-go 中的特性门控

为了应对这些挑战，大量的 client-go 特性将使用新的特性门控机制来逐步引入。这一机制将允许开发人员和用户以类似 Kubernetes 组件特性门控的管理方式启用或禁用特性。

作为一种开箱即用的能力，用户只需使用最新版本的 client-go。这种设计带来多种好处。

对于使用通过 client-go 构建的软件的用户：

早期采用者可以针对各个进程分别启用默认关闭的 client-go 特性。
无需构建新的二进制文件即可禁用行为不当的特性。
所有已知的 client-go 特性门控的状态都会被记录到日志中，允许用户检查。

对于开发使用 client-go 构建的软件的人员：

默认情况下，client-go 特性门控覆盖是从环境变量中读取的。如果在 client-go 特性中发现错误，用户将能够禁用它，而无需等待新版本发布。
开发人员可以替换程序中基于默认环境变量的覆盖值以更改默认值、从其他源读取覆盖值或完全禁用运行时覆盖值。 Kubernetes 组件使用这种可定制性将 client-go 特性门控与现有的 --feature-gates 命令行标志、特性启用指标和日志记录集成在一起。

覆盖 client-go 特性门控

注意：这描述了在运行时覆盖 client-go 特性门控的默认方法，它可以由特定程序的开发人员禁用或自定义。在 Kubernetes 组件中，client-go 特性门控覆盖由 --feature-gates 标志控制。

可以通过设置以 KUBE_FEATURE 为前缀的环境变量来启用或禁用 client-go 的特性。例如，要启用名为 MyFeature 的特性，请按如下方式设置环境变量：

KUBE_FEATURE_MyFeature=true

要禁用特性，可将环境变量设置为 false：

KUBE_FEATURE_MyFeature=false

注意：在某些操作系统上，环境变量区分大小写。因此，KUBE_FEATURE_MyFeature 和 KUBE_FEATURE_MYFEATURE 将被视为两个不同的变量。

自定义 client-go 特性门控

基于环境变量的默认特性门控覆盖机制足以满足 Kubernetes 生态系统中许多程序的需求，无需特殊集成。需要不同行为的程序可以用自己的自定义特性门控提供程序替换它。这允许程序执行诸如强制禁用已知运行不良的特性、直接从远程配置服务读取特性门控或通过命令行选项接受特性门控覆盖等操作。

Kubernetes 组件将 client-go 的默认特性门控提供程序替换为现有 Kubernetes 特性门控提供程序的转换层。在所有实际应用场合中，client-go 特性门控与其他 Kubernetes 特性门控的处理方式相同：它们连接到 --feature-gates 命令行标志，包含在特性启用指标中，并在启动时记录。

要替换默认的特性门控提供程序，请实现 Gates 接口并在包初始化时调用 ReplaceFeatureGates，如以下简单示例所示：

import (
 "k8s.io/client-go/features"
)

type AlwaysEnabledGates struct{}

func (AlwaysEnabledGates) Enabled(features.Feature) bool {
 return true
}

func init() {
 features.ReplaceFeatureGates(AlwaysEnabledGates{})
}

需要定义的 client-go 特性完整列表的实现可以通过实现 Registry 接口并调用 AddFeaturesToExistingFeatureGates 来获取它。完整示例请参考 Kubernetes 内部使用。

总结

随着 client-go v1.30 中特性门控的引入，推出新的 client-go 特性变得更加安全、简单。用户和开发人员可以控制自己采用 client-go 特性的步伐。通过为跨 Kubernetes API 边界两侧的特性提供一种通用的培育机制，Kubernetes 贡献者的工作得到了简化。

特别感谢 @sttts 和 @deads2k 对此特性提供的帮助。

聚焦 SIG API Machinery

Wed, 07 Aug 2024 00:00:00 +0000

我们最近与 SIG API Machinery 的主席 Federico Bongiovanni（Google）和 David Eads（Red Hat）进行了访谈，了解一些有关这个 Kubernetes 特别兴趣小组的信息。

介绍

Frederico (FSM)：你好，感谢你抽时间参与访谈。首先，你能做个自我介绍以及你是如何参与到 Kubernetes 的？

David：我在 2014 年秋天开始在 OpenShift （Red Hat 的 Kubernetes 发行版）工作，很快就参与到 API Machinery 的工作中。我的第一个 PR 是修复 kube-apiserver 的错误消息，然后逐渐扩展到 kubectl（kubeconfigs 是我的杰作！）， auth（RBAC 和 *Review API 是从 OpenShift 移植过来的），apps（例如 workqueues 和 sharedinformers）。别告诉别人，但 API Machinery 仍然是我的最爱 :)

Federico：我加入 Kubernetes 没有 David 那么早，但现在也已经超过六年了。在我之前的公司，我们开始为自己的产品使用 Kubernetes，当我有机会直接参与 Kubernetes 的工作时，我放下了一切，登上了这艘船（无意双关）。我在 2018 年初加入 Google 从事 Kubernetes 的相关工作，从那时起一直参与其中。

SIG Machinery 的范围

FSM：只需快速浏览一下 SIG API Machinery 的章程，就可以看到它的范围相当广泛，不亚于 Kubernetes 的控制平面。你能用自己的话描述一下这个范围吗？

David：我们全权负责 kube-apiserver 以及如何高效地使用它。在后端，这包括它与后端存储的契约以及如何让 API 模式随时间演变。在前端，这包括模式的最佳实践、序列化、客户端模式以及在其之上的控制器模式。

Federico：Kubernetes 有很多不同的组件，但控制平面有一个非常关键的任务：它是你与集群的通信层，同时也拥有所有使 Kubernetes 如此强大的可扩展机制。我们不能犯像回归或不兼容变更这样的错误，因为影响范围太大了。

FSM：鉴于这个广度，你们如何管理它的不同方面？

Federico：我们尝试将大量工作组织成较小的领域。工作组和子项目是其中的一部分。 SIG 中的各位贡献者有各自的专长领域，如果一切都失败了，我们很幸运有像 David、Joe 和 Stefan 这样的人，他们真的是“全能型”，这种方式让我在这些年里一直感到惊叹。但另一方面，这也是为什么我们需要更多人来帮助我们在版本变迁之时保持 Kubernetes 的质量和卓越。

不断演变的协作模式

FSM：现有的模式一直是这样，还是随着时间的推移而演变的 - 如果是在演变的，你认为主要的变化以及背后的原因是什么？

David：API Machinery 在随着时间的推移不断发展，既有扩展也有收缩。在尝试满足客户端访问模式时，它很容易在特性和应用方面扩大范围。

一个范围扩大的好例子是我们认识到需要减少客户端写入控制器时的内存使用率而开发了共享通知器。在开发共享通知器和使用它们的控制器模式（工作队列、错误处理和列举器）时，我们大大减少了内存使用率，并消除了许多占用资源较多的列表。缺点是：我们增加了一套新的权能来提供支持，并有效地从 sig-apps 接管了该领域的所有权。

一个更多共享所有权的例子是：构建出合作的资源管理（服务器端应用的目标）， kubectl 扩展为负责利用服务器端应用的权能。这个过渡尚未完成，但 SIG CLI 管理其使用情况并拥有它。

FSM：对于方法之间的权衡，你们有什么指导方针吗？

David：我认为这很大程度上取决于影响。如果影响在立即见效中是局部的，我们会给其他 SIG 提出建议并让他们以自己的节奏推进。如果影响在立即见效中是全局的且没有自然的激励，我们发现需要直接推动采用。

FSM：仍然在这个话题上，SIG Architecture 有一个 API Governance 子项目，它与 SIG API Machinery 是否完全独立，还是有重要的连接点？

David：这些项目有相似的名称并对彼此产生一些影响，但有不同的使命和范围。 API Machinery 负责“如何做”，而 API Governance 负责“做什么”。 API 约定、API 审批过程以及对单个 k8s.io API 的最终决定权属于 API Governance。 API Machinery 负责 REST 语义和非 API 特定行为。

Federico：我真得很喜欢 David 的说法： “API Machinery 负责‘如何做’，而 API Governance 负责‘做什么’”：我们并未拥有实际的 API，但实际的 API 依靠我们存在。

Kubernetes 受欢迎的挑战

FSM：随着 Kubernetes 的采用率上升，我们肯定看到了对控制平面的需求增加：你们对这点的感受如何，它如何影响 SIG 的工作？

David：这对 API Machinery 产生了巨大的影响。多年来，我们经常响应并多次促进了 Kubernetes 的发展阶段。作为几乎所有 Kubernetes 集群上权能的集中编排中心，我们既领导又跟随社区。从广义上讲，我看到多年来 API Machinery 经历了一些发展阶段，活跃度一直很高。

寻找目标：从 pre-1.0 到 v1.3（我们达到了第一个 1000+ 节点/命名空间）。这段时间以快速变化为特征。我们经历了五个不同版本的模式，并满足了需求。我们优化了快速、树内 API 的演变（有时以牺牲长期目标为代价），并首次定义了模式。
满足需求的扩展：v1.3-1.9（直到控制器中的共享通知器）。当我们开始尝试满足客户需求时，我们发现了严重的 CPU 和内存规模限制。这也是为什么我们将 API Machinery 扩展到包含访问模式，但我们仍然非常关注树内类型。我们构建了 watch 缓存、protobuf 序列化和共享缓存。

培育生态系统：v1.8-1.21（直到 CRD v1）。这是我们设计和编写 CRD（视为第三方资源的替代品）的时间，满足我们知道即将到来的即时需求（准入 Webhook），以及我们知道需要的最佳实践演变（API 模式）。这促成了早期采用者的爆发式增长，他们愿意在约束内非常谨慎地工作，以实现服务 Pod 的用例。采用速度非常快，有时超出了我们的权能，并形成了新的问题。

简化部署：v1.22+。在不久之前，我们采用扩展机制来响应运行大规模的 Kubernetes 集群的压力，其中包含大量有时会发生冲突的生态系统项目。我们投入了许多努力，使平台更易于扩展，管理更安全，就算不是很精通 Kubernetes 的人也能做到。这些努力始于服务器端应用，并在如今延续到 Webhook 匹配状况和验证准入策略等特性。

API Machinery 的工作对整个项目和生态系统有广泛的影响。对于那些能够长期投入大量时间的人来说，这是一个令人兴奋的工作领域。

未来发展

FSM：考虑到这些不同的发展阶段，你能说说这个 SIG 的当前首要任务是什么吗？

David：大致的顺序为可靠性、效率和权能。

随着 kube-apiserver 和扩展机制的使用增加，我们发现第一套扩展机制虽然在权能方面相当完整，但在潜在误用方面存在重大风险，影响范围很大。为了减轻这些风险，我们正在致力于减少事故影响范围的特性（Webhook 匹配状况）以及为大多数操作提供风险配置较低的替代机制（验证准入策略）。

同时，使用量的增加使我们更加意识到我们可以同时改进服务器端和客户端的扩缩限制。这里的努力包括更高效的序列化（CBOR），减少 etcd 负载（从缓存中一致读取）和减少峰值内存使用量（流式列表）。

最后，使用量的增加突显了一些长期存在的、我们正在设法填补的差距。这些包括针对 CRD 的字段选择算符， Batch Working Group 渴望利用这些选择算符，并最终构建一种新的方法以防止从有漏洞的节点实施“蹦床式”的 Pod 攻击。

加入有趣的我们

FSM：如果有人想要开始贡献，你有什么建议？

Federico：SIG API Machinery 毫不例外也遵循 Kubernetes 的风格：砍柴和挑水（踏实工作，注重细节）。有多个每周例会对所有人开放，总是有更多的工作要做，人手总是不够。

我承认 API Machinery 并不容易，入门的坡度会比较陡峭。门槛较高，就像我们所讨论的原因：我们肩负着巨大的责任。当然凭借激情和毅力，多年来有许多人已经跟了上来，我们希望更多的人加入。

具体的机会方面，每两周有一次 SIG 会议。欢迎所有人参会和听会，了解小组在讨论什么，了解这个版本中发生了什么等等。

此外，每周两次，周二和周四，我们有公开的 Bug 分类管理会，在会上我们会讨论上次会议以来的所有新内容。我们已经保持这种做法 7 年多了。这是一个很好的机会，你可以志愿审查代码、修复 Bug、改进文档等。周二的会议在下午 1 点（PST），周四是在 EMEA 友好时间（上午 9:30 PST）。我们总是在寻找改进的机会，希望能够在未来提供更多具体的参与机会。

FSM：太好了，谢谢！你们还有什么想与我们的读者分享吗？

Federico：正如我提到的，第一步可能较难，但回报也更大。参与 API Machinery 的工作就是在加入一个影响巨大（百万用户？）的领域，你的贡献将直接影响 Kubernetes 的工作方式和使用方式。对我来说，这已经足够作为回报和动力了！

Kubernetes v1.31 中的移除和主要变更

Fri, 19 Jul 2024 00:00:00 +0000

随着 Kubernetes 的发展和成熟，为了项目的整体健康，某些特性可能会被弃用、删除或替换为更好的特性。本文阐述了 Kubernetes v1.31 版本的一些更改计划，发行团队认为你应当了解这些更改，以便持续维护 Kubernetes 环境。下面列出的信息基于 v1.31 版本的当前状态；这些状态可能会在实际发布日期之前发生变化。

Kubernetes API 删除和弃用流程

Kubernetes 项目针对其功能特性有一个详细说明的弃用策略。此策略规定，只有当某稳定 API 的更新、稳定版本可用时，才可以弃用该 API，并且 API 的各个稳定性级别都有对应的生命周期下限。已弃用的 API 标记为在未来的 Kubernetes 版本中删除，这类 API 将继续发挥作用，直至被删除（从弃用起至少一年），但使用时会显示警告。已删除的 API 在当前版本中不再可用，因此你必须将其迁移到替换版本。

正式发布的（GA）或稳定的 API 版本可被标记为已弃用，但不得在 Kubernetes 主要版本未变时删除。
Beta 或预发布 API 版本在被弃用后，必须保持 3 个发布版本中仍然可用。
Alpha 或实验性 API 版本可以在任何版本中删除，不必提前通知。

无论 API 是因为某个特性从 Beta 版升级到稳定版，还是因为此 API 未成功而被删除，所有删除都将符合此弃用策略。每当删除 API 时，迁移选项都会在文档中传达。

关于 SHA-1 签名支持的说明

在 go1.18（2022 年 3 月发布）中，crypto/x509 库开始拒绝使用 SHA-1 哈希函数签名的证书。虽然 SHA-1 被确定为不安全，并且公众信任的证书颁发机构自 2015 年以来就没有颁发过 SHA-1 证书，但在 Kubernetes 环境中，仍可能存在用户提供的证书通过私人颁发机构使用 SHA-1 哈希函数签名的情况，这些证书用于聚合 API 服务器或 Webhook。如果你依赖基于 SHA-1 的证书，则必须通过在环境中设置 GODEBUG=x509sha1=1 以明确选择重新支持这种证书。

鉴于 Go 的 GODEBUG 兼容性策略，x509sha1 GODEBUG 和对 SHA-1 证书的支持将在 2025 年上半年发布的 go1.24 中完全消失。如果你依赖 SHA-1 证书，请开始放弃使用它们。

请参阅 Kubernetes 问题 #125689，以更好地了解对 SHA-1 支持的时间表，以及 Kubernetes 发布采用 go1.24 的计划时间、如何通过指标和审计日志检测 SHA-1 证书使用情况的更多详细信息。

Kubernetes 1.31 中的弃用和删除

弃用节点的 `status.nodeInfo.kubeProxyVersion` 字段（KEP 4004）

Node 的 .status.nodeInfo.kubeProxyVersion 字段在 Kubernetes v1.31 中将被弃用，并将在后续版本中删除。该字段被弃用是因为其取值原来不准确，并且现在也不准确。该字段由 kubelet 设置，而 kubelet 没有关于 kube-proxy 版本或 kube-proxy 是否正在运行的可靠信息。

在 v1.31 中，DisableNodeKubeProxyVersion 特性门控将默认设置为 true，并且 kubelet 将不再尝试为其关联的 Node 设置 .status.kubeProxyVersion 字段。

删除所有云驱动的树内集成组件

正如之前一篇文章中所强调的， v1.31 版本将删除云驱动集成的树内支持的最后剩余部分。这并不意味着你无法与某云驱动集成，只是你现在必须使用推荐的外部集成方法。一些集成组件是 Kubernetes 项目的一部分，其余集成组件则是第三方软件。

这一里程碑标志着将所有云驱动集成组件从 Kubernetes 核心外部化的过程已经完成（KEP-2395），该过程从 Kubernetes v1.26 开始。这一变化有助于 Kubernetes 进一步成为真正的供应商中立平台。

有关云驱动集成的更多详细信息，请阅读我们的 v1.29 云驱动集成特性的博客。有关树内代码删除的更多背景信息，请阅读（v1.29 弃用博客）。

后一个博客还包含对需要迁移到 v1.29 及更高版本的用户有用的信息。

删除 kubelet `--keep-terminated-pod-volumes` 命令行标志

kubelet 标志 --keep-terminated-pod-volumes 已于 2017 年弃用，将在 v1.31 版本中被删除。

你可以在拉取请求 #122082 中找到更多详细信息。

删除 CephFS 卷插件

CephFS 卷插件已在此版本中删除，并且 cephfs 卷类型已无法使用。

建议你改用 CephFS CSI 驱动程序作为第三方存储驱动程序。如果你在将集群版本升级到 v1.31 之前在使用 CephFS 卷插件，则必须重新部署应用才能使用新驱动。

CephFS 卷插件在 v1.28 中正式标记为已弃用。

删除 Ceph RBD 卷插件

v1.31 版本将删除 Ceph RBD 卷插件及其 CSI 迁移支持， rbd 卷类型将无法继续使用。

建议你在集群中使用 RBD CSI 驱动。如果你在将集群版本升级到 v1.31 之前在使用 Ceph RBD 卷插件，则必须重新部署应用以使用新驱动。

Ceph RBD 卷插件在 v1.28 中正式标记为已弃用。

kube-scheduler 中非 CSI 卷限制插件的弃用

v1.31 版本将弃用所有非 CSI 卷限制调度程序插件，并将从默认插件中删除一些已弃用的插件，包括：

AzureDiskLimits
CinderLimits
EBSLimits
GCEPDLimits

建议你改用 NodeVolumeLimits 插件，因为它可以处理与已删除插件相同的功能，因为这些卷类型已迁移到 CSI。如果你在调度器配置中显式使用已弃用的插件，请用 NodeVolumeLimits 插件替换它们。 AzureDiskLimits、CinderLimits、EBSLimits 和 GCEPDLimits 插件将在未来的版本中被删除。

这些插件将从默认调度程序插件列表中删除，因为它们自 Kubernetes v1.14 以来已被弃用。

展望未来

Kubernetes v1.32 计划删除的官方 API 包括：

将删除 flowcontrol.apiserver.k8s.io/v1beta3 API 版本的 FlowSchema 和 PriorityLevelConfiguration。为了做好准备，你可以编辑现有清单并重写客户端软件以使用自 v1.29 起可用的 flowcontrol.apiserver.k8s.io/v1 API 版本。所有现有的持久化对象都可以通过新 API 访问。flowcontrol.apiserver.k8s.io/v1beta3 中需要注意的变化包括优先级配置 spec.limited.nominalConcurrencyShares 字段仅在未指定时默认为 30，并且显式设置为 0 的话不会被更改为 30。

有关更多信息，请参阅 API 弃用指南。

想要了解更多？

Kubernetes 发行说明中会宣布弃用信息。我们将在 Kubernetes v1.31 中正式宣布弃用信息，作为该版本的 CHANGELOG 的一部分。

你可以在发行说明中看到待弃用的公告：

Kubernetes 的十年

Thu, 06 Jun 2024 00:00:00 +0000

十年前的 2014 年 6 月 6 日，Kubernetes 的第一次提交被推送到 GitHub。第一次提交包含了 250 个文件和 47,501 行的 Go、Bash 和 Markdown 代码，开启了我们今天所拥有的项目。谁能预测到 10 年后，Kubernetes 会成长为迄今为止最大的开源项目之一，拥有来自超过 8,000 家公司、来自 44 个国家的 88,000 名贡献者。

这一里程碑不仅属于 Kubernetes，也属于由此蓬勃发展的云原生生态系统。在 CNCF 本身就有近 200 个项目，有来自 240,000 多名个人贡献者，还有数千名来自更大的生态系统的贡献者的贡献。如果没有 700 多万开发者和更庞大的用户社区， Kubernetes 就不会达到今天的成就，他们一起帮助塑造了今天的生态系统。

Kubernetes 的起源 - 技术的融合

Kubernetes 背后的理念早在第一次提交之前，甚至第一个原型（在 2013 年问世之前就已经存在。在 21 世纪初，摩尔定律仍然成立。计算硬件正以惊人的速度变得越来越强大。相应地，应用程序变得越来越复杂。硬件商品化和应用程序复杂性的结合表明需要进一步将软件从硬件中抽象出来，因此解决方案开始出现。

像当时的许多公司一样，Google 正在快速扩张，其工程师对在 Linux 内核中创建一种隔离形式的想法很感兴趣。 Google 工程师 Rohit Seth 在 2006 年的一封电子邮件中描述了这个概念：

我们使用术语 “容器” 来表示一种结构，通过该结构我们可以对负载的系统资源（如内存、任务等）利用情况进行跟踪和计费。

2013 年 3 月，Solomon Hykes 在 PyCon 上进行了一场名为 “Linux容器的未来”的 5 分钟闪电演讲，介绍了名为 “Docker” 的一款即将被推出的开源工具，用于创建和使用 Linux 容器。Docker 提升了 Linux 容器的可用性，使其比以往更容易被更多用户使用，从而使 Docker 和Linux 容器的流行度飙升。随着 Docker 使 Linux 容器的抽象概念可供所有人使用，以更便于移植且可重复的方式运行应用突然成为可能，但大规模使用的问题仍然存在。

Google 用来管理大规模应用编排的 Borg 系统在 2000 年代中期采用当时所开发的 Linux 容器技术。此后，该公司还开始研发该系统的一个新版本，名为 “Omega”。熟悉 Borg 和 Omega 系统的 Google 工程师们看到了 Docker 所推动的容器化技术的流行。他们意识到对一个开源的容器编排系统的需求，而且意识到这一系统的“必然性”，正如 Brendan Burns 在这篇博文中所描述的。这一认识在 2013 年秋天激发了一个小团队开始着手一个后来成为 Kubernetes 的项目。该团队包括 Joe Beda、Brendan Burns、Craig McLuckie、Ville Aikas、Tim Hockin、Dawn Chen、Brian Grant 和 Daniel Smith。

Kubernetes 十年回顾

Kubernetes 的历史始于 2014 年 6 月 6 日的那次历史性提交，随后， Google 工程师 Eric Brewer 在 2014 年 6 月 10 日的 DockerCon 2014 上的主题演讲(及其相应的 Google 博客)中由宣布了该项目。

在接下来的一年里，一个由主要来自 Google 和 Red Hat 等公司的贡献者组成的小型社区为该项目付出了辛勤的努力，最终在 2015 年 7 月 21 日发布了 1.0 版本。在发布 1.0 版本的同时，Google 宣布将 Kubernetes 捐赠给 Linux 基金会下的一个新成立的分支，即云原生计算基金会 (Cloud Native Computing Foundation，CNCF)。

尽管到了 1.0 版本，但 Kubernetes 项目的使用和理解仍然很困难。Kubernetes 贡献者 Kelsey Hightower 特别注意到了该项目在易用性方面的不足，并于 2016 年 7 月 7 日推出了他著名的 “Kubernetes the Hard Way” 指南的第一次提交。

自从最初的 1.0 版本发布以来，项目经历了巨大的变化，取得了许多重大的成就，例如在 1.16 版本中正式发布的 Custom Resource Definitions (CRD) ，或者在 1.23 版本中推出的全面双栈支持，以及社区从 1.22 版本中移除广泛使用的 Beta API 和弃用 Dockershim 中吸取的“教训”。

自 1.0 版本以来的一些值得注意的更新、里程碑和事件包括：

2016 年 12 月 - Kubernetes 1.5 引入了运行时可插拔性，初步支持 CRI 和 Alpha 版 Windows 节点支持。 OpenAPI 也首次出现，为客户端能够发现扩展 API 铺平了道路。
- 此版本还引入了 Beta 版的 StatefulSet 和 PodDisruptionBudget。

2017 年 4 月 — 引入基于角色的访问控制（RBAC）。
2017 年 6 月 — 在 Kubernetes 1.7 中，ThirdPartyResources 或 "TPRs" 被 CustomResourceDefinitions（CRD）取代。
2017 年 12 月 — Kubernetes 1.9 中，工作负载 API 成为 GA（正式可用）。发布博客中指出：“Deployment 和 ReplicaSet 是 Kubernetes 中最常用的两个对象，在经过一年多的实际使用和反馈后，现在已经稳定下来。”

2018 年 12 月 — 在 1.13 版本中，容器存储接口（CSI）达到 GA，用于引导最小可用集群的 kubeadm 工具达到 GA，并且 CoreDNS 成为默认的 DNS 服务器。
2019 年 9 月 — 自定义资源定义（Custom Resource Definition）在 Kubernetes 1.16 中正式发布。
2020 年 8 月 — Kubernetes 1.19 将发布支持窗口增加到 1 年。
2020 年 12 月 — Dockershim 在 1.20 版本中被弃用。

2021 年 4 月 - Kubernetes 发布节奏变更，从每年发布 4 个版本变为每年发布 3 个版本。
2021 年 7 月 - 在 Kubernetes 1.22 中移除了广泛使用的 Beta API。
2022 年 5 月 - 在 Kubernetes 1.24 中，Beta API 默认被禁用，以减少升级冲突，并移除了 Dockershim，导致用户普遍感到困惑（我们已经改进了我们的沟通方式！）
2022 年 12 月 - 在 1.26 版本中，进行了重大的批处理和作业 API 改进，为更好地支持 AI/ML/批处理工作负载铺平了道路。

附言: 想亲自体会一下这个项目的进展么？可以查看由社区成员 Carlos Santana、Amim Moises Salum Knabben 和 James Spurin 创建的 Kubernetes 1.0 集群搭建教程。

Kubernetes 提供的扩展点多得数不胜数。最初设计用于与 Docker 一起工作，现在你可以插入任何符合 CRI 标准的容器运行时。还有其他类似的接口：用于存储的 CSI 和用于网络的 CNI。而且这还远远不是全部。在过去的十年中，出现了全新的模式，例如使用自定义资源定义（CRD）来支持第三方控制器 - 这现在是 Kubernetes 生态系统的重要组成部分。

在过去十年间，参与构建该项目的社区也得到了巨大的扩展。通过使用 DevStats，我们可以看到过去十年中令人难以置信的贡献量，这使得 Kubernetes 成为了全球第二大开源项目：

88,474 位贡献者
15,121 位代码提交者
4,228,347 次贡献
158,530 个问题
311,787 个拉取请求

Kubernetes 现状

自项目初期以来，项目在技术能力、使用率和贡献方面取得了巨大的增长。项目仍在积极努力改进并更好地为用户服务。

在即将发布的 1.31 版本中，该项目将庆祝一个重要的长期项目的完成：移除内部云提供商代码。在这个 Kubernetes 历史上最大的迁移中，大约删除了 150 万行代码，将核心组件的二进制文件大小减小了约 40%。在项目早期，很明显可扩展性是成功的关键。然而，如何实现这种可扩展性并不总是很清楚。此次迁移从核心 Kubernetes 代码库中删除了各种特定于供应商的功能。现在，特定于供应商的功能可以通过其他可插拔的扩展功能或模式更好地提供，例如自定义资源定义（CRD）或 Gateway API 等 API 标准。 Kubernetes 在为其庞大的用户群体提供服务时也面临着新的挑战，社区正在相应地进行调整。其中一个例子是将镜像托管迁移到新的、由社区拥有的 registry.k8s.io。为用户提供预编译二进制镜像的出口带宽和成本已经变得非常巨大。这一新的仓库变更使社区能够以更具成本效益和性能高效的方式继续提供这些便利的镜像。请务必查看此博客文章并更新你必须使用 registry.k8s.io 仓库的任何自动化设施！

Kubernetes 的未来

十年过去了，Kubernetes 的未来依然光明。社区正在优先考虑改进用户体验和增强项目可持续性的变革。应用程序开发的世界不断演变，Kubernetes 正准备随之变化。

2024 年，人工智能的进展将一种曾经小众的工作负载类型变成了一种非常重要的工作负载类型。分布式计算和工作负载调度一直与人工智能、机器学习和高性能计算工作负载的资源密集需求密切相关。贡献者们密切关注新开发的工作负载的需求以及 Kubernetes 如何为它们提供最佳服务。新成立的 Serving 工作组就是社区组织来解决这些工作负载需求的一个例子。未来几年可能会看到 Kubernetes 在管理各种类型的硬件以及管理跨硬件运行的大型批处理工作负载的调度能力方面的改进。

Kubernetes 周围的生态系统将继续发展壮大。未来，为了保持项目的可持续性，像内部供应商代码的迁移和仓库变更这样的举措将变得更加重要。

Kubernetes 的未来 10 年将由其用户和生态系统引领，但最重要的是，由为其做出贡献的人引领。社区对新贡献者持开放态度。你可以在我们的新贡献者课程 https://k8s.dev/docs/onboarding 中找到更多有关贡献的信息。

我们期待与你一起构建 Kubernetes 的未来！

完成 Kubernetes 史上最大规模迁移

Mon, 20 May 2024 00:00:00 +0000

早自 Kubernetes v1.7 起，Kubernetes 项目就开始追求取消集成内置云驱动（KEP-2395）。虽然这些集成对于 Kubernetes 的早期发展和增长发挥了重要作用，但它们的移除是由两个关键因素驱动的：为各云启动维护数百万行 Go 代码的原生支持所带来的日趋增长的复杂度，以及将 Kubernetes 打造为真正的供应商中立平台的愿景。

历经很多发布版本之后，我们很高兴地宣布所有云驱动集成组件已被成功地从核心 Kubernetes 仓库迁移到外部插件中。除了实现我们最初的目标之外，我们还通过删除大约 150 万行代码，将核心组件的可执行文件大小减少了大约 40%，极大简化了 Kubernetes。

由于受影响的组件众多，而且关键代码路径依赖于五个初始云驱动（Google Cloud、AWS、Azure、OpenStack 和 vSphere）的内置集成，因此此次迁移是一项复杂且耗时的工作。为了成功完成此迁移，我们必须从头开始构建四个新的子系统：

云控制器管理器（Cloud controller manager）（KEP-2392）
API 服务器网络代理（KEP-1281）
kubelet 凭证提供程序插件（KEP-2133）
存储迁移以使用 CSI（KEP-625）

就与内置功能实现完全的特性等价而言，每个子系统都至关重要，并且需要迭代多个版本才能使每个子系统达到 GA 级别并具有安全可靠的迁移路径。下面详细介绍每个子系统。

云控制器管理器

云控制器管理器是这项工作中引入的第一个外部组件，取代了 kube-controller-manager 和 kubelet 中直接与云 API 交互的功能。这个基本组件负责通过施加元数据标签来初始化节点。所施加的元数据标签标示节点运行所在的云区域和可用区，以及只有云驱动知道的 IP 地址。此外，它还运行服务控制器，该控制器负责为 LoadBalancer 类型的 Service 配置云负载均衡器。

要进一步了解相关信息，请阅读 Kubernetes 文档中的云控制器管理器。

API 服务器网络代理

API 服务器网络代理项目于 2018 年与 SIG API Machinery 合作启动，旨在取代 kube-apiserver 中的 SSH 隧道功能。该隧道器原用于安全地代理 Kubernetes 控制平面和节点之间的流量，但它重度依赖于 kube-apiserver 中所嵌入的、特定于提供商的实现细节来建立这些 SSH 隧道。

现在，API 服务器网络代理成为 kube-apiserver 中 GA 级别的扩展点。提供了一种通用代理机制，可以通过一个安全的代理将流量从 API 服务器路由到节点，从而使 API 服务器无需了解其运行所在的特定云驱动。此项目还引入了 Konnectivity 项目，该项目在生产环境中的采用越来越多。

你可以在其 README 中了解有关 API 服务器网络代理的更多信息。

kubelet 的凭据提供程序插件

kubelet 凭据提供程序插件的开发是为了取代 kubelet 的内置功能，用于动态获取用于托管在 Google Cloud、AWS 或 Azure 上的镜像仓库的凭据。原来所实现的功能很方便，因为它允许 kubelet 无缝地获取短期令牌以从 GCR、ECR 或 ACR 拉取镜像然而，与 Kubernetes 的其他领域一样，支持这一点需要 kubelet 具有不同云环境和 API 的特定知识。

凭据驱动插件机制于 2019 年推出，为 kubelet 提供了一个通用扩展点用于执行插件的可执行文件，进而为访问各种云上托管的镜像动态提供凭据。可扩展性扩展了 kubelet 获取短期令牌的能力，且不受限于最初的三个云驱动。

要了解更多信息，请阅读用于认证镜像拉取的 kubelet 凭据提供程序。

存储插件从树内迁移到 CSI

容器存储接口（Container Storage Interface，CSI）是一种控制平面标准，用于管理 Kubernetes 和其他容器编排系统中的块和文件存储系统，已在 1.13 中进入正式发布状态。它的设计目标是用可在 Kubernetes 集群中 Pod 内运行的驱动程序替换直接内置于 Kubernetes 中的树内卷插件。这些驱动程序通过 Kubernetes API 与 kube-controller-manager 存储控制器通信，并通过本地 gRPC 端点与 kubelet 进行通信。现在，所有主要云和存储供应商一起提供了 100 多个 CSI 驱动，使 Kubernetes 中运行有状态工作负载成为现实。

然而，如何处理树内卷 API 的所有现有用户仍然是一个重大挑战。为了保持 API 向后兼容性，我们在控制器中构建了一个 API 转换层，把树内卷 API 转换为等效的 CSI API。这使我们能够将所有存储操作重定向到 CSI 驱动程序，为我们在不删除 API 的情况下删除内置卷插件的代码铺平了道路。

你可以在 Kubernetes 树内卷到 CSI 卷的迁移进入 Beta 阶段。

下一步是什么？

过去几年，这一迁移工程一直是 SIG Cloud Provider 的主要关注点。随着这一重要里程碑的实现，我们将把努力转向探索新的创新方法，让 Kubernetes 更好地与云驱动集成，利用我们多年来构建的外部子系统。这包括使 Kubernetes 在混合环境中变得更加智能，其集群中的节点可以运行在公共云和私有云上，以及为外部驱动的开发人员提供更好的工具和框架，以简化他们的集成工作，提高效率。

在规划所有这些新特性、工具和框架的同时，SIG Cloud Provider 并没有忘记另一项同样重要的工作：测试。 SIG 未来活动的另一个重点领域是改进云控制器测试以涵盖更多的驱动。这项工作的最终目标是创建一个包含尽可能多驱动的测试框架，以便我们让 Kubernetes 社区对其 Kubernetes 环境充满信心。

如果你使用的 Kubernetes 版本早于 v1.29 并且尚未迁移到外部云驱动，我们建议你查阅我们之前的博客文章 Kubernetes 1.29：云驱动集成现在是单独的组件。该博客包含与我们所作的变更相关的详细信息，并提供了有关如何迁移到外部驱动的指导。从 v1.31 开始，树内云驱动将被永久禁用并从核心 Kubernetes 组件中删除。

如果你有兴趣做出贡献，请参加我们的每两周一次的 SIG 会议!

Gateway API v1.1：服务网格、GRPCRoute 和更多变化

Thu, 09 May 2024 09:00:00 -0800

继去年十月正式发布 Gateway API 之后，Kubernetes SIG Network 现在又很高兴地宣布 Gateway API v1.1 版本发布。在本次发布中，有几个特性已进阶至标准渠道（GA），特别是对服务网格和 GRPCRoute 的支持也已进阶。我们还引入了一些新的实验性特性，包括会话持久性和客户端证书验证。

新内容

进阶至标准渠道

本次发布有四个备受期待的特性进阶至标准渠道。这意味着它们不再是实验性的概念；包含在标准发布渠道中的举措展现了大家对 API 接口的高度信心，并提供向后兼容的保证。当然，与所有其他 Kubernetes API 一样，标准渠道的特性可以随着时间的推移通过向后兼容的方式演进，我们当然期待未来对这些新特性有进一步的优化和改进。有关细节请参阅 Gateway API 版本控制政策。

服务网格支持

在 Gateway API 中支持服务网格意味着允许服务网格用户使用相同的 API 来管理 Ingress 流量和网格流量，能够重用相同的策略和路由接口。在 Gateway API v1.1 中，路由（如 HTTPRoute）现在可以将一个 Service 作为 parentRef，以控制到特定服务的流量行为。有关细节请查阅 Gateway API 服务网格文档或 Gateway API 实现列表。

例如，你可以使用如下 HTTPRoute 以金丝雀部署深入到应用调用图中的工作负载：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
 name: color-canary
 namespace: faces
spec:
 parentRefs:
 - name: color
 kind: Service
 group: ""
 port: 80
 rules:
 - backendRefs:
 - name: color
 port: 80
 weight: 50
 - name: color2
 port: 80
 weight: 50

通过使用一种便于从一个网格迁移到另一个网格的可移植配置，此 HTTPRoute 对象将把发送到 faces 命名空间中的 color Service 的流量按 50/50 拆分到原始的 color Service 和 color2 Service 上。

GRPCRoute

如果你已经在使用实验性版本的 GRPCRoute，我们建议你暂时不要升级到标准渠道版本的 GRPCRoute，除非你正使用的控制器已被更新为支持 GRPCRoute v1。在此之后，你才可以安全地升级到实验性渠道版本的 GRPCRoute v1.1，这个版本同时包含了 v1alpha2 和 v1 的 API。

ParentReference 端口

port 字段已被添加到 ParentReference 中，允许你将资源挂接到 Gateway 监听器、Service 或其他父资源（取决于实现）。绑定到某个端口还允许你一次挂接到多个监听器。

例如，你可以将 HTTPRoute 挂接到由监听器 port 而不是监听器 name 字段所指定的一个或多个特定监听器。

有关细节请参阅挂接到 Gateways。

合规性配置文件和报告

合规性报告 API 被扩展了，添加了 mode 字段（用于指定实现的工作模式）以及 gatewayAPIChannel（标准或实验性）。 gatewayAPIVersion 和 gatewayAPIChannel 现在由套件机制自动填充，并附有测试结果的简要描述。这些报告已通过更加结构化的方式进行重新组织，现在实现可以添加测试是如何运行的有关信息，还能提供复现步骤。

实验性渠道的新增内容

Gateway 客户端证书验证

Gateway 现在可以通过在 tls 内引入的新字段 frontendValidation 来为每个 Gateway 监听器配置客户端证书验证。此字段支持配置可用作信任锚的 CA 证书列表，以验证客户端呈现的证书。

以下示例显示了如何使用存储在 foo-example-com-ca-cert ConfigMap 中的 CACertificate 来验证连接到 foo-https Gateway 监听器的客户端所呈现的证书。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
 name: client-validation-basic
spec:
 gatewayClassName: acme-lb
 listeners:
 - name: foo-https
 protocol: HTTPS
 port: 443
 hostname: foo.example.com
 tls:
 certificateRefs:
 - kind: Secret
 group: ""
 name: foo-example-com-cert
 frontendValidation:
 caCertificateRefs:
 - kind: ConfigMap
 group: ""
 name: foo-example-com-ca-cert

会话持久性和 BackendLBPolicy

会话持久性通过新的策略（BackendLBPolicy）引入到 Gateway API 中用于服务级配置，在 HTTPRoute 和 GRPCRoute 内以字段的形式用于路由级配置。 BackendLBPolicy 和路由级 API 提供相同的会话持久性配置，包括会话超时、会话名称、会话类型和 cookie 生命周期类型。

以下是 BackendLBPolicy 的示例配置，为 foo 服务启用基于 Cookie 的会话持久性。它将会话名称设置为 foo-session，定义绝对超时时间和空闲超时时间，并将 Cookie 配置为会话 Cookie：

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendLBPolicy
metadata:
 name: lb-policy
 namespace: foo-ns
spec:
 targetRefs:
 - group: core
 kind: service
 name: foo
 sessionPersistence:
 sessionName: foo-session
 absoluteTimeout: 1h
 idleTimeout: 30m
 type: Cookie
 cookieConfig:
 lifetimeType: Session

其他更新

TLS 术语阐述

为了在整个 API 中让我们的 TLS 术语更加一致以实现更广泛的目标，我们对 BackendTLSPolicy 做了一些破坏性变更。这就产生了新的 API 版本（v1alpha3），且将需要这个策略所有现有的实现来正确处理版本升级，例如通过备份数据并在安装这个新版本之前卸载 v1alpha2 版本。

所有引用了 v1alpha2 BackendTLSPolicy 的字段都将需要更新为 v1alpha3。这些字段的具体变更包括：

targetRef 变为 targetRefs 以允许 BackendTLSPolicy 挂接到多个目标
tls 变为 validation
tls.caCertRefs 变为 validation.caCertificateRefs
tls.wellKnownCACerts 变为 validation.wellKnownCACertificates

有关本次发布包含的完整变更列表，请参阅 v1.1.0 发布说明。

Gateway API 背景

Gateway API 的想法最初是在 2019 年 KubeCon San Diego 上作为下一代 Ingress API 提出的。从那时起，一个令人瞩目的社区逐渐形成，共同开发出了可能成为 Kubernetes 历史上最具合作精神的 API。到目前为止，已有超过 200 人为该 API 做过贡献，而且这一数字还在不断攀升。

维护者们要感谢为 Gateway API 做出贡献的每一个人，无论是提交代码、参与讨论、提供创意，还是给予常规支持，我们都在此表示诚挚的感谢。没有这个专注且活跃的社区的支持，我们不可能走到这一步。

试用一下

与其他 Kubernetes API 不同，你不需要升级到最新版本的 Kubernetes 即可获得最新版本的 Gateway API。只要你运行的是 Kubernetes 1.26 或更高版本，你就可以使用这个版本的 Gateway API。

要试用此 API，请参阅入门指南。

参与进来

你有很多机会可以参与进来并帮助为 Ingress 和服务网格定义 Kubernetes 路由 API 的未来。

查阅用户指南以了解可以解决哪些用例。
试用其中一个现有的 Gateway 控制器。
或者加入我们的社区，帮助我们一起构建 Gateway API 的未来！

2023 年 11 月 Gateway API v1.0 中的新实验性特性
2023 年 10 月 Gateway API v1.0：正式发布（GA）
2023 年 10 月介绍 ingress2gateway；简化 Gateway API 升级
2023 年 8 月 Gateway API v0.8.0：引入服务网格支持

Kubernetes 1.30：防止未经授权的卷模式转换进阶到 GA

Tue, 30 Apr 2024 00:00:00 +0000

作者: Raunak Pradip Shah (Mirantis)

译者: Xin Li (DaoCloud)

随着 Kubernetes 1.30 的发布，防止修改从 Kubernetes 集群中现有 VolumeSnapshot 创建的 PersistentVolumeClaim 的卷模式的特性已被升级至 GA！

问题

PersistentVolumeClaim 的卷模式是指存储设备上的底层卷是被格式化为某文件系统还是作为原始块设备呈现给使用它的 Pod。

用户可以利用自 Kubernetes v1.20 以来一直稳定的 VolumeSnapshot 特性，基于 Kubernetes 集群中现有的 VolumeSnapshot 创建 PersistentVolumeClaim（简称 PVC）。 PVC 规约中包括一个 dataSource 字段，它可以指向现有的 VolumeSnapshot 实例。有关如何基于 Kubernetes 集群中现有 VolumeSnapshot 创建 PVC 的更多详细信息，请访问使用卷快照创建 PersistentVolumeClaim。

当利用上述特性时，没有逻辑来验证制作快照的原始卷的模式是否与新创建的卷的模式匹配。

这带来了一个安全漏洞，允许恶意用户潜在地利用主机操作系统中未知的漏洞。

有一个合法的场景允许某些用户执行此类转换。通常，存储备份供应商会在备份操作过程中转换卷模式，通过检索已被更改的块来提高操作效率。这使得 Kubernetes 无法完全阻止此类操作，但给区分可信用户和恶意用户带来了挑战。

防止未经授权的用户转换卷模式

在此上下文中，授权用户是有权对 VolumeSnapshotContents（集群级资源）执行 update 或 patch 操作的用户。集群管理员应仅向受信任的用户或应用程序（例如备份供应商）赋予这些权限。当从 VolumeSnapshot 创建 PVC 时，除了此类授权用户之外的用户将永远不会被允许修改 PVC 的卷模式。

要转换卷模式，授权用户必须执行以下操作：

标识要用作给定命名空间中新创建的 PVC 的数据源的 VolumeSnapshot。
识别与上述 VolumeSnapshot 绑定的 VolumeSnapshotContent。
```
kubectl describe volumesnapshot -n <namespace> <name>
```

在 VolumeSnapshotContent 上添加 snapshot.storage.kubernetes.io/allow-volume-mode-change: "true" 注解，VolumeSnapshotContent 注解必须包含类似于以下清单片段：
```
kind: VolumeSnapshotContent
metadata:
 annotations:
 - snapshot.storage.kubernetes.io/allow-volume-mode-change: "true"
...
```

注意：对于预配置的 VolumeSnapshotContents，你必须执行额外的步骤，将 spec.sourceVolumeMode 字段设置为 Filesystem 或 Block，具体取决于用来制作此快照的卷的模式。

一个例子如下所示：

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
 annotations:
 - snapshot.storage.kubernetes.io/allow-volume-mode-change: "true"
 name: <volume-snapshot-content-name>
spec:
 deletionPolicy: Delete
 driver: hostpath.csi.k8s.io
 source:
 snapshotHandle: <snapshot-handle>
 sourceVolumeMode: Filesystem
 volumeSnapshotRef:
 name: <volume-snapshot-name>
 namespace: <namespace>

对备份或恢复操作期间需要转换卷模式的所有 VolumeSnapshotContent 重复步骤 1 至 3。这可以通过具有授权用户凭据的软件来完成，也可以由授权用户手动完成。

如果 VolumeSnapshotContent 对象上存在上面显示的注解，Kubernetes 将不会阻止卷模式转换。用户在尝试将注解添加到任何 VolumeSnapshotContent 之前应记住这一点。

需要采取的行动

默认情况下，在 external-provisioner v4.0.0 和 external-snapshotter v7.0.0 中启用 prevent-volume-mode-conversion 特性标志。基于 VolumeSnapshot 来创建 PVC 时，卷模式更改将被拒绝，除非已执行上述步骤。

接下来

要确定哪些 CSI 外部 sidecar 版本支持此功能，请前往 CSI 文档页面。对于任何疑问或问题，请加入 Slack 上的 Kubernetes 并在 #csi 或 #sig-storage 频道中发起讨论。或者，在 CSI 外部快照仓库中登记问题。

Kubernetes 1.30：结构化身份认证配置进阶至 Beta

Thu, 25 Apr 2024 00:00:00 +0000

在 Kubernetes 1.30 中，我们（SIG Auth）将结构化身份认证配置（Structured Authentication Configuration）进阶至 Beta。

今天的文章是关于身份认证：找出谁在执行任务，核查他们是否是自己所说的那个人。本文还述及 Kubernetes v1.30 中关于鉴权（决定某些人能访问什么，不能访问什么）的新内容。

动机

Kubernetes 长期以来都需要一个更灵活、更好扩展的身份认证系统。当前的系统虽然强大，但有一些限制，使其难以用在某些场景下。例如，不可能同时使用多个相同类型的认证组件（例如，多个 JWT 认证组件），也不可能在不重启 API 服务器的情况下更改身份认证配置。结构化身份认证配置特性是解决这些限制并提供一种更灵活、更好扩展的方式来配置 Kubernetes 中身份认证的第一步。

什么是结构化身份认证配置？

Kubernetes v1.30 针对基于文件来配置身份认证提供实验性支持，这是在 Kubernetes v1.30 中新增的 Alpha 特性。在此 Beta 阶段，Kubernetes 仅支持配置 JWT 认证组件，这是现有 OIDC 认证组件的下一次迭代。 JWT 认证组件使用符合 JWT 标准的令牌对 Kubernetes 用户进行身份认证。此认证组件将尝试解析原始 ID 令牌，验证其是否由配置的签发方签名。

Kubernetes 项目新增了基于文件的配置，以便提供比使用命令行选项（命令行依然有效，仍受支持）更灵活的方式。对配置文件的支持还使得在即将发布的版本中更容易提供更多改进措施。

结构化身份认证配置的好处

以下是使用配置文件来配置集群身份认证的好处：

多个 JWT 认证组件：你可以同时配置多个 JWT 认证组件。这允许你使用多个身份提供程序（例如 Okta、Keycloak、GitLab）而无需使用像 Dex 这样的中间程序来处理多个身份提供程序之间的多路复用。
动态配置：你可以在不重启 API 服务器的情况下更改配置。这允许你添加、移除或修改认证组件而不会中断 API 服务器。

任何符合 JWT 标准的令牌：你可以使用任何符合 JWT 标准的令牌进行身份认证。这允许你使用任何支持 JWT 的身份提供程序的令牌。最小有效的 JWT 载荷必须包含 Kubernetes 文档中结构化身份认证配置页面中记录的申领。
CEL（通用表达式语言）支持：你可以使用 CEL 来确定令牌的申领是否与 Kubernetes 中用户的属性（例如用户名、组）匹配。这允许你使用复杂逻辑来确定令牌是否有效。

多个受众群体：你可以为单个认证组件配置多个受众群体。这允许你为多个受众群体使用相同的认证组件，例如为 kubectl 和仪表板使用不同的 OAuth 客户端。
使用不支持 OpenID 连接发现的身份提供程序：你可以使用不支持 OpenID 连接发现的身份提供程序。唯一的要求是将发现文档托管到与签发方不同的位置（例如在集群中本地），并在配置文件中指定 issuer.discoveryURL。

如何使用结构化身份认证配置

要使用结构化身份认证配置，你可以使用 --authentication-config 命令行参数在 API 服务器中指定身份认证配置的路径。此配置文件是一个 YAML 文件，指定认证组件及其配置。以下是一个配置两个 JWT 认证组件的示例配置文件：

apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
# 如果某人具有这些 issuer 之一签发的有效令牌，则此人可以在集群上进行身份认证
jwt:
- issuer:
 url: https://issuer1.example.com
 audiences:
 - audience1
 - audience2
 audienceMatchPolicy: MatchAny
 claimValidationRules:
 expression: 'claims.hd == "example.com"'
 message: "the hosted domain name must be example.com"
 claimMappings:
 username:
 expression: 'claims.username'
 groups:
 expression: 'claims.groups'
 uid:
 expression: 'claims.uid'
 extra:
 - key: 'example.com/tenant'
 expression: 'claims.tenant'
 userValidationRules:
 - expression: "!user.username.startsWith('system:')"
 message: "username cannot use reserved system: prefix"
# 第二个认证组件将发现文档公布于与签发方不同的位置
- issuer:
 url: https://issuer2.example.com
 discoveryURL: https://discovery.example.com/.well-known/openid-configuration
 audiences:
 - audience3
 - audience4
 audienceMatchPolicy: MatchAny
 claimValidationRules:
 expression: 'claims.hd == "example.com"'
 message: "the hosted domain name must be example.com"
 claimMappings:
 username:
 expression: 'claims.username'
 groups:
 expression: 'claims.groups'
 uid:
 expression: 'claims.uid'
 extra:
 - key: 'example.com/tenant'
 expression: 'claims.tenant'
 userValidationRules:
 - expression: "!user.username.startsWith('system:')"
 message: "username cannot use reserved system: prefix"

从命令行参数迁移到配置文件

结构化身份认证配置特性旨在与基于命令行选项配置 JWT 认证组件的现有方法向后兼容。这意味着你可以继续使用现有的命令行选项来配置 JWT 认证组件。但是，我们（Kubernetes SIG Auth）建议迁移到新的基于配置文件的方法，因为这种方法更灵活，更好扩展。

Note

如果你同时指定 --authentication-config 和任何 --oidc-* 命令行参数，这是一种错误的配置。在这种情况下，API 服务器会报告错误，然后立即退出。

如果你想切换到使用结构化身份认证配置，你必须移除 --oidc-* 命令行参数，并改为使用配置文件。

以下是如何从命令行标志迁移到配置文件的示例：

命令行参数

--oidc-issuer-url=https://issuer.example.com
--oidc-client-id=example-client-id
--oidc-username-claim=username
--oidc-groups-claim=groups
--oidc-username-prefix=oidc:
--oidc-groups-prefix=oidc:
--oidc-required-claim="hd=example.com"
--oidc-required-claim="admin=true"
--oidc-ca-file=/path/to/ca.pem

在配置文件中没有与 --oidc-signing-algs 相对应的配置项。对于 Kubernetes v1.30，认证组件支持在 oidc.go 中列出的所有非对称算法。

配置文件

apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
jwt:
- issuer:
 url: https://issuer.example.com
 audiences:
 - example-client-id
 certificateAuthority: <取值是 /path/to/ca.pem 文件的内容>
 claimMappings:
 username:
 claim: username
 prefix: "oidc:"
 groups:
 claim: groups
 prefix: "oidc:"
 claimValidationRules:
 - claim: hd
 requiredValue: "example.com"
 - claim: admin
 requiredValue: "true"

下一步是什么？

对于 Kubernetes v1.31，我们预计该特性将保持在 Beta，我们要收集更多反馈意见。在即将发布的版本中，我们希望调查以下内容：

通过 CEL 表达式使分布式申领生效。
对 issuer.url 和 issuer.discoveryURL 的调用提供 Egress 选择算符配置支持。

你可以在 Kubernetes 文档的结构化身份认证配置页面上了解关于此特性的更多信息。你还可以通过 KEP-3331 跟踪未来 Kubernetes 版本中的进展。

试用一下

在本文中，我介绍了结构化身份认证配置特性在 Kubernetes v1.30 中带来的好处。要使用此特性，你必须使用 --authentication-config 命令行参数指定身份认证配置的路径。从 Kubernetes v1.30 开始，此特性处于 Beta 并默认启用。如果你希望继续使用命令行参数而不想用配置文件，原来的命令行参数也将继续按原样起作用。

我们很高兴听取你对此特性的反馈意见。请在 Kubernetes Slack 上的 #sig-auth-authenticators-dev 频道与我们联系（若要获取邀请，请访问 https://slack.k8s.io/）。

如何参与

如果你有兴趣参与此特性的开发、分享反馈意见或参与任何其他 SIG Auth 项目，请在 Kubernetes Slack 上的 #sig-auth 频道联系我们。

我们也欢迎你参加 SIG Auth 双周会议。

Kubernetes 1.30：验证准入策略 ValidatingAdmissionPolicy 正式发布

Wed, 24 Apr 2024 00:00:00 +0000

我代表 Kubernetes 项目组成员，很高兴地宣布 ValidatingAdmissionPolicy 已经作为 Kubernetes 1.30 发布的一部分正式发布。如果你还不了解这个全新的声明式验证准入 Webhook 的替代方案，请参阅有关这个新特性的上一篇博文。如果你已经对 ValidatingAdmissionPolicy 有所了解并且想要尝试一下，那么现在是最好的时机。

让我们替换一个简单的 Webhook，体验一下 ValidatingAdmissionPolicy。

准入 Webhook 示例

首先，让我们看一个简单 Webhook 的示例。以下是一个强制将 runAsNonRoot、readOnlyRootFilesystem、allowPrivilegeEscalation 和 privileged 设置为最低权限值的 Webhook 代码片段。

func verifyDeployment(deploy *appsv1.Deployment) error {
 var errs []error
 for i, c := range deploy.Spec.Template.Spec.Containers {
 if c.Name == "" {
 return fmt.Errorf("container %d has no name", i)
 }
 if c.SecurityContext == nil {
 errs = append(errs, fmt.Errorf("container %q does not have SecurityContext", c.Name))
 }
 if c.SecurityContext.RunAsNonRoot == nil || !*c.SecurityContext.RunAsNonRoot {
 errs = append(errs, fmt.Errorf("container %q must set RunAsNonRoot to true in its SecurityContext", c.Name))
 }
 if c.SecurityContext.ReadOnlyRootFilesystem == nil || !*c.SecurityContext.ReadOnlyRootFilesystem {
 errs = append(errs, fmt.Errorf("container %q must set ReadOnlyRootFilesystem to true in its SecurityContext", c.Name))
 }
 if c.SecurityContext.AllowPrivilegeEscalation != nil && *c.SecurityContext.AllowPrivilegeEscalation {
 errs = append(errs, fmt.Errorf("container %q must NOT set AllowPrivilegeEscalation to true in its SecurityContext", c.Name))
 }
 if c.SecurityContext.Privileged != nil && *c.SecurityContext.Privileged {
 errs = append(errs, fmt.Errorf("container %q must NOT set Privileged to true in its SecurityContext", c.Name))
 }
 }
 return errors.NewAggregate(errs)
}

查阅什么是准入 Webhook？，或者查看这个 Webhook 的完整代码以便更好地理解下述演示。

策略

现在，让我们尝试使用 ValidatingAdmissionPolicy 来忠实地重新创建验证。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
 name: "pod-security.policy.example.com"
spec:
 failurePolicy: Fail
 matchConstraints:
 resourceRules:
 - apiGroups: ["apps"]
 apiVersions: ["v1"]
 operations: ["CREATE", "UPDATE"]
 resources: ["deployments"]
 validations:
 - expression: object.spec.template.spec.containers.all(c, has(c.securityContext) && has(c.securityContext.runAsNonRoot) && c.securityContext.runAsNonRoot)
 message: 'all containers must set runAsNonRoot to true'
 - expression: object.spec.template.spec.containers.all(c, has(c.securityContext) && has(c.securityContext.readOnlyRootFilesystem) && c.securityContext.readOnlyRootFilesystem)
 message: 'all containers must set readOnlyRootFilesystem to true'
 - expression: object.spec.template.spec.containers.all(c, !has(c.securityContext) || !has(c.securityContext.allowPrivilegeEscalation) || !c.securityContext.allowPrivilegeEscalation)
 message: 'all containers must NOT set allowPrivilegeEscalation to true'
 - expression: object.spec.template.spec.containers.all(c, !has(c.securityContext) || !has(c.securityContext.Privileged) || !c.securityContext.Privileged)
 message: 'all containers must NOT set privileged to true'

使用 kubectl 创建策略。很好，到目前为止没有任何问题。那我们获取此策略对象并查看其状态。

kubectl get -oyaml validatingadmissionpolicies/pod-security.policy.example.com

 status:
 typeChecking:
 expressionWarnings:
 - fieldRef: spec.validations[3].expression
 warning: |
 apps/v1, Kind=Deployment: ERROR: <input>:1:76: undefined field 'Privileged'
 | object.spec.template.spec.containers.all(c, !has(c.securityContext) || !has(c.securityContext.Privileged) || !c.securityContext.Privileged)
 | ...........................................................................^
 ERROR: <input>:1:128: undefined field 'Privileged'
 | object.spec.template.spec.containers.all(c, !has(c.securityContext) || !has(c.securityContext.Privileged) || !c.securityContext.Privileged)
 | ...............................................................................................................................^

系统根据所匹配的类别 apps/v1.Deployment 对策略执行了检查。查看 fieldRef 后，发现问题出现在第 3 个表达式上（索引从 0 开始）。有问题的表达式访问了一个未定义的 Privileged 字段。噢，看起来是一个复制粘贴错误。字段名应该是小写的。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
 name: "pod-security.policy.example.com"
spec:
 failurePolicy: Fail
 matchConstraints:
 resourceRules:
 - apiGroups: ["apps"]
 apiVersions: ["v1"]
 operations: ["CREATE", "UPDATE"]
 resources: ["deployments"]
 validations:
 - expression: object.spec.template.spec.containers.all(c, has(c.securityContext) && has(c.securityContext.runAsNonRoot) && c.securityContext.runAsNonRoot)
 message: 'all containers must set runAsNonRoot to true'
 - expression: object.spec.template.spec.containers.all(c, has(c.securityContext) && has(c.securityContext.readOnlyRootFilesystem) && c.securityContext.readOnlyRootFilesystem)
 message: 'all containers must set readOnlyRootFilesystem to true'
 - expression: object.spec.template.spec.containers.all(c, !has(c.securityContext) || !has(c.securityContext.allowPrivilegeEscalation) || !c.securityContext.allowPrivilegeEscalation)
 message: 'all containers must NOT set allowPrivilegeEscalation to true'
 - expression: object.spec.template.spec.containers.all(c, !has(c.securityContext) || !has(c.securityContext.privileged) || !c.securityContext.privileged)
 message: 'all containers must NOT set privileged to true'

再次检查状态，你应该看到所有警告都已被清除。

接下来，我们创建一个命名空间进行测试。

kubectl create namespace policy-test

接下来，我将策略绑定到命名空间。但此时我将动作设置为 Warn，这样此策略将打印出警告而不是拒绝请求。这对于在开发和自动化测试期间收集所有表达式的结果非常有用。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
 name: "pod-security.policy-binding.example.com"
spec:
 policyName: "pod-security.policy.example.com"
 validationActions: ["Warn"]
 matchResources:
 namespaceSelector:
 matchLabels:
 "kubernetes.io/metadata.name": "policy-test"

测试策略的执行过程。

kubectl create -n policy-test -f- <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
 labels:
 app: nginx
 name: nginx
spec:
 selector:
 matchLabels:
 app: nginx
 template:
 metadata:
 labels:
 app: nginx
 spec:
 containers:
 - image: nginx
 name: nginx
 securityContext:
 privileged: true
 allowPrivilegeEscalation: true
EOF

Warning: Validation failed for ValidatingAdmissionPolicy 'pod-security.policy.example.com' with binding 'pod-security.policy-binding.example.com': all containers must set runAsNonRoot to true
Warning: Validation failed for ValidatingAdmissionPolicy 'pod-security.policy.example.com' with binding 'pod-security.policy-binding.example.com': all containers must set readOnlyRootFilesystem to true
Warning: Validation failed for ValidatingAdmissionPolicy 'pod-security.policy.example.com' with binding 'pod-security.policy-binding.example.com': all containers must NOT set allowPrivilegeEscalation to true
Warning: Validation failed for ValidatingAdmissionPolicy 'pod-security.policy.example.com' with binding 'pod-security.policy-binding.example.com': all containers must NOT set privileged to true
Error from server: error when creating "STDIN": admission webhook "webhook.example.com" denied the request: [container "nginx" must set RunAsNonRoot to true in its SecurityContext, container "nginx" must set ReadOnlyRootFilesystem to true in its SecurityContext, container "nginx" must NOT set AllowPrivilegeEscalation to true in its SecurityContext, container "nginx" must NOT set Privileged to true in its SecurityContext]

看起来很不错！策略和 Webhook 给出了等效的结果。又测试了其他几种情形后，当我们对策略有信心时，也许是时候进行一些清理工作了。

对于每个表达式，我们重复访问 object.spec.template.spec.containers 和每个 securityContext；
有一个检查某字段是否存在然后访问该字段的模式，这种模式看起来有点繁琐。

幸运的是，自 Kubernetes 1.28 以来，我们对这两个问题都有了新的解决方案。变量组合（Variable Composition）允许我们将重复的子表达式提取到单独的变量中。 Kubernetes 允许为 CEL 使用可选库，这些库非常适合处理可选的字段，你猜对了。

在了解了这两个特性后，让我们稍微重构一下此策略。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
 name: "pod-security.policy.example.com"
spec:
 failurePolicy: Fail
 matchConstraints:
 resourceRules:
 - apiGroups: ["apps"]
 apiVersions: ["v1"]
 operations: ["CREATE", "UPDATE"]
 resources: ["deployments"]
 variables:
 - name: containers
 expression: object.spec.template.spec.containers
 - name: securityContexts
 expression: 'variables.containers.map(c, c.?securityContext)'
 validations:
 - expression: variables.securityContexts.all(c, c.?runAsNonRoot == optional.of(true))
 message: 'all containers must set runAsNonRoot to true'
 - expression: variables.securityContexts.all(c, c.?readOnlyRootFilesystem == optional.of(true))
 message: 'all containers must set readOnlyRootFilesystem to true'
 - expression: variables.securityContexts.all(c, c.?allowPrivilegeEscalation != optional.of(true))
 message: 'all containers must NOT set allowPrivilegeEscalation to true'
 - expression: variables.securityContexts.all(c, c.?privileged != optional.of(true))
 message: 'all containers must NOT set privileged to true'

策略现在更简洁、更易读。更新策略后，你应该看到它的功用与之前无异。

现在让我们将策略绑定从警告更改为实际拒绝验证失败的请求。

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
 name: "pod-security.policy-binding.example.com"
spec:
 policyName: "pod-security.policy.example.com"
 validationActions: ["Deny"]
 matchResources:
 namespaceSelector:
 matchLabels:
 "kubernetes.io/metadata.name": "policy-test"

最后，移除 Webhook。现在结果应该只包含来自策略的消息。

kubectl create -n policy-test -f- <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
 labels:
 app: nginx
 name: nginx
spec:
 selector:
 matchLabels:
 app: nginx
 template:
 metadata:
 labels:
 app: nginx
 spec:
 containers:
 - image: nginx
 name: nginx
 securityContext:
 privileged: true
 allowPrivilegeEscalation: true
EOF

The deployments "nginx" is invalid: : ValidatingAdmissionPolicy 'pod-security.policy.example.com' with binding 'pod-security.policy-binding.example.com' denied request: all containers must set runAsNonRoot to true

请注意，根据设计，此策略在第一个导致请求被拒绝的表达式之后停止处理。这与表达式只生成警告时的情况不同。

设置监控

与 Webhook 不同，策略不是一个可以公开其自身指标的专用进程。相反，你可以使用源自 API 服务器的指标来代替。

以下是使用 Prometheus 查询语言执行一些常见监控任务的示例。

找到上述策略执行期间的 95 分位值：

histogram_quantile(0.95, sum(rate(apiserver_validating_admission_policy_check_duration_seconds_bucket{policy="pod-security.policy.example.com"}[5m])) by (le))

找到策略评估的速率：

rate(apiserver_validating_admission_policy_check_total{policy="pod-security.policy.example.com"}[5m])

你可以阅读指标参考了解有关上述指标的更多信息。 ValidatingAdmissionPolicy 的指标目前处于 Alpha 阶段，随着稳定性在未来版本中的提升，将会有更多和更好的指标。

Kubernetes 1.30：只读卷挂载终于可以真正实现只读了

Tue, 23 Apr 2024 00:00:00 +0000

作者: Akihiro Suda (NTT)

译者: Xin Li (DaoCloud)

只读卷挂载从一开始就是 Kubernetes 的一个特性。令人惊讶的是，在 Linux 上的某些条件下，只读挂载并不是完全只读的。从 v1.30 版本开始，这类卷挂载可以被处理为完全只读；v1.30 为递归只读挂载提供 Alpha 支持。

默认情况下，只读卷装载并不是真正的只读

卷挂载可能看似复杂。

你可能期望以下清单使容器中 /mnt 下的所有内容变为只读：

---
apiVersion: v1
kind: Pod
spec:
 volumes:
 - name: mnt
 hostPath:
 path: /mnt
 containers:
 - volumeMounts:
 - name: mnt
 mountPath: /mnt
 readOnly: true

但是，/mnt 下的任何子挂载可能仍然是可写的！例如，假设 /mnt/my-nfs-server 在主机上是可写的。在容器内部，写入 /mnt/* 将被拒绝，但 /mnt/my-nfs-server/* 仍然可写。

新的挂载选项：递归只读

Kubernetes 1.30 添加了一个新的挂载选项 recursiveReadOnly，以使子挂载递归只读。

可以按如下方式启用该选项：

---
apiVersion: v1
kind: Pod
spec:
 volumes:
 - name: mnt
 hostPath:
 path: /mnt
 containers:
 - volumeMounts:
 - name: mnt
 mountPath: /mnt
 readOnly: true
 # NEW
 # 可能的值为 `Enabled`、`IfPossible` 和 `Disabled`。
 # 需要与 `readOnly: true` 一起指定。
 recursiveReadOnly: Enabled

这是通过使用 Linux 内核 v5.12 中添加的 mount_setattr(2) 应用带有 AT_RECURSIVE 标志的 MOUNT_ATTR_RDONLY 属性来实现的。

为了向后兼容，recursiveReadOnly 字段不是 readOnly 的替代品，而是与其结合使用。要获得正确的递归只读挂载，你必须设置这两个字段。

特性可用性

要启用 recursiveReadOnly 挂载，必须使用以下组件：

Kubernetes：v1.30 或更新版本，并启用 RecursiveReadOnlyMounts 特性门控。从 v1.30 开始，此特性被标记为 Alpha。
CRI 运行时：
- containerd：v2.0 或更新版本
OCI 运行时：
- runc：v1.1 或更新版本
- crun: v1.8.6 或更新版本
Linux 内核: v5.12 或更新版本

接下来

Kubernetes SIG Node 希望并期望该特性将在 Kubernetes 的未来版本中升级为 Beta 版本并最终稳定可用（GA），以便用户不再需要手动启用此特性门控。

为了向后兼容，recursive ReadOnly 的默认值仍将保持 Disabled。

怎样才能了解更多？

请查看文档以获取 recursiveReadOnly 挂载的更多详细信息。

如何参与？

此特性由 SIG Node 社区推动。请加入我们，与社区建立联系，并分享你对上述特性及其他特性的想法和反馈。我们期待你的回音！

Kubernetes 1.30：对 Pod 使用用户命名空间的支持进阶至 Beta

Mon, 22 Apr 2024 00:00:00 +0000

Linux 提供了不同的命名空间来将进程彼此隔离。例如，一个典型的 Kubernetes Pod 运行在一个网络命名空间中可以隔离网络身份，运行在一个 PID 命名空间中可以隔离进程。

Linux 有一个以前一直未被容器化应用所支持的命名空间是用户命名空间。这个命名空间允许我们将容器内使用的用户标识符和组标识符（UID 和 GID）与主机上的标识符隔离开来。

这是一个强大的抽象，允许我们以 “root” 身份运行容器：我们在容器内部有 root 权限，可以在 Pod 内执行所有 root 能做的操作，但我们与主机的交互仅限于非特权用户可以执行的操作。这对于限制容器逃逸的影响非常有用。

容器逃逸是指容器内的进程利用容器运行时或内核中的某些未打补丁的漏洞逃逸到主机上，并可以访问/修改主机或其他容器上的文件。如果我们以用户命名空间运行我们的 Pod，容器对主机其余部分的特权将减少，并且此容器可以访问的容器外的文件也将受到限制。

在 Kubernetes v1.25 中，我们仅为无状态 Pod 引入了对用户命名空间的支持。 Kubernetes 1.28 取消了这一限制，目前在 Kubernetes 1.30 中，这个特性进阶到了 Beta！

什么是用户命名空间？

注意：Linux 用户命名空间与 Kubernetes 命名空间是不同的概念。前者是一个 Linux 内核特性；后者是一个 Kubernetes 特性。

用户命名空间是一个 Linux 特性，它将容器的 UID 和 GID 与主机上的隔离开来。容器中的标识符可以被映射为主机上的标识符，并且保证不同容器所使用的主机 UID/GID 不会重叠。此外，这些标识符可以被映射到主机上没有特权的、非重叠的 UID 和 GID。这带来了两个关键好处：

防止横向移动：由于不同容器的 UID 和 GID 被映射到主机上的不同 UID 和 GID，即使这些标识符逃出了容器的边界，容器之间也很难互相攻击。例如，假设容器 A 在主机上使用的 UID 和 GID 与容器 B 不同。在这种情况下，它对容器 B 的文件和进程的操作是有限的：只能读取/写入某文件所允许的操作，因为它永远不会拥有文件所有者或组权限（主机上的 UID/GID 保证对不同容器是不同的）。

增加主机隔离：由于 UID 和 GID 被映射到主机上的非特权用户，如果某容器逃出了它的边界，即使它在容器内部以 root 身份运行，它在主机上也没有特权。这大大保护了它可以读取/写入的主机文件，它可以向哪个进程发送信号等。此外，所授予的权能仅在用户命名空间内有效，而在主机上无效，这就限制了容器逃逸的影响。

用户命名空间 ID 分配

如果不使用用户命名空间，容器逃逸时以 root 运行的容器在节点上将具有 root 特权。如果某些权能授权给了此容器，这些权能在主机上也会有效。如果使用用户命名空间，就不会是这种情况（当然，除非有漏洞 🙂）。

1.30 的变化

在 Kubernetes 1.30 中，除了将用户命名空间进阶至 Beta，参与此特性的贡献者们还：

为 kubelet 引入了一种使用自定义范围进行 UID/GID 映射的方式
为 Kubernetes 添加了一种强制执行的方式让运行时支持用户命名空间所需的所有特性。如果不支持这些特性，Kubernetes 在尝试创建具有用户命名空间的 Pod 时，会显示一个明确的错误。在 1.30 之前，如果容器运行时不支持用户命名空间，Pod 可能会在没有用户命名空间的情况下被创建。
新增了更多的测试，包括在 cri-tools 仓库中的测试。

你可以查阅有关用户命名空间的文档，了解如何配置映射的自定义范围。

演示

几个月前，CVE-2024-21626 被披露。这个 漏洞评分为 8.6（高）。它允许攻击者让容器逃逸，并读取/写入节点上的任何路径以及同一节点上托管的其他 Pod。

Rodrigo 创建了一个滥用 CVE 2024-21626 的演示，演示了此漏洞在没有用户命名空间时的工作方式，而在使用用户命名空间后 得到了缓解。

请注意，使用用户命名空间时，攻击者可以在主机文件系统上执行“其他”权限位所允许的操作。因此，此 CVE 并没有完全被修复，但影响大大降低。

节点系统要求

使用此特性对 Linux 内核版本和容器运行时有一些要求。

在 Linux 上，你需要 Linux 6.3 或更高版本。这是因为此特性依赖于一个名为 idmap 挂载的内核特性，而支持 idmap 挂载与 tmpfs 一起使用的特性是在 Linux 6.3 中合并的。

假设你使用 CRI-O 和 crun；就像往常一样，你可以期待 CRI-O 1.30 支持 Kubernetes 1.30。请注意，你还需要 crun 1.9 或更高版本。如果你使用的是 CRI-O 和 runc，则仍然不支持用户命名空间。

containerd 对此特性的支持目前锁定为 containerd 2.0，同样 crun 也有适用的版本要求。如果你使用的是 containerd 和 runc，则仍然不支持用户命名空间。

请注意，正如在 Kubernetes 1.25 和 1.26 中实现的那样，containerd 1.7 增加了对用户命名空间的实验性支持。我们曾在 Kubernetes 1.27 中进行了重新设计，所以容器运行时需要做一些变更。而 containerd 1.7 并未包含这些变更，所以它仅在 Kubernetes 1.25 和 1.26 中支持使用用户命名空间。

containerd 1.7 的另一个限制是，它需要在 Pod 启动期间变更容器镜像内的每个文件和目录的所有权。这会增加存储开销，并可能显著影响容器启动延迟。containerd 2.0 可能会包含一个实现，以消除增加的启动延迟和存储开销。如果你计划在生产环境中使用 containerd 1.7 和用户命名空间，请考虑这一点。

containerd 1.7 的这些限制均不适用于 CRI-O。

如何参与？

你可以通过以下方式联系 SIG Node：

你也可以通过以下方式直接联系我们：

GitHub：@rata @giuseppe @saschagrunert
Slack：@rata @giuseppe @sascha

SIG Architecture 特别报道：代码组织

Thu, 11 Apr 2024 00:00:00 +0000

作者: Frederico Muñoz (SAS Institute)

译者: Xin Li (DaoCloud)

这是 SIG Architecture Spotlight 系列的第三次采访，该系列将涵盖不同的子项目。我们将介绍 SIG Architecture：代码组织。

在本次 SIG Architecture 聚焦中，我与代码组织子项目的成员 Madhav Jivrajani（VMware）进行了交谈。

介绍代码组织子项目

Frederico (FSM)：你好，Madhav，感谢你百忙之中接受我们的采访。你能否首先向我们介绍一下你自己、你的角色以及你是如何参与 Kubernetes 的？

Madhav Jivrajani (MJ)：你好！我叫 Madhav Jivrajani，担任 SIG 贡献者体验的技术主管和 Kubernetes 项目的 GitHub 管理员。除此之外，我还为 SIG API Machinery 和 SIG Etcd 做出贡献，但最近，我一直在帮助完成 Kubernetes 保留受支持的 Go 版本所需的工作，正是通过这一点，参与到了 SIG Architecture 的代码组织子项目中。

FSM：像 Kubernetes 这样规模的项目在代码组织方面肯定会遇到独特的挑战 -- 这是一个合理的假设吗？如果是这样，你认为 Kubernetes 特有的一些主要挑战是什么？

MJ：这是一个合理的假设！第一个有趣的挑战来自 Kubernetes 代码库的庞大规模。我们有大约 220 万行 Go 代码（由于 dims 和这个子项目中的其他人的努力，该代码正在稳步减少！），而且我们的依赖项（无论是直接还是间接）超过 240 个，这就是为什么拥有一个致力于帮助进行依赖项管理的子项目至关重要：我们需要知道我们正在引入哪些依赖项，这些依赖项处于什么版本，以及帮助确保我们能够以一致的方式管理代码库不同部分的依赖关系的工具。以一致的方式管理代码库不同部分的这些依赖关系。

Kubernetes 的另一个有趣的挑战是，我们在 Kubernetes 发布周期中发布了许多 Go 模块，其中一个例子是 client-go。然而，作为一个项目，我们也希望将所有内容都放在一个仓库中，便获得使用单一仓库的优势，例如原子性的提交…… 因此，代码组织与其他 SIG（例如 SIG Release）合作，以实现将代码从单一仓库发布到下游仓库的自动化过程，下游仓库更容易使用，因为你就不必导入整个 Kubernetes 代码库！

代码组织和 Kubernetes

FSM：对于刚刚开始为 Kubernetes 代码做出贡献的人来说，在代码组织方面他们应该考虑的主要事项是什么？你认为有哪些关键概念？

MJ：我认为至少在开始时要记住的关键事情之一是 staging 目录的概念。在 kubernetes/kubernetes 中，你会遇到一个名为 staging/ 的目录。该目录中的子文件夹充当一堆伪仓库。例如，发布 client-go 版本的 kubernetes/client-go 仓库实际上是一个 staging 仓库。

FSM：那么 staging 目录的概念会从根本上影响贡献？

MJ：准确地说，因为如果你想为任何 staging 仓库做出贡献，你需要将 PR 发送到 kubernetes/kubernetes 中相应的 staging 目录。一旦代码合并到那里，我们就会让一个名为 publishing-bot 的机器人将合并的提交同步到必要的 staging 仓库（例如 kubernetes/client-go）中。通过这种方式，我们可以获得单一仓库的好处，但我们也可以以模块化的形式发布代码以供下游使用。 PS：publishing-bot 需要更多人的帮助！

FSM：说到贡献，贡献者数量非常多，包括个人和公司，也一定是一个挑战：这个子项目是如何运作的以确保大家都遵循标准呢？

MJ：当涉及到项目中的依赖关系管理时，有一个专门团队帮助审查和批准依赖关系更改。这些人为目前 Kubernetes 用于管理依赖的许多工具做了开拓性的工作。这些工具帮助我们确保贡献者可以以一致的方式更改依赖项。这个子项目还开发了其他工具来基于被添加或删除的依赖项的统计信息发出通知： depstat

除了依赖管理之外，这个项目执行的另一项重要任务是管理 staging 仓库。用于实现此目的的工具（publishing-bot）对贡献者完全透明，有助于确保就提交给 kubernetes/kubernetes 的贡献而言，各个 staging 仓库获得的视图是一致的。

代码组织还致力于确保 Kubernetes 一直在使用受支持的 Go 版本。链接所指向的 KEP 中包含更详细的背景信息，用来说明为什么我们需要这样做。我们与 SIG Release 合作，确保我们在 Go 版本上尽可能严格、尽早地测试 Kubernetes；作为这些工作的一部分，我们要处理会破坏我们的 CI 的那些变更。我们如何跟踪此过程的示例可以在此处找到。

发布周期和当前优先级

FSM：在发布周期中有什么变化吗？

MJ：在发布周期内，特别是在代码冻结之前，通常会发生添加、更新、删除依赖项的变更，以及修复需要修复的代码等更改，这些都是我们继续使用受支持的 Go 版本的努力的一部分。

此外，其中一些更改也可以向后移植到我们支持的发布分支。

FSM：就子项目中目前正在进行的主要项目或主题而言你有什么要特别强调的吗？

MJ：我认为最近添加的一个非常有趣且非常有用的变更（我借这个机会特别强调 Tim Hockin 在这方面的工作）是引入 Go 工作空间的概念到Kubernetes 仓库中。我们当前的许多依赖管理和代码发布工具，以及在 Kubernetes 仓库中编辑代码的体验，都可以通过此更改得到显着改善。

收尾

FSM：对这个主题感兴趣的人要怎样开始帮助这个子项目？

MJ：与 Kubernetes 中任何项目的第一步一样，第一步是加入我们的 Slack：slack.k8s.io，然后加入 #k8s-code-organization 频道，你还可以选择参加代码组织办公时间。时区是个困难点，所以请随时查看录音或会议记录并跟进 Slack！

FSM：非常好，谢谢！最后你还有什么想分享的吗？

MJ：代码组织子项目总是需要帮助！特别是像发布机器人这样的领域，所以请不要犹豫，参与到 #k8s-code-organization Slack 频道中。

Kubernetes v1.30 初探

Tue, 12 Mar 2024 00:00:00 +0000

作者: Amit Dsouza, Frederick Kautz, Kristin Martin, Abigail McCarthy, Natali Vlatko

译者: Paco Xu (DaoCloud)

快速预览：Kubernetes v1.30 中令人兴奋的变化

新年新版本，v1.30 发布周期已过半，我们将迎来一系列有趣且令人兴奋的增强功能。从全新的 alpha 特性，到已有的特性升级为稳定版，再到期待已久的改进，这个版本对每个人都有值得关注的内容！

为了让你在正式发布之前对其有所了解，下面给出我们在这个周期中最为期待的增强功能的预览！

Kubernetes v1.30 的主要变化

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

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

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

节点交换内存 SWAP 支持 (KEP-2400)

在 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 中 Linux 节点交换支持的更多详细信息。

支持 Pod 运行在用户命名空间 (KEP-127)

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

结构化鉴权配置(KEP-3221)

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

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

基于容器资源指标的 Pod 自动扩缩容 (KEP-1610)

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

在准入控制中使用 CEL (KEP-3488)

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

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

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

走进 Kubernetes 读书会（Book Club）

Thu, 22 Feb 2024 00:00:00 +0000

学习 Kubernetes 及其整个生态的技术并非易事。在本次采访中，我们的访谈对象是 Carlos Santana (AWS)，了解他是如何创办 Kubernetes 读书会（Book Club）的，整个读书会是如何运作的，以及大家如何加入其中，进而更好地利用社区学习体验。

Frederico Muñoz (FSM)：你好 Carlos，非常感谢你能接受我们的采访。首先，你能介绍一下自己吗？

Carlos Santana (CS)：当然可以。六年前，我在生产环境中部署 Kubernetes 的经验为我加入 Knative 并通过 Release Team 为 Kubernetes 贡献代码打开了大门。为上游 Kubernetes 工作是我在开源领域最好的经历之一。在过去的两年里，作为 AWS 的高级专业解决方案架构师，我一直在帮助大型企业在 Kubernetes 之上构建他们的内部开发平台（IDP）。未来我的开源贡献将主要集中在 CNOE 和 CNCF 项目，如 Argo、Crossplane 和 Backstage。

创办读书会

FSM：所以你的职业道路把你引向了 Kubernetes，那么是什么动机促使你开始创办读书会呢？

CS：Kubernetes 读书会的想法源于一次 TGIK 直播中的一个临时建议。对我来说，这不仅仅是读一本书，更是创办一个学习社区。这个社区平台不仅是知识的来源，也是一个支持系统，特别是在疫情期间陪我度过了艰难时刻。读书会的这项倡议后来帮助许多成员学会了应对和成长，这让我感到很欣慰。我们在 2021 年 3 月 5 日开始第一本书 Production Kubernetes，花了 36 周时间。目前，一本书不会再花那么长时间了，如今每周会完成一到两章。

FSM：你能介绍一下 Kubernetes 读书会是如何运作的吗？你们如何选书以及如何阅读它们？

CS：我们根据小组的兴趣和需求以集体的方式选书。这种实用的方法有助于成员们（特别是初学者）更容易地掌握复杂的概念。我们每周有两次读书会应对不同的时区，一个针对 EMEA（欧洲、中东及非洲）时区，另一个是由我自己负责的美国时区。每位组织者与他们的联合主持人在 Slack 上甄选一本书，然后安排几个主持人用几周时间讨论每一章。

FSM：如果我没记错的话，Kubernetes 读书会如今已经进行到了第 17 本书。这很了不起：有什么秘诀可以让读书这件事保持活跃吗？

CS：保持俱乐部活跃和吸引人参与的秘诀在于几个关键因素。

首先，一贯性至关重要。我们努力保持定期聚会，只有在重大事件如节假日或 KubeCon 时才会取消聚会。这种规律性有助于成员保持惯性参与，有助于建立一个可靠的社区。

其次，让聚会有趣生动也非常重要。例如，我经常在聚会期间引入提问测验，不仅检测成员们的理解程度，还增加了一些乐趣。这种方法使读书内容更加贴近实际，并帮助成员们理解理论概念在现实世界中的运用方式。

读书会涵盖的话题

FSM：书籍的主要话题包括 Kubernetes、GitOps、安全、SRE 和可观测性：这是否也反映了云原生领域的现状，特别是在受欢迎程度方面？

CS：我们的旅程始于《Production Kubernetes》，为我们专注于实用、生产就绪的解决方案定下了基调。从那时起，我们深入探讨了 CNCF 领域的各个方面，根据不同的主题去选书。每个主题，无论是安全性、可观测性还是服务网格，都是根据其相关性和社区需求来选择的。例如，在我们最近关于 Kubernetes 考试认证的主题中，我们邀请了书籍的作者作为活跃现场的主持人，用他们的专业知识丰富了我们的讨论。

FSM：我了解到此项目最近有一些变化，即被整合到了 CNCF 作为云原生社区组（Cloud Native Community Group）的一部分。你能谈谈这个变化吗？

CS：CNCF 慷慨地接受了读书会作为云原生社区组的一部分。这是读书会发展过程中的重要一步，优化了读书会的运作并扩大了读书会的影响力。这种拉齐对于增强读书会的管理能力至关重要，这点很像 Kubernetes Community Days (KCD) 聚会。现在，读书会有了更稳健的会员结构、活动安排、邮件列表、托管的网络会议和录播系统。

FSM：在过去的六个月里，你参与 CNCF 这件事对 Kubernetes 读书会的成长和参与度产生了什么影响？

CS：自从六个月前成为 CNCF 社区的一部分以来，我们在 Kubernetes 读书会中看到了一些显著的变化。我们的会员人数激增至 600 多人，并在此期间成功组织并举办了超过 40 场活动。更令人鼓舞的是，每场活动的出席人数都很稳定，平均约有 30 人参加。这种增长和参与度清楚地表明了我们与 CNCF 的合作让 Kubernetes 读书会在社区中增强了影响力。

加入读书会

FSM：若有人想加入读书会，他们应该怎么做？

CS：加入读书会只需三步：

首先加入 Kubernetes 读书会社区
然后注册参与在社区页面上列出的活动
最后加入 CNCF Slack 频道 #kubernetes-book-club。

FSM：太好了，谢谢你！最后你还有什么想法要跟大家分享吗？

CS：Kubernetes 读书会不仅仅是一个讨论书籍的专业小组，它是一个充满活力的社区，有许多令人敬佩的志愿者帮助组织和主持聚会。我想借这次机会感谢几位志愿者： Neependra Khare、 Eric Smalling、 Sevi Karakulak、 Chad M. Crowell 和 Walid (CNJ) Shaari。欢迎来 KubeCon 与我们相聚，还能领取你的 Kubernetes 读书会贴纸！

镜像文件系统：配置 Kubernetes 将容器存储在独立的文件系统上

Tue, 23 Jan 2024 00:00:00 +0000

作者: Kevin Hannon (Red Hat)

译者: Michael Yao

磁盘空间不足是运行或操作 Kubernetes 集群时的一个常见问题。在制备节点时，你应该为容器镜像和正在运行的容器留足够的存储空间。容器运行时通常会向 /var 目录写入数据。此目录可以位于单独的分区或根文件系统上。CRI-O 默认将其容器和镜像写入 /var/lib/containers，而 containerd 将其容器和镜像写入 /var/lib/containerd。

在这篇博文中，我们想要关注的是几种不同方式，用来配置容器运行时将其内容存储到别的位置而非默认分区。这些配置允许我们更灵活地配置 Kubernetes，支持在保持默认文件系统不受影响的情况下为容器存储添加更大的磁盘。

需要额外讲述的是 Kubernetes 向磁盘在写入数据的具体位置及内容。

了解 Kubernetes 磁盘使用情况

Kubernetes 有持久数据和临时数据。kubelet 和特定于 Kubernetes 的本地存储的基础路径是可配置的，但通常假定为 /var/lib/kubelet。在 Kubernetes 文档中，这一位置有时被称为根文件系统或节点文件系统。写入的数据可以大致分类为：

临时存储
日志
容器运行时

与大多数 POSIX 系统不同，这里的根/节点文件系统不是 /，而是 /var/lib/kubelet 所在的磁盘。

临时存储

Pod 和容器的某些操作可能需要临时或瞬态的本地存储。临时存储的生命周期短于 Pod 的生命周期，且临时存储不能被多个 Pod 共享。

日志

默认情况下，Kubernetes 将每个运行容器的日志存储为 /var/log 中的文件。这些日志是临时性质的，并由 kubelet 负责监控以确保不会在 Pod 运行时变得过大。

你可以为每个节点自定义日志轮换设置，以管控这些日志的大小，并（使用第三方解决方案）配置日志转储以避免对节点本地存储形成依赖。

容器运行时

容器运行时针对容器和镜像使用两个不同的存储区域。

只读层：镜像通常被表示为只读层，因为镜像在容器处于运行状态期间不会被修改。只读层可以由多个层组成，这些层组合到一起形成最终的只读层。如果容器要向文件系统中写入数据，则在容器层之上会存在一个薄层为容器提供临时存储。

可写层：取决于容器运行时的不同实现，本地写入可能会用分层写入机制来实现（例如 Linux 上的 overlayfs 或 Windows 上的 CimFS）。这一机制被称为可写层。本地写入也可以使用一个可写文件系统来实现，该文件系统使用容器镜像的完整克隆来初始化；这种方式适用于某些基于 Hypervisor 虚拟化的运行时。

容器运行时文件系统包含只读层和可写层。在 Kubernetes 文档中，这一文件系统被称为 imagefs。

容器运行时配置

CRI-O

CRI-O 使用 TOML 格式的存储配置文件，让你控制容器运行时如何存储持久数据和临时数据。 CRI-O 使用了 containers-storage 库。某些 Linux 发行版为 containers-storage 提供了帮助手册条目（man 5 containers-storage.conf）。存储的主要配置位于 /etc/containers/storage.conf 中，你可以控制临时数据和根目录的位置。根目录是 CRI-O 存储持久数据的位置。

[storage]
# 默认存储驱动
driver = "overlay"
# 临时存储位置
runroot = "/var/run/containers/storage"
# 容器存储的主要读/写位置
graphroot = "/var/lib/containers/storage"

graphroot
- 存储来自容器运行时的持久数据
- 如果 SELinux 被启用，则此项必须是 /var/lib/containers/storage
runroot
- 容器的临时读/写访问
- 建议将其放在某个临时文件系统上

以下是为你的 graphroot 目录快速重新打标签以匹配 /var/lib/containers/storage 的方法：

semanage fcontext -a -e /var/lib/containers/storage <你的存储路径>
restorecon -R -v <你的存储路径>

containerd

containerd 运行时使用 TOML 配置文件来控制存储持久数据和临时数据的位置。配置文件的默认路径位于 /etc/containerd/config.toml。

与 containerd 存储的相关字段是 root 和 state。

root
- containerd 元数据的根目录
- 默认为 /var/lib/containerd
- 如果你的操作系统要求，需要为根目录设置 SELinux 标签
state
- containerd 的临时数据
- 默认为 /run/containerd

Kubernetes 节点压力驱逐

Kubernetes 将自动检测容器文件系统是否与节点文件系统分离。当你分离文件系统时，Kubernetes 负责同时监视节点文件系统和容器运行时文件系统。 Kubernetes 文档将节点文件系统称为 nodefs，将容器运行时文件系统称为 imagefs。如果 nodefs 或 imagefs 中有一个磁盘空间不足，则整个节点被视为有磁盘压力。这种情况下，Kubernetes 先通过删除未使用的容器和镜像来回收空间，之后会尝试驱逐 Pod。在同时具有 nodefs 和 imagefs 的节点上，kubelet 将在 imagefs 上对未使用的容器镜像执行垃圾回收，并从 nodefs 中移除死掉的 Pod 及其容器。如果只有 nodefs，则 Kubernetes 垃圾回收将包括死掉的容器、死掉的 Pod 和未使用的镜像。

Kubernetes 提供额外的配置方法来确定磁盘是否已满。kubelet 中的驱逐管理器有一些让你可以控制相关阈值的配置项。对于文件系统，相关测量值有 nodefs.available、nodefs.inodesfree、imagefs.available 和 imagefs.inodesfree。如果容器运行时没有专用磁盘，则 imagefs 被忽略。

用户可以使用现有的默认值：

memory.available < 100MiB
nodefs.available < 10%
imagefs.available < 15%
nodefs.inodesFree < 5%（Linux 节点）

Kubernetes 允许你在 kubelet 配置文件中将 EvictionHard 和 EvictionSoft 设置为用户定义的值。

EvictionHard: 定义限制；一旦超出这些限制，Pod 将被立即驱逐，没有任何宽限期。
EvictionSoft: 定义限制；一旦超出这些限制，Pod 将在按各信号所设置的宽限期后被驱逐。

如果你为 EvictionHard 指定了值，所设置的值将取代默认值。这意味着在你的配置中设置所有信号非常重要。

例如，以下 kubelet 配置可用于配置驱逐信号和宽限期选项。

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: "192.168.0.8"
port: 20250
serializeImagePulls: false
evictionHard:
 memory.available: "100Mi"
 nodefs.available: "10%"
 nodefs.inodesFree: "5%"
 imagefs.available: "15%"
 imagefs.inodesFree: "5%"
evictionSoft:
 memory.available: "100Mi"
 nodefs.available: "10%"
 nodefs.inodesFree: "5%"
 imagefs.available: "15%"
 imagefs.inodesFree: "5%"
evictionSoftGracePeriod:
 memory.available: "1m30s"
 nodefs.available: "2m"
 nodefs.inodesFree: "2m"
 imagefs.available: "2m"
 imagefs.inodesFree: "2m"
evictionMaxPodGracePeriod: 60s

问题

Kubernetes 项目建议你针对 Pod 驱逐要么使用其默认设置，要么设置与之相关的所有字段。你可以使用默认设置或指定你自己的 evictionHard 设置。如果你漏掉一个信号，那么 Kubernetes 将不会监视该资源。管理员或用户可能会遇到的一个常见误配是将新的文件系统挂载到 /var/lib/containers/storage 或 /var/lib/containerd。 Kubernetes 将检测到一个单独的文件系统，因此你要确保 imagefs.inodesfree 和 imagefs.available 符合你的需要。

另一个令人困惑的地方是，如果你为节点定义了镜像文件系统，则临时存储报告不会发生变化。镜像文件系统（imagefs）用于存储容器镜像层；如果容器向自己的根文件系统写入，那么这种本地写入不会计入容器镜像的大小。容器运行时存储这些本地修改的位置是由运行时定义的，但通常是镜像文件系统。如果 Pod 中的容器正在向基于文件系统的 emptyDir 卷写入，所写入的数据将使用 nodefs 文件系统的空间。 kubelet 始终根据 nodefs 所表示的文件系统来报告临时存储容量和分配情况；当临时写入操作实际上是写到镜像文件系统时，这种差别可能会让人困惑。

后续工作

为了解决临时存储报告相关的限制并为容器运行时提供更多配置选项，SIG Node 正在处理 KEP-4191。在 KEP-4191 中， Kubernetes 将检测可写层是否与只读层（镜像）分离。这种检测使我们可以将包括可写层在内的所有临时存储放在同一磁盘上，同时也可以为镜像使用单独的磁盘。

参与其中

如果你想参与其中，可以加入 Kubernetes Node 特别兴趣小组（SIG）。

如果你想分享反馈，可以分享到我们的 #sig-node Slack 频道。如果你还没有加入该 Slack 工作区，可以访问 https://slack.k8s.io/ 获取邀请。

特别感谢所有提供出色评审、分享宝贵见解或建议主题想法的贡献者。

Peter Hunt
Mrunal Patel
Ryan Phillips
Gaurav Singh

Kubernetes 1.29 中的上下文日志生成：更好的故障排除和增强的日志记录

Wed, 20 Dec 2023 09:30:00 -0800

作者：Mengjiao Liu (DaoCloud), Patrick Ohly (Intel)

译者：Mengjiao Liu (DaoCloud)

代表结构化日志工作组和 SIG Instrumentation，我们很高兴地宣布在 Kubernetes v1.24 中引入的上下文日志记录功能现已成功迁移了两个组件（kube-scheduler 和 kube-controller-manager）以及一些目录。该功能旨在为 Kubernetes 提供更多有用的日志以更好地进行故障排除，并帮助开发人员增强 Kubernetes。

上下文日志记录是什么？

上下文日志记录基于 go-logr API。关键思想是调用者将一个日志生成器实例传递给库，并使用它进行日志记录而不是访问全局日志生成器。二进制文件而不是库负责选择日志记录的实现。go-logr API 围绕结构化日志记录而设计，并支持向日志生成器提供额外信息。

这一设计可以支持某些额外的使用场景：

调用者可以为日志生成器提供额外的信息：
- WithName 添加一个 “logger” 键，并用句点（.）将名称的各个部分串接起来作为取值
- WithValues 添加键/值对
当将此经过扩展的日志生成器传递到函数中，并且该函数使用它而不是全局日志生成器时，所有日志条目中都会包含所给的额外信息，而无需修改生成日志条目的代码。这一特点在高度并行的应用中非常有用。在这类应用中，很难辨识某操作的所有日志条目，因为不同操作的输出是交错的。
运行单元测试时，日志输出可以与当前测试相关联。且当测试失败时，go test 仅显示失败测试的日志输出。默认情况下，该输出也可能更详细，因为它不会在成功的测试中显示。测试可以并行运行，而无需交错输出。

上下文日志记录的设计决策之一是允许将日志生成器作为值附加到 context.Context 之上。由于日志生成器封装了调用所预期的、与日志记录相关的所有元素，因此它是 context 的一部分，而不仅仅是使用它。这一设计的一个比较实际的优点是，许多 API 已经有一个 ctx 参数，或者可以添加一个 ctx 参数。进而产生的额外好处还包括比如可以去掉函数内的 context.TODO() 调用。

如何使用它

从 Kubernetes v1.24 开始，上下文日志记录功能处于 Alpha 状态，因此它需要启用 ContextualLogging 特性门控。如果你想在该功能处于 Alpha 状态时对其进行测试，则需要在 kube-controller-manager 和 kube-scheduler 上启用此特性门控。

对于 kube-scheduler，有一点需要注意，除了启用 ContextualLogging 特性门控之外，插桩行为还取决于日志的详细程度设置。为了避免因 1.29 添加的上下文日志记录工具而降低调度程序的速度，请务必仔细选择何时添加额外的信息：

在 -v3 或更低日志级别中，每个调度周期仅使用一次 WithValues("pod")。这样做可以达到预期效果，即该周期的所有日志消息都包含 Pod 信息。一旦上下文日志记录特性到达 GA 阶段，就可以从所有日志调用中删除 “pod” 键值对。
在 -v4 或更高日志级别中，会生成更丰富的日志条目，其中 WithValues 也用于节点（如果适用），WithName 用于当前操作和插件。

下面的示例展示了这一效果：

I1113 08:43:37.029524 87144 default_binder.go:53] "Attempting to bind pod to node" logger="Bind.DefaultBinder" pod="kube-system/coredns-69cbfb9798-ms4pq" node="127.0.0.1"

这一设计的直接好处是在 logger 中可以看到操作和插件名称。pod 和 node 已作为参数记录在 kube-scheduler 代码中的各个日志调用中。一旦 kube-scheduler 之外的其他包也支持上下文日志记录，在这些包（例如，client-go）中也可以看到操作和插件名称。一旦上下文日志记录特性到达 GA 阶段，就可以简化日志调用以避免重复这些值。

在 kube-controller-manager 中，WithName 被用来在日志中输出用户可见的控制器名称，例如：

I1113 08:43:29.284360 87141 graph_builder.go:285] "garbage controller monitor not synced: no monitors" logger="garbage-collector-controller"

logger=”garbage-collector-controller” 是由 kube-controller-manager 核心代码在实例化该控制器时添加的，会出现在其所有日志条目中——只要它所调用的代码支持上下文日志记录。转换像 client-go 这样的共享包还需要额外的工作。

性能影响

在包中支持上下文日志记录，即接受来自调用者的记录器，成本很低。没有观察到 kube-scheduler 的性能影响。如上所述，添加 WithName 和 WithValues 需要更加小心。

在 Kubernetes 1.29 中，以生产环境日志详细程度（-v3 或更低）启用上下文日志不会导致 kube-scheduler 速度出现明显的减慢，并且 kube-controller-manager 速度也不会出现明显的减慢。在 debug 级别，考虑到生成的日志使调试更容易，某些测试用例减速 28% 仍然是合理的。详细信息请参阅有关将该特性升级为 Beta 版的讨论。

对下游用户的影响

日志输出不是 Kubernetes API 的一部分，并且经常在每个版本中都会出现更改，无论是因为开发人员修改代码还是因为不断转换为结构化和上下文日志记录。

如果下游用户对特定日志有依赖性，他们需要了解此更改如何影响他们。

进一步阅读

参阅 Kubernetes 1.24 中的上下文日志记录。
参阅 KEP-3077：上下文日志记录。

如何参与

如果你有兴趣参与，我们始终欢迎新的贡献者加入我们。上下文日志记录为你参与 Kubernetes 开发做出贡献并产生有意义的影响提供了绝佳的机会。通过加入 Structured Logging WG，你可以积极参与 Kubernetes 的开发并做出你的第一个贡献。这是学习和参与社区并获得宝贵经验的好方法。

我们鼓励你探索存储库并熟悉正在进行的讨论和项目。这是一个协作环境，你可以在这里交流想法、提出问题并与其他贡献者一起工作。

如果你有任何疑问或需要指导，请随时与我们联系，你可以通过我们的公共 Slack 频道联系我们。如果你尚未加入 Slack 工作区，可以访问 https://slack.k8s.io/ 获取邀请。

我们要向所有提供精彩评论、分享宝贵见解并协助实施此功能的贡献者表示感谢（按字母顺序排列）：

Aldo Culquicondor (alculquicondor)
Andy Goldstein (ncdc)
Feruzjon Muyassarov (fmuyassarov)
Freddie (freddie400)
JUN YANG (yangjunmyfm192085)
Kante Yin (kerthcet)
Kiki (carlory)
Lucas Severo Alve (knelasevero)
Maciej Szulik (soltysh)
Mengjiao Liu (mengjiao-liu)
Naman Lakhwani (Namanl2001)
Oksana Baranova (oxxenix)
Patrick Ohly (pohly)
songxiao-wang87 (songxiao-wang87)
Tim Allclai (tallclair)
ZhangYu (Octopusjust)
Ziqi Zhao (fatsheep9146)
Zac (249043822)

Kubernetes 1.29: 解耦污点管理器与节点生命周期控制器

Tue, 19 Dec 2023 00:00:00 +0000

作者: Yuan Chen (Apple), Andrea Tosatto (Apple)

译者: Allen Zhang

这篇博客讨论在 Kubernetes 1.29 中基于污点的 Pod 驱逐处理的新特性。

背景

在 Kubernetes 1.29 中引入了一项改进，以加强节点上基于污点的 Pod 驱逐处理。本文将讨论对节点生命周期控制器（node-lifecycle-controller）所做的更改，以分离职责并提高代码的整体可维护性。

变动摘要

节点生命周期控制器之前组合了两个独立的功能：

基于节点的条件为节点新增了一组预定义的污点 NoExecute。
对有 NoExecute 污点的 Pod 执行驱逐操作。

在 Kubernetes 1.29 版本中，基于污点的驱逐实现已经从节点生命周期控制器中移出，成为一个名为污点驱逐控制器（taint-eviction-controller）的独立组件。旨在拆分代码，提高代码的可维护性，并方便未来对这两个组件进行扩展。

以下新指标可以帮助你监控基于污点的 Pod 驱逐：

pod_deletion_duration_seconds 表示当 Pod 的污点被激活直到这个 Pod 被污点驱逐控制器删除的延迟时间。
pod_deletions_total 表示自从污点驱逐控制器启动以来驱逐的 Pod 总数。

如何使用这个新特性？

名为 SeparateTaintEvictionController 的特性门控已被添加。该特性在 Kubernetes 1.29 Beta 版本中默认开启。详情请参阅特性门控。

当这项特性启用时，用户可以通过在 kube-controller-manager 通过手动设置 --controllers=-taint-eviction-controller 的方式来禁用基于污点的驱逐功能。

如果想禁用该特性并在节点生命周期中使用旧版本污点管理器，用户可以通过设置 SeparateTaintEvictionController=false 来禁用。

使用案例

该特性将允许集群管理员扩展、增强默认的污点驱逐控制器，并且可以使用自定义的实现方式替换默认的污点驱逐控制器以满足不同的需要。例如：更好地支持在本地磁盘的持久卷中的有状态工作负载。

FAQ

该特性是否会改变现有的基于污点的 Pod 驱逐行为？

不会，基于污点的 Pod 驱逐行为保持不变。如果特性门控 SeparateTaintEvictionController 被关闭，将继续使用之前的节点生命周期管理器中的污点管理器。

启用/使用此特性是否会导致现有 SLI/SLO 中任何操作的用时增加？

不会。

启用/使用此特性是否会导致资源利用量（如 CPU、内存、磁盘、IO 等）的增加？

运行单独的 taint-eviction-controller 所增加的资源利用量可以忽略不计。

了解更多

更多细节请参考 KEP。

特别鸣谢

与任何 Kubernetes 特性一样，从撰写 KEP 到实现新控制器再到审核 KEP 和代码，多名社区成员都做出了贡献，特别感谢：

Aldo Culquicondor (@alculquicondor)
Maciej Szulik (@soltysh)
Filip Křepinský (@atiratree)
Han Kang (@logicalhan)
Wei Huang (@Huang-Wei)
Sergey Kanzhelevi (@SergeyKanzhelev)
Ravi Gudimetla (@ravisantoshgudimetla)
Deep Debroy (@ddebroy)

Kubernetes 1.29：PodReadyToStartContainers 状况进阶至 Beta

Tue, 19 Dec 2023 00:00:00 +0000

作者：Zefeng Chen (independent), Kevin Hannon (Red Hat)

译者：Michael Yao

随着最近发布的 Kubernetes 1.29，PodReadyToStartContainers 状况默认可用。 kubelet 在 Pod 的整个生命周期中管理该状况的值，将其存储在 Pod 的状态字段中。 kubelet 将通过容器运行时从 Pod 沙箱创建和网络配置的角度使用 PodReadyToStartContainers 状况准确地展示 Pod 的初始化状态，

这个特性的动机是什么？

集群管理员以前没有明确且轻松访问的方式来查看 Pod 沙箱创建和初始化的完成情况。从 1.28 版本开始，Pod 中的 Initialized 状况跟踪 Init 容器的执行情况。然而，它在准确反映沙箱创建完成和容器准备启动的方面存在一些限制，无法适用于集群中的所有 Pod。在多租户集群中，这种区别尤为重要，租户拥有包括 Init 容器集合在内的 Pod 规约，而集群管理员管理存储插件、网络插件和容器运行时处理程序。因此，需要改进这个机制，以便为集群管理员提供清晰和全面的 Pod 沙箱创建完成和容器就绪状态的视图。

这个特性有什么好处？

改进可见性：集群管理员可以更清晰和全面地查看 Pod 沙箱的创建完成和容器的就绪状态。这种增强的可见性使他们能够做出更明智的决策，并更有效地解决问题。

指标收集和监控：监控服务可以利用与 PodReadyToStartContainers 状况相关的字段来报告沙箱创建状态和延迟。可以按照每个 Pod 的基数进行指标收集，或者根据 Pod 的各种属性进行聚合，例如 volumes、runtimeClassName、CNI 和 IPAM 插件的自定义注解，以及任意标签和注解，以及 PersistentVolumeClaims 的 storageClassName。这样可以全面监控和分析集群中 Pod 的就绪状态。

增强故障排查能力：通过更准确地表示 Pod 沙箱的创建和容器的就绪状态，集群管理员可以快速识别和解决初始化过程中可能出现的任何问题。这将提高故障排查能力，并减少停机时间。

后续事项

鉴于反馈和采用情况，Kubernetes 团队在 1.29 版本中将 PodReadyToStartContainersCondition 进阶至 Beta版。你的评论将有助于确定该状况是否继续并晋升至 GA，请针对此特性提交更多反馈！

如何了解更多？

请查看关于 PodReadyToStartContainersCondition 的文档，以了解其更多信息及其与其他 Pod 状况的关系。

如何参与？

该特性由 SIG Node 社区推动。请加入我们，与社区建立联系，分享你对这一特性及更多内容的想法和反馈。我们期待倾听你的建议！

Kubernetes 1.29 新的 Alpha 特性：Service 的负载均衡器 IP 模式

Mon, 18 Dec 2023 00:00:00 +0000

作者： Aohan Yang

译者： Allen Zhang

本文介绍 Kubernetes 1.29 中一个新的 Alpha 特性。此特性提供了一种可配置的方式用于定义 Service 的实现方式，本文中以 kube-proxy 为例介绍如何处理集群内从 Pod 到 Service 的流量。

背景

在 Kubernetes 早期版本中，kube-proxy 会拦截指向 type: LoadBalancer Service 关联 IP 地址的流量。这与你为 kube-proxy 所使用的哪种模式无关。

这种拦截实现了预期行为（流量最终会抵达服务后挂载的端点）。这种机制取决于 kube-proxy 的模式，在 Linux 中，运行于 iptables 模式下的 kube-proxy 会重定向数据包到后端端点；在 ipvs 模式下， kube-proxy 会将负载均衡器的 IP 地址配置到节点的一个网络接口上。采用这种拦截有两个原因：

流量路径优化： 高效地重定向 Pod 流量 - 当 Pod 中的容器发送指向负载均衡器 IP 地址的出站包时，会绕过负载均衡器直接重定向到后端服务。

处理负载均衡数据包： 有些负载均衡器发送的数据包设置目标 IP 为负载均衡器的 IP 地址。因此，这些数据包需要被直接路由到正确的后端（可能不在该节点本地），以避免回环。

问题

然而，上述行为存在几个问题：

源 IP（Source IP）： 一些云厂商在传输数据包到节点时使用负载均衡器的 IP 地址作为源 IP。在 kube-proxy 的 ipvs 模式下，存在负载均衡器健康检查永远不会返回的问题。原因是回复的数据包被转发到本地网络接口 kube-ipvs0（绑定负载均衡器 IP 的接口）上并被忽略。

负载均衡器层功能缺失： 某些云厂商在负载均衡器层提供了部分特性（例如 TLS 终结、协议代理等）。绕过负载均衡器会导致当数据包抵达后端服务时这些特性不会生效（导致协议错误等）。

即使新的 Alpha 特性默认关闭，也有临时解决方案，即为 Service 设置 .status.loadBalancer.ingress.hostname 以绕过 kube-proxy 绑定。但这终究只是临时解决方案。

解决方案

总之，为云厂商提供选项以禁用当前这种行为大有裨益。

Kubernetes 1.29 版本为 Service 引入新的 Alpha 字段 .status.loadBalancer.ingress.ipMode 以解决上述问题。该字段指定负载均衡器 IP 的运行方式，并且只有在指定 .status.loadBalancer.ingress.ip 字段时才能指定。

.status.loadBalancer.ingress.ipMode 可选值为："VIP" 和 "Proxy"。默认值为 VIP，即目标 IP 设置为负载均衡 IP 和端口并发送到节点的流量会被 kube-proxy 重定向到后端服务。这种方式保持 kube-proxy 现有行为模式。Proxy 用于阻止 kube-proxy 在 ipvs 和 iptables 模式下绑定负载均衡 IP 地址到节点。此时，流量会直达负载均衡器然后被重定向到目标节点。转发数据包的目的值配置取决于云厂商的负载均衡器如何传输流量。

如果流量被发送到节点然后通过目标地址转换（DNAT）的方式到达 Pod，目的地应当设置为节点和 IP 和端口；
如果流量被直接转发到 Pod，目的地应当被设置为 Pod 的 IP 和端口。

用法

开启该特性的必要步骤：

下载 Kubernetes 最新版本（v1.29.0 或更新）。
通过命令行参数 --feature-gates=LoadBalancerIPMode=true 在 kube-proxy、kube-apiserver 和 cloud-controller-manager 开启特性门控。
对于 type: LoadBalancer 类型的 Service，将 ipMode 设置为合适的值。这一步可能由你在 EnsureLoadBalancer 过程中选择的 cloud-controller-manager 进行处理。

联系我们

通过 Slack 频道 #sig-network, 或者通过邮件列表联系我们。

特别鸣谢

非常感谢 @Sh4d1 的原始提案和最初代码实现。我中途接手并完成了这项工作。同样我们也向其他帮助设计、实现、审查特性代码的贡献者表示感谢（按首字母顺序排列）：

Kubernetes 1.29：修改卷之 VolumeAttributesClass

Fri, 15 Dec 2023 00:00:00 +0000

译者：Baofa Fan (DaoCloud)

Kubernetes v1.29 版本引入了一个 Alpha 功能，支持通过变更 PersistentVolumeClaim（PVC）的 volumeAttributesClassName 字段来修改卷。启用该功能后，Kubernetes 可以处理除容量以外的卷属性的更新。允许更改卷属性，而无需通过不同提供商的 API 对其进行管理，这直接简化了当前流程。

你可以在 Kubernetes 文档中，阅读有关 VolumeAttributesClass 的详细使用信息，或者继续阅读了解 Kubernetes 项目为什么支持此功能。

VolumeAttributesClass

新的 storage.k8s.io/v1alpha1 API 组提供了两种新类型：

VolumeAttributesClass

表示由 CSI 驱动程序定义的可变卷属性的规约。你可以在 PersistentVolumeClaim 动态制备时指定它，并且允许在制备完成后在 PersistentVolumeClaim 规约中进行更改。

ModifyVolumeStatus

表示 ControllerModifyVolume 操作的状态对象。

启用此 Alpha 功能后，PersistentVolumeClaim 的 spec.VolumeAttributesClassName 字段指明了在 PVC 中使用的 VolumeAttributesClass。在制备卷时，CreateVolume 操作将应用 VolumeAttributesClass 中的参数以及 StorageClass 中的参数。

当 PVC 的 spec.VolumeAttributesClassName 发生变化时，external-resizer sidecar 将会收到一个 informer 事件。基于当前的配置状态，resizer 将触发 CSI ControllerModifyVolume。更多细节可以在 KEP-3751 中找到。

如何使用它

如果你想在 Alpha 版本中测试该功能，需要在 kube-controller-manager 和 kube-apiserver 中启用相关的特性门控。使用 --feature-gates 命令行参数：

--feature-gates="...,VolumeAttributesClass=true"

它还需要 CSI 驱动程序实现 ModifyVolume API。

用户流程

如果你想看到该功能的运行情况，并验证它在你的集群中是否正常工作，可以尝试以下操作：

定义 StorageClass 和 VolumeAttributesClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: csi-sc-example
provisioner: pd.csi.storage.gke.io
parameters:
 type: "hyperdisk-balanced"
volumeBindingMode: WaitForFirstConsumer

apiVersion: storage.k8s.io/v1alpha1
kind: VolumeAttributesClass
metadata:
 name: silver
driverName: pd.csi.storage.gke.io
parameters:
 provisioned-iops: "3000"
 provisioned-throughput: "50"

定义并创建 PersistentVolumeClaim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: test-pv-claim
spec:
 storageClassName: csi-sc-example
 volumeAttributesClassName: silver
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 64Gi

验证 PersistentVolumeClaim 是否已正确制备：
```
kubectl get pvc
```

创建一个新的名为 gold 的 VolumeAttributesClass：

apiVersion: storage.k8s.io/v1alpha1
kind: VolumeAttributesClass
metadata:
 name: gold
driverName: pd.csi.storage.gke.io
parameters:
 iops: "4000"
 throughput: "60"

使用新的 VolumeAttributesClass 更新 PVC 并应用：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: test-pv-claim
spec:
 storageClassName: csi-sc-example
 volumeAttributesClassName: gold
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 64Gi

验证 PersistentVolumeClaims 是否具有更新的 VolumeAttributesClass 参数：
```
kubectl describe pvc <PVC_NAME>
```

后续步骤

有关设计的更多信息，请参阅 VolumeAttributesClass KEP
你可以在项目看板上查看或评论 VolumeAttributesClass
为了将此功能推向 Beta 版本，我们需要社区的反馈，因此这里有一个行动倡议：为 CSI 驱动程序添加支持，尝试此功能，考虑它如何帮助解决你的用户遇到的问题...

参与其中

我们始终欢迎新的贡献者。因此，如果你想参与其中，可以加入我们的 Kubernetes 存储特别兴趣小组 (SIG)。

如果你想分享反馈意见，可以在我们的公共 Slack 频道上留言。

特别感谢所有为此功能提供了很好的评论、分享了宝贵见解并帮助实现此功能的贡献者（按字母顺序）：

Baofa Fan (calory)
Ben Swartzlander (bswartz)
Connor Catlett (ConnorJC3)
Hemant Kumar (gnufied)
Jan Šafránek (jsafrane)
Joe Betz (jpbetz)
Jordan Liggitt (liggitt)
Matthew Cary (mattcary)
Michelle Au (msau42)
Xing Yang (xing-yang)

聚焦 SIG Testing

Fri, 24 Nov 2023 00:00:00 +0000

作者: Sandipan Panda

译者: Michael Yao

欢迎阅读又一期的 “SIG 聚光灯” 系列博客，这些博客重点介绍 Kubernetes 项目中各个特别兴趣小组（SIG）所从事的令人赞叹的工作。这篇博客将聚焦 SIG Testing，这是一个致力于有效测试 Kubernetes，让此项目的繁琐工作实现自动化的兴趣小组。 SIG Testing 专注于创建和运行工具和基础设施，使社区更容易编写和运行测试，并对测试结果做贡献、分析和处理。

为了深入了解 SIG Testing 的情况， Sandipan Panda 采访了 Google 高级软件工程师兼 SIG Testing 主席 Michelle Shepardson 以及英特尔软件工程师、架构师兼 SIG Testing 技术负责人 Patrick Ohly。

会见贡献者

Sandipan: 你能简单介绍一下自己吗，谈谈你的职责角色以及你是如何参与 Kubernetes 项目和 SIG Testing 的？

Michelle: 嗨！我是 Michelle，是 Google 高级软件工程师。我最初是为 SIG Testing 开发工具（如 TestGrid 的外部实例）而参与到 Kubernetes 项目的。我是 TestGrid 和 Prow 的轮值人员，现在也是这个 SIG 的主席。

Patrick: 你好！我在英特尔的一个团队中担任软件工程师和架构师，专注于开源云原生项目。当我开始学习 Kubernetes 开发存储驱动时，我最初的问题是“如何在集群中进行测试以及如何记录信息？” 这个兴趣点引发了各种增强提案，直到我（重新）编写了足够多的代码，也正式担任了 SIG Testing 技术负责人（负责 E2E 框架）兼结构化日志工作组负责人。

测试实践和工具

Sandipan: 测试是一个存在多种方法和工具的领域，你们是如何形成现有实践方式的？

Patrick: 我没法谈论早期情况，因为那时我还未参与其中 😆，但回顾一些提交历史可以明显看出，当时开发人员只是看看有什么可用的工具并开始使用这些工具。对于 E2E 测试来说，使用的是 Ginkgo + Gomega。集成一些黑科技是必要的，例如在测试运行后进行清理和对测试进行分类。最终形成了 Ginkgo v2 和重新修订的 E2E 测试最佳实践。关于单元测试，意见非常多样化：一些维护者倾向于只使用 Go 标准库和手动检查。而其他人使用 stretchr/testify 这类辅助工具包。这种多样性是可以接受的，因为单元测试是自包含的：贡献者只需在处理许多不同领域时保持灵活。集成测试介于二者之间，它基于 Go 单元测试，但需要复杂的辅助工具包来启动 API 服务器和其他组件，然后运行更像是 E2E 测试的测试。

SIG Testing 拥有的子项目

Sandipan: SIG Testing 非常多样化。你能简要介绍一下 SIG Testing 拥有的各个子项目吗？

Michelle: 广义上来说，我们拥有与测试框架相关的子项目和基础设施，尽管它们肯定存在重叠。我们的子项目包括：

e2e-framework（外部使用）
test/e2e/framework （用于 Kubernetes 本身）
kubetest2（用于端到端测试）
boskos（用于 e2e 测试的资源租赁）
KIND（在 Docker 中运行 Kubernetes，用于本地测试和开发）
以及 KIND 的云驱动。

我们的基础设施包括：

Prow（基于 K8s 的 CI/CD 和 chatops）
test-infra 仓库中用于分类、分析、覆盖率、Prow/TestGrid 配置生成等的其他工具和实用程序。

如果你有兴趣了解更多并参与到 SIG Testing 的任何子项目中，查阅 SIG Testing 的 README。

主要挑战和成就

Sandipan: 你们面临的一些主要挑战是什么？

Michelle: Kubernetes 从贡献者到代码再到用户等各方面看都是一个庞大的项目。测试和基础设施必须满足这种规模，跟上 Kubernetes 每个仓库的所有变化，同时尽可能地促进开发、改进和发布项目，尽管当然我们并不是唯一参与其中的 SIG。我认为另一个挑战是子项目的人员配置。SIG Testing 有一些已经存在多年的子项目，但其中许多最初的维护者已经转到其他领域或者没有时间继续维护它们。我们需要在这些子项目中培养长期的专业知识和 Owner。

Patrick: 正如 Michelle 所说，规模本身可能就是一个挑战。不仅基础设施要与之匹配，我们的流程也必须与贡献者数量相匹配。记录最佳实践是好的，但还不够好：我们有许多新的贡献者，这是好事，但是让 Reviewer 靠人工解释最佳实践并不可行，这前提是 Reviewer 了解这些最佳实践！如果现有代码不能被立即更新也无济于事，因为代码实在太多了，特别是对于 E2E 测试来说更是如此。在接受现有代码无法通过同样的 linter 检查的同时，为新代码或代码修改应用更严格的 lint 检查对于改善情况会有所帮助。

Sandipan: 有没有一些 SIG 成就使你感到自豪，想要重点说一下？

Patrick: 我有一些拙见，因为我一直在推动这个项目，但我认为现在 E2E 框架和 lint 机制比以前好得多。我们可能很快就能在启用竞争检测的情况下运行集成测试，这很重要，因为目前我们只能对单元测试进行竞争检测，而那些往往不太复杂。

Sandipan: 测试始终很重要，但在 Kubernetes 发布过程中，你的工作是否有任何特殊之处？

Patrick: 测试不稳定…… 如果我们有太多这样的不稳定测试，开发速度就会下降，因为我们无法在没有干净测试运行环境的情况下合并 PR，并且这些环境会越来越少。开发者也会失去对测试的信任，只是“重新测试”直到有了一个干净的运行环境为止，而不会检查失败是否确实与当前更改中的回归有关。

人员和范围

Sandipan: 这个 SIG 中有哪些让你热爱的？

Michelle: 当然是人 🙂。除此之外，我喜欢 SIG Testing 的宽广范围。我觉得即使是小的改动也可以对其他贡献者产生重大影响，即使随着时间的推移我的兴趣发生变化，我也永远不会缺少项目可供我参与。

Patrick: 我的工作是为了让我和其他开发人员的工作变得更好，比如建设在其他地方开发新特性时每天必须使用的工具。

Sandipan: 你们有没有任何好玩/酷炫/日常趣事可以告诉我们？

Patrick: 五年前，我开始致力于 E2E 框架的增强，然后在一段时间内参与活动较少。当我回来并想要测试一些新的增强功能时，我询问如何为新代码编写单元测试，并被指向了一些看起来有些熟悉的、好像以前见过的现有测试。我查看了提交历史，发现这些测试是我自己编写的！你可以决定这是否说明了我的长期记忆力衰退还是这很正常... 无论如何，伙计们，要谨记让每个 Commit 的消息和注释明确、友好；某一刻会有人需要看这些消息和注释 - 甚至可能就是你自己！

展望未来

Sandipan: 在哪些领域和/或子项目上，你们的 SIG 需要帮助？

Michelle: 目前有一些子项目没有人员配置，需要有意愿了解更多的人参与进来。 boskos 和 kubetest2 对我来说尤其突出，因为它们对于测试非常重要，但却缺乏专门的负责人。

Sandipan: 新的 SIG Testing 贡献者可以带来哪些有用的技能？如果他们的背景与编程没有直接关联，有哪些方面可以帮助到这个 SIG？

Michelle: 我认为具备用户共情、清晰反馈和识别模式的能力非常有用。有人使用测试框架或工具，并能用清晰的示例概述痛点，或者能够识别项目中的更广泛的问题并提供数据来支持解决方案。

Sandipan: SIG Testing 的下一步是什么？

Patrick: 对于新代码，更严格的 lint 检查很快将成为强制要求。如果有人愿意承担这项工作，我们可以对一些 E2E 框架的子工具包进行现代化改造。我还看到一个机会，可以统一一些 E2E 和集成测试的辅助代码，但这需要更多的思考和讨论。

Michelle: 我期待为我们的工具和基础设施进行一些可用性改进，并支持更多长期贡献者的贡献和成长，使他们在 SIG 中担任长期角色。如果你有兴趣，请联系我们！

展望未来，SIG Testing 有令人兴奋的计划。你可以通过他们的 Slack 频道与 SIG Testing 的人员取得联系，或参加他们定期举行的每两周的周二会议。如果你有兴趣为社区更轻松地运行测试并贡献测试结果，确保 Kubernetes 在各种集群配置和云驱动中保持稳定，请立即加入 SIG Testing 社区！

Kubernetes Blog

Kubernetes v1.33 预览

Kubernetes API 的移除与弃用流程

Kubernetes v1.33 的弃用与移除

稳定版 Endpoints API 的弃用

节点状态中 kube-proxy 版本信息的移除

移除对 Windows Pod 的主机网络支持

Kubernetes v1.33 的特色改进

Linux Pods 中用户命名空间的支持

精选的其他 Kubernetes v1.33 改进

Pod 垂直扩展的就地资源调整

DRA 的 ResourceClaim 设备状态升级为 Beta

有序的命名空间删除

针对带索引作业（Indexed Job）管理的增强

想了解更多？

参与进来

ingress-nginx CVE-2025-1974 须知

背景

今日修复的漏洞

你需要做什么

总结、致谢与更多参考

聚焦 SIG Apps

自我介绍

关于 SIG Apps

最佳实践与挑战

贡献于 SIG Apps

展望未来

kube-proxy 的 NFTables 模式

为什么选择 nftables？第一部分：数据平面延迟

为什么选择 nftables？第二部分：控制平面延迟

不选择 nftables 的理由有哪些？

尝试使用 nftables 模式

未来计划

进一步了解

云控制器管理器（Cloud Controller Manager）'鸡与蛋'的问题

依赖问题的示例

示例：由于未初始化的污点导致云控制器管理器无法调度

示例：由于未就绪污点导致云控制器管理器无法调度

我们的建议

示例

聚焦 SIG Architecture: Enhancements

Enhancements 子项目

KEP 及其影响

当前关注领域

如何参与

使用 API 流式传输来增强 Kubernetes API 服务器效率

为什么 kube-apiserver 为 list 请求分配这么多内存？

流式处理 list 请求

为你的组件启用 API 流式传输

接下来

模拟测试

Kubernetes v1.32 增加了新的 CPU Manager 静态策略选项用于严格 CPU 预留

理解此特性

启用此特性

监控此特性

总结

进一步阅读

参与其中

Kubernetes v1.32：内存管理器进阶至 GA

改进可观测性

提高内存管理器可靠性和一致性

未来发展

参与其中

Kubernetes v1.32：QueueingHint 为优化 Pod 调度带来了新的可能

调度队列

调度框架和插件

使用 QueueingHint 改进 Pod 调度重试

QueueingHint 的历史及 v1.32 中的新变化

参与其中

如何了解更多？

Kubernetes v1.32 预览

Kubernetes API 的移除和弃用流程

关于撤回 DRA 的旧的实现的说明

API 移除

Kubernetes v1.32 的抢先预览

更多 DRA 增强特性！

在 Pod 状态中添加资源健康状态

Windows 工作继续

允许环境变量中使用特殊字符

使 Kubernetes 感知到 LoadBalancer 的行为

动机：容器镜像中 `/etc/group` 中定义的隐式组成员关系

Pod 中的细粒度 SupplementalGroups 控制：`SupplementaryGroupsPolicy`

`matchLabelKeys` - 为多样化滚动更新增强了调度

`mismatchLabelKeys` - 服务隔离