Kubernetes服务发现-跨命名空间 [英] Kubernetes Services Discovery - Cross Namespace
问题描述
我有一个Kubernetes集群,在名称空间A上有serviceA,在名称空间B上有serviceB.
I have a kubernetes cluster with serviceA on namespaceA and serviceB on namespaceB.
我想从serviceA使用kubernetes服务发现以编程方式列出serviceB. 我打算使用春季云kubernetes (@EnableDiscoveryClient).
I want, from serviceA, use kubernetes service discovery to programmatically list serviceB. I am planning to use spring cloud kubernetes ( @EnableDiscoveryClient ).
但是,有一个公司范围内的政策禁止使用下面已解决问题的配置:
spring.cloud.kubernetes.discovery.all-namespaces=true
However, there is a company wide policy to block the use of the configuration below that should have solved the problem:
spring.cloud.kubernetes.discovery.all-namespaces=true
有什么办法可以解决这个问题?也许将serviceB分配给两个不同的名称空间或我不知道的其他权限/配置?
Is there any way to circumvent the problem? Maybe assign serviceB to two different namespaces or some other permission/configuration that I am not aware of?
推荐答案
如果您只是尝试通过Kubernetes API按服务名称查找服务IP,那么通过kubectl
进行操作就没有关系了或Java客户端,您传递给API的选项是相同的.
If you are trying to simply look up a service IP by service name through Kubernetes API than it should not really matter if you're doing it through kubectl
or a Java client, the options you pass to the API are the same.
但是重要的是,将仅在同一名称空间中还是在所有名称空间中查找服务名称.可以通过指定名称和名称空间来从其他名称空间访问服务-他们需要写my-service.some-namespace
代替my-service
.
The thing that matters however is whether the service name would be looked up in the same namespace only or in all namespaces. Accessing a service from a different namespace can be done by specifying its name along with the namespace - instead of my-service
they would need to write my-service.some-namespace
.
没有选择器的服务也是选择将服务从一个名称空间公开到另一个名称空间,以便该名称空间将在Kubernetes对象而不是应用程序代码中指定.
Services without selectors are also an option to expose a service from one namespace to another so that the namespace would be specified in Kubernetes objects and not in app code.
请告诉我是否有帮助.
这篇关于Kubernetes服务发现-跨命名空间的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!