Spring Cloud Kubernetes和ConfigMaps跨多个名称空间

Question

在阅读Spring Cloud Kubernetes文档时，似乎Spring Cloud Kubernetes支持跨多个名称空间从配置映射加载属性。以下是文档中的示例:

spring:
  application:
    name: cloud-k8s-app
  cloud:
    kubernetes:
      config:
        name: default-name
        namespace: default-namespace
        sources:
         # Spring Cloud Kubernetes looks up a ConfigMap named c1 in namespace default-namespace
         - name: c1
         # Spring Cloud Kubernetes looks up a ConfigMap named default-name in whatever namespace n2
         - namespace: n2
         # Spring Cloud Kubernetes looks up a ConfigMap named c3 in namespace n3
         - namespace: n3
           name: c3

然而，根据Kubernetes文档，“Pod和ConfigMap必须位于同一名称空间中。”

那么，Spring Cloud Kubernetes是否支持跨多个名称空间从ConfigMaps加载属性？如果支持，允许这样做的正确配置是什么？

从与Spring Boot pod相同名称空间中的ConfigMaps加载属性没有问题，但当我尝试加载来自不同名称空间中ConfigMap的属性时（在本例中，＜code＞common＜/code＞），我遇到以下异常：

2021-07-22 21:28:06.658  WARN 1 --- [           main] .KubernetesClientConfigMapPropertySource : Unable to get ConfigMap common in namespace common
io.kubernetes.client.openapi.ApiException: Forbidden
    at io.kubernetes.client.openapi.ApiClient.handleResponse(ApiClient.java:993) ~[client-java-api-11.0.2.jar!/:na]
    at io.kubernetes.client.openapi.ApiClient.execute(ApiClient.java:905) ~[client-java-api-11.0.2.jar!/:na]
    at io.kubernetes.client.openapi.apis.CoreV1Api.listNamespacedConfigMapWithHttpInfo(CoreV1Api.java:28375) ~[client-java-api-11.0.2.jar!/:na]
    at io.kubernetes.client.openapi.apis.CoreV1Api.listNamespacedConfigMap(CoreV1Api.java:28263) ~[client-java-api-11.0.2.jar!/:na]
    at org.springframework.cloud.kubernetes.client.config.KubernetesClientConfigMapPropertySource.getData(KubernetesClientConfigMapPropertySource.java:56) ~[spring-cloud-kubernetes-client-config-2.0.3.jar!/:2.0.3]
    at org.springframework.cloud.kubernetes.client.config.KubernetesClientConfigMapPropertySource.<init>(KubernetesClientConfigMapPropertySource.java:41) ~[spring-cloud-kubernetes-client-config-2.0.3.jar!/:2.0.3]
    at org.springframework.cloud.kubernetes.client.config.KubernetesClientConfigMapPropertySourceLocator.getMapPropertySource(KubernetesClientConfigMapPropertySourceLocator.java:62) ~[spring-cloud-kubernetes-client-config-2.0.3.jar!/:2.0.3]
    at org.springframework.cloud.kubernetes.commons.config.ConfigMapPropertySourceLocator.getMapPropertySourceForSingleConfigMap(ConfigMapPropertySourceLocator.java:81) ~[spring-cloud-kubernetes-commons-2.0.3.jar!/:2.0.3]
    at org.springframework.cloud.kubernetes.commons.config.ConfigMapPropertySourceLocator.lambda$locate$0(ConfigMapPropertySourceLocator.java:67) ~[spring-cloud-kubernetes-commons-2.0.3.jar!/:2.0.3]
    at java.base/java.util.ArrayList.forEach(ArrayList.java:1541) ~[na:na]
    at org.springframework.cloud.kubernetes.commons.config.ConfigMapPropertySourceLocator.locate(ConfigMapPropertySourceLocator.java:67) ~[spring-cloud-kubernetes-commons-2.0.3.jar!/:2.0.3]
    at org.springframework.cloud.bootstrap.config.PropertySourceLocator.locateCollection(PropertySourceLocator.java:51) ~[spring-cloud-context-3.0.3.jar!/:3.0.3]
    at org.springframework.cloud.bootstrap.config.PropertySourceLocator.locateCollection(PropertySourceLocator.java:47) ~[spring-cloud-context-3.0.3.jar!/:3.0.3]
    at org.springframework.cloud.bootstrap.config.PropertySourceBootstrapConfiguration.initialize(PropertySourceBootstrapConfiguration.java:95) ~[spring-cloud-context-3.0.3.jar!/:3.0.3]
    at org.springframework.boot.SpringApplication.applyInitializers(SpringApplication.java:639) ~[spring-boot-2.4.9.jar!/:2.4.9]
    at org.springframework.boot.SpringApplication.prepareContext(SpringApplication.java:402) ~[spring-boot-2.4.9.jar!/:2.4.9]
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:338) ~[spring-boot-2.4.9.jar!/:2.4.9]
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:1329) ~[spring-boot-2.4.9.jar!/:2.4.9]
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:1318) ~[spring-boot-2.4.9.jar!/:2.4.9]
    at com.example.echo.Bootstrapper.main(Bootstrapper.java:23) ~[classes!/:na]
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:na]
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:na]
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:na]
    at java.base/java.lang.reflect.Method.invoke(Method.java:566) ~[na:na]
    at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:49) ~[service.jar:na]
    at org.springframework.boot.loader.Launcher.launch(Launcher.java:108) ~[service.jar:na]
    at org.springframework.boot.loader.Launcher.launch(Launcher.java:58) ~[service.jar:na]
    at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:88) ~[service.jar:na]

总而言之，我试图确定如何在 Kubernetes 世界中进行类似于 Docker Swarm 环境中的Spring云配置为我提供的设置，在该环境中，我们使用由Spring云尤里卡、Spring云配置和Spring云网关组成的堆栈。例如，今天我有了与我的所有微服务相关的通用属性，这些属性在我的 Git 存储库中可用作应用程序.yml 和应用程序配置文件.yml 文件。我的想法是，这些属性将在 Kubernetes 中作为公共命名空间中的配置映射提供，而我的 xyz-microservice.yml 今天由 Spring Cloud 配置加载并与应用程序.yml 和应用程序配置文件.yml 属性结合使用，将位于其自己的命名空间中。

Answer 1

Spring云库伯内特斯需要访问库伯内特斯API，以便能够检索为单个服务运行的 Pod 的地址列表。

你试过服务账户部分吗？-https://cloud . spring . io/spring-cloud-kubernetes/reference/html/# service-account

基本上，您需要为ServiceAccount应该访问的每个名称空间创建一个RoleBinding。