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.
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: falseCreate 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=DEVTesting 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: 500mAfter 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.
Selected Java Interview Questions
A professional Java tech channel sharing common knowledge to help developers fill gaps. Follow us!
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.