ConfigServerInstanceProvider$Function has not been registered in kubernetes

[mschneid0207]

Hello together,

I migrated from Spring Boot 2.3.2 to 2.5.6. When starting up the services and using eureka as service discovery everything is running fine. All my client services are finding correctly the spring cloud config service and fetching their configurations from it. But when I use the service discovery from spring cloud kubernetes (spring-cloud-starter-kubernetes-all) I always getting the following error.

I always get the following error. java.lang.IllegalStateException: org.springframework.cloud.config.client.ConfigServerInstanceProvider$Function has not been registered at org.springframework.boot.DefaultBootstrapContext.lambda$get$1(DefaultBootstrapContext.java:88) at org.springframework.boot.DefaultBootstrapContext.getOrElseThrow(DefaultBootstrapContext.java:109) at org.springframework.boot.DefaultBootstrapContext.get(DefaultBootstrapContext.java:88) at org.springframework.cloud.config.client.ConfigServerConfigDataLocationResolver.lambda$resolveProfileSpecific$8(ConfigServerConfigDataLocationResolver.java:196) ........

Here is my config in the application.yml of one of my client services (e.g. customer-service).

spring:
  application:
    name: customer-service
  config:
    import: "configserver:"
  cloud:
    config:
      discovery:
        enabled: true
        service-id: config-service
      retry:
        max-attempts: 10
      fail-fast: true

I tested it with spring cloud dependencies 2020.0.0 - 2020.0.4. But I am always getting the following error. Also I tested with different version of spring-cloud-starter-kubernetes-all. I always getting the same error.

Thanks a lot for your support.

Regards Markus

[vananiev]

I've got same exception with:

• spring-boot 2.6.6
• spring-boot 2.6.5
• spring-boot 2.6.4
• spring-boot 2.6.0 (breaking build)

Client app works on

• spring-boot 2.5.12
• spring-boot 2.5.5

I tested with Spring Cloud 2020.0.5

[ryanjbaxter]

Can you please try Spring Cloud 2021.0.1?

[vananiev]

Yes. Spring Boot 2.6.6 + Spring Cloud 2021.0.1 starts, but client can't get config from Cloud Server.

Server has this configuration

spring.cloud.config.server.prefix=cloud-config
spring.cloud.config.server.composite[0].type=native
spring.cloud.config.server.composite[0].search-locations=file:test/{application}/{label}

and client calls GET /app/default/master from Cloud Server 2021.0.1, thereas from 2020.0.5 Cloud Server client calls right address - GET /cloud-config/app/default/master.

So client from Cloud Server 2021.0.1 can't pull it's configuration.

The difference in debug mode on client side in ConfigServerInstanceMonitor:105-111

if (server.getMetadata().containsKey("configPath")) {
    String path = server.getMetadata().get("configPath");
    if (url.endsWith("/") && path.startsWith("/")) {
        url = url.substring(0, url.length() - 1);
    }
    url = url + path;
}

Config Server 2020.0.5 provides configPath = cloud-config (configured in spring.cloud.config.server.prefix=cloud-config), but Config Server 2021.0.1 doesn't provide configPath methadata.

So problem on Config Server 2021.0.1 side.

[ryanjbaxter]

Can you provide a complete, minimal, verifiable sample that reproduces the problem? It should be available as a GitHub (or similar) project or attached to this issue as a zip file.

[vananiev]

Sorry, can't reproduce problem with minimal sample. My app with Config Server 2020.0.5 configures configPath in Eureka metadata if spring.cloud.config.server.prefix was set, but Config Server 2021.0.1 doesn't configure configPath.

I need more time to explore, come back later.

[vananiev]

I found the problem.

Spring Boot 2.5.12 + Spring Cloud 2020.0.5 + Spring Cloud Starter Netflix Ribbon 2.2.7 + Ribbon Eureka 2.3.0 leads to this order in methods call

1. EurekaClientConfigServerAutoConfiguration:41 (adds configPath to metadata)
2. DicscoveryClient:338 (client registeration)

This is ok, configPath appears in client's Eureka metadata.

Now if I update only Spring Boot to 2.6.6 and Spring Cloud to 2021.0.1, then app starts, but calls are reordered

1. DicscoveryClient:338 (client registeration)
2. EurekaClientConfigServerAutoConfiguration:41 (adds configPath to metadata)

So, there is no configPath in clients's Eureka metadata.

Now if I update ribbon's version too (finally I've got Spring Boot 2.6.6 + Spring Cloud 2021.0.1 + Spring Cloud Starter Netflix Ribbon 2.2.10 + Ribbon Eureka 2.7.18), methods are called in right order

1. EurekaClientConfigServerAutoConfiguration:41
2. DicscoveryClient:338

configPath again appears in client's Eureka metadata.

Problem in old version of Ribbon Eureka 2.3.0. Workaround is to add

eureka.instance.metadataMap.configPath=${spring.cloud.config.server.prefix}

to bootstrap.properties

Thanks.

[ryanjbaxter]

Ribbon is no longer supported, you configuration is invalid https://github.com/spring-cloud/spring-cloud-release/wiki/Spring-Cloud-2020.0-Release-Notes#breaking-changes-1

[alejandroMartin]

Hi, I have the same problem with Spring Boot 2.6.7 and Spring Cloud 2021.0.2 using spring-cloud-starter-kubernetes-fabric8. Here is a minimal sample application I've created from Spring Initializr that reproduces the problem. I hope may help.

[ryanjbaxter]

Please provide instructions on how to reproduce the problem with the sample

[alejandroMartin]

Sorry, I get the error when application starts, so just run the default test class.

[ryanjbaxter]

I created an issue in Spring Cloud Kubernetes https://github.com/spring-cloud/spring-cloud-kubernetes/issues/1021

We will need to do some work there in order to support this

[LybrialsGit]

Im currently running into the same issue with:

• Spring Boot 2.7.2
• Spring Cloud 2021.0.3

My configserver is set to a eureka service name:

spring.cloud.config.enabled: true
spring.cloud.config.discovery.enabled: true
spring.cloud.config.discovery.serviceId: config-server
spring.config.import=configserver:https://config-server
spring.cloud.config.failFast: true
spring.cloud.config.allowOverride: true

[ryanjbaxter]

Please try 2021.0.8

[ryanjbaxter]

This was fixed by https://github.com/spring-cloud/spring-cloud-kubernetes/issues/1021