Comprehensive Guide to Using Apollo Configuration Center with SpringBoot and Kubernetes

Currently many microservices use Apollo, an open‑source configuration center from Ctrip, to centralize configuration management across environments, clusters, and namespaces, enabling real‑time updates, version control, and permission governance.

Basic concepts include the four dimensions of Apollo: application, environment (FAT, UAT, DEV, PRO), cluster, and namespace, each with specific roles and access levels (public, private, inherited).

The client design relies on a long‑polling HTTP connection to receive configuration changes instantly, with a fallback periodic pull every five minutes; the client caches configurations locally to survive service outages.

Overall architecture consists of Config Service (provides read/push), Admin Service (handles modifications), and Meta Server (service discovery via Eureka), all typically deployed together in a single JVM.

To create a SpringBoot project , add the Apollo client dependency in <dependency>...</dependency> , configure app.id , apollo.meta , apollo.cluster , and other properties in application.yml , and implement a controller that injects a configuration key using @Value("${test:default}") .

Run the application with JVM arguments such as -Dapollo.configService=http:// :30002 -Denv=DEV to specify the config service address and environment.

Testing demonstrates that the application reads values from Apollo, reflects updates after publishing, rolls back changes, and falls back to cached values when the config service is unreachable; deleting the cache forces the default value to be used.

Further exploration shows how to manage different environments (PRO), clusters (e.g., beijing, shanghai), and namespaces (dev‑1, dev‑2) by adjusting apollo.meta , apollo.cluster , and apollo.bootstrap.namespaces settings.

For Kubernetes deployment , build a Docker image with a Dockerfile that sets JAVA_OPTS and APP_OPTS , then create a springboot-apollo.yaml manifest defining a Service (NodePort) and Deployment, injecting the necessary environment variables to point to the Apollo server.

Finally, access the deployed service via the NodePort to verify that dynamic configuration works in the Kubernetes cluster.