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

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

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 邮件列表积极提交。

本文原日期标注有误，现更正为 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。

混合版本代理（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 服务中的 `.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.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 版本中构建高级工作负载调度能力奠定了坚实基础。

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