在AWS EKS(Kubernetes)上部署geth(go-ethereum)的最优解决方案

你遇到的报错本质是geth底层使用的LevelDB数据库自带单进程独占文件锁机制，默认启动的可写geth实例会对/data/geth/chaindata目录加锁防止并发写入损坏数据，多个可写实例同时访问同一个目录时就会触发resource temporarily unavailable的锁冲突报错。

独立持久化卷不是唯一解决方式，可根据你的业务场景选择以下方案：

• 读写分离共享单PV方案（最优先推荐，无存储冗余） #

  仅部署1个可写主节点负责链数据同步，挂载支持ReadWriteMany(RWX)模式的PV（如NFS、NAS、CephFS等共享存储都支持该模式）；其余所有从节点启动时添加--read-only参数启动为只读实例，共享挂载同一个PV，只读模式下geth不会对chaindata目录加锁，仅提供查询、交易广播等服务，不会触发锁冲突。该方案全程只需要存储1份chaindata，完全没有冗余空间占用。

• 精简制备存储类降冗余方案 #

  如果你确实需要多个可写geth实例（如需要多节点承担交易打包、签名等写入类需求），可以将集群存储类配置为**精简制备(Thin Provisioning)**模式，该模式下重复的磁盘数据块只会存储1份物理副本，就算多个Pod挂载逻辑独立的PV，重复的chaindata内容不会重复占用物理磁盘，实际物理存储占用仅比单份chaindata高10%以内，大幅降低冗余开销。

• 快照预热降同步成本方案 #

  如果你的集群没有RWX存储资源，也可以采用StatefulSet部署geth集群，第一个节点完成chaindata全量同步后对PV生成快照，后续新增Pod的PV直接从快照创建，不需要从头同步链数据，大幅降低节点扩容的时间成本，存储冗余可以配合精简制备模式进一步优化。

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