The “default ingress” of minikube is actually activated through “minikube addons enable ingress”, which activales a recent (0.26.x at the moment) version of the nginx-ingress-controller.
So it’s supposedly the same tool, nginx-ingress-controller, but in a more recent version, that comes “standard” with minikube.
The main difference I see is that the declaration of ingress rules may be done through “Ingress” resources which seems to be the standard way nowadays, whereas in selfmedicate, those were deployment options, somehow. I’m not yet sure how this mixes with deployment specs, like nodePort vs LoadBalancer, vs clusterPort, etc. IIUC, it’s the LoadBalancer part that we’re missing, which “automagically” redirects traffic from the cluster’s external IP to the internal services, that wouldn’t work on selfmedicate.
+1 for not needing metallb if it’s not necessary, but that’s a tool that often pops up in docs about such configuration of Ingress resources, for instance in https://www.eclipse.org/che/docs/che-7/running-che-locally/#installing-che-on-kind-using-chectl_running-che-locally and as KinD and Vagrant VM seemed somehow related, that’s why I was investigating this option. I’m still so bad at networking that I may be confusing elements of topology/protocols… pardon my ignorance (and a nice room for more curricula ?)
I’ll continue to test how we could deploy antidote-core, webssh2 and stuff we need on port 443, in addition to what I now have in the aforementioned vagrant-minikube-eclipse-che setup. All these tests are just so slow to perform