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
Evaluating the capability to support kind https://kind.sigs.k8s.io/ (or potentially other k8s implementations) in a KNE topology build.
Use case associated : to be able to test, validate build topologies which includes CNI specific capabilities. In that case, the nested kind cluster must be able to implement off the shelf CNIs connected to emulated network topology (see attached diagram).
The text was updated successfully, but these errors were encountered:
Not sure I follow exactly what you want here (although the diagram is definitely helpful). Would utilizing the node HOST implementation work for this?
The HOST node could either use a base linux container which could be set up to talk with the existing kind worker nodes or potentially the HOST node could bring up kind node container image directly?
Alex think about more like there is a KNE instance which has the CNI connecting all the nodes for that cluster
dabernie has an other k8s cluster that they want to have network connectivity over the KNE cluster's meshnet CNI
So you could either have kne meshnet create "external" ports which could then be "wired" to the other k8s instance or you could use host nodes maybe in the way you were thinking to create a k8s instance over the kne instance i think this would be much more problematic to maintain
Evaluating the capability to support kind https://kind.sigs.k8s.io/ (or potentially other k8s implementations) in a KNE topology build.
Use case associated : to be able to test, validate build topologies which includes CNI specific capabilities. In that case, the nested kind cluster must be able to implement off the shelf CNIs connected to emulated network topology (see attached diagram).
The text was updated successfully, but these errors were encountered: