基于Kubernetes的区块链部署相关技术问题咨询

问题1：是否需要配置3个以上的K8s节点？ #

这个取决于你的部署环境和业务可用性要求：

• 测试/PoC环境：当前1 master + 3 worker的配置完全够用，5个独立微服务可以轻松调度在3个worker节点上，足够完成功能验证和小规模测试。
• 生产环境：建议至少扩容到4个worker节点，同时把单master升级为3节点高可用master集群。原因有二：一是单master存在单点故障风险，一旦master节点挂掉整个集群都无法操作；二是3个worker节点没有冗余容量，一旦某个worker故障，上面调度的区块链节点和业务服务会被重新调度到剩余节点，可能出现资源不足的情况，要是你部署的区块链共识节点需要容忍1个以上节点故障，3个节点也满足不了拜占庭容错的最低节点数要求。

问题2：长期来看，在K8s上部署运行区块链是否具备可行性？ #

完全具备可行性，目前不管是联盟链还是公链节点，都有大量生产环境跑在K8s上的落地案例，优势非常匹配区块链的部署需求：

• 你现有的Reader/Writer/Processor这类无状态业务服务，天然适配K8s的Deployment部署、服务发现、负载均衡能力，不用额外做架构改造。
• 有状态的区块链节点可以用StatefulSet部署，能保证稳定的网络标识、持久化存储绑定，完全满足区块链节点需要持久化区块数据、P2P通信需要固定访问标识的要求。
• K8s的PV/PVC能力可以对接云服务商的高性能持久化存储，自动做数据多副本备份，解决裸机部署区块链的数据丢失风险。
  当然落地时需要注意两个核心点：一是要给区块链节点的P2P端口配置正确的NodePort/LoadBalancer规则，保证公网节点可以正常通信；二是给区块存储分配SSD级别的PV，避免IO瓶颈导致区块同步慢、交易确认延迟的问题。

问题3：随着用户量增长，能否实现节点无downtime扩容？ #

可以实现全链路无 downtime 扩容，分两种场景：

• 业务服务扩容：Reader/Writer/Processor这类无状态服务直接调整Deployment的副本数即可，K8s自带的滚动调度机制会保证新副本完全启动并健康检查通过后，才会把流量切过去，不会影响现有请求处理。
• 区块链节点扩容：如果是新增全节点/同步节点，直接调高StatefulSet副本数即可，新节点启动后会自动从现有节点同步全量区块数据，同步完成前不会接入业务流量，完全不影响现有链的运行；如果是新增共识节点，只要你用的共识算法支持动态节点加入，先在链上完成新节点的权限注册，再部署对应的节点Pod即可，整个过程不会中断链的出块和交易处理。
  如果是K8s集群本身的worker节点容量不足，云厂商托管K8s的节点池支持无感新增worker节点，新节点加入集群后会自动承接新调度的Pod，现有运行的服务不受任何影响。

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