Kubernetes native configuration managenment

[DanielLiu1123]

Background

Kubernetes has become synonymous with cloud-native, and building applications based on Kubernetes can help us reduce maintenance costs and software complexity, so imagine if Kubernetes could be integrated into the Spring ecosystem, which I'm sure could solve any problem you're facing.

Kubernetes provides Configmap and Secret to manage configuration, Spring Cloud provides the ability to dynamically refresh at runtime, and the combination of the two makes for a "cloud-native configuration center" with native-supported RBAC, so you don't need Nacos (config) / Apollo anymore.

Goals

• Ability to pull the specified configuration and resolve it to the Spring environment when the application starts up.
• Provides the ability to dynamically refresh and get the latest values when configmap/secret is changed.
• Configure priority, prioritize local configuration or remote configuration
• Completely driven by configuration, providing configuration items similar to the following

spring:
  cloud:
    k8s:
      configmaps:
        - name: demo-configmap-01
          namespace: default
          refreshable: true
        - name: demo-configmap-02
          namespace: default
          refreshable: false
          priority: local
      secrets:
        - name: demo-secret
          namespace: default
          refreshable: true 

[steverao]

It looks good! But we need to discuss which main branch of 2.2.x/2021.x/2022.x that will support the ability.

[DanielLiu1123]

I think it is possible to support both 2021.x and 2022.x branches.

[DanielLiu1123]

This module has the same purpose as Spring Cloud Kubernetes Config, to provide Kubernetes ConfigMap/Secret as a remote configuration with the ability to be dynamically refreshed.

But one major difference is that Spring Cloud Kubernetes Config relies on the spring-cloud-starter-bootstrap implementation for its configurations. So the configurations need to be placed in bootstrap.yml or by using import: spring.config.import=kubernetes:config.

Both of these approaches have some limitations.

For way one:

• The biggest problem is that it depends on spring-cloud-starter-bootstrap, the performance of refresh is not good. It will introduce parent-child context, increasing the use and understanding cost.
• You can not specify whether to dynamically refresh for a single configuration.
• You can not specify the configuration priority.

For way two:

• without the parent-child context, refresh performance will be better, but not much better, because in the refresh phase will go to pull all configurations.
• The main problem is the configuration is not flexible enough, for example, you can't specify different namespace for different configurations, can not specify whether to dynamically refresh for a single configuration, can not specify the configuration priority...

What problems are solved by Spring Cloud Alibaba Kubernetes Config module?

1. Unified configuration, unlike Spring Cloud Kubernetes has two sets of configuration, reducing the cost of use.
2. The implementation does not depend on spring-cloud-starter-bootstrap, all configurations are placed in application.yml, there is no parent-child context, which is more convenient for debugging and understanding.
3. More flexible and simple configuration, you can specify different namesapce, configuration priority, refreshable for different configurations.
4. Better refresh performance, in the refresh phase will not pull any configuration, but only the latest configuration will be resolved as PropertySource and added to the environment, so this approach should have theoretical best performance for the refresh phase.

Configurations when using Spring Cloud Kubernetes Config and Spring Cloud Alibaba Kubernetes Config:

• Spring Cloud Kubernetes Config

spring:
  cloud:
    kubernetes:
      reload:
        enabled: true
        monitoring-config-maps: true
        monitoring-secrets: true
      config:
        sources:
          - name: configmap-01
            namespace: default
      secrets:
        sources:
          - name: secret-01
            namespace: default

• Spring Cloud Alibaba Kubernetes Config

spring:
  cloud:
    k8s:
      config:
        config-maps:
          - name: configmap-01
            namespace: default
            refreshable: true
        secrets:
          - name: secret-01
            namespace: default
            refreshable: true

[ruansheng8]

@DanielLiu1123
Why Spring Cloud Alibaba Kubernetes Config using spring.cloud.k8s.config instead of using spring.cloud.kubernetes.config, it may be a better choice to keep the configuration properties of similar functional modules consistent.

[DanielLiu1123]

Why Spring Cloud Alibaba Kubernetes Config using spring.cloud.k8s.config instead of using spring.cloud.kubernetes.config.

This is tricky one, it conflicts with Spring Cloud Kubernetes if we use spring.cloud.kubernetes.config.

spring.cloud.alibaba-kubernetes.config might also be an option?

[DanielLiu1123]

I think spring.cloud.alibaba.kubernetes.config is a good choice

All of the modules don't have alibaba in the prefix, such as spring.cloud.nacos, spring.cloud.sentinel, if the prefix contains alibaba from the beginning, it's a good choice.

I think both spring.cloud.alibaba-kubernetes and spring.cloud.alibaba.kubernetes are acceptable.

[steverao]

I think spring.cloud.alibaba.kubernetes.config is a good choice

All of the modules don't have alibaba in the prefix, such as spring.cloud.nacos, spring.cloud.sentinel, if the prefix contains alibaba from the beginning, it's a good choice.

I think both spring.cloud.alibaba-kubernetes and spring.cloud.alibaba.kubernetes are acceptable.

I suggest using spring.cloud.alibaba-kubernetes, alibaba-kubernetes is component name. It will be same as before.