vcluster

vcluster copied to clipboard

If it is necessary to use a specific non default ingress class in the underlying cluster, as is, it would be required to specify that ingress class also in Ingress created inside of the virtual cluster. This can be inconvenient since so much stuff assumes use of default ingress class and forcing accomodation of that onto users of the virtual cluster may be too much to ask. As such, could be a convenient addition to have the syncer accept an option --default-ingress-class=name or similar which if set, would be used as an explicit ingress class on Ingress created in the underlying cluster, if no ingress class is specified in the Ingress inside of the virtual cluster.

Note that this requirement is based purely on pondering theoretical constraints and not something that currently require in practice. Was asked to create issue about it on Slack anyway.

https://loft-sh.slack.com/archives/C01N273CF4P/p1636159855060400

@GrahamDumpleton thanks for creating this issue! Makes sense, we can add this to the ingress syncer

@GrahamDumpleton as we wanted to start working on this, I'm wondering whats the problem with using a default ingress class in the host cluster? https://kubernetes.io/docs/concepts/services-networking/ingress/#default-ingress-class

Or are you refering to the deprecated class annotation?

As I said asking about this was theoretical as worked out whether it made sense. If it doesn't make sense you can possibly ignore it until a real need presents itself.

The background was that encountered an application product which would set up its own ingress class with its own ingress controller stack and thus never set up a default ingress class in the underlying Kubernetes. There attitude was they didn't want people using their ingress controller and was sort of some expectation that people install a separate ingress controller for use as the default. In companies though wouldn't be surprised where they wouldn't allow a second ingress controller or even mapping default ingress controller somehow to that products ingress controller, as they only want to use what the product provides, so stuck using this products ingress class for everything. So was just pondering how you could handle that, or even in general where for some reason you might legitimately having multiple ingress controllers, nginx/contour, and wanted to choose which was used as a default for the whole virtual cluster.

So if you don't see a need for it, I would hold off doing anything about it and see if anyone else might need it.

Since the v0.12.0 the IngressClasses are synced from vcluster to the host, so you could create one in vcluster and mark it as the default one. Combined with the "init manifests" feature you can have that default IngressClass be automatically present in the vcluster immediately after vcluster creation. But I will keep this issue open since we want to allow the sync of Ingress without IngressClass (#755), and with that configuration, this feature request would still make sense.