CLI 和 Peer/Orderer 之間的連接無法正常工作（Kubernetes 設置）

Question

我在 Kubernetes 集群中運行一個網絡，並且有一個 CLI、一個 Peer 和一個同一組織的 Orderer，每個都在它自己的 Pod 中運行。 我可以毫無問題地創建頻道、安裝鏈碼、批准和提交。 但是，當涉及到鏈代碼調用時，CLI 輸出可能未安裝鏈代碼，而 Peer 記錄到 CLI 的連接失敗。

所以這里是 CLI 命令（更新： with -o org1-orderer:30011 ）：

$ export CORE_PEER_MSPCONFIGPATH=/config/admin/msp
$ peer chaincode invoke -C channel1 -n cc-abac -c '{"Args":["invoke","a","b","10"]}' -o org1-orderer:30011 --clientauth --tls --cafile /config/peer/tls-msp/tlscacerts/ca-cert.pem --keyfile /config/peer/tls-msp/keystore/key.pem --certfile /config/peer/tls-msp/signcerts
/cert.pem

命令行 Output：

2020-07-07 16:47:20.918 UTC [msp] loadCertificateAt -> WARN 001 Failed loading ClientOU certificate at [/config/admin/msp]: [could not read file /config/admin/msp: read /config/admin/msp: is a directory]
2020-07-07 16:47:20.919 UTC [msp] loadCertificateAt -> WARN 002 Failed loading PeerOU certificate at [/config/admin/msp]: [could not read file /config/admin/msp: read /config/admin/msp: is a directory]
2020-07-07 16:47:20.919 UTC [msp] loadCertificateAt -> WARN 003 Failed loading AdminOU certificate at [/config/admin/msp]: [could not read file /config/admin/msp: read /config/admin/msp: is a directory]
2020-07-07 16:47:20.919 UTC [msp] loadCertificateAt -> WARN 004 Failed loading OrdererOU certificate at [/config/admin/msp]: [could not read file /config/admin/msp: read /config/admin/msp: is a directory]
2020-07-07 16:47:20.928 UTC [grpc] Infof -> DEBU 005 parsed scheme: ""
2020-07-07 16:47:20.928 UTC [grpc] Infof -> DEBU 006 scheme "" not registered, fallback to default scheme
2020-07-07 16:47:20.928 UTC [grpc] Infof -> DEBU 007 ccResolverWrapper: sending update to cc: {[{org1-peer1:30151  <nil> 0 <nil>}] <nil> <nil>}
2020-07-07 16:47:20.928 UTC [grpc] Infof -> DEBU 008 ClientConn switching balancer to "pick_first"
2020-07-07 16:47:20.928 UTC [grpc] Infof -> DEBU 009 Channel switches to new LB policy "pick_first"
2020-07-07 16:47:20.928 UTC [grpc] Infof -> DEBU 00a Subchannel Connectivity change to CONNECTING
2020-07-07 16:47:20.928 UTC [grpc] Infof -> DEBU 00b Subchannel picks a new address "org1-peer1:30151" to connect
2020-07-07 16:47:20.928 UTC [grpc] UpdateSubConnState -> DEBU 00c pickfirstBalancer: HandleSubConnStateChange: 0xc000114450, {CONNECTING <nil>}
2020-07-07 16:47:20.928 UTC [grpc] Infof -> DEBU 00d Channel Connectivity change to CONNECTING
2020-07-07 16:47:20.935 UTC [grpc] Infof -> DEBU 00e Subchannel Connectivity change to READY
2020-07-07 16:47:20.935 UTC [grpc] UpdateSubConnState -> DEBU 00f pickfirstBalancer: HandleSubConnStateChange: 0xc000114450, {READY <nil>}
2020-07-07 16:47:20.935 UTC [grpc] Infof -> DEBU 010 Channel Connectivity change to READY
2020-07-07 16:47:20.948 UTC [grpc] Infof -> DEBU 011 parsed scheme: ""
2020-07-07 16:47:20.948 UTC [grpc] Infof -> DEBU 012 scheme "" not registered, fallback to default scheme
2020-07-07 16:47:20.948 UTC [grpc] Infof -> DEBU 013 ccResolverWrapper: sending update to cc: {[{org1-peer1:30151  <nil> 0 <nil>}] <nil> <nil>}
2020-07-07 16:47:20.948 UTC [grpc] Infof -> DEBU 014 ClientConn switching balancer to "pick_first"
2020-07-07 16:47:20.948 UTC [grpc] Infof -> DEBU 015 Channel switches to new LB policy "pick_first"
2020-07-07 16:47:20.948 UTC [grpc] Infof -> DEBU 016 Subchannel Connectivity change to CONNECTING
2020-07-07 16:47:20.948 UTC [grpc] Infof -> DEBU 017 Subchannel picks a new address "org1-peer1:30151" to connect
2020-07-07 16:47:20.948 UTC [grpc] UpdateSubConnState -> DEBU 018 pickfirstBalancer: HandleSubConnStateChange: 0xc000496070, {CONNECTING <nil>}
2020-07-07 16:47:20.948 UTC [grpc] Infof -> DEBU 019 Channel Connectivity change to CONNECTING
2020-07-07 16:47:20.954 UTC [grpc] Infof -> DEBU 01a Subchannel Connectivity change to READY
2020-07-07 16:47:20.955 UTC [grpc] UpdateSubConnState -> DEBU 01b pickfirstBalancer: HandleSubConnStateChange: 0xc000496070, {READY <nil>}
2020-07-07 16:47:20.955 UTC [grpc] Infof -> DEBU 01c Channel Connectivity change to READY
2020-07-07 16:47:20.987 UTC [chaincodeCmd] InitCmdFactory -> INFO 01d Retrieved channel (channel1) orderer endpoint: org1-orderer:30011
2020-07-07 16:47:20.991 UTC [grpc] WithKeepaliveParams -> DEBU 01e Adjusting keepalive ping interval to minimum period of 10s
2020-07-07 16:47:20.991 UTC [grpc] Infof -> DEBU 01f parsed scheme: ""
2020-07-07 16:47:20.991 UTC [grpc] Infof -> DEBU 020 scheme "" not registered, fallback to default scheme
2020-07-07 16:47:20.991 UTC [grpc] Infof -> DEBU 021 ccResolverWrapper: sending update to cc: {[{org1-orderer:30011  <nil> 0 <nil>}] <nil> <nil>}
2020-07-07 16:47:20.991 UTC [grpc] Infof -> DEBU 022 ClientConn switching balancer to "pick_first"
2020-07-07 16:47:20.991 UTC [grpc] Infof -> DEBU 023 Channel switches to new LB policy "pick_first"
2020-07-07 16:47:20.991 UTC [grpc] Infof -> DEBU 024 Subchannel Connectivity change to CONNECTING
2020-07-07 16:47:20.991 UTC [grpc] Infof -> DEBU 025 Subchannel picks a new address "org1-orderer:30011" to connect
2020-07-07 16:47:20.991 UTC [grpc] UpdateSubConnState -> DEBU 026 pickfirstBalancer: HandleSubConnStateChange: 0xc000205a60, {CONNECTING <nil>}
2020-07-07 16:47:20.991 UTC [grpc] Infof -> DEBU 027 Channel Connectivity change to CONNECTING
2020-07-07 16:47:21.000 UTC [grpc] Infof -> DEBU 028 Subchannel Connectivity change to READY
2020-07-07 16:47:21.000 UTC [grpc] UpdateSubConnState -> DEBU 029 pickfirstBalancer: HandleSubConnStateChange: 0xc000205a60, {READY <nil>}
2020-07-07 16:47:21.000 UTC [grpc] Infof -> DEBU 02a Channel Connectivity change to READY
Error: endorsement failure during invoke. response: status:500 message:"make sure the chaincode cc-abac has been successfully defined on channel channel1 and try again: chaincode definition for 'cc-abac' exists, but chaincode is not installed"

我確定它安裝在 channel1 上（存在的唯一頻道，除了 sys-channel）：

$ peer lifecycle chaincode queryinstalled
Installed chaincodes on peer:
Package ID: cc-abac:4992a37bf5c7b48f91f5062d9700a58a4129599c53d759e8282fdeffc8836c72, Label: cc-abac

在 Peer 方面，我在日志中得到以下信息（更新）：

[36m2020-07-09 06:45:55.976 UTC [gossip.discovery] periodicalSendAlive -> DEBU 194c[0m Sleeping 5s
[36m2020-07-09 06:45:56.182 UTC [endorser] ProcessProposal -> DEBU 194d[0m request from 10.129.1.229:60184
[36m2020-07-09 06:45:56.182 UTC [endorser] Validate -> DEBU 194e[0m creator is valid channel=channel1 txID=a71312e4 mspID=Org1MSP
[36m2020-07-09 06:45:56.182 UTC [msp.identity] Verify -> DEBU 194f[0m Verify: digest = 00000000  87 29 a0 e5 96 b8 5f 5e  9b e0 fb e5 4d 5b 86 b2  |.)...._^....M[..|
00000010  bd 43 ee 30 59 d6 a9 55  e3 e9 77 7b fd a2 47 8f  |.C.0Y..U..w{..G.|
[36m2020-07-09 06:45:56.182 UTC [msp.identity] Verify -> DEBU 1950[0m Verify: sig = 00000000  30 45 02 21 00 f0 6b 23  9d f6 ec f2 29 be 64 4e  |0E.!..k#....).dN|
00000010  75 69 a7 05 7e 05 71 51  64 6c 52 59 83 be ea f9  |ui..~.qQdlRY....|
00000020  08 5e 07 09 f3 02 20 7a  f7 b0 6c e0 bb 32 b9 0c  |.^.... z..l..2..|
00000030  8c 41 be b8 ea 39 33 91  92 0b 08 9e c6 14 39 e8  |.A...93.......9.|
00000040  46 eb a5 80 7a 7d d1                              |F...z}.|
[36m2020-07-09 06:45:56.182 UTC [endorser] Validate -> DEBU 1951[0m signature is valid channel=channel1 txID=a71312e4 mspID=Org1MSP
[36m2020-07-09 06:45:56.182 UTC [fsblkstorage] retrieveTransactionByID -> DEBU 1952[0m retrieveTransactionByID() - txId = [a71312e411a6b417a541112e2aeac73adc8d6f7fbbb3c62ffcad2348e0c91fac]
[36m2020-07-09 06:45:56.182 UTC [leveldbhelper] GetIterator -> DEBU 1953[0m Getting iterator for range [[]byte{0x63, 0x68, 0x61, 0x6e, 0x6e, 0x65, 0x6c, 0x31, 0x0, 0x74, 0x1, 0x40, 0x61, 0x37, 0x31, 0x33, 0x31, 0x32, 0x65, 0x34, 0x31, 0x31, 0x61, 0x36, 0x62, 0x34, 0x31, 0x37, 0x61, 0x35, 0x34, 0x31, 0x31, 0x31, 0x32, 0x65, 0x32, 0x61, 0x65, 0x61, 0x63, 0x37, 0x33, 0x61, 0x64, 0x63, 0x38, 0x64, 0x36, 0x66, 0x37, 0x66, 0x62, 0x62, 0x62, 0x33, 0x63, 0x36, 0x32, 0x66, 0x66, 0x63, 0x61, 0x64, 0x32, 0x33, 0x34, 0x38, 0x65, 0x30, 0x63, 0x39, 0x31, 0x66, 0x61, 0x63}] - [[]byte{0x63, 0x68, 0x61, 0x6e, 0x6e, 0x65, 0x6c, 0x31, 0x0, 0x74, 0x1, 0x40, 0x61, 0x37, 0x31, 0x33, 0x31, 0x32, 0x65, 0x34, 0x31, 0x31, 0x61, 0x36, 0x62, 0x34, 0x31, 0x37, 0x61, 0x35, 0x34, 0x31, 0x31, 0x31, 0x32, 0x65, 0x32, 0x61, 0x65, 0x61, 0x63, 0x37, 0x33, 0x61, 0x64, 0x63, 0x38, 0x64, 0x36, 0x66, 0x37, 0x66, 0x62, 0x62, 0x62, 0x33, 0x63, 0x36, 0x32, 0x66, 0x66, 0x63, 0x61, 0x64, 0x32, 0x33, 0x34, 0x38, 0x65, 0x30, 0x63, 0x39, 0x31, 0x66, 0x61, 0x63, 0xff}]
[36m2020-07-09 06:45:56.182 UTC [aclmgmt] CheckACL -> DEBU 1954[0m acl policy /Channel/Application/Writers found in config for resource peer/Propose
[36m2020-07-09 06:45:56.182 UTC [aclmgmt] CheckACL -> DEBU 1955[0m acl check(/Channel/Application/Writers)
[36m2020-07-09 06:45:56.183 UTC [policies] EvaluateSignedData -> DEBU 1956[0m == Evaluating *policies.ImplicitMetaPolicy Policy /Channel/Application/Writers ==
[36m2020-07-09 06:45:56.183 UTC [policies] EvaluateSignedData -> DEBU 1957[0m This is an implicit meta policy, it will trigger other policy evaluations, whose failures may be benign
[36m2020-07-09 06:45:56.183 UTC [policies] EvaluateSignedData -> DEBU 1958[0m == Evaluating *cauthdsl.policy Policy /Channel/Application/Org1/Writers ==
[36m2020-07-09 06:45:56.183 UTC [msp.identity] Verify -> DEBU 1959[0m Verify: digest = 00000000  87 29 a0 e5 96 b8 5f 5e  9b e0 fb e5 4d 5b 86 b2  |.)...._^....M[..|
00000010  bd 43 ee 30 59 d6 a9 55  e3 e9 77 7b fd a2 47 8f  |.C.0Y..U..w{..G.|
[36m2020-07-09 06:45:56.183 UTC [msp.identity] Verify -> DEBU 195a[0m Verify: sig = 00000000  30 45 02 21 00 f0 6b 23  9d f6 ec f2 29 be 64 4e  |0E.!..k#....).dN|
00000010  75 69 a7 05 7e 05 71 51  64 6c 52 59 83 be ea f9  |ui..~.qQdlRY....|
00000020  08 5e 07 09 f3 02 20 7a  f7 b0 6c e0 bb 32 b9 0c  |.^.... z..l..2..|
00000030  8c 41 be b8 ea 39 33 91  92 0b 08 9e c6 14 39 e8  |.A...93.......9.|
00000040  46 eb a5 80 7a 7d d1                              |F...z}.|
[36m2020-07-09 06:45:56.183 UTC [policies] SignatureSetToValidIdentities -> DEBU 195b[0m signature for identity 0 validated
[36m2020-07-09 06:45:56.183 UTC [cauthdsl] func1 -> DEBU 195c[0m 0xc0006210e0 gate 1594277156183221199 evaluation starts
[36m2020-07-09 06:45:56.183 UTC [cauthdsl] func2 -> DEBU 195d[0m 0xc0006210e0 signed by 0 principal evaluation starts (used [false])
[36m2020-07-09 06:45:56.183 UTC [cauthdsl] func2 -> DEBU 195e[0m 0xc0006210e0 processing identity 0 - &{Org1MSP 0b33fd619da73c0915b76088b0678047f834593ea6a4f22f0772b36f3c6bd68f}
[36m2020-07-09 06:45:56.183 UTC [cauthdsl] func2 -> DEBU 195f[0m 0xc0006210e0 principal evaluation succeeds for identity 0
[36m2020-07-09 06:45:56.183 UTC [cauthdsl] func1 -> DEBU 1960[0m 0xc0006210e0 gate 1594277156183221199 evaluation succeeds
[36m2020-07-09 06:45:56.183 UTC [policies] EvaluateSignedData -> DEBU 1961[0m Signature set satisfies policy /Channel/Application/Org1/Writers
[36m2020-07-09 06:45:56.183 UTC [policies] EvaluateSignedData -> DEBU 1962[0m == Done Evaluating *cauthdsl.policy Policy /Channel/Application/Org1/Writers
[36m2020-07-09 06:45:56.183 UTC [policies] EvaluateSignedData -> DEBU 1963[0m Signature set satisfies policy /Channel/Application/Writers
[36m2020-07-09 06:45:56.183 UTC [policies] EvaluateSignedData -> DEBU 1964[0m == Done Evaluating *policies.ImplicitMetaPolicy Policy /Channel/Application/Writers
[36m2020-07-09 06:45:56.183 UTC [lockbasedtxmgr] NewTxSimulator -> DEBU 1965[0m constructing new tx simulator
[36m2020-07-09 06:45:56.183 UTC [lockbasedtxmgr] newLockBasedTxSimulator -> DEBU 1966[0m constructing new tx simulator txid = [a71312e411a6b417a541112e2aeac73adc8d6f7fbbb3c62ffcad2348e0c91fac]
[36m2020-07-09 06:45:56.183 UTC [stateleveldb] GetState -> DEBU 1967[0m GetState(). ns=_lifecycle, key=namespaces/fields/cc-abac/Sequence
[36m2020-07-09 06:45:56.183 UTC [lockbasedtxmgr] Done -> DEBU 1968[0m Done with transaction simulation / query execution [a71312e411a6b417a541112e2aeac73adc8d6f7fbbb3c62ffcad2348e0c91fac]
[34m2020-07-09 06:45:56.183 UTC [comm.grpc.server] 1 -> INFO 1969[0m unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=10.129.1.229:60184 grpc.peer_subject="CN=org1-peer1,OU=peer,O=Hyperledger,ST=North Carolina,C=US" grpc.code=OK grpc.call_duration=1.225382ms
[36m2020-07-09 06:45:56.186 UTC [grpc] warningf -> DEBU 196a[0m transport: http2Server.HandleStreams failed to read frame: read tcp 10.130.2.65:7051->10.129.1.229:60184: read: connection reset by peer
[36m2020-07-09 06:45:56.186 UTC [grpc] infof -> DEBU 196b[0m transport: loopyWriter.run returning. connection error: desc = "transport is closing"
[36m2020-07-09 06:45:56.186 UTC [grpc] infof -> DEBU 196c[0m transport: loopyWriter.run returning. connection error: desc = "transport is closing"

[更新]消息unary call completed grpc.service=protos.Endorser grpc.method=ProcessProposal grpc.peer_address=10.129.1.229:60184 grpc.peer_subject="CN=org1-peer1,OU=peer,O=Hyperledger,ST=North Carolina,C=US" grpc.code=OK grpc.call_duration=1.225382ms表示 Peer 將 CLI 視為另一個 Peer，不是嗎？ 如果是這樣，那么連接失敗的原因就很清楚了。 現在的問題是，為什么 Peer 會這樣認為？

對等體：10.130.2.65
命令行：10.129.1.229

親切的問候

Answer 1

不幸的是，所有 GRPC 日志和 k8s 相關問題似乎都是一個紅鯡魚。 連接正在正確建立，“對等方”一詞在 GRPC 日志中只是有點令人困惑，因為 GRPC 總是將“線路另一端的一方”稱為“對等方”。 這個術語在 Fabric 中以不同的含義重復使用。

如日志所示，鏈碼已成功批准並在通道上定義。

正如對等 CLI output 所示，您已經安裝了一個帶有 package-id cc-abac:4992a37bf5c7b48f91f5062d9700a58a4129599c53d759e8282fdeffc8836c72 。

但是，在調用時，您會看到以下錯誤：

chaincode definition for 'cc-abac' exists, but chaincode is not installed

這意味着當您進行鏈碼批准時，您要么沒有指定包 ID，要么指定了不正確的 package id。

如果您使用的是 v2.2+ 版本的 Fabric，您應該能夠使用對peer lifecycle queryapproved實用程序查看您選擇的 package ID。

您可以使用正確的 package-id ( cc-abac:4992a37bf5c7b48f91f5062d9700a58a4129599c53d759e8282fdeffc8836c72 ) 重新運行對peer lifecycle approveformyorg ，這應該可以糾正問題。