Control which kubernetes nodes chaincode runs on

[jt-nti]

It may be desirable to control which kubernetes nodes chaincode runs on. For example, to use a pool of nodes specifically for running chaincode on, or to run the chaincode on the same node as the peer.

Covering all possible use cases is outside the scope of the k8s builder and should be handled with a Dynamic Admission Control using a Mutating Webhook. For example, it looks like the namespace-node-affinity webhook could be used to assign node affinity and tolerations to all pods in the FABRIC_K8S_BUILDER_NAMESPACE namespace.

Developing and deploying a webhook is not trivial though, so optionally adding basic affinity and toleration to chaincode pods may be useful for simple deployments. For example,

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      – matchExpressions:
        – key: hlf-node-role/chaincode
          operator: Exists
tolerations:
- key: "hlf-node-role/chaincode"
  operator: "Exists"
  effect: "NoSchedule"

Chaincode nodes would then need a corresponding label and taint. For example,

kubectl label nodes node1 hlf-node-role/chaincode
kubectl taint nodes node1 hlf-node-role/chaincode:NoSchedule

[davidfdr]

Very nice upgrade!

[labibfarag]

Also we have to consider that NOT all CC run on the same nodes ,
Example:
each orgs has a set of nodes ,
chaincodes for Org1 run on nodes managed by Org1 ex: node1,
chaincodes for Org2 run on nodes managed by Org2 ex: node2,

[jt-nti]

I think adding a new FABRIC_K8S_BUILDER_NODE_ROLE configuration option should work.

For example, in the simple case with the node role set to "chaincode" the following affinity and toleration would be added:

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: "fabric-builder-k8s-role"
          operator: In
          values:
          - "chaincode"
tolerations:
- key: "fabric-builder-k8s-role"
  operator: "Equal"
  value: "chaincode"
  effect: "NoSchedule"

Nodes with the matching label and taint should then be dedicated to running chaincode. For example:

kubectl label nodes node1 fabric-builder-k8s-role=chaincode
kubectl taint nodes node1 fabric-builder-k8s-role=chaincode:NoSchedule

To handle the case where you want different nodes running different chaincode, different node roles could be configured. For example, "org1cc", "org2cc", etc.

Does that sound ok?