AWS环境下Kubernetes使用volumeClaimTemplates时Pod Pending问题排查

嘿，咱们来解决你遇到的这个StatefulSet搭配AWS EBS的问题——单副本正常跑，一搞两副本Pod就卡在Pending状态，EBS卷还显示可用。我给你梳理几个排查和解决的方向：

一、先把隐藏的报错信息挖出来 #

你说看不到报错日志，其实Pod在Pending状态时根本还没启动，所以Pod日志是空的。真正的关键信息在Kubernetes事件里，赶紧跑这几个命令看看：

• 查看那两个Pending Pod的详细状态和关联事件：

  kubectl describe pod web2-0 web2-1
  

• 过滤集群里和存储相关的事件，按时间排序找最新的问题：

  kubectl get events --sort-by='.metadata.creationTimestamp' | grep -E 'PersistentVolumeClaim|Volume|EBS'
  

这些命令基本能帮你定位到卷绑定失败的具体原因，比如权限不够、可用区不匹配、存储类配置错了之类的。

二、调整存储类和StatefulSet的配置细节 #

你的K8s服务器版本是1.8.6，kubectl是1.9.2，跨小版本兼容没问题，但配置里有两个过时的地方可能导致动态卷申领失败：

1. 替换过时的存储类注解：
   你在volumeClaimTemplates里用的是旧的alpha注解volume.alpha.kubernetes.io/storage-class，这个在K8s 1.8之后就被废弃了，应该换成标准的storageClassName字段。修改后的volumeClaimTemplates部分应该是这样：

   volumeClaimTemplates:
   - metadata:
       name: mypd1
     spec:
       accessModes: [ "ReadWriteOnce" ]
       storageClassName: mongo-ssd  # 替换原来的alpha注解
       resources:
         requests:
           storage: 10Gi
   

   这个旧注解可能让StatefulSet没法正确触发EBS卷的动态创建。

2. 给StorageClass添加可用区配置（可选但重要）：
   EBS卷是区域绑定的，只能挂载到同一可用区的节点上。如果你的StatefulSet第二个Pod被调度到和第一个Pod不同的可用区，而存储类没配置可用区范围，就会出现卷创建在第一个可用区，第二个Pod跨区无法绑定的情况。给StorageClass加上可用区配置试试：

   kind: StorageClass
   apiVersion: storage.k8s.io/v1beta1
   metadata:
     name: mongo-ssd
   provisioner: kubernetes.io/aws-ebs
   parameters:
     type: gp2
   allowedTopologies:
   - matchLabelExpressions:
     - key: failure-domain.beta.kubernetes.io/zone
       values:
       - us-west-2a  # 换成你集群实际的可用区
       - us-west-2b
       - us-west-2c
   

   这样每个副本的卷会自动创建在Pod所在的可用区，避免跨区绑定失败。

三、检查AWS侧的权限和配额 #

1. 集群IAM权限：
   确保K8s集群的节点IAM角色（或者控制平面的IAM角色）拥有管理EBS卷的权限，必须包含这些权限：

   • ec2:CreateVolume
   • ec2:AttachVolume
   • ec2:DescribeVolumes
   • ec2:DescribeInstances
   • ec2:DetachVolume
     如果是用EKS或者官方工具部署的集群，一般默认有这些权限，但如果是自定义部署的，得手动给角色加权限。

2. EBS卷配额：
   去AWS控制台的EC2服务里看看当前区域的gp2卷配额是不是已经用完了。如果配额不够，得提交配额提升申请，不然没法创建新的EBS卷。

四、临时测试：手动绑定卷验证 #

如果上面的方法都没解决，你可以手动创建一个EBS卷和PV，绑定到第二个Pod的PVC上，看看Pod能不能启动：

1. 用AWS控制台或者CLI创建一个10Gi的gp2卷，记下卷ID（比如vol-xxxxxxxxxxxxxxxxx）。
2. 创建一个PV的YAML文件：

   kind: PersistentVolume
   apiVersion: v1
   metadata:
     name: manual-pv-1
   spec:
     capacity:
       storage: 10Gi
     accessModes:
       - ReadWriteOnce
     awsElasticBlockStore:
       volumeID: vol-xxxxxxxxxxxxxxxxx  # 替换成你的卷ID
       fsType: ext4
     storageClassName: mongo-ssd
   

3. 应用这个PV：kubectl apply -f pv.yaml
4. 查看PVC状态：kubectl get pvc
   如果PVC绑定成功后Pod能启动，说明问题出在动态卷申领的流程上，回到前面的权限或存储类配置继续排查。

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