EKS 1.24升级1.25后Filebeat节点发现异常求助

1. 验证CNI插件版本与兼容性 #

EKS 1.25对AWS VPC CNI插件有明确的版本兼容要求，先确认当前集群的插件配置是否与正常集群一致：

• 执行命令查看当前CNI版本：kubectl describe daemonset aws-node -n kube-system | grep Image
• 对比另一个正常1.25+集群的CNI版本，确保两者使用同一兼容版本（EKS 1.25推荐v1.12.x及以上版本）
• 若版本存在差异，将当前集群CNI升级/降级至匹配版本

2. 检查Filebeat与API Server的通信可达性 #

怀疑CNI阻止通信时，直接验证Filebeat Pod到K8s API Server的连通性：

• 进入Filebeat Pod执行测试：kubectl exec -n <filebeat-namespace> <filebeat-pod> -- curl -I https://kubernetes.default.svc
• 在问题节点上执行路由检查：ip route show，对比正常集群的节点路由规则，确认是否存在异常路由拦截API Server请求
• 检查AWS CNI的关键配置（如ENABLE_PREFIX_DELEGATION、AWS_VPC_K8S_CNI_EXTERNALSNAT）是否与正常集群一致，这类配置会影响Pod网络可达性

3. 核对Filebeat的ServiceAccount权限 #

集群升级过程中可能出现权限配置遗漏，需确认Filebeat的权限是否足够获取节点信息：

• 查看Filebeat Pod使用的ServiceAccount：kubectl describe pod <filebeat-pod> -n <namespace> | grep ServiceAccount
• 检查对应ClusterRole的权限：kubectl describe clusterrole <filebeat-cluster-role>，确保包含nodes资源的get、list权限
• 对比正常集群的ClusterRole绑定规则，确认权限配置无差异

4. 验证节点本身的API Server访问能力 #

排除节点层面无法连接API Server的可能：

• 在问题节点上直接访问API Server：curl -k https://<api-server-endpoint>/api/v1/nodes（需使用节点本地kubeconfig或证书）
• 检查节点kubelet配置，确认--api-servers参数指向正确的API Server地址
• 核对节点安全组规则，确保允许节点与API Server的443端口通信

5. 排查CNI插件日志与网络策略 #

• 查看aws-node Pod的运行日志：kubectl logs -n kube-system <aws-node-pod>，搜索是否存在网络配置错误或拦截相关的日志信息
• 检查集群内的网络策略：kubectl get networkpolicy -A，对比正常集群的策略配置，确认是否有规则阻止Filebeat访问API Server

6. 临时验证NODE_NAME环境变量的作用 #

虽然怀疑CNI问题，但可通过添加环境变量快速验证是否能绕过节点发现异常：

• 在Filebeat DaemonSet中添加环境变量配置：

  env:
    - name: NODE_NAME
      valueFrom:
        fieldRef:
          fieldPath: spec.nodeName
  

• 重新部署Filebeat后观察是否仍出现重启，若恢复正常，说明自动节点探测逻辑在当前CNI环境下存在兼容性问题，需进一步排查CNI的主机网络配置

内容的提问来源于stack exchange，提问作者Lucas Abreu