Operations 25 min read

Comprehensive Guide to Using Apollo Configuration Center with Spring Boot and Kubernetes

This article provides a step‑by‑step tutorial on Apollo’s concepts, features, model, namespace handling, client design, high‑availability considerations, project creation, configuration management, Spring Boot client implementation, testing across environments, clusters and namespaces, and deployment on Kubernetes with Docker.

Selected Java Interview Questions
Selected Java Interview Questions
Selected Java Interview Questions
Comprehensive Guide to Using Apollo Configuration Center with Spring Boot and Kubernetes

Apollo is an open‑source distributed configuration center developed by Ctrip that centralizes configuration management for microservices, supporting real‑time updates, permission control, and multi‑environment deployment.

Basic concepts cover the background, a brief introduction, and key characteristics such as simple deployment, gray release, version management, open API, client monitoring, and real‑time push.

Fundamental model consists of three steps: (1) users modify and publish configurations in the config center, (2) the config center notifies Apollo clients of updates, and (3) clients pull the latest configuration, update local cache, and notify the application.

Four dimensions of Apollo configuration are application, environment (FAT, UAT, DEV, PRO), cluster, and namespace, each with specific usage and configuration keys like app.id , env , and namespace .

Local cache stores configuration files under /opt/data/{appId}/config-cache (Linux/macOS) or C:\opt\data\{appId}\config-cache (Windows) with filenames {appId}+{cluster}+{namespace}.properties .

Client design uses a long‑polling HTTP connection to receive push notifications, falls back to periodic polling (default every 5 minutes, configurable via apollo.refreshInterval ), and caches configurations in memory and on disk.

Configuration update push is implemented via HTTP long polling: the client sends a request, the server holds it for 60 seconds, returns immediately if a change occurs, otherwise returns 304, and the client reconnects.

Overall architecture includes Config Service (read/push), Admin Service (modify/publish), Eureka for service discovery, Meta Server for abstraction, and load‑balanced client access.

Availability considerations are illustrated in a table showing impact and fallback strategies for various failure scenarios of config services, admin services, portals, and data centers.

Creating a project and configuration steps:

Log in to Apollo Portal (default user: apollo , password: admin ).

Modify department data directly in the ApolloPortalDB if needed.

Create a project with custom department, set appId to apollo-test and name to apollo-demo .

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

Spring Boot client project :

<?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>
    <properties>
        <java.version>1.8</java.version>
    </properties>
    <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>

In application.yml add Apollo parameters such as apollo.meta , apollo.cluster , apollo.bootstrap.enabled , apollo.bootstrap.namespaces , apollo.cacheDir , etc.

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

# Apollo config
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

Create a controller to expose the test value:

@RestController
public class TestController {
    @Value("${test:默认值}")
    private String test;
    @GetMapping("/test")
    public String test() {
        return "test的值为:" + test;
    }
}

Start the Spring Boot application with JVM arguments to specify the environment and config service, e.g.:

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

Testing shows that the endpoint http://localhost:8080/test returns the value from Apollo ( 123456 ), and updates are reflected instantly after publishing changes, rolling back, or handling service outages via local cache.

Exploring environments, clusters, and namespaces demonstrates how to switch between DEV/PRO environments, specify clusters like beijing or shanghai , and use private namespaces ( dev-1 , dev-2 ) to retrieve different configuration values.

Kubernetes deployment includes building a Docker image (Dockerfile sets JAVA_OPTS and APP_OPTS ), creating a Kubernetes manifest ( springboot-apollo.yaml ) with a Service (NodePort) and Deployment, and injecting Apollo parameters via environment variables.

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:
      containers:
        - name: springboot-apollo
          image: mydlqclub/springboot-apollo:0.0.1
          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

After applying the manifest ( kubectl apply -f springboot-apollo.yaml -n mydlqcloud ), the service is reachable via the NodePort (e.g., http://192.168.2.11:31080/test ) and returns the configured value, confirming successful integration of Apollo with a cloud‑native Spring Boot application.

microservicesKubernetesconfiguration managementSpring BootApollo
Selected Java Interview Questions
Written by

Selected Java Interview Questions

A professional Java tech channel sharing common knowledge to help developers fill gaps. Follow us!

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.