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

Question

在阅读Spring Cloud Kubernetes documentation时，似乎Spring Cloud Kubernetes支持跨多个命名空间从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 documentation的规定，“Pod和ConfigMap必须位于相同的名称空间中。”

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

从与我的Spring Boot pod相同名称空间的ConfigMaps加载属性没有问题，但是当我尝试加载来自不同名称空间(在本例中为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世界中，如何拥有一个类似于Spring Cloud Config目前在我们的Docker Swarm环境中提供给我的设置，在这个环境中，我们正在使用由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属性组合在其自己的名称空间中。

Answer 1

Spring Cloud Kubernetes需要访问Kubernetes API，以便能够检索为单个服务运行的pods的地址列表。

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

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