K
Q

Kubernetes configmap name is not picked up by springboot application

1/14/2018

I am integrating kubernetes configmap with my springboot application. I created config-map, given its name in my bootstrap.yml file and have a simple RestController to read the properties. However, the name of the configmap is not picked up by the pod. In the logs of the pod I see the name of the configmap as 'default'. I don't know what's going wrong. Appreciate any help!

 Located property source: ConfigMapPropertySource [name='configmap.application.default']

Here is my configmap

apiVersion: v1
kind: ConfigMap
metadata:
  name: echo-configmap
data:
  application.yml: |-
    bean:
      message: Hello from Kubernetes Configmap

pom.xml

    <dependency>
           <groupId>org.springframework.cloud</groupId>
           <artifactId>spring-cloud-starter-kubernetes-config</artifactId>
           <version>0.2.0.RELEASE</version>
    </dependency>

bootstrap.yml

 spring:
 application:
  name: echo-configmap

 cloud:
kubernetes:
  reload:
     enabled: true

Controller class

@RestController
 @EnableConfigurationProperties
@ConfigurationProperties(prefix = "bean")
public class EchoConfigController {

@Value("${message}")
private String message;



@RequestMapping(value="/echo", method=GET)
public String printKubeConfig() {
    System.out.println("EchoController is invoked ");
    System.out.println("message = "+message);
    return message;
}

}

Kubernetes pod logs:

[kubernetes1@se-docker-int-2 ~]$ kubectl logs echo-deployment-2968296553-h8m1q
04:53:33.873 [main] DEBUG io.fabric8.kubernetes.client.Config - Trying to configure client from Kubernetes config...
2018-01-14 04:53:42.122  INFO 7 --- [           main] b.c.PropertySourceBootstrapConfiguration : Located property source: ConfigMapPropertySource [name='configmap.application.default']
 2018-01-14 04:53:42.125  INFO 7 --- [           main] b.c.PropertySourceBootstrapConfiguration : Located property source: SecretsPropertySource [name='secrets.application.default']
2018-01-14 04:53:42.181  INFO 7 --- [           main] c.o.a.c.EchoServiceApplication           : The following profiles are active: kubernetes
-- A V
kubernetes
maven
spring-boot

Similar Questions

Starting an Ingress service on Docker for Mac
Limit access to a a kubernetes cluster on google cloud platform
How does Kubernetes track which cloud disk is attached to which Pod in a StatefulSet?
Kubernetes installation on fedora meets a package conflict

2 Answers

1/14/2018

That's not the name of the ConfigMap, it's the name of the kubernetes namespace in which it's running, as seen here, showing that in your example the "name" is application.

You didn't actually say whether you tested the RestController, to say what it returns (and/or emits to stdout); did your GET produce any output, or are you asking this question solely based on that log message?

bootstrap.yml

 spring:
 application:
  name: echo-configmap

I can't tell if you have just mis-copy-pasted, but if you really do have the spring: key indented in your bootstrap.yml, then that file will be mis-parsed by Spring, causing the spring.application.name to not be what you think.

data:
  application.yml: |-
    bean:
      message: Hello from Kubernetes Configmap
...
@EnableConfigurationProperties
@ConfigurationProperties(prefix = "bean")

Foremost, you are treading on thin ice by naming your ConfigurationProperties prefix a very generic word like bean. Secondarily, you are making things harder by causing your RestController to serve as your ConfigurationProperties instance, too, since they have very, very different lifecycles within Spring. Thirdly, I would need to test it to say with certainty, but @Value is traditionally used to inject a SPeL value into some other bean, not a random field in the ConfigurationProperties -- you'll get a lot further by just making message into a normal JavaBean property via its getMessage()/setMessage() accessor/mutator pattern. Plus, doing it that way has the very, very real benefit that you can set a breakpoint inside the get or set method and see for yourself that Spring is calling them with the values you expect.

-- mdaniel
Source: StackOverflow
3/6/2018

The issue was that I didn't package my application.properties in the JAR file. Hence the application name was not read. After fixing the packaging it worked

-- A V
Source: StackOverflow