How to Leverage Apollo Config Center for Dynamic SpringBoot Configuration in Kubernetes

1. Core Concepts

Apollo is an open‑source distributed configuration center developed by Ctrip that centralizes configuration management across environments, clusters, and namespaces, supporting real‑time updates, gray releases, and fine‑grained permission control.

1.1 Background

As microservice applications grow, traditional file‑based or database configuration becomes insufficient. Apollo addresses the need for dynamic, environment‑aware configuration with features such as real‑time push, gray release, and multi‑environment support.

1.2 Overview

Apollo provides a centralized portal for managing configuration items (key‑value pairs) and offers Java and .NET native clients for fetching configurations.

1.3 Key Features

Simple deployment

Gray release

Version management

Open API

Local cache

Permission and audit

Multi‑environment, multi‑cluster, multi‑namespace support

1.4 Basic Model

Application modifies a configuration and publishes it.

Apollo notifies the client of the update.

The client pulls the latest configuration, updates its local cache, and notifies the application.

The following diagram (original image) illustrates the client‑server interaction.

1.5 Four Dimensions

application : Unique app ID (e.g., app.id).

environment : DEV, FAT, UAT, PRO.

cluster : Logical grouping such as data‑center clusters.

namespace : Logical separation of configuration files (e.g., application.yml).

1.6 Local Cache

Apollo caches configuration files locally (e.g., /opt/data/{appId}/config-cache on Linux or C:\opt\data\{appId}\config-cache on Windows). The cache file name follows the pattern {appId}+{cluster}+{namespace}.properties.

1.7 Client Design

The client maintains a long‑running HTTP long‑polling connection to receive push notifications. If no change occurs within 60 seconds, the server returns HTTP 304. A fallback polling mechanism runs every 5 minutes (configurable via apollo.refreshInterval).

1.8 Overall Architecture

Config Service handles configuration reads and pushes; Admin Service handles publishing. Both services are stateless and register to Eureka. A Meta Server abstracts service discovery. The diagram (original image) shows the layered design.

2. Creating a Project and Configuration in Apollo

Log in to the Apollo portal (default credentials: apollo / admin) and create a new project, specifying the application ID ( apollo-test) and name ( apollo-demo).

Add a configuration key test with value 123456 and publish it.

3. Building a SpringBoot Test Application

3.1 Add Maven Dependency

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.1.8.RELEASE</version>
    </parent>
    <groupId>club.mydlq</groupId>
    <artifactId>apollo-demo</artifactId>
    <version>0.0.1</version>
    <name>apollo-demo</name>
    <description>Apollo Demo</description>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>com.ctrip.framework.apollo</groupId>
            <artifactId>apollo-client</artifactId>
            <version>1.4.0</version>
        </dependency>
    </dependencies>
    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>
</project>

3.2 Application.yml Configuration

# Application configuration
server:
  port: 8080
spring:
  application:
    name: apollo-demo

# Apollo configuration
app:
  id: apollo-test
apollo:
  cacheDir: /opt/data
  cluster: default
  meta: http://192.168.2.11:30002
  autoUpdateInjectedSpringProperties: true
  bootstrap:
    enabled: true
    namespaces: application
    eagerLoad:
      enabled: false

3.3 Test Controller

@RestController
public class TestController {
    @Value("${test:默认值}")
    private String test;

    @GetMapping("/test")
    public String test() {
        return "test的值为:" + test;
    }
}

3.4 Application Entry Point

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

3.5 JVM Startup Parameters

When running in Kubernetes, add the following JVM arguments:

-Dapollo.configService=http://192.168.2.11:30002 -Denv=DEV

For a plain java command:

java -Dapollo.configService=http://192.168.2.11:30002 -Denv=DEV -jar apollo-demo.jar

4. Running Tests

4.1 Verify Initial Value

After starting the app, http://localhost:8080/test returns test的值为:123456, confirming the value comes from Apollo.

4.2 Dynamic Update

Modify the test key in Apollo to 666666 and publish. The endpoint now returns test的值为:666666 without restarting the app.

4.3 Rollback

Rollback the configuration in Apollo; the endpoint reverts to the previous value 123456.

4.4 Offline Scenario

If the Apollo address is incorrect, the client falls back to the local cache and still returns the last known value. Deleting the cache file forces the app to use the default value defined in @Value.

4.5 Deleting the Key

Removing the test key from Apollo causes the endpoint to return the default value 默认值.

5. Exploring Cluster, Environment, and Namespace

5.1 Different Environments

By changing the JVM -Denv=PRO and pointing apollo.meta to the production config server, the same key can return a production‑specific value (e.g., abcdefg).

5.2 Different Clusters

Create clusters beijing and shanghai with distinct test values. Set apollo.cluster=beijing (or shanghai) in application.yml to fetch the corresponding value.

5.3 Different Namespaces

Create private namespaces dev-1 and dev-2, each holding a different test value. Configure apollo.bootstrap.namespaces=dev-1 (or dev-2) to retrieve the respective value.

6. Deploying the SpringBoot Application on Kubernetes

6.1 Build Docker Image

FROM openjdk:8u222-jre-slim
VOLUME /tmp
ADD target/*.jar app.jar
RUN sh -c 'touch /app.jar'
ENV JAVA_OPTS="-XX:MaxRAMPercentage=80.0 -Duser.timezone=Asia/Shanghai"
ENV APP_OPTS=""
ENTRYPOINT [ "sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar $APP_OPTS" ]

Build the image:

docker build -t mydlqclub/springboot-apollo:0.0.1 .

6.2 Kubernetes Manifest

The manifest defines a Service (NodePort) and a Deployment. Environment variables inject Apollo settings:

apiVersion: v1
kind: Service
metadata:
  name: springboot-apollo
spec:
  type: NodePort
  ports:
    - name: server
      nodePort: 31080
      port: 8080
      targetPort: 8080
    - name: management
      nodePort: 31081
      port: 8081
      targetPort: 8081
  selector:
    app: springboot-apollo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: springboot-apollo
  labels:
    app: springboot-apollo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: springboot-apollo
  template:
    metadata:
      name: springboot-apollo
      labels:
        app: springboot-apollo
    spec:
      restartPolicy: Always
      containers:
        - name: springboot-apollo
          image: mydlqclub/springboot-apollo:0.0.1
          imagePullPolicy: Always
          ports:
            - containerPort: 8080
              name: server
          env:
            - name: JAVA_OPTS
              value: "-Denv=DEV"
            - name: APP_OPTS
              value: "\
                --app.id=apollo-demo\
                --apollo.bootstrap.enabled=true\
                --apollo.bootstrap.eagerLoad.enabled=false\
                --apollo.cacheDir=/opt/data/\
                --apollo.cluster=default\
                --apollo.bootstrap.namespaces=application\
                --apollo.autoUpdateInjectedSpringProperties=true\
                --apollo.meta=http://service-apollo-config-server-dev.mydlqcloud:8080\
                "
          resources:
            limits:
              memory: 1000Mi
              cpu: 1000m
            requests:
              memory: 500Mi
              cpu: 500m

Deploy with:

kubectl apply -f springboot-apollo.yaml -n mydlqcloud

6.3 Verify Deployment

Access the service via NodePort (e.g., http://192.168.2.11:31081/test) and observe the same dynamic value ( 123456) returned from Apollo.

Source: Internet