mirror of
https://github.com/kubernetes-sigs/kubespray.git
synced 2026-01-31 17:19:17 -03:30
Add graceful upgrade process
Based on #718 introduced by rsmitty. Includes all roles and all options to support deployment of new hosts in case they were added to inventory. Main difference here is that master role is evaluated first so that master components get upgraded first. Fixes #694
This commit is contained in:
@@ -18,7 +18,7 @@ versions. Here are all version vars for each component:
|
||||
* flannel_version
|
||||
* kubedns_version
|
||||
|
||||
#### Example
|
||||
#### Unsafe upgrade example
|
||||
|
||||
If you wanted to upgrade just kube_version from v1.4.3 to v1.4.6, you could
|
||||
deploy the following way:
|
||||
@@ -33,6 +33,20 @@ And then repeat with v1.4.6 as kube_version:
|
||||
ansible-playbook cluster.yml -i inventory/inventory.cfg -e kube_version=v1.4.6
|
||||
```
|
||||
|
||||
#### Graceful upgrade
|
||||
|
||||
Kargo also supports cordon, drain and uncordoning of nodes when performing
|
||||
a cluster upgrade. There is a separate playbook used for this purpose. It is
|
||||
important to note that upgrade-cluster.yml can only be used for upgrading an
|
||||
existing cluster. That means there must be at least 1 kube-master already
|
||||
deployed.
|
||||
|
||||
```
|
||||
git fetch origin
|
||||
git checkout origin/master
|
||||
ansible-playbook upgrade-cluster cluster.yml -i inventory/inventory.cfg
|
||||
```
|
||||
|
||||
#### Upgrade order
|
||||
|
||||
As mentioned above, components are upgraded in the order in which they were
|
||||
|
||||
Reference in New Issue
Block a user