Category: Containers

介绍如何支撑万级 agent 运行的存储架构选择

在不修改客户端、不 fork LiteLLM 源码的前提下，将 LiteLLM 的 websearch interception 搜索后端 从自建 SearXNG 替换为 Amazon Bedrock AgentCore Web Search——一项 AWS 全托管、由 Amazon 自营 web 索引在 AWS 基础设施内服务搜索查询（查询不发往第三方搜索引擎）的 Web 搜索服务。文末给出 进阶用法：将其暴露为 MCP server，使没有 AWS 凭证的客户端 （如 OpenAI Codex）也能通过一个 LiteLLM virtual key 进行调用。

本文以真实集群从 EKS 1.32 升级到 1.35 为例，展示如何将风险识别、路径规划、升级执行和故障定位交给 Kiro agent。我们在同一集群做对照实验——唯一变量是否加载 Skill 知识库：无 Skill 时工程师需全程介入，耗时约 6 小时；加载 Skill 后 agent 自主执行，耗时约 2.5 小时，节省 60%。两组共享同一工具链，差距主要来自 Skill。更值得关注的是，agent 在实战中主动发现新隐性约束并补充回 Skill，说明知识库具备随实战增长的潜力。

本文对比了在 EKS 上通过 Mountpoint S3 CSI 和 S3 Files + EFS CSI 两种方案访问 S3 数据的差异。Mountpoint S3 是基于 FUSE 的轻量客户端，设计目标是高吞吐而非完整 POSIX 语义；S3 Files 是 2026 年 4 月 GA 的新服务，通过 NFSv4.1+ 协议和全托管智能缓存层，首次让 S3 原生支持完整文件系统语义。
两种方案并非互斥，工作负载特征互补，在同一 EKS 集群中混合部署、按场景选型，是当前 AWS 上 S3 数据接入的最佳实践。

Amazon EKS 不支持跨多个版本直接升级，且有时 Kubernetes 版本之间都伴随一系列废弃 API、运行时变更和节点 OS 调整。本文以一个真实集群从 EKS 1.32 升级到 1.35 为例，介绍如何对集群中的自管理组件和托管组件做风险分级评估、识别 cgroup v1、containerd、Ingress NGINX 等关键变更带来的影响，并给出一套可复制的逐版本升级路径，帮助企业以最小风险完成跨多个 Kubernetes 大版本的升级。

AI Agent 从实验走向生产，企业需要让不同团队各跑独立实例且互不可见。本文介绍基于 Amazon ECS Fargate + Graviton 的轻量级多租户方案，同时部署 OpenClaw（开箱即用 Web Agent）与 Hermes（自进化 AI 助手），四层隔离机制保障企业级安全，并演示 Hermes 通过自然语言驱动 Spark on EKS 数据分析。

在 EKS 上结合 GPU Operator 与 Kiro+EKS MCP，管理自定义 GPU 驱动和 CUDA 工作负载。

基于 Amazon EKS 与 NVIDIA NIM 构建混合云大模型推理架构，实现本地 GPU 优先、云上 Spot 实例弹性兜底，结合 KEDA 和 Karpenter 达成 0→N 自动扩缩容与成本最优。

本文介绍了 npd-node-replace 组件的整体架构与实现原理，重点阐述了如何基于该组件对节点问题事件进行采集与分析，并对异常节点状态进行自动化处理。通过对节点异常场景的自动修复机制进行方案设计与实践探索，提升集群的可用性与整体稳定性。

随着生成式 AI 的快速普及，越来越多的企业需要为内部团队或外部客户提供 AI Agent 服务。如何在保障安全隔离的前提下，实现高效、低成本的多租户 AI Agent 部署，成为一项关键的技术挑战。本文介绍如何基于 Amazon EKS、AWS Graviton 和 Kubernetes Operator 模式，构建一个支持多租户、多模型的 OpenClaw AI Agent 平台，并通过 CloudFront + Cognito + ALB 的前端架构实现用户自助 Provisioning。