Category: Containers

本文介绍了一个面向 Amazon EKS 用户的 AI 驱动集群健康诊断 SaaS 平台，该平台通过”确定性规则 + AI 关联分析 + MCP Agent 自主诊断”三层架构，实现从静态规则检查到 AI Agent 按需实时采集集群数据的智能化运维诊断，帮助用户快速定位集群配置风险并获得可执行的修复建议。

本文分享在 Amazon EKS 上自建开源可观测性数据栈的完整实战：用 VictoriaMetrics、Grafana Loki、Grafana Tempo 分别承载指标、日志与链路，数据存入 Amazon S3 与 EBS gp3，通过 IRSA 安全集成。借助 OpenTelemetry Operator 实现存量微服务零代码接入，并在 Grafana 中打通 trace、log、metrics 三向一键关联，自动生成服务拓扑，显著提升故障排查效率。

本文介绍了一种 AI Agent 的沙箱方案：用于多租户 AI Agent 平台（不同用户的会话需要完全隔离）、编程助手的代码执行沙箱（OpenClaw、Hermes 之类）、合规环境下需要可审计的工作负载隔离，以及任何需要规模化执行不可信代码的场景。

介绍如何支撑万级 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 工作负载。