tailscale
FR: Make ingressClassName for k8s operator configurable
What are you trying to do?
Background I run a cluster with multiple nginx ingress controllers, all tied to their own loadbalancer ports. This cluster and its ingresscontrollers date back to before the availability of the tailscale kubernetes operator. One of the ingresses is running on a tailscale IP, and its ingressClassName is aptly named tailscale, This works well: devs understand what an ingress resource named tailscale does, and externaldns picks up the resource and creates a record in our zone that points to the tailscale IP of the loadbalancer resource that serves the ingress controller. Some devs have expressed the need for a way of creating new resources without the immediate creation of a hostname in our domain. Running a service on a host with a mynetwork.ts.net suffix is good enough for these services.
Installing the operator Upon installation of the helm chart, the operator will create an ingressClass resource named tailscale. The name is not configurable, though I can disable creation (lines 76-77) if I want to.
I don't know what happens if I install the operator in this cluster, with or without the ingressClass. I suspect installing the ingressClass fails, because a resource with that name already exists in my cluster. What I don't know, is whether the operator will start monitoring my ingress resources for the tailscale ingressClass and subsequently take these over from the ingress nginx controller that watches the same name. I haven't tried.
How should we solve this?
Make the ingressClassName configurable. Don't hardcode it.
What is the impact of not solving this?
With certainty: I will have to rename the ingressClassName in my existing ingress controller AND all ingress resources that are currently deployed on the cluster.
Possibly: mayhem because the operator will start a fight with the existing controller that watches for the same ingressClassName.
Anything else?
No response
I had to wait for our maintenance window before I could test the ingresses that are already deployed with an ingressClass of tailscale: as I expected, these are taken over by the operator.
Hey @cathelijne, this seems like a reasonable addition and helps you on the onboarding path for your cluster. I've started taking a look into how we make this customisable.
Hey @cathelijne, this seems like a reasonable addition and helps you on the onboarding path for your cluster. I've started taking a look into how we make this customisable.
That is fantastic news! Really happy that you want to take this ito consideration.
Hey @cathelijne, I've implemented and tested a solution for using custom ingress class names. Please keep an eye out for the next release where this should be supported.
Specifically, when installed using helm you can now specify ingressClass.name. If you're using static manifests, you'll need to do some manual work to set the new environment variable on the operator and create the ingress class.
Hopefully this helps!
Hey @cathelijne, I've implemented and tested a solution for using custom ingress class names. Please keep an eye out for the next release where this should be supported.
Specifically, when installed using helm you can now specify
ingressClass.name. If you're using static manifests, you'll need to do some manual work to set the new environment variable on the operator and create the ingress class.Hopefully this helps!
That's amazing! I'm using argocd, with a very minimal valuesObject (I think just the standard values.yaml from the docs or example). But manual work doesn't bother me one bit.
Will keep an eye out for the next release and report back here.