Kubernetes

你的 Kubernetes 仪表盘一片绿，用户却在叫苦连天

企业运维中常见一种“幽灵变慢”：Kubernetes 和 Grafana 仪表盘全绿，Pod 正常运行、探针返回成功、CPU 也没打满，但用户却抱怨应用查询或 AI 模型响应时快时慢。原因是探针只回答“容器要不要重启、能不能接流量”，并不衡量一次完整用户请求是否按时完成。HPE OpsRamp 产品负责人 Mahesh Ramachandran 建议持续采集跨层遥测数据并保留历史记录，因为间歇性变慢过去后，没有历史证据几乎无法定位；再结合异常检测和相关性分析找出可疑因素，但相关不等于证因，改动后需对比同一用户侧指标验证。对读者的用处是：看板变绿不等于用户体验变好，应补上应用性能测量和历史数据。该系统需要团队自行配置探针与集成，文中未说明具体可用的 AI 排查功能或发布时间。

Kubernetes 的 cgroup v1 已死，接下来会发生什么？

Kubernetes 用来限制容器 CPU 和内存的底层机制 cgroup v1 正在被淘汰，从 v1.35 起 kubelet 默认不再支持它。新版本改用 cgroup v2，提供统一层级和更好的资源隔离。运维者应把所有 Linux 节点升级到 v2 再升级 Kubernetes，否则节点无法启动。读者若在管理 Kubernetes 集群，需要尽早安排迁移，避免旧架构卡住升级。

如何在 15 分钟内用 Harness CD 部署你的第一个应用

Harness 发布了一篇入门教程，手把手教没有用过 Harness CD 的开发者部署一个示例 Java 应用。原来很多团队用 SSH 脚本手动部署，一旦要加第二个环境、回滚或上线审批，脚本就会变得混乱，回滚往往要凭记忆找回上一个可用的镜像版本。这次教程把“构建”和“部署”拆开：部署目标、策略和失败处理只需配置一次、到处复用，从测试环境切到生产环境只改少量设置，出错一键回滚并保留完整发布历史。教程需要 GitHub 等代码仓库账号、Docker Hub 账号、Kubernetes 集群和 Harness 账号，并说明仓库里已带一份可用的流水线配置，可直接指过去跳过手动步骤，但整篇是演示性质，是否已在正式产品中可用原文未明确说明。

Kubernetes 赢得了编排之战，其团队仍在鏖战

CNCF 报告说，82% 的容器用户在生产环境里使用 Kubernetes（一种管理大量容器的工具），它已经成了默认选择。但选对了技术不代表团队就省心了：开发人员喜欢自助上线、快速改配置，运维团队却担心稳定性和审批流程，双方常常较劲。现在 AI 推理任务越来越多，应用要跑到混合云和边缘设备上，GPU 调度和扩容又成了新难题；有专家认为，公司过度拆分微服务也带来了“架构臃肿”。好消息是，AI 自动化有望帮团队盯集群、查日志，甚至提前预测故障，把一部分运维活儿接过去。对读者来说，这意味着未来容器混乱有希望缓解，但作者也强调没有单一产品能解决所有问题——HPE 等厂商在推相关工具，但哪些具体限制、何时落地，文中没有说明。

CNCF 项目毕业速度空前，AI 智能体正协助尽职调查

CNCF 执行董事 Jonathan Bryce 说，过去 18 个月里该基金会审批项目毕业的速度比以往任何时候都快，部分原因是他们创建了 AI 智能体来帮忙做不同阶段的尽职调查。他用 2018 年 OpenAI 早期借助 Kubernetes 调度算力的例子说明，开源工具让 AI 公司能在自有数据中心和多家云厂商之间灵活调配资源，不用被单一供应商锁死。现在这些 AI 公司把改进回馈给开源社区，金融和制造业也能跟着受益。不过，智能体具体怎样做尽调、准确率如何，文中并未说明。

智能体让 CI 成了瓶颈，但更快的流水线并非正解

Anthropic、Linear 和 Depot 在九月先后指出：智能体写代码太快，把持续集成（CI，即每次提交代码后自动跑测试的流水线）压成了瓶颈。Anthropic 的 CI 任务量半年涨了 25 倍，工程师每季度交付的代码约为 2021 至 2025 年的 8 倍；Linear 的测试套件自一月以来翻了近两番。业界的反应是让流水线更快，但作者认为这解决错了层面：云原生系统里一个仓库只是几十个服务之一，CI 只验证仓库里的代码和模拟（mock）出来的依赖，跨服务边界才出问题。真正该做的是把验证提前到提交 PR 之前、并且针对整个系统而非单个仓库，再用共享的 Kubernetes 集群多路复用来控制成本。读者会得到判断：智能体时代不能只靠提速，还要改变验证的对象和时机。

K3s 与 K8s：轻量级 Kubernetes 发行版何时胜出（何时不适用）

标准 Kubernetes（K8s，一个管理容器化应用的开源平台）功能强大，但运维负担重：搭建一套生产集群要配置控制面、网络、存储、安全、可观测性等多个组件，还要持续维护。K3s 是 Rancher Labs（现属 SUSE）推出的轻量发行版，把控制面和许多组件打包成一个不到 100 MB 的单一二进制文件，默认用 SQLite 存储，最低只需 512 MB 内存和 1 个 CPU 核心即可运行；而标准 K8s 通常至少要 4 GB 内存和 2 个 CPU 核心。因此 K3s 更适合边缘计算、物联网设备（如树莓派、零售终端、工业电脑）等资源受限场景，标准 K8s 则适合需要最大灵活性的复杂集群。需要注意的是，文章只给出了选型思路，没有提供两者性能或成本的对照数据。

Kubernetes 的“单体”教训对 AI agent harness 意味着什么

Stacklok 创始人 Craig McLuckie 在 CNCF 博客上提出，目前多数 AI agent harness（即围绕 AI agent 的上下文、文件系统、子 agent、权限等支撑层）太“本地”，只适合单个开发者在笔记本上跑，难以支撑数百个会话，会话容易中断，体验也无法在不同客户端或设备间迁移。他认为应当把 agent harness 当作云原生分布式应用：把 agent 循环与底层基础设施和服务分开，就像 Kubernetes 教会业界“容器里的单体仍是单体”一样。对读者来说，这预示未来 AI agent 的支撑层可能像云服务一样可扩展、可迁移，而不只是本地玩具。目前这只是观点和倡议，尚未说明具体落地产品。

一个运行中的 Kubernetes 集群仍可能存在归属缺口

HPE 的 Karthik Subramanian 解释，Kubernetes 上线后集群本身健康不代表应用没问题。他把后续运维责任分给平台团队（负责集群、网络、安全策略和升级）与应用团队（只在指定命名空间里部署和管理自己的应用）。标准分两层：云级策略（如角色权限、备份、Terraform）和集群级设置（如版本节奏、命名、网络策略）。升级用预检查、分批滚动、金丝雀或蓝绿发布，先给小比例流量再逐步放大；升级完成的标准是应用关键路径可用、服务目标达标，而不是节点恢复 Ready。

“把它看作Agent的Kubernetes”：OpenClaw携OpenAI、Nvidia和Red Hat进军企业市场

OpenClaw 最初是奥地利开发者 Peter Steinberger 在 2025 年底做的一个周末项目，后来迅速走红，GitHub 星标超过 10 万，连 OpenAI 都把他招了进来。问题是，企业 IT 部门看到这种能访问代码、凭证和内部系统的 Agent 平台，第一反应往往是直接禁掉，因为权限太大、没法集中管。于是 OpenClaw 推出企业版 OCE——一个开源、不绑定厂商的管理平台，核心是一个“控制平面”，让管理员集中部署 Agent、隔离命名空间、管理配置和权限，思路类似用 Kubernetes 管容器那样管 Agent。目前 OCE 还在 1.0 发布前的开发阶段，只适合内部试点，代码已在 GitHub 上公开，可自托管且免费。

Kubernetes 上智能体 AI 的崛起：释放新的基础设施层

如今 Kubernetes 集群、环境和运维信号越来越多，手动管理容易跟不上，配置容易跑偏，出故障的风险也变高。有人提出把「智能体 AI」用到 Kubernetes 上：它能观察集群状态、给出诊断建议、并在事先批准和限定的范围内动手改。前提是让智能体能看到集群状态、策略和权限规则，否则它只能靠猜。对读者来说，这代表多集群管理有望在保持可控的同时更快，但具体产品、可用时间和效果材料没有说明。

GKE Pod 快照缩短模型加载时间，将工作重心转向快照生命周期管理

Google 为 GKE 的 Pod 快照功能发布了基准测试：启动延迟最高降低 89%，加载一个 700 亿参数的大模型只需 37 秒。过去在 Kubernetes 上冷启动 AI 模型往往要等很久，因为每次都要把模型和数据重新加载进内存。这个功能通过 gVisor 把 CPU 和 GPU 内存的状态保存下来，存进云存储，下次启动时直接恢复。不过开发者提出，快照失效可能才是更难的问题：快照只对规格哈希、机器系列以及内核和驱动版本都一致时才有效。目前只有 Google 公布的基准数据，该功能是否已正式可用、定价如何，材料未说明。

agent-skills：跨仓库复用的个人 Agent 技能合集

Eu4ng/agent-skills · Personal agent skills shared across repositories (Agent Skills standard + Claude Code plugin marketplace)

这是一个按 Agent Skills 标准组织的个人 Agent 技能合集，涵盖 Git 工作流（提交、分支、推送、PR、worktree）、技能编写、Python 开发、环境引导，以及 GitOps 变更、Grafana 面板检查、Home Assistant、Proxmox、Ansible、Kubernetes 节点维护与排障、Patroni 等基础设施运维场景。仓库本身同时作为 Claude Code 插件市场发布，也支持读取 .agents/skills 的工具（Codex、Cursor 等）。

开发者和平台团队都想要 Kubernetes 自助服务，但对归属权意见不一

HPE 的 Marius Bogoevici 和 Karthik Subramanian 在采访中聊了 Kubernetes 自助服务的矛盾点。开发者想要随用随取的 Kubernetes 环境，但不想等一周多的工单流程；平台团队则要管成本、权限和合规。HPE 的做法是用 HKS 和 HPE Morpheus Software 把安全配置做成服务目录：开发者可以自助选择预批准的集群版本、资源配额、工具链和租期，但网络隔离、身份认证、安全策略和费用归属仍由平台团队自动应用。这样开发者不用放弃 Kubernetes 原生接口，平台团队也能统一管控，减少手动拼工具链和集群闲置浪费。

2026 年云成本优化策略：降低支出

这是一篇面向平台工程和 DevOps 团队的指南性文章，讲的是怎么在 2026 年把云账单降下来。文章指出，很多云资源被闲置或超额配置，会造成浪费；数据显示 AI 相关支出中约有 26% 被浪费。解决思路分四步：先搞清楚钱花在哪些团队和业务上，再找出闲置或配置过大的资源，在调整容量前先评估对可靠性的影响，最后用自动关停、自动扩缩容、预算和异常告警等手段让节省持续下去。文中给了 10 条具体策略，也包括 Kubernetes 安全缩容和提交折扣等做法，并附有 GE Vernova 省下 50.4 万美元、Tyler Technologies 年化节省 120 万美元等例子。文中还提到 Harness 成本管理代理（Cost Management Agent）可用于自动分摊成本，但文章只是介绍策略，并未说明这些工具目前的开放状态。

Modal 超越 Kubernetes：如何在数秒内扩展 100 万个并发沙箱

Modal 的两名资深工程师 Colin Weld 和 Connor Adams 最近写了一篇文章，讲他们怎样把公司用来跑代码的“沙箱”系统整个推倒重做。原来的问题是：用 Kubernetes 这种常见容器管理方式，没法同时支撑几百万个沙箱，也没法每秒新建几万个。他们从底层重新设计后，做到了这两点。对读者的用处是：如果你关心云端跑代码、AI 智能体执行环境这类场景，这提供了一条不用 Kubernetes 也能大规模扩容的思路。目前文章只是经验分享，没有提到具体产品是否开放或开源。

为什么面向工程师的云成本优化会失败

这篇文章解释了工程师为什么常常忽视云成本：账单数据往往延迟几周才出现，而且是汇总后的数字，跟具体哪次提交、哪个部署造成的花费对不上号。作者提出的解决思路是把成本信息“左移”，也就是在代码合并和 CI/CD 流程里直接显示这次改动会多花多少钱，让工程师在写代码时就能看到并负责。文章还提到，Kubernetes 里把 CPU、内存请求设得过高，会导致云账单悄悄上涨，但普通账单面板查不出是哪个部署干的。Harness 被作为能帮助实现这类开发者视角 FinOps 的工具提及。

Kubernetes 1.37 发布：指标 API 稳定，无根 Kubelet 进入测试版

云原生计算基金会（CNCF）发布了 Kubernetes 1.37 版本，代号“Garhwal”。这次更新主要关注稳定性、安全性，以及对 AI/ML 工作负载的优化。对用户来说，稳定版指标 API 意味着监控工具可以直接依赖它，不用再冒险用试验功能；无根 Kubelet 进入测试版，则让容器运行更安全，即使被攻破也不容易影响整个机器。不过，文章没有说明具体哪些指标 API 转正、无根 Kubelet 什么时候正式可用，也没有提到具体的下载或升级方式。

超越同步：Argo CD 需要企业级控制平面

Argo CD 是个很受欢迎的开源工具，专门把 Git 里的配置自动同步到 Kubernetes 集群，相当于“你说要什么状态，它帮你照着调”。问题是，当公司规模变大、集群和应用越来越多时，光同步配置远远不够：团队要自己写脚本去接工单、审批、安全策略和发布检查，每个 Argo 实例还要单独管权限，最后运维负担和安全风险都会迅速膨胀。这篇文章提出用“企业级控制平面”来包住 Argo，把工作流编排、集中治理和部署验证这些能力内置进去，减少人工救火和故障恢复时间。对读者来说，如果团队正在用 Argo CD 做大规模 GitOps，这篇文章指出了一个补齐短板的思路：不换掉 Argo，而是在它上面加一层管理平台。

使用 Harness 与 Terraform 自动化创建 Docker 镜像仓库

本文介绍如何通过 Harness Pipelines 与 Harness Terraform Provider 构建一条全自动 CI/CD 流水线：在 CI 步骤中内联运行 Terraform 动态创建唯一命名的 Docker 镜像仓库，构建并推送容器镜像，再将其部署到 Kubernetes，并通过输出变量与 Harness 表达式在各阶段间传递数据，全程无需手动操作 UI。