当SSH成为过去，用Agent结合SSM文档重新定义云上容器环境故障诊断

PixPin_2026-06-28_11-37-22

本文介绍一种基于LLM和AWS SSM的EKS故障诊断架构，完全摒弃传统的SSH登录模式，让AI成为运维工程师的"智能助手"。

想象一下这样的场景：凌晨两点，监控系统突然报警，XXXXXXX集群的一个节点无法加入。作为运维工程师，你的第一反应是什么？找IP地址，检查SSH密钥，确认安全组22端口是否开放，如果是私有子网还要先连跳板机，最后执行ssh命令登录到节点，查看kubelet日志。整个过程可能需要十分钟到十五分钟，而且还得在脑子里记住一堆命令。

但如果我们换一种方式呢？只需要一条命令，输入集群名和节点ID，然后等AI告诉你问题在哪，怎么修。三分钟，一杯咖啡的时间，AI已经分析完所有日志，生成了修复方案。

这个转变背后，是SSH诊断模式存在的几个根本性问题。

  • 安全性。使用SSH必须开放22端口，这本身就扩大了攻击面。SSH密钥需要妥善管理，存在泄露风险。更重要的是SSH操作通常缺乏完整的审计日志，很难追溯谁做了什么操作。如果需要连接私有子网的节点，还得通过跳板机，这又引入了额外的单点故障。
  • 效率。人工分析日志容易遗漏关键信息，特别是当日志量很大时。每次遇到重复性问题都要从头排查，无法积累知识。更重要的是这种诊断方式形成了知识孤岛，只有资深工程师才能处理复杂问题，新人很难上手。
  • 规模化。当一百个节点同时出问题，或者节点分布在跨可用区，或者节点根本没有公网IP时，传统的SSH方案几乎无法应对。人力无法线性扩展，而这些问题在云原生时代越来越常见。

正是在这样的背景下，大语言模型的爆发让我们重新思考：如果AI能读日志、找问题、给建议，为什么我们还要手动SSH？但这引出一个核心问题：如何让AI安全地访问生产环境？

AWS SSM - 被低估的运维神器

很多人知道AWS有EC2，但不知道每个EC2实例都可以成为SSM托管实例。简单说，不需要SSH，不需要公网IP，实例上的SSM Agent会主动连接AWS。你可以远程执行命令、收集日志、运行脚本，而且所有通信都是加密的。

flowchart TB subgraph 传统模式 direction TB A[运维人员] -->|SSH| B[Jump Server] B -->|SSH| C[EC2实例] C -->|开放22端口| D[互联网] end subgraph SSM模式 direction TB A2[运维人员] -->|HTTPS API| E[AWS Systems Manager] E -->|加密通道| F[SSM Agent] F -->|不需要入站端口| C2[EC2实例] end

SSM提供的"开箱即用"能力

AWS已经为我们准备好了专门的EKS诊断工具。这些工具是免费的，只需要你的实例安装了SSM Agent。

  • AWSSupport-CollectEKSInstanceLogs，它可以一键收集节点的所有关键日志，包括kubelet、containerd、系统日志、网络配置等，并自动打包上传到S3。
  • AWSSupport-TroubleshootEKSWorkerNode，它可以自动检查21个常见故障点，涵盖IAM配置、网络连通性、Bootstrap脚本等，最后生成结构化的诊断报告。

让我用几个真实场景来说明两者的本质差异。

场景一：深夜紧急排障

凌晨两点，监控系统报警。你迷迷糊糊打开电脑，发现是一个EKS节点无法加入集群。

如果用SSH方案，你的第一反应是找这个节点的IP地址。但等等，节点在私有子网，没有公网IP。你需要先SSH到跳板机，再从跳板机SSH到目标节点。每次连接要等5-10秒建立隧道，输入密码或选择密钥。等你终于连上去，已经过去了3分钟。你执行journalctl -u kubelet -f，屏幕开始滚动日志。你盯着屏幕，试图从几百行输出中找出关键错误。

而SSM方案呢？你甚至不需要知道节点的IP。一条命令，5秒后你已经在看结构化诊断报告。

场景二：权限审计

季度审计来了。审计员问："过去三个月，都有哪些人访问过生产环境？"

如果用SSH方案，你需要翻遍所有节点的auth.log，grep出所有登录记录，手动汇总成表格。这个过程可能需要一整天。

而SSM方案呢？CloudTrail早已自动记录了所有操作。一条查询命令，5分钟后审计报告就生成了。

场景三：安全事件

公司一台员工的笔记本被盗，上面存着SSH私钥。

如果用SSH方案，你需要立即撤销这个密钥在所有节点上的授权。但问题来了，这个密钥在哪些节点上？你根本不知道。你只能在所有节点上紧急轮换密钥，整个过程可能需要数小时。

而SSM方案呢？IAM角色统一管理，你只需在IAM控制台点几下，权限立即生效。整个过程不超过5分钟。

场景四：批量操作

你需要在100个节点上执行同一个命令。

如果用SSH方案，你需要写个脚本循环SSH到每个节点。串行执行太慢，并发执行又担心网络拥塞。你还需要处理各种超时、连接失败、权限问题。整个过程可能需要一上午。

而SSM方案呢？一条命令同时发送到100个节点，并行执行，自动收集所有结果。

架构设计 - AI如何安全地诊断生产环境

核心思想即智能体不应该做所有事情。这句话听起来反直觉。既然AI这么强大，为什么不能让它包办一切？要理解这个问题，需要先明白智能体和执行者的本质区别。

当用户说"XXXXXXX集群的i-xxx节点好像有问题"时，LLM首先需要理解这句话背后的真实意图。"好像有问题"是一个很模糊的描述，可能指节点无法加入集群，也可能是节点加入了但Pod调度失败，还可能是节点性能异常。LLM需要从这种模糊表达中推理出最可能的含义，判断应该调用哪个诊断工具，制定什么样的检查计划。这个过程充满了不确定性，需要联想、推理和判断，正是LLM最擅长的领域。

但当LLM决定调用AWSSupport-TroubleshootEKSWorkerNode时，接下来的事情就必须确定无疑。

  • 传入cluster名称和node ID，必须返回一个执行ID。这个执行ID必须真实存在，能够用于查询执行状态。执行要么成功要么失败，不能有第三种状态。
  • 执行时间虽然可能有波动，但必须在可预期范围内，不能今天30秒完成，明天30分钟还没结束。这些确定性要求，是LLM无法满足的。
  • LLM的输出来自概率模型，即使温度参数设为0，仍然存在微小的不确定性。而这种不确定性在关键路径上是不可接受的。

因此，正确的做法是将架构分层。

  • 当用户输入到达时，由LLM负责理解意图、制定策略、判断应该调用哪个SSM文档。这个决策过程允许有一定的不确定性，因为即使LLM判断错了，也可以在后续环节纠正。
  • 决策一旦做出，接下来的执行就必须交给传统代码。代码负责调用SSM API，等待执行完成，处理超时和重试，获取执行结果。这些操作必须是确定的、可预期的、可测试的。
  • 最后，当执行结果返回，再由LLM负责分析这些结果，识别问题根因，生成人类可读的修复建议。这个分析过程又可以接受一定的不确定性，因为分析结果最终要由人类运维工程师判断和执行。

这种分层带来的好处体现在四个维度。

  • 可替换性。今天用的GLM-5明天可以换成GPT-4，只需要改动LLMClient这一个类，SSM执行层完全不需要修改。同样，如果把AWS换成Azure，也只需要修改EKSSSMExecutor，LLM分析层不受影响。

  • 可测试性。SSM执行层可以单独测试，通过mock AWS API来验证调用参数是否正确。LLM分析层也可以单独测试，给固定的输入，验证输出结构是否符合预期。

  • 可演进性。业务逻辑变化比如新增一种诊断类型，只需要修改LLM Prompt。执行逻辑变化比如SSM API升级，只需要修改代码。两者独立演进，不互相牵制。

  • 可解释性。当用户问为什么调用Troubleshoot而不是CollectLogs，可以展示LLM的推理过程。当用户问为什么执行失败，可以展示SSM的错误日志。责任边界清晰，问题定位容易。

归根结底，智能体不应该做所有事情，是因为架构的本质在于划分边界。不确定性边界内的任务交给LLM，发挥它的推理和生成能力。确定性边界内的任务交给代码，发挥它的稳定和可预期特性。两者结合，才能构建出既智能又可靠的系统。

在EKS集群运维场景，一个完整的诊断流程是这样的。当运维工程师输入"XXXXXXX集群的i-xxx节点加入失败"时：

  • 首先由AI Agent理解这句话的真实含义。Agent会判断这是一个节点加入失败的问题，需要调用AWSSupport-TroubleshootEKSWorkerNode进行全面诊断。
  • 于是Agent向SSM发送请求，启动诊断流程。
  • SSM在目标节点执行一系列检查，包括IAM配置、网络连通性、Bootstrap脚本等21个检查项，最后返回结构化的诊断结果。
  • Agent收到这些结果后，将它们传递给LLM进行分析。LLM从诊断输出中识别出关键问题，比如IAM角色Trust Policy配置错误、UserData缺少NodeConfig等，并生成人类可读的摘要。
  • 然后Agent再次调用LLM，基于发现的问题生成详细的修复计划。
  • 最终，运维工程师收到的是一份结构化的诊断报告，包含问题列表、根因分析和逐步修复指南。

这种设计在安全性方面提供三层保护，成本效益也很显著。

  • 网络层。节点不需要开放任何入站端口，所有通信都是SSM Agent主动发起的出站HTTPS连接，攻击面大大缩小。

  • 权限层。使用AWS IAM进行细粒度控制，运维人员通过IAM角色获取权限，不需要管理SSH密钥，避免了密钥泄露的风险。

  • 审计层。所有SSM操作都会通过CloudTrail记录，谁在什么时间对哪个节点执行了什么操作，都有完整的日志可追溯。

  • 成本方面。SSM本身是免费的，只有调用LLM进行深度分析时才会产生费用，大约每次几分钱，且只在需要时启用。

实战测试 - 我们在EKS集群上做了什么

为了验证这个方案的可行性，我们在真实环境中搭建了测试集群并进行了完整的实战测试。

测试使用的EKS集群版本为1.33，部署在AWS北京区域。AI模型选用智谱AI的GLM-5，这是一款在国内访问稳定且中文支持优秀的大语言模型。测试节点是一台t3.medium规格的EC2实例，实例ID为i-xxxxxxxxxxxx。

我们在测试节点上故意配置了三个最常见的生产环境错误。

  • IAM Role的Trust Policy配置问题。具体来说，Trust Relationship策略中没有配置ec2.amazonaws.com的AssumeRole权限。这意味着节点虽然可以启动，但无法获取临时的AWS凭证，导致无法与EKS控制平面通信。
  • UserData配置问题。我们使用的是Amazon Linux 2023，但UserData中没有配置有效的NodeConfig。正确的NodeConfig应该包含集群名称、API服务器端点、CA证书等关键信息，用于引导节点加入EKS集群。
  • 服务启动问题。我们手动停止了containerd和kubelet服务，模拟容器运行时和Kubernetes节点代理故障的场景。

这三个错误的组合在生产环境中极为常见，通常发生在手动创建EC2实例但未正确配置EKS bootstrap的情况下。节点启动后会显示为NotReady状态，kubelet日志中会出现大量的权限错误和连接超时错误。

测试过程与结果

我们设计了两种诊断方案进行对比测试。第一种是传统SSH方案，模拟当前大多数团队的处理方式。第二种是AI加SSM方案，展示本文提出的新架构。

使用SSH方案时，运维工程师首先需要登录AWS EC2控制台，在实例列表中找到目标节点的IP地址。但这里就出现了第一个问题，由于节点部署在私有子网，没有公网IP，所以无法直接SSH。工程师需要找到跳板机的IP，先SSH到跳板机，建立隧道，再从跳板机SSH到目标节点。这个过程通常需要5到10分钟，取决于网络延迟和认证速度。

登录成功后，工程师需要手动收集日志。这包括执行journalctl查看kubelet日志，查看containerd状态，检查网络配置，验证IAM凭证等。每个命令的输出都是几百行甚至上千行的文本，需要人工阅读和分析。最后，工程师需要根据自己的经验判断问题根因，并生成修复方案。整个过程从开始登录到得到诊断结果，通常需要10到15分钟，而且高度依赖工程师的经验水平。

使用AI加SSM方案时，整个过程截然不同。运维工程师只需要在命令行输入一条命令：

python diagnose.py --cluster test127 --node i-xxxxxxxxxxxx

程序会自动调用AWSSupport-TroubleshootEKSWorkerNode文档，在目标节点执行诊断。这个过程不需要SSH，不需要公网IP，不需要登录控制台。SSM Agent会自动执行21项检查，包括IAM配置、网络连通性、Bootstrap脚本、容器运行时状态等。所有结果会自动收集并格式化，整个过程只需要1到2分钟。

执行过程中，控制台会显示进度信息：

2026-06-27 14:32:15 INFO: Starting troubleshoot runbook for cluster=test127, worker=i-xxxxxxxxxxxx
2026-06-27 14:32:16 INFO: Automation execution started: a-1234567890abcdef0
2026-06-27 14:32:26 INFO: Automation a-1234567890abcdef0 status: InProgress
2026-06-27 14:33:45 INFO: Automation a-1234567890abcdef0 status: Success
2026-06-27 14:33:46 INFO: Execution completed in 91.2 seconds

得到SSM诊断结果后，AI Agent会将这些结果传递给GLM-5进行分析。以下是SSM返回的部分原始输出：

{
  "iam_checks": {
    "trust_policy_valid": false,
    "error": "Trust relationship does not contain ec2.amazonaws.com",
    "can_assume_role": false
  },
  "userdata_checks": {
    "nodeconfig_present": false,
    "format": "invalid",
    "error": "MIME multipart missing application/node.eks.aws"
  },
  "service_checks": {
    "containerd": "inactive",
    "kubelet": "inactive",
    "error": "Services failed to start"
  }
}

AI在30秒内识别出三个关键问题：Trust Policy缺失ec2.amazonaws.com权限，UserData缺少有效的NodeConfig配置，以及containerd和kubelet服务未启动。AI还生成了详细的修复建议，包括具体的AWS CLI命令和配置参数。从输入命令到得到完整的诊断报告，整个过程只需要3分钟。

诊断结果分析

AI生成的诊断报告结构清晰，包含问题列表、根因分析和修复建议。以下是AI生成的诊断摘要示例：

============================================================
                EKS节点诊断报告
============================================================

【诊断摘要】
在test127集群的节点i-xxxxxxxxxxxx上发现3个关键问题，
导致节点无法加入EKS集群。

【问题列表】
1. [CRITICAL] IAM Trust Policy配置错误
   - Trust Relationship缺少ec2.amazonaws.com的AssumeRole权限
   - 节点无法获取AWS凭证，无法与EKS控制平面通信

2. [HIGH] UserData配置缺失  
   - 缺少有效的NodeConfig配置
   - EKS bootstrap脚本无法正确引导节点

3. [HIGH] 关键服务未启动
   - containerd和kubelet服务处于inactive状态
   - 节点无法运行容器和与Kubernetes通信

【根因分析】
该节点是手动创建的EC2实例，未使用EKS托管节点组的标准配置流程。
缺少IAM权限导致认证失败，UserData配置错误导致引导失败，
服务启动失败是前两个问题的连锁反应。

【修复计划】
建议按以下顺序修复：
Step 1: 修复IAM Trust Policy
Step 2: 重新配置UserData并重启节点
Step 3: 验证服务启动状态

预计修复时间: 10-15分钟
============================================================
  • 第一个问题，AI明确指出Trust Relationship策略中缺少ec2.amazonaws.com的AssumeRole权限，这导致节点无法获取STS临时凭证。证据是在SSM诊断输出中看到了AccessDenied错误，以及缺少有效的AWS凭证链。
  • 第二个问题，AI识别出AL2023 UserData缺少有效的NodeConfig配置。AL2023是Amazon Linux的2023版本，相比AL2使用了新的bootstrap机制。正确的NodeConfig应该是一个MIME多部分消息，包含cloud-init配置和EKS节点引导配置。AI发现了配置中的语法错误和缺失字段。
  • 第三个问题，AI注意到containerd和kubelet服务处于inactive状态。通过分析systemctl输出，AI判断这是服务配置错误导致的启动失败，而不是进程崩溃。AI建议在修复前两个配置问题后，使用systemctl命令重新启动这些服务。

基于这些发现，AI生成了完整的修复计划。

  • 修复IAM Trust Policy，使用aws iam update-assume-role-policy命令更新角色策略，添加ec2.amazonaws.com的AssumeRole权限。
  • 重新配置UserData，使用正确的NodeConfig格式，包含集群名称、API端点地址、CA证书数据等必要字段。
  • 重启服务，使用systemctl start命令启动containerd和kubelet。

遇到的问题与优化

在测试过程中，我们也遇到了一些实际问题和挑战。比如SSM文档的执行时间，AWSSupport-TroubleshootEKSWorkerNode文档执行大约需要2到3分钟，这在大多数情况下是可以接受的，但在紧急故障场景下可能需要优化。我们考虑在后续版本中添加异步执行选项，让用户可以先收到诊断任务已启动的确认，然后在后台等待结果完成。

核心代码结构

class EKSDiagnosisAgent:
    def __init__(self, api_key):
        # SSM执行层
        self.executor = EKSSSMExecutor()
        
        # LLM推理层  
        self.llm = LLMClient(api_key=api_key, model='GLM-5')
    
    def diagnose(self, cluster, node):
        # 1. SSM收集原始数据
        ssm_result = self.executor.run_troubleshoot(cluster, node)
        
        # 2. LLM智能分析
        analysis = self.llm.analyze(ssm_result)
        
        # 3. LLM生成修复方案
        remediation = self.llm.generate_plan(analysis)
        
        return DiagnosisResult(analysis, remediation)

这个方案适合谁

关于适用场景，这个方案最适合以下情况：

适合使用

  • 管理多套EKS集群，需要标准化运维流程
  • 团队水平参差不齐，需要降低诊断门槛
  • 故障响应时间要求高，需要快速定位问题

不太适合

  • 节点数量少，问题简单，传统方式更经济
  • 已有完善的运维体系和知识库
  • 对API调用成本敏感

扩展：从EKS到ECS和Elastic Beanstalk

前面的讨论主要围绕EKS，但这个架构可以很容易地扩展到其他AWS计算服务。核心原因是所有AWS计算服务都支持SSM。无论是EKS、ECS、Elastic Beanstalk还是裸EC2，SSM都提供了统一的日志收集能力，AI提供了统一的分析能力。

具体场景

  • ECS。容器启动失败时，SSM收集ECS Agent、Docker daemon、容器状态和系统日志，AI分析退出原因。

  • Elastic Beanstalk。部署失败时，SSM收集EB引擎、应用、平台和部署历史日志，AI判断是代码问题还是环境问题。

结语：运维工作的未来

回顾整个方案，核心的变化不是用AI替换了人，而是用AI放大了人的能力。过去，运维工程师需要记住几十个命令、数百种错误模式和各种诊断流程。而现在，运维工程师只需要定义问题，AI负责分析，系统负责执行。人做决策，机器做苦力。

这符合技术发展的规律。工业革命时期，机器替代了体力劳动。信息革命时期，计算机替代了计算劳动。而到了智能革命时代，AI开始替代认知劳动。运维工程师的价值将从会敲命令转向会定义问题、评估方案、做最终决策。

本文介绍的AI加SSM架构，只是这个大趋势下的一个小小实践。

posted @ 2026-06-28 02:37  zhaojie10  阅读(6)  评论(0)    收藏  举报