Zero-downtime deployment workflow with configuration centers¶

Zero-downtime deployment workflow with configuration centers is a deployment strategy that decouples application artifacts from configuration management, allowing updates to be pushed to services without requiring new container builds or downtime.^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md] This workflow relies on a centralized configuration management system, such as Apollo, which enables dynamic configuration updates and environment separation.

Core Workflow¶

The core mechanism involves delivering a generic application image that reads its operational parameters from a central configuration center at runtime.^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md] When a configuration change is required (e.g., changing a database connection string or a service port), operators update the configuration in the center's portal. The client application then detects this change—often via a "pull" or long-polling mechanism—and applies the new configuration in real-time.^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md]

This allows for continuous updates without service interruption. For example, a Dubbo service provider can have its registry address or port updated in the configuration center; upon releasing the configuration, the service connects to the new target immediately, often without requiring a pod restart, depending on the client implementation.^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md]

Environment Separation¶

A key advantage of this workflow is the ability to manage multiple environments (e.g., Fat/Test, Production) using a single application artifact.^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md]

Single Artifact Delivery: Only one Docker image needs to be built and stored.^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md]
Environment-Specific Configuration: Different environments are distinguished by the environment variable passed to the application (e.g., -Denv=fat or -Denv=pro) and the corresponding meta server address (e.g., http://config-test.od.com).^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md]
Promotion Workflow: New code versions are typically deployed first to the Test environment. Once validated, the deployment to Production is performed by simply updating the Kubernetes Deployment (e.g., changing the image tag), causing a rolling update that swaps containers with zero downtime.^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md]

Integration Architecture¶

In a Kubernetes environment, this workflow integrates the configuration center with the cluster's native resources:

ConfigMap: Used to inject the initial bootstrap configuration into the Pod, such as the address of the configuration service (e.g., apollo.meta).^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md]
Secrets: Sensitive data, like database credentials stored in the configuration center, should be secured. While the configuration center stores the value, access must be controlled.
Ingress: Provides external access to the configuration center's management portal (e.g., portal.od.com) and the config service API endpoints.^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md]

Advantages¶

Zero Downtime: Configuration changes take effect immediately or upon a graceful refresh, without needing to kill or restart the application process.
Reduced Deployment Risk: Separating configuration from code reduces the chance of environment-specific errors (e.g., using a production database in a test environment) and eliminates the need for multiple environment-specific builds.^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md]
Operational Efficiency: Operations teams can adjust parameters dynamically via a UI (Portal) rather than modifying YAML files or rebuilding images.

Sources¶

^[400-devops__06-Kubernetes__k8s-paas__06.在K8S中集成Apollo配置中心.md]