🆕 专题一 产品新功能/新版本
1. Amazon ECS Service Connect 支持基于区域的路由功能
Announcing zone-aware routing in Amazon ECS Service Connect
背景
在微服务架构中，流量模式和服务部署方式会直接影响成本和性能。借助 Amazon ECS Service Connect 中的区域感知路由功能，Amazon Elastic Container Service 现在会优先将请求发送到与客户端位于同一可用区内的正常运行的服务端点。这样一来，既能降低跨区域数据传输的成本，又能减少延迟，同时不影响服务的可用性。
工作原理
ECS Service Connect 会将大部分流量引导至同一可用区内的终端节点，从而减少跨可用区的网络调用。该算法利用了 Envoy 的区域感知路由功能来实现这一目标：
- 发现各个端点——该代理能够实时掌握目标服务中所有端点的信息，包括这些端点在哪个可用区中。
- 优先选择本区域的 AZ：在路由请求时，代理会优先将流量发送到与发起请求的客户端位于同一区域的终端节点。
- 基于剩余容量的路由选择方式——该算法并不计算各节点的权重，而是比较每个区域中源节点群和目标节点群之间的比例关系。如果某个目标区域的节点数量多于源区域，那么该区域的剩余容量就可以用来吸收来自其他超负荷区域的流量，从而避免某个区域不堪重负。
- 优雅地回退——如果本地区域中有足够的健康端点，那么流量会自动分配到其他区域的健康端点上，从而确保系统的可用性不会受到影响。
- 动态重新平衡——随着端点的数量增加或减少，路由决策会实时更新，无需进行重新部署。
优势
- 降低数据传输成本
- 更低的延迟
- 无需修改任何应用程序代码
- 保持了高可用性
拓展阅读
What running Kubernetes across millions of clusters taught AWS about zonal failures
2. Amazon EKS 宣布推出回滚功能，以实现集群升级的安全可靠管理
Announcing Amazon EKS Rollback for safe and reliable management of cluster upgrades
背景
由于每年需要发布三个次要版本，因此用户必须定期升级集群，以保持其安全性和功能性。不过，对 Kubernetes 进行版本升级并非易事。新版本往往会导致各种变化，从而影响现有应用程序的运行，比如新增功能、废弃某些 API 或修改内部组件。按照设计，开源版的 Kubernetes 在升级完成后并不支持回滚操作。由于缺乏原生的回滚机制，许多机构不得不采用复杂的解决方案。这些方案包括成本高昂的蓝/绿部署方式，或者手动创建集群状态快照，这些做法都耗费了大量的人力物力。其实，Kubernetes 本身完全可以提供更简单的回滚机制。
借助 Amazon EKS 版本回滚功能，如果您在升级后发现某些问题，现在可以安全地将 Kubernetes 控制平面恢复到已知良好的状态。对于使用 EKS 自动模式的集群，该回滚功能也适用于数据平面，从而为整个集群提供全面的保护。这一功能具有两大优势：首先，它为生产环境中的升级提供了可靠的安全保障，同时也有助于满足与灾难恢复计划相关的监管要求。其次，它有助于加快升级进程，从而提升安全性——因为回滚功能消除了延迟升级的顾虑。这样一来，团队可以更主动地进行升级，减少使用存在已知安全漏洞的软件的时间，同时确保符合那些要求使用经过及时修补的软件的规范。通过提供回滚升级的途径，EKS 版本回滚功能有助于您在保持运行可靠性的同时，始终使用最新的 Kubernetes 版本。
EKS 版本回滚的运作方式
当触发回滚操作时，EKS 会进行一系列全面的安全检查，包括：
- API 兼容性：确保您的资源所使用的 API 与旧版本兼容。
- API 字段变更：检查不同版本之间是否存在不兼容的 API 字段使用情况。
- 集群健康状况：确认不存在任何可能妨碍回滚操作成功的健康问题。
- Kubelet 版本一致性检查：验证工作节点是否遵守 Kubernetes 的版本一致性要求。
- Kube-proxy 兼容性：验证 Kube-proxy 的版本兼容性。
- 附加组件版本：检查已安装的 EKS 附加组件是否与目标版本兼容。
重要限制
- 只能回滚一个 minor version，不能从 N 回滚到 N-2。
- 只能回滚通过 in-place upgrade 升级到当前版本的集群；如果集群创建时就是当前版本，不能回滚到更旧版本。
- 回滚窗口是升级完成后 7 天内，且前一个版本必须仍受 EKS 支持。
- 如果已经使用了新版本 API 或新字段，回滚前需要先移除这些变更。
- Rollback Insights 只检查 EKS managed add-ons，例如 CoreDNS、VPC CNI、kube-proxy；自管理 add-on、定制 AMI 和特殊配置需要用户自己验证。
- Managed Node Groups 需要通过 UpdateNodegroupVersion 回滚 worker nodes；self-managed 和 hybrid nodes 需要用户手动处理。
- Fargate worker node 不支持版本回滚。可以回滚控制面，但 Fargate pod 可能触发 kubelet version skew 检查，需要删除受影响 pod 或使用 --force 绕过部分 insight。
- 如果回滚到 extended support 版本，会产生 extended support 费用。
3. Red Hat OpenShift 4.22 中开始提供 BackendTLSPolicy
BackendTLSPolicy expands Gateway API transport security
BackendTLSPolicy 是一种 Kubernetes 资源，可用于在 Gateway API 中指定额外的传输层安全（TLS）加密措施。这使得 Red Hat OpenShift 上的 Gateway API 用户能够享受到与 OpenShift 路由所提供的一致的安全传输体验。该功能现已在 Red Hat OpenShift 4.22 中正式可用。实际上，重新加密 TLS 数据的功能早已被应用于 OpenShift 路由中，从而确保了用户能够通过加密方式访问 Web 控制台，同时也能确保客户应用程序的登录过程具有安全性。
Gateway API 是一种开源的、下一代网络接入解决方案。它是由 Kubernetes 网络社区开发出来的，旨在取代 Kubernetes 现有的网络接入方案。OpenShift 在 4.19 版本中开始正式支持 Gateway API 这一功能。 BackendTLSPolicy 则是 Red Hat 最近提出的一个改进方案，其目的是让 Gateway API 具备与 OpenShift 现有的 TLS 重新加密功能相媲美的性能。
BackendTLSPolicy 用于指定目标服务，同时提供了灵活的 TLS 验证机制。你可以将主机名用作服务器名称指示符（SNI），或用于验证证书的匹配。此外，还可以使用 subjectAltNames 来匹配多个证书，此时可以将 SAN 值设置为主机名或统一资源标识符（URI）。 caCertificateRefs 可用于指定特定的 TLS 证书组合，而 wellKnownCertificates 则用于指定受信任的系统 CA 证书。
BackendTLSPolicy 的配置方式取决于后端 Pod 所提供的 TLS 证书。在大多数情况下，管理员希望使用同一份证书来保护多个域名或子域名。因此，他们会申请一份包含多个 SAN 字段的证书，以便各个应用程序能够共享该证书。在初始验证过程中，网关会使用其 caCertificate 来验证所提供的证书；随后，网关会检查应用程序所提供的证书，确保至少有一个 SAN 字段匹配。在极少数情况下，证书中只包含一个主机名，此时可以配置 BackendTLSPolicy 作为替代方案。当 Pod 提供的是自签名证书时，更有可能使用 wellKnownCertificates （即默认或系统证书）来验证该证书。这种情况通常出现在开发或测试阶段。
4. 重构 Kepler 以解决旧架构的问题
Kepler, re-architected: Improved power accuracy and a community call to action!
背景
根据国际能源署 2025 年发布的《能源与人工智能》报告，2024 年，数据中心占全球电力需求的 1.5%。预计到 2030 年，这一比例将上升至约 945 太瓦时。这一增长趋势部分是由于人工智能相关任务的快速增长所导致的。在 Kubernetes 集群中，目前没有简单的方法来为不同的任务分配相应的电量。Kepler 解决了这个问题：它能够读取硬件的电量计量数据，将这些数据与 Linux 进程相关联，再进一步与 Kubernetes 集群中运行的各个 Pod 关联起来。最后，Kepler 还会将相关数据以 Prometheus 指标的形式输出。
Kepler 最初的架构依赖于 eBPF 技术。虽然这种技术提升了系统的精确度，但也带来了一些问题。首先，它需要 CAP_BPF 和 CAP_SYSADMIN 级别的权限，而这对于许多生产环境来说是个障碍。其次，当需要以如此高的精度来追踪内核层面的详细进程时，eBPF 容易出错。这种数据不准确性会影响到我们用于在虚拟机上部署 Kepler 的模型训练过程。除了权限和精度问题之外，eBPF 的集成也增加了代码的复杂性，使得代码的维护和扩展变得更加困难。
重新设计
为了优先考虑易用性和准确性的提升，放弃了 eBPF 技术，转而采用更简单、更可靠的方法。经过重新设计的解决方案充分利用了 Linux 系统中标准接口 /proc 和 /sys 的只读功能。由于这些接口在 Linux 系统中普遍存在，因此所需的权限更低，配置也更为简单。通过消除复杂的配置过程，现在可以通过简单的 Helm 配置即可轻松部署 Kepler。
在功耗指标方面，Kepler 之前采用了一种固定的硬件架构模型来计算功耗（例如，RAPL 由核心、DRAM 等组件构成）。但实际上，各种硬件的实际架构差异很大。这意味着，原来的设计实际上是根据一种并不存在的理想化模型来计算功耗的。经过重新设计的 Kepler 能够在运行时动态识别出硬件的实际功耗结构。通过适应底层硬件的实际布局，Kepler 现在能够根据不同环境下的实际情况，提供准确的能耗数据。
后续规划
- GPU 功耗监控功能
- 虚拟机功耗建模
- 验证数据准确性
- 改进空闲状态下的功耗计算方式
5. etcd v3.7.0 发布
重要变化
- RangeStream — 分块流式传输大型结果集，而不是缓冲整个响应。
- 仅限键（Keys-only）的范围请求，更快、更可靠的租约机制，以及其他多项性能改进。
- etcd 现在完全从 v3store 启动，消除了对遗留 v2 store 的长期依赖
- 已完成的 protobuf 重构，用完全支持的库替换过时的 protobuf 库。
- etcd v3.7 包含 bbolt v1.5.1 和 raft v3.7.0。
升级注意事项
此版本包含破坏性更改，特别是关于移除遗留 v2 组件的更改。 用户在升级其节点之前应查看升级指南。与所有次要版本一样，一次升级一个成员，并在步骤之间确认集群健康状况。
6. Security Profiles Operator v1 发布：8 大 API 全面稳定，Kubernetes 安全能力再升级
Security Profiles Operator v1 发布：8 大 API 全面稳定，Kubernetes 安全能力再升级
Security Profiles Operator 是一种独立的 Kubernetes 扩展功能，其目的是让用户在 Kubernetes 集群中更轻松地创建和使用 SELinux、seccomp 以及 AppArmor 等安全配置文件。
Linux 提供了强大的内核级安全机制：seccomp、SELinux 和 AppArmor，用于限制容器化工作负载的行为。每种机制都使用定义允许行为的 profile，但手动编写、分发和维护这些 profile 既繁琐又容易出错。Security Profiles Operator（SPO）通过将安全 profile 作为 Kubernetes 自定义资源（CRD）进行管理、从真实运行工作负载中记录 profile，并以声明式方式将其绑定到 Pod，来解决这一问题。在 v1.0.0 中，Security Profiles Operator 将其全部 8 个 CRD API 升级为 v1。这是该项目的首个稳定版本，并经过第三方安全审计、完整的加固周期，以及从所有旧 API 版本平滑迁移的零停机方案支持。
📰 专题二 新闻与访谈
1. Flux 迎来 10 岁生日
简介
Flux 是一个 Kubernetes GitOps 持续交付项目。它把 Git 仓库作为期望状态来源，由集群内控制器持续拉取、比较并把集群协调到 Git 中声明的状态。
Flux 是一个由 CNCF 认证的项目。
从开始到现在
2016 年 7 月 7 日，Peter Bourgon 提交了初始代码 a6fbd68a，旨在探索实现持续交付的新方法。
目前，Flux 正在被那些使用 Kubernetes v1.11 的先进团队所采用。Flux 在用户的命名空间内运行，开发团队可以完全自助式地安装它。Flux 会复制用户的代码仓库、执行相关脚本、检查容器注册表中的镜像标签，然后通过 kubectl 来应用用户的更改。
十年中的成果：
- 1,076 名贡献者
- 44 个 repo
- 17,946 个 pull request
- 7,474 个 issue
- 对于 Flux 2 而言：
- 210 Flux2 版本已发布
- 302 亿次容器镜像下载量
下一个十年
- Helm 4 支持，并保持 per-resource backwards compatibility；
- Kustomize 和 Helm controller 的资源生命周期改进；
- ConfigMap/Secret watch 触发 reactive apply；
- 跨集群和多服务 Workload Identity；
- GitOps Toolkit 支持自定义 source artifacts；
- 新 CLI plugin system；
- fluxcd/agent-skills 帮助 coding agents 使用现代 GitOps 实践；
- Flux Operator MCP 将运行时状态连接到编辑器和 agentic workflow；
- flux-schema 用于配置校验；
- flux-mirror 用于 artifact relocation 和安全供应链 diode。
2. HAMi 晋升 CNCF 孵化项目：与全球开发者共建 AI 时代的异构算力基础设施
HAMi 晋升 CNCF 孵化项目：与全球开发者共建 AI 时代的异构算力基础设施
2026 年 7 月 2 日，HAMi 正式晋升为 CNCF Incubating（孵化）项目，CNCF 技术监督委员会（TOC）以全票赞成通过了本次孵化投票。
这是 HAMi 继 2024 年 8 月作为 Sandbox（沙箱）项目加入 CNCF 之后的又一重要里程碑。在 CNCF 的成熟度体系里，Sandbox 是面向早期探索项目的 " 试验田 "，Incubating 则要求项目在技术成熟度、安全实践、社区治理、生产采用和生态集成 上都经过严格验证。晋升孵化阶段，意味着 HAMi 已经从 " 有潜力的新项目 " 成长为 " 被真实生产环境广泛采用的可信基础设施 "。
3. 我国启动人工智能大模型 IPv6 能力提升专项行动
中央网信办联合北京、上海、浙江、深圳四地网信办及 5 家头部大模型企业，在雄安新区启动“人工智能大模型 IPv6 能力提升专项行动”，推动生成式大模型应用全面支持 IPv6。行动为期一年，重点提升大模型基础设施 IPv6 支持水平、扩大大模型应用 IPv6 流量占比、提高 API 调用 IPv6 访问比例，并完善相关管理规范。背景是大模型应用快速发展带来 Token 流量爆发，对网络承载能力提出更高要求，IPv6 被视为支撑智能时代网络发展的关键底座。
同日，雄安新区 IPv6 单栈部署行动启动。雄安将从基础建设、应用赋能、技术攻关和生态培育四方面推进 IPv6 单栈部署，目标到 2030 年在新建片区实现 IPv6 单栈规模化运行。
🔐 专题三 安全
本月无。
💬 专题四 讨论与分享
1. 从 Kubernetes Dashboard 到实际应用：步骤指南
Kubernetes Dashboard to Headlamp: A Step-by-Step Guide
差异
Kubernetes Dashboard：
- 使用 Helm 部署在集群中。
- 每个集群都对应一个 Kubernetes Dashboard。
- 可以通过 kubectl port-forward 或入口来访问。
- 通常依赖 ServiceAccount token 登录。
- 包含各种创建资源的表格。
- 依靠表格和列表来进行导航。
Headlamp：
- 既可以在桌面电脑上运行，也可以在集群环境中运行。
- 和 kubectl 一样，能够读取 kubeconfig 文件。
- 可以在一个位置上显示多个集群。
- 创建或修改资源时，YAML 格式更受青睐。
- 包含列表视图和可视化地图。
- 可以通过插件来添加各种功能。
迁移前的检查清单
- 列出基本要素：
- 使用的是哪些集群（开发环境、测试环境、生产环境）
- 最常使用的是哪些命名空间
- 最常进行的操作是什么（查看、编辑、缩放、删除、调试）
- 通过哪种方式访问控制面板？是端口转发还是其他方式？
- 是如何登录的（使用 service account token，还是通过其他方式？同时，还涉及了哪些 RBAC 绑定设置？）
- 检查 kubeconfig 是否正常工作
- 选择实施计划
- 并行迁移（推荐）
- 直接切换
- 确定 Headlamp 的安装位置
- 桌面
- 集群内部
- 可选的依赖项
- metrics-server （用于显示 CPU 和内存使用情况的数据图表）
- 入口地址（用于集群内的 URL）
- OIDC/SOSS（用于浏览器登录）
- 清理旧的 Dashboard service accounts 和 RBAC 配置
然后进行安装与配置，理解并使用各种资源/掌握如何利用各种资源。
2. Kubernetes 赢得了容器技术的十年主导权，谷歌的 Agent Substrate 则希望成为下一个主导者
Kubernetes won the container decade. Google’s Agent Substrate wants the next one.
简介
- Agent Sandbox：Google 在 GKE 上推出的安全执行环境，用于运行 AI Agent 生成的非可信代码。它基于 Kubernetes，但默认使用 gVisor 做内核级隔离，并配合默认拒绝的网络策略。
- Agent Substrate：Google 提出的 Agent 运行时/调度层，用来管理大量长生命周期、状态化、但大部分时间处于空闲状态的 Agent session。它运行在 Kubernetes 旁边，而不是把每个 Agent 都直接变成普通 Pod。
- kagent：Solo.io 的 Kubernetes-native Agent 平台，已经把 Agent Substrate 作为可选 runtime 接入。
背景
谷歌于 2026 年 5 月正式推出了 GKE Agent Sandbox 功能。在同一份公告中，谷歌还介绍了另一个名为 Agent Substrate 的项目。这两项举措都承认了 Kubernetes 领域的老手们一直不愿承认的事实：在过去的十年里占据主导地位的容器技术平台，并不适合用来作为 AI 智能体的控制平台。
主要观点
- 如果把各种代理程序比作操作系统中的进程，而不是数据中心里的服务，那么两者之间的差异就显而易见了。现代操作系统会运行成千上万的进程，而这些进程大部分时间都处于“休眠”状态。只有当有事件发生时，系统才会唤醒相应的进程，分配一部分 CPU 资源给它处理任务。之后，系统会将该进程的空闲内存转储到磁盘上，以便为下一个需要处理的进程腾出空间。各种代理程序的行为其实与这些进程非常相似。Kubernetes 最初是为了管理那些需要长期运行、且需要被复制的服务而设计的。这一设计理念也解释了为什么现在许多代理程序都是在 Kubernetes 上运行的，而不是作为其中的某个工作负载来集成进去的，比如 Deployment 或 StatefulSet。
- 代理其实是一种长期运行的、具有状态保持功能的进程。在大部分时间内，它都处于闲置状态；只有当需要执行某段代码时，它才会被激活。所执行的代码是由模型在运行时生成的。默认情况下，主机应将其视为不可信的实体来处理。每个代理都需要有唯一的身份标识，能够暂停和恢复运行而不丢失先前存储的数据，同时还要与周围的代理严格隔离。
- Kubernetes 通过中央 API 服务器以及专为处理少量长期运行的 Pod 而设计的调度器来安排任务。这种设计假设，Pod 的部署决策是偶尔发生的、且一旦确定就不会轻易改变。但实际上，各种代理程序不断产生大量的详细调度请求，打破了这一假设。这样一来，控制平面反而成了瓶颈，而无法发挥其作为调度协调者的作用。
- 调度策略往往是首先受到影响的。研究代理调度的学者们指出，Kubernetes 集群中常用的轮询和随机分配策略，在请求时间较短、请求到达率较高的情况下效果不错，因为此时错误的调度决策很快就能被纠正。然而，当代理请求的时间变长、请求频率降低时，错误的调度决策就会持续存在，从而增加后序用户的延迟。
- 第二个压力点就是 API 服务器本身。如果要把每一个代理节点——无论其是处于活跃状态还是闲置状态——都作为 Kubernetes 对象来存储，那么系统中将需要处理数以百万计的资源，而该系统的架构显然无法承受如此大的负载。Agent Substrate 的架构文档也明确指出了这一点：没有简单的方法能让标准控制平面来管理这么大量的对象。因此，运行时系统会将大多数代理节点排除在控制平面的管理范围之外。在路由方面，系统也采用了类似的解决方案：通过专门的网络层将每个请求直接发送到相应的会话中，如果该会话处于休眠状态，则会将其唤醒。
- Agent runtime 很可能成为继 VM、container、serverless 之后的新一层计算抽象。Kubernetes 仍然是底层基础设施，但 Agent 的调度、休眠、恢复、隔离和状态管理会在 Kubernetes 之上重新构建。
3. Pod 真的是部署 AI 智能体的合适单元吗？
Is a Pod the right deployment unit for an AI agent?
背景
第一阶段：一个运行时环境可以容纳多个代理
在最初开发 kagent 的时候，我们并没有让每个代理都在独立的 Kubernetes Pod、Service 和 ServiceAccount 中运行。相反，这些代理都是直接在 kagent 的运行时环境中被执行的。这是一种最简单的架构：一个运行时环境可以容纳多个代理。
随着代理数量的增加，一些问题开始浮现出来：
- 如何将一种代理与另一种区分开来呢？
- 每个代理是如何获得自己独特身份的？
- 该如何执行访问和网络相关策略？
- 该如何理解某个代理体正在做什么？
- 谁拥有代理程序？我们又该如何实现多租户支持？
第二阶段：让每个代理都在各自的 Pod、Service 和 ServiceAccount 中运行
Pod 实现了进程和容器的隔离。ServiceAccount 为每个代理节点提供了独立的 Kubernetes 身份标识，从而便于我们与各种认证和授权机制进行无缝集成。现有的网络策略、准入策略以及安全控制措施均无需修改即可继续使用。可观测性系统能够将日志、指标和追踪信息与各个代理节点关联起来。调度和资源管理功能也完全成为了 Kubernetes 的原生功能。
随着架构的不断发展，我们在 kagent 中引入了更强大的隔离机制，比如代理沙箱机制。这些机制确保了各个代理能够在严格的安全边界内运行。
思考把代理视为“Pod”来表示是否合适呢？
越深入地思考“代理”这一概念，就越意识到它们与传统微服务有着本质上的不同。预计大多数服务都能持续正常使用。代理则不是。代理只有在被分配任务时才会被激活，执行完任务后又会立即进入闲置状态。为每个潜在的代理都维持一个独立的运行环境，显然是一种浪费资源的做法。
代理程序的执行方式也不同于那些需要长时间运行的服务：
- 代理可以动态地创建多个子代理，以便并行执行某些子任务。
- 代理可以假冒用户的身份来行事，或者代表人类来执行各种操作。
- 在等待人工审批之前，代理可以暂停操作，等待进一步的指示。
- 一个代理的生命周期可能以秒或分钟来计算，而非天数。
这些特征自然引出了一个问题：Kubernetes Pod 是否适合用于那些生命周期短暂、使用频率不高的 AI 智能体呢？
agent-substrate
agent-substrate 是一个运行在 Kubernetes 之上的 Agent 生命周期与调度层，用来把大量逻辑 Agent 调度到较少的执行 Worker 上。
agent-substrate 并没有将每个智能体都视为 Kubernetes 中的“一级工作负载”。相反，它在 Kubernetes 之上增加了额外的控制层。Kubernetes 继续负责管理 Pods、服务、网络、存储和计算资源，而 agent-substrate 则负责管理 AI 智能体的生命周期以及它们在各个执行节点上的分配。
Agent-substrate 引入了一组抽象概念，这些概念与我们已经熟悉的 Kubernetes 概念类似。WorkerPool 相当于 NodePool，Workers 则相当于 Nodes，而 ActorTemplates 则对应于 Pod 的声明式定义方式。Actor 是逻辑代理实例。
Worker 和 Actor 不是 Kubernetes 中的一等 CR 资源。Kubernetes 只看到 WorkerPool 和 ActorTemplate。agent-substrate 自己看到 Workers 和 Actors。每个 Worker 映射到一个唯一 Pod，但 Actor 不再直接表示为 Pod。
换句话说，Pods 充当了执行任务的“工人”，而非用于部署各种代理程序的机制。
agent-substrate 挑战的不只是部署模型，还包括 identity、security、policy、ownership、multi-tenancy 和 observability。
4. EKS Kubernetes 中的自愈型 GPU 节点
Self-healing GPU nodes in Kubernetes: What we learned building the EKS node monitoring agent
背景
当像我们在 Amazon EKS 上那样大规模运行 Kubernetes 时，节点经常出现故障。GPU 会从 PCIe 总线上脱落。容器运行时也会出现各种问题。网络接口也会失效。在成千上万个集群中，这种“偶发”的硬件故障每天都会在某个地方发生多次。
开发了 EKS 节点监控代理，旨在弥补这一缺陷。该代理已于今年 4 月被开源。它能检测节点故障，并将相关信息以 Kubernetes NodeConditions 的形式发送给 Karpenter。Karpenter 随后会自动处理这些故障，必要时会更换出现问题的节点。
Amazon EKS Auto Mode 功能
该功能可完全自动化 Kubernetes 集群的基础设施管理：包括计算资源的分配、扩展、网络配置、存储管理、操作系统补丁更新以及安全加固等。这样一来，团队就可以专注于应用程序的开发，而无需操心集群的运营管理。该功能会自动选择最合适的 EC2 实例（包括 P5、P6 和 G6 系列等带有 GPU 的实例），根据工作负载需求进行扩展或缩减，整合那些利用率较低的节点，同时确保操作系统始终处于最新补丁状态。作为默认设置，EKS Auto Mode 还具备自动节点修复功能：从检测、严重程度评估到节点替换，整个过程都无需额外配置或安装任何插件。
6 个经验教训
- 代码规范其实是一种 API 契约。所有的下游系统（比如维修控制模块、仪表盘、客户自动化系统等）都是通过字符串匹配来遵循这些规范的。新增功能属于正常更新；而重命名或严重程度的变更则属于破坏性变更。应对这类变更的方式，应与处理 API 版本升级的方式相同。
- “不存在”和“未知”是两回事。“我们没有在监控”与“我们在监控但无法确定情况”需要不同的处理方式。如果某个被禁用的监控设备报告了“未知”状态，那么总会有某个控制器对此作出反应。当没有进行监控时，就不需要发送任何信号。
- 不要跨越所有权边界。Kubelet 负责处理由工作负载引发的各种问题。而节点健康检测机制则负责处理与硬件和基础设施相关的故障。如果跨越了这一边界，那么你的修复系统就会与 Kubelet 的驱逐机制发生冲突，最终必然会导致错误的决策。
- 需要测量从源头到目标的延迟时间。检测的 SLO 涵盖了信号传输过程中的每一个环节：从硬件事件到驱动程序日志的记录、从驱动程序日志到日志系统的传输、从日志系统到代理程序的同步、以及从代理程序到 NodeCondition 的写入操作。其中，最长的延迟环节会决定整体延迟水平。对于内核级别的信号传输，日志系统的刷新频率是制约因素。而对于通过 DCGM 进行的 GPU 遥测，基于推送方式的检测几乎可以即时完成；而基于轮询方式的检测则至少需要 5 分钟才能完成。因此，需要明确每种检测方式所经过的路径。
- 检测和诊断是两个独立的系统，各自有各自的用途。检测的结果用于自动化处理（速度快、连续性强、所需数据量少）；而诊断的结果则供人类参考使用（按需提供、信息详细、所需数据量较大）。将两者混为一谈只会降低两者的效率。
- 在测试过程中，应依据技术规格来解读遥测数据，而非依赖实际测量得到的数值。硬件上的遥测接口并非采用布尔逻辑来处理数据。我们通过读取 DCGM 位字段来判断 GPU 的运行状态：将非零值视为故障信号。当驱动程序更新后，正常的返回值从 0 变成了符合技术规格的非零值，结果所有 GPU 节点都被标记为故障状态。不过，由于设计上的原因，安全机制会自动启动，这为我们提供了时间来修复问题。这个教训是：如果要从 GPU 固件中解析各种枚举值或位字段，那么测试参数必须依据供应商提供的文档来确定，而不能根据之前该硬件实际返回的值来决定。
具体细节
见原文。
5. EKS 支持对所有的 request and response 都进行完整的日志记录
Full request and response compliance logging on Amazon EKS
背景
在 Amazon Elastic Kubernetes Service（Amazon EKS）中，合规性记录功能在最需要发挥作用的时刻却暴露出了最大的缺陷。审计人员需要查看交易背后的实际请求和响应数据，而不仅仅是与这些交易相关的元数据。想象一下，如果安全团队需要查看上周二所有涉及患者健康记录的 API 交易记录，他们打开可观测性控制台后，只能看到 HTTP 状态码、延迟指标和请求次数。但审计人员会表示不满，因为他们需要查看实际传输的数据。
这就是许多在 Amazon EKS 上运行微服务的企业目前所面临的合规性难题。像 Istio 这样的服务网格和 Envoy 这样的代理工具虽然能够很好地记录元数据、状态码、请求头信息以及延迟数据，但却无法记录实际的请求和响应内容。而恰恰是这些数据，才是审计人员、监管机构和合规官员需要核查的信息。可惜，这些数据根本没有被记录下来。
场景
传统的可观测性工具旨在回答“发生了什么？”这类问题。它们能告诉你有多少请求被发送、每个请求的处理时间，以及请求是否成功。但合规性要求我们回答另一个问题：“实际的数据是什么？”
让我们来看看几个需要考虑的情景。例如，金融服务机构必须证明，在每一次通过 API 进行的交易中，敏感的持卡人数据都得到了妥善处理；而医疗保健机构则必须提供详细的审计记录，以证明在各项服务之间究竟交换了哪些受保护的医疗信息。同样，接受审计的企业也需要证明，敏感数据得到了妥善处理，且没有未经授权的数据泄露出网络。
在每种情况下，仅靠元数据都是不够的。只有对所有的请求和响应进行完整记录，才能真正实现可观测性与可审计性之间的平衡。
完整记录的方法
各组织试图实现完整的请求与响应记录的方式有多种，但每种方式都伴随着一定的权衡和妥协：
- 应用层日志记录：将日志记录功能直接嵌入到每个微服务中。这种方法起初可行，但会导致数十甚至数百个服务中都存在重复的代码、实现方式不统一的问题。此外，随着新服务的不断增加，维护工作量也会随之增加。同时，合规性相关的逻辑也会分散在各个团队和代码库中。
- 自定义 Envoy 过滤器（C++）：虽然通过 C++编写自定义 Envoy 过滤器可以带来完全的控制权，但这就需要将代码编译到 Envoy 的代码库中，同时还需要维护相应的构建流程。此外，还需要找到精通 C++以及 Envoy 内部机制的工程师来协助开发。对大多数机构来说，这种方式并不实用。
- Envoy 中的 Lua 脚本：虽然是一种较为轻量级的解决方案，但随着业务逻辑的复杂化，Lua 脚本的维护、测试和扩展都会变得十分困难。此外，Lua 脚本还缺乏主流编程语言所具备的生态系统支持及调试工具。
- 具备日志记录功能的专用 API 网关：虽然有些 API 网关具备请求和响应的日志记录功能，但添加这一功能会带来延迟、成本增加以及运营上的复杂性。此外，这类网关可能难以与现有的服务网格顺利集成。
EKS 的选择
EKS 利用 Envoy 的“外部处理”过滤器（ext_proc）来解决这一难题。
这种方法的几大显著优势：
- 集中的合规性管理机制：在单一位置即可对所有服务中的请求和响应记录进行收集、审计及管理。
- 无需修改任何应用程序代码：各项服务保持不变。所有日志记录都在代理层自动完成。
- 选择性捕获：仅记录那些对合规性要求较高的端点的完整请求和响应数据，而忽略其他端点。
- 数据编辑功能：在数据进入日志记录系统之前，可以屏蔽或删除其中的敏感信息，比如个人身份信息、健康信息以及信用卡相关数据。这样一来，原本属于数据治理方面的风险，就能被转化为有效的控制措施。
架构图：
架构流程：
- 客户端发起 HTTPS 请求，DNS 指向部署在 VPC public subnets 中的 Network Load Balancer。
- NLB 将流量转发到 EKS 集群内的 Istio Ingress Gateway。
- Istio Ingress Gateway 根据 Gateway 和 VirtualService 把请求路由到目标应用 Pod。
- 应用 Pod 中自动注入的 Envoy sidecar 接收流量。
- Envoy sidecar 为每个 HTTP 请求打开一个独立双向 gRPC stream，连接到 ext_proc server。
- Envoy 分阶段发送 request headers、request body，并等待 ext_proc server 返回 CONTINUE 后才把请求发给应用容器。
- 应用处理请求并返回响应。
- Envoy 再把 response headers、response body 发送给 ext_proc server。
- ext_proc server 将 request headers、request body、response headers、response body 合并为一条 audit log，并用 x-request-id 关联为同一笔交易。
具体技术细节见原文。
6. 为 Kubernetes 构建自定义的指标导出工具
Building a Custom Metrics Exporter for Kubernetes
背景
Kubernetes 本身就具备对 CPU 和内存使用情况的监控功能，但大多数实际的扩展决策其实取决于那些无法通过 Kubernetes 内置功能直接获取的指标：队列中还有多少消息等待处理、上一次批量处理任务花了多长时间、该 Pod 当前有多少个活跃的 WebSocket 连接。当 Kubernetes 内置的指标不够用时，就需要借助外部指标收集工具来弥补这一不足。
metrics exporter 的作用
metrics exporter 其实是一个简单的 HTTP 服务器，它的唯一功能就是将应用程序的状态以文本形式展示在某个 /metrics 端点上。Prometheus 会定期从该端点获取数据，将这些时间序列数据存储起来，以便后续用于查询、警报生成以及自动扩缩容等操作。
在某些情况下，你可以直接在应用程序中实现相关功能——即嵌入 Prometheus 客户端库，并在同一进程中暴露相关接口——而无需单独运行导出器。不过，当数据源位于应用程序外部，或者你无法控制应用程序的代码时，使用独立的 metrics exporter 会更为合适。
Prometheus 所期望的格式是纯文本形式：每行表示一个指标，包括该指标的名称、可选的标签以及数值。客户端库会负责数据的序列化处理，因此实际上你只需决定要监控哪些指标，当这些指标的数值发生变化时，再调用相应的函数即可。
Prometheus 的数据模型
在编写任何代码之前，先确定自己所处理的信号类型是很重要的。Prometheus 的数据模型主要有三种类型：
- 计数器只会不断增加。它们是用来统计各种总量的理想工具：比如已处理的请求数量、已完成的任务数量、出现的错误数量等。绝对不要用计数器来记录可能会减少的数值。
- 这些指标反映的是某个数值的当前状态，而该数值可能会随时上升或下降。队列长度、活跃连接数以及缓存大小都属于此类指标。
- 直方图用于记录各种观测值的分布情况，比如请求延迟。利用直方图，我们可以计算出百分位数（如 p99、p50），而不仅仅是平均值。
制作步骤
见原文。
7. 虚拟机与 VKS 的内存分层管理：更高的部署灵活性、更智能的整合方式、更高效的资源利用
简介
- VKS：VKS 是一种符合 Cloud Native Computing Foundation (CNCF)标准的 Kubernetes 发行版。它运行在 vSphere Supervisor 之上。vSphere Supervisor 是嵌入在每个 vSphere 集群中的 Kubernetes 控制平面组件。正是由于有了 vSphere Supervisor，VKS 才能将上游的 Kubernetes 集群视为 VCF 中的普通对象来加以管理。
- 内存分层：vSphere 管理着一个分层式内存池，该内存池将高速的 DRAM 与辅助存储层结合在一起。辅助存储层通常是基于 NVMe 的存储设备，被配置为内存的扩展部分。管理程序会根据数据的访问频率，自动处理内存页面在各个层级之间的移动。那些经常被访问的数据会保留在 DRAM 中；而那些不常被访问的数据则会被转移到辅助存储层。如果某个被转移到辅助存储层的数据再次被访问，它就会重新被调回到 DRAM 中。整个过程都在客户操作系统、Kubernetes 节点虚拟机以及容器运行时之下进行。管理程序之上的一切组件都不需要知道这一过程的存在。
无需安装任何驱动程序，也无需调整内核参数或修改任何应用程序。无论是在虚拟机、Kubernetes 容器还是微服务中，所有工作负载都共享同一个连续的内存地址空间。对于 VKS 而言，这意味着平台团队无需再为容器化工作负载单独管理内存分配。只需在集群层面进行一次配置，VKS 就会自动继承该配置。
测试数据
我们测试了不同的 HammerDB 参数，以了解 VKS 工作负载如何从内存分层技术中获益。在这些测试中，虽然参数有所不同，但我们都遵循了内存分层的最佳实践，确保了活跃内存的使用量始终低于 DRAM 容量的 50%。有关内存分层技术的详细信息，请参阅相关白皮书。下图显示，通过使用内存分层技术，我们的 VKS 工作负载在仅使用一半 DRAM 容量的情况下，仍能实现接近 100%的基准吞吐量。这无疑体现了内存分层技术在降低基础设施成本方面的巨大优势。
具体见原文。
8. Controller-runtime 缓存是如何工作的
简介
controller-runtime：Kubernetes Operator / Controller 开发中常用的 Go 框架，提供 Manager、Client、Cache、Reconciler、webhook、健康检查等基础能力。很多基于 Kubebuilder 或 Operator SDK 的控制器都使用它。
核心观点
controller-runtime 的 cache 不是一个可有可无的性能优化，而是 controller 的默认工作模型。大多数 Get 和 List 并不会直接请求 API Server，而是读本地已经预热并持续更新的内存快照；写操作则直接发给 API Server。这个设计让控制器不会因为频繁 reconcile 把 API Server 打爆。
具体技术细节见原文。
📄 专题五 报告查看与分析
1. [Open Source Initiative] 2025 年度报告
简介
开放源代码促进会（Open Source Initiative，缩写：OSI），又译作开放源代码组织，是一个旨在推动开源软件发展的非盈利组织。
1998年2月，OSI由布鲁斯·斐伦斯及埃里克·斯蒂芬·雷蒙等人创立，启发于当时网景公司为了与微软的IE浏览器竞争，将他们的旗舰产品网景浏览器发布成自由软件。
许可与法律事宜
- OSI 的许可审批流程批准并审议了若干份重要的申请：
- 通过批准 OSC 许可证，OSI 解决了 MIT 许可证在跨境法律适用方面的不确定性。
- CDDL（通用开发与分发许可证）的修订版。
- 许可委员会和各方人士共同讨论了 ModelGo 许可协议。这是一种借鉴知识共享协议的许可框架，专为人工智能模型而设计。
- 2025 年最受欢迎的开源许可证（浏览量最高）：
- MIT 许可证（150 万次）
- Apache 2.0 许可证（34.4 万次）
- BSD 3-Clause 许可证（21.4 万次）
- BSD 2-Clause 许可证（12.8 万次）
- GPL 2.0 许可证（7.6 万次）
- GPL 3.0 许可证（5.5 万次）
- OSI Approved Licenses® 的新 API 接口。
- OSI 与 GitHub 的“安全开源计划”合作，将 ClearlyDefined 项目中的核心组件 ScanCode 纳入了该计划的首批受益项目之中。
政策与标准
OSI 在全球、欧洲和美国都加强了政策与标准的讨论参与。
研究与推广工作
OSI 正在召集全球各地的专家，共同制定一套通用原则，从而让人工智能领域的开发者能够再次实现那种无需额外许可、高效且简单的协作方式。
媒体报道
2025 年，OSI 的研究成果被《The Verge》、《TechCrunch》、《ZDNET》、《InfoWorld》、《Ars Technica》、《The New Stack》、《Forbes》、《Nature》以及《中国日报》等知名科技与政策类媒体广泛报道。
2025 年全年，OSI 积极参与了世界各地的各种活动，旨在向不同受众和社区传递相关信息并与其进行互动。OSI 的工作人员和代表还以专家身份参加了 ETSI 及 CEN/CENELEC 举办的众多 CRA 标准相关会议。
财务状况
OSI 2025 年收入下降到 66.7 万美元，低于 2024 年的 109.1 万美元，主要受技术赞助收缩、执行董事交接期间运营节奏变化和 grant funding 减少影响。全年支出为 112.9 万美元，净亏损 46.2 万美元。
在各项支出中，与政策和标准相关的费用占了近 60%。法律与专业服务费用增加了 30%。
截至 2025 年底，OSI 拥有 43.2 万美元的现金及现金等价物，足以满足 2026 年的各项业务需求。
关于 2026
2026 年，OSI 将继续完善开源人工智能的定义。随着美国和欧洲的相关监管框架的最终确定并开始实施，OSI 会继续与这些地区的政策制定者保持沟通。同时，OSI 还将通过“开放政策联盟”等倡议来加强合作，并推进“开放技术研究”项目，从而为开源政策的制定提供有力的证据支持。确保这些工作的财务可持续性也是 OSI 的重要任务。
💁♀️ 专题六 产品/方案介绍
1. KitOps：适用于 AI/ML 项目的打包与版本管理方案
简介
KitOps 是 CNCF 旗下的开源工具，用于 AI/ML 项目的打包、版本管理以及安全共享。
KitOps 基于与容器技术相同的 OCI（开放容器倡议）技术。它将模型在开发或生产过程中所需的一切元素，都打包成一个经过版本控制的、分层结构的文件，这些文件会被存储在现有的容器注册表中。KitOps 可以与所有 AI/ML 工具、CI/CD 工具以及 DevOps 工具进行集成。
作为 Kubernetes AI/ML 技术栈的一部分，KitOps 是那些需要自行托管 AI 模型和智能代理的安全意识较强的企业、政府机构和云服务提供商在打包、版本控制及管理 AI 资产方面的理想解决方案。
使用场景
- 生产交接
- 模型安全
- 完整的生命周期版本控制
使用角色
- DevOps 与平台工程师
- 数据科学家
- 开发者
2. Cozystack：用于构建云服务的免费平台和框架
简介
Cozystack 是一个用于构建云服务的免费平台和框架。Cozystack 是一个属于 CNCF Sandbox 级别的项目，最初由Ænix 公司开发并资助。
使用 Cozystack，你可以轻松地将多台服务器整合成一个智能系统。该平台通过简单的 REST API，能够帮助用户轻松创建 Kubernetes 集群、数据库即服务、虚拟机、负载均衡器、HTTP 缓存服务等各种功能。
使用场景
- 使用 Cozystack 构建公有云
- 使用 Cozystack 构建私有云
- 将 Cozystack 作为 Kubernetes 发行版来使用
3. Hyperlight：轻量级的虚拟机管理程序
简介
Hyperlight 是一种轻量级的虚拟机管理程序，能够在微型虚拟机中运行不可信的代码，且几乎不产生额外开销。这是一个属于云原生计算基金会的沙箱项目。
Hyperlight 允许你在由管理程序隔离的微型虚拟机中安全地运行不可信的代码。这些虚拟机可以在几毫秒内启动，而其中的函数调用则可在几微秒内完成。你只需将 Hyperlight 作为库嵌入到 Rust 应用程序中，再传递相应的二进制文件给虚拟机，然后就可以像调用本地函数一样轻松地调用虚拟机中的函数。为了最大限度地减少启动时间和内存占用，Hyperlight 不使用任何虚拟机内核或操作系统。所有的虚拟机都是利用 Hyperlight 库专门构建的。
- 支持 KVM、MSHV 和 Windows 虚拟化平台。
- 虚拟机中不包含内核或操作系统。其中的 guest 程序都是用 Rust 或 C 语言编写的普通 ELF 二进制文件。
- host 和 guest 通过输入的函数调用来进行通信。
- 默认情况下，guest 被隔离在独立的沙箱环境中，无法访问宿主计算机的文件系统、网络等资源。
友商对比
见 How is Hyperlight Different?
🤔 专题七 有意思的事与 Meme
1. 100 多个 Kubernetes 实战练习
100+ Hands-On Kubernetes Problems
RT
2. Cloudflare 希望打造人工智能网络的经济基础架构
Cloudflare wants to build the economic layer of the AI web
Cloudflare 可以提供 CDN、安全防护、反向代理、边缘计算等互联网基础设施服务的公司。因为大量网站流量会经过 Cloudflare，它天然处在网站、爬虫、搜索引擎和 AI 公司之间。
在谷歌的 AI 功能帮助下，那些曾经占据搜索结果首页的网页内容，现在都被摘要所取代。读者无需点击就能获得所需信息。因此，大量的流量就此流失。
一年前，Cloudflare 的立场基本上是防御性的，主张网站所有者应该有权阻止人工智能爬虫的访问。虽然这一观点至今仍然成立，但该公司现在转而致力于为“代理经济”打造相应的基础设施。这其实很有道理。既然人工智能已经能够在网络上浏览、收集信息，甚至在某些情况下进行购买，那么就必须有人来处理与这些网站相关的商业事务。Cloudflare 认为，这个角色应该由 Cloudflare 来承担。
大约一年前，Cloudflare 推出了“按爬取次数计费”的模式，允许出版商自行设定 AI 公司在获取页面内容时所需支付的费用。现在，该公司正致力于推出“按使用次数计费”的模式，也就是说，只有当出版商的内容真正被 AI 系统用于生成答案时，他们才能获得报酬。根据内容本身的价值来收费。这种模式更类似于联盟营销或许可协议的方式。不过，要实现这种模式则困难得多。因为需要确定是哪些内容促成了某个结果的产生，而这需要一个完善的归因机制，而目前这样的机制还远远没有建立起来。
Cloudflare 希望人工智能公司不要把所有的爬虫都混为一谈。目前，大型人工智能公司的某个爬虫可能会同时被用于页面的搜索索引、模型训练以及各种其他任务。这样一来，网站所有者就无法针对不同的用途来分别决定是否允许该爬虫使用自己的网站了。
从 9 月 15 日开始，Cloudflare 计划更改新网站和免费用户网站的默认设置。虽然 AI 搜索功能仍然可用，但在那些以广告为盈利方式的网站上，除非网站所有者主动启用该功能，否则 AI 搜索的训练和相关操作将被禁止。那些拒绝分离不同类型流量的爬虫也将被完全禁止使用。Cloudflare 指出，谷歌的捆绑式服务模式使其能够获取的内容量几乎是那些以人工智能为技术基础的竞争对手的两倍。在出版商和人工智能公司之间建立有效的合作关系，就必须先区分出各种爬虫的意图。因为如果网站所有者无法区分“将我的页面收录到搜索结果中”和“利用我的内容来训练你的模型”这两种需求，他们就只能选择屏蔽所有来自爬虫的请求了。
如果人工智能成为人们在线获取信息的主要方式，那么 Cloudflare 认为，下一场竞争不会取决于谁能够构建出最智能的模型，而将取决于谁能够建立起其他人所依赖的基础设施。
3. “只需计算一次”：Clockwork 如何解决 AI 训练过程中反复重启的问题
“You Only Compute Once”: How Clockwork wants to put an end to AI training restarts
背景
在规模足够大的 GPU 集群上，总会有某些部件出现故障。这就是现实情况。标准的解决方式是回滚到上一个检查点，然后重新计算从那个点之后的所有数据。不过，这种方式既耗时又昂贵。https://clockwork.io/ 希望彻底消除这种麻烦。
在大规模应用中，系统故障并非罕见现象。Meta 公司的 FAIR 团队所做的研究显示：在拥有 1,024 个 GPU 的集群中，系统平均故障时间为 7.9 小时；而当 GPU 数量增加到 16,384 个时，这一时间则降至 1.8 小时。Clockwork 公司指出，这意味着 GPU 集群的实际运行效率仅为理论值的 30%到 50%。不过，该团队认为，硬件并非真正的瓶颈，真正的瓶颈在于相关的可靠性模型——这些模型假设系统故障的发生率远低于实际情况。
据 Clockwork 的估算，在典型的 2,048 个 GPU 组成的 H200 系统中，由于系统故障而导致的重启现象，每年会浪费超过 600 万美元的计算资源。
Clockwork 做法
Clockwork 能够防止训练过程因故障而中断，这一功能的实现依赖于 TorchPass——Clockwork 的容错技术。TorchPass 已于 3 月正式投入使用。当某个 GPU 或整个节点发生故障时，TorchPass 会将训练过程中存储在内存中的所有数据，包括模型权重、梯度以及优化器状态，转移到另一台正常的 GPU 上——或者转移到正在执行低优先级任务的 GPU 上。这样一来，训练过程就能继续进行下去，通常只需几分钟就能恢复正常状态。
最近，该公司推出了“YOCO 保障”服务。所谓“YOCO”，即“You Only Compute Once”。该公司承诺：在所有受支持的训练过程中，90%的故障都能得到解决，用户无需重新开始计算、恢复之前的进度或重新创建检查点。如果 Clockwork 公司在某个合同年度内未能履行承诺，客户可以享受 25%的折扣，用于下一次的续订或扩展服务。
TorchPass 通过在实际任务仍在运行时将其转移来规避这些回滚操作。“从宏观上讲，我可以把它想象成类似 vMotion 的技术，只不过这里处理的是 GPU 相关的任务，所以可以称之为‘gMotion’吧，”
TorchPass 的两种模式
两种模式的主要区别在于：每种模式下需要移动的状态量有多大，以及因此而决定的恢复速度有多快。
- 快速处理方式是“模型感知型”的。只需添加几行代码即可。这样一来，TorchPass 就能准确知道该获取哪些数据，从而减少数据传输量，使恢复过程在几十秒内完成。
- “模型透明型”方式。使用这种方式时，训练团队无需对训练代码进行任何修改。TorchPass 可以直接获取系统层面的快照。这种方式使用起来更简单，但相应地，它需要传输更多的数据，恢复过程也需要几分钟时间。
局限性
“如果整个网络都瘫痪了，那就毫无办法了，就像停电一样——谁也无可奈何。”
目标客户
该解决方案不适合 Anthropic、OpenAI 或谷歌这类已具备强大自研能力的公司。适合缺乏顶级 AI 实验室工程能力、但希望获得高水平抗灾能力的机构，包括 AI 初创企业、传统企业、量化分析机构和生物技术研究机构。
4. 价值 130 万美元的盗窃案暴露了人工智能的缺陷
The $1.3 million theft that exposed AI’s blind spot
前不久，库克县治安官办公室找回了两辆被偷的拖车。这些拖车上装有价值约 130 万美元的数据中心设备与铜线。这些物品都是从数百英里外分别被偷走的。其中一辆拖车上装有价值约 30 万美元的铜线，这些铜线原本是来自阿拉巴马州派恩希尔的，是用来建造数据中心的。另一辆拖车上则装有价值约 100 万美元的数据中心基础设施设备，这些设备是从佛罗里达州杰克逊维尔被偷走的。最终，这两辆拖车都被送到了芝加哥郊外的埃尔克格罗夫镇的同一个卡车场。
从人工智能发展的背景来看，这表明，物理供应链本身正成为不良分子的新目标。
我们都很清楚那些典型的瓶颈问题：比如 GPU 供应不足、电力供应受限以及冷却能力不足。这些问题从人工智能时代诞生之初就一直存在。但我们往往忽视了，建设人工智能数据中心需要大量专业硬件，而这些硬件都需要通过货运网络进行运输。这些硬件包括服务器、网络设备、光纤、交换机、冷却系统、电力分配设备，还有成千上万磅的铜材。所有这些都需要投入大量资金，同时也可能导致项目的延迟。
基础设施的韧性在很大程度上取决于关键硬件能否按时送达施工现场。据 Verisk CargoNet 的报告，2025 年，美国和加拿大的货物盗窃损失增加了约 60%，达到了近 7.25 亿美元。尽管盗窃事件的总数基本保持不变，但这表明窃贼们开始更倾向于盗窃高价值的货物。金属盗窃案件增加了 77%，其主要原因是对铜的需求增加；而有组织的犯罪团伙则将目标转向了企业级计算硬件。CargoNet 预计，这种对高价值技术的盗窃行为将在 2026 年继续存在。作为参考，美国国土安全部估计，货物盗窃每年造成的损失高达 350 亿美元。
5. 2026 年上半年，人工智能领域发生的 10 件重要事件
10 moments that defined AI’s turbulent first half of 2026
10. 特朗普总统关于人工智能的行政命令
2026 年 6 月 2 日，特朗普签署了一项行政命令，旨在加强美国各系统对与人工智能相关的威胁的防御能力，同时反对“过于繁琐的监管”。该命令要求国家系统安全委员会将网络防御作为重点任务，并责成财政部、国家安全局和网络与信息系统局建立人工智能安全信息共享机制，以协调对关键基础设施的漏洞检测和修复工作。该政府在推动人工智能发展的同时，也强调以国家安全为前提的适当监管。
9. 人工智能基础设施的建设
2026 年，芯片制造商和人工智能研究机构加强了合作，以跟上各种新模型的推出节奏。此外，还出现了几项重大合作：英伟达与 SK 海力士建立了长期合作伙伴关系，涵盖了 Vera Rubin 超级计算机、Vera CPU 以及下一代存储器等领域。与此同时，全球数据中心的容量也在不断扩大。这些发展表明，计算能力、能源供应和硬件条件已成为人工智能发展的瓶颈。
8. harness 的兴起
各基础模型的性能在各项测试中相差无几时，所谓的“harness”就成为了决定性因素。所谓“harness”，其实就是围绕模型而存在的各种工具、内存管理机制、协调机制以及安全保障措施。它决定了模型能否正常执行任务、能否从错误中恢复过来，以及能否安全地运行。可以说，“harness”将竞争优势从模型本身的能力转移到了系统设计上。
7. 代币经济模型
在当前环境下，成本控制已成为人工智能领域中，无论是生产者还是消费者都需要重点关注的环节。各人工智能实验室正在调整定价方式，不再采用固定的订阅模式，而是根据计算资源的实际使用量来收费。同时，各企业也在寻求各种方法来降低与人工智能相关的成本。上个月，Linux 基金会得到了谷歌、微软、IBM、摩根大通、普华永道、甲骨文和 Salesforce 等公司的支持，共同成立了“Tokenomics 基金会”。该基金会的任务是制定整个人工智能领域的开放标准、基准和最佳实践。
6. Agentic AI 正在成为主流技术
一年前，各种智能代理还只是概念验证阶段的产物，无法在实际应用中可靠地发挥作用。到了 2026 年，它们已经变成了不可或缺的基础设施。例如，ChatGPT 的浏览功能、Claude 的工具使用能力以及多步骤编程功能，还有 Google 的自主信息处理功能，现在都可以在后台持续运行，而无需人工指令。与此同时，各企业也开始将智能代理应用到监控、代码审查、采购和客户支持等实际工作中。不过，随着智能代理能够访问各种数据和系统，这种变革也可能带来安全风险。
5. 五角大楼与 Anthropic 开战了
2 月份，战争部长皮特·赫格塞斯将 Anthropic 的首席执行官达里奥·阿莫代叫到办公室，要求军方能够无限制地使用该公司的技术。但阿莫代坚决拒绝，不允许军方将 Anthropic 的技术用于对公民进行大规模监控或制造自主武器。此后，特朗普总统命令各联邦机构逐步停止使用 Anthropic 的技术。赫格塞斯还将该公司列为“供应链风险企业”——这一标签通常用于指代外国对手，实际上相当于禁止了该公司的业务运营。Anthropic 向联邦法院提起诉讼，称政府的举措毫无根据，属于报复行为。旧金山法院下达了初步禁令，认定政府的做法违反了宪法第一修正案的规定，属于报复行为。
4. 人工智能领域的巨头们在华尔街站稳了脚跟
5 月内的 72 小时内，Anthropic 和 OpenAI 都推出了面向企业的解决方案，宣布了与多家金融服务的合作，并推出了专为华尔街工作流程设计的工具。它们的核心理念都是一样的：下一代人工智能的发展重点不再是模型本身，而是如何将人工智能技术有效地应用到实际场景中。
Anthropic 的新业务部门得到了黑石集团、赫尔曼&弗里德曼公司、General Atlantic、Apollo、高盛和红杉资本的资助。该业务部门主要针对那些大型咨询公司和系统集成公司不愿涉足的中型企业。这些企业包括社区银行、地区性医疗系统以及中型制造企业。Anthropic 的 AI 工程师会与该业务部门自己的工程师一起直接与客户合作，共同开发定制化的解决方案，并为客户提供长期的支持。
OpenAI 的子公司“DeployCo”专注于服务大型企业，同样采用先进的工程模型来推动各项业务的开展。通过收购人工智能咨询公司 Tomoro，DeployCo 从一开始就拥有了约 150 名经验丰富的工程师。该公司还获得了超过 40 亿美元的投资支持，其合作伙伴包括麦肯锡、贝恩公司和凯捷等知名企业。
与此同时，这两家公司都在考虑进行首次公开募股，其估值都将超过 8000 亿美元。
这两家公司都押注于同一个观点：即“部署差距”——也就是前沿人工智能所能实现的功能与企业实际应用之间的差距——将是下一个巨大的商业机会。而且，这两家公司都在同一周内采取了行动。
3. 开放式权重模型即将问世
2026 年，中国的实验室在追赶西方前沿实验室方面取得了进一步进展。阿里巴巴的 Qwen、Zai 的 GLM 以及 Moonshot 的 Kimi 所推出的开源模型，在各项标准测试中的表现可与那些封闭式模型相媲美。6 月 13 日发布的 Zai 的 GLM-5.2 在某些测试指标上甚至超过了 Anthropic 的 Claude Opus 4.8，成为目前开源模型中的佼佼者。此外，GLM-5.2 的价格仅为同类封闭式模型的五分之一。
《The New Stack》的特约撰稿人保罗·索沃斯在本次排名中这样说道：“目前，那些采用开放式架构的预算友好型模型，在成本上已经可以与最先进的专用模型相媲美。这样一来，就没有必要再为那些封闭式的模型支付高昂的费用了。比如，就有初创公司放弃了 Anthropic，转而选择 DeepSeek。
事实上，欧洲的 AI 智能体初创公司 Lindy AI 将其所有的业务流量都从 Anthropic 转移到了 DeepSeek。该公司称，这样做节省了数百万美元的成本。
2. CEO 们亲自编写自己的工具程序
虽然软件开发者似乎已经完全接受了人工智能编程助手，但企业的管理层——也就是那些处于指挥链顶端的高管们——则利用这些工具来开发各种智能应用和提升工作效率。
OutSystems 的首席执行官伍德森·马丁在开展自己的“即兴编程”实验时采取了更为系统化的方法。他在团队开发的 MCP 服务基础上，开发了一个个人移动应用框架。他同时用两种方式来开发这个框架：一次使用 OutSystems 自己的 AI 编程工具 Mentor，另一次则使用 Claude。不过，这两种方式都连接到了同一个后端系统。
这款应用程序实际上是一个个人化的“参谋系统”。它将客户的各种信息——比如购买记录、网站活动数据、内部数据等——整合在一起，销售人员在开会前可以随时在手机上查看这些信息。这样一来，就无需再花费 45 分钟来制作 PPT，也不需要销售团队再召开各种准备工作会议了。
1. 政府对《Anthropic Fable 5》和《Mythos 5》采取了严厉打击措施（后来又有所放松）
“Fable/Mythos”项目的失败充分体现了人工智能领域的政策走向如今变得多么难以预测。2026 年 6 月 9 日，Anthropic 推出了其唯一的“Mythos”级模型“Fable 5”。不过，真正的“Mythos 5”版本则仅向少数被该公司视为“可靠客户”的用户提供，该项目被命名为“Project Glasswing”。该产品的测试仅持续了三天而已。
6 月 12 日，商务部长霍华德·卢特尼克向 Anthropic 的首席执行官达里奥·阿莫代发出指令，要求立即在全球范围内禁止所有外国公民使用该公司的这两款产品，其中包括 Anthropic 自身的非公民员工。
显然，引发这一问题的原因是亚马逊的研究人员发现了一个安全漏洞，该漏洞可能会暴露相关模型的网络安全功能。这一情况引起了商务部的担忧。Anthropic 表示，他们无法实时根据用户的国籍来限制访问权限，因此不得不在全球范围内暂停了 Fable 5 和 Mythos 5 的服务。在接下来的几周里，商务部允许一些经过政府批准的机构使用 Mythos 5，但该服务的全面恢复直到 6 月 30 日才实现——中间经历了 18 天的停滞期。
与此同时，Anthropic 为《Fable 5》增加了额外的网络安全措施，并于 7 月 1 日开始恢复全球用户的访问权限。
在谈到 Anthropic 与五角大楼之间的矛盾时，《The New Stack》的弗雷德里克·拉尔迪诺斯指出：“虽然这两起事件没有直接关联，但很难不将 Fable Controls 事件视为 Anthropic 与特朗普政府之间长期不和的延续。在某种程度上，这似乎也带有个人恩怨的成分。”
6. 《MAGNIFICA HUMANITAS / 伟大的人类》
简介
这份文档是教宗利奥十四世的首份通谕，于 2026 年 5 月 15 日签署、同月 25 日发布，旨在探讨在人工智能时代守护人的尊严。
好句摘抄
It now falls to us to face the challenges of our time with clarity of thought and responsibility. It is necessary to establish adequate regulatory tools capable of upholding justice and curbing the distorting effects of technological power. Nevertheless, the issue is not limited to regulation. As Pope Francis warned, we must realistically ask ourselves who holds this power today and how they use it: “It must also be recognized that nuclear energy, biotechnology, information technology, knowledge of our own DNA, and many other abilities which we have acquired… have given those with the knowledge, and especially the economic resources to use them, an impressive dominance over the whole of humanity and the entire world.” [7] In the past, it was largely up to the State to guide and direct innovation. Today, however, the main drivers of development are private, often transnational, parties that are endowed with resources and the capacity to intervene that surpass those of many Governments. Technological power thus takes on an unprecedented, predominantly “private” aspect, which makes it even more challenging to discern, govern and direct such power toward the common good.
现在轮到我们以清晰的思想和责任感，面对我们时代的挑战。必须建立适当的监管工具，以维护正义，并遏制技术权力所造成的扭曲影响。然而，问题并不限于监管。正如教宗方济各所警示的，我们必须现实地追问：今日谁掌握着这种权力，又如何使用它？“还必须承认，核能、生物技术、信息技术、关于我们自身 DNA 的知识，以及我们所获得的许多其他能力……已经使那些拥有相关知识、尤其是拥有运用这些知识所需经济资源的人，对整个人类和整个世界取得了惊人的支配力。”过去，引导和指导创新在很大程度上是国家的职责。然而，今日发展的主要推动者却是私人行为体，且往往是跨国行为体；他们拥有的资源和干预能力，超过许多政府。由此，技术权力呈现出一种前所未有的、主要属于“私人”的面貌，这使得分辨、治理并引导这种权力服务于共同善，变得更加艰巨。
For this reason it is necessary to begin a shared discernment process for identifying the spiritual and cultural roots of ongoing transformations. If we focus only on contingencies, we risk letting the succession of emergencies dictate the direction of our path. We are living through a rapid phase of transition, a “change of era,” in which — while some are vying for the future of new technologies and others dedicate themselves to reflecting on the matter — most people are watching and waiting, observing from afar and merely hoping for the best. For this very reason, crucial questions impose themselves on our conscience and can no longer be avoided: Where are we going? Toward what goal do we wish to orient ourselves? What direction should we choose as a people and as a human community?
因此，必须开启一个共同的分辨进程，以辨认当前种种转变背后的属灵与文化根源。若我们只关注偶发事件，就有可能让接连不断的紧急状况决定我们前行的方向。我们正经历一个快速的转型阶段，一个“时代的转变”：在这一阶段中，有些人正在争夺新技术的未来，有些人则致力于对此进行反思，而大多数人却只是观望和等待，远远地观察，并仅仅寄望于最好的结果。正因如此，一些关键问题已经迫使我们的良知作出回应，且再也无法回避：我们将走向何方？我们希望朝着什么目标调整自己的方向？作为一个民族、作为一个人类共同体，我们应当选择怎样的方向？
——
We must, then, avoid the “Babel syndrome,” namely the idolatry of profit that sacrifices the weak, a uniformity that neutralizes differences, and the pretense that a single language — even a digital one — can translate everything, including the mystery of the person, into data and performance. The risk of dehumanization — of building a future that excludes God and reduces the other to a means — is an ancient and ever-new temptation that today takes on a technical guise. Instead, let us choose the “way of Nehemiah,” which highlights the importance of working together to make the City of God a safe place for returning exiles. Rebuilding today means recognizing that, precisely from the plurality of voices and visions which, even though they sometimes remind us of the confusion caused by the diversity of spoken languages, a bright possibility emerges. Indeed, this is the possibility of building together, of transforming diversity into a resource and of making listening and dialogue the common ground upon which to cultivate justice and fraternity. Within this shared task, Christians discover their unique role of guiding actions toward God so that, in his light, pluralism does not dissipate into disorder, but instead, through the practice of synodality, it becomes the space in which humanity rediscovers its solid foundations and its final end. In the Book of Revelation, John sees the New Jerusalem “coming down out of heaven from God” (Rev 21:2) as a gift for all humanity. And this vision of grace is an invitation for us Christians to work together in order to foster a peaceful, just and dignified life in community within today’s “cities.”
因此，我们必须避免“巴别综合征”，也就是那种将利润偶像化、以牺牲弱小者为代价的倾向；避免那种消解差异的单一化；也要避免一种假象，即认为某一种语言，哪怕是数字语言，能够把一切，包括人的奥秘，都转译为数据和绩效。非人化的风险，也就是建造一个排除天主、并将他人贬为手段的未来，是一种古老而又常新的诱惑；而在今天，它披上了技术的外衣。相反，让我们选择“厄斯德拉之路”：这条道路强调共同协作的重要性，好使天主之城成为流亡者归来时的安全之所。今日的重建意味着承认，正是从声音与愿景的多元性中，尽管这种多元有时使我们想起不同口语所造成的混乱，却也显现出一种光明的可能性。事实上，这就是共同建设的可能性，是将差异转化为资源的可能性，也是使聆听与对话成为共同基础、以培育正义与兄弟情谊的可能性。在这项共同使命中，基督徒发现自己独特的角色：将行动引向天主，好使多元主义在祂的光照下不致消散为混乱，而是借着共议同行的实践，成为人类重新发现其坚实根基和终极归宿的空间。在《默示录》中，若望看见新耶路撒冷“由天主那里，从天降下”，成为赐予全人类的礼物。而这一恩宠的愿景，也邀请我们基督徒共同努力，在今日的“城市”中，促进和平、公义且有尊严的共同生活。
——
When we speak of dignity, we do not always use the word in the same way. Sometimes we refer to moral dignity, namely the way in which a person directs his or her choices and actions. At other times, we think of social dignity, which refers to a person’s living conditions and the concrete respect received from society. In other cases, we refer to existential dignity, meaning the way in which a person perceives his or her own worth and the value of life. These aspects of dignity can be enhanced or diminished. In addition to these notions, there is also the more profound and important level of ontological dignity. This is the dignity that belongs to every human being simply by virtue of existing, of having been willed, created and loved by God. [60] No sin, failure, humiliation or exclusion can diminish the profound value of a human life that God has willed and called into being.
当我们谈论尊严时，并不总是以同一种方式使用这个词。有时，我们指的是道德尊严，即一个人引导其选择与行动的方式。另一些时候，我们想到的是社会尊严，也就是一个人的生活条件，以及他从社会中实际获得的尊重。在其他情况下，我们所说的是存在尊严，意指一个人如何感知自身的价值以及生命的意义。这些尊严的不同层面可以被提升，也可以被削弱。除这些含义之外，还有一个更深刻且更重要的层面，即本体尊严。这是每一个人仅仅因其存在、因其为天主所愿、所造并所爱而拥有的尊严。任何罪恶、失败、羞辱或排斥，都不能削弱一个由天主所愿并召唤进入存在的人类生命所具有的深层价值。
🎤：
- 枯燥、重复。随便在开头摘两句，《ANTIQUA ET NOVA》还是更惊艳，这篇说教与工作指导意味过浓。
- 配合诗梳风的《EP23 何为理解 · Thoughts》，别有一番感受。