持续监控EKS nodegroup状态并触发事件的最优实现方案

以下两个方案均为无服务器架构，无需维护底层实例，配置复杂度低。

方案1：EventBridge Scheduler + Lambda 定时巡检实现 #

完全匹配你要求的间隔巡检需求，实现步骤如下：

• 提前配置IAM权限：创建Lambda执行角色，附加eks:DescribeNodegroup、sqs:SendMessage权限，以及基础的Lambda日志输出权限
• 编写Lambda核心逻辑，示例代码如下：

import boto3
from botocore.exceptions import ClientError

eks_client = boto3.client('eks')
sqs_client = boto3.client('sqs')

# 替换为你的实际配置
EKS_CLUSTER = "your-cluster-name"
TARGET_NODEGROUP = "your-nodegroup-name"
SQS_URL = "your-sqs-queue-url"

def lambda_handler(event, context):
    try:
        nodegroup_info = eks_client.describe_nodegroup(
            clusterName=EKS_CLUSTER,
            nodegroupName=TARGET_NODEGROUP
        )
        # 可选：扩展其他状态变更检测逻辑
        # 例如判断 nodegroup_info['nodegroup']['status'] 是否为DEGRADED/DELETING等，满足条件时触发消息推送
    except ClientError as err:
        if err.response["Error"]["Code"] == "ResourceNotFoundException":
            # 匹配到资源不存在的返回，发送消息到SQS
            sqs_client.send_message(
                QueueUrl=SQS_URL,
                MessageBody="EKS nodegroup not found"
                # 可自定义MessageAttributes补充业务参数
            )
        else:
            raise err

• 创建EventBridge Scheduler规则，设置触发间隔为你需要的数分钟周期，目标指定为上述Lambda函数即可。

方案2：CloudTrail + EventBridge 事件驱动实时触发 #

如果不需要等待巡检间隔，希望状态变更后秒级触发，可使用该事件驱动方案，无需定时轮询：

• 确认账号已开启CloudTrail，正常采集EKS控制面操作日志
• 创建EventBridge自定义规则，事件匹配模式如下：

{
  "source": ["aws.eks"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["eks.amazonaws.com"],
    "eventName": ["DeleteNodegroup", "CreateNodegroup", "UpdateNodegroupConfig"],
    "requestParameters": {
      "clusterName": ["your-cluster-name"],
      "nodegroupName": ["your-nodegroup-name"]
    }
  }
}

• 规则目标直接配置为SQS队列，或者你需要调用的HTTP API对应的API Gateway/EventBridge API Destination即可，无需编写业务代码即可实现事件实时推送。

方案选型建议 #

• 仅需要固定间隔巡检、对延迟不敏感选方案1，配置逻辑简单，可灵活自定义巡检判断规则
• 需要实时捕获节点组状态变更、避免轮询开销选方案2，事件触发延迟通常在10秒以内。

内容的提问来源于stack exchange，提问作者Anton James