阅读Spring Cloud Kubernetes文档后，Spring Cloud Kubornetes似乎支持跨多个命名空间从ConfigMaps加载属性。以下是文档中的示例：
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相同的命名空间中从ConfigMap加载属性没有问题，但当我尝试在不同的命名空间(在本例中为common(中加载来自ConfigMap的属性时，我会遇到以下异常：
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 Cloud Config目前为我提供的设置，在该环境中，我们使用由Spring Cloud Eureka、Spring Cloud Config和Spring Cloud Gateway组成的堆栈。例如，今天我有了与我的Git repo中可用的application.yml和application-profile.yml文件的所有微服务相关的公共属性。我的想法是，这些属性将在Kubernetes中作为common命名空间中的ConfigMaps提供，而我的xyz-microservice.yml(今天由Spring Cloud Config加载并与application.yml和application-profile.yml属性组合(将在其自己的命名空间中。
Spring Cloud Kubernetes需要访问Kubernetesneneneba API，以便能够检索为单个服务运行的pods的地址列表。
你试过服务帐户部分吗？-https://cloud.spring.io/spring-cloud-kubernetes/reference/html/#service-账户
基本上，您需要为ServiceAccount应该访问的每个命名空间创建一个RoleBinding