Quarkus Kubernetes Config扩展覆盖application.yml出现异常问题

核心问题本质 #

你遇到的是Quarkus原生构建环境与JVM模式（如CI环境）下，配置覆盖逻辑不一致的问题：原生构建时直接用环境变量覆盖application.yml的静态配置无效，只有通过占位符引用环境变量才生效，而JVM模式下两种方式都正常。

原因拆解 #

Quarkus原生构建的核心优化之一是配置静态固化：

• JVM模式下，Quarkus运行时会加载所有配置源（环境变量、ConfigMap等），并按照标准优先级覆盖；
• 原生构建阶段，Quarkus会对application.yml中的静态配置值做固化处理——如果配置项是明确的字符串值（而非${变量}占位符），会直接写入镜像，运行时不再读取对应环境变量，导致覆盖失效。

你的测试结果完全符合这个逻辑：

• 直接设置QUARKUS_LOG_LEVEL无效，是因为原生构建已经把application.yml里的日志级别固化；
• 用${MY_LOG_LEVEL:debug}时，原生构建识别到需要动态读取环境变量，所以运行时变量变更会生效，无效值也会触发异常。

关于扩展变更的说明 #

近期Quarkus 2.13及以上版本对原生构建的配置处理做了严格优化：

• 默认情况下，只有通过占位符明确引用的环境变量，才会被标记为动态可覆盖；
• 未使用占位符的配置项，即使是Kubernetes Config Extension引入的环境变量，也会被视为静态配置，原生构建后无法在运行时覆盖。

解决方案 #

有两种可行方案：

1. 全局使用占位符配置
   在application.yml中，对所有需要动态覆盖的配置项采用${环境变量名:默认值}的格式，确保原生构建时识别到动态需求：

   quarkus:
     oidc:
       auth-server-url: ${QUARKUS_OIDC_AUTH_SERVER_URL:https://localhost:8543/auth/realms/test}
   

2. 强制原生构建保留动态配置
   通过构建参数指定需要保留动态读取能力的配置项，比如在application.yml中添加：

   quarkus:
     native:
       additional-build-args: -Dquarkus.oidc.auth-server-url=${QUARKUS_OIDC_AUTH_SERVER_URL}
   

   或者全局开启环境变量作为动态配置源：

   quarkus:
     native:
       additional-build-args: -Dquarkus.config.locations=classpath:application.yml,environment-variables
   

总结 #

这不是配置优先级逻辑的变更，而是原生构建的优化特性导致的差异。JVM模式依赖运行时配置加载，而原生构建需要明确标记动态配置项，要么用占位符，要么通过构建参数声明。

内容的提问来源于stack exchange，提问作者KJQ