RSS Kubernetes 博客 - TheNote.app

RSS Kubernetes 博客
关注

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

Kubernetes Blog kubernetes.io

RSS kubernetes.io

RSS Hunter • 2024年8月23日

笔记线程

发布 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日

Kubernetes v1.36：利用内存 QoS 提供分层内存保护

Kubernetes v1.36 引入了对内存 QoS 功能的更新，该功能采用 cgroup v2 以实现更优的容器内存管理。v1.36 的关键更新包括按需启用内存预留，并根据 Pod QoS 类别提供分层保护。Guaranteed Pod 现在获得硬性内存保护（memory.min），而 Burstable Pod 获得软性保护（memory.low）。BestEffort Pod 仍保持完全可回收且无特殊保护。新的 memoryReservationPolicy 允许分别控制节流和预留。系统提供可观测性指标，用于监控节点上 memory.min 和 memory.low 的使用情况。内核版本检查会在内核早于 5.9 时向用户发出警告，以避免潜在的活锁问题。该实现利用了 memory.max、memory.min、memory.low 和 memory.high 等 cgroup v2 接口。节点内存分配由 kubelet 管理，确保每个 Pod 及各类 QoS 获得适当的保护。该功能可通过 kubelet 配置启用，其中 TieredReservation 为关键设置。推荐的前置条件为：Kubernetes v1.36 或更高版本、支持 cgroup v2 的 Linux 系统以及 5.9 或更高版本的内核。用户可参与 SIG Node 社区以提供反馈和贡献。

Kubernetes v1.36: Tiered Memory Protection with Memory QoS kubernetes.io

RSS Hunter • 4月29日

Kubernetes v1.36：控制器的陈旧性缓解与可观测性

Kubernetes 控制器可能因数据陈旧而出现问题，导致基于过时的缓存数据执行错误或延迟的操作。数据陈旧源于控制器的本地缓存与集群的实际状态不同步。Kubernetes v1.36 引入了多项功能以缓解数据陈旧问题并优化控制器行为。这些改进包括在 client-go 中实现原子性的 FIFO 处理，从而提升队列的一致性。kube-controller-manager 已在 DaemonSet 和 ReplicaSet 等关键控制器中集成了 client-go 的这些改进。这些控制器现在会在执行操作前检查缓存资源的版本，避免对陈旧数据采取行动。Informer 作者可以使用 ConsistencyStore 来跟踪和管理资源版本，从而在其控制器中缓解数据陈旧问题。ConsistencyStore 提供了记录写入、检查缓存就绪状态以及清除陈旧对象条目等功能。此外，Kubernetes v1.36 还新增了用于监控控制器健康状态的指标，其中包括因数据陈旧而跳过的同步次数。client-go 现在也会发出指标，以暴露共享 Informer 的最新资源版本。Kubernetes 团队计划将这些缓解数据陈旧的功能扩展至更多控制器，并将其集成到 controller-runtime 中。团队欢迎用户反馈，并期待未来的持续发展。

Kubernetes v1.36: Staleness Mitigation and Observability for Controllers kubernetes.io

RSS Hunter • 4月28日

Kubernetes v1.36：为挂起的作业启用可变的 Pod 资源（beta）

Kubernetes v1.36 将 Pod 模板中挂起（suspended）Job 的容器资源请求和限制修改能力提升至 beta 阶段。该功能在 v1.35 中作为 alpha 版本引入，允许队列控制器和管理员在 Job 执行前、处于挂起状态时调整其资源规格（如 CPU、内存和 GPU）。此前，资源需求一旦设定即不可更改，若要修改则必须删除并重新创建 Job，从而导致宝贵元数据的丢失。这一新功能解决了 Job 创建时资源需求不明确或集群容量波动的场景。例如，队列控制器现在可以将机器学习 Job 的 GPU 请求从 4 台减少至 2 台，若集群中仅有 2 台可用。Kubernetes API 服务器针对挂起 Job 的特定资源字段放宽了不可变性约束，前提是 Job 的 spec.suspend 必须为 true；若该 Job 此前正在运行，则所有活动 Pod 必须已终止。在 beta 版本中，MutablePodResourcesForSuspendedJobs 功能门控在 v1.36 中默认启用。用户可通过创建挂起 Job、编辑其资源并随后恢复执行来测试此功能。对于正在运行的挂起 Job，在修改资源之前，务必确保所有活动 Pod 均已终止，以避免出现不一致状态。

Kubernetes v1.36: Mutable Pod Resources for Suspended Jobs (beta) kubernetes.io

RSS Hunter • 4月27日

Kubernetes v1.36：细粒度 Kubelet API 授权正式晋升为 GA 版本

细粒度 kubelet API 授权已在 Kubernetes v1.36 中达到通用可用（GA）状态。该功能取代了访问 kubelet HTTPS API 时过于宽泛的 nodes/proxy 权限，从而提升了安全性。此举旨在解决向监控工具授予过多权限所带来的安全风险。此前，nodes/proxy 权限常被使用，其允许执行命令。细粒度授权将特定的 kubelet API 路径映射到更专用的子资源。系统执行双重授权检查以保障向后兼容性：拥有 nodes/proxy 权限的现有工作负载将继续按原方式运行。内置的 system:kubelet-api-admin ClusterRole 将自动更新。监控工具现在可以利用如 nodes/metrics 等特定资源，从而增强最小权限访问。大多数集群升级无需进行更改。要验证该功能，可运行一个通过 curl 检查功能标志的 Pod。后续步骤包括生态系统进一步适配；此外，nodes/proxy 权限可能会被弃用。

Kubernetes v1.36: Fine-Grained Kubelet API Authorization Graduates to GA kubernetes.io

RSS Hunter • 4月24日

Kubernetes v1.36：Kubernetes 中的用户命名空间现已正式通用（GA）。

Kubernetes v1.36 正式推出了用户命名空间（User Namespaces）的通用可用性支持。用户命名空间是 Linux 专属的一项功能，可为容器化工作负载提供增强的安全隔离。这一备受期待的里程碑使 Kubernetes 应用能够实现“无 root"级别的安全隔离。关键能力在于：通过将 hostUsers 设置为 false，可以在用户命名空间内运行具有特权的负载，同时将其限制在该命名空间中。这使得某些能力（如 CAP_NET_ADMIN）被限制在用户命名空间内，仅赋予对本地容器资源的行政管理权限。此前，容器内的进程 root 同时也是宿主机上的 root，在容器逃逸场景下构成重大安全风险。实现该功能的关键是 ID 映射挂载（ID-mapped mounts），它能在挂载时透明地重新映射 UID 和 GID，而无需更改磁盘所有权。此举解决了早期开发阶段因卷所有权更新而导致的性能问题。实施用户命名空间非常简单：只需在 Pod 规范中将 hostUsers 设为 false，无需修改容器镜像或进行复杂的配置。该功能复用了 Alpha 阶段引入的相同接口。这一进展代表了 Kubernetes SIG Node、容器运行时与 Linux 内核之间多年跨项目协作的成果。

Kubernetes v1.36: User Namespaces in Kubernetes are finally GA kubernetes.io

RSS Hunter • 4月23日

SELinux 卷标变更现已进入通用可用（GA）阶段（并可能在 v1.37 版本中产生相应影响）

Kubernetes v1.37 计划默认启用 SELinuxMount 功能门控，以提升卷的挂载速度。此变更可能会破坏依赖旧版递归重新标记方法的现有应用，尤其是那些在特权与非特权 Pod 之间共享卷的应用。文章建议对 v1.36 集群进行审计，以识别并解决与 SELinux 相关的潜在冲突。当启用 SELinux 时，kubelet 会为卷应用 SELinux 标签以实现访问控制；新方法通过挂载选项实现更快的重新标记。为此引入了 SELinuxChangePolicy 字段和 Recursive 选项，允许用户退出该性能加速机制。若满足相应条件，kubelet 现在可直接以适当的 SELinux 标签挂载卷，无需执行递归重新标记。selinux-warning-controller 可识别可能因新配置而失效的冲突 Pod，并发出事件和指标。集群管理员可利用这些指标检测潜在问题并做出相应调整。推荐的升级路径包括：启用控制器、解决冲突，随后在监控错误的同时升级到默认启用 SELinuxMount 的版本。管理员可采用多种方法针对特定 Pod 强制退出该机制。新行为虽能提升性能，但会改变不同 Pod 间卷的共享方式。

SELinux Volume Label Changes goes GA (and likely implications in v1.37) kubernetes.io

RSS Hunter • 4月22日

Kubernetes v1.36：哈尔 (Haru)

Kubernetes v1.36 已发布，包含 70 项增强功能，其中 18 项晋升为稳定版，25 项进入 Beta 阶段。本次发布的主题为"Haru"，象征春天、晴朗的天空与远方的地平线，其标志灵感源自葛饰北斋的《红富士》。此次发布强调社区协作，众多个人与团队为成功做出了贡献。关键稳定功能包括：细粒度的 kubelet API 授权，以提升最小权限访问控制；已分配设备的资源健康状态进入 Beta 阶段，提供统一的硬件故障报告。Alpha 阶段引入了工作负载感知调度，将相关 Pod 视为单一逻辑实体，从而优化资源管理。卷组快照现已稳定，支持跨多个 PersistentVolumeClaim 实现崩溃一致性快照。可变的 CSI 节点可分配限制也达到稳定状态，允许动态更新节点卷容量。外部 ServiceAccount 令牌签名功能现已稳定，可将令牌签名卸载至外部系统。动态资源分配（DRA）的管理员访问和优先级列表现已稳定，为资源管理提供安全框架。声明式变异准入策略已稳定，为资源变异提供原生的 Webhook 替代方案。使用 validation-gen 对 Kubernetes 原生类型进行声明式验证也已晋升为稳定版，简化了自定义资源开发。此外，移除 Kubernetes API 类型对 gogo protobuf 的依赖，标志着在安全性和可维护性方面迈出了重要一步。

Kubernetes v1.36: ハル (Haru) kubernetes.io

RSS Hunter • 4月22日

Gateway API v1.5：将功能迁移至稳定版

Gateway API v1.5 于 2026 年 3 月 14 日发布，标志着该项目迄今为止最重要的版本。该版本的重点是将多个此前处于实验阶段的特性提升至稳定通道。主要提升的特性包括：ListenerSet、TLSRoute、HTTPRoute 的 CORS 过滤器、客户端证书验证、网关 TLS 源端证书选择以及 ReferenceGrant。该项目已采用发布列车模型，与 Kubernetes SIG Release 同步，以实现更可预测的更新。新流程设立了专门的发布经理（Release Manager）和发布影子（Release Shadow）角色。ListenerSet 允许独立定义监听器并将其合并到网关上，从而提升可扩展性和多租户支持能力。TLSRoute 支持基于 SNI 对 TLS 连接进行路由，同时兼容透传（Passthrough）和终止（Terminate）两种模式。HTTPRoute 的 CORS 过滤器提供对跨域资源共享（CORS）设置的细粒度控制。客户端证书验证（即双向 TLS，mTLS）允许网关通过对照受信任的证书颁发机构（CA）验证客户端证书来确认客户端身份。该功能可在全局或按端口级别进行配置，以增强安全性。

Gateway API v1.5: Moving features to Stable kubernetes.io

RSS Hunter • 4月21日

Kubernetes 的 PSI 指标升级到 Beta 版本

Kubernetes v1.34 已将压力停滞信息 (PSI) 指标提升至 Beta 阶段，为监控不断增长的集群中的节点健康状况提供了关键工具。PSI 是一个 Linux 内核特性，它通过测量因资源争用而导致的任务停滞时间来量化资源压力，而不仅仅是利用率。它提供了针对 CPU、内存和 I/O 的指标，分为“部分”压力（至少一个任务停滞）或“完全”压力（所有非空闲任务停滞）。这些指标以 10 秒、1 分钟和 5 分钟的滚动窗口提供。KubeletPSI 特性门控允许 kubelet 通过 Summary API 和 /metrics/cadvisor Prometheus 端点收集和公开 PSI 指标。现在可以访问新的 Prometheus 指标，例如 container_pressure_cpu_stalled_seconds_total。这些指标有助于识别内存泄漏、优化资源请求和触发自动伸缩。要启用 PSI，节点必须运行 Linux 内核 4.20+ 并使用 cgroup v2，并且必须启用 KubeletPSI 特性门控。PSI 指标是 Linux 专属的，在 Windows 节点上不可用。此 Beta 特性正在积极开发中，鼓励反馈。

PSI Metrics for Kubernetes Graduates to Beta kubernetes.io

RSS Hunter • 2025年9月4日

Kubernetes v1.34：用于镜像拉取的 Service Account Token 集成升级至 Beta 版

Kubernetes v1.34 将 Kubelet 凭据提供程序的 Service Account Token 集成提升至 Beta 阶段。此增强功能使凭据提供程序能够使用特定于工作负载的服务账户令牌来获取注册表凭据，从而取代了长期存在的镜像拉取 Secret。Beta 版发布引入了凭据提供程序配置的强制性 cacheType 字段。有两种可用的缓存策略：Token，用于与令牌生命周期绑定的凭据；ServiceAccount，用于对使用相同服务账户的所有 Pod 都有效的凭据。Beta 版本还提供了增强的安全隔离，确保 Pod 只能访问使用其授权 ServiceAccounts 拉取的镜像。该系统会跟踪 ServiceAccount 身份，并在 Pod 使用缓存镜像时进行验证。管理员可以通过删除并重新创建 ServiceAccount 来撤销镜像访问权限。此功能建立在服务账户节点受众限制的基础上，以实现安全的令牌请求。要使用 Beta 功能，请确保 Kubernetes 版本为 v1.34 或更高，并更新凭据提供程序。从 Alpha 迁移需要添加 cacheType 字段并审查缓存策略。Kubernetes 社区正在就此功能征求反馈，特别是来自凭据提供程序实现者的反馈。计划在未来的版本中进一步开发和收集反馈。

Kubernetes v1.34: Service Account Token Integration for Image Pulls Graduates to Beta kubernetes.io

RSS Hunter • 2025年9月3日

Kubernetes v1.34：推出 CPU Manager 的静态策略选项以实现 Uncore 缓存对齐

Kubernetes v1.34 引入了 CPU Manager 静态策略的 Beta 版功能 prefer-align-cpus-by-uncorecache。此选项可优化在具有分裂的 uncore 缓存架构的处理器上的工作负载。Uncore 缓存，也称为最后一级缓存 (LLC)，在 CPU 核心之间共享。现代处理器使用分裂的 uncore 缓存，通过将缓存划分为 CPU 组来降低延迟。此功能允许 Kubernetes 将容器 CPU 放置在同一个 uncore 缓存中，从而最大限度地减少延迟和争用。这种缓存感知的放置可以提高敏感应用程序的吞吐量。默认情况下，Kubernetes 使用打包方法，这可能导致“吵闹的邻居”问题和跨缓存延迟。启用此功能可以将容器隔离到单个缓存中，从而解决争用问题。用例包括 vRAN 等电信应用程序，但收益取决于工作负载，特别是对于内存带宽受限的应用程序。要启用，请将 CPU Manager 策略设置为 static 并启用 CPUManagerPolicyBetaOptions。配置涉及修改 kubelet 配置文件以设置策略和选项。该功能通过模拟套接字对齐来处理单片 uncore 缓存处理器。

Kubernetes v1.34: Introducing CPU Manager Static Policy Option for Uncore Cache Alignment kubernetes.io

RSS Hunter • 2025年9月2日

Kubernetes v1.34：DRA 已毕业到 GA

Kubernetes 1.34 带来了对动态资源分配 (DRA) 的重大增强。DRA 的核心功能已毕业到通用可用性 (GA)，这意味着它稳定且可供长期采用。DRA 能够灵活管理 GPU 等专用硬件，允许工作负载指定设备需求，并让调度器分配实际设备。随着 DRA 现在达到 GA 状态，它以及之前处于 Beta 阶段的功能都将默认启用。一些功能已进入 Beta 阶段，包括管理员访问标签，用于限制授权用户滥用特定设备功能。优先级列表允许工作负载指定多个可接受的设备替代方案，以实现更灵活的调度。Kubelet API 已更新，用于报告 DRA 分配的 Pod 资源，从而改进节点监控。新的 Alpha 功能预示着 DRA 的未来。扩展资源映射支持将 DRA 管理的资源作为扩展资源进行广告，从而简化了现有工作负载的消耗。可消耗容量引入了灵活的设备共享，允许多个不相关的 Pod 根据管理员定义的策略共享单个物理设备。绑定条件通过延迟 Pod 绑定直到外部资源确认就绪来增强调度可靠性。最后，DRA 的资源健康状态通过 Pod 状态暴露设备健康状况，从而提高了可观测性。团队计划在未来的版本中将更多 Alpha 和 Beta 功能推向 GA。

Kubernetes v1.34: DRA has graduated to GA kubernetes.io

RSS Hunter • 2025年9月1日

Kubernetes v1.34：对容器重启进行更精细化的控制

Kubernetes 1.34 引入了一个名为容器重启策略和规则的 Alpha 功能。该功能允许在 Pod 中对容器重启进行个性化控制，覆盖 Pod 的全局重启策略。此外，它还启用了基于容器退出代码的条件重启。以前，Pod 中的所有容器共享单个重启策略。这限制了场景，如拥有仅运行一次的 init 容器，而主应用程序容器总是重启。该新功能，通过 ContainerRestartRules Alpha 功能门启用，解决了这个问题，允许每个容器拥有自己的重启策略和规则。使用场景包括基于特定退出代码的就地重启、try-once init 容器和具有不同重启需求的多容器 Pod。要使用该功能，必须启用 ContainerRestartRules 功能门。示例演示如何根据特定退出代码配置重启、实现 try-once init 容器和将不同重启策略分配给多个容器。该 Alpha 功能欢迎社区反馈，由 SIG Node 开发。未来计划包括对整个 Pod 的重启支持。

Kubernetes v1.34: Finer-Grained Control Over Container Restarts kubernetes.io

RSS Hunter • 2025年8月29日

Kubernetes v1.34：kubectl 1.34 中已提供用户偏好设置 (kuberc) 以供测试

Kubernetes v1.34 的 Kubectl 用户偏好设置现已达到 Beta 版，提供了自定义选项。此功能允许用户为 kubectl 命令定义自定义设置。用户偏好设置文件通常命名为 kuberc，位于默认的 kubeconfig 目录 $HOME/.kube 中。该文件使用 apiVersion 和 kind 结构，类似于 Kubernetes manifests。defaults 部分允许为 kubectl 命令选项设置默认值，例如始终使用交互式删除。这些默认值可以通过在命令执行期间显式提供不同的选项来覆盖。另一个推荐的默认设置是为 kubectl apply 命令启用 Server-Side Apply。aliases 部分允许用户为常用命令创建快捷方式，节省时间和精力。可以定义别名来映射到具有预定义参数和选项的特定 kubectl 命令。该机制支持将参数添加到基础 kubectl 命令的前面或后面。可以通过增加详细程度来访问此功能的调试信息，例如使用 -v=5。随着该功能的成熟，强烈鼓励用户提供反馈，用户可以通过 Slack、GitHub issue 或社区会议来贡献。

Kubernetes v1.34: User preferences (kuberc) are available for testing in kubectl 1.34 kubernetes.io

RSS Hunter • 2025年8月28日

Kubernetes v1.34：风与意志 (O' WaW)

Kubernetes v1.34 版本，主题为“风与意志”，引入了 58 项增强功能，其中 23 项达到稳定状态。设备管理的动态资源分配（DRA）现在普遍可用，允许更灵活的设备选择和配置。kubelet 镜像凭证提供商的Projected ServiceAccount 令牌提供了增强的安全性，使用短暂的、特定于工作负载的令牌。kubectl 引入了新的输出格式 KYAML（alpha 版），旨在提供更安全、更少歧义的 YAML 格式。作业控制器现在具有延迟替换 Pod 创建功能，以防止同时执行和资源争夺。卷扩展失败的恢复现在稳定，允许用户取消和重试卷扩展。VolumeAttributesClass 也稳定，提供了一个 Kubernetes 本地 API 用于修改卷参数。结构化的身份验证配置现在稳定，改善了 API 服务器客户端身份验证的可管理性和审计性。基于选择器的细粒度授权增强了安全性，启用了最小权限规则。匿名请求现在可以限制到特定端点，提高安全性而不破坏外部探测。更高效的重新排队机制减少了不必要的重试，提高了调度吞吐量。有序的命名空间删除确保了确定性和安全的资源删除，减少了安全风险。流式列表响应提高了可扩展性，减少了 API 服务器的内存压力。弹性观察缓存初始化增强了控制平面的鲁棒性，使观察缓存初始化过程更具抵抗力。

Kubernetes v1.34: Of Wind & Will (O' WaW) kubernetes.io

RSS Hunter • 2025年8月27日

Kubernetes Linux Swap 调优：深度解析

Kubernetes 节点交换功能，即将稳定，允许 Linux 节点使用交换空间以获取额外的虚拟内存。该功能旨在提高资源利用率并减少物理 RAM 耗尽时的内存不足（OOM）杀死事件。然而，其有效性取决于调整特定的 Linux 内核参数，如 vm.swappiness、vm.min_free_kbytes 和 vm.watermark_scale_factor。vm.swappiness 参数控制内核在交换匿名内存和回收文件支持内存之间的偏好。vm.min_free_kbytes 作为安全缓冲区，影响激进的页面回收何时开始。vm.watermark_scale_factor 调整内存自由水印之间的间隙，影响交换窗口。测试表明，默认内核参数可能导致 OOM 杀死和节点重启在内存压力下。增加 vm.min_free_kbytes 和 vm.watermark_scale_factor 证明是防止过早驱逐和 OOM 杀死的关键，提供了内核更多的时间来交换。较高的 swappiness 可能导致显著的 I/O 等待，而较低的 swappiness 优先考虑文件缓存的释放。正确调整这些参数，连同 Kubelet 的驱逐阈值，创建了一个平衡的内存压力管理策略。风险包括由于慢速交换访问导致的性能下降和掩盖内存泄露。

Tuning Linux Swap for Kubernetes: A Deep Dive kubernetes.io

RSS Hunter • 2025年8月19日

介绍kube-scheduler模拟器

Kubernetes 调度器是一个关键组件，确定 Pod 将在哪个节点上运行，了解其行为可能很具挑战性，因为它考虑了多种因素。kube-scheduler-simulator 是一个工具，允许用户 CLOSELY 考察调度器的行为和决策，对于普通用户和扩展调度器的专家用户都非常有用。该模拟器最初是作为 Google Summer of Code 2021 项目开发的，自那以来已经收到了许多贡献。它使用户能够测试他们的调度约束、调度器配置和自定义插件，同时检查每个详细的调度决策。模拟器还允许用户创建一个模拟集群环境，在其中他们可以使用与生产集群相同的资源来测试调度器，而不会影响实际工作负载。模拟器的核心功能是其能够暴露调度器的内部决策，并提供了一个 Web 前端来可视化调度结果。用户可以将自定义插件或扩展器集成到可调试的调度器中，并可视化结果。模拟器也可以独立运行，对于想要测试插件或在真实集群中检查自定义调度器的开发者非常有用。模拟器的导入功能允许用户在生产环境中模拟部署新版本的调度器，而不会影响实时工作负载。模拟器有多种用例，包括检查调度约束、评估调度器配置的更改和测试自定义调度器插件或扩展器。要开始使用模拟器，用户只需要在机器上安装 Docker，然后可以访问模拟器的 Web UI at http://localhost:3000。

Introducing kube-scheduler-simulator kubernetes.io

RSS Hunter • 2025年4月7日