search

networkop / k8s-topo

Topology builder for network simulations inside K8S
BSD 3-Clause "New" or "Revised" License
72 stars 18 forks source link

Adding to Topology #1

Open captainCrench opened 5 years ago

captainCrench commented 5 years ago

If you leave a topology running and feed k8s-topo a second file, will that work? An example would be something like leaving a core set of pods (running say XRv for example) then only adding and destroying edge of the topology pods (csr pods for example).

I could just tear down the core and re-add everytime but if those are always there I feel like that's a waste of time. My guess is this will be tricky adding and deleting the core interfaces that connect to the edge dynamically.

Theoretically what would need to be edited is for k8s-topo to check the YAML file to make sure the links and pods are created already and if not add them (checking etcd?). Both checks would need to be done separately since a pod could be there already but not a link due to connecting a new pod. I think the same needs to be done on the destroy logic too.

captainCrench commented 5 years ago

Also, for new interfaces to take effect in KVM based pods like those in vrnetlab, I think the VM needs to be restarted to add a new interface. Not sure if this would be in this scope or just something that gets done externally of k8s-topo.

networkop commented 5 years ago

I've thought about it for a while and I think this problem can be broken down into two parts:

  1. Making sure meshnet cni and k8s-topo can handle variable number of links. So far the create/destroy actions will remove all pods (instead of cleaning up individual links). So I'd need to modify k8s-topo to take a more granular approach.
  2. The pods themselves need to be able to "learn" about new connected interfaces. there will be two scenarios here: 2.1 Cloud-native images (cEOS, Quagga/FRR) will need to be able to handle adding/removing interface during runtime. If this doesn't work (I'm pretty sure I remember cEOS not working), there's not much we can do here to help. 2.1 Vrnetlab images. In here we can take the same approach as vrnetlab topology machine, i.e. pre-connect a maximum number of interfaces to bridges. Then it'd be possible to plug "physical" interfaces in and out of those bridges at runtime.

I'll try to tackle these separately whenever I'll have more time. I'm also happy to accept pull requests.