You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With Fabric 2.4, the Gateway Client feature allows an application developer to connect to a Gateway Peer, or proxy, to the ledger. Behind the scenes, the gateway peer will dispatch contract invocations and requests to a set of Peer gRPCs nodes, providing both reliable / stable network connections as well as some level of load balancing based on maintaining a balanced ledger height.
Implement, in the operator, logic and API extensions for the Peer CRD, such that the peer spec includes a delegation of gatewayPeer: true. When operator reconciles a peer spec with the "gateway peer" flag enabled, it should construct a k8s Service, Ingress, and certificate / SAN alias for the host such that it can be consumed by a gateway-client enabled application.
Some attention to (and overridden if possible), the k8s load balancing strategy for client -> gateway connections should be made. By default this is "round robin" across Deployments backing a Service.
Also note that the k8s Service should support TWO different URLs / SANs for access:
external traffic routed via Ingress
internal traffic routed via K8s internal / namespace-local networks.
The text was updated successfully, but these errors were encountered:
With Fabric 2.4, the Gateway Client feature allows an application developer to connect to a Gateway Peer, or proxy, to the ledger. Behind the scenes, the gateway peer will dispatch contract invocations and requests to a set of Peer gRPCs nodes, providing both reliable / stable network connections as well as some level of load balancing based on maintaining a balanced ledger height.
Implement, in the operator, logic and API extensions for the Peer CRD, such that the peer spec includes a delegation of
gatewayPeer: true
. When operator reconciles a peer spec with the "gateway peer" flag enabled, it should construct a k8s Service, Ingress, and certificate / SAN alias for the host such that it can be consumed by a gateway-client enabled application.Some attention to (and overridden if possible), the k8s load balancing strategy for client -> gateway connections should be made. By default this is "round robin" across Deployments backing a Service.
Also note that the k8s Service should support TWO different URLs / SANs for access:
The text was updated successfully, but these errors were encountered: