我想做的是在default
命名空间中有一个服务,并在我的其他命名空间中进入,该服务指向该服务。我尝试实现如下所示的服务和Ingress,但没有用。
kind: Service
apiVersion: v1
metadata:
name: serviceX
namespace: default
spec:
type: ExternalName
externalName: serviceX.default.svc.cluster.local
ports:
- port: 123
kind: Ingress
apiVersion: extensions/v1beta1
metadata:
name: web-ingress-test-vpndev
namespace: my-namespace
spec:
tls:
- hosts:
- abc.my-namespace.domain.com
secretName: tls-secret-my-namespace
rules:
- http:
paths:
- path: "/"
backend:
serviceName: serviceX
servicePort: 123
status:
loadBalancer:
ingress: {}
我知道我可以在每个名称空间中实现该服务,但是我想知道是否可以拥有一个服务。如果我尝试在入口的externalName
处理程序中键入服务的backend->serviceName
,则会出现错误并指出服务的名称只能包含数字,字母和'-'。>
答案 0 :(得分:2)
我认为这是不可能的,也不认为这是个好主意。入口不是群集级资源。每个名称空间都应该有自己的实例。
答案 1 :(得分:2)
我不得不说这不是一个好方法。因为不同NS中的所有入口都将转换为Nginx规则,并在入口控制器容器中生效。
如果您看一下Nginx规则(入口控制器窗格中的nginx.conf
),您会看到location
中nginx.conf
的每个块都有变量set $namespace "****";
,其中表示入侵已被NS隔离
此外,如果您仍然想实现自己的想法,则可能需要修改入口控制器。
答案 2 :(得分:0)
我使用Istio实现了这一目标。这不是我们使用它的主要原因,但是流量管理功能允许这种事情。
+--Namespace A-------------------------------+
| |
| +-------+ +-------+ +--------------+ |
| |Ingress+--->Service+--->VirtualService| |
| +-------+ +-------+ +------+-------+ |
| | |
+--------------------------------------------+
|
+---------------+
|
| +--Namespace B---------+
| | |
| | +-------+ +---+ |
+--------->Service+---->Pod| |
| +-------+ +---+ |
| |
+----------------------+
使用Istio,您可以将入口放入一个名称空间,没有选择器的服务(因为此处没有吊舱)和将服务上的流量路由到service.namespaceB的虚拟服务。
我正在使用它来实现蓝绿色部署。想象一下与上述相同的原理,但是具有3个名称空间:
蓝色和绿色版本之间的切换由名称空间-A中的virtualService管理。优点是您可以在将istio发布给所有人之前,使用istio的路由功能测试绿色版本(烟雾测试)。