request help: What is the recommended way to proxy TCP traffic for Services in other namespaces?

[carefree666]

Issue description

I’m trying to expose TCP Services that are located in a different namespace from APISIX.
TCP routing works when the backend Service is in the same namespace as the ApisixRoute, but fails when the Service is in another namespace.

Question:
What is the recommended or officially supported way to proxy TCP (stream) traffic to Kubernetes Services located in other namespaces?

Environment

• apisix-ingress-controller version 2.0.0-rc5
• kubernetes version 1.24.17

[AlinsRan]

The ApisixRoute does not support cross namespace ref service.

[carefree666]

The ApisixRoute does not support cross namespace

Hi 👋, thanks for your reply! I would like to ask if there is a specific method or documentation example for exposing TCP services in other namespaces. I’m encountering some issues when trying to expose TCP services across namespaces, so having a concrete example or step-by-step guide would be really helpful. Thanks!

[AlinsRan]

Hi 👋, thanks for your reply! I would like to ask if there is a specific method or documentation example for exposing TCP services in other namespaces. I’m encountering some issues when trying to expose TCP services across namespaces, so having a concrete example or step-by-step guide would be really helpful. Thanks!

Perhaps we can use ExternalName's service to bypass it?

apiVersion: v1
kind: Service
metadata:
  namespace: v1
  name: tcp-server-proxy
spec:
  type: ExternalName
  externalName: tcp-service-backend.v2.svc

[carefree666]

Hi 👋, thanks for your reply! I would like to ask if there is a specific method or documentation example for exposing TCP services in other namespaces. I’m encountering some issues when trying to expose TCP services across namespaces, so having a concrete example or step-by-step guide would be really helpful. Thanks!

Perhaps we can use ExternalName's service to bypass it?

apiVersion: v1
kind: Service
metadata:
namespace: v1
name: tcp-server-proxy
spec:
type: ExternalName
externalName: tcp-service-backend.v2.svc

This is indeed how I'm currently implementing it, but I want to confirm if this approach is the optimal one