🆕 专题一 产品新功能/新版本
1. Kubernetes 1.37 Garhwal 发布
Kubernetes 1.37: Deep dive into new alpha features
发布主题和 Logo
Kubernetes v1.37 的主题是加瓦尔（Garhwal，发音为 gaṛhvāl），位于印度北阿坎德兰邦的一个喜马拉雅地区。加瓦尔喜马拉雅山脉的雪峰、雪松森林、梯田、河流与小溪，以及山路，共同塑造了这一地区的风貌。这些元素共同构成了一个紧密相连的社区，其中每个层面、每条路径、每项贡献都相互连接在一起。
关键更新
共有 67 项 enhancements：
- 16 项升为 Stable
- 23 项升为 Beta
- 27 项进入 Alpha
- 1 项弃用/移除
Stable：watchcache 初始化过程具有弹性
API Server 在启动或恢复 watch cache 时，不再把大量 list/watch 请求直接压到 etcd 上；无法安全处理的请求会返回 429，客户端应支持 Retry-After 和指数退避。etcd RangeStream 进入 Beta，用流式方式读取大列表，降低大集群下的内存峰值。
Stable：KYAML
is now Stable.
KYAML 是一种更简洁、更明确的 YAML 格式，专为 Kubernetes 环境设计，并非其替代品。所有的 KYAML 文件都符合 YAML 的标准，因此可以作为任何版本 kubectl 的输入格式。无需将规范文件转换为 KYAML 格式即可进行解析。您现有的清单、工具和管道系统无需做任何改动。KYAML 作为 Alpha 功能在 v1.34 版本中被引入，并在 v1.35 版本升级为 Beta 版本。在 v1.37 版本中，KYAML 已完全通过一致性测试，正式成为稳定版本，而 kubectl get -o kyaml 也已成为稳定版本。
Stable：metrics.k8s.io API
该 API 提供了一种标准的方式来获取 Pod 和节点的 CPU 和内存使用情况，这为 Kubernetes 中的许多功能提供了支持，例如水平 Pod 自动扩展器（HPA），以及像 kubectl top 这样的命令。
随着 Kubernetes 项目的推进，我们遵循了避免永久使用测试版 API 的目标。现在 v1 已经存在了，未来的 Kubernetes 版本将会逐步迁移到这个新版本；而 v1beta1 仍然可以在整个过渡期间被使用，这符合 API 淘汰政策的规定。因此，您可以继续使用稳定的 API，而不会破坏现有的工作流程。
Stable：SELinuxMount 和 SELinuxChangePolicy
在 Kubernetes v1.37 版本中， SELinuxMount 和 SELinuxChangePolicy 标志已处于稳定状态，并且默认启用。这意味着卷会在 -o context=<label> （即默认的 MountOption）参数下被挂载到集群中，而不是进行递归重命名操作。不过，这种情况只会在卷的 CSI 驱动程序通过 .spec.seLinuxMount: true 参数选择 CSIDriver 对象时才会发生。
一个挂载点只能承载一种 SELinux 上下文。因此，那些具有不同 SELinux 标签、且在同一节点上共享同一卷资源的 Pod，由于之前可以通过递归重新标记来共存，但现在可能会无法启动。为了保留旧的行为，建议为这些 Pod 设置 .spec.seLinuxChangePolicy 为 Recursive 。
Stable：DRA 的相关功能
- 资源占用状态，可能包含标准化的网络接口数据：驱动程序可以针对每个被分配到的设备，报告与设备相关的状态数据。这一改进使得更容易了解设备的配置情况，解决故障问题，并让设备能够与其他服务协同工作。
- 通过 DRA 驱动来处理扩展的资源请求：DRA 驱动程序能够直接处理通过传统扩展资源机制提出的请求，例如 Pod 规范中的 abc.example/gpu: 3 指令，而无需使用额外的设备插件。通过这种机制，可以直接为某个设备类分配一个较长的资源名称。接着，那些需要该资源的容器可以无需在工作负载中定义资源声明，而直接通过 DRA 来分配相应的设备。
- 设备 taints 与 tolerations：默认情况下，任何可用的设备都可以被考虑用于调度任务。这一改进使得对设备调度的控制更加灵活，因为 DRA 驱动程序可以标记某些设备为“污点设备”，从而防止这些设备被选中用于工作负载。此外，集群管理员还可以创建“设备污点规则”来根据特定标准对设备进行污点处理，例如仅选择由特定驱动程序管理的设备。
- 标准的 numa 节点设备属性：定义了一个新的标准属性 NUMA 节点设备属性。它将 resource.kubernetes.io/numaNode 作为 NUMA 节点信息的共享属性名称，从而使得由不同 DRA 驱动程序管理的设备能够基于同一个 NUMA 节点进行比较。这样避免了每个驱动程序都需要定义自己的属性名称，同时提供了一种统一的方式来识别各个设备中的 NUMA 布局。
Stable：节点相关功能
该功能为节点引入了一个新的 .status.declaredFeatures 字段，用于标识系统经历从 Alpha 阶段到 Beta 阶段，再到稳定阶段的演变过程。控制平面可以利用这个字段来确保系统在运行着不同版本节点的集群中也能保持正确的行为。
一旦这些特性在 Stable 版本中得以应用，且控制平面能够确保在整个支持版本范围内，所有节点都能支持这些特性，那么这些节点就会停止上报相关信息了。
kubelet 在启动时会根据其特征门和节点的静态配置来决定其特性。因此，任何更改都需要通过 kubelet 来重新启动系统才能实现。
Stable：存储版本迁移工具
StorageVersionMigration 接口已升级为稳定版本，并默认启用。该接口可以帮助在 API 升级后，将现有资源从旧版本存储迁移到新版本存储。例如，当首选存储版本从 v1beta1 升级到 v1 时，就可以使用此接口进行资源迁移。此外，当静态加密设置发生变化时，也可以使用该接口来重新整理现有数据，使得旧的数据能够使用新的加密设置进行存储。
要开始对存储版本进行迁移，用户需要创建一个名为 StorageVersionMigration 的对象。Kubernetes 控制平面内置的 StorageVersionMigrator 控制器会监控这些对象，并自动将现有资源迁移到该 API 的默认存储版本。由于 StorageVersionMigration 是标准的 Kubernetes API，因此通过 CRD 可以仅在升级 CRD 时触发迁移操作，而无需单独管理迁移过程。
Stable：Pod 证书和集群信任包
要使用此功能，开发者或管理员需要选择一个签名者名称，并部署一个签名者控制器。该控制器会监控 PodCertificateRequest 对象，为符合条件的 Pod 颁发并更新证书，同时维护着包含用于验证这些证书的信任锚点的 ClusterTrustBundle 对象。然后，工作负载可以通过使用所选签名者名称定义 podCertificate 投影卷来加入此身份识别机制。工作负载还可以挂载 ClusterTrustBundle 投影卷以加载信任锚点信息。
Beta：HorizontalPodAutoscaler 已缩放到零
对于使用对象级或外部指标进行监控的工作负载，这一功能允许 HorizontalPodAutoscaler 在空闲时减少 Pod 的数量，而在需求恢复时再恢复这些 Pod。这样做可以有效降低队列处理程序、批处理作业以及 GPU 工作负载的运营成本。使用 spec.minReplicas: 0 标记可以针对特定工作负载启用此功能。
Beta：基于 manifestion 的接入控制配置
可以通过磁盘上的清单文件来加载准入钩子和基于 CEL 的策略，而无需仅存在于 Kubernetes API 中。通过这种方式加载的策略在 API 服务器启动时会立即生效，即使在 etcd 字段不可用时也能继续运行，并且能够保护基于 API 的准入资源免受修改。
Alpha：节点级别的检查点和恢复机制
Kubernetes v1.37 版本新增了对 Pod 级别检查点和恢复功能的 Alpha 支持。同时，它还扩展了 CRI 功能，通过 CheckpointPod 和 RestorePod 接口支持 RPC 通信。这意味着 kubelet 以及兼容的容器运行时能够创建 Pod 级别的检查点，并从中恢复 Pod 的状态。要使用这一功能，你的容器运行时也必须实现这些新的 RPC 接口。
过度到 Beta 阶段的相关功能
- 新的 Recreate 策略适用于 StatefulSet 的部署过程
- DRA 的相关功能
- 可分配的节点资源请求
- 派生属性
- 设备兼容性组
- 用于原地调整 Pod 大小的调度器优先级抢占机制
- 动态调整基于内存的卷的大小
- 针对节点提供的生命周期管理服务
其他值得注意的变更
- maxUnavailable 对于 StatefulSet 类型的工作负载默认是可用
- 提升了 nftables 的性能表现
- 在 client-go 中处理上下文以及进行上下文相关的日志记录
弃用与移除
- 弃用 kube-dns
- 计划取消 kube-proxy 对 ipvs 模式的支持
- kubectl ： kubectl run --filename/-f 将会被弃用
- kubelet ：静态 Pod 不再能引用 Secret 或 ConfigMap
- 未来将不再支持 cgroup v1 版本的功能
2. Gateway API v1.6 发布：TCPRoute 和 UDPRoute 现已成为标准功能
Gateway API v1.6: TCPRoute and UDPRoute Graduate to Standard
Gateway API v1.6.0 版本于今年 6 月 30 日正式发布！
以下是新功能概述。
TCPRoute 和 UDPRoute 已正式成为标准功能
到目前为止，Gateway API 仅提供了适用于 HTTP 和 TLS 流量的稳定路由机制。那些通过 TCP 或 UDP 传输数据的负载——比如数据库、DNS、VoIP、游戏、物联网遥测等场景——并没有一种可移植的方式能够连接到 Gateway 上。因此，用户要么继续使用传统的 Kubernetes 服务，要么不得不使用特定于某种实现的标准 API，因为这些标准 API 无法在不同的 Gateway 控制器之间切换使用。
TCPRoute 和 UDPRoute 填补了这一空白：它们仅通过协议和端口来路由流量，无需了解层 7 的详细信息。随着这次发布，这两种接口已经从实验版升级为标准版，并转向了 v1 版本。而 v1alpha2 版本则已在 v1.6 版本中被弃用，未来将会被移除。
XBackend 已到达实验版本阶段
Gateway API v1.6 引入了新的 XBackend 资源，这是一种用于 Gateway API 中服务类对象（以及其他后端类型）的通用装饰器。“Service”资源是一种非常出色、稳定且灵活的对象，但随之而来的也有一些代价：这种灵活性会导致许多复杂的情况，需要 Gateway API 来处理；而稳定性则使得无法为 Service 添加新的功能。XBackend 资源是在上游 EndpointSelector KEP 的设想基础上开发的。它引入了一个专为网关设计的原生对象，该对象仍然针对后端应用程序；同时，社区也可以扩展该资源，以处理那些通过服务难以处理或存在风险的情况。这种支持对于出口场景非常有用（这类场景最常用于集群承载的代理型工作负载）。
XBackend API 目前处于实验阶段，其行为可能会发生变化，因此不建议将其用于生产环境。
实验性 API 分组调整
之前，实验性资源与标准资源共享同一个 API 组—— gateway.networking.k8s.io ——两者的区别仅在于版本格式上的差异，即 v1alpha2 样式。TCPRoute 和 UDPRoute 是最后一批采用这种架构开发的资源。
今后，新的实验性资源将被归类到一个独立的组里，编号为 gateway.networking.x-k8s.io 。这些资源的 API 类型名称会加上 X 作为前缀——例如 XBackend 和 XMesh。当这些资源升级为标准版本时，它们的名称会改为 gateway.networking.k8s.io 组的形式，并且会去掉 X 前缀。就像 XMesh 即将升级为 Mesh 一样。
3. KubeSphere v4.3.0 正式发布：推出智能助手，打造更易用的企业级云原生平台
KubeSphere v4.3.0 正式发布：推出智能助手，打造更易用的企业级云原生平台
KubeSphere v4.3.0 全新上线，一方面持续打磨 KubeSphere Core 核心平台体验，优化许可管理、故障排查、负载管理等基础能力；另一方面重磅推出 KubeSphere Copilot AI 智能助手扩展能力，依托平台现有多租户、观测、权限体系，把智能分析融入日常运维流程，从实操层面降低平台使用门槛，助力高效落地运维服务。
- 故障排查轻量化，提升问题处置效率：新增可视化 kubectl debug，运维人员可直接在控制台为 Pod 创建调试容器，无需本地安装工具、登录节点，在平台内完成基础故障定位，简化问题排查链路。平台同步优化实时日志查询体验、工作负载回退交互；搭配全新 KubeSphere Copilot，支持页面文本一键带入 AI 侧边栏，结合告警、指标信息辅助分析资源与业务异常，缩短问题定位耗时。
- 许可与资产精细化管理，让交付与管理更省心：支持 License 增量导入，可分开管理软件许可期限、维保服务期限。离线环境下支持配置私有镜像仓库凭证，优化私有镜像仓库场景部署体验。支持导出许可证环境信息，便于许可申请、日常问题排查。
- 平台体验持续优化，增强可定制性与稳定性：支持自定义导航菜单，可根据业务场景调整导航入口。增强终端模板自定义能力，适配企业安全管控规范。底层升级 Redis 及 Redis HA 组件，提升平台自身稳定性与兼容性。
- KubeSphere Copilot：开启云原生智能运维新时代：KubeSphere Copilot 是 KubeSphere 平台全新推出的云原生智能助手能力。基于 HolmesGPT 构建 Agentic AI，打造平台运维 AI Copilot，深度融合 KubeSphere 多租户、可观测、工作流与权限体系，通过 UI 界面与开放 API 提供一体化智能运维能力，实现集群自动化故障诊断、问题根因分析与优化变更建议。供常驻右侧对话侧边栏，浏览业务资源时可随时唤起 AI 对话。内置流式输出、Markdown 渲染、代码高亮复制等标准对话交互能力。支持接入商用/开源大语言模型，可通过配置快速切换模型源。支持手动选定集群绑定对话上下文，保障多租户数据隔离。全工作负载内置 AI 诊断入口，支持指标、事件告警一键智能分析。支持页面文本一键带入 AI 侧边栏，快速解读资源信息。
拓展阅读：Simplify hybrid cloud ops with Red Hat OpenShift Lightspeed: 5 sets of prompts to try today
4. Red Hat OpenShift 4.22 开始支持 EVPN
背景
传统的 Kubernetes 网络架构通常将集群边界视为软件定义网络终止、企业网络开始的地方。在集群内部，连接性由 Kubernetes 网络堆栈进行抽象化和自动化处理。而在集群之外，连接性则遵循成熟的路由架构、数据中心网络结构以及经过多年发展形成的运营规范来加以管理。
简介
EVPN（Ethernet VPN）是一种基于 BGP 的网络控制平面，配合 VXLAN 把二层/三层网络抽象出来，让不同物理网络上的工作负载像在同一个逻辑网络里通信。
借助行业标准的 EVPN 控制平面，OpenShift 能够更自然地与现有的 EVPN-VXLAN 数据中心网络架构进行集成，从而实现一致的二层与三层连接性、可扩展的网络虚拟化，以及与企业网络基础设施的协同运作。这一功能对于那些在现代化大型虚拟化环境的同时，仍需保留传统网络架构和运营模式的组织来说尤为重要。
OpenShift 4.18 版本引入了用户自定义网络功能，使得能够在集群内为高级应用程序提供隔离的二层与三层网络域。OpenShift 4.19.12 版本则通过边界网关协议（BGP）进一步扩展了这一功能，使 OpenShift 能够直接参与到企业级路由架构中。
从根本上说，EVPN 使得连接在不同物理网络上的工作负载能够像位于同一二层或三层段一样进行通信。即使流量需要经过多个路由网络、叶节点-主干节点结构或地理分布的数据中心，EVPN 也能实现这种通信。其实现方式是通过使用 BGP 作为基于标准的控制平面来分发 MAC 和 IP 可达性信息，从而将逻辑网络与底层物理拓扑分离开来。同时，这些流量被封装在 VXLAN 隧道中传输。
价值
这种功能对于那些正在现代化大型虚拟化环境或需要在混合基础设施上运行的组织来说尤为宝贵。当虚拟机工作负载从现有的虚拟化平台迁移到 OpenShift Virtualization 时，EVPN 能够确保这些工作负载保持与同类资源相同的逻辑网络连接。在迁移过程中，现有的 IP 地址分配方案、网络策略以及应用程序依赖关系都可以得到保留，从而无需进行破坏性的网络重新设计或大规模的地址重新分配工作。
📰 专题二 新闻与访谈
1. 英国正式将 Microsoft、Google、亚马逊网络服务和甲骨文指定为金融领域的“关键第三方”
UK says the cloud is financial infrastructure
英国已正式将 Microsoft、Google、亚马逊网络服务和甲骨文指定为金融领域的“关键第三方”，这意味着它们现在受到英国金融监管机构的直接监管，而不再被视为监管范围之外的远程基础设施供应商。这些指定于 2026 年 7 月 13 日生效，监管将由英格兰银行、审慎监管局和金融行为监管局共同执行。
多年来，企业一直将云平台视为外包技术供应商。但现在，监管机构提出了不同的观点。他们指出，当足够多的银行、保险公司、支付机构以及市场基础设施依赖于同一批云服务提供商时，这些提供商就会成为具有系统性的基础设施，无论它们是否愿意接受这一标签。据路透社报道，英国的相关框架将要求这些提供商进行弹性测试、自我评估以及事件报告等工作。换句话说，这不仅仅是更多的政策规定，而是针对这些平台本身的运营监管。人们需要将云计算视为金融系统自身管道的一部分，而非外包的产能。
传统上，监管机构主要关注银行、保险公司或市场机构，并要求这些机构自行管理来自外部供应商带来的风险。这种做法仍然存在，金融机构仍需对其自身的抗风险能力负责。然而，英国现在认为，在某些情况下，这种间接管理模式已经不够了。如果第三方变得足够重要，监管机构希望能够直接了解该第三方在抗风险方面的能力。
直接监管意味着云服务提供商不再被当作可选的技术合作伙伴来对待，而是被视作支持国家经济稳定的重要基础设施。一旦这种情况发生，架构决策的重要性就发生了改变。关于控制层、故障转移模型、身份依赖关系、区域设计、可观测性以及事件响应等方面的决策，不再只是内部工程方面的选择，而是成为了一个更广泛的韧性建设议题，甚至可能涉及到监管机构的参与。
如果你所在的行业受监管或高度敏感，你应将此视为一个警示：韧性不能再被视为次要话题。你需要准确知道哪些服务对业务至关重要，哪些控制平面是共享的，哪些身份系统会造成跨平台依赖，以及你的恢复假设在现实世界中是如何运作的。大多数组织在这里比他们想象的要弱得多。英国的举措也应促使关于运营透明度展开严肃讨论。如果监管机构要求主要供应商提供事件报告和韧性证据，企业应当要求更清晰的依赖映射和更好的架构可视化。
更深层的信息是，云计算正在从企业技术选择转向国家和行业层面的基础设施政策。一旦少数政府和中央监管机构开始这样对待云，世界其他地区通常也会以某种形式效仿。我们已经在欧洲看到类似的担忧，现在英国也采取了自己的行动，直接指定并进行监督。
拓展阅读：When the cloud control plane fails
2. CoHDI 加入 CNCF 沙箱：让 Kubernetes 灵活组合 GPU 等硬件资源
CoHDI 加入 CNCF 沙箱：让 Kubernetes 灵活组合 GPU 等硬件资源
CoHDI 于 2025 年 3 月启动，由 Red Hat、FSAS、Fujitsu、IBM Research 和 NTT 共同协作推进。CoHDI 的前身是 InfraDDS，其目标是围绕 Kubernetes 节点上的可组合解耦基础设施，培育一个由社区推动、基于标准的下一代架构生态系统。CoHDI 是 Composable Hardware in Disaggregated Infrastructure 的缩写，读作“Cody”。
CoHDI 面向可组合解耦基础设施，通过 Kubernetes 动态资源分配（DRA）将传统固定绑定的硬件资源纳入云原生编排，使 GPU 等设备可以按 Pod 需求动态挂接或卸载。对于 LLM 推理中的 Prefill/Decode 解耦、Agentic AI 不同运行阶段的资源变化等场景，这种能力有望提升资源分配效率与可持续性。
CoHDI 软件套件旨在弥合传统硬件边界与云原生编排之间的鸿沟。通过直接集成 Kubernetes 动态资源分配（DRA），并与 SIG Node、SIG Autoscaling 和 SIG Scheduling 协作，CoHDI 依靠三个核心组件无缝管理解耦资源。
- Composable-DRA-Driver：该组件与 Dynamic-Device-Scaler 协同工作，根据 Pod 请求实现设备的动态扩缩容。它充当 Kubernetes 与可组合解耦基础设施 CoHDI Manager 之间的桥梁，将 CoHDI Manager 管理的可用资源以 ResourceSlice 的形式暴露在 Kubernetes DRA 框架中。
- Dynamic-Device-Scaler：该组件与 Composable-DRA-Driver 配合，根据 Pod 请求动态增加或移除设备，整个过程不需要重启操作系统。
- Composable Resource Operator：这是一个 Kubernetes Operator。它调用可组合解耦基础设施 CoHDI Manager 的外部 API，将 GPU 等可组合硬件资源动态挂接到集群节点，或从节点上卸载。
3. Nutanix 支持裸机 Kubernetes 并看好 Arm 架构
Nutanix brings its K8s to bare metal because hardware matters again
Nutanix built $20m AI cluster to reduce use of Copilot and Claude, expects ROI in a year
Nutanix 越来越倾向于将其产品移植到 Arm 架构上运行，这一决策是由于硬件价格高昂，以及希望让客户能够在任何他们想要的地方使用其产品所决定的。Nutanix 的客户目前非常清楚硬件成本和可用性的问题，这些问题正在阻碍一些软件采购的完成。Nutanix 试图通过扩大硬件兼容性列表以及支持外部存储设备来避免这种延迟现象。
公司决定允许在裸机环境下运行其 Kubernetes 平台，这也是实现硬件最小化的努力之一。今天，Nutanix 的 CEO 在 The Register 杂志上表示，现在 Nutanix 认为支持 Arm 架构是确保其软件平台能够在用户需要的任何设备上运行的关键途径。他认为，采用这种架构意味着 Nutanix 的软件平台可以在成本较低的硬件上运行，而在当前的市场环境下，用户通常愿意购买价格较低的硬件。
Nutanix 的 Kubernetes 平台可以在裸机环境下运行，这一功能被命名为 NKP Metal。这意味着将容器化应用平台部署在边缘基础设施上变得更加容易。Nutanix 的云平台将使用与处理虚拟机器或运行在虚拟机器上的 K8s 实例相同的工具和策略来管理 NKP Metal。Nutanix 认为，裸机 K8s 架构为人工智能工作负载提供了相当不错的性能，尤其是在训练任务方面。
🔐 专题三 安全
💬 专题四 讨论与分享
1. 通过 VMware vSphere Kubernetes 服务策略套件，简化 Kubernetes 系统的安全性管理
Simplify Kubernetes Security with the VMware vSphere Kubernetes Service Policy Bundle
背景
随着 Kubernetes 在企业环境中的应用不断扩展，平台团队的责任也越来越重要。他们不仅需要负责提供集群服务，还需要提供安全、标准化的平台，以便应用程序团队能够快速部署应用程序，同时满足组织的安全性和合规性要求。
Kubernetes 的准入控制策略已成为该策略的重要组成部分。这意味着在工作负载被允许接入集群之前，需要进行验证。这样就能避免常见的安全配置错误，比如允许特权容器运行、主机命名空间访问，或者容器以 root 用户身份运行等问题。
组织希望建立一个完整的政策库，但这需要时间、专业知识以及持续的维护工作。他们必须确定要实施哪些政策，编写或获取政策定义，对这些定义进行验证，然后确保在各个集群中一致地应用这些政策。
Policy Bundle 附加组件
VMware vSphere Kubernetes Service（VKS）引入了 Policy Bundle 附加组件。该组件提供了一组精心挑选的 Kubernetes 准入策略，这些策略符合 NSA/CISA 的 Kubernetes 加固指南 v1.2 的要求。结合 Broadcom 开发的 Gatekeeper 附加组件，平台工程师可以轻松建立支持的安全基线，而无需亲自创建和维护策略定义所带来的操作负担。
该政策套件提供了一整套预先封装的访问策略，这些策略遵循了 NSA/CISA 的 Kubernetes 加固指南 v1.2 版本。用户无需自行编写和维护各种门控约束模板，平台工程师只需在集群生命周期管理中安装这些预定义的策略配置文件即可。
由于这些策略是通过 VKS 进行打包和传递的，因此组织可以在保持集群间安全级别一致的同时，减少管理策略内容所需的操作工作量。平台团队无需再自行获取、打包和维护策略定义，而是可以依赖由 Broadcom 策划的、已与 VKS 集成且随时可以部署的策略集。
配置的灵活性
每个 Kubernetes 环境都是独特的。有些组织正在部署新的绿色新项目集群，而另一些组织则在对现有的生产环境进行现代化改造。通过以下机制提供相应的灵活性：
- 策略可选
- 策略支持两种模式：
- 警告模式：虽然发现了一些违规行为，但工作负载仍然能够安全地进行部署。
- 拒绝模式：不符合要求的工作负载在接入过程中会被拒绝。
- 支持设置排除范围
实现机制
Policy Bundle 与由 Broadcom 开发的 Gatekeeper 附加组件协同工作。Gatekeeper 负责处理 Kubernetes API 请求的技术评估工作，而 Policy Bundle 则提供了符合 NSA/CISA 标准的策略定义。通过这种方式，Policy Bundle 能够提供一种集成的执行解决方案，无需平台工程师亲自编写或维护策略内容。
使用前提：在启用 Policy Bundle 之前，必须先在目标 VKS 集群上成功安装并运行由 Broadcom 开发的 Gatekeeper 附加组件。
NSA/CISA Kubernetes Hardening Guidance
NSA/CISA Kubernetes Hardening Guidance 是美国 NSA（国家安全局）和 CISA（网络安全和基础设施安全局）发布的 Kubernetes 安全加固指南，用来说明 Kubernetes 集群常见风险，以及如何通过配置和策略降低被攻击面。
它主要关注几类问题：
- 容器和 Pod 安全：例如扫描镜像漏洞和错误配置，避免容器以 root 运行，禁止特权容器，限制 Linux capabilities，使用只读 root filesystem。
- 权限最小化：限制过大的 RBAC 权限，避免随意绑定 cluster-admin，减少 service account token 暴露。
- 网络隔离：通过 NetworkPolicy、TLS、访问控制等方式限制 Pod、服务和控制平面之间的非必要通信。
- 控制平面与节点保护：保护 API Server、etcd、kubelet 等关键组件，减少公开暴露，强化认证、授权和审计日志。
- 监控与审计：保留日志、监控异常行为，帮助发现配置漂移、权限滥用或攻击活动。
2. Karpenter 的节点整合机制
Karpenter's consolidation behaviour is counter-intuitive
摘要：
- Karpenter 架构包含两个控制循环：一个是“扩展”循环，另一个是“整合”循环。扩展循环的设计目标是实现快速响应：它能够迅速处理任何待处理的任务，并立即启动新的节点以尽快安排这些任务。而整合循环则相对较慢，它不断寻找任务与节点的最佳配置方案，这里的“最佳”指的是“最便宜”的配置。实际上，这意味着系统会不断尝试将任务从“使用率较低的”节点上移开，从而让这些节点能够被终止。
- 对于整合，只能设置两个参数（每个节点池一个）： consolidationPolicy 和 consolidateAfter 。第一个参数用于控制 Karpenter 进行整合的方式，你可以将其设置为 WhenEmpty 或 WhenEmptyOrUnderutilized 7；第二个参数则决定了节点在等待整合机制启动之前需要等待的时间长度。
- Karpenter 会考虑将某个节点进行整合，无论该节点已经负载到何种程度。无论该节点上运行的是一个容器，还是一百个容器，只要这些容器位于节点的 consolidateAfter 范围之外，那么该节点就有资格进行整合。从 Karpenter 的角度来看，唯一重要的因素是：“这些容器是否可以被转移到其他地方？”这意味着，Karpenter 的整合行为完全不依赖于特定节点的状态，而是完全取决于其周围集群的状态。在一个拥有大量 Pod 的集群中，如果一个节点上有 100 个 Pod，那么它就不会被整合。而在一个有许多空闲节点的集群中，同一个节点上的 100 个 Pod 就有可能被整合。或者更简单地说：Karpenter 利用全局状态（整个集群的现状是什么？）来做出局部决策（我该如何处理这个节点？）。通常来说，这种做法与分布式系统所期望的恰恰相反。
3. EKS 的自动模式如何检测、修复和诊断节点故障
Under the hood: how Amazon EKS Auto Mode detects, repairs, and diagnoses node failures
Amazon EKS Auto Mode 是 EKS 的托管计算模式，AWS 负责节点生命周期、容量供应、扩缩容和部分数据平面运维。Node Monitoring Agent（NMA）是 AWS 提供的节点监控组件，用来把底层故障转换成 Kubernetes NodeCondition。Karpenter 是节点供应和替换控制器，在 EKS Auto Mode 中负责根据这些健康信号替换故障节点。
某个 GPU 从 PCIe 总线上脱落，某个网络接口变得不可用，或者容器运行时出现故障。在大多数 Kubernetes 集群中，这种情况就意味着麻烦开始了：有人会醒来查看仪表盘信息，通过 SSH 登录系统，然后手动隔离、排空故障节点，并最终终止该实例。而在 Amazon Elastic Kubernetes Service（Amazon EKS）的自动模式下，故障节点会在无人干预的情况下被自动检测、排空并替换掉。
实现这一功能需要两个组件的共同作用。Amazon EKS 节点监控代理（NMA）负责检测故障，并将相关信息记录为 Kubernetes 节点的状态变化。Karpenter 则会根据该状态来替换故障节点。在 EKS 自动模式下，这两个组件会无需任何配置即可自动运行。而在其他 EKS 计算环境（如由管理系统管理的节点组或自行管理的 Karpenter 集群）中，你可以将节点监控代理作为 EKS 附加组件进行安装，以获取相同的检测信号。这样就能实现相同的修复功能。自动模式下的区别在于，该代理作为系统服务运行在 AMI 中，而不是作为 DaemonSet 运行。这意味着即使在 Pod 调度出现问题时，该代理也能持续运行，而不会被意外淘汰或配置错误。
部分参数说明：
大规模运营的经验总结：
- 如果某种故障无论运行哪些容器都无法自行恢复，那么它就被归类为严重故障，需要更换设备。而如果这种故障取决于工作负载的行为，或者能够自行清除，那么它就被归类为信息性故障，仅作为信息提示而已。
- 20% 的阈值意味着 Karpenter 不会同时终止超过一个节点池的五分之一的节点，这样可以保留大部分的容量，同时还能修复真正的故障。
- 对于加速出现的硬件故障，可以给予 10 分钟的容忍时间，因为这些故障是显而易见的（要么 GPU 存在于总线中，要么不存在），而且忽略它们会带来高昂的成本。而对于内核、运行时、网络以及存储方面的故障，则可以给予 30 分钟的容忍时间，因为这些子系统中的临时问题可以自行解决。轻微的网络故障或短暂的运行时重启，不应该成为节点的负担。
- 原因代码是一种公开可用的 API。每个下游应用程序（如维修控制器、仪表盘、客户自动化系统等）都会通过字面匹配来识别原因代码。我们将其后的原因代码添加视为功能更新，而严重等级的变化则被视为破坏性变更。
- “缺席”并不等同于“健康”。当监控器被禁用时，代理根本不会输出任何状态信息，而是选择不写入
True或Unknown。如果写入True，就会误以为节点是健康的，而实际上该节点可能并不健康。而写入Unknown则会导致不必要的修复操作。因此，不输出任何信息才是安全的选择。
4. EKS 加速超大容器镜像拉取
Pulling multi-gigabyte container images in seconds on Amazon EKS
背景
当镜像成为瓶颈时：机器学习改变了容器镜像的样貌。一个典型的应用程序只需几百 MB，几秒钟内就能启动。现代机器学习推断镜像包含深度学习框架、CUDA 栈，有时还包含模型权重。这些镜像大约可达 20 到 30 GB，有些甚至更高。在 GPU 和加速实例上，拉取其中一个镜像需要几分钟才能满足第一个请求：这段时间里，已配置的加速器准备处理实际工作，但等待镜像被拉取。
简介
容器镜像不是单一文件。它是一个图层堆叠加上一个列出图层的小型 JSON 清单。每一层都是文件系统部分的 tar 压缩档（一层是基础操作系统，另一层是 CUDA 库，第三层是你的代码），经过 gzip 压缩。对于每一层，清单记录摘要，即压缩字节的 SHA-256 哈希值，以便节点证明收到的正是发布内容。当容器运行时，这些层会被堆叠并挂载到一个统一的文件系统中。
镜像中的每一层大小大致不相等。单层可能占总镜像的一半以上，单层通常达到 9 GB 或更大，其余层相对较小。这种规模差异直接影响拉取时间。
将每一层都应用到节点上需要经历六个阶段。传统上，行业标准的容器运行时工具——containerd，会依次执行这些操作。
下载层可以并行进行，但解压过程却是逐层进行的。直到第一层完成所有六个阶段的操作之后，第二层才能开始。因此，在下载过程中，节点往往只受到某一资源的限制：在下载阶段，可能是网络带宽的限制；在解压和哈希验证阶段，可能是 CPU 的限制；在提取数据阶段，则可能是磁盘吞吐量的限制。其他资源则处于闲置状态，等待自己的执行时机。
EKS 的处理：
- 把“先整包下载完再启动”改成“边下边用”：通过索引和 seekable 方式，容器可以更早开始运行，不必等整个镜像完全落盘解包。
- 并行 pull / unpack
5. EKS 支持 Kubernetes 控制面配置
Introducing advanced Kubernetes control plane configuration in Amazon EKS
EKS 支持配置托管控制平面里的 kube-apiserver、kube-scheduler 和 kube-controller-manager 参数，而不需要自己维护自定义 scheduler 或自建 Kubernetes 控制平面。
具体支持配置以下参数：
- kube-scheduler：Pod 放置策略。支持配置 nodeResourcesFit.scoringStrategy，例如从默认的 LeastAllocated 改成 MostAllocated。LeastAllocated 倾向把 Pod 放到更空的节点上，优先分散；MostAllocated 倾向把 Pod 放到已经较满的节点上，优先装箱。后者可以让相同工作负载集中跑在更少节点上，减少半空闲节点，方便后续节点回收和降低计算成本。
- kube-controller-manager：HPA 同步周期。支持配置 horizontalPodAutoscalerSyncPeriod，控制 HPA 多久评估一次指标并做扩缩容决策，范围是 10-15 秒。更短周期可以让应用在负载上升后更快扩容，但这个参数需要 EKS Provisioned Control Plane。
- kube-apiserver：事件保留时间；支持配置 eventTtl，范围是 10-60 分钟。高 churn 集群，例如批处理、CI/CD、AI/ML 训练，会产生大量 Kubernetes events。缩短保留时间可以降低 etcd 压力，提高 API server 的 list/watch 响应效率，但会缩短 kubectl get events 和 kubectl describe pod 能看到的历史窗口。
- kube-apiserver：NodePort 端口范围。支持配置 serviceNodePortRange，范围是 10260-32767。它适合迁移遗留应用时对齐已有固定端口、网络策略或防火墙规则，减少改应用或额外加代理的需求。
6. 如何将 Kubernetes 的 YAML 格式数据以 KYAML 格式进行美化，以及为什么应该这样做
How to Pretty-Print Your Kubernetes YAML as KYAML and Why You'd Want To
多年来，YAML 一直都是编写 Kubernetes 配置文件的标准格式。你遇到的每一个示例、教程以及配置文件都是用 YAML 编写的。问题并不在于 YAML 是一种不好的格式，而在于 YAML 提供了许多选择，而并非所有选择都适合用于编写 Kubernetes 配置文件。某些功能会使得文件更难以阅读，有些功能容易被滥用，还有一些功能可能会导致意外的行为。
Kubernetes 实际上并不需要那些功能中的大部分。它只依赖于一小部分的 YAML 格式。这引出了一个问题：如果 Kubernetes 只需要少量的 YAML 数据，那么为什么不将这些数据标准化，而忽略其余部分呢？作为替代方案，SIG CLI 引入了 KYAML 这种更严格、更统一的 YAML 编写方式。
KYAML 是标准 YAML 语法的严格子集（或“方言”），其设计目的是让现有系统能够无需任何修改即可解析它。正如在 KEP 5295 中所提出的，它并没有引入新的格式或解析器。它只是限制了在编写 YAML 时可以选择的选项范围，这样一来，最终所有人都会使用相同的表达方式。
可以把它看作一种约定俗成的风格，而不是一种全新的语言。KYAML 中所有的有效格式，在 YAML 中同样也是有效的。
具体细节见原文。
7. Kubernetes DRA 会取代 HAMi 吗？
DRA（Dynamic Resource Allocation）是 Kubernetes 的动态资源分配机制，用 ResourceClaim、DeviceClass、ResourceSlice 等原生 API 表达设备需求。HAMi 是 CNCF 孵化项目，主要解决 Kubernetes 中 GPU 共享问题，能把一张 GPU 按显存和算力切片给多个 Pod 使用。
DRA 是否会让 HAMi 过时？
简短的回答是“不会”，但完整的答案取决于你讨论的是 HAMi 的哪项职能。其中一项——编码细粒度请求，以便调度器能够理解——正是 DRA 所吸收的。另一项——在容器内部，以 CUDA 调用为粒度执行这些资源限制——则是 DRA 从未设计要承担的工作。
8. 停止使用 CPU limits：原因与证据
Stop using CPU limits: why + proof
CPU request 是 Kubernetes 调度和 CPU share 的依据，表示 Pod 至少应该获得多少 CPU；CPU limit 是硬上限，超过后会被 Linux CFS throttling，即使节点上还有空闲 CPU，也可能被限速。
贴主观点：很多在线服务不应该随手设置 CPU limit，因为它可能制造不必要的延迟抖动。在贴主的测试里，加上 CPU limit 后，Web API 的典型延迟从 23ms 上升到 87ms，平均 CPU 图表看起来却仍然正常，问题藏在 throttling 里。
9. Amazon EKS 中的证书轮换机制
Deep dive into Amazon EKS certificate authority rotation
背景
每个连接到 Amazon Elastic Kubernetes Service（Amazon EKS）集群的 Kubernetes API 的连接，都依赖传输层安全证书（TLS 证书）来确保连接的安全性。这些证书由集群的证书颁发机构签发，该机构能够确保所有连接系统与 API 服务器之间的信任关系。当客户端使用 kubectl 进行操作、ArgoCD 进行部署协调、或者工作节点上的 kubelet 报告状态时，所有这些连接都会使用这些证书与 API 服务器进行身份验证，而这些证书又源自于集群的证书颁发机构。这就是 Kubernetes 的工作机制：证书颁发机构是整个集群信任的基石。
自 2018 年推出以来，亚马逊 EKS 集群所使用的证书拥有 10 年的有效期。这些早期集群即将进入证书轮换的阶段。
自动化的 CA 轮换机制
Amazon EKS 提供了自动化的 CA 轮换机制，能够确保在整个轮换过程中保持集群的可用性。您仍然可以按照自己的时间表进行操作。CA 轮换是一个共同的责任，AWS 会自动处理其管理的组件。而您则需要负责更新那些只有您才能访问的组件，比如持续集成和持续交付流程、工作站以及不由 AWS 管理的工作节点。接下来的部分将详细说明这一机制的实际运作方式。
成功的 CA 轮换意味着两件事：你的集群始终处于可用状态（AWS 的保障措施确保了这一点），而且所有组件在迁移过程中都能保持连接。第一点由 AWS 保证。第二点则取决于你能否顺利完成迁移任务。
AWS 负责处理以下事项：AWS 负责管理组件轮换的生命周期，并自动更新 EKS 中的所有由 AWS 管理的组件（如控制平面、EKS 自动模式、AWS Fargate 等），使其能够信任新的证书颁发机构。对于这些组件来说，您无需采取任何行动。
你的职责是负责更新你所管理的工作节点（包括管理节点组、由 Karpenter 控制器管理的节点、自行管理的节点以及混合类型的节点）。此外，你还必须更新外部客户端的数据，如 kubeconfig 文件、CI/CD 管道以及 GitOps 控制器，以确保它们在激活之前能够信任新的证书颁发机构。
AWS 提供的相关能力：
- 在 Amazon EKS 中，AWS 管理的组件包括控制平面、EKS 自动模式和 AWS Fargate 等。这些组件已更新为能够信任新的证书颁发机构（即那个将取代现有证书颁发机构的新机构），而无需您采取任何行动。这些组件由 AWS 在 Amazon EKS 中完全管理，并且在证书颁发机构激活的任何时刻都能保持连接性。证书颁发机构激活指的是集群开始使用新的证书颁发机构来颁发新证书的过程。
- 提供自动化安全保护。AWS 提供了多种保护机制，以确保您的 EKS 集群能够持续正常运行。
- 通知机制。AWS 会在旋转生命周期的每个阶段通过 AWS Health 和电子邮件向您通知情况。每一条通知都会说明发生了什么，需要您采取什么行动（如果有的话），以及您的集群在旋转时间表中的位置。
📄 专题五 报告查看与分析
1. Nutanix 2026 年第四季度及全年的财务业绩
Nutanix Reports Fourth Quarter and Fiscal 2026 Financial Results
⚠️
- Nutanix 的 fiscal 2026 截止到 2026-07-31。Q4 FY2026 = 2026-05-01 到 2026-07-31 这一季度。此为财年财报，不是自然年财报。
- GAAP 是 Generally Accepted Accounting Principles，即美国通用会计准则。它是美国上市公司编制财报时必须遵守的标准口径。几个带 GAPP 的指标可以理解为 “按美国会计准则计算的 xx 指标”
全年关键数据
- 新增超过 3000 名客户
- 2026 年收入 28.5 亿美元
- 年度周期性收入（ARR）增长 16%
- 毛利率 86.8%
- 自由现金流 8.407 亿美元
- 平均合同期限为 3.2 年（平均合同期限是指在该期间内执行的所有订阅合同、以及数量有限的设备终身合同的金额加权期限；该期限基于计费基础进行计算，并对设备终身许可采用五年假定公认期限。）
2026 财年第四季度的财务总结
| 指标 | 2026 财年 Q4 | 2025 财年 Q4 | 同比变化 |
|---|---|---|---|
| 年度经常性收入 ARR | 25.5 亿美元 | 22.0 亿美元 | 16% |
| 平均合同期限 | 3.3 年 | 3.2 年 | 0.1 年 |
| 收入 | 7.571 亿美元 | 6.533 亿美元 | 16% |
| GAAP 毛利率 | 86.0% | 87.2% | -120 个基点 |
| Non-GAAP 毛利率 | 87.7% | 88.3% | -60 个基点 |
| GAAP 运营费用 | 5.814 亿美元 | 5.382 亿美元 | 8% |
| Non-GAAP 运营费用 | 4.656 亿美元 | 4.572 亿美元 | 2% |
| GAAP 运营利润 | 7000 万美元 | 3120 万美元 | 3880 万美元 |
| Non-GAAP 运营利润 | 1.980 亿美元 | 1.195 亿美元 | 7850 万美元 |
| GAAP 运营利润率 | 9.2% | 4.8% | +440 个基点 |
| Non-GAAP 运营利润率 | 26.2% | 18.3% | +790 个基点 |
| 经营活动产生的现金流净额 | 3.150 亿美元 | 2.195 亿美元 | 9550 万美元 |
| 自由现金流 | 2.776 亿美元 | 2.078 亿美元 | 6980 万美元 |
2026 财年财务总结
| 指标 | 2026 财年 | 2025 财年 | 同比变化 |
|---|---|---|---|
| 年度经常性收入 ARR | 25.5 亿美元 | 22.0 亿美元 | 16% |
| 平均合同期限 | 3.2 年 | 3.1 年 | 0.1 年 |
| 收入 | 28.5 亿美元 | 25.4 亿美元 | 12% |
| GAAP 毛利率 | 86.8% | 86.8% | 0 个基点 |
| Non-GAAP 毛利率 | 88.0% | 88.1% | -10 个基点 |
| GAAP 运营费用 | 22.0 亿美元 | 20.3 亿美元 | 8% |
| Non-GAAP 运营费用 | 18.4 亿美元 | 17.0 亿美元 | 8% |
| GAAP 运营利润 | 2.740 亿美元 | 1.725 亿美元 | 1.015 亿美元 |
| Non-GAAP 运营利润 | 6.754 亿美元 | 5.361 亿美元 | 1.393 亿美元 |
| GAAP 运营利润率 | 9.6% | 6.8% | +280 个基点 |
| Non-GAAP 运营利润率 | 23.7% | 21.1% | +260 个基点 |
| 经营活动产生的现金流净额 | 9.167 亿美元 | 8.215 亿美元 | 9520 万美元 |
| 自由现金流 | 8.407 亿美元 | 7.502 亿美元 | 9050 万美元 |
2027 财年展望
| 展望项目 | 数据 |
|---|---|
| 2027 财年 Q1 收入 | 7.55 亿-7.65 亿美元 |
| 2027 财年 Q1 Non-GAAP 运营利润率 | 26%-28% |
| 2027 财年 Q1 稀释后加权平均股数 | 约 2.94 亿股 |
| 2027 财年全年收入 | 31.80 亿-32.30 亿美元 |
| 2027 财年全年 Non-GAAP 运营利润率 | 24%-25% |
| 2027 财年全年自由现金流 | 8.50 亿-9.50 亿美元 |
公司 Highlight
- Nutanix 宣布推出 MCP 服务器：针对 Nutanix 云平台，Nutanix 发布了 MCP 服务器。该服务器能够为混合云环境提供安全、基于自然语言处理的智能自动化服务，同时不会牺牲控制能力。
- Nutanix 宣布 Dell PowerStore 的上市情况：Nutanix 表示，搭载 Nutanix Cloud Infrastructure 7.6 软件的 Dell 私有云解决方案现已可供使用。
- Nutanix 发布了其第八次年度企业云指数调查的新数据，这些数据属于受监管行业领域。调查显示，在人工智能的隐私保护、数据主权问题、合规性挑战以及组织内部的协作障碍等方面，医疗保健、金融服务和公共部门这三个行业面临的最大风险。
- Nutanix 和 ChronoScale 宣布建立战略合作伙伴关系，以加速企业级人工智能技术的应用：Nutanix 和 ChronoScale 合作推出适用于企业级的人工智能基础设施，共同推动人工智能服务器在全球市场的应用。
- Nutanix 为企业提供了自由运行自主 AI 系统的机会。Nutanix 宣布了 Nutanix Enterprise AI 2.8 版本的正式发布，同时即将推出 Nutanix Kubernetes Platform 2.19 版本。此外，Nutanix 还提供了新的激励措施、计划以及资源，以帮助合作伙伴在新兴 AI 领域加速成长。
💁♀️ 专题六 产品/方案介绍
🤔 专题七 有意思的事与 Meme
1. Top 100 重要的开源项目组织
Discover the world's most critical open source projects
前十五名截图如下：
该网页中有不同维度的更多表单。