Skip to content

spec.strategy configuration

In Kubernetes, the spec.strategy configuration within a [[Deployment]] resource defines the strategy used to replace old Pods with new ones during an application update^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md]. This setting dictates the deployment behavior, specifically influencing how the system handles the transition between versions to balance uptime and resource usage^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md].

Two primary strategies are supported natively by the Deployment object: Recreate and RollingUpdate^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md].

Recreate Strategy

The Recreate strategy is defined by setting spec.strategy.type to Recreate^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md].

When this strategy is employed, the deployment process involves terminating all currently running instances of the application before creating new ones^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md].

  • Behavior: All Pods are shut down simultaneously, followed by the creation of the new version Pods^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md].
  • Impact: This results in a period of service downtime, the duration of which depends on the application's shutdown and startup times^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md].
  • Usage: Due to the service interruption, this approach is generally not recommended for production environments requiring high availability^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md].

RollingUpdate Strategy

RollingUpdate is the default deployment strategy for Kubernetes Deployments^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md]. It can be explicitly configured by setting spec.strategy.type to RollingUpdate^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md].

Unlike the Recreate strategy, this method updates Pods incrementally without cutting all service at once^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md]. To control the rate and safety of the update, specific parameters under spec.strategy.rollingUpdate are used^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md].

Configuration Parameters

The behavior of a rolling update is managed by two key fields^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md]:

  • maxSurge: Specifies the maximum number of Pods that can be created above the desired number of replicas during the update^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md]. For example, a value of 1 ensures that only one extra Pod is brought up at a time.
  • maxUnavailable: Defines the maximum number of Pods that can be unavailable during the update process^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md].

These parameters allow administrators to fine-tune the deployment process to ensure stability while new versions are rolled out^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md].

Sources

^[400-devops-06-kubernetes-k8s-ithelp-day13-readme.md]