🆕 专题一 产品新功能/新版本
1. headlamp 0.43.0 版本已发布
重要新功能
- 新增基于 Cluster Inventory API 的 ClusterProfile 自动发现能力，可自动注册多集群，目前为 alpha。
- 新增 Deployment 创建表单、YAML 编辑器 Dry Run 校验、Rollback Dry Run 预览，以及工作负载批量扩缩容，资源操作更接近常用运维流程。
- 新增 Pod 和工作负载 Diagnostics 区域，可根据状态、事件和容器信息提供排障提示。Job 也新增专门详情页，支持查看运行状态和相关 Pod 日志。
重要改进
- 认证能力增强，in-cluster 部署支持可选 ServiceAccount Token 登录，也支持读取代理注入的认证 Header，便于接入 OIDC 或外部认证代理。
- 节点运维体验增强，新增托管节点升级进度视图，并在节点列表和详情中显示 node pool 信息。
- 本地化和平台支持扩展，新增俄语、孟加拉语和 RTL 语言布局支持，桌面端新增 Windows Arm64 构建。
- 稳定性和安全性方面，修复 OIDC、资源编辑、日志、端口转发、WebSocket、Electron 等问题，并为后端 HTTP server 增加超时配置，降低慢请求风险。
2. mariadb-operator 26.06 发布
mariadb-operator 以云原生的方式来运行和管理 MariaDB。利用 Kubernetes 的 CRD 来进行 MariaDB 的声明式管理，而无需使用命令行指令。MariaDB Server 是一个通用的开源关系数据库管理系统。
支持多集群架构
该功能允许您将数据分布在多个 Kubernetes 集群中，从而实现高可用性、灾难恢复以及无中断的蓝绿部署。
多集群功能通过在多个 MariaDB 集群之间复制数据来实现高可用性。该功能基于复制或 Galera 集群技术实现：其中一个集群充当主节点，其他集群则作为副本节点。每个集群都拥有自己的高可用性机制。
多集群架构可以通过两种方式来部署：
- 在多个 Kubernetes 集群中：每个 Kubernetes 集群都运行着一个拥有自己高可用性机制的 MariaDB 集群。这些集群通过远程复制方式相互连接，从而形成一个层级结构。其中，主集群负责处理所有的写操作，而副本集群则从主集群复制数据。这种方式既保证了每个集群内部的高可用性，也实现了跨集群的高可用性。因此，这种架构非常适合多区域部署和灾难恢复场景。
- 在同一个 Kubernetes 集群中：一个 Kubernetes 集群可以托管多个 MariaDB 集群，这些集群之间可以配置本地复制功能。这对于“蓝绿部署”模式非常有用：其中一个集群负责处理用户请求，而另一个集群则在后台进行更新。这样一来，就可以实现无中断的升级，同时避免数据丢失。
维护模式
维护模式允许用户安全地对 MariaDB 集群进行维护操作。启用维护模式后，用户可以详细控制数据库在维护期间的运行方式，包括阻止新连接、断开现有连接，以及将数据库设置为只读模式。这在多集群环境中的集群切换场景中特别有用：可以防止在将副本提升为主节点之前对主集群进行写入操作。此外，它还可以用于通过将数据库与应用程序流量隔离开来来进行调试，或者用于任何需要严格控制访问权限的操作任务。
维护模式支持三种可组合的模式：
- 封锁模式：通过将 Pod 从服务端点中移除，从而阻止所有新的连接。
- 连接断开处理：在经过可配置的延时时间后，优雅地终止那些仍在运行的连接。
- 只读模式：将数据库设置为只读状态，禁止一切写入操作，同时允许读取操作。
根密码定期更换
只需更新所引用的 Secret ，即可更改 MariaDB 资源的根密码。系统会自动处理整个更改过程：首先使用旧密码进行连接，然后发出 ALTER USER 命令来更新密码，最后在数据层面同步密码信息。这使得凭证的更换能够无缝进行，而不会造成任何停机时间。
Helm OCI charts
Helm OCI charts 现已通过 GitHub Container Registry 上的 OCI 注册表提供使用( ghcr.io )。从现在开始，这将是安装和管理 MariaDB 操作员的推荐方式。
📰 专题二 新闻与访谈
1. Inspektor Gadget 完成首次安全审计：未发现高危漏洞，所有问题均已修复
Inspektor Gadget 完成首次安全审计：未发现高危漏洞，所有问题均已修复
背景
近日，CNCF 项目 Inspektor Gadget 完成了首次独立安全审计。这次审计由 Open Source Technology Improvement Fund（OSTIF）协调，CNCF 资助，并由安全公司 Shielder 执行。审计结果、修复方案以及后续加固建议均已公开；所有报告中提到的漏洞，目前也都已经有可用补丁。
对于正在生产环境中使用 Inspektor Gadget 的团队来说，最重要的动作很明确：升级到 v0.50.1 或更高版本。
Inspektor Gadget 的工作方式决定了它需要较高权限。为了完成节点级别的观测，它会在节点上以 root 级权限运行。对于任何会在共享基础设施中以高权限运行的工具而言，安全性不能只依赖项目自己的判断。随着项目逐渐成熟、用户采用增加，引入独立第三方安全审计，是建立信任的关键一步。
简介
Inspektor Gadget 是一个基于 eBPF 的 Kubernetes 可观测性和 Linux 主机检查工具包。它可以在 Kubernetes 集群和 Linux 主机中收集、检查运行时数据，并通过所谓的 “gadget” 来完成具体观测任务。这里的 gadget 可以理解为被打包成 OCI 镜像的 eBPF 程序，能够像容器镜像一样被分发和运行。
审计结果
本次审计共发现 3 个漏洞。其中没有 Critical 或 High 级别漏洞，严重程度分布为：2 个 Medium，1 个 Low。
- ig image build 中存在命令注入风险，对应 CVE-2026-24905。已在 v0.48.1 中修复。
- 通过事件洪泛造成拒绝服务。已在 v0.50.1 中修复。
- columns 输出模式中未清理 ANSI 转义序列，对应 CVE-2026-25996。已在 v0.49.1 中修复。
2. Helm 3 End of Life
简介
Helm 3 即将进入生命周期的尾声。最后一次功能更新将于 2026 年 9 月 9 日进行，之后将不再有新的功能更新。不过，安全补丁的提供将持续到 2027 年 2 月 10 日。
随着 Helm 4 于 2025 年 11 月成功发布，其维护者和社区成员现在正致力于进一步提升 Helm 4 的功能。
Helm 4 的新功能
- 插件系统升级——现在提供了基于 WebAssembly 的插件运行时，提升了安全性。现有的插件仍然可以正常使用。Helm 4 中包含了三种类型的插件：CLI 插件、获取器插件和渲染后处理插件。此外，还提供了一个可扩展的系统，用于添加新的插件类型。
- 更出色的资源监控功能——通过与 kstatus 的集成，可以详细了解各项部署的进展情况。
- 多文档值——将相关值分散到多个 YAML 文件中，以便针对不同的环境进行配置。
- 服务器端应用方式——在新的版本发布时默认采用这种方式。对于现有的 Helm 3 版本进行升级时，则会自动切换到客户端应用方式。
- 自定义模板函数——通过插件来扩展 Helm 的模板功能。
- 稳定的 SDK API——与 API 相关的破坏性变更已经全部解决，现在可以开始 Charts v3 的开发工作了。
重大变动
- Post-renderer 现已转为插件形式 —— helm install --post-renderer 现在接收的是插件名称，而非可执行文件路径。请及时更新所有现有的后渲染器（post-renderer）工作流。
- 注册表登录作用域限定为域名 —— helm registry login 现在仅接受域名（不再支持完整 URL），以此支持未来实现按特定作用域（per-scope）进行精细化登录的功能。
- CLI 参数（Flags）重命名 —— --atomic 现已更名为 --rollback-on-failure，--force 现已更名为 --force-replace。旧参数目前仍可正常使用，但系统会打印弃用警告（deprecation warnings）。
迁移到 Helm 4
- 测试您的 Chart —— 在非生产环境中，使用 Helm 4 部署您现有的 Chart。
- 测试您的 CI/CD 流水线 —— 更新所有使用了重命名 CLI 参数的脚本（--atomic → --rollback-on-failure，--force → --force-replace）。
- 测试 post-renderer 工作流 —— 将所有 --post-renderer 的使用方式迁移至新的插件系统。
- 测试注册表（Registry）认证 —— 验证仅使用域名进行 helm registry login 的 OCI 工作流。
- 升级 —— Helm 4 可以直接管理现有的 Helm 3 Release，无需任何迁移步骤。
🔐 专题三 安全
💬 专题四 讨论与分享
1. 从 Kubernetes 控制面板到 Headlamp：了解这一转变过程
From Kubernetes Dashboard to Headlamp: Understanding the Transition
Kubernetes Dashboard 项目现已被归档。Headlamp 在原有基础上进行了改进和拓展。它保留了视觉界面的清晰性，同时新增了与当今 Kubernetes 使用方式相契合的功能。这些功能包括多集群监控、以应用为中心的视图展示、通过插件实现的可扩展性，以及适用于集群内和桌面环境的灵活部署方式。
将 Kubernetes 控制面板中的各项任务映射到 Headlamp 系统中
- 查看工作负载和资源情况
- 对资源的编辑与操作/与资源的交互
- 理解各种关系
Headlamp 在功能上如何超越 Kubernetes 控制面板
- 从单集群扩展到多集群的工作流程
- 从资源列表到与项目相关联的应用程序上下文
- 通过插件扩展 Headlamp UI
决定 Headlamp 的运行方式和运行地点
Headlamp 让团队在如何使用 Kubernetes 用户界面方面拥有更大的灵活性。你可以直接在集群中运行它，也可以将其作为桌面应用程序来使用。当然，你还可以根据实际需求，将这两种方式结合起来使用。
2. 用于不同产品的 Headlamp 插件
Cluster API
Introducing the Cluster API plugin for Headlamp
Cluster API（CAPI）是 Kubernetes 的一个子项目，它将 Kubernetes 风格的声明式 API 引入到集群的生命周期管理中。通过该 API，平台团队可以利用存储在管理集群中的标准 Kubernetes 对象来配置、升级及管理 Kubernetes 集群的整个生命周期。
过去，管理 Cluster API 资源需要使用复杂的命令行操作，同时还需要对各种所有权结构了如指掌。而 Headlamp Cluster API 插件则直接在 Headlamp 界面内提供了直观的可视化操作方式，大大提升了调试效率，简化了平台团队的操作流程。
功能：
- 集群概览
- 机器的可见性/机器能否被看到/机器的可视程度
- Cluster API dashboard
- 控制平面监控
- 从用户界面进行缩放操作
- 所属资源层次结构
- KubeadmConfig 检查
- 拓扑感知能力
- 地图视图
- 动态 API 版本控制
- Prometheus 指标
Volcano
Inspect Volcano workloads faster with Headlamp
Volcano 是一款专为 Kubernetes 设计的云原生批处理调度工具，非常适合用于高性能计算、人工智能/机器学习等需要批量处理的任务。
Kubernetes 最初是为那些需要长期运行的服务而设计的。在这种场景下，应用程序需要持续运行，不会中断。不过，批处理、人工智能/机器学习以及高性能计算类任务则有所不同：这些任务是动态生成的，它们会争夺有限的资源，而且往往需要多个任务同时启动后，才能开始执行实际的工作。Volcano 通过引入队列、优先级、配额以及分组调度等概念，对 Kubernetes 进行了扩展。它不会将每个 Pod 视为独立个体来处理，而是从整体上考虑各项任务及其所需的资源，从而来安排工作负载的调度。
为了使这些工作负载更易于管理和排除故障，Volcano 插件将相关的调度信息直接引入了 Headlamp 系统中。
Knative
See your serverless: introducing the Headlamp plugin for Knative
Knative 将无服务器工作负载引入了 Kubernetes 平台，负责处理流量路由、自动扩缩容以及版本管理等功能。这样一来，团队就可以专注于应用程序的开发和迭代，而无需操心基础设施方面的问题。不过，日常维护 Knative 工作负载并非易事：需要频繁在 kn CLI、 kubectl 以及 Kubernetes 用户界面之间切换，才能全面了解系统的运行状况。
功能：
- 将 Knative 资源与 Headlamp 的地图视图相集成
- KService 管理：编辑流量分配比例、重启容器节点、查看日志
- 流量分配：通过多次迭代来逐步推进部署和测试过程
- 自动扩展配置：查看有效设置及集群默认值
- Prometheus 指标：用于监控请求速率、延迟以及资源利用率
- 其他 CRD 的仪表板
3. Amazon EKS 相关功能介绍
EKS 自动模式的新功能
- 通过启动检测功能的优化，节点的启动时间减少了 39%（快了 13 秒）。
- Karpenter是 EKS 自动模式（EKS Auto Mode） 下的节点生命周期管理器，其横向扩展速度提升了 43%。集群资源整合速度最高提升了 69%，同时可额外增加 30% 的集群容量。
- 节点本地 DNS 能够实现亚毫秒级的解析速度，且不会受到整个集群的瓶颈限制。
- 将不同的 Pod 子网和安全组分开，有助于将企业网络配置切换到自动模式。
- 所有改进都会自动应用。对于已经处于 EKS 自动模式下的集群，无需进行任何配置更改。
EKS 自动模式与 Istio Ambient Mesh 的结合
Better Together: Amazon EKS Auto Mode and Istio Ambient Mesh
团队通常需要花费大量时间来处理那些重复性的操作任务，比如给节点打补丁、调整集群规模以及配置网络策略。随着服务数量的增加，确保服务之间的安全通信以及管理每个服务的代理配置就变得更加繁琐。这种日益复杂的状况凸显了采用更自动化、更集成的解决方案的必要性。这就是 Amazon Elastic Kubernetes Service（Amazon EKS）的 Auto Mode 和 Istio Ambient Mesh 能够发挥作用的地方。Amazon EKS 的 Auto Mode 可以自动处理节点的配置、扩展和补丁应用，从而让团队不必再手动管理计算层的相关事务。Istio Ambient Mesh 则能实现自动的相互 TLS 加密和流量管理，而无需对应用程序代码进行任何修改，也无需使用传统的侧车代理。这种组合方式有助于减少人工操作，同时还能实现自动加密和策略执行的功能。我们将深入探讨其集成架构，并详细演示从集群创建、mTLS 加密、授权策略到第 7 层流量控制的整个实现过程。
EKS 支持通过 VPC 来实现控制平面的出站连接
Amazon EKS now supports control plane egress through your VPC
该功能允许您将 Kubernetes 控制平面的流量通过自己的 Amazon Virtual Private Cloud（Amazon VPC）进行路由。这包括 Webhook 回调、OpenID Connect（OIDC）提供商查询以及各种 API 服务器请求的路由处理。利用这一功能，您可以将原本用于数据平面的 VPC 路由、安全组设置、端点策略以及 AWS 网络防火墙规则，同样应用到 Amazon Elastic Kubernetes Service（Amazon EKS）集群中 Kubernetes API 服务器的出站流量上。
默认情况下，来自 Kubernetes API Server 的流量会通过 EKS 所管理的控制平面离开集群。这些流量包括用于验证和修改相关数据的 Webhook 请求、获取 OIDC 发现文档的请求，以及发送给各个 API 服务器的请求。那些处于受监管行业的客户希望能够对该流量路径实施自己的 VPC 出口控制机制，这样，用于管理其工作负载的策略也能同时用于管理 Kubernetes API Server 所发出的流量。
通过客户路由机制来控制数据流出，就能实现精确的控制。当您启用此功能来创建或更新现有集群时，Kubernetes API 服务器的数据流出会经过您 VPC 中的弹性网络接口(ENI)。您可以利用现有的路由设置、安全组、VPC 端点以及 AWS PrivateLink 连接来控制数据的传输路径。
4. 从 SpaceX IPO，看下一代基础设施的演进方向
Jonathan Boyce：
今天的 SpaceX，已经同时处在多个基础设施议题的交汇点上：火箭、卫星、xAI、大规模 GPU 数据中心，甚至还有关于“太空数据中心”的讨论。无论我们如何看待某一家公司的发展路径，一个更大的趋势已经非常清晰：AI 正在推动一轮庞大的物理基础设施建设浪潮。
我一直认为，推理将成为历史上规模最大的计算工作负载。McKinsey 曾预测，到 2030 年，仅 AI 推理就可能需要 90GW 的数据中心电力，其规模甚至可能超过其他所有计算负载的总和。
未来会有更多数据中心被建设，更多 GPU 被部署，也会有更多电力资源被提前锁定。
但问题在于，电力、芯片、散热、网络和土地，都是现实世界中的硬约束。它们不可能像需求增长一样快速扩张。这也让软件层和运维层变得极其关键。在既有硬件和电力资源条件下，当前最有效的优化路径之一，是尽可能提升资源利用率：更好的调度、更好的路由、更好的可观测性、更高效的加速器利用率，以及更高效的推理服务。
5. 基础设施的束缚让人工智能公司损失了数亿美元
The infrastructure lock-in costing AI companies hundreds of millions
背景
在最近接受《EE Times》采访时，Tenstorrent 的首席执行官认为，目前企业最不可取的做法，就是试图让自身的人工智能基础设施更好地适应当前所使用的模型。这并不是因为那些模型本身不好，而是因为 18 个月后，这些模型可能已经不再被使用。Keller 援引了“伦特法则”和“阿姆达尔定律”来说明：相比浮点运算性能，内存、网络和系统层面的平衡性现在更为重要。
因为人工智能的发展速度远远超过了支撑它的基础设施的发展速度。那些花费了数亿美元来开发某一代人工智能模型的公司，现在不得不面对重新开始这一切的巨大成本。这种恐惧被称为“锁定效应”，它正在改变人工智能领域中的各大巨头对硬件的看法。
发展
在 2023 年和 2024 年，人工智能相关基础设施的采购相对简单：只需训练大型语言模型，将其提供给用户使用，同时购买 Nvidia 能够提供的尽可能多的 GPU 即可。这些工作负载具有可预测性，而 GPU 也完全能够胜任这些任务。
后来，人工智能的发展已经超出了当初为其构建的基础设施所能承受的范围。推理模型需要花费更多时间来分析问题，而不会直接得出答案。在完成任务之前，这些模型需要在各种 API、数据库和代码之间来回切换。多模态模型则将文本、图像、音频和视频等信息结合在一起。这些不同的工作方式对硬件的要求各不相同——这就迫使基础设施团队重新审视那些在两年前还看似合理的假设。
思考
没有哪种单一的芯片架构能够完美地应对所有这些挑战。那些致力于构建人工智能基础设施的公司逐渐意识到：问题不在于哪种加速器速度最快，而在于如何构建出这样的系统：即便人工智能不断取得新的突破，也无需频繁地对系统进行拆解和重新组装。
厂商的做法
- 在 2026 年的 GTC 大会上，Nvidia 推出了 Vera Rubin 平台——该平台由七块芯片组成，它们共同构成一个完整的系统：Rubin GPU、Vera CPU、NVLink 6 交换器、ConnectX-9 网络芯片、BlueField-4 DPU 等等。Vera CPU 也是该平台的重要组成部分。Nvidia 出售的是完整的基础设施，而非单独的加速器。当一家占据 70%市场份额的公司不再以 GPU 性能指标作为衡量标准，而是开始谈论系统级的协同设计时，这就表明了该市场的重心正在向何处转移。
- AMD 也面临着同样的问题，只不过采取的解决方案有所不同。Helios 将 CPU、GPU 和网络功能整合到了同一个平台上，这一举措体现了人们不再把 GPU 视为整个系统的核心。其宣传重点并非“我们的加速器更快”，而是强调：围绕芯片的基础设施的重要性，已经与芯片本身相当了。
- 谷歌花了十年时间来共同设计其 TPU 芯片、互连组件以及软件框架。其第七代 Ironwood 芯片现已正式上市，这使得谷歌能够对整个技术栈拥有极高的掌控力。
- 亚马逊则采取了相反的做法：为不同的任务专门设计芯片——用于训练的 Trainium 芯片，用于推理的 Inferentia 芯片。目前，Trainium3 已经投入实际使用，为 Anthropic 等客户提供服务。
- 微软的 Maia 200 则专注于降低推理成本；同时，该公司还使用 Nvidia 的 Vera Rubin NVL72 芯片来进行训练和实验。
在所有这些公司的背后，是博通公司。由于对定制型加速器及数据中心交换机的需求巨大，博通在人工智能半导体领域的营收最近在一个季度内就突破了 100 亿美元大关。博通为谷歌、Meta 等公司设计定制型加速器，同时还负责提供用于在数据中心范围内连接这些加速器的 Tomahawk 和 Jericho 交换机芯片。预计 2026 年，定制型 ASIC 的出货量将实现约 45%的年增长率——这一增长率是商用 GPU 增长率的三倍。
还有一些公司认为，打造更出色的 GPU 并非解决问题的办法。
- Cerebras 认为没有必要使用成千上万个相互连接的芯片，而是选择使用晶圆级处理器——这样可以将更多的工作负载集中在一块硅片上处理。
- Groq 则采取了相反的做法，几乎完全专注于推理功能的优化。
- SambaNova 则着眼于企业级人工智能领域，致力于打造那些能够高效处理多个模型的系统，而非只追求最快的测试成绩。
每家公司都在以自己的方式来应对这一挑战。它们采用不同的策略，但都在思考同一个问题：如何构建出能够经受住其上运行的 AI 系统所带来的考验的基础设施呢？