AWS上Helm部署Prometheus Alertmanager失败问题排查

我之前在kops搭建的K8s集群里部署Prometheus时，遇到过和你几乎一模一样的问题——Alertmanager Pod CrashLoopBackOff、挂载EBS卷失败，明明控制台看卷是正常的但K8s就是报状态不对。结合你的描述，我整理了几个最可能的原因和对应的解决步骤：

1. K8s与AWS EBS的状态不同步 #

有时候AWS控制台显示卷处于“可用”状态，但K8s的云控制器（cloud-controller-manager）或者节点上的kubelet没有及时同步到这个状态，导致挂载请求被错误地拒绝。

• 解决步骤：
  1. 先确认PV的状态：

     kubectl get pv pvc-a4c420a5-01b3-11e8-a981-06b56e90ab12
     

     看PV是否处于Bound或Available状态
  2. 重启对应节点的kubelet，强制同步卷状态：

     ssh <节点IP> sudo systemctl restart kubelet
     

  3. 删除异常的Alertmanager Pod，让K8s重新调度尝试挂载：

     kubectl delete po soft-flee-monitoring-alertmanager-5f56f7879d-sg5lx
     

2. 卷与Pod所在节点的可用区不匹配 #

EBS卷是可用区绑定的，只能挂载到同一AZ的EC2实例上。如果你的PVC提前创建了卷（比如StorageClass用了Immediate绑定模式），而Pod被调度到了其他AZ的节点，就会出现挂载失败——卷本身是可用的，但跨AZ无法挂载。

• 排查步骤：
  1. 查看PV对应的可用区：

     kubectl describe pv pvc-a4c420a5-01b3-11e8-a981-06b56e90ab12 | grep "availabilityZone"
     

  2. 查看Pod所在节点的可用区：

     kubectl describe node $(kubectl get po soft-flee-monitoring-alertmanager-5f56f7879d-sg5lx -o jsonpath='{.spec.nodeName}') | grep "failure-domain.beta.kubernetes.io/zone"
     

• 解决办法：
  • 最彻底的方式是修改默认StorageClass为WaitForFirstConsumer绑定模式（PVC会等Pod调度后再创建对应AZ的卷）：

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: gp2  # 替换成你的默认StorageClass名称
    provisioner: kubernetes.io/aws-ebs
    parameters:
      type: gp2
    volumeBindingMode: WaitForFirstConsumer
    reclaimPolicy: Delete
    

    应用后删除现有PVC和PV，让Helm重新创建：

    kubectl delete pvc $(kubectl get pvc | grep alertmanager | awk '{print $1}')
    

  • 临时解决：给Alertmanager Deployment添加节点亲和性，强制调度到卷所在的AZ：
    在Helm的values.yaml里添加如下配置，然后执行helm upgrade：

    alertmanager:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: failure-domain.beta.kubernetes.io/zone
                operator: In
                values:
                - <卷所在的AZ，比如us-west-2a>
    

3. 节点IAM角色缺少EBS操作权限 #

kops创建的节点实例需要具备操作EBS卷的IAM权限（比如挂载、描述卷），如果权限缺失，即使卷状态正常，节点也无法完成挂载流程。

• 排查步骤：
  1. 登录AWS控制台，找到异常Pod所在节点的EC2实例，查看其关联的IAM角色名称
  2. 用AWS CLI检查角色的权限：

     aws iam list-attached-role-policies --role-name <节点IAM角色名>
     

     确认是否包含AmazonEKSWorkerNodePolicy或自定义的包含ec2:AttachVolume、ec2:DescribeVolumes、ec2:DetachVolume的策略
• 解决办法：
  给节点IAM角色添加包含以下权限的自定义策略：

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "ec2:AttachVolume",
          "ec2:DescribeVolumes",
          "ec2:DetachVolume"
        ],
        "Resource": "*"
      }
    ]
  }
  

  权限生效后，重启节点kubelet或重新调度Pod即可。

4. EBS卷存在残留的挂载关联 #

有时候AWS控制台显示卷是“可用”，但实际上卷还和某个已终止的实例存在挂载关联（比如之前的Pod异常终止，卷没正确卸载），导致无法挂载到新节点。

• 排查步骤：
  用AWS CLI查看卷的挂载详情：

  aws ec2 describe-volumes --volume-ids vol-0c8c9d3794bdbec90
  

  检查Attachments字段，如果存在实例ID（即使实例状态是terminated），说明有残留关联。
• 解决办法：
  手动解除残留的挂载关联：

  aws ec2 detach-volume --volume-id vol-0c8c9d3794bdbec90 --instance-id <残留的实例ID>
  

  等待2-3分钟后，删除Alertmanager Pod让它重新尝试挂载。

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