在 Kubernetes 上启动 Quarkus 时出现 NumberFormatException

Question

I'm trying to deploy a Quarkus app to a Kubernetes cluster, but I got the following stacktrace:

exec java -Dquarkus.http.host=0.0.0.0 -Djava.util.logging.manager=org.jboss.logmanager.LogManager -XX:+ExitOnOutOfMemoryError -cp . -jar /deployments/quarkus-run.jar
__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2021-05-11 16:47:19,455 ERROR [io.qua.run.Application] (main) Failed to start application (with profile prod): java.lang.NumberFormatException: SRCFG00029: Expected an integer value, got "tcp://10.233.12.82:80"
    at io.smallrye.config.Converters.lambda$static$60db1e39$1(Converters.java:104)
    at io.smallrye.config.Converters$EmptyValueConverter.convert(Converters.java:949)
    at io.smallrye.config.Converters$TrimmingConverter.convert(Converters.java:970)
    at io.smallrye.config.Converters$BuiltInConverter.convert(Converters.java:872)
    at io.smallrye.config.Converters$OptionalConverter.convert(Converters.java:790)
    at io.smallrye.config.Converters$OptionalConverter.convert(Converters.java:771)
    at io.smallrye.config.SmallRyeConfig.getValue(SmallRyeConfig.java:225)
    at io.smallrye.config.SmallRyeConfig.getOptionalValue(SmallRyeConfig.java:270)
    at io.quarkus.arc.runtime.ConfigRecorder.validateConfigProperties(ConfigRecorder.java:37)
    at io.quarkus.deployment.steps.ConfigBuildStep$validateConfigProperties1249763973.deploy_0(ConfigBuildStep$validateConfigProperties1249763973.zig:328)
    at io.quarkus.deployment.steps.ConfigBuildStep$validateConfigProperties1249763973.deploy(ConfigBuildStep$validateConfigProperties1249763973.zig:40)
    at io.quarkus.runner.ApplicationImpl.doStart(ApplicationImpl.zig:576)
    at io.quarkus.runtime.Application.start(Application.java:90)
    at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:100)
    at io.quarkus.runtime.Quarkus.run(Quarkus.java:66)
    at io.quarkus.runtime.Quarkus.run(Quarkus.java:42)
    at io.quarkus.runtime.Quarkus.run(Quarkus.java:119)
    at io.quarkus.runner.GeneratedMain.main(GeneratedMain.zig:29)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at io.quarkus.bootstrap.runner.QuarkusEntryPoint.doRun(QuarkusEntryPoint.java:48)
    at io.quarkus.bootstrap.runner.QuarkusEntryPoint.main(QuarkusEntryPoint.java:25)

I build the Docker image with the default dockerfile , and my quarkus-related dependencies are the following:

dependencies {
    implementation(enforcedPlatform("${quarkusPlatformGroupId}:${quarkusPlatformArtifactId}:${quarkusPlatformVersion}"))
    implementation("org.optaplanner:optaplanner-quarkus")
    implementation("io.quarkus:quarkus-resteasy")
    implementation("io.quarkus:quarkus-vertx")
    implementation("io.quarkus:quarkus-resteasy-jackson")
    implementation("io.quarkus:quarkus-undertow-websockets")
    implementation("io.quarkus:quarkus-smallrye-health")
}

I'm using Quarkus 1.13.3.Final, and I've written a helm chart for my deployment by hand. The deployed dockerfile runs fine on my machine, and the kubernetes deployment descriptor does not have that IP address in it. I think that IP is a ClusterIP of the cluster.

Any idea? Thanks

Answer 1

It's due to the docker link variables that kubernetes mimics for Service names in scope; it bites people a lot when they have generically named services such as { apiVersion: v1, kind: Service, metadata: { name: http }, ... as it will cheerfully produce environment variables of the form HTTP_PORT=tcp://10.233.12.82:80 in the Pod, and things such as Spring boot or evidently Quarkus which coerce env-vars into configuration overrides can cause the exact outcome you're experiencing

The solution is (a) don't name Services with bland names (b) "mask off" the offensive env-vars for the Pod:

...
  containers:
  - ...
    env:
    - name: HTTP_PORT
    # it doesn't need a value:, it just needs the name to be specified
    # so it hides the injected version
    - ... any remaining env-vars you really want