Adding a new Network Services Endpoind to the running NSC

[nephilimboy]

Hi all,

Considering the NSM multiple-services example, is there anyway to add a new end point service (with different name) to the existing/running NSC (the NSC which already existed)?

Assume the below NSC's YAML file

---
apiVersion: v1
kind: Pod
metadata:
  name: alpine
  labels:
    app: alpine
  annotations:
    networkservicemesh.io: kernel://multiple-services-1/nsm-1,kernel://multiple-services-2/nsm-2
spec:
  containers:
  - name: alpine
    image: alpine:3.15.0
    imagePullPolicy: IfNotPresent
    # simple `sleep` command would work
    # but we need `trap` to be able to delete pods quckly
    command: ["/bin/sh", "-c", "trap : TERM INT; sleep infinity & wait"]

Is there anyway to change and then apply the annotations part in the Yaml and add the 3rd Network Services Endpoind like below while the NSC pod is running? In my use case I am not allowed to recreate the NSC pods.

annotations:
    networkservicemesh.io: kernel://multiple-services-1/nsm-1,kernel://multiple-services-2/nsm-2,kernel://multiple-services-3/nsm-3

My issue may be related to the #9889 but what I am trying to do is to add a new endpoint (as well as a new kernel type interface) to the running NSC pod. To elaborate on my use case, currently I am working on a monitoring framework for pod-to-pod connectivity for network Service Function Chaining (SFC). This framework detects any connectivity failure in the service chain and changes the traffic routing using a customized virtual router container in the NSC pods. This customized virtual router uses the Kernel type interfaces created by the NSC sidecar container to route the traffic to different endpoints using a different Kernel-type interface in the Pod.

I appreciate any suggestions or workaround about this matter.

[denis-tingaikin]

Hello @nephilimboy !

At this moment, we're not providing the example that you're looking for. At this moment, we're using annotations only for external clients, like pods or deployments in K8s.

But we also provide a flexible NSM API that allows you to do what you want.

You may find an example of client code usage here: https://github.com/networkservicemesh/cmd-nsc/blob/main/main.go#L272

To achieve dynamic endpoint addition for the NSC, we will probably need to create a new NSC app that will read NSM urls from the configmap.

[nephilimboy]

Hi @denis-tingaikin ,

Thanks for your reply. I appreciate your explanation. So, just to make sure I understand correctly, I should run a new NCS code (cmd-nsc) in the existing NSC pod to add a new endpoint? Originally, I was planning to add a new cmd-nsc sidecar container to the existing pod, but as you know, only an Ephemeral container can be added to the existing pod which has limited features.

[denis-tingaikin]

The trick here is that we can't dynamically change the annotation of the deployment without re-deploying. To do it, we can create a new cmd-nsc-... application that may read a list of NSM URLs via a mounted config file.

Another thing that I'd like to point out here is that we're able to change nses dynamically via network service change: https://github.com/networkservicemesh/deployments-k8s/tree/main/examples/features/change-nse-dynamically.

/cc @edwarnicke

[edwarnicke]

@nephilimboy Could you help us understand a bit more the underlying thing you are trying to do that requires this? Its an interesting requirement, and we've seen it before for more complex CNFs, but those are usually running their own NSM client to micromanage things, rather than relying on the annotations. The annotations are traditionally used by folks with more traditional non-NSM aware applications. It would be quite interesting to understand your case better :)