Kubernetes Blog 中文 - TheNote.app

Kubernetes Blog 中文
关注

Kubernetes 的官方主页，是一个容器编排系统，用于自动化容器化应用程序的部署、缩放和管理。该平台提供了 Kubernetes 的详细文档，Kubernetes 是 Cloud Native Computing Foundation 维护的一个项目。它包括关于使用 Kubernetes 运行无状态和有状态应用程序、批处理作业和 CI/CD 工作流的详细信息。该网站包括详细的指南、教程、参考资料、API 文档和社区参与计划，以帮助用户开始使用 Kubernetes 并充分利用其特点来高效地管理基于云的应用程序。

Kubernetes Blog kubernetes.io

RSS kubernetes.io

Kubernetes Blog 中文 RSS thenote.app

RSS Hunter • 2024年8月23日

笔记线程

为什么我的 Kubernetes Job 仍处于 Pending 状态？使用 Headlamp 追踪 Kueue 的准入

当 Kubernetes Job 处于 Pending 状态时，可能是由于 Kueue 仍在确定资源可用性。Headlamp 的 Kueue 插件通过将 Kueue 资源视图集成到 UI 中，帮助用户调查此类问题。这使得用户无需大量使用命令行，即可追踪 Workload 的准入路径，包括 LocalQueues、ClusterQueues、ResourceFlavors 和 Cohorts。调查始于检查 Workload 的状态和条件，以确认 Kueue 是否已将其准入。若 Workload 未获准入，则问题出在 Kueue 的准入流程上；若 Workload 已获准入但 Pod 仍处于 Pending 状态，则问题转向 Kubernetes 调度器。Headlamp 中的 Workload 视图显示请求的资源，并可通过 LocalQueue 链接查看 Job 请求的入口点。检查关联的 ClusterQueue 至关重要，因为其配额和策略决定了资源分配。在特定示例中，一个 CPU 和 Pod 槽位有限的 ClusterQueue 导致请求更多资源的 Job 被 Kueue 挂起。ResourceFlavors 和 Cohorts 则用于排查更复杂的配额或硬件类别问题。若 Workload 已获准入，则故障排查转向 Headlamp 标准的 Job 和 Pod 视图，以检查与调度器相关的事件。这种以 Headlamp 为先的方法旨在为 Kueue 相关的延迟提供更快速、更集成的故障排查体验。

Why Is My Kubernetes Job Still Pending? Tracing Kueue Admission with Headlamp kubernetes.io

RSS Hunter • 10月14日

Kubernetes 向 cgroup v2 的迁移：您需要了解的内容

Kubernetes 使用 Linux cgroups 管理容器资源，正显著向 cgroup v2 迁移。cgroup v1 现已进入维护模式，将在未来的 Kubernetes 版本中完全移除。cgroup v2 提供统一的层级结构、更一致的接口以及增强的资源隔离能力。Kubernetes v1.31 将 cgroup v1 的管理标记为维护状态，而 v2 自 v1.25 起已稳定。较新的 Kubernetes 版本（如 v1.35）默认会在 cgroup v1 节点上阻止 kubelet 启动，除非显式覆盖该行为。从 v1.35 开始，kubeadm 的系统验证检查也会标记 cgroup v1 的使用情况。cgroup v2 支持新功能，例如带有分层保护的内存 QoS，提供优于 cgroup v1 的内存管理能力。它还改进了容器感知的 OOM 处理，确保容器内的所有进程被统一终止。无 root 容器支持也通过 cgroup v2 的委托能力得到了更官方的优化。迁移需要确保与内核版本、容器运行时以及 kubelet 配置的兼容性。

The Shift to cgroup v2 in Kubernetes: What You Need to Know kubernetes.io

RSS Hunter • 10月6日

通过节点交换扩展Kubernetes工作负载

Kubernetes 集群往往在面临 CPU 限制之前先遭遇内存限制，而新的代理式 AI 工作负载进一步加剧了这一难题。这些 AI 工作负载需要大量内存来启动和运行不可信代码，随后便处于空闲状态。这种空闲内存成本高昂，并限制了单个节点可托管的 Pod 数量。交换内存（Swap），尤其是由高速 NVMe SSD 支持的交换内存，可以通过将休眠内存分页出去来解决这一问题。Kubernetes 现已普遍可用地支持交换内存，使节点能够托管更多 Pod。在 CI/CD 构建、沙箱化浏览器和 Python 运行时等场景下的基准测试表明，交换内存可将密度提升高达三倍，且对延迟的影响微乎其微。历史上，由于内存记账问题和高磁盘延迟，交换内存一直被避免使用。然而，cgroup v2 和高速 NVMe SSD 解决了这些顾虑，使交换内存成为可行的解决方案。传统工作负载（如内核构建）在启用交换内存时可以容忍降低的内存限制。高密度代理工作负载（如无头浏览器）在启用交换内存后，Pod 密度显著提升。沙箱化 Python 运行时同样受益于交换内存，可实现三倍的并发会话数。启用节点交换涉及配置 kubelet 并使用云提供商的本地磁盘。具有 Burstable QoS 的工作负载可利用交换内存进行动态内存平衡。最终，快速交换内存能够卸载空闲内存状态，从而提高代理式工作负载的 Pod 密度和节点利用率。

Scaling Kubernetes Workloads with Node Swap kubernetes.io

RSS Hunter • 10月5日

SIG应用聚焦

Kubernetes 的采用使得管理复杂的应用生命周期、支持多样化的工作负载并确保可靠性成为可能。SIG Apps 由 Deployment 和 StatefulSet 等控制器组成，构成了 Kubernetes 中应用管理的基石。该小组专注于提升工作负载的韧性、优化生命周期管理，并解决运营挑战。SIG Apps 主席 Janet Kuo 和 Maciej Szulik 讨论了工作负载管理的演进及未来方向。SIG Apps 对于应用在 Kubernetes 上的运行方式至关重要，负责管理应用的创建、更新、扩缩容和恢复。随着 Kubernetes 支持更多样化的工作负载（如 AI 和批处理），SIG Apps 正在演进其 API 以提升可靠性和简洁性。当前的工作重点包括服务工作负载、改进发布和扩缩容性能，以及解决用户报告的问题。一个主要焦点是提升工作负载的韧性，特别是针对节点故障及其对 DaemonSet 和 Job 等工作负载的影响。新的子项目如 JobSet 和 LeaderWorkerSet 旨在处理大规模 AI 训练和推理中的故障。成功交付这些改进将减少 Kubernetes 平台团队进行手动干预的需求。SIG Apps 面临的一个关键挑战是在激进的控制器行为、必要的信号以及现有用户自动化的关键向后兼容性之间取得平衡。为避免破坏遗留系统，SIG Apps 倾向于采用可选功能（opt-in）并通过自定义资源定义（CRD）引入新范式。该小组还重新审视了如 KEP-4443 等提案，以通过提供更具体的失败原因来增强 Job API，从而改善自动化能力。鼓励新贡献者加入 #sig-apps Slack 频道，或为不断发展的子项目（如 Agent Sandbox）做出贡献。

Spotlight on SIG Apps kubernetes.io

RSS Hunter • 9月22日

Kubernetes v1.37：追踪 PersistentVolumeClaim 的最后使用时间（Beta）

Kubernetes v1.37 将 PersistentVolumeClaimUnusedSinceTime 特性门控提升至 Beta 阶段，并默认启用。该增强功能为每个 PersistentVolumeClaim（PVC）的状态中添加了"Unused"条件，直接指示是否有正在运行的 Pod 引用该 PVC。此前，识别未使用的 PVC 较为复杂，需要交叉引用多个 Kubernetes 对象并进行大量自定义脚本处理。新功能通过原生报告 PVC 使用状态简化了这一过程。若没有任何非终止状态的 Pod 引用某 PVC，则该 PVC 被标记为"Unused"；若至少有一个运行中或待处理的 Pod 已挂载该 PVC，则被标记为"Used"。终止状态的 Pod（包括已完成批处理任务的 Pod）不计为正在活跃使用 PVC。"Unused"条件还包含一个 lastTransitionTime 字段，记录 PVC 何时变为空闲状态。这使得管理员能够轻松识别已闲置特定时长以上的 PVC，从而辅助成本优化和存储管理。该功能在 v1.36 中处于 Alpha 阶段，经过广泛测试后，现已在 Beta 阶段默认启用。用户可直接通过 kubectl 检查 PVC 状态以观察这些变更。Kubernetes 项目计划根据用户反馈，在后续版本中将此功能推进至通用可用（General Availability）阶段。

Kubernetes v1.37: Tracking When a PersistentVolumeClaim Was Last Used (Beta) kubernetes.io

RSS Hunter • 9月21日

Kubernetes v1.37：通过绑定挂载选项和 EmptyDir 权限加固容器存储

Kubernetes v1.37 引入了关键的存储安全增强功能，以加强工作负载保护。这些功能允许直接在 Kubernetes 中配置 emptyDir 卷的权限模式和绑定挂载选项。这使得开发人员和安全专业人员能够在无需复杂变通方案的情况下实施严格的安全策略。这些改进基于根本的 Linux 安全机制，如绑定挂载标志和目录权限。绑定挂载标志（例如 noexec、nosuid 和 nodev）控制允许在已挂载的文件系统上执行的操作。目录权限（包括粘滞位）规范访问权限，并防止在共享目录中进行未经授权的删除操作。这些功能的主要动机是通过允许设置安全相关的绑定挂载选项来提升 Kubernetes 工作负载的安全性。此前，卷在挂载时未包含这些保护标志，从而造成了安全漏洞。所解决的一个重大差距是：无法为 emptyDir 卷设置挂载选项，且目录的默认权限模式为 0777。这导致任何进程均可访问、修改或删除 emptyDir 卷中的文件，而不论其所有权归属。新功能提供了原生解决方案，例如允许在 emptyDir 上设置粘滞位，以实现安全的共享工作区，其行为类似于 /tmp。这些增强功能使应用程序开发人员能够防止在可写挂载点上发生权限提升，并强制对应用程序数据实施最小权限原则。使用场景包括防止从可写卷执行任意二进制文件，以及保护多容器 Pod 中的共享临时存储空间。开发人员现在可以自信地通过设置特定模式（如 0750）来锁定对临时存储的访问。这两项功能在 v1.37 中当前处于 Alpha 阶段，需要启用功能门控：VolumeBindMountOptions 和 EmptyDirVolumeMode。这些新功能仅适用于 Linux，不影响 Windows 节点。

Kubernetes v1.37: Hardening Container Storage with Bind Mount Options and EmptyDir Permissions kubernetes.io

RSS Hunter • 9月16日

Kubernetes v1.37：Pod 级资源管理器已晋升为 Beta 版本

Kubernetes v1.37 将 Pod 级资源管理器（Pod-Level Resource Managers）提升至 Beta 状态，使 Kubelet 的管理器能够利用 Pod 级资源声明。此前，关键应用所需的独占 NUMA 对齐需要为所有容器预留核心，这对边车容器而言效率低下。该新功能支持混合分配：为主容器保留 NUMA 对齐的资源，同时由共享资源池容纳边车容器。边车容器因此获得 NUMA 对齐与保护，而无需消耗独占核心。Beta 版本包含 PodLevelResourceManagers 功能门控（默认禁用），并对 PodResources API 进行了增强。该 API 现在报告 Pod 的顶层 cpu_ids 和内存，防止监控中的重复计数。用户可启用此功能以更有效地管理资源。目标是为主关键工作负载提供更好的性能，并实现更高效的资源利用。详细的文档和教程可供用户参考以开始使用。随着该功能向通用可用（General Availability）推进，用户反馈至关重要。

Kubernetes v1.37: Pod-Level Resource Managers graduated to Beta kubernetes.io

RSS Hunter • 9月15日

Kubernetes 更改块跟踪 API - 测试版差异

Kubernetes 存储 CSI 驱动中的“块变更跟踪”（Changed Block Tracking, CBT）功能最初于 2025 年 9 月以 Alpha 版本发布。该功能通过跟踪块卷内的变更来增强存储操作。Alpha 版本的发布说明详细阐述了其动机、核心组件及使用方法。目前，CBT 仅支持块卷，暂不支持基于文件的存储。external-snapshot-metadata 项目最近的 v1.0.0 版本发布将该功能提升至 Beta 阶段。Beta 阶段的主要更新是将 SnapshotMetadataService 自定义资源定义（CRD）从 v1alpha1 升级至 v1beta1。尽管 schema 保持不变，但旧的 v1alpha1 版本已被移除，用户需进行相应调整。从 Alpha 迁移至 Beta 需要用户重新应用 CRD 定义，更新其清单以使用新的 API 版本，并调整任何客户端或控制器代码。此迁移为手动的一次性过程。Beta 版本要求 Kubernetes 最低版本为 1.33，CSI 规范版本为 1.10 或更高。兼容的容器镜像为 csi-snapshot-metadata:v1.0.0。为测试该功能，请确保您的 CSI 驱动支持快照并包含 external-snapshot-metadata sidecar。安装 v1beta1 CRD 并为您驱动创建 SnapshotMetadataService 资源。然后，使用 lister 工具或自定义实现来调用 GetMetadataAllocated 和 GetMetadataDelta 函数。开发团队目前正致力于推动更广泛的 CSI 驱动采用，并在 Beta 期间收集运营反馈。他们鼓励 CSI 驱动维护者评估添加支持，并欢迎应用程序开发人员就流式客户端和迭代器包提供反馈。更多信息可查阅 CSI 开发者文档、KEP-3314、external-snapshot-metadata 仓库、gRPC schema 以及 snapshot-metadata-lister 示例。对该功能的贡献十分显著，有兴趣的个人被鼓励与 SIG Storage 和数据保护工作组进行互动。

Kubernetes Changed Block Tracking API - Beta Differences kubernetes.io

RSS Hunter • 9月14日

Kubernetes v1.37：内存QoS升级至测试版

Kubernetes v1.37 标志着 Memory QoS 进入 Beta 毕业阶段，现已默认在 Linux 节点上启用（基于 cgroup v2）。该功能通过利用内核内存控制器提供更优的引导，从而增强容器内存管理。Memory QoS 最初于 v1.22 以 Alpha 版本引入，并在 v1.36 中通过分层内存预留功能进行了扩展。Beta 升级意味着 MemoryQoS 功能门控在 v1.37 的所有 kubelet 中默认激活，无需进行显式配置更改。关键在于，默认 kubelet 配置不会启用内存节流或预留，除非用户明确选择启用。用户可以通过 kubelet 配置字段启用特定的 Memory QoS 行为。例如，设置 memoryThrottlingFactor 可为 Burstable 和 BestEffort 容器激活 memory.high 节流。或者，将 memoryReservationPolicy 配置为 TieredReservation，可通过 memory.min 和 memory.low 实现分层内存保护。v1.37 中的一个重大变更是 memoryThrottlingFactor 的默认值从 0.9 调整为 null，从而防止现有集群在升级时自动启用内存节流。这确保了除非显式配置其他行为，否则运行时行为保持一致。要配置 Memory QoS，集群操作员可以设置 memoryThrottlingFactor 以启用节流，设置 memoryReservationPolicy 以启用分层预留。两者可同时启用或独立启用。完全禁用 Memory QoS 可通过将功能门控设置为 false 并相应调整 kubelet 配置来实现。一个已知限制是内存预留为节点级，一致地应用于所有 Pod，无论其期望行为如何，从而影响对单个 Pod 的控制。Memory QoS 的下一个开发阶段是其毕业至通用可用（General Availability），持续的反馈将塑造未来的调整。

Kubernetes v1.37: Memory QoS Graduates to Beta kubernetes.io

RSS Hunter • 9月14日

Kubernetes v1.37：原生直方图升级为测试版

原生直方图将在 Kubernetes v1.37 中晋升为 Beta 版本，提供高分辨率且低基数（low-cardinality）的可观测性。这一进展取代了旧有的静态 Prometheus 直方图，后者存在分桶猜测、高基数以及插值误差等问题。Prometheus 原生直方图利用存储在单个时间序列中的动态指数分桶，可将时间序列数量减少高达 90%。这实现了自动高分辨率，并提供精确的分位数计算。在 Kubernetes 中，原生直方图已集成到共享指标中，采用双重暴露（dual exposition）机制，确保与现有可观测性栈的兼容性。经典分桶仍与新原生分桶一同发出，以实现零破坏性变更的平滑过渡。标准指数选项会自动应用，确保分位数计算具有有界误差。该功能自动支持主要的 Kubernetes 组件，如 API 服务器、调度器和 Kubelet。升级到 Kubernetes v1.37 即可启用此功能，Prometheus 抓取配置将适配以摄入新格式。迁移仪表板和告警涉及将 PromQL 查询从经典分桶引用更新为直接使用指标名称。推荐的迁移流程包括：初始启用两种格式，然后更新查询、验证，最后禁用经典格式抓取以节省存储。退出或回滚操作灵活，可通过调整 Prometheus 抓取配置或组件功能门控（feature gates）实现。该功能正迈向通用可用（General Availability）阶段，鼓励社区参与。

Kubernetes v1.37: Native Histograms Graduates to Beta kubernetes.io

RSS Hunter • 9月11日

Kubernetes v1.37：原地 Pod 扩容的调度器抢占（Alpha）

Kubernetes v1.35 引入了 Pod 原地扩容功能，允许在不重启的情况下动态调整 CPU 和内存。然而，在节点资源完全耗尽的情况下对 Pod 进行扩容，若存在容量不足，Pod 状态可能变为"Deferred"，导致其无限期等待资源可用。为解决此问题，Kubernetes v1.37 引入了用于 Pod 原地扩容的调度器抢占功能，当前处于 Alpha 阶段。该功能使 Kubernetes 调度器能够主动释放节点容量。若运行中 Pod 的原地扩容请求超出可用资源，调度器可抢占优先级较低的 Pod。这确保了关键应用即使在繁忙节点上也能完成扩容。抢占操作局限于 Pod 当前所在节点，针对符合条件的低优先级工作负载。这使得集群运营者能够通过二部打包（bin-packing）低优先级任务来最大化资源利用率。若无此功能，运营者将面临资源利用率不足或关键应用扩容失败的风险。该功能集成了调度器现有的跟踪机制，并将扩容抢占与标准 Pod 放置抢占区分开来。资源预留得到安全处理，以防止扩容过程中出现竞态条件。该功能需要 Kubernetes v1.37 或更高版本，并启用 InPlacePodVerticalScalingSchedulerPreemption 功能门控。管理员可通过 podPreemptionPolicy 字段为特定节点禁用扩容抢占。

Kubernetes v1.37: Scheduler Preemption for In-Place Pod Resize (Alpha) kubernetes.io

RSS Hunter • 9月10日

Kubernetes v1.37：节点生命周期条件介绍

Kubernetes 传统上缺乏一种统一的方式来描述 Node 的生命周期状态，仅能提供基本的状态信息。这往往导致理解碎片化，并可能引发不同集群组件之间的冲突。Kubernetes v1.37 引入了五个众所周知的 Node 条件以填补这一空白。这些新条件包括 DrainInProgress、Drained、MaintenancePlanned、MaintenanceInProgress 和 GracefulNodeShutdownInProgress。每个条件使用 True、False 或 Unknown 状态来表示其当前状态。管理员或授权控制器负责设置和清除这些条件。目前，核心工作负载控制器不会针对这些条件采取行动，但它们通过信号化 Node 生命周期事件提供了操作层面的清晰度。例如，自动化系统可以在工作开始前设置 MaintenancePlanned，在工作开始后设置 MaintenanceInProgress。同样，驱逐自动化系统可以相应地设置 DrainInProgress 和 Drained。推荐的模式是：使用这些条件进行状态报告，同时仍利用现有的 Kubernetes 机制执行实际的操作，如隔离（cordon）和驱逐（drain）。这种共享信号至关重要，因为从调度器到外部维护系统的各种集群组件都需要理解 Node 状态。如果没有它，组件可能会做出相互冲突的决策，例如 DaemonSet 控制器替换了在优雅关闭期间被有意终止的 Pod。这些新条件为 Node 生命周期管理的未来增强提供了稳定的基础。Kubernetes 社区正在积极征求对这些新条件的反馈，以改进优雅节点关闭和维护等场景。

Kubernetes v1.37: Introducing Node Lifecycle Conditions kubernetes.io

RSS Hunter • 9月9日

Kubernetes v1.37：推进工作负载感知调度

Kubernetes v1.37 为工作负载感知调度（Workload-Aware Scheduling）树立了重要里程碑，增强了对复杂批处理和 AI/ML 工作负载的支持。用于抢占式调度的核心 Workload 和 PodGroup API 已晋升至 Beta 阶段。本次发布引入了 CompositePodGroup API，以管理异构 Pod 组的分层调度需求。新的控制器集成 API 和 workloadbuilder Go 库简化了树外控制器与工作负载感知调度功能的集成。原生的 Job 控制器现已充分利用这些扩展 API，实现高级调度策略和拓扑感知。随着 Beta 阶段的晋升和版本更新，抢占式调度及 Workload/PodGroup API 更加稳健。PodGroup 队列机制得到改进，使 PodGroup 成为调度队列中的一等公民。PodGroup 的 minCount 字段现已可修改，支持弹性工作负载的动态调整。工作负载感知抢占已集成到 GenericWorkload 功能中，并尊重 PodGroup 的干扰模式。CompositePodGroup API 支持多级拓扑感知调度，允许在不同基础设施层级之间实现复杂的共置约束。

Kubernetes v1.37: Advancing Workload-Aware Scheduling kubernetes.io

RSS Hunter • 9月8日

Kubernetes v1.37：KubeletInUserNamespace（即无根模式）晋升为 Beta 版本

Kubernetes v1.37 将 KubeletInUserNamespace 特性提升至 beta 阶段，允许 kubelet 及运行时等节点组件以非 root 用户身份运行。该无 root 模式源于 2018 年的实验性探索，通过限制潜在的容器逃逸漏洞影响范围来增强安全性。与 Pod 用户命名空间不同，该特性聚焦于宿主机节点组件。该功能可缓解 CVE-2022-0811 和 CVE-2023-27561 等历史漏洞带来的风险，此类漏洞曾可能赋予攻击者 root 权限。在用户命名空间中运行可将攻击影响限制在非 root 用户账户内，防止对内核或固件的修改。用户命名空间本身无法防护内核漏洞，应与其他加固措施（如 seccomp）结合使用。该特性适用于多种场景，包括生产集群、共享机器、笔记本电脑及 AI 沙箱。其工作原理是将宿主机上的非 root 用户映射为命名空间内的伪 root，这已足以满足大多数节点组件任务的需求。用户命名空间需外部创建，例如使用 Rootless Docker。KubeletInUserNamespace 特性门控现已默认启用，允许 kubelet 忽略特定的权限错误。近期改进包括对 idmapped tmpfs、用户命名空间 Pod 及可写 cgroups 的更好支持，从而启用嵌套 Kubernetes 部署。kind、minikube、Usernetes 和 k3s 等工具提供了轻松创建无 root Kubernetes 集群的便捷方式。该项目计划在未来将该特性晋升为通用可用（General Availability）阶段，并欢迎社区参与。

Kubernetes v1.37: KubeletInUserNamespace (aka Rootless mode) Graduates to Beta kubernetes.io

RSS Hunter • 9月4日

Kubernetes v1.37：DRA 更新

Kubernetes 1.37 为动态资源分配（DRA）带来了重大进展，扩展资源支持已达到通用可用（GA）状态。这使得 DRA 驱动能够无需独立的设备插件即可管理传统扩展资源。ResourceClaim 的状态中现在包含 devices 字段，从而提升了对设备状态（如网络接口名称和 IP 地址）的可见性。DRA 设备污点和容忍度现已稳定，通过镜像节点污点来管理设备可用性和维护。标准化的 numaNode 设备属性确保了不同驱动之间命名的一致性。ResourceClaim 的工作负载支持已推进至 Beta 阶段，允许单个声明被多个 Pod 共享，克服了先前的限制。DRA 设备属性向下 API 现已进入 Beta 阶段，支持直接将设备属性注入工作负载，简化了自定义控制器的需求。Alpha 阶段的功能包括属性的列表类型，支持更复杂的设备匹配，以及节点可分配资源请求，以防止节点过度订阅。资源可用性可见性已进入第二个 Alpha 阶段，提供时间点快照。DRA 的可选节点操作允许驱动跳过不必要的节点设置调用。Derived Attributes 是一项新的 Alpha 功能，使用 CEL 表达式实现基于自定义规则的灵活设备匹配。DRA 设备兼容性组可防止调度不兼容的设备组合。PreQueueingHint 扩展点也处于 Alpha 阶段，通过减少扩缩容期间的扫描范围来优化 Pod 调度。DRA 可消耗容量现已支持分数值，提升了资源分配的精度。这些持续的发展彰显了 Kubernetes 致力于提升资源管理能力的承诺。

Kubernetes v1.37: DRA Updates kubernetes.io

RSS Hunter • 9月3日

Kubernetes v1.37：使用 HorizontalPodAutoscaler 将工作负载缩容至零

Kubernetes v1.37 现已默认提供将工作负载缩放到零副本的 Beta 级 API 支持。这使得 HorizontalPodAutoscaler 能够将闲置资源缩减至零，并在需要时重新扩容。此前，该功能需要外部附加组件或 Alpha 级特性门控。将工作负载缩放到零对于队列消费者类工作负载尤为有益，可显著节省资源，特别是在使用昂贵专用硬件的场景下。主要权衡在于冷启动时间增加，因为系统需要观察指标、调度 Pod 并启动应用程序。这种方法在任务可暂时保留在持久化队列中时最为有效。与 Pod 消失后不复存在的 CPU 或内存指标不同，对象指标和外部指标可独立持续存在。这使得 HorizontalPodAutoscaler 即使在没有任何工作 Pod 运行时，仍能继续监控队列长度等指标。要从零开始扩容，需要使用外部指标适配器（如 Prometheus Adapter）将指标（如队列消费者延迟）暴露给 Kubernetes。HorizontalPodAutoscaler 随后配置为最小副本数为零，并针对外部指标进行配置以决定扩容行为。一个特殊的 ScaledToZero 状态条件用于区分自动缩放到零与手动暂停，确保 HorizontalPodAutoscaler 能够恢复控制。该功能此前处于 Alpha 阶段，现已在 v1.37 中晋升为 Beta 级，并默认启用以提升资源效率。

Kubernetes v1.37: Scale Workloads to Zero with HorizontalPodAutoscaler kubernetes.io

RSS Hunter • 9月2日

Kubernetes v1.37：etcd RangeStream 大幅降低大型列表读取的内存占用

etcd 的 RangeStream 功能将在 Kubernetes v1.37 中晋升为 beta 版本，需配合 etcd v3.7 使用。该功能显著降低了 API 服务器和 etcd 在读取大量资源时的内存占用。此前，填充 API 服务器的 watch 缓存涉及从 etcd 进行昂贵的全量读取。虽然已有分页机制，但其基于键的数量而非对象大小，导致内存峰值不可预测，并可能引发内存溢出（Out-Of-Memory）错误。etcd 的单次 Range RPC 会在发送前组装整个页面，加剧了 etcd 和 API 服务器的内存压力。etcd v3.7 中的新 RangeStream RPC 通过将结果以块（chunks）形式流式传输来解决此问题。块大小会根据值的大小自适应调整，将读取限制在字节数而非键的数量上。这使得随着流式传输的进行，内存可以逐步释放。当启用 EtcdRangeStream 功能门控（feature gate）时，API 服务器将 RangeStream 用于 watch 缓存初始化以及回退的列表请求。它会解码并释放到达的块，防止整个集合同时驻留在内存中。该功能需要 Kubernetes v1.37+ 和 etcd v3.7+。API 服务器会自动检测 etcd 的支持情况，若 RangeStream 未实现则自动回退。要确认 RangeStream 是否已激活，请监控 etcd_request_duration_seconds_count{operation="listStream"} 指标，观察其是否显示非零值。

Kubernetes v1.37: etcd RangeStream Cuts Memory Use on Large List Reads kubernetes.io

RSS Hunter • 9月1日

Kubernetes v1.37：默认启用存储版本迁移

存储版本迁移（Storage Version Migration，SVM）已在 Kubernetes v1.37 中达到通用可用（General Availability）状态，并默认启用。该功能解决了更新 Kubernetes API 资源存储版本的挑战。资源使用特定的模式表示进行存储，对该表示的变更需要重写现有对象。一个常见用例是将自定义资源定义（CRD）提升至更新的 API 版本，同时弃用旧版本。若无 SVM，当资源仍在使用旧版本进行存储时，移除旧版本是不安全的。同样，静态加密或密钥轮换也需要重写已存储的数据以应用新的加密方式。此前，这需要手动脚本或外部工具，存在错误风险且难以管理。SVM 通过引入声明式的 StorageVersionMigration API 对象简化了这一过程。内置控制器会监听这些对象，并自动将资源迁移到指定的默认存储版本。启动迁移涉及创建 StorageVersionMigration 对象，随后由控制器进行处理。可以监控迁移状态，成功完成表明所有资源均已更新。CRD 作者现在可以在 CRD 升级中直接包含迁移清单，从而实现更流畅的流程。

Kubernetes v1.37: Storage Version Migration Enabled by Default kubernetes.io

RSS Hunter • 8月31日

Kubernetes v1.37：Pod 证书与集群信任存储

Kubernetes 引入了 Pod 证书（Pod Certificates）和集群信任捆绑包（Cluster Trust Bundles）作为新的生产级身份机制。该功能现已普遍可用，将 X.509 证书签发直接集成到核心 Kubernetes 中，用于 TLS 和 mTLS。这是相对于之前主要机制——服务账户 JWT——的重大进步。虽然 JWT 具有易用性和广泛的兼容性，但其存在一个关键弱点：作为持有者令牌（bearer tokens），一旦泄露便容易遭受未经授权的访问。相比之下，Pod 证书基于非对称密码学的“持有证明”凭据，主要采用 X.509 证书。这通过要求证明持有者身份而非仅仅共享凭据本身，从而增强了安全性。目标是使 Kubernetes 工作负载使用 X.509 证书的过程与使用 JWT 一样简便，同时保持高标准的安全性。Pod 证书旨在提供灵活性，通过可插拔接口支持单个集群内多种类型的证书，这与服务账户 JWT 单一标准化的形式形成对比。未来的 Kubernetes 版本预计将提供内置的证书颁发程序，用于服务 DNS 名称和 SPIFFE 客户端证书。该架构涉及应用程序请求证书、Kubelet 发起请求并管理信任捆绑包，以及签名控制器（signer controller）履行这些请求并发布信任捆绑包。签发过程按时间顺序进行，从 Pod 调度开始，直至应用程序访问其密钥和证书。自动轮换已内置，应用程序需处理这些更新。安全检测已集成到 kube-apiserver 中，以强制实施隔离并防止受损节点获得不当访问权限。若要实验这些功能，用户需要安装第三方签名器（如 Tinycert），它提供示例签名器和库，以帮助应用程序加载 SPIFFE 证书。

Kubernetes v1.37: Pod Certificates and Cluster Trust Bundles kubernetes.io

RSS Hunter • 8月28日

Kubernetes v1.37：指标API升级为稳定版

Kubernetes v1.37 已将 metrics.k8s.io API 晋升为稳定的 v1 版本。该 API 为节点和 Pod 提供关键的 CPU 和内存使用数据，支撑着 kubectl top 以及基于资源指标的水平自动扩缩容等关键功能。对于集群操作人员和开发人员而言，此次晋升标志着该 API 具有保证的稳定性。v1 API 保留了与其前身 v1beta1 相同的资源类型和字段。该资源指标 API 自 v1.6 作为 alpha 版本引入，在 v1.8 中晋升为 beta 版本，并已在生产环境中可靠使用多年。该 API 暴露 NodeMetrics 以提供节点资源使用情况，以及 PodMetrics 以提供 Pod 资源使用情况（包括按容器细分的数据）。该 API 仅提供自动扩缩容和基本检查所需的指标，而非完整的监控解决方案。v1 API 的接口表面与 v1beta1 完全相同，仅 API 版本本身除外。虽然 kubectl top 支持这两个版本并优先使用 v1，但水平 Pod 自动扩缩容控制器目前仅支持 v1beta1。无需启用任何特性门控，因为该 API 通过 metrics-server 等实现提供的 API 聚合进行服务。要使 v1 可用，实现必须提供该版本并注册关联的 APIService。在此过渡期间，为实现向后兼容，实现应继续同时提供 v1 和 v1beta1。

Kubernetes v1.37: Metrics API graduates to stable kubernetes.io

RSS Hunter • 8月27日

Kubernetes v1.37： Garhwal

Kubernetes v1.37 以“加瓦尔”（Garhwal）为主题正式发布，共包含 67 项增强功能。其中，16 项功能晋升为稳定版（Stable），23 项进入候选版（Beta），27 项进入预览版（Alpha）。本次发布主题象征着社区贡献的互联互通。一项关键的稳定版更新是弹性 Watch 缓存初始化，通过防止 etcd 过载，提升了 API 服务器的启动与恢复能力。水平 Pod 自动伸缩器（HPA）的缩至零支持现已进入候选版，允许工作负载在空闲时缩容以降低成本，但不支持 CPU 和内存指标。基于清单的准入控制配置也晋升为候选版，使得策略和 Webhook 可从磁盘加载。预览版新增功能包括 Pod 级别的检查点与恢复，通过为容器运行时扩展新的 RPC 接口来增强容器运行时接口（CRI）。值得关注的稳定版晋升包括 KYAML（用于更安全的 YAML 子集）以及 metrics.k8s.io API（用于资源使用监控）。SELinuxMount 和 SELinuxChangePolicy 标志现已稳定并默认启用，适用于卷。多项设备资源分配（DRA）功能已晋升为稳定版，包括设备配置的资源声明状态、扩展资源请求的处理、设备污点与容忍度，以及标准化的 NUMA 节点设备属性。节点声明功能（Node declared features），一个用于声明功能门控节点能力的框架，也晋升为稳定版。

Kubernetes v1.37: Garhwal kubernetes.io

RSS Hunter • 8月26日

如何以 KYAML 格式美化打印您的 Kubernetes YAML 以及您为何需要这样做

KYAML 提供了一种更严格、更一致的编写 Kubernetes 清单的方式，解决了标准 YAML 中存在的问题。作为 YAML 的子集，KYAML 在保持与现有解析器兼容的同时，限制了风格选择。其目标是防止常见陷阱，如空格敏感性和静默类型转换，这些陷阱可能导致意外行为。与标准 YAML 不同，KYAML 显式定义结构和类型，使用花括号表示映射，使用方括号表示列表。它强制要求对字符串值进行引号包裹，以避免静默类型转换，例如“挪威虫”问题，其中"NO"被解析为布尔值 false。KYAML 还支持注释和尾随逗号，相比 JSON 提升了配置编写体验。Kubernetes 1.34+ 支持通过 kubectl -o kyaml 生成 KYAML 输出。工具如 sigs.k8s.io/yamlfmt 和 google/yamlfmt 可将现有 YAML 文件转换为 KYAML 格式。采用 KYAML 是一种追求更高一致性和更少错误的选择，尤其在团队环境中，且无需更改现有的 Kubernetes 工具或流水线。这是一种编写更健壮配置的新习惯，而非强制迁移。

How to Pretty-Print Your Kubernetes YAML as KYAML and Why You'd Want To kubernetes.io

RSS Hunter • 8月11日

Gateway API v1.6：TCPRoute 和 UDPRoute 晋升为标准

Kubernetes Gateway API 已发布 1.6.0 版本，增强了其服务网络功能。此次发布通过标准化第 4 层协议路由，标志着重大进展。此前，Gateway API 的稳定基础主要面向 HTTP 和 TLS 流量。1.6.0 版本现已将 TCPRoute 和 UDPRoute 资源纳入稳定的 v1 API。这些资源支持对原始 TCP 和 UDP 流量进行路由，填补了数据库和物联网遥测等工作负载的空白。同时，实验性创新的流程也得到优化，API 边界更加清晰。新的实验性资源现位于独立的 API 组 gateway.networking.x-k8s.io 中，并使用"X"前缀。这一区分使得实验性与标准资源更易识别。例如，XBackend 资源是一项新的实验性添加，支持扩展后端配置，允许使用此前对稳定版 Service 资源存在问题的 ExternalHostname 等目标。该实验性功能专为向云 API 发起的出向流量等用例设计。TCP 和 UDP 路由晋升为稳定版，进一步巩固了 Gateway API 作为通用网络解决方案的地位。用户现在可以采用 1.6.0 版本，并配合各种兼容的 Gateway 控制器实现。Gateway API 社区鼓励用户和开发者提供反馈并贡献代码。

Gateway API v1.6: TCPRoute and UDPRoute Graduate to Standard kubernetes.io

RSS Hunter • 8月3日

Kubernetes v1.37 抢先预览

Kubernetes v1.37 即将发布，并包含多项计划变更。kubectl run 的 --filename/-f 标志将被弃用。由于一项错误修复，静态 Pod 将不再能直接引用 Secret 或 ConfigMap。Kube-proxy 对 IPVS 模式的支持正在被弃用，并将在 v1.43 中被移除。对 cgroup v1 的支持正在逐步淘汰，用户应迁移至 cgroup v2。SELinux 卷重新标记（即 SELinuxMount）将晋升为通用可用（GA）阶段。metrics.k8s.io API 在经历近九年的 Beta 阶段后，也将晋升为 GA。Kubelet 的用户命名空间（即无根模式）预计将晋升为 Beta 阶段。卷健康监控功能将以新的 CSI RPC 形式重新引入 Alpha 阶段。这些变更旨在提升 Kubernetes 环境的维护性和健康度。

Kubernetes v1.37 Sneak Peek kubernetes.io

RSS Hunter • 7月31日

controller-runtime 缓存的实际工作原理，以及为何您的控制器不会导致 API Server 崩溃

Kubernetes 控制器通常使用 Go 语言，借助 kubebuilder 和 controller-runtime 进行开发，能够高效地处理分布式工作负载。然而，随着负载增加，深入理解 controller-runtime 的内部机制变得至关重要，以避免生产环境问题。其核心概念是：Reconciler 中的 r.Get() 和 r.List() 并不直接查询 API Server，而是访问本地内存缓存。该缓存最初通过一次列表操作填充，随后通过 Watch 机制持续维护。这种设计使得本地读取速度极快，避免了对控制平面的压力。然而，其代价是本地缓存可能消耗大量内存，且可能返回陈旧数据。相反，写入操作始终直接指向 API Server，绕过缓存。本地缓存的大小及索引策略直接影响内存使用。低效的 List() 操作可能导致对大量对象进行缓慢的线性扫描。Reconciliation Loop（对等循环）持续比较期望状态与实际状态，以使其保持一致。事件被加入队列，触发 Reconcile 函数，该函数读取当前状态、确定必要操作，并可能生成新事件。缓存的主要目的是为这些对等循环提供快速、最新的对象状态视图。这种基于 Watch 的模型源自 client-go，通过维护单个长连接来接收更新，从而避免了对 API 的持续轮询。controller-runtime 抽象了底层 client-go 组件（如 Reflector、DeltaFIFO 和 Indexer）的复杂性。Manager 负责协调共享缓存、控制器及其他服务。Informer 监控特定的 GVK，维护本地存储（Indexer），并将事件分发给订阅者。ResourceEventHandlers 处理这些事件，更新存储，进而反映在控制器的视图中。Workqueue 管理待由 Worker 处理的对象键，而 Predicates 则在入队前过滤事件。Reflector 是唯一直接与 API Server 交互的组件，执行初始列表操作，随后建立 Watch。它利用 resourceVersion 恢复 Watch 并确保不遗漏任何事件。如果 Watch 连接丢失或 API Server 指示 resourceVersion 过时，则执行重新列表（relist）。DeltaFIFO 充当变更的有序缓冲区，按对象键对 Delta 进行分组。它为自上次 Pop() 调用以来对象累积的所有变更提供数据，确保有序、批量的处理。然而，它不会合并连续的"Added"或"Updated"事件，这可能导致对快速变化的对象进行多次处理轮次。

How the controller-runtime Cache Actually Works, and Why Your Controller Does Not Crash the API Server kubernetes.io

RSS Hunter • 7月29日

为Kubernetes构建自定义指标导出器

Kubernetes 基于 CPU 和内存进行扩缩容，但现实场景中的需求往往需要自定义指标，例如队列深度或活跃连接数。Prometheus 指标导出器通过 HTTP 的 /metrics 端点以纯文本形式暴露应用状态，供 Prometheus 抓取，从而弥合这一差距。导出器可以是独立服务，也可以直接嵌入应用程序中，具体取决于数据源以及对应用代码的控制程度。Prometheus 期望指标采用特定格式：计数器（counters）用于持续递增的值，观测值（gauges）用于波动值，直方图（histograms）用于分布数据。指标名称应遵循清晰的蛇形命名法（snake_case）约定，即使用下划线分隔单词。使用 Go 构建导出器涉及初始化模块、配置 Prometheus 客户端库，并注册计数器、观测值和直方图等指标。这些指标随后由一个轮询循环更新，该循环从应用程序的数据源读取数据。HTTP 服务器暴露 /metrics 端点，同时提供 /healthz 端点用于存活探针。导出器通过多阶段 Docker 构建打包为精简的容器镜像，确保占用极小的资源。部署到 Kubernetes 集群时，需使用 Deployment 进行 Pod 管理，并使用 Service 为 Prometheus 提供稳定的地址。Prometheus 通过 ServiceMonitor 发现这些指标（若使用 Prometheus Operator），或通过 Pod 模板中的注解进行基于注解的发现。验证过程包括检查 Prometheus 的目标页面，确保导出器状态为"UP"，并在表达式浏览器中查询指标。这一基础支持使用 HorizontalPodAutoscaler 进行自动扩缩容，该组件利用指标适配器（如 Prometheus Adapter）将自定义指标集成到 Kubernetes 自定义指标 API 中。这使得工作负载能够基于业务相关信号而非仅基础资源利用率进行扩缩容。

Building a Custom Metrics Exporter for Kubernetes kubernetes.io

RSS Hunter • 7月14日

在 Kubernetes 上运行 AI/ML 工作负载：Kubeflow 的 Headlamp 插件

Kubernetes 正逐渐成为 AI 和机器学习工作负载的默认平台。Kubeflow 是一款流行的工具，它利用 Kubernetes 的自定义资源定义（CRD）来管理这些机器学习任务。虽然 Kubeflow 的专用仪表板有助于数据科学家，但它们往往掩盖了底层的 Kubernetes 层，迫使运维人员使用 kubectl 进行故障排查。Headlamp Kubeflow 插件填补了这一空白，它在一个通用的 Kubernetes UI 中直接展示 Kubeflow 的自定义资源。这使得运维人员能够使用与其他集群组件相同的原语来观察和管理机器学习资源。Headlamp 本身是一个可扩展的 Kubernetes Web UI，由 Kubernetes SIG UI 维护。该插件通过直接查询 Kubernetes API 服务器提供集群级别的洞察，展示各命名空间中 Pod 的状态、失败原因和资源状态等详细信息。它支持多种 Kubeflow 组件，包括 Notebooks、Pipelines、用于超参数调优的 Katib、Training 和 Spark。该插件允许在不依赖 Kubeflow 后端数据库的情况下检查 Notebook Pod 详情、Katib 试验状态和 Pipeline 状态。它还将机器学习资源映射为 Headlamp 中的图节点，可视化它们之间的关系。这种方法为任何以 CRD 为主的平台提供了一种模式，使其能够在运维人员熟悉的工具中直接提供必要的集群级别可见性。

Operating AI/ML Workloads on Kubernetes: A Headlamp Plugin for Kubeflow kubernetes.io

RSS Hunter • 7月13日

Kubernetes 仪表盘到大灯：逐步指南

Kubernetes Dashboard 和 Headlamp 均提供集群可见性，但功能实现方式不同。Headlamp 是桌面端或集群内客户端，通过 kubeconfig 连接多个集群，并尊重用户身份。Kubernetes Dashboard 是集群内的 Web 应用，通常通过令牌认证访问。迁移时，需记录当前 Dashboard 的使用情况，验证 kubeconfig 是否可用，并选择部署方案（如并行部署）。需决定 Headlamp 是运行在桌面端还是集群内：桌面端更适合个人使用且速度更快，集群内部署则更适合共享访问。桌面端安装可通过包管理器轻松完成，而集群内安装则使用 Helm 或 YAML 清单。桌面端 Headlamp 的认证依赖 kubeconfig，而集群内部署通常采用 OpenID Connect (OIDC) 或外部认证层进行登录。Headlamp 遵循 RBAC 权限，用户仅能看到并执行其被授权的操作。Headlamp 在多集群管理方面表现卓越，允许用户直接在 UI 中通过 kubeconfig 切换集群，相比 Kubernetes Dashboard 的单集群聚焦模式，提供了更集成的体验。

Kubernetes Dashboard to Headlamp: A Step-by-Step Guide kubernetes.io

RSS Hunter • 7月13日

发布 etcd v3.7.0

SIG etcd 宣布发布 etcd v3.7.0，这是对分布式键值存储的一次重大更新。此次发布引入了备受期待的 RangeStream 功能，支持高效流式传输大型结果集。同时，还带来了多项性能提升，包括更快的租约操作以及优化的仅键范围请求。已完全移除对遗留 v2 存储的依赖，etcd 现在仅从 v3store 启动，简化了操作流程。全面的 protobuf 重构将过时库替换为受支持的版本，提升了安全性和可维护性。此次发布还更新了核心依赖项：bbolt 至 v1.5.1，raft 至 v3.7.0。其他改进包括支持 Unix 套接字以用于本地开发和测试。etcdutl 命令现已支持超时参数，防止无限期阻塞。Client v3 提供了更灵活的认证方式，支持直接设置 JWT，并可在未预先认证的情况下获取 AuthStatus。新增了 watch 和请求持续时间指标，以增强可观测性。etcdctl 命令已重新组织以提高清晰度，并移除了已弃用的实验性标志。此外，还对遗留 v2 API 包和代码进行了大幅清理。

Announcing etcd v3.7.0 kubernetes.io

RSS Hunter • 7月8日

人工智能时代的开源维护

人工智能正在变革软件开发，通过代码生成赋能更多贡献者。然而，这一进展快于代码维护能力的提升，构成了挑战。Kubernetes 社区正积极适应人工智能辅助编程，制定了一项全面的 AI 政策。该政策旨在平衡创新与问责，确保代码质量与人工监督。核心原则是透明性，要求贡献者在拉取请求（Pull Request）中披露人工智能使用情况。至关重要的是，人类问责制始终居于首位；人工智能不能作为合著者或共同签署人。贡献者还必须亲自解释任何由人工智能生成的代码，以避免知识断层。该项目对所有合著者（包括人工智能辅助的）强制执行贡献者许可协议（Contributor License Agreements），并对不完整的拉取请求进行标记。社区正在探索自动化人工智能审查，以提升代码质量并提供初步反馈。GitHub Copilot 和 CodeRabbit 等工具正在特定的 Kubernetes 项目中进行评估和测试。这些工具可作为质量门禁，在人工审查前提供快速抽查。社区正积极寻求协助，以调优审查工具、评估新兴人工智能技术，并探索人工智能在减少维护者倦怠以及协助测试分诊方面的潜力。

Open source maintainership in the age of AI kubernetes.io

RSS Hunter • 6月26日

介绍Cluster接口（Headlamp）插件

Headlamp 是一个开源的 Kubernetes 用户界面项目，用于通过浏览器管理集群资源。Cluster API（CAPI）为集群生命周期管理提供声明式、Kubernetes 风格的 API。Headlamp Cluster API 插件简化了 CAPI 资源的管理，无需使用原始的 kubectl 命令。该插件在 Headlamp 中添加了专用的 CAPI 部分，通过一致的列表和详情视图提供对核心 CAPI 资源的完整可见性。主要功能包括集群概览、Machine 可见性以及用于健康监控的集中式 Cluster API 仪表板。用户可以跟踪 KubeadmControlPlane 副本、扩缩 MachineDeployments 和 MachineSets，并可视化所拥有资源的层级结构。该插件还支持在不使用原始 YAML 的情况下检查 KubeadmConfig，并提供拓扑感知能力。地图视图可视化了 Cluster、Control Plane 和 Worker 之间的关系，支持 v1beta1 和 v1beta2 两个 Cluster API 版本。Prometheus 指标已集成，可在详情页面内联显示实时性能数据。该插件是在 CNCF LFX Mentorship 项目期间开发的，旨在提升 Cluster API 的管理体验。此为 Alpha 版本，欢迎社区反馈以指导后续开发。

Introducing the Cluster API plugin for Headlamp kubernetes.io

RSS Hunter • 6月25日

使用头灯更快地检查火山工作负载

Volcano 是一款专为 Kubernetes 设计的云原生批处理调度器，面向高性能计算、AI/ML 及其他批处理工作负载。Kubernetes 最初是为长运行服务而构建，而批处理工作负载通常需要动态作业到达、资源竞争以及同时启动多个工作节点。Volcano 通过引入队列、优先级、配额和 Gang 调度等概念扩展了 Kubernetes，将工作负载视为整体而非独立的 Pod 进行管理。Volcano 为 Headlamp（一个可扩展的 Kubernetes Web UI）提供的插件将这些调度细节集成到单一界面中。该插件为 Volcano Jobs、Queues 和 PodGroups 提供专用视图，使批处理工作负载的运维和故障排查更加便捷。Job 视图显示工作负载状态、任务详情、Pod 状态，并支持直接执行挂起/恢复操作及访问日志。Queue 视图提供资源分配、容量及预留详情的洞察。PodGroup 视图则清晰展示 Gang 调度状态及潜在阻塞因素。关键特性是地图视图，它以可视化方式呈现 Jobs、Queues、PodGroups 和 Pod 之间的互联关系，有助于快速识别处于待处理或非进展状态的工作负载中的问题。该插件通过集中相关资源、结构化详情和运行时输出，增强了交互式故障排查体验，同时不替代用于自动化的 CLI 工具。未来的增强功能可能包括 Prometheus 集成及更丰富的调度洞察。用户可通过 Headlamp 的插件目录安装该插件，并提供反馈以推动其开发演进。

Inspect Volcano workloads faster with Headlamp kubernetes.io

RSS Hunter • 6月25日

查看您的无服务器架构：介绍用于 Knative 的 Headlamp 插件

Headlamp 是一个开源项目，旨在管理和调试 Kubernetes 资源。Knative 可在 Kubernetes 上实现无服务器工作负载，但在跨多个工具进行操作时可能较为复杂。为解决这一问题，已开发了一个针对 Knative 的 Headlamp 插件。该插件允许用户在 Headlamp 内部对 Knative 进行广泛管理。它将 Knative 资源集成到 Headlamp 的资源映射视图中，展示 KService、Revision 和 DomainMapping 之间的关系。该插件提供 KService 的详细视图，支持对流量分割和自动扩缩配配置进行实时编辑。用户还可以直接从 KService 头部重启 Pod 并访问日志。该插件支持针对 Revision 进行细粒度的流量分割，以分阶段发布和 A/B 测试。它以可视化方式展示每个 Revision 的流量分布、就绪状态和标签。自动扩缩配配置清晰呈现，并标明设置是显式配置还是继承自集群默认值。当与 Prometheus 插件结合使用时，可提供 KService 和 Revision 的请求速率和延迟等指标。该插件还为其他 Knative CRD（包括 Revision、DomainMapping 以及网络概览）提供列表和详情视图。安装过程涉及在 Headlamp 的插件目录中搜索并安装 Knative 插件。反馈和错误报告可通过 GitHub Issues 或 Kubernetes Slack 频道提交。

See your serverless: introducing the Headlamp plugin for Knative kubernetes.io

RSS Hunter • 6月25日

聚焦 WG 设备管理

设备管理工作组（Device Management Working Group）应对 Kubernetes 中对专用硬件管理日益增长的需求。传统的资源分配方法已不足以支持需要 GPU、TPU 及特定网络接口的 AI、边缘计算和电信工作负载。该工作组的主要项目——动态资源分配（Dynamic Resource Allocation, DRA）——现已达到通用可用（General Availability）状态，标志着重大进展。DRA 提供了一个结构化的四阶段设备管理框架：建模、请求、调度和执行。这一新方法使供应商能够以细粒度方式宣传硬件能力，使用户能够精确指定硬件需求，随后 Kubernetes 调度器将智能地将这些需求与可用硬件进行匹配。DRA 取代了将设备视为简单整数的遗留设备插件 API（Device Plugin API），转而采用灵活且声明式的 API。该工作组是一项跨 SIG 的协作努力，涉及多个 SIG，以确保在 Kubernetes 各组件之间实现全面集成。当前的重点举措包括增强 DRA 的表达力、支持操作可见性，以及改进多节点和复杂硬件拓扑管理。未来的工作将涵盖设备健康监测以及对分组设备使用场景的更好支持。该工作组旨在为 Kubernetes 构建一个更具可编程性且更感知硬件的未来。

Spotlight on WG Device Management kubernetes.io

RSS Hunter • 6月24日

聚焦SIG存储

本文聚焦于 SIG Storage，即负责持久化数据与卷管理的 Kubernetes 特殊兴趣组。SIG Storage 联合主席杨兴探讨了该小组从管理基础持久化卷到推进复杂存储功能的演进历程。Kubernetes 最初设计用于无状态工作负载，如今已支持有状态应用，因此需要专门的存储解决方案。SIG Storage 应运而生，引入了持久化卷（PersistentVolumes）和持久化卷声明（PersistentVolumeClaims）等基础原语。一项重大进展是容器存储接口（Container Storage Interface, CSI），它使第三方存储提供商能够在无需修改 Kubernetes 核心的情况下将其系统集成。当前工作包括卷组快照（Volume Group Snapshot）和变更块跟踪（Changed Block Tracking），前者支持崩溃一致的多卷快照，后者用于高效备份，两者近期均已晋升至稳定版本。容器对象存储接口（Container Object Storage Interface, COSI）也在推进中，旨在标准化对象存储集成。用户近期的收获包括 VolumeAttributesClass 晋升至通用可用（General Availability）阶段，允许动态调整存储属性（如 IOPS）。未来路线图涵盖卷健康检查（Volume Health），以提升运维可见性并实现潜在的自动修复。SIG Storage 寻求社区协助，包括修复漏洞、编写测试、审查代码以及对可变卷亲和性（Mutable PV Affinity）和卷复制等功能提供反馈。有状态工作负载面临的挑战包括数据重力、日常运维复杂性以及数据迁移。随着 AI 工作负载的增长，Kubernetes 中的存储预计将变得更加智能，对象存储的地位也将日益凸显。高性能、低延迟存储以及数据感知调度也是预期的趋势。SIG Storage 邀请社区参与，以应对这些不断演进的存储需求。

Spotlight on SIG Storage kubernetes.io

RSS Hunter • 6月15日

从 Kubernetes Dashboard 到 Headlamp：理解这一转变

Kubernetes Dashboard 曾作为 Kubernetes 的主要可视化界面，现已归档。它曾是众多用户的重要入门工具，简化了集群可见性与资源检查。Headlamp 继承这一传统，在 Dashboard 的基础上构建，提供清晰的可视化界面，同时融入现代 Kubernetes 使用模式。Headlamp 支持多集群可见性，通过 Projects 提供以应用为中心的视图，并借助插件实现扩展性。此次迁移旨在致敬 Dashboard 以用户为中心的传统，并提供一个不断发展的 UI 解决方案。Headlamp 保留了 Kubernetes Dashboard 中的许多熟悉工作流，确保连续性与易用性。Headlamp 通过允许从单一界面管理多集群来扩展功能，降低分布式环境的摩擦。Headlamp 中的 Projects 提供以应用为中心的视图，将相关资源分组，以便更好地理解和排查问题。该平台还可通过插件进行扩展，例如用于 GitOps 工作流的 Flux 插件或提供指导的 AI 助手。Headlamp 提供灵活的部署选项，既可作为集群内工具，也可作为桌面应用程序使用。了解当前 Dashboard 的使用情况（包括集群、命名空间和认证）有助于顺利过渡到 Headlamp。

From Kubernetes Dashboard to Headlamp: Understanding the Transition kubernetes.io

RSS Hunter • 6月1日

弥合过去：修正未修复 Kubernetes CVE 的记录

Kubernetes 正通过优化其 CVE 记录以提升准确性，从而增强透明度。他们发现旧版 CVE 记录存在不一致之处，部分记录错误地列出了修复版本。Kubernetes 安全响应委员会将于 2026 年 6 月 1 日更正这些记录。此举可能导致漏洞扫描器识别出此前未被发现的问题。本文提供三项未修复漏洞的技术细节：CVE-2020-8561、CVE-2020-8562 和 CVE-2021-25740。此次更新确保漏洞扫描的准确性，并阐明持续性的管理缓解需求。另一项未修复的漏洞 CVE-2020-8554 也将采用标准化的版本号格式。所识别的漏洞之所以保持未修复状态，是因为修复它们将破坏 Kubernetes 的核心功能。每个漏洞均有特定的缓解措施，管理员应予以实施以保障集群安全。鉴于这些漏洞具有架构层面的特性，采取上述行动至关重要。该项目强调“通过配置实现安全”的方法以管理此类风险。更新这些记录体现了安全生态系统的成熟，促进了透明度与准确的风险评估。

Reconciling the Past: Correcting Records for Unfixed Kubernetes CVEs kubernetes.io

RSS Hunter • 5月26日

宣布etcd 3.7.0-beta.0

SIG-Etcd 发布了 etcd v3.7.0 的首个 beta 版本，这是分布式数据库的一次重大更新。该版本引入了 RangeStream 功能，旨在优化大规模结果集的处理，从而提升延迟性能和内存管理效率。此次发布还包含对遗留组件和接口的重构与清理，进一步提升了整体性能。开发团队鼓励用户测试该 beta 版本，并在 etcd 仓库中报告发现的问题。一个关键亮点是彻底移除了 etcd v2store 的最后残留，完成了向 v3store 的过渡。此次过渡可能引入破坏性变更，尤其对于未升级至 v3.6.11 的用户，因此恳请反馈所遇到的任何问题。该 beta 版本还集成了 bbolt 和 raft 库的更新。此外，发布时间表与 etcd v3.4 的生命周期结束（EOL）相关联，该版本将于五月后停止更新。社区已准备好在最终弃用前，根据需要为 v3.4 发布额外的安全补丁。用户被敦促从 v3.4 升级。未来计划发布更多 beta 版本，可能包含进一步的 protobuf 重构，随后推出候选版本，最终版本预计于六月或七月初发布。反馈可通过 GitHub 问题、Kubernetes Slack 频道以及 etcd-dev 邮件列表积极提交。

Announcing etcd 3.7.0-beta.0 kubernetes.io

RSS Hunter • 5月20日

Kubernetes v1.36：云控制器管理器中新增路由同步指标

本文原日期标注有误，现更正为 2026 年 5 月 15 日发布。Kubernetes v1.36 为 Cloud Controller Manager 的路由控制器引入了一个新的 alpha 指标 route_controller_route_sync_total。该指标用于跟踪与云提供商的路由同步操作，有助于监控 CloudControllerManagerWatchBasedRoutesReconciliation 特性门控。该特性于 v1.35 引入，将路由控制器切换为基于监听（watch-based）的方式。此变更通过仅在节点变更时同步路由，从而减少了 API 调用。为测试该新特性，请对比特性门控禁用与启用时该指标的行为。当特性门控禁用时，计数器以固定间隔递增；而当特性门控启用时，计数器仅在节点变更时递增。在节点修改不频繁的稳定集群中，这种差异尤为明显。反馈可通过 Kubernetes Slack、GitHub Issue 以及 SIG Cloud Provider 社区页面提供。更多详细信息请参阅 KEP-5237。

Kubernetes v1.36: New Metric for Route Sync in the Cloud Controller Manager kubernetes.io

RSS Hunter • 5月15日

Kubernetes v1.36：混合版本代理晋升为 Beta 版

混合版本代理（MVP）通过安全地将未知资源的请求路由到更新的 API 服务器，防止出现 404 错误，从而增强 Kubernetes 集群升级。MVP 最初作为 Kubernetes 1.28 的 Alpha 功能引入，现将在 1.36 版本中进入 Beta 阶段并默认启用。MVP 解决了升级过程中不同版本的 API 服务器之间的问题：当请求新资源时，旧版服务器可能会失败。此前会返回错误的 404，而现在请求将被代理到能够处理该请求的服务器。MVP 的 Beta 版本使用聚合发现（aggregated discovery）替代 StorageVersion API 来确定对等节点的能力，从而提升功能。此次更新还包含对等聚合发现（peer-aggregated discovery），为客户提供所有可用 API 的统一视图。要启用 MVP，API 服务器需要 --peer-ca-file 标志；如有需要，还需添加 --peer-advertise-ip 和 --peer-advertise-port 标志。使用 kubeadm 时，您可以在 ClusterConfiguration 文件中包含这些标志以简化流程。鼓励用户在预发布环境中测试 MVP，并将反馈提供给 SIG API Machinery，作为 1.36 升级的一部分。

Kubernetes v1.36: Mixed Version Proxy Graduates to Beta kubernetes.io

RSS Hunter • 5月15日

Kubernetes v1.36：弃用并移除 Service 的 ExternalIPs

Kubernetes 服务中的 .spec.externalIPs 字段最初设计用于非云负载均衡功能，现因 CVE-2020-8554 所揭示的安全漏洞而被弃用。该字段允许指定服务响应的额外 IP 地址，但其存在固有的安全风险，因为它假设所有用户之间互信。Kubernetes 1.21 已建议禁用 .spec.externalIPs，并引入了 admission controller 以强制执行此策略。替代方案包括手动管理的 LoadBalancer 服务或非云负载均衡控制器（如 MetalLB），后者能提供更高的安全性和控制力。MetalLB 允许管理员控制 IP 地址分配，从而缓解安全顾虑。Gateway API 也提供了一种安全解决方案，管理员可通过 Gateway 资源对 IP 进行控制。Kubernetes 1.36 正式弃用 .spec.externalIPs，并开始对其使用发出警告。未来版本中将禁用 Kube-proxy 对该特性的支持，并在后续版本中完全移除。建议用户迁移至该不安全特性。

Kubernetes v1.36: Deprecation and removal of Service ExternalIPs kubernetes.io

RSS Hunter • 5月14日

Kubernetes v1.36：推进工作负载感知调度

Kubernetes v1.35 引入了感知工作负载的调度改进，包括 Workload API 以及针对相同 Pod 的基础 Gang 调度。Kubernetes v1.36 通过分离 Workload API（静态模板）与新的 PodGroup API（运行时状态）来优化该架构。这种分离简化了 kube-scheduler，使其能够直接读取 PodGroup 信息以提升性能。新的 PodGroup 调度周期支持工作负载的原子化处理，将整个组作为统一操作进行评估，以防止死锁。若找到有效放置方案且满足组约束，则 Pod 将被绑定在一起；否则，整个组将被视为不可调度，稍后重试。这构成了 Gang 调度的基础，确保严格工作负载需求的全有或全无放置。v1.36 中的感知拓扑调度允许在 PodGroup 上定义拓扑约束，将 Pod 共置于特定的物理或逻辑域内，以降低网络延迟。这涉及基于调度约束生成、评估和评分候选放置方案。引入了感知工作负载的抢占功能，以支持 PodGroup 调度周期，可同时从多个节点抢占 Pod，为整个 PodGroup 腾出空间。它将 PodGroup 视为单个抢占单元，PodGroup 的 priority 和 disruptionMode 字段控制抢占行为。最后，v1.36 将动态资源分配（DRA）与 Workload API 集成，允许 PodGroup 通过 ResourceClaims 请求和共享专用硬件资源。这些进展为在后续 Kubernetes 版本中构建高级工作负载调度能力奠定了坚实基础。

Kubernetes v1.36: Advancing Workload-Aware Scheduling kubernetes.io

RSS Hunter • 5月13日

Kubernetes v1.36：Kubernetes 中的 PSI 指标已毕业至 GA 阶段

压力停滞信息（PSI）自 2018 年起已集成到 Linux 内核中，为在故障发生前识别资源饱和提供了高保真信号。与传统利用率指标不同，PSI 量化了 CPU、内存和 I/O 上的停滞任务及丢失时间。随着 Kubernetes v1.36 的发布，现已提供稳定的接口，用于在节点、Pod 和容器级别观察资源争用。PSI 提供停滞时间的累计总量以及移动平均值（10 秒、60 秒、300 秒），以区分瞬时尖峰与持续的资源紧张。SIG Node 对高密度工作负载（80+ 个 Pod）进行了广泛的性能测试，证明了 PSI 在生产环境中的就绪状态。通过切换 KubeletPSI 功能门控来测量的 Kubelet 开销显示，其对资源使用的影响微乎其微。Kubelet 的收集逻辑被证明非常轻量，能够无缝融入标准的维护周期，消耗的 CPU 资源低于 0.1 个核心或节点总容量的 2.5%。关于内核开销，在 Linux 内核中启用 PSI（psi=1 对比 psi=0）在重负载下导致一致的差值，为 0.037 至 0.125 个核心（占节点容量的 0.925% - 3.125%）。作为主要收集器的 kubelet 进程也保持了极低的 CPU 使用率，其尖峰不超过 0.25 个核心（6.25%），且持续时间未超过一秒。v1.36 中的改进包括更智能的指标发布机制：Kubelet 现在会在报告之前通过 cgroup 配置检测操作系统级别的 PSI 支持，从而防止出现误导性的零值指标。要使用 PSI，节点必须运行 Linux 内核 4.20+，使用 cgroup v2，并在操作系统层面启用 PSI（CONFIG_PSI=y，且无 psi=0 启动参数）。PSI 指标在 v1.36 中通常可用，无需功能门控选项。用户可以通过抓取 /metrics/cadvisor 端点或查询 Summary API 来获取数据。PSI 是 Linux 内核功能，在 Windows 节点上不可用。通过控制平面的 API 服务器代理到 Kubelet 的 HTTP API 可从 Summary API 获取实时压力数据，但这属于特权操作。

Kubernetes v1.36: PSI Metrics for Kubernetes Graduates to GA kubernetes.io

RSS Hunter • 5月12日

Kubernetes v1.36：将卷组快照迁移到 GA

Kubernetes v1.36 为卷组快照（volume group snapshots）提供了通用可用（General Availability, GA）支持，该功能此前曾作为 Alpha 和 Beta 阶段的增强特性。此功能利用扩展 API，支持对多个卷同时创建崩溃一致性快照。系统通过标签选择器对 PersistentVolumeClaim 对象进行分组，从而实现将工作负载恢复到一致恢复点。该功能仅支持 CSI 卷驱动，为需要写入顺序一致性的多卷应用程序提供了显著优势。此前，若在不同时间点单独对卷进行快照，可能导致数据不一致，尤其对于多卷应用程序而言。卷组快照消除了手动使应用程序静默的需求，可在无需繁琐、顺序执行单个卷快照的情况下，为组内所有卷提供崩溃一致性。Kubernetes 通过三种自定义 API 类型管理卷组快照：VolumeGroupSnapshot、VolumeGroupSnapshotContent 和 VolumeGroupSnapshotClass。这些 CRD 在 GA 版本中已晋升至 v1，分别允许用户请求卷组快照、跟踪其已配置的资源以及定义其创建策略。GA 版本带来了增强的稳定性、错误修复以及基于先前 Beta 版本反馈改进的 restoreSize 报告。要使用此功能，用户需对其 PersistentVolumeClaim 添加标签以进行分组，然后定义一个 VolumeGroupSnapshot 对象，其选择器匹配这些标签，并指定一个 VolumeGroupSnapshotClass。在恢复过程中，新的 PersistentVolumeClaim 将从属于更大 VolumeGroupSnapshot 的单个 VolumeSnapshot 对象创建。存储供应商可通过在其 CSI 驱动中实现新的组控制器服务和 RPC 来添加支持。

Kubernetes v1.36: Moving Volume Group Snapshots to GA kubernetes.io

RSS Hunter • 5月8日

Kubernetes v1.36：更多驱动、新功能以及 DRA 的新时代

Kubernetes v1.36 中的动态资源分配（DRA）引入了重大进展，将其能力从专用硬件扩展至原生资源（如 CPU 和内存）。对各类硬件（包括网络）的驱动支持正在扩展，使 DRA 成为一种更硬件无关的解决方案。多项关键功能已毕业，增强了调度灵活性和集群利用率。优先级列表功能为设备请求提供回退偏好，提升了资源分配效率。扩展资源支持允许通过传统的扩展资源逐步过渡到 DRA。可划分设备为物理硬件动态划分为更小的逻辑实例提供了原生的 DRA 支持。设备污点使管理员能够更有效地管理硬件，通过防止故障设备被分配或预留特定硬件。设备绑定条件通过延迟 Pod 提交直至外部资源完全就绪，提高了调度可靠性。资源健康状态直接在 Pod 状态中暴露设备健康信息，有助于快速识别和应对硬件故障。新的 Alpha 功能包括针对工作负载的 ResourceClaim 支持，通过跨 PodGroup 管理共享资源来优化大规模 AI/ML。节点可分配资源将 CPU 和内存分配纳入 DRA 范畴，支持细粒度性能调优。DRA 资源可用性可见性为管理员提供实时设备容量信息，以更好地进行规划。确定性设备选择允许驱动通过字典序排序影响调度。容器中的可发现设备元数据为驱动向容器暴露设备属性提供了标准协议。未来路线图侧重于成熟现有功能，提升性能、可扩展性，以及与工作负载感知和拓扑感知调度的集成，并重点强调将用户从 Device Plugin 迁移至 DRA。

Kubernetes v1.36: More Drivers, New Features, and the Next Era of DRA kubernetes.io

RSS Hunter • 5月7日

Kubernetes v1.36：服务器端分片列表与Watch

随着集群规模扩大，Kubernetes 控制器在监控高基数资源时面临扩展挑战。客户端分片虽可行，但无法减少来自 API 服务器的数据量，导致效率低下。Kubernetes v1.36 引入的服务器端分片列表和监听功能（作为 alpha 特性，对应 KEP-5866）解决了这一效率问题。API 服务器根据控制器指定的哈希范围过滤事件，仅向每个副本发送相关数据。控制器使用 Informer 来列出和监听资源，并通过 WithTweakListOptions 集成 shardSelector。分片选择器用于根据对象的 metadata.uid 或 metadata.namespace 过滤资源。API 服务器在列表响应的元数据中返回 shardInfo 字段，以确认分片选择器是否正确应用。若该字段缺失，客户端必须处理完整的未过滤集合，可能不得不回退到客户端过滤。此功能需要启用 ShardedListAndWatch 特性门控。Kubernetes 社区寻求来自控制器作者和运维人员的反馈，尤其是那些管理大型集群的用户。该方法旨在提升控制器在苛刻 Kubernetes 环境中的性能和可扩展性。

Kubernetes v1.36: Server-Side Sharded List and Watch kubernetes.io

RSS Hunter • 5月6日

Kubernetes v1.36：声明式验证升级为通用认证

Kubernetes v1.36 现已普遍可用，引入了原生类型的声明式验证。该功能将验证规则的定义方式从手写 Go 代码转向 IDL 标签，从而提升了 API 的可靠性与可预测性。此前对手写代码的依赖导致了技术债务、不一致性以及不透明的 API 接口。该解决方案利用 validation-gen 代码生成器，通过解析标签自动生成 Go 验证函数。该框架包含多种标记标签，用于处理存在性、约束、集合、联合类型及不可变性。其关键优势在于“环境式棘轮”（ambient ratcheting），允许在不破坏现有对象的前提下即时收紧或放宽验证规则。声明式验证使得 API 审查更加便捷，并与 kube-api-linter 等工具保持一致。该项目计划迁移剩余的遗留代码，并强制要求新 API 采用声明式验证。此举还将释放未来生态系统的诸多益处，例如支持 kubectl 等工具进行客户端验证，以及与 Kubebuilder 等工具的集成。迁移工作正在进行中，并提供了参与 Kubernetes 代码库贡献的机会。文档最后向贡献者致谢，欢迎 Kubernetes 验证的声明式未来。

Kubernetes v1.36: Declarative Validation Graduates to GA kubernetes.io

RSS Hunter • 5月5日

Kubernetes v1.36：无法删除的准入政策

Kubernetes 在 v1.36 版本中引入的基于清单的准入控制（manifest-based admission control），解决了集群引导阶段安全策略执行方面的漏洞。现有的基于 API 的准入控制存在安全隐患：策略是 API 对象，可以被删除，从而形成安全窗口期。这一新功能允许将准入 Webhook 和基于 CEL 的策略定义为文件，由 API 服务器在启动时加载。这确保了在响应任何请求之前策略即已生效，从而防止未经授权的修改。该功能在 AdmissionConfiguration 文件中通过 staticManifestsDir 字段指定包含策略 YAML 文件的目录。这些文件的名称必须以 .static.k8s.io 结尾，以将其与基于 API 的配置区分开来。该功能可保护准入配置本身免受删除或修改。对清单文件的更改会在运行时自动更新。API 服务器在启动期间执行严格的验证，并以原子方式处理运行时的更新。要实施此功能，需要启用 ManifestBasedAdmissionControlConfig 功能门控。

Kubernetes v1.36: Admission Policies That Can't Be Deleted kubernetes.io

RSS Hunter • 5月4日

Kubernetes v1.36：Pod 级资源管理器（Alpha）

Kubernetes v1.36 引入了作为 Alpha 特性的 Pod 级资源管理器（Pod-Level Resource Managers），以增强对性能敏感型工作负载的资源管理。该特性将 kubelet 的拓扑管理器（Topology Manager）、CPU 管理器和内存管理器的功能扩展至以 Pod 为中心的资源分配模型，超越了以往仅针对容器的规格定义。此举解决了为主应用容器提供独占且与 NUMA 对齐的资源，同时高效支持轻量级边车容器（sidecars）的挑战。此前，要实现可预测的性能，通常需为所有容器分配独占资源，这对边车容器而言是一种浪费；反之，若不这样做，则会牺牲 Pod 的 Guaranteed QoS。Pod 级资源管理器支持混合分配模式，使高性能工作负载能够在不浪费资源的前提下实现 NUMA 对齐。例如，一个对延迟敏感的数据库 Pod 可使其主容器获得独占的 CPU 和内存，而边车容器则共享一个独立的 Pod 共享池（pod shared pool），该池与其他节点资源隔离。另一个应用场景涉及机器学习工作负载，其中训练容器获得独占的 NUMA 对齐资源，而服务网格边车容器则在节点范围的共享池中运行。CPU 隔离通过为独占容器禁用 CFS 配额执行，并在共享池容器层面强制执行来实现。启用该功能需要特定的 kubelet 功能门控（feature gates）、Topology Manager 策略以及静态的 CPU 和内存管理器配置。新的 kubelet 指标提供了对资源分配和容器分配的可见性。该功能目前处于 Alpha 阶段，存在已知限制和注意事项，欢迎用户通过 Kubernetes 社区渠道提供反馈。

Kubernetes v1.36: Pod-Level Resource Managers (Alpha) kubernetes.io

RSS Hunter • 5月1日

Kubernetes v1.36：Pod 级别资源的原地垂直扩缩容功能晋升为 Beta 版本

Kubernetes v1.36 引入了 Pod 级别资源的原地垂直扩展（In-Place Pod-Level Resources Vertical Scaling），现已进入 Beta 阶段并默认启用。该功能允许用户动态调整运行中 Pod 的聚合资源限制。对于具有共享资源且未设置容器特定限制的 Pod，此功能尤为有用。Kubelet 会根据每个容器的 resizePolicy 确定更新方式，即在原地更新或重启之间进行选择。当发生调整大小时，Kubelet 首先检查节点是否有足够的资源。随后，它会按顺序执行 cgroup 更新，以防止资源超配：先扩展 Pod 级别的 cgroup，再扩大各个容器的 cgroup。Pod 条件（如 PodResizeInProgress）用于跟踪调整进度和状态。该功能需要 cgroup v2、CRI 支持、特定的功能门控以及基于 Linux 的节点。下一步是将此功能与垂直 Pod 自动伸缩器（Vertical Pod Autoscaler, VPA）集成。鼓励用户测试此功能并通过社区渠道提供反馈。

Kubernetes v1.36: In-Place Vertical Scaling for Pod-Level Resources Graduates to Beta kubernetes.io

RSS Hunter • 4月30日