maxunavailable-deployment-parameter¶
maxUnavailable is a configuration parameter used within the [[deployment-strategies|RollingUpdate]] strategy of a Kubernetes Deployment.^[400-devops__06-Kubernetes__k8s-ithelp__Day13__README.md]
Definition¶
The parameter defines the maximum number of [[pods|Pods]] that can be unavailable during the update process.^[400-devops__06-Kubernetes__k8s-ithelp__Day13__README.md] It is used to control the rate and stability of a rolling update by specifying how many instances may be down at any given moment.
In a Kubernetes manifest, this is set using the path spec.strategy.rollingUpdate.maxUnavailable.^[400-devops__06-Kubernetes__k8s-ithelp__Day13__README.md]
Usage and Impact¶
When a [[deployment-strategies|Deployment]] is configured with type: RollingUpdate, the maxUnavailable parameter works in conjunction with maxSurge to manage the transition from an old version to a new version.^[400-devops__06-Kubernetes__k8s-ithelp__Day13__README.md]
- Zero Downtime: Setting
maxUnavailable: 0ensures that no pods are terminated before new pods are ready, effectively preventing service downtime during the update.^[400-devops__06-Kubernetes__k8s-ithelp__Day13__README.md] - Faster Updates: Allowing a higher number of unavailable pods can speed up the deployment process by terminating old instances sooner, though this increases the risk of service capacity reduction.
This parameter is distinct from the [[recreate-deployment-strategy|Recreate]] strategy, where all instances are terminated simultaneously, resulting in inherent downtime.^[400-devops__06-Kubernetes__k8s-ithelp__Day13__README.md]
Related Concepts¶
- maxsurge-deployment-parameter
- [[deployment-strategies]]
- [[recreate-deployment-strategy]]