服务位于另一个名称空间

我一直试图找到一种方法来在一个命名空间中定义服务，该服务链接到在另一个命名空间中运行的Pod。我知道运行Pod的容器namespaceA可以通过在群集DNS中将其引用为来访问serviceX定义的内容，但是我宁愿容器内的代码不需要知道的位置。也就是说，我希望代码只是查找然后可以访问它。namespaceBserviceX.namespaceB.svc.cluster.localserviceXserviceX

该Kubernetes文档表明这是可能的。它说，没有选择器就定义服务的原因之一是，您想将服务指向另一个命名空间或另一个群集中的服务。

这表明我应该：

1. 在中定义serviceX服务namespaceA，不带选择器（因为我要选择的POD不在中namespaceA）。
2. 在中定义服务（我也称为serviceX）namespaceB，然后
3. 在中定义一个Endpoints对象namespaceA以指向serviceXin namespaceB。

这是我无法完成的第三步。

首先，我尝试以这种方式定义Endpoints对象：

kind: Endpoints
apiVersion: v1
metadata:
  name: serviceX
  namespace: namespaceA
subsets:
  - addresses:
      - targetRef:
          kind: Service
          namespace: namespaceB
          name: serviceX
          apiVersion: v1
    ports:
      - name: http
        port: 3000

这似乎是合乎逻辑的方法，而且显然targetRef是为了什么。但是，这导致一个错误，表明数组中的ip字段addresses是必填字段。因此，我的下一个尝试是为serviceXin 分配一个固定的ClusterIP地址namespaceB，并将其放在IP字段中（请注意，将in service_cluster_ip_range配置为192.168.0.0/16，并将192.168.1.1其分配为serviceXin 的ClusterIP namespaceB；serviceXin namespaceA在192.168.0.0/16子网中自动分配了一个不同的ClusterIP ） ：

kind: Endpoints
apiVersion: v1
metadata:
  name: serviceX
  namespace: namespaceA
subsets:
  - addresses:
        - ip: 192.168.1.1
          targetRef:
            kind: Service
            namespace: namespaceB
            name: serviceX
            apiVersion: v1
    ports:
      - name: http
        port: 3000

那被接受了，但是进入serviceXin的访问namespaceA没有转发到Pod in- namespaceB他们超时了。查看iptables设置，看起来它必须要做两次NAT预路由才能完成此任务。

但并不是一个令人满意的解决方案- -我确实发现了工作的唯一的事情是查找提供吊舱的实际IP地址serviceX中namespaceB，并把该地址在端点对象namespaceA。当然，这并不令人满意，因为Pod IP地址可能会随着时间变化。这就是服务IP需要解决的问题。

因此，有没有一种方法可以满足文档中的承诺，即我可以将一个命名空间中的服务指向在另一个命名空间中运行的服务？

一位评论者质疑您为什么要执行此操作-这对我来说至少是一个用例：

假设您有一个多租户系统，该系统还包括可以在租户之间共享的通用数据访问功能。现在想象一下，使用通用API的数据访问功能有不同的风格，但是性能特征也不同。一些租户可以访问其中一个，其他租户可以访问另一个。

每个租户的Pod在各自的名称空间中运行，但是每个人都需要访问这些公共数据访问服务之一，该服务必定​​在另一个名称空间中（因为它被多个租户访问）。但是，如果租户的订阅发生更改以访问性能更高的服务，则您不希望租户更改其代码。

一个可能的解决方案（如果可以的话，我认为是最干净的解决方案）是在每个租户的数据访问服务的命名空间中包含一个服务定义，并为每个端点配置适当的端点。该服务定义将配置为指向每个租户有权使用的正确数据访问服务。

我偶然发现了相同的问题，发现了一个不需要任何静态ip配置的不错的解决方案：

您可以通过服务的DNS名称（如您所述）访问服务：servicename.namespace.svc.cluster.local

您可以使用该DNS名称通过本地服务在另一个名称空间中引用它：

kind: Service
apiVersion: v1
metadata:
  name: service-y
  namespace: namespace-a
spec:
  type: ExternalName
  externalName: service-x.namespace-b.svc.cluster.local
  ports:
  - port: 80

做起来很简单

如果要使用它作为主机并要解决它

如果您使用大使身份访问位于其他命名空间中的任何其他API网关以获取服务，则始终建议使用：

            Use : <service name>
            Use : <service.name>.<namespace name>
            Not : <service.name>.<namespace name>.svc.cluster.local

它会像： servicename.namespacename.svc.cluster.local

这会将请求发送到您提到的名称空间内的特定服务。

例：

kind: Service
apiVersion: v1
metadata:
  name: service
spec:
  type: ExternalName
  externalName: <servicename>.<namespace>.svc.cluster.local

在此将<servicename>和替换为<namespace>适当的值。

在Kubernetes中，名称空间用于创建虚拟环境，但是所有名称空间都相互连接。

您可以通过在比命名空间的服务更高的层上部署某些东西来实现此目的，例如服务负载均衡器 https://github.com/kubernetes/contrib/tree/master/service-loadbalancer。如果要将其限制为单个名称空间，请使用“ --namespace = ns”参数（默认为所有名称空间：https : //github.com/kubernetes/contrib/blob/master/service-loadbalancer/service_loadbalancer.go ＃L715）。这对于L7效果很好，但对于L4则有点混乱。