Kubernetes(EKS)环境Ethereum节点创世initContainer打开数据库失败 资源暂时不可用

根因分析 #

• RWO存储卷并发挂载冲突：你使用的PVC底层是AWS EBS gp2存储，访问模式为ReadWriteOnce，这类存储同一时间只能挂载到同一个EC2节点上的一个Pod进行读写操作。如果Deployment副本数大于1，或者滚动发布时旧Pod还未完全终止、EBS卷未完成解绑，新启动的Pod就会无法正常挂载存储卷，访问链数据目录时报resource temporarily unavailable错误。
• initContainer逻辑缺陷：geth init命令仅适用于初始化空目录的创世区块数据，当PV中已经存在同步过的存量链数据时，LevelDB数据库默认会加锁保护，再次执行init命令尝试修改已有数据库文件时，就会抛出数据库打开失败的报错。

修复方案 #

非生产环境验证步骤 #

你可以先在测试环境验证以下逻辑正确性，避免生产操作风险：

1. 拿存量的链数据目录，使用同版本的ethereum/client-go:alltools-v1.8.27镜像执行geth init命令，确认可以复现相同的数据库报错
2. 启动一个测试Pod挂载测试用的EBS RWO卷保持运行，再启动第二个Pod尝试挂载同个PVC，确认可以复现资源不可用的报错

生产环境修复步骤 #

1. 修正initContainer执行逻辑：调整initContainer的启动命令，增加链数据目录存在性判断，避免重复执行创世初始化操作：

initContainers:
- name: genesis
  image: 'ethereum/client-go:alltools-v1.8.27'
  command: ["/bin/sh", "-c"]
  args:
  - |
    if [ ! -d /ethereum/geth/chaindata ]; then
      geth --datadir=/ethereum init /tmp/json/genesis.json
    else
      echo "chaindata already exists, skip genesis init"
    fi
  volumeMounts:
  - name: config
    readOnly: true
    mountPath: /tmp/json/genesis.json
    subPath: genesis.json
  - name: chaindata
    mountPath: /ethereum

2. 调整Deployment发布策略：由于使用RWO存储，必须将发布策略改为Recreate，确保旧Pod完全终止、存储卷解绑后再启动新Pod，彻底避免挂载冲突：

spec:
  strategy:
    type: Recreate

3. 可选：数据损坏修复：如果确认当前PV中的链数据已经损坏需要重新初始化，先停止所有关联的Pod，备份PV中的全量数据后，删除/ethereum/geth目录下的所有内容，再重新启动Pod即可执行创世初始化。

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