Deployment strategies are used to change or upgrade applications without downtime so that users barely notice a change.
Because users generally access applications through a route handled by a router, deployment strategies can focus on DeploymentConfig
object features or routing features. Strategies that focus on DeploymentConfig
object features impact all routes that use the application. Strategies that use router features target individual routes.
Most deployment strategies are supported through the DeploymentConfig
object, and some additional strategies are supported through router features.
Consider the following when choosing a deployment strategy:
-
Long-running connections must be handled gracefully.
-
Database conversions can be complex and must be done and rolled back along with the application.
-
If the application is a hybrid of microservices and traditional components, downtime might be required to complete the transition.
-
You must have the infrastructure to do this.
-
If you have a non-isolated test environment, you can break both new and old versions.
A deployment strategy uses readiness checks to determine if a new pod is ready for use. If a readiness check fails, the DeploymentConfig
object retries to run the pod until it times out. The default timeout is 10m
, a value set in TimeoutSeconds
in dc.spec.strategy.*params
.
modules/deployments-rolling-strategy.adoc modules/deployments-canary-deployments.adoc modules/creating-rolling-deployments-CLI.adoc :context: rolling-strategy modules/odc-editing-deployments.adoc modules/odc-starting-rolling-deployment.adoc
modules/deployments-recreate-strategy.adoc :context: recreate-strategy modules/odc-editing-deployments.adoc modules/odc-starting-recreate-deployment.adoc
modules/deployments-custom-strategy.adoc :context: custom-strategy modules/odc-editing-deployments.adoc