Hyperledger Fabric 1.4迁移至Kubernetes 1.19后无法连接Docker端点如何解决

根因说明 #

Azure Kubernetes 1.19版本相比1.17有两处核心变更会影响Fabric Peer的Docker端点连接：

1. AKS 1.19默认将容器运行时从Docker切换为containerd，节点宿主机不再默认存在/var/run/docker.sock文件，原有hostPath挂载的sock路径失效
2. 1.19版本默认强化了Pod安全策略限制，即使节点保留Docker运行时，未做特殊权限配置的Pod也无法直接访问宿主机的Docker sock文件

可行解决方案 #

你提到的将CORE_VM_ENDPOINT调整为tcp://docker:2375是可行方案，需满足以下前置条件：

• 集群内已部署独立的Docker in Docker（DinD）工作负载，且配置了名为docker的ClusterIP Service，暴露2375端口（测试环境可用非TLS模式，生产环境建议使用2376 TLS端口避免未授权访问）
• 集群未配置NetworkPolicy禁止Peer Pod访问DinD Service的2375端口
• DinD工作负载配置了持久化存储，避免Pod重启后已构建的链码容器丢失，同时配置了足够的CPU、内存资源配额

如果不想维护独立DinD服务，也可以选择以下两种方案：

• 若AKS节点仍保留Docker运行时：调整Peer Pod的安全上下文配置，开放Docker sock访问权限，参考配置如下：

securityContext:
  privileged: true
volumes:
- name: docker-sock
  hostPath:
    path: /var/run/docker.sock
    type: Socket
volumeMounts:
- name: docker-sock
  mountPath: /host/var/run/docker.sock

• 长期方案：将Fabric版本升级至2.3及以上，该版本开始支持外部链码运行模式，不需要依赖Docker守护进程构建、启动链码，可彻底规避Docker端点连接问题

TCP连接模式验证步骤 #

1. 进入Peer Pod执行nc -zv docker 2375，确认与DinD服务的网络连通性
2. 修改Peer的环境变量配置：CORE_VM_ENDPOINT=tcp://docker:2375
3. 重启Peer Pod，重新安装、实例化链码，调用链码验证功能正常

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