What are you trying to do?
A stated purpose of the ProxyGroup is to "Expose many Service and Ingress resources to your tailnet using a smaller number of proxy Pods." (https://tailscale.com/kb/1439/kubernetes-operator-cluster-ingress#high-availability)
However, the service/ingress resources that I would like to expose are littered around in many different namespaces in my k8s cluster. The current implementation of how to reference proxy groups (the "tailscale.com/proxy-group" annotation) necessitates that the proxy group lives in the same namespace as the service. In effect this means I have to create a separate proxy group for each namespace, which in turn ends up wasting a bunch of resources, and doesn't really help use "a smaller number of proxy Pods".
How should we solve this?
Allow the namespace to be specified on service/ingress resource annotaions by either:
- Using the "/" delimiter in the existing "tailscale.com/proxy-group" annotation
- Add support for an additional (optional) "tailscale.com/proxy-group-namespace" annotation
What is the impact of not solving this?
No response
Anything else?
No response
What are you trying to do?
A stated purpose of the ProxyGroup is to "Expose many Service and Ingress resources to your tailnet using a smaller number of proxy Pods." (https://tailscale.com/kb/1439/kubernetes-operator-cluster-ingress#high-availability)
However, the service/ingress resources that I would like to expose are littered around in many different namespaces in my k8s cluster. The current implementation of how to reference proxy groups (the "tailscale.com/proxy-group" annotation) necessitates that the proxy group lives in the same namespace as the service. In effect this means I have to create a separate proxy group for each namespace, which in turn ends up wasting a bunch of resources, and doesn't really help use "a smaller number of proxy Pods".
How should we solve this?
Allow the namespace to be specified on service/ingress resource annotaions by either:
What is the impact of not solving this?
No response
Anything else?
No response