add nodePort service type support for mizar network provider

[h-w-chen]

This is a sub task of #420.

implements full support of mizar network provider for nodePort type of Kubernetes service

When such a nodePort service is created, mizar should allocate the specific port on EVERY node to which the network communication leads to one pod of the service .

Creation:

1. user starts a few pods having specific label (e.g. app=test);
2. user specifies a service of nodePort type, by the specific service label (e.g. app=test);
3. user sees the service created, and have nodePort allocated (e.g. 30567);
4. user checks endpoints of the service, sees the IP addresses of all the pods with app=test label;
5. user initiates connection to a node:nodePort (e.g. curl 172.18.0.3:30567), should be able to lead to one of the pods

Deletion:

• user deletes the service of nodePortType;
• ... (omitted for brevity)
• all network resources allocated for the service, particularly the node port (e.g. 30567), should be clean up and freed

[click2cloud-akshay]

I wanted to add this below parameter in grpc file to establish communication between arktos and Mizar for node port service 1.spec 2.type 3.nodePort 4.selector 5.targetport

:-For reference I have node port service YMAL file. apiVersion: v1 kind: Service metadata: name: my-service spec: type: NodePort selector: app: MyApp ports:

By default and for convenience, the targetPort is set to the same value as the port field.

- port: 80
  targetPort: 80
  # Optional field
  # By default and for convenience, the Kubernetes control plane will allocate a port from a range (default: 30000-32767)
  nodePort: 30007

[clu2xlu]

IF we were to add additional messages in grpc, we will have to make changes in files listed below: https://github.com/CentaurusInfra/mizar/blob/dev-next/mizar/proto/mizar/proto/builtins.proto#L48-L54 https://github.com/CentaurusInfra/mizar/blob/dev-next/mizar/arktos/arktos_service.py#L72-L85

However, I would suggest we by-pass arktos first. We can add this feature in stand-a-lone mizar for now. (Deployment is managed by kind-setup.sh file). If we by-pass arktos, there is no need to change grpc.

@click2cloud-akshay Detailed design discussion is needed after @h-w-chen is back from vacation since he is in charge of this task. For now, please try to deploy mizar by itself, and see if you can make changes to service workflow to add attributes such as nodePort etc.

The deployment steps are:

1. git clone https://github.com/CentaurusInfra/mizar.git
2. cd mizar
3. make
4. ./kind-setup,py dev

[h-w-chen]

@click2cloud-akshay this feature seems to involves multiple components in mizar system; not trivial. If you can come up with KEP-like proposal, that would help community to provide feedback; see KEP for its explanation. However, you can use other form of proposal if appropriate too.

The proposal you had given, is about prpc format extension in the attempt of accommodating NodePort type service. Not very clear which component (API contract) this grpc extension will apply for. Also, what other components should be extended? It is legitimate to design and implement incrementally; however, it is better to have a overall (rough design level) breakdown which serves as roadmap to the full feature.

If you can give a design (online) session, that would be even better.